Методология

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее