Обратная связь и цикл «обзор-контроль-адаптация»

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

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

Особенно трудно бывает, когда традиционный проект выполняется по принципу «вначале детальные требования» (big requirements up front, BRUF). Представьте себе все эти многочисленные этапы, через которые должен пройти проект, прежде чем попасть к разработчику. В типичном водопадном проекте разработка BRUF выглядит примерно так.

• Руководитель проекта должен определить объем работы, чаще всего исходя из бизнес-требований или документированных целей.

• Руководитель проекта должен «подписаться» под объемом работ.

• Бизнес-аналитик должен изучить цели и объем работ, а затем выяснить у пользователей и других стейкхолдеров, как они планируют использовать создаваемый продукт и какая проблема решается.

• Бизнес-аналитик продумывает варианты использования, функциональные требования и т. д.

• Программист принимает требования и делает оценки работ.

• Менеджер проекта принимает требования и оценки, строит график и согласовывает его со стейкхолдерами и руководством.

Эта длинная цепь событий должна произойти, прежде чем начнется разработка. Неудивительно, что такая «игра в испорченный телефон» мешает разработчикам получить правильную информацию.

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

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

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме Обратная связь и цикл «обзор-контроль-адаптация»:

  1. Обратная связь
  2. Обратная связь
  3. 360-градусная обратная связь
  4. Обратная связь с потребителем
  5. Обратная связь
  6. ОБРАТНАЯ СВЯЗЬ «ПО СТАРИНКЕ»
  7. 7. Ищите обратную связь
  8. Многоканальная обратная связь и ее роль в оценке результатов труда
  9. Обратная связь и отчеты о трендах
  10. Система внутреннего контроля (свк) и бухгалтерского учета и ее связь с аудиторским риском
  11. Понятие контроля. Предварительный, текущий и последующий контроль. Аудит как форма контроля
  12. Понятие логистического цикла. Полный логистический цикл — цикл выполнения заказа. Составляющие полного логистического цикла товара