Кетчуппопрежнемувбутылке

Словом аджайл на территории бывшего союза среди айтишников уже никого не удивишь. Потихоньку разгораются священные войны типа “мой канбан твой скрам укопает” или наоборот. Но, к сожалению, похвастаться реально сногсшибательными результатами от внедрения аджайл не может почти никто. Это как эффект кетчупа, все бутылкой трясут-трясут, а оттуда практически ничего не вылезает.

Хочу поделится с вами своими наблюдениями, сделанными в странах бывшего союза, по-поводу наиболее типичных “узких горлышек”, которые по-прежнему держат кетчуп в бутылке и не дают вам тех преимуществ, которые должно давать внедрение аджайл. Ну, и заодно хочу напомнить о “розовых” трактовках, то есть о том, как должно быть в идеальном мире.

Product Owner

Очень проблемная область. Плохих вариантов тут великое множество:

• Product Owner-a просто нет
• Удаленный Product Owner, которого мы совсем не видим
• “Зашитый” Product Owner. Он, вроде как, есть, но настолько занятой, что его никто не видит
• Product Owner на треть ставки (или на половину, в том смысле, что ему наплевать и его не поймать, у него таких продуктов тьма-тьмущая)
• Product Owner, не имеющий знаний о своей роли, и не умеющий ее выполнять надлежащим образом
• Product Owner, не имеющий права принятия решений
• Product Owner не одно лицо, а целый комитет. А комитет, как известно, хорошо говорит и мало делает

Как должно быть: само собой, PO должен обладать нужными знаниями и навыками выполнения своей работы, иметь полномочия для принятия любых решений (с него и спрос потом, за результаты работы команды) и быть доступным команде, по крайней мере, 3 часа каждый день.

Scrum Master

Типичные болезни вокруг этой роли заключатся в скрам мастерах:

• не имеющих времени (от них ожидают выполнения девелоперской работы на уровне с любыми другими членами команды, а скрам мастерство “Как-нибудь так… Ты уж как-нить – так.” (с) Масяня)
• не имеющих интереса к этой роли (я девелопер, зачем на меня еще и “это” повесили)
• самоучках, с недостаточным количеством знаний (читал Книберга “Записки с передовой”)
• бывших PM-ах, сохранивших PM-скую ментальность и command & control стиль
• тим-лидах, сохранивших авторитет принятия решений в команде

Как должно быть: Скрам мастер не имеет никакой власти над членами команды, работает с одной командой и работает со скрам мастерством больше, чем с прочими вещами. Скорее, бывший HR, нежели бывший разработчик.

Самоорганизовываемая Команда

Именно с большой буквы “К”. Типично, ее просто нет. “А что есть?” – спросите вы. Кучка индивидов, в лучшем случае, сидящих в одной комнате. Каждый работает над “своими” задачами и отношением: “Я свое сделал, что дальше – меня не касается” (количество задач в “In progress” больше количества членов команды). Никакой командной ответственности и никаких командных обязательств. Никто не делится знаниями, все тянут одеяло на себя. Никто не может ответить на вопрос, почему он часть этой команды. Что он в нее привносит? Чего ожидает получить взамен?

Как должно быть: наоборот от всего, что описано выше.

У вас остались PM-ы

Помимо скрам ролей (команда, PO, скрам мастер) у вас есть PM-ы, проектные координаторы и прочие роли “из прошлой жизни”. Ну, не выгонять же столько хороших людей? А учить их делать что-то другое долго, да и не все они хотят этого. Поэтому оставляем их, пусть придумают, чем им заняться. Пусть PO работает с направлением “наружу” к клиентам, а PM с направлением “внутрь” к команде. Ну, или еще чего-нибудь. Они же умные, найдут, чем заняться.

Как должно быть: зачем телеге 5-ое колесо?

Разработчики – разрабатывают

Как вам: “Я не тестер, я разработчик, не боги горшки обжигают”. Или может быть вам знакомо: “Разработчики должны сидеть в, закрытой на ключ, серверной. В щель под дверью, им надо регулярно закидывать пиццу. А периодечески “оттуда” будут вылетать прекрасные продукты в красивых праздничных упаковках. Ни в коем случае разработчики не должны встречаться с клиентами, и уж тем более с пользователями.”

Как должно быть: наоборот.

У вас есть ТЗ

Вы по-прежнему удовлетворяете требования вместо того, чтобы поставлять business value?

Бесполезные скучные ретроспективы

Я вам расскажу, как типично умирают ретроспективы. Мы делаем одночасовую ретроспективу в формате: “Что было хорошо? Что было плохо? Что можем улучшить?” один раз. Второй раз. Третий раз. После третьего раза в wiki уже собрался довольно длинный список наших проблем и он продолжает расти. После 20-ого раза, список уже не растет, и в wiki снизу под списком уже появилась прокрутка страниц, чтобы его прочитать до конца. На 21-й раз кто-то подкидывает умную мысль: “К чему нам тратить час на ретро? У нас же в wiki все проблемы уже описаны. Кому надо пусть идет в вики и почитает. Давайте сделаем 30 минут. Потом 15 минут, потом 5. И в конце-концов мы от ретроспектив отказываемся. Можно делать ее раз в полгода, в формате: “Ну что? Все, как в вики?” – Дааа, все, как в вики, расходимся”.

Как должно быть: в топку списки. И вики в топку. Закончите свою ретро, согласившись всей командой пофиксить одну единственную проблему, которая вам (как команде) подконтрольна и которая для вас больше всего наболела. Запишите ее одну единственную себе на флип-чарт, унесите с собой в следующий спринт и сделайте так, чтобы к следующей ретроспективе эта проблема исчезла. Да, это так просто! И, кстати, купите уже библию ретроспектив: Agile retrospectives. Making good teams great , сделайте свои ретроспективы разнообразными и интересными. И еще одно (после того, как книжку прочитаете): сделайте свои ретро длиннее, пусть они будут 4 часа, вместо часа.

Редкие релизы в продакшн

А у нас релиз в прод – раз в году. Слава богу, у вас спринты не по одному году, спасибо и на этом. Мы быстро-быстро  работаем короткими спринтами по две недели. А толку что, если пользователи смогут это увидеть через год? И связь обратную вы получите не раньше. И переделывать придется снова за целый год. И в чем, собственно, преимущества вашего аджайл?

Как должно быть: частые релизы в прод, ключ к успеху. Чем чаще, тем лучше. Сможете релизиться в прод в конце каждого спринта – просто супер.

Зашиваемся в суппорте

Аджайл внедрили, только баги покоя не дают. Планировать невозможно, никогда не знаешь, когда баг размером с пол-спринта на голову упадет. Ну, а тогда и о командных обязательствах говорить не приходится. Как можно обещать хоть что-то в такой обстановке?

Как должно быть: в 2011 году начинать надо с качества. А это значит с солидных современных инженерных практик. К чему ваш аджайл, если вы код нормально писать не умеете? А если вы не умеете, это не значит, что надо продолжать в том же духе. У нас есть достойные эксперты, которые придут и научат вас, как это делается. Расскажут вам, как делать code review, парное программирование, наладят continious integration, научат TDD, BDD, DDD и заразят желанием заниматься прочими DD. Если вы ждали команды сверху, то вот она: “Просто сделайте это! Уже пора.”

Контракт с фиксированным объемом работ и детальная спецификация

Дааа, давайте взглянем на ваши контракты. Уже страшно? Мне да. Я знаю, там scope зафиксировали (а как же иначе, у нас же гос заказ, там инструкции какие-то за номер 40 чего-то там) и дату и стоимость. И попробуй тут не сделать. Поэтому мы все делаем по старинке. Прикинули по зафиксированному объему работ наши оценки, умножили на греческое число “пи” (самые смелые умножили на “е” вместо “пи”) и вперед, делать скрам. Не надо, простите, уже поздно.

Как должно быть: идите и продайте заказчику фиксированную дату, фиксированный бюджет и нефиксированный объем работ. Я знаю, что сложно, я знаю, что никто до вас не продал. Да, это требует доверия между вами и заказчиком. А никто и не говорил, что будет легко. Но кто-то же должен быть первым.