Доклад Андрея Павлова на конференции Analyst Days-6 www.analystdays.com

1. Очередность требований:
от хаоса к FIFO
Павлов Андрей
T-Systems RUS, Санкт-Петербург
Надо бы снова
изменить порядок
требований.
Поработайте в
первую очередь
вот над этим!

2. About me
• Ex-Developer
• В IT более 10 лет
• 5 из них в тестировании
• ~2 в аналитике
• Test Team Lead @ T-Systems RUS
linkedin.com/in/qapavlov
ru.apavlov@gmail.com

3. Ловушка приоритетов требований

4. Зачем нужна очередность при работе с требованиями?

5. Зачем нужна очередность при работе с требованиями?
• Разработка наиболее важных требований в первую очередь;
• Распределение усилий, направленных на разработку

6. Почему просто не попросить заказчика дать приоритеты?

7. Почему просто не попросить заказчика дать приоритеты?
1. У заказчика появляется необходимость в решении некоторой реальной
проблемы. Или идея, подразумевающая некоторую конкретную выгоду.
2. Он привыкает к своей идее, и со временем она начинает обрастать всё новыми
и новыми уточнениями и улучшениями.
3. Идея обрастает совсем экстремальными и инновационными требованиями,
которые до сих пор никем не были реализованы.
Если принять известное правило “80-20”, то из вышесказанного можно сделать два вывода:
• 80% выгоды находятся в 20% начальных требований.
• 80% рисков содержатся в 20% поздних требований. Но эти требования, по сути, не решают
изначальной задачи, а, в основном, “украшают” её.

8. Ловушка приоритетов требований

9. Ловушка приоритетов требований
Главной проблемой была неспособность команды обеспечить поставку готовой
спецификации к необходимой дате.

10. Ловушка приоритетов требований
Все началось, когда один из членов команды предложил разработать карту потока
работы с требованиями, чтобы определить источник проблемы.

11. Ловушка приоритетов требований
Один из разработчиков спросил: “Что, если мы начнем работать с требованиями в
модели "first-in, first-out"?

12. Готовим жесткую FIFO очередь

13. Готовим жесткую FIFO очередь
Команда выбрала свободное место в графике релизов, чтобы запустить новый
процесс.

14. Как это делали мы?
Команда согласилась, что, возможность реализовать запланированную дату
выпуска релиза была основной целью нового процесса. Мы также решили, что
кумулятивная блок-схема (CFD) предоставит всю необходимую информацию для
понимания, насколько нам помогает новый подход.

15. CFD (Cumulative Flow Diagram)
Date To be worked
In Progress
(FIFO)
Release
Ready
Released to
QA
In Progress
(Escalation) Blocked In Production
8/19/2013 50 11 2 14 1 10 19
8/20/2013 47 9 2 16 1 11 22
8/23/2014 47 7 5 24 2 13 23
8/24/2014 43 7 5 23 1 13 30
8/25/2014 50 9 11 15 2 13 33
8/26/2015 50 9 13 16 2 16 38
8/27/2015 52 7 14 18 2 15 38

16. CFD (Cumulative Flow Diagram)
Используя эту панель, мы смогли предоставить точную дату выпуска спецификации
в любое время.
Когда для определенных фич заказчик видел ожидаемую дату через три месяца, он
был немного расстроен =)

17. Готовим жесткую FIFO очередь
К этому моменту мы уже поняли, что решаем не только проблему разработки
требований, мы оптимизируем весь процесс разработки ПО, включая работу
разработчиков, конфигураторов, тестировщиков и менеджеров.

18. Полезные советы

19. Полезные советы
• Создайте “безопасную среду”, запланировав план отката

20. Полезные советы
• Создайте “безопасную среду”, запланировав план отката
• Создайте очередь эскалации

21. Полезные советы
• Создайте “безопасную среду”, запланировав план отката
• Создайте очередь эскалации
• Работайте с очередью эскалации как с первоочередной

22. Полезные советы
• Создайте “безопасную среду”, запланировав план отката
• Создайте очередь эскалации
• Работайте с очередью эскалации как с первоочередной
• Рассмотрите использование class of service (CoS)

23. Полезные советы
• Создайте “безопасную среду”, запланировав план отката
• Создайте очередь эскалации
• Работайте с очередью эскалации как с первоочередной
• Рассмотрите использование class of service (CoS)
• Обновляйте информацию о времени разработки требований и
сделайте ее общедоступной

24. Полезные советы
• Создайте “безопасную среду”, запланировав план отката
• Создайте очередь эскалации
• Работайте с очередью эскалации как с первоочередной
• Рассмотрите использование class of service (CoS)
• Обновляйте информацию о времени разработки требований и
сделайте ее общедоступной
• Продолжайте улучшать процесс

25. Вопросы
linkedin.com/in/qapavlov
ru.apavlov@gmail.com