Пятая встреча. Тезисы.

Встреча была посвящена работе с рисками. В рамках Встречи Денис Тучин сделал сообщение «Работа с рисками в проектах SCRUM». Тема сама по себе провокационная! Ведь SCRUM, как agile технология, был первоначально придуман чтобы снизить вероятность возникновения многих проектных рисков! Но, судя по всему, не до конца…

Презентация Дениса доступна по ссылке: http://dream-project.ru/wp-content/uploads/2011/02/scrum-risks.ppt

Кстати, оченно интересный у Дениса блог.



После доклада Дениса состоялось обсуждение.

Участвовали: Александр Калугин (Mercury Development, pmarcor.com), Всеволод Денисенко (Mercury Development), Денис Журавлев (Indigobyte),  Игорь Михеенков (Mercury Development), Денис Тучин.

Тезисы обсуждения:

1. Наиболее интересным в работе с рисками являются:
-- типовые практики работы с рисками, а именно практики предупреждения рисков, так как выявление рисков – в принципе достаточно понятный процесс.
-- типология рисков в различных типах проектов – так как в ежедневной практике, глаз замыливается и не всегда удается «распознать» новый риск.
-- эффективные формальные методы/процессы работы с рисками – так как всё происходит по наитию

2. Agile методология – сама появилась как ответ на риски и как средство борьбы с ними. Мы готовы меняться и подстраиваться под возникающие изменения. А раз так, нужны ли средства борьбы с рисками в Agile? – да, нужны. Мало того, есть специфические средства и методы. Причем не только Agile – но и в scrum в частности.

3. Технические риски – основным средством работы в рамках SCRUM является предупреждение. Дополнительно – в SPRINT закладывается буфер на риски (порядка 20%). Который может потом использоваться на список опциональных задач.

Возникает практический вопрос, как в рамках SCRUM понять что риск сработал? Ведь сработавший риск это не баг… -- Ответ – смотреть по прогрессу задачи где-то в середине ее выполнения и принимать меры. Если задача маленькая – меньше чем расстояние между SCRUM митингами – то отловить срабатывание такого риска на уровне процесса –невозможно.

4. В рамках самоорганизующейся команды как избежать «детского сада» -- когда сотрудник добивается выделения себе части рискового буфера мотивируя это сработавшим тех риском, хотя истинная причина проблемы – его личная неэффективная работа? Ответ: Всё же на практике получается, что решение о выделении части этого бюджета должен принимать PO/Scrum Master/Dev-Lead, так как только они могут блокировать такие нечистоплотные попытки. Всё-таки люди, важнее чем процесс! :)

5. Часто практика итеративной разработки скатывается к практике затягивания поясов перед релизами и некоторого расслабления после релиза. Но это далеко не SCRUM. И такая схема не работает в заказной разработке. Складывается чаще всего ситуация, когда фаза отдыха пропускается… Короткий спринт – это один из эффективных методов пропуска такой фазы отдыха. Поэтому при SCRUM – необходимо помнить о тезисе не более чем 40-часовой рабочей недели.

6. О BackLog и архитектуре: сначала фичи оцениваются, а потом тасуются. Однако фичи – не независимые, и при попытке их тасовать – меняется их взаимовлияние и оценка каждой из фич (Пример – как быть что при тасовке было выкинуто фича-ядро, сервис который необходим для реализации всех основных. При этом оценки – на все оставшиеся фичи автоматически возрастают). Такой процесс переоценки очень затратен по времени. В результате – между спринтами возникает пауза на планирование следующей итерации. Ответ: команды практикующие скрам, в который явно вовлечен PO со стороны заказчика, с 2-х недельным спринтом – имеют в возможность завершить фазу планирования за 2-5 часов между спринтами. В offshore outsourcing – такое не работает.

7. Как избежать риска реворка в SCRUM/Agile. Ведь мы каждый раз должны делать конкретный функционал в рамках спринта, но если известен бэклог с оставшимися фичами, как быть с архитектурированием и разработкой центрального функционала, разработать который сначала – дешевле, при условии что бэклог сильно не изменяется. Ответ: мы делаем KISS – то есть разрабатываем по фичам. Либо не заглядывать вперед более чем на 1-2 спринта.

Либо попытаться обсудить этот вопрос с PO/заказчиком.

8. Получается, учитывая все ограничения SCRUM – в качестве PO должен выступать человек который очень хорошо понимает нутро процесса разработки.

9. Риски качества: если после каждого спринта идет публичный релиз продукта, а в рамках спринта фиксятся только блокеры, и баги-мажоры откладываются на более поздние этапы – то может возникнуть очень неприятная ситуация. Блокеров-то нет, но заказчику продукт не нравится из-за других багов. В итоге выпуск на рынок получается провальным по техническим проблемам качества… Как быть? Ответ: фича считается реализованной, если ей можно пользоваться.
Для этого нужен список критериев приемки, TDD и т. д. Если тест пройден все остальные баги – добавляются в backlog как отдельные пункты. В заказной разработке – необходимо к таким багам заказчика/Product Owner-а готовить.

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

11. Интересными особенностями SCRUM-а обладает разработка функционала, который носит сугубо служебный характер, или имеет характер автоматической обработки каких-либо данных. В такой ситуации приемка фич, сдача спринта носит очень специфический характер.

12. Если SCRUM внутри – а во вне заказчик думает что Fixed Price – То в результате при сдаче скорее всего будут проблемы.

13. SCRUM надо адаптировать под проект, но не принимать его в чистом виде.

14. SCRUM нельзя насадить сверху. SCRUM должен вырасти снизу (лучшее из пройденного).