Итак, вы прочитали про Agile и у вас загорелись глаза. Вы хотите работать по Scrum. Однако одному Agile не внедрить. Вам нужно убедить заказчика, начальника и коллег. Каждый день с горящими глазами вы рассказываете им по Scrum и Agile, но вот беда - в какой то момент они могут начать вас избегать :-) Несколько лет я (в числе прочего) занимаюсь тем, что продаю или помогаю продать гибкие методологии. В докладе я расскажу о совем опыте продажи Agile заказчику и всем остальным заинтересованным лицам.

1. Как продавать Agile?

6. У нас много багов в коде

7. Нам нужно парное программирование!

9. Ну мы не можем разработать достаточно быстро. Срываются сроки релиза. Заказчики жалуются.

10. А парное программирование может помочь?

11. Не уверен

12. Может попробуем поработать так одну итерацию?

14. Выявление последствий проблемы

15. Предложить решение, обсудить его выгоды

16. Рассмотреть опасения

17. Установить безопасное окружение для пилотирования

19. Неосознаваемая заказчиком

20. Явная потребность

23. Проясняющие текущую ситуацию

24. Проблемные вопросы

25. Нащупывающие реальные проблемы

26. Извлекающие вопросы

27. Выясняющие важность проблем

28. Направляющие вопросы

30. Заказчик не заинтересован в результате

31. Agile работает

33. Старинные методы оценки

36. «Мы обычно согласовываем процедуру изменений» (Не беспокойтесь, меняют требования все и всегда!)

37. А давайте мы вам будем показывать раз в 2 недели результат?

39. Заказчик может поменять любую несделанную фичу на эквивалентную по размерам

40. Фичи оценивает вендор

41. Заказчик может добавить или удалить фичу.

42. Заказчик может поменять порядок несделанных фич

43. В любой момент заказчик может принять решение остановить разработку

45. Демонстрировать незыблемость позиции относительно согласованных правил

46. Переводить разговор в конструктивное русло (например - что можно выкинуть из плана или что можно урезать)

49. Постоянно объяснять, что увеличение scope затягивает сроки

50. С самого начала вникать в бизнес-потребности заказчика и просить его аргументировать изменения

55. Регулярно проводить демонстрации и знакомить его с командой

56. Приглашать на стендапы, ретроспективы и так далее

59. Настаивать на соблюдении ритма

60. Тщательно готовится к встрече

61. Ловить за пуговицу в коридоре

62. Опять - хорошие отношения!

65. Если общение заходит в тупик, дать понять, что вы готовы прекратить работу

66. Как правило, это действует отрезвляюще

69. Вовлекайте в работу на ключевых этапах (формирование архитектуры, дизайн компонентов)

70. Целенаправленно повышайте его уровень доверия

71. Обеспечьте высокий уровень прозрачности разработки

72. Ни в коем случае не устраивайте войну! Вы проиграете!

74. АсхатУразбаев askhat@scrumtrek.ru Twitter: zibsun Skype: askhatu ЖЖ: zibsun.livejournal.com