Методология

Главными задачами, стоявшими передо мной при модернизации методологии разработки, были:

обеспечение эффективности по времени и ресурсам как всего процесса разработки, так и выпускаемого ПО;
обеспечение кроссплатформенности решений;
улучшение качества сопровождения продуктов (обеспечение минимальной стоимости сопровождения).

Таким образом, по каждому из продуктов компании у меня появились следующие задачи:

хранение всего кода продукта в системе контроля версий (обычно, код хранимых процедур там не хранился);
документирование продукта;
модернизация платформы (повышение версий используемых библиотек и инструментов. Например, переход с JavaScript на TypeScript);
модернизация механизма развёртывания (поддержка автоматического обновления);
автоматическое обновление сопутствующих БД (поддержка версий БД и миграций);
обеспечение модульной архитектуры, стандартизация и документация API модулей, рефакторинг, удаление неактуального кода;
написание юнит-тестов для модулей;
внедрение Code Review;
минимизация числа сервисов (было такое, что одна и та же функциональность была разнесена по ряду отдельных сервисов);
оптимизация скорости работы и потребления ресурсов.

В итоге стоимость сопровождения проекта должна свестись к минимальному значению. Можно использовать соответствующую метрику и подсчитывать средние затраты в месяц на проект.

Суммарный объём работ вышел большой, и этим можно заниматься в течение нескольких лет (думаю, каждый следующий проект будет модернизироваться быстрее предыдущего).

Итеративная модель разработки

Итеративная модель разработки предполагает вести разработку короткими циклами - итерациями, спринтами. Часто спринты считают исключительно компонентом Agile-подхода, но это не так: никто не мешает использовать вам итерации и в Waterfall-подходе. Agile отличается от Waterfall изменчивостью конечной цели, а не наличием итераций.

Основное правило применения итераций следующее: в конце каждой итерации должен иметься работоспособный продукт. Если следовать описанным правилам ветвления, то продукт будет работоспособен непрерывно во времени, и это требование будет автоматически выполнено.

Итерации обычно продолжаются 1, 2 или 4 недели. На мой взгляд, оптимальная продолжительность итерации - 2 недели.

Преимущество использования итераций - это удобство краткосрочного планирования.

В основе планирования лежит оценка трудоёмкости задач, в Story Point'ах или во времени. Имея на руках задачи с заданными трудоёмкостями, можно примерно оценить, какой объём задач команда сможет выполнить в отведённое время. Разумеется, при планировании следует закладывать резерв времени на внештатные ситуации.

Общий алгоритм использования итераций таков:

менеджер проекта выставляет приоритет всем поступающим в систему багтрекинга задачам;
перед началом недели (обычно в пятницу) руководитель разработки формирует план задач на итерацию. Процесс этот сам по себе итеративный и состоит из следующих шагов:

руководитель набирает в будущую итерацию задачи из общего пула задач согласно их приоритету (при необходимости добавляет также и задачи на рефакторинг);
совместно с исполнителями производится оценка выбранных задач (для этого необходимо тесное взаимодействие с исполнителями этих задач);
суммарная трудоёмкость по времени для каждого исполнителя должна составить 80% от общей продолжительности итерации (для 80 часов в двух рабочих неделях - 64 часа). Остальное время резервируется на Code Review и внеплановые ситуации. В зависимости от набранной трудоёмкости в итерацию добавляются или из неё исключаются задачи;
предыдущие два шага повторяются до тех пор, пока не будут достигнуты целевые показатели трудоёмкости.

при начале итерации программист занимается только задачами из этой итерации. Менеджер проекта не может назначить на программиста задачи не из этой итерации. Если же возникла действительно острая необходимости выполнить какую-то работу, менеджер советуется с руководителем разработки, и они либо подключают на проект дополнительного программиста, либо исключают одну из имеющихся в итерации задач, меняя её на новую. Все подобные ситуации являются внештатными и должны подробно анализироваться, чтобы не возникало их повторения впоследствии;
если программист справился со всеми задачами из итерации досрочно, он переход к работе над задачами в "классическом" режиме - в порядке убывания их приоритета;
если же программист не уложился в срок - задачи перемещаются на следующую итерацию. Проводим анализ проблемы, делаем выводы.

В итоге мы защищаем команду от внепланового прессинга со стороны менеджера проектов. Команда может самостоятельно распланировать порядок выполнения задач внутри итерации и быть более самостоятельной в принятии решений по разработке и делегировании ответственности. Процесс разработки становится более упорядоченным, прогнозируемым и управляемым.

По своей сути, перед началом итерации команда берёт на себя обязательства выполнить определённый объём работ за определённый период времени ("пятилетку за три года"). В конце итерации команда может продемонстрировать результаты своей работы менеджеру проекта и другим заинтересованным лицам. Допускается устраивать отчётные чаепития.

Встречаются также исследовательские задачи, трудоёмкость которых заранее не удаётся определить. Крайне желательно попытаться разбить такие задачи на набор измеримых подзадач и планировать уже их выполнение. Если же задача никак не разбивается (например, исследование какой-то невоспроизводимой ошибки), такая задача помечается особой меткой и выполняется вне итерационной модели.