AgilePiter. 22 мая
Friday, May 23rd, 2008 @ 11:05:02 am by Igor SobolevСпешу записать впечатления. Спасибо организатором за хороший семинар (см анонс). Очень приятно и интересно было послушать москвичей. Запомнился доклад Алексея Корcуна с полезными ссылками.
Теперь просто немного основных идей и мыслей, которые остались после первой ночи.
Саша Иванов спросил, что же мы пытаемся продать, продавая Agile? Итерации, что еще? По-моему, продавая Agile, мы пытаемся так же “продать” отказ от единого и могучего ТЗ, пытаемся доказать заказчику необходимость его непосредственного и активного участия в разработке. Кстати, по мнению большинства участников, создание своего “прокси” в случае невозможности активного участия заказчика, не решает проблему.
Когда я шел на семинар, вопрос “как продать Agile?”, я понимал в контексте, есть ли какие-то специальные способы убедить заказчика отказаться от тяжелого и неповоротливого ТЗ в пользу активного участия в процессе разработки. На семинаре большей частью речь была о другом, но от этого он (семинар) даже выиграл.
Итак. Серебряной пули нет. (Кто бы сомневался.) Продавать Agile надо так же, как и все остальное, т.е. не надо продавать Agile, а надо продавать решение проблем заказчика, прежде всего, того человека, который принимает решение о том, чтобы платить деньги. Надо говорить на его языке. Хороший способ выявлять скрытые проблемы и переводить их в явные - SPIN. Для установления доверительных отношений - пилотники. Agile - хороший инструмент, надо уметь объяснить, как с его помощью решаются проблемы заказчика. Но, прежде всего, заказчик должен осознать, что у него есть проблема и размер ее достаточен, чтобы потратить силы и ресурсы. Высший пилотаж, это сделать так, чтобы заказчик считал, что он сам придумал, как с помощью нашего инструмента решаются его проблемы.
Заказчик не ищет лучшего, время и силы его ограничены. Ему не надо говорить, что Вы лучшие. Его достаточно убедить, что Вы можете решить его проблемы. Да, но задача заказчика обычно включает в себя граничные условия по деньгам и срокам. А значит, оценку предварительную делать надо. Потом это может вылиться в фикс прайс с ТЗ и технологией change request’ов или стартовую оценку для почасового договора.
Пилотник, как способ завоевания доверия, - замечательная штука. Если удается выделить задачку на 2-3 месяца, на небольшую команду, которая с другой стороны решает конкретную проблему заказчика, то дальше обычно все хорошо. Проблема в том, что не всегда получается подобрать такую задачку, особенно если речь идет о больших клиентах и больших проблемах. Значит ли это, что Agile это удел небольших команд и небольших проектов?
Запомнились 2 слайда Асхата про внедрение Agile по частям. Раньше я обычно слышал, что методологию надо внедрять всю разом и целиком, что, честно говоря, напрягало. Думаю, тут есть еще один момент, внедрение Agile неминуемо связано с перестройкой привычек, психологии людей вовлеченных в это. А это не происходит быстро. Но это уже скорее разговор про внедрение Agile, про границы применимости, как с точки зрения задачи, так и с точки зрения команды. Можно так же подумать о том, когда же можно считать, что мы внедрили, например, скрум, сколько практик надо внедрить, какие отклонения от практик допустимы.
Понравился слайд Александра - Agile в быту. Серьезная медицина - сплошной Agile, и почему-то меня это не радует ни капли. У людей всегда есть глупая надежда, что простое решение где-то есть. Убедить их в обратном - ой как не просто. Путь только один - через осознание проблемы.