1. Краткое введение в Agile и Scrum
2. Как и какие риски снижает применение Scrum?
3. Как планировать риски на итерацию и как это объяснить заказчику?
a. Стоит ли говорить заказчику о том, что вы планируете риски, и, если стоит, то как?
b. Что делать с «мега срочными» задачами от заказчика в середине итерации и как аргументированно сказать «нет»?
4. Что делать, что объём незапланированных задач больше объема запланированных?
5. Способы снижения рисков:
a. Снижение вероятности рисков
b. Снижение влияния на производительность команды
6. Управление рисками в самоорганизуемой команде
4. Манифест Agile
Люди и взаимодействие
важнее процессов и инструментов
Работающий продукт
важнее исчерпывающей документации
Сотрудничество с заказчиком
важнее согласования условий контракта
Готовность к изменениям
важнее следования первоначальному плану
То есть, не отрицая важности того, что справа,
мы всё таки больше ценим то, что слева.
http://agilemanifesto.org/iso/ru/
7. Зачем придумали Agile?
● Снизить риск разночтения требований
● Снизить риск изменения требований, когда часть из них уже
реализована
● Сделать то что нужно заказчику,
а не то что написано в ТЗ
● Дать заказчику, как можно раньше бизнес результат
● Как можно раньше узнать обо всех
возможных проблемах
9. Риски в рамках одной итерации
● Технические
● Незапланированные backlog item’ы
10. Незапланированные backlog item’ы:
Как «отшить» заказчика
1. Заказчик завышает приоритет незапланированного item’а
2. Готов ли он пожертвовать запланированным функционалом?
3. Нужны чётко прописанные критерии приоритезации
4. Если действительно «Вся система валится и пользователь не может
выполнить даже простых операций», то бросаем всё и фиксим
5. Если не blocker, но всё же критично,
ставим в начало следующего спринта
6. Иначе – откладываем до этапа
стабилизации, или в конец следующего
спринта
11. Пример
QA
- Мы нашли очень большую ошибку! Нужно срочно исправить!
- Правда? А как давно она существует?
- Она тут уже около года, но нашли мы её только что.
- Хм, она тут уже около года и вы не можете подождать ещё две
недели?
12. Shit happens. Что же всё таки делать?
1. Планируем часть спринта на
незапланированные задачи
2. Говорим заказчику об этом
3. Согласуем с заказчиком стек задач
про запас, на случай, если риски не сработают
4. Размер буфера определяем статистически из опыта работы с данной
командой, данным заказчиком, данным проектом.
5. Задачи из стека выбираются только после того, как реализован
запланированный функционал
6. Буфер используется только для рисков реализации функционала
текущего спринта и для исправления blocker’ов
13. Внеплановые item’ы? Да их ТЫСЯЧИ!
● Много багов в свежем коде:
○ Ретроспектива
○ Code review
○ Парное программирование
○ TDD
○ И т.д.
● Много задач поддержки (доработки и баги)
○ Уменьшение спринта
○ Или канбан
14. Работа с рисками в самоорганизуемой команде
● Идентификация рисков производится всей командой при
планировании спринта
● Каждый пишет те риски, которые он считает возможными в
предстоящем спринте
● Все риски представляются команде
● Голосование за наиболее опасные и наиболее вероятные риски
● Риски связываются с backlog item'aми, на которые могут оказать
влияние
● Формируется план действий для снижения вероятности возникновения
рисков
● Постоянный мониторинг рисков, например, на ежедневных скрам-
митингах
15. Использованные источники
● Что 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)