Управление разработкой *

1. «У нас очень маленький и простой проект»

• Стоимость меняется на каждой стадии разработки
• Решение задачи изменяется и улучшается с каждой моделью
• На каждой стадии, решения могут согласовываться и приниматься снова, если это необходимо.

Что общего между mutt, mplayer и gzip помимо того, что это качественные проекты с открытым кодом? В качестве подсказки даю наводящий вопрос: вы можете точно назвать месяц выхода очередной версии Debian Linux, до официального объявления на вебсайте?

Все эти программы имеют одну особенность — относительно длинный и непредсказуемый цикл разработки и релиза. Между тем все более популярным становится предсказуемый и относительно короткий цикл релиза, строго по графику. Какая стратегия разработки более выигрышная и каковы условия добиться перехода на оптимальную стратегию? Об этом мы поговорим в данной статье.

В связи с усложнением процессов разработки, а также растущим интересом к облачным технологиям, где старая добрая монолитная система уже не может ответить на все нужды продукта, многие разработчики столкнулись с тем, что от них требуется намного больше, чем знать определенный язык или паттерн программирования. Их сфера деятельности медленно сдвигается в нишу, которая требует знания не только программирования, но и IT, разбираться в операционных системах, облачных сервисах, их особенностях и так далее… Проекты уже не программируют… Их ПРОЕКТИРУЮТ, и эти новшества требуют иного подхода, а также требуют иной организации разработки проекта.

Дурацкая задача – когда ожидаемая от реализации польза не оправдывает количества необходимых ресурсов, но Заказчик настаивает на необходимости её выполнения.

• управлении потоком задач на разработку,
  Как избавится от «дурацких» задач?
• управлении расходами на разработку,
  Как определить и выбрать самые выгодные задачи?
• распределении ограниченных ресурсов.
  Как сделать так, чтобы все Заказчики были довольны, а количество ресурсов при этом осталось тем же?

Как бы вы руководили разработкой крупнейшего проекта с открытыми исходниками, в котором порядка 15 тыс. разработчиков и 222 компании вносят более 12 тыс. изменений между релизами или 7 / 8 правок каждый час? Чем пользуются создатель кернела Линус Торвальдс, мейнтейнер стабильной ветки Грег Кроа-Хартман (GKH) и другие товарищи, чтобы успешно координировать работу проекта и обеспечивать своевременный выход каждой новой версии?

Этим чудо-инструментом является текстовый клиент электронной почты: Mutt у GKH и Alpine у Линуса Торвальдса. Третий по рангу разработчик ядра Эндрю Мортон, также вовсю использует электронку для управления mm веткой.

With the wide variety of more “modern” development tools such as github, gerrit, and other methods of software development, why is the Linux kernel team still stuck in the 1990’s with ancient requirements of plain text email in order to get patches accepted? This talk will discuss just how the kernel development process works, why we rely on these “ancient” tools, and how they still work so much better than anything else.^[1]