Докладчик: Екатерина Шалапанова, деливери-менеджер финансовой практики DataArt, Петербург О чем пойдет речь: Что делать: Если ваш заказчик не подписывал Agile Manifesto и не читал Scrum Guide? Если в итерацию врываются сверхсрочные задачи? Если бизнес-процессы не позволяют регулярные релизы? Идеологи Scrum создавали процесс для небольших вовлеченных и нацеленных на результат команд. Что же делать, если вам приходится работать с корпорациями? Процесс приходится строить заново, беря все самое лучшее и подстраиваясь под нужды и возможности любимых клиентов. Я расскажу, какие подходы мы используем при создании процесса разработки, что, по моему опыту, важно, а чем можно пренебречь, ну, и обязательно о чем-нибудь еще.

1. Если не Scrum, то что?
IT Talk Odessa 2016
Ekaterina Shalapanova (eshalapanova@dataart.com)

2. 1. Вижу Цель
2. Верю в себя
3. Не замечаю препятствий
4. Писал код три дня и три ночи
Зачем вообще нужен «процесс»?
1. Чем больше команда, тем сложней коммуникации
2. Последовательность дает понимание и определенность
3. Намного проще спланировать и дать прогнозы
4. Проще получать необходимую информацию
2

3. Методология vs Процесс
3
Методология
Процесс

4. История Agile в двух словах
4

5. Scrum в одной картинке
5

6. • Agile-методология
• Potentially Shippable Product
• Management-oriented
• CMM Level 3 compatible
Почему Scrum стал процессом по умолчанию*?
*Согласно опросу проведенному автором доклада среди трех потенциальных клиентов и пяти коллег 6

7. Scrum в трех слайдах - роли
• Scrum Master
• Product Owner
• Development Team
• Все остальные
7

8. • Sprint
• Sprint Planning
• Sprint Review
• Sprint Retrospective
Scrum в трех слайдах - активности
8

9. • Product Backlog
• Sprint Backlog
• Potentially Shippable Product
Scrum в трех слайдах - артефакты
9

10. Зачем может понадобиться свой процесс?
Идеологи Scrum создавали процесс для небольших
вовлеченных и нацеленных на результат команд. Что же
делать, если вам приходится работать с корпорациями?
10

11. • Коллективная ответственность?
• А кто РО?
• Универсалы и
cross-functional team?
... да забыли про овраги. Роли
При заказной разработке для компаний 11

12. • Sprint Review
• Регулярные релизы
• Планирование и ретроспективы
... да забыли про овраги. Активности
При заказной разработке для компаний
12

13. ... да забыли про овраги. Артефакты
• Product Backlog
• Результат итерации (aka) Potential
shippable product
• Sprint backlog
При заказной разработке для компаний
13

14. Использовать Силу мозг…
И что же делать?
14

15. … И строить свой процесс
Придумываем,
как будем достигать
Формулируем цель.
На самом деле цели.
Периодически проверяем, что цели
не поменялись и выбранный
процесс ведет к ним.
Если что, корректируем
цели или способы
достижения
15

16. • Теория управления (да, то что было на 3-м курсе)
• SEMAT - Software Engineering Method and Theory
• TOS - Theory of Constraints
• Lean
Шаг в сторону и немного теории
• Individuals and interactions over process and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
Agile – способ мысли.
Концепции, которые помогают думать:
16

17. Обратная связь процесса разработки ПО
• Продукт
• Отчет
• Мнения людей
Теория управления
Шаг в сторону и немного теории
17

18. • Три area of concern и семь key factors(альфы) есть
у любого IT-проекта
• Каждая альфа проходит через несколько стадий в
течение жизни проекта
• Состояние проекта описывается через стадии
альф, проект рассматривается как network of
collaborating elements.
Software Engineering Method and Theory
Шаг в сторону и немного теории
18

19. SEMAT: предложенные статусы альф
Customer – для кого делаем Solution – что делаем Endeavour – кто и как делает
Шаг в сторону и немного теории
19

20. Alpha Abacus – то, ради чего SEMAT упомянут
Шаг в сторону и немного теории
20

21. Предположим, что у нас есть система, про которую мы знаем все, и везде
замеряем
ToS – Theory of constraints
Шаг в сторону и немного теории
• Определяем, на каком участке системы у нас есть
помехи.
• Придумываем, как помехи устранять.
• Подстраиваем остальные части системы так, чтобы
придумки стали осуществимы.
• И устраняем ограничения, поднимая
производительность системы
• Возвращаемся к шагу 1
21

22. Принципы
• Исключение потерь.
• Акцент на обучении.
• Предельно отсроченное принятие решений.
• Предельно быстрая доставка заказчику..
• Мотивация команды.
• Интегрирование.
• Целостное видение.
Lean – еще одна очень известная методология
Шаг в сторону и немного теории
22

23. • Какие внешние ограничения?
• Какие внутренние ограничения?
• Какие из альф куда будем толкать на данном этапе?
• Какие из практик известных нам метолологий могут нам пригодиться?
Иными словами, берём ли за основу Scrum или…
• Нет ли между ними противоречий?
К построению своего процесса
23

24. • Daily Stand-ups.
• Burndown.
• Retrospective.
• Definition of Done.
Что почти всегда остаётся
• Potentially shippable product, sprint review,
sprint planning, неприкосновенный sprint
backlog, «чистый» PO и много чего еще
часто приносится в жертву.
24

25. Цель - sign-off от заказчика
Requirements
Testing
Development
Handover
User
Acceptance
Sign-off
Внешняя среда
25

26. Цель - sign-off от заказчика
Requirements
Testing
Development
Handover
User
Acceptance
Sign-off
Внутренняя среда
26

27. Помним про Lean принципы. Каждый раз, когда вы пытаетесь
что-то предложить или внедрять, задаём простые вопросы:
• Чего мы хотим добиться данной практикой?
• Приведёт ли то, как мы это делаем, к желаемому
результату?
• Можно ли это оптимизировать (сохранить чьё-то время,
решить ещё какие-то проблемы с теми же затратами)
Все ещё советы по построению процесса
27

28. Пытаемся остаться разумно удобными
• требования к репортингу
• процедуры взаимодействия между командами
• максимальную прозрачность
• если заказчик «хочет странного»
И ещё советы по построению процесса
28

29. • Не полениться и записать то, до чего
договорились в документ
• Собрать всех заинтересованных, и рассказать что
в документе написано
• И главное, помнить, что этот документ не в камне
высечен
И последний совет
29

30. • Люди разные с обеих сторон
• Требования к надёжности системы могут быть
разными
• Внешняя среда тоже поменяется
Не слушайте ничьих советов, в том числе и этот
30

31. Thank you
31