2. • Никита Филиппов
– Agile Coach @ ScrumTrek
• Прошлый опыт работы
– Методолог, Product
Manager, Разработчик
– Product Manager
внутренних проектов
ScrumTrek
3. Оговорка #1
• C вашей точки зрения, я могу ошибаться
• С вашей точки зрения я могу быть –
Капитаном Очевидностью!
Это конференция
Разработчиков
для
разработчиков!
4. Оговорка #2
• Я основываюсь на практических
внедрениях который были сделаны мной.
или с моим участием в течении последних 5
лет
• В каждом внедрении с 90% вероятностью
возникают эти вопросы и совершаются
одни и те же ошибки
• Тем более это хороший способ для
провокаций
6. Agile как философия
• Люди и взаимодействия важнее чем процессы и
инструменты
• Работающий продукт важнее совершенной
документации
• Сотрудничество с заказчиком важнее
контрактных обязательств
• Реакция на изменения важнее
следования плану
www.agilemanifesto.org
8. Эволюция философии Agile
• Командная работа и ответственность важнее
людей и их взаимодействий
• Поставка ценности важнее рабочего продукта
• Развитие партнерства важнее взаимодействия
с заказчиком
• Предвосхищение изменений важнее реакции
на них
http://blog.xebia.com/2010/12/23/moreagile-manifesto/
10. Lean как принципы и философия
Цель: Создавать/ Поставлять Ценность потребителю,
как можно быстрее и качественнее
Поставляй как Оптимизируй в
Уважай людей
можно раньше целом
Принимай
решение, как Встраивай
Создавай знания
можно позже (но качество
вовремя)
Устраняй потери
11. Lean как набор инструментов
• Восприятие процесса, как непрерывного
потока
• Визуализация всего потока
• Ограничения WIP
• Pull против Push
• Кайзен
Это Канбан
доска!
12.
13. В моей душе…
Можно, но по
возможности
избегайте
DON’T!!!!
Mr. Agile Tolerance Miss Agile Nazi
14. Пример #1: Шизофрения
• Product Owner и ScrumMaster
один человек
• Конфликт интересов
– SM=Интересы команды: Хороший
процесс, здоровая рабочая
атмосфера
– PO=Интересы клиента: Больше
полезных фич, меньше сроки.
15. Пример #1: Шизофрения
• Product Owner и ScrumMaster
один человек
DON’T!!! Можно совмещать,
В результате всегда – если это ваш 10-ый
плохие требования и проект и вы были и
немотивированная SM и PO независимо
команда
разработчиков
По
возможности
избегайте!!!
16. Пример #2: Нестабильность
• Команда не стабильна: команду
раздергивают на другие проекты
• Команда не может накапливать
экспертизу
• Проблемы с ответственностью
• Невозможно планировать работы
• Состояние пассивного конфликта
17. Пример #2: Нестабильность
• Команда не стабильна: команду
раздергивают на другие проекты
Допустимо, но ядро
NEIN!!!
(50%) команды
Золотое правило Agile-
должно быть
разработки: В команды
стабильно.
загружаем проекты.
Людей не набираем по
новой на каждый
проект!
Запомни, чем
стабильнее
команда – тем она
производительнее!
18. Пример #3: Любовь на расстоянии
• Команда разделена по
локациям
• Недопонимание
• Более долгий цикл разработки
• Они и мы: «Ошибка на вашей
стороне»
Если вы на разных
этажах – это тоже
распределенная
разработка!
19. Пример #3: Любовь на расстоянии
• Команда разделена по локациям
Тем не менее 50%
всех проектов – NEIN!!!
географически Максимальный
распределены Collocation
Совместный старт
проекта (старт в
одной локации)
Регулярные
командировки,
video skype, и тд.
20. Пример #4: Кто-нибудь остановите
Backlog!
• Demo => Feedback => New
Requirement
• Бесконечное улучшение «одного
отчета»
• Потеря фокуса разработки
• Срыв сроков
21. Пример #4: Кто-нибудь остановите
Backlog!
• Demo => Feedback => New Requirement
NEIN!!!
PO должен Feedback ≠
балансировать м/у Requirements!
обратной связью и Запиши на Демо,
целью релиза прими решение
после нее!
У релиза
должна быть
Цель!
22. Пример #5: Самоделкины
• У нас Scrum, но…
• У нас KanBan, но…
• Нет прогресса
• Маскировка процесса – А у нас «Модный
Scrum»
• Нет обещанного результата
• Agile – отстой, Scrum – не работает. Все плохо
23. Пример #5: Самоделкины
• У нас Scrum, но…
• У нас KanBan, но… Не меняй Scrum
или Kanban – до
Нельзя отменить то, тех пор пока все
что не пробовал практики
полностью не
Как правило, то что внедрены
хочется отменить
оказывается самым
полезным
внедрением
24. Пример #6: Бесконечная итерация
• Мы не успеваем сделать все в срок
• Отодвинем итерацию на пару дней
• Теряется ритм
• Расслабляется команда
• Если много команд, начинается
интеграционный АД!
25. Пример #6: Бесконечная итерация
• Мы не успеваем сделать все в срок
• Отодвинем итерацию на пару дней
NEIN!!!NEIN!!! NEIN!!!
Нарушение итерации
приводит к тому, что
Бывают ситуации… она становится
Разница в один последней
день ОК!
Бывают праздники,
форс-мажоры:
Публично порицать
удлинение
итерации
26. Пример 7: Близорукость
• Применение Канбан, только
для фазы разработки
• И вообще с нашей стороны
пули вылетают
• Мы отслеживаем задачки на
доске
Софт - это только
• Работаем быстро часть сервиса
для заказчика
27. Пример 7: Близорукость
• Применение Канбан, только
для фазы разработки
ACHTUNG!!!
Несмотря на то, что Канбан приносит
вы не можете максимальные
влиять на всю результаты когда на
цепочку, доске отражена вся
визуализируйте картина от запроса до
весь поток релиза
28.
29. Пример #8: Повысить ВВП в два
раза!
• Цель следующей итерации на
30% поднять скорость
разработки
• Команду требуют
сфокусироваться на росте
Скорости
• Цифры растут
30. Пример #8: Повысить ВВП в два
Schnellere! Schnellere ! раза!
Так выглядит
Schnellere ! Плохой Менеджер
Velocity! Performance !
Ретроспектива –
митинг для
улучшения процесса
работы команды
У нас тут Agile! Вот
результаты
ретроспективы…
31. Пример #8: Повысить ВВП в два
раза!
• Цель следующей итерации на
30% поднять скорость
разработки в
Понятие скорости
Agile не сильно NEIN!!!NIGHT!!!
совпадает с Цифры растут!
понятием реальной Скорость нет!
скорости Не трогай Velocity!11
Работа менеджера
в Agile – понять, что
нужно заказчику.
32. Пример #9: Слоупоки
• Разработка ТЗ по
Agile
• Итерация 1: REQ1,
REQ2, REQ3
• Итерация 2: REQ4,
REQ5, REQ6 ,
• Итерация N:…
• Релиз
34. Пример #9: Слоупоки
• Разработка ТЗ по
Agile
Вовлекайте
заказчика! Если нет заказчика это
Это возможно даже с просто разработка
гос. службами и кода с регулярным
военными статус репорт в стиле
демо!
Если не вовлекли!
Демо внутри, лучше
чем их отсутствие
35. Проблема #11: Цеховой подход
• Сделали Agile команду, но Интеграционная
команда
как-то не так…
UI-команда
DB
команда
36. Проблема #11: Цеховой подход
Интеграция с онлайн-банком
Свободный платеж
Оплата мобильного телефона
Оплата ЖКХ
База данных Server Side Front end
37. Проблема #11: Цеховой подход
• Сделали Agile команду, но
как-то не так… Не создавайте
компонентные
команды!
Жопа в том! Что ТОЛЬКО(!)
слушает это только Функционально
каждый третий ориентированные
команды
Если компонентные
команды уже произошли!
Используйте Канбан для
синхронизации команд
38. Пример #10:Мусор на вход, Мусор
на выход!
• У нас Agile – можно закидывать
разработку чем угодно!
• Можно сделать плохое требование! Потом
поменять!
Менеджеры это
для Вас! Вы в
зале! Я знаю…
39. Пример #10: Мусор на вход, Мусор
на выход!
Если вы
ожидаете от
разработчиков
это!
40. Пример #10: Мусор на вход, Мусор
на выход!
Не стоит
относиться к
разработчикам
вот так…
41. Итог:
• Если вы вначале пути - будьте категоричны.
– Слушайте Agile Nazi внутри себя
• Право на гибкость имеет только, тот кто
доказал, что может играть по правилам
• Делая изменения в процессе думайте зачем
вы это делаете – ценность имеет то, что
ценит заказчик
42. Для тех кто использует подходы Lean
и Agile в Nazi стиле
• А что если…
Focus фактор отменить
Не использовать Planning Poker для оценок
Задачи не оценивать, только UserStory
Не набивать итерацию: разработчики должны
«курить бамбук»
Собирать топ 3 проблемы со всех команд и
решайте всем скопом
Измерять уровень счастья ваших клиентов
44. • Никита Филиппов
– Мы много знаем о требованиях
и формировании продуктов,
юзер экспириенсе, и ооочень
много об Agile и Lean подходах
• Контакты для связи
– Twitter: @nfilippov
– nfilippov@scrumtrek.ru
– www.Scrumtrek.ru
