Итак, вы прочитали про Agile и у вас загорелись глаза. Вы хотите работать по Scrum. Однако одному Agile не внедрить. Вам нужно убедить заказчика, начальника и коллег. Каждый день с горящими глазами вы рассказываете им по Scrum и Agile, но вот беда - в какой то момент они могут начать вас избегать :-) Несколько лет я (в числе прочего) занимаюсь тем, что продаю или помогаю продать гибкие методологии. В докладе я расскажу о совем опыте продажи Agile заказчику и всем остальным заинтересованным лицам.
4. AgileRussia.ru Разговор (1) Нам нужно парное программирование (и это круто) Нет, не нужно (а ты гик)
5. AgileRussia.ru Разговор (2) Какая проблема самая важная для вас? У нас много багов в коде Нам нужно парное программирование! У нас нет времени
6. AgileRussia.ru Разговор (3) А почему это проблема? Ну мы не можем разработать достаточно быстро. Срываются сроки релиза. Заказчики жалуются. А парное программирование может помочь? Не уверен Может попробуем поработать так одну итерацию? Хорошая идея!
10. СПИН Ситуационные вопросы Проясняющие текущую ситуацию Проблемные вопросы Нащупывающие реальные проблемы Извлекающие вопросы Выясняющие важность проблем Направляющие вопросы Направляющие на варианты решения проблем
11. Применимость Agile Agile противопоказан Заказчик не заинтересован в результате Agile работает Нужно максимально быстрое и эффективное достижение бизне-цели
16. «Мы обычно согласовываем процедуру изменений» (Не беспокойтесь, меняют требования все и всегда!)
17. А давайте мы вам будем показывать раз в 2 недели результат?
18. Общие правила Backlog ака список функциональности Заказчик может поменять любую несделанную фичу на эквивалентную по размерам Фичи оценивает вендор Заказчик может добавить или удалить фичу. Заказчик может поменять порядок несделанных фич В любой момент заказчик может принять решение остановить разработку Заказчик формально принимает сделанные фичи
19. Что если заказчик будет напихивать новые фичи, и упираться при разговоре о изменении срока?
20. Все разговоры вести вокруг баклога Демонстрировать незыблемость позиции относительно согласованных правил Переводить разговор в конструктивное русло (например - что можно выкинуть из плана или что можно урезать) Уметь говорить НЕТ
21. Что если заказчик будет раздувать scope фич: «Такое поведение тут подразумевалось! Вы должны это сделать»
22. Партнерство Подчеркивать с самого начала, что заказчик и вендор являются партнерами Постоянно объяснять, что увеличение scope затягивает сроки С самого начала вникать в бизнес-потребности заказчика и просить его аргументировать изменения В крайнем случае, отыграетесь, когда заказчик попросит новые фичи :-)
23. Что если заказчик будет менятьфичи, которые находятся в работе в текущей итерации?
25. Что если мой заказчик при наличии проблем будет сваливать вину на нас?
26. Инвестировать как можно больше в хорошие отношения с заказчиком Регулярно проводить демонстрации и знакомить его с командой Приглашать на стендапы, ретроспективы и так далее Обеспечить высокую прозрачность разработки
27. Мой заказчик очень занятый человек и он не может уделить мне достаточно времени
28. Создавать ритм общения. Например, пусть заказчик встречается с вами каждый второй четверг Настаивать на соблюдении ритма Тщательно готовится к встрече Ловить за пуговицу в коридоре Опять - хорошие отношения! Звонить и вытягивать на общение
30. Заранее согласовывать в контрактепроцедуру выхода. Она должна быть по возможности простой для каждой из сторон Если общение заходит в тупик, дать понять, что вы готовы прекратить работу Как правило, это действует отрезвляюще Если нет, то все равно это не ваш клиент
31. Мой заказчик – технический человек. Он постоянно вмешивается в работу команды
32. Формулируйте с заказчиком правила его участия в работе команды (лучше заранее) Вовлекайте в работу на ключевых этапах (формирование архитектуры, дизайн компонентов) Целенаправленно повышайте его уровень доверия Обеспечьте высокий уровень прозрачности разработки Ни в коем случае не устраивайте войну! Вы проиграете! Хвалите его :-)