The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Помимо того, что я активно занимаюсь программированием, я также являюсь сооснователем и техническим директором Zerocracy, компании по разработке программного обеспечения на заказ. Во всех проектах, с которыми мы работаем, я выполняю роль технического и управленческого лидера.
Я написал эту статью для тех, кто заинтересован в найме меня и/или моей команды. Эта статья продемонстрирует, что происходит с первого дня до конца проекта, когда вы решаете работать с нами.
Ниже вы увидите, что наши методы разработки программного обеспечения серьезно отличаются от того, что используют многие другие команды. Я лично уделяю большое внимание качеству кода и качеству внутренних процессов, связывающих нашу команду.
В каждом проекте, с которым я работаю в Zerocracy, есть четыре фазы:
Здание. Здесь программный архитектор создает доказательство концепции (также известное как MVP или прототип или каркас). Это работа одного человека, которая выполняется практически без взаимодействия с другими людьми. Архитектор создает продукт в соответствии с требованиями, в очень ограниченные сроки. Результат будет содержать несколько ошибок и незаконченных моментов, но он будет реализовывать основную историю пользователя. Архитектор также настраивает непрерывную интеграцию и доставку. Результат: работающее программное обеспечение. Продолжительность: 2-5 дней. Участники: архитектор.
Исправление. На этой фазе мы добавляем всю суть к скелету. Эта фаза занимает большую часть времени и бюджета и включает множество участников. В некоторых проектах мы приглашаем до 50 человек для работы одновременно. Поскольку мы относимся ко всем несоответствиям как к ошибкам, эта фаза в основном связана с поиском, сообщением и исправлением ошибок, чтобы стабилизировать продукт и подготовить его к запуску на рынок. Мы увеличиваем и выпускаем программное обеспечение несколько раз в день, предпочтительно для его пользовательских чемпионов. Результаты: исправления ошибок через запросы на вытягивание. Продолжительность: от недель до месяцев. Участники: программист(ы), дизайнер(ы), тестировщик(и), рецензент(ы) кода, архитектор, менеджер проекта.
Использование. На этой финальной стадии мы запускаем продукт для его конечных пользователей и собираем их отзывы (как положительные, так и отрицательные). Все, что они сообщают нам, регистрируется как ошибка. Затем мы классифицируем ошибки и устраняем их. Эта фаза может занимать годы, но никогда не включает активную реализацию новых функций. Результаты: исправления ошибок через запросы на объединение изменений. Продолжительность: месяцы. Участники: программист(-ы), рецензент(-ы) кода, менеджер проекта.
Самая большая (то есть, самая продолжительная и дорогостоящая) фаза - это, конечно же, исправление. Обычно она занимает большую часть времени (более 70%). Однако, самая важная и рискованная фаза - первая, то есть мышление. Ошибка, совершенная на этапе мышления, будет стоить гораздо дороже, чем ошибка, совершенная позже.
Думание - первая и самая важная фаза.
Сначала мы называем проект и создаем репозиторий на GitHub. Мы стараемся размещать все наши проекты (как открытые, так и коммерческие) на GitHub. В основном потому, что эта платформа очень популярна, мощна и дешева ($7/мес за набор из 5 закрытых проектов). Мы также ведем всю коммуникацию в системе учета проблем GitHub.
Затем мы создаем простой документ SRS (Software Requirements Specification) размером половины страницы. Обычно это делается прямо в исходном коде, но иногда - в файле README.md на GitHub. Важно, чтобы документ был под версионным контролем. Мы будем его интенсивно изменять в ходе проекта. README.md должен кратко идентифицировать основных “действующих лиц” системы и определить область продукта.
Хотя это всего лишь полстраницы, создание этого первоначального документа SRS является самой важной и самой дорогостоящей задачей во всем проекте. Мы уделяем этому этапу большое внимание. Обычно этот документ пишется одним из наших системных аналитиков в прямом общении с заказчиком проекта. Мы не можем себе позволить ошибку на этом этапе.
Затем мы приглашаем нескольких новых системных аналитиков в проект. Эти ребята отвечают за превращение нашего начального README в более полную и детальную спецификацию. Они начинают задавать вопросы, по одному размещая их в качестве проблем на GitHub. Каждый вопрос адресован владельцу продукта. Используя его/ее ответы, системные аналитики изменяют документ README. Иногда мы используем Requs.
В конце фазы Думания мы оцениваем размер проекта в Хитах Кода. Используя эту метрику HoC, мы можем грубо оценить бюджет.
Это работа одного архитектора. В каждом проекте, над которым мы работаем, есть архитектор, который лично отвечает за качество и технические решения. У нас есть несколько блестящих инженеров для этой роли.
Фаза строительства довольно простая. Архитектор должен реализовать решение в соответствии с README за несколько рабочих дней. Независимо от того, насколько большая идея и насколько обширное планирование разработки, архитектор все равно должен создать (построить с нуля!) продукт, скажем, за три дня.
Помимо создания самого программного обеспечения, архитектор должен настроить все основные процессы DevOps, включая: 1) автоматическое тестирование и контроль качества, 2) развертывание и выпуск конвейеров, 3) хранилище артефактов, 4) сервис непрерывной интеграции и т. д.
Результатом этой фазы является работающий программный пакет, который можно развернуть в месте назначения и предоставить для тестирования. Технические требования к качеству также определены на этой фазе.
Более подробно о фазе строительства можно узнать здесь: Девять шагов для запуска проекта по разработке программного обеспечения
Теперь пришло время создать распределенную команду программистов. Сначала мы приглашаем тех, кто уже работал над другими проектами и уже доказал свою качественную работу. Очень часто мы приглашаем новых людей, находим их через Stack Overflow, GitHub, Upwork и другие источники. Средний размер команды для среднего проекта составляет от 15 до 25 программистов.
На этой стадии мы рассматриваем любое несоответствие как ошибку. Если что-то не ясно в документации, или если что-то можно переделать для лучшей читабельности, или если функцию можно улучшить для более высокой производительности, - для нас это ошибка. И ошибки приветствуются в наших проектах. Мы призываем всех сообщать как можно больше ошибок. Именно так мы достигаем высокого качества.
Вот почему эта стадия называется исправлением. Мы сообщаем об ошибках и исправляем их. Сотни ошибок. Иногда тысячи. Продукт растет прямо у нас на глазах, потому что после каждого исправления ошибки мы повторно разворачиваем весь продукт на производственной платформе.
Каждая ошибка сообщается, классифицируется, обсуждается и исправляется в своем собственном тикете GitHub и своей собственной ветке Git. Мы никогда не позволяем кому-либо просто коммитить в ветку master - все изменения должны пройти через наши контроли качества и быть смержены в master при помощи rultor.com, нашего бота для слияния.
Также важно упомянуть, что все общение с владельцем продукта и между программистами происходит только через проблемы GitHub. Мы никогда не используем чаты, Skype, электронную почту или программное обеспечение для конференций. Мы общаемся только через тикеты и комментарии в GitHub.
Это последний этап и он может занять довольно много времени. К настоящему моменту продукт готов и запущен на рынок. Но мы все еще получаем отчеты об ошибках и запросы на добавление функций от владельца продукта, и все еще исправляем их по тому же процессу, что и в фазе исправления.
Мы стараемся сделать этот этап наиболее тихим в терминах количества сообщенных и исправленных ошибок. Благодаря нашему интенсивному и проактивному поиску и устранению ошибок на предыдущем этапе, у нас обычно возникает очень мало проблем на этапе использования.
А что насчет больших запросов на функции? На этом этапе мы обычно пытаемся превратить их в новые проекты и разрабатывать их отдельно, начиная снова с размышлений.
Кстати, иллюстрации, которые вы видите выше, сделаны Барбарой Лопес.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-28 at 15:50
