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

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

С другой стороны, лучше всего с незапланированной работой справляется Kanban. Команда непрерывно старается улучшить свой процесс, повышая свою производительность. Но Kanban ничего не говорит о том, как формулировать требования, как проводить демонстрацию продукта пользователям, обмениваться знаниями и проблемами внутри команды. А без этого команда не сможет создавать продукт.

Объединив лучшее из Scrum и Kanban вы получите процесс, идеально подходящий для продукта на стадии развития - Scrumban.

  • Ваша команда не обязательно должна быть кросс-функциональной, некоторые стадии процесса могут предшествовать разработке продукта. Например, если ваш заказчик не готов оперативно и качественно исполнять роль владельца продукта, то вам пригодится дополнительная стадия "Уточнение историй", на которой будет формироваться качественный бэклог продукта, создаваться необходимые макеты UI и т.п.
  • Поскольку объем незапланированной работы заранее неизвестен, то команда не согласует с заказчиком жесткий срок завершения спринта. По объективным причинам срок завершения, то есть срок поставки очередного инкремента продукта, может быть перенесен.
  • Ограничение незавершенной работы (Work In Progress Limit) позволит увидеть реальные возможности команды, исключить неоправданные ожидания, обнаружить узкие места процесса разработки.
  • Вытягивающая модель работы (в отличие от планирования историй в Scrum) позволяет участникам проекта лучше балансировать нагрузку в условиях наличия незапланированной работы.
  • Основной метрикой производительности команды становится "Среднее время цикла", причем для разных типов задач оно будет отличаться. Например, для срочных запросов - одно, а для доработок - другое.

В процессе реализации историй документируйте важные технические решения в форме фотографий, скриншотов, UML-диаграмм, формул, алгоритмов или в произвольной текстовой форме. Это позволит любому члену команды освежить в памяти детали, а новым членам команды быстрее войти в курс дела. Разрабатывайте тестовую документацию по ходу реализации историй. Затем она будет использована для ручного тестирования, например, для смоук, регрессионного или исследовательского тестирования перед передачей продукта заказчику.

Остальные полезные практики, такие как ежедневные встречи, сессии планирования, ретроспективы и демонстрация продукта, применяются также как вы это делали в проекте на основе Scrum.


Еще интересные статьи на эту тему: