Технические требования в Agile: быть или не быть

Аналитика рынка

Технические требования в Agile: быть или не быть

2 марта, 2020

В 2014 году Институт Проектного Менеджмента (PMI) изучил вопрос, как нечеткие или недостаточно хорошо прописанные требования на входе проекта влияют на весь проект в целом. Выяснились, в общем, неудивительные детали – в 51% случаев заказчик потратил больше денег, чем изначально закладывалось, а 47% проектов не были выполнены в полном объеме. Казалось бы, здравый смысл подсказывает, что в интересах самого заказчика проработать (или заказать подрядчику) требования к продукту в качестве предпроектной деятельности и, тем самым, снизить риски срыва сроков релиза, превышения бюджета, снижения качества финального решения.

Как прекрасно знают руководители проектов, бывают ситуации, когда заказчик в силу разных причин не может сам написать технические требования к продукту, и разработчикам приходится иметь дело с довольно сложной ситуацией. Чаще всего причина в «высокоуровневости» требований – по факту заказчику ближе и важнее бизнес-требования (запрос на разработку поступает от заказчика или отдела заказчика, для которого разработка/поддержка ПО не является профильным занятием), и у него недостаточно специалистов или навыков персонала для перевода этих требований в технические. Иногда такая ситуация складывается, когда заказчик работает с устаревшим или унаследованным в результате поглощения продуктом с утраченной (или недостоверной, неполной, неподдерживаемой) документацией и отсутствующими экспертами. Но встречается еще одна категория заказчиков, которые предполагают, что при использовании Agile технические требования неважны. Превратно понятая фраза из Манифеста: “Working software over comprehensive documentation” (работающий продукт важнее исчерпывающей документации) заставляет их сделать вид, что технические требования и документация вообще не важны, все равно все будет меняться. С ней-то я и хотел поспорить в этой статье. Но, прежде всего….

Как это делается в стандартных ситуациях?

Предположим, наша ситуация укладывается в первые два случая: заказчик понимает, что технические требования нужны, но не имеет возможности их написать самостоятельно. Написание технических требований – естественный шаг в проектном плане. Для начала выделенный специалист команды (аналитик) должен ознакомиться с существующей документацией, поговорить с экспертами – носителями знаний о продукте, тщательно изучить бизнес-требования, посмотреть на архитектуру продукта и уже после этого, используя существующие стандарты, методологии и своды знаний (такие как ГОСТ 34, ГОСТ 19, IEEE STD 830-1998, ISO/IEC/ IEEE 29148-2011, RUP, SWEBOK, BABOK и другие), по которым пишутся технические требования или SRS (Software or System Requirements Specification), написать технические требования, понятные разработчикам.

Эти требования фиксируются с заказчиком, и дальше проект идет по запланированному расписанию, независимо от того, выполняется он по Agile или Waterfall методологии.

А как в Agile проекте?

Бизнес-департаментам не всегда понятно, зачем нужно тратить время на составление каких-то документов и требований. Им нужен продукт, и именно за продукт они готовы платить. Поэтому, узнав про Agile, бизнес-заказчик и решает, что раз «работающий продукт» важнее «исчерпывающей документации», то она и вовсе не нужна – ни исчерпывающая, ни какая другая. Это наиболее распространенный и неверный подход. Перечислю основные заблуждения (и напишу, почему они неверны):

1. Для Agile проекта не требуется управление требованиями. На самом деле оно встроено в саму ткань Agile. На Agile проектах в качестве требований выступает беклог продукта: приоритизация и переприоритизация пользовательских историй, планирование итераций и релизов, ежедневные стендапы, burn-down и burn-up charts, добавление критериев приемки в пользовательские истории, демо и ретроспективы – это все, по сути, не что иное, как контроль требований от старта проекта до его окончания.

2. Внесение изменений в продукт на Agile проектах не контролируется. В реальности, конечно, изменения вносятся далеко не бесконтрольно. Запросы на изменения описываются как пользовательские истории, помещаются в беклог, им присваиваются приоритеты по согласованию с владельцем продукта.

3. Если беклог постоянно изменяется, незачем фиксировать требования жестко. Да, в Agile признается, что беклог продукта меняется в течение всего проекта (разработчиками или владельцами продукта). Главное, что предлагает Agile методология, – гибкость: не есть огромного слона проекта целиком, а разрезать его на более мелкие куски (спринты). Но если мы хотим получить удачный качественный продукт, остаться в рамках бюджета и расписания, требования для каждого спринта должны быть четко прописаны и согласованы до начала работы над ними, иначе объем требований будет неконтролируемо расти.

Шесть советов заказчику

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

  • Для начала поймите, что работа с требованиями – это часть проекта, а не прихоть подрядчика. Согласуйте этот этап с подрядчиком и заложите соответствующие расходы в бюджет. Помните, что в противном случае на кону большие риски получить продукт не в срок, дороже и не совсем с тем функционалом, производительностью и надежностью, на которую вы рассчитывали. Скупой платит дважды – это тот самый случай.
  • Выделите часть времени на работу аналитика. Он задаст правильные вопросы, которые определят высокоуровневый профиль продукта (классические WWWH – Why? What? Who? How?).
  • Проработайте карту коммуникаций – кто, как и когда получает информацию о требованиях, изменениях, прогрессе, проблемах. Лучше всего, если еще «на берегу» у вас будет составлен план коммуникаций на все более-менее стандартные ситуации и выбраны удобные каналы общения.
  • Решите, кто и на каких условиях вносит изменения в беклог и как приоритизируются эти изменения.
  • С самого начала выделите у себя владельца продукта – точку доступа для руководителя проекта и инженеров. Заложите его время на общение с командой и отслеживание прогресса. Более 37% проектов (согласно PMI) проваливаются из-за недостаточной вовлеченности владельца продукта в процесс.
  • Заложите время в начале проекта на “Спринт 0”, о котором я писал в предыдущей статье. В эти две-три недели пишутся HLD и HLA, происходит наладка CI/CD, планирование и оценка основных задач и, самое главное, работа с требованиями.

Михаил Чкалов, Менеджер проектов, Аурига

Похожие новости

Новости

Auriga вошла в список лучших IoT-компаний по версии Clutch

Auriga вошла в список лучших IoT-компаний по версии Clutch

Auriga, одна из ведущих компаний-разработчиков программного обеспечения на заказ, вошла в список лучших поставщиков IoT-решений по версии Clutch, независимой рейтинговой платформы для B2B-рынка. Рейтинг составлен

Auriga вошла в Топ-100 компаний-разработчиков ПО

Auriga была включена в рейтинг ста лучших в мире компаний-разработчиков программного обеспечения на заказ, опубликованный на бизнес-платформе The Manifest. Цель рейтинга – помочь заказчикам найти надежных партнеров...

Заказчик оценил проактивный подход Auriga в разработке ПО

Успех разработки программного обеспечения на заказ зависит от целого ряда факторов, включая не только техническую экспертизу и глубокое понимание бизнес-области, но также корпоративную культуру, коммуникативные...

Признанный лидер услуг по разработке ПО:
управление командами и проектами;
разработка новых продуктов, сопровождение, тестирование