Работа с рисками в Scrum проектах

Денис Тучин

Руководитель команды разработчиков,

i-Sys

Что такое Agile?

Манифест AgileЛюди и взаимодействие

важнее процессов и инструментов

Работающий продукт

важнее исчерпывающей документации

Сотрудничество с заказчиком

важнее согласования условий контракта

Готовность к изменениям

важнее следования первоначальному плану

То есть, не отрицая важности того, что справа,

мы всё таки больше ценим то, что слева.

http://agilemanifesto.org/iso/ru/

Scrum

Backlog items

Зачем придумали Agile?● Снизить риск разночтения требований

● Снизить риск изменения требований, когда часть из них уже

реализована

● Сделать то что нужно заказчику,

а не то что написано в ТЗ

● Дать заказчику, как можно раньше бизнес результат

● Как можно раньше узнать обо всех

возможных проблемах

http://www.versionone.com/Agile101/Agile_Benefits.asp

● Технические

Риски в рамках одной итерации

● Незапланированные backlog item’ы

Незапланированные backlog item’ы:Как «отшить» заказчика

1. Заказчик завышает приоритет незапланированного item’а

2. Готов ли он пожертвовать запланированным функционалом?

3. Нужны чётко прописанные критерии приоритезации

4. Если действительно «Вся система валится и пользователь не может

выполнить даже простых операций», то бросаем всё и фиксим

5. Если не blocker, но всё же критично,

ставим в начало следующего спринта

6. Иначе – откладываем до этапа

стабилизации, или в конец следующего

спринта

Пример

- Мы нашли очень большую ошибку! Нужно срочно исправить!

- Правда? А как давно она существует?

- Она тут уже около года, но нашли мы её только что.

- Хм, она тут уже около года и вы не можете подождать ещё две

недели?

QA

Shit happens. Что же всё таки делать?1. Планируем часть спринта на

незапланированные задачи

2. Говорим заказчику об этом

3. Согласуем с заказчиком стек задач

про запас, на случай, если риски не сработают

4. Размер буфера определяем статистически из опыта работы с данной

командой, данным заказчиком, данным проектом.

5. Задачи из стека выбираются только после того, как реализован

запланированный функционал

6. Буфер используется только для рисков реализации функционала

текущего спринта и для исправления blocker’ов

Внеплановые item’ы? Да их ТЫСЯЧИ!● Много багов в свежем коде:

○ Ретроспектива

○ Code review

○ Парное программирование

○ TDD

○ И т.д.

● Много задач поддержки (доработки и баги)

○ Уменьшение спринта

○ Или канбан

Работа с рисками в самоорганизуемой команде● Идентификация рисков производится всей командой при

планировании спринта

● Каждый пишет те риски, которые он считает возможными в

предстоящем спринте

● Все риски представляются команде

● Голосование за наиболее опасные и наиболее вероятные риски

● Риски связываются с backlog item'aми, на которые могут оказать

влияние

● Формируется план действий для снижения вероятности возникновения

рисков

● Постоянный мониторинг рисков, например, на ежедневных скрам-

митингах

● Что Agile команде делать с «авралами»

(http://tim.com.ua/2011/03/dealing-with-emergencies-in-agile-teams/)

● Dealing with emergencies in Agile teams

(http://blog.xebia.com/2011/02/dealing-with-emergencies-in-agile-teams/)

● Управление рисками в разных методологиях

(http://www.slideshare.net/ittuning/pm-zone-riskmethodologies?from=ss_embed)

● Риски в Agile проектах (http://lobasev.ru/2008/05/agile.html)

● Agile-манифест разработки программного обеспечения

(http://agilemanifesto.org/iso/ru/)

● Benefits of Agile Development

(http://www.versionone.com/Agile101/Agile_Benefits.asp)

Использованные источники

Денис Тучин

E-mail: info@dream-project.tu

Skype: Denis.Tuchin

Телефон: +7-927-264-77-53

ICQ: 305867845

Визитка

Ещё про Scrum

Рассылка «100 ошибок применения Scrum»

на dream-project.ru