Главными задачами, стоявшими передо мной при модернизации методологии разработки, были:
- обеспечение эффективности по времени и ресурсам как всего процесса разработки, так и выпускаемого ПО;
- обеспечение кроссплатформенности решений;
- улучшение качества сопровождения продуктов (обеспечение минимальной стоимости сопровождения).
Таким образом, по каждому из продуктов компании у меня появились следующие задачи:
- хранение всего кода продукта в системе контроля версий (обычно, код хранимых процедур там не хранился);
- документирование продукта;
- модернизация платформы (повышение версий используемых библиотек и инструментов. Например, переход с JavaScript на TypeScript);
- модернизация механизма развёртывания (поддержка автоматического обновления);
- автоматическое обновление сопутствующих БД (поддержка версий БД и миграций);
- обеспечение модульной архитектуры, стандартизация и документация API модулей, рефакторинг, удаление неактуального кода;
- написание юнит-тестов для модулей;
- внедрение Code Review;
- минимизация числа сервисов (было такое, что одна и та же функциональность была разнесена по ряду отдельных сервисов);
- оптимизация скорости работы и потребления ресурсов.
В итоге стоимость сопровождения проекта должна свестись к минимальному значению. Можно использовать соответствующую метрику и подсчитывать средние затраты в месяц на проект.
Суммарный объём работ вышел большой, и этим можно заниматься в течение нескольких лет (думаю, каждый следующий проект будет модернизироваться быстрее предыдущего).
Итеративная модель разработки
Итеративная модель разработки предполагает вести разработку короткими циклами - итерациями, спринтами. Часто спринты считают исключительно компонентом Agile-подхода, но это не так: никто не мешает использовать вам итерации и в Waterfall-подходе. Agile отличается от Waterfall изменчивостью конечной цели, а не наличием итераций.
Основное правило применения итераций следующее: в конце каждой итерации должен иметься работоспособный продукт. Если следовать описанным правилам ветвления, то продукт будет работоспособен непрерывно во времени, и это требование будет автоматически выполнено.
Итерации обычно продолжаются 1, 2 или 4 недели. На мой взгляд, оптимальная продолжительность итерации - 2 недели.
Преимущество использования итераций - это удобство краткосрочного планирования.
В основе планирования лежит оценка трудоёмкости задач, в Story Point'ах или во времени. Имея на руках задачи с заданными трудоёмкостями, можно примерно оценить, какой объём задач команда сможет выполнить в отведённое время. Разумеется, при планировании следует закладывать резерв времени на внештатные ситуации.
Общий алгоритм использования итераций таков:
- менеджер проекта выставляет приоритет всем поступающим в систему багтрекинга задачам;
- перед началом недели (обычно в пятницу) руководитель разработки формирует план задач на итерацию. Процесс этот сам по себе итеративный и состоит из следующих шагов:
- руководитель набирает в будущую итерацию задачи из общего пула задач согласно их приоритету (при необходимости добавляет также и задачи на рефакторинг);
- совместно с исполнителями производится оценка выбранных задач (для этого необходимо тесное взаимодействие с исполнителями этих задач);
- суммарная трудоёмкость по времени для каждого исполнителя должна составить 80% от общей продолжительности итерации (для 80 часов в двух рабочих неделях - 64 часа). Остальное время резервируется на Code Review и внеплановые ситуации. В зависимости от набранной трудоёмкости в итерацию добавляются или из неё исключаются задачи;
- предыдущие два шага повторяются до тех пор, пока не будут достигнуты целевые показатели трудоёмкости.
- при начале итерации программист занимается только задачами из этой итерации. Менеджер проекта не может назначить на программиста задачи не из этой итерации. Если же возникла действительно острая необходимости выполнить какую-то работу, менеджер советуется с руководителем разработки, и они либо подключают на проект дополнительного программиста, либо исключают одну из имеющихся в итерации задач, меняя её на новую. Все подобные ситуации являются внештатными и должны подробно анализироваться, чтобы не возникало их повторения впоследствии;
- если программист справился со всеми задачами из итерации досрочно, он переход к работе над задачами в "классическом" режиме - в порядке убывания их приоритета;
- если же программист не уложился в срок - задачи перемещаются на следующую итерацию. Проводим анализ проблемы, делаем выводы.
В итоге мы защищаем команду от внепланового прессинга со стороны менеджера проектов. Команда может самостоятельно распланировать порядок выполнения задач внутри итерации и быть более самостоятельной в принятии решений по разработке и делегировании ответственности. Процесс разработки становится более упорядоченным, прогнозируемым и управляемым.
По своей сути, перед началом итерации команда берёт на себя обязательства выполнить определённый объём работ за определённый период времени ("пятилетку за три года"). В конце итерации команда может продемонстрировать результаты своей работы менеджеру проекта и другим заинтересованным лицам. Допускается устраивать отчётные чаепития.
Встречаются также исследовательские задачи, трудоёмкость которых заранее не удаётся определить. Крайне желательно попытаться разбить такие задачи на набор измеримых подзадач и планировать уже их выполнение. Если же задача никак не разбивается (например, исследование какой-то невоспроизводимой ошибки), такая задача помечается особой меткой и выполняется вне итерационной модели.
Далее