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, есть четыре фазы.
Мысль. Здесь мы пытаемся понять: какую проблему будет решать продукт? Мы также исследуем границы продукта - кто будет работать с программным обеспечением (актеры) и как они будут с ним работать (пользовательские истории). Результаты: спецификация. Продолжительность: от 2 дней до 3 недель. Участники: владелец продукта, аналитики, архитектор, руководитель проекта.
Строительство. Здесь программный архитектор создает доказательство концепции (также известное как MVP или прототип или скелет). Это работа одного человека, которая выполняется практически без взаимодействия с кем-либо еще. Архитектор строит продукт в соответствии с техническим заданием в очень ограниченные сроки. Результат будет иметь несколько ошибок и незаконченных моментов, но он реализует основную пользовательскую историю. Архитектор также настраивает непрерывные процессы интеграции и доставки. Результаты: работающее программное обеспечение. Длительность: 2-5 дней. Участники: архитектор.
Фиксация. На этой фазе мы добавляем всю “мякоть” к скелету. Эта фаза занимает большую часть времени и бюджета и включает множество участников. В некоторых проектах мы приглашаем работать до 50 человек одновременно. Поскольку мы рассматриваем все несоответствия как ошибки, эта фаза в основном связана с поиском, сообщением о найденных ошибках и их исправлением, чтобы стабилизировать продукт и подготовить его к запуску на рынок. Мы инкрементально и выпускаем программное обеспечение несколько раз в день, предпочтительно для его пользовательских чемпионов. Результаты работы: исправление ошибок через pull-запросы. Продолжительность: от недель до месяцев. Участники: программист(ы), дизайнер(ы), тестеры, рецензенты кода, архитектор, менеджер проекта.
Использование. На этой последней фазе мы запускаем продукт для его конечных пользователей и собираем их обратную связь (как положительную, так и отрицательную). Все, что они нам сообщают, регистрируется как ошибка. Затем мы классифицируем ошибки и исправляем их. Эта фаза может занимать годы, но она никогда не включает активную реализацию новых функций. Результаты работы: исправления ошибок через запросы на объединение изменений. Продолжительность: месяцы. Участники: программист(ы), рецензент(ы) кода, менеджер проекта.
Самый большой (то есть самый длительный и дорогой) этап, конечно же, это исправление. Обычно это занимает большую часть времени (более 70%). Однако, самый важный и рискованный этап - первый - мышление. Ошибка, допущенная на этапе мышления, будет стоить гораздо больше, чем ошибка, допущенная позже.
Thinking
Думание – первая и самая важная фаза.
Сначала мы даем название проекту и создаем репозиторий на GitHub. Мы стараемся хранить все наши проекты (как открытые, так и коммерческие) на GitHub. В основном потому, что эта платформа очень популярна, мощна и действительно недорога ($7/мес за набор из 5 частных проектов). Мы также ведем всю коммуникацию в трекере проблем GitHub.
Затем мы создаем простой документ SRS (Спецификация требований к программному обеспечению) на полстраницы. Обычно это делается непосредственно в исходном коде, но иногда в файле README.md на GitHub. Важно, чтобы документ находился под контролем версий. Мы будем его активно изменять в ходе проекта. README.md должен кратко определить основных “актеров” системы и описать область продукта.
Несмотря на то, что это всего лишь полстраницы, создание этого первоначального документа SRS является самым важным и самым дорогостоящим заданием во всем проекте. Мы уделяем этому шагу большое внимание. Обычно этот документ составляется одним из наших системных аналитиков в прямом общении с спонсором проекта. Мы не можем позволить себе ошибку на этом этапе.
Затем мы приглашаем нескольких новых системных аналитиков в проект. Эти ребята отвечают за превращение нашего первоначального README в более полное и подробное техническое задание. Они начинают с задавания вопросов, по одному, и представляют их в виде проблем на GitHub. Каждый вопрос адресован владельцу продукта. С использованием его/ее ответов системные аналитики изменяют документ README. Иногда мы используем Requs.
В конце фазы Thinking мы оцениваем размер проекта в количестве строк кода. Используя эту метрику HoC, мы можем грубо оценить бюджет. Оценить бюджет можно здесь.
Building
Это работа для одного архитектора. В каждом проекте, над которым мы работаем, есть архитектор, который лично отвечает за качество и технические решения. У нас есть несколько блестящих инженеров для этой роли.
Фаза строительства довольно прямолинейна. Архитектор должен реализовать решение в соответствии с README за несколько рабочих дней. Независимо от того, насколько велика идея и насколько масштабно планируется разработка, архитектор все равно должен создать (создать с нуля!) продукт, скажем, за три дня.
Кроме самого процесса создания программного обеспечения, архитектор должен настраивать все основные процессы DevOps, включая: 1) автоматизированное тестирование и контроль качества, 2) процессы развертывания и выпуска, 3) хранилище артефактов, 4) сервис непрерывной интеграции и другие.
Результатом данной фазы является готовый программный пакет, готовый к развертыванию на своем месте и доступный для тестировщиков. Также на этой фазе определяются технические требования к качеству.
Больше информации о фазе создания здесь: Девять шагов для запуска программного проекта
Fixing
Теперь пришло время сформировать распределенную команду программистов. Сначала мы приглашаем тех, кто уже работал над другими проектами и уже доказал свое качество. Очень часто мы приглашаем новых людей, находя их через Stack Overflow, GitHub, Upwork и другие источники. Средний размер команды для среднего проекта составляет 15-25 программистов.
На данном этапе мы рассматриваем любое расхождение как ошибку. Если что-то непонятно в документации, или если что-то можно перестроить для лучшей читаемости, или если функцию можно улучшить для более высокой производительности - для нас это ошибка. И ошибки приветствуются в наших проектах. Мы призываем всех сообщать о как можно большем количестве ошибок. Таким образом мы достигаем высокого качества.
Вот почему эту фазу и называют «Исправление». Мы сообщаем о багах и исправляем их. Сотни багов. Иногда тысячи. Продукт растет перед нашими глазами, потому что после каждого исправления мы снова развертываем весь продукт на производственной платформе.
Каждая ошибка сообщается, классифицируется, обсуждается и исправляется в своем собственном тикете GitHub и своей собственной ветке Git. Мы никогда не позволяем коммитить изменения напрямую в ветку master — все изменения должны пройти наш контроль качества и быть объединенными в master с помощью нашего бота для слияния rultor.com.
Также важно отметить, что вся коммуникация с владельцем продукта и между программистами происходит только через задачи в GitHub. Мы никогда не используем чаты, Skype, электронные письма или конференц-связь. Мы общаемся только через тикеты и комментарии в GitHub.
Using
Это финальная фаза и она может занять довольно много времени. К настоящему моменту продукт готов и выведен на рынок. Однако мы все еще получаем отчеты об ошибках и запросы на новые функции от владельца продукта, и мы все еще исправляем их через тот же процесс, что и в фазе исправления.
Мы стараемся сохранить эту фазу как можно более спокойной, в терминах количества сообщенных и исправленных ошибок. Благодаря нашему интенсивному и проактивному поиску и устранению ошибок в предыдущей фазе, обычно у нас возникает очень мало проблем на этапе использования.
А как насчет больших запросов на новые функции? На этой стадии мы обычно пытаемся превратить их в отдельные проекты и разрабатывать их отдельно, начиная снова с размышлений.
Кстати, иллюстрации, которые вы видите выше, выполнены Барбарой Лопес.
Translated by ChatGPT gpt-3.5-turbo/35 on 2023-09-06 at 19:40
