Дмитрий Лобасев (lobasev.ru)

Давайте погрузимся в механику гибких процессов и вместе подумаем, как сделать так, что вот, приходите вы, например, с конференции и как менеджер говорите: «Так, ребята, всем Kanban с понедельника!» или «Всем Scrum!». А ребята смотрят на вас – ну, а какой у них выбор? Сказали Scrum, значит, Scrum… Идут, что-то делают, пытаются сделать Scrum, делают какие-то ритуалы, приплясывают возле доски по утрам, ходят, что-то еще делают. Но что-то не работает.

Мой доклад, как раз, этому и посвящен. Давайте рассмотрим механику Agile-процессов – как сделать так, чтобы все-таки это приносило ценность.

Вот как было задумано:

Ну, и получается на выходе:

Пара вступительных слов. О себе. Меня зовут Дима Лобасев. Я последние 5 лет занимаюсь тем, что помогаю компаниям сделать процессы более хорошими, чем они есть сейчас.

Работать приходится с двумя типами компаний:

1. у которых каскадная модель, т.е. водопад,
2. у них никакой процесс. Они говорят, что у них уже Agile, например, или у них водопад, хотя на самом деле там, конечно, процессный адафат…

Смотрите, как интересно индустрия развивалась, пара ключевых моментов:

В 1970 г придумали каскадную модель. Выглядело это примерно вот так:

Т.е. приходит к нам заказчик и говорит: «Ребята, запилите продукт». Мы: «Хорошо, сейчас мы соберем требования, спроектируем, разработаем, протестируем, выкатим, и будет тебе счастье». Правильно?

А на самом деле водопад выглядел вот так вот (это оригинальная pdf, ее можно в Google скачать):

Winston Royce говорил о том, что на самом деле невозможно за один проход сделать хороший, качественный продукт. Нужно сделать таких, минимум, два прохода.

Те, у кого из вас водопад, делаете вы два раза одно и то же, начиная от анализа и заканчивая тестированием перед выкладкой? Мало, кто делает.

Ну, и получается на выходе:

Есть такой ролик Макса Дорофеева на Ютубе, это оттуда скриншотик.

Процесс выглядит примерно так. Какие-то люди большую половину времени проекта генерят какую-то безумную документацию. Разработчики на это все потом смотрят, если смотрят. Они как бы немного в шоке. Тестировщики плачут. На моей практике всегда тестировщикам очень грустно, потому что мало того, что ребята сделали не совсем то, что было написано, так они еще делали это очень долго – мы же не закладывали, какие буферы между стадиями, все равно у нас разработка занимает больше времени, чем мы хотели. И самое интересное – они тестируют обо что?.. Есть даже такой термин «тестирование об требования», хотя заказчик уже понимает, что должно быть что-то по-другому.

Дальше было вот что:

Появился в 1995 г. RUP (Rational Unified Process), основанный на каскадной модели, и появился Scrum. В один и то же год индустрия раскололась на две части.

Были люди, которые верили в RUP и каскадную модель, жестко регламентированные процессы: «Давайте сделаем 33 роли, опишем все-все процессы, процедуры, будем по ним идти, и тогда мы верим в то, что тогда наш проект с высокой степенью вероятности будет сделан в срок, в рамках бюджета, с нужным качеством и т.д.».

И были люди, которые говорили: «Ни фига, не будет это никогда работать, потому что, какой бы мы универсальный процесс ни придумывали, контексты проектов все время разные. Даже внутри одной компании разные проекты имеют совершенно разные контексты, потому что люди разные, технологии разные, заказчики разные, сами продукты разные и т.д. Как один процесс может подходить сразу всем?».

И раз уж сейчас 2015 год, и мы тут говорим с вами про Agile, выглядит так, что вторые ребята победили. Веточка гибких процессов. Почему? Потому что в 2005 г. RUP успешно почил. Не то, чтобы его нельзя было бы использовать или что-то еще. Просто он перестал развиваться, вышла последняя его четвертая версия, и в 2012-13 гг. один из его авторов – Ивар Якобсон – у себя в блоге написал, что «Ребята, извините, был не прав. В современном мире RUP не работает, слишком unified и это его погубило».

В 2006 г. появился Kanban, в 2009 г. – DevOps. Это все нюансы.

Идея вот какая: в индустрии с 2005 г. не появилось ни одной методологии, которая описывала бы последовательно, что и как мы должны делать, которая стала бы промышленным стандартом. Все, что появилось – XP, Scrum и т.д. – это все наборы инструментов. Это все процессные фреймворки, которые вы можете взять за основу и вокруг которых в своей проектной команде можете выстроить свой процесс – такой, какой вам нужен в данный конкретный момент времени.

Давайте посмотрим на пример команды.

Что с ними не так? Все улыбаются. Ну, люди в банке работают. В стороне кто-то сидит. Вы посмотрите в ваших командах, если у вас распределенные команды, есть у вас такое, проявляется или нет? Ребята из Москвы, а этот приехал из Екатеринбурга в командировку. Поэтому он как бы себя с ними чувствует в не очень тесных отношениях, хотя они работают над одним проектом.

Итак, есть проектная команда, которая как-то работает, какие-то проблемы есть, какие-то факапчики, работаем по выходным, заказчик нами не всегда доволен, перерабатываем что-то. И в определенный момент кто-то говорит: «Доколе?». Или бизнес приходит, например, и говорит: «Ребята, уже нельзя больше так работать, давайте начнем что-то менять».

Существует, в принципе, несколько возможных вариантов, как можно поступить. Смотрите, как обычно бывает на практике:

1. внедряем готовый подход, т.е. приходим и говорим: «Теперь вы делаете так, так и так». Это первый вариант.
2. второй вариант – это попробовать «что-нибудь модненькое». Ну, все говорят, Agile, Scrum, Kanban и т.д. Надо, типа, брать и делать.

И что получается на выходе?

Смотрите, бывает или было у вас так? Пример со Scrum’ом:

Разработчики встречаются у доски и один другому говорит: «Вчера я охотился на диких волосатых мамонтов. Сегодня буду охотиться на диких волосатых мамонтов. Как бы, проблем никаких нет». Другой разработчик повторяет то же самое, потому что это ритуал, про который Scrum нам говорит, что мы должны отвечать на три вопроса на этих утренних стендапах. Они поговорили и разошлись.

Есть от этого польза какая-то? «Я делал задачу Jira 125. Сегодня буду продолжать делать эту задачу. И проблем у меня никаких нет. Все, я молодец». Это пример. Есть этому даже название – карго-культ, наверное, слышали? Когда мы исполняем ритуалы, не понимая, зачем они нужны.

Еще один пример. В Scrum’е есть такая штука, на которую все обычно забивают, потому что «понятно, что это, конечно, очень хорошо, но нам она не очень нужна». Но у тех, кто не забивает, бывает вот такая штука:

Ретроспектива. Итерация закончилась, мы встретились, один говорит: «Блин, было отстойно». И другие: «Даа». Друг на друга посмотрели и разошлись.

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

Помогла такая ретроспектива? Наверное, не очень. Потому что не понятно, что это значит – «более качественный код»? «Давайте работать лучше» – из этой же серии.

Есть еще. Я в некоторых компаниях наблюдал вариант «Декларирование ценностей «сверху».

Представьте себе, что менеджер какой-нибудь, руководитель функциональный, например, руководитель IT-департамента послушал специальный доклад, в котором было все круто, фреймворки там в компании, все дела… Приходит в офис и говорит: «Ребята, вы должны разделять Agile ценности, вы должны быть вот такими, инновационными и т.д.». Вот что-то из этой серии:

Ребята на него смотрят… И это не работает… Он не понимает: «Да как же так? Мы же за Agile, мы за вот эти ценности, люди и их взаимодействия… Ходим постоянно… Ребята, вы должны быть ответственны, вы должны думать за бизнес, помогать ему и т.д.».

Проблема заключается в том, что мало говорить, что нужно делать, надо еще и помогать людям это делать.

И идея такая: наша с вами задача, как людей, которые, так или иначе, участвуют в процессе внедрения Scrum, Kanban, чего угодно, чтобы люди – наша проектная команда – понимала, почему и зачем им ходить на стендапы, на ретроспективы, почему их заставляют двигаться короткими итерациями, почему важно устраивать еженедельные демонстрации заказчику результатов?

И тогда это заработает.

Сегодня, как раз, я и хочу вам указать на три основных, ключевых навыка команды, которая могла бы считаться крутой командой.

Давайте представим ситуацию. Помните улыбающихся ребят на фото выше? Они выкатили что-то, и заказчик им: «Это полная хрень, не то», а мы его спрашиваем: «Что же ты молчал, раньше не сказал?». Вот такая ситуация.

Что мы с этим можем сделать? В принципе есть такие варианты:

Agile нам предлагает уже готовые и понятные инструменты. Возьмем тот же Scrum – короткие итерации. Давайте вместо 3х-месячных, полугодовых, годовых циклов научимся, каким бы B2B’шным, сложным, суперэнтерпрайз или B2G наше приложение бы ни было… Давайте научимся раз в две недели поставлять какую-то сборку, собирать с нее обратную связь, делать демонстрацию в конце каждой итерации.

Бизнес к нам приходит и говорит: «Сделайте мне хорошо». Мы его спрашиваем: «А что это значит?». Он: «Ну, как бы это все и значит». Трудно поставлять каждые две недели результат, поэтому мы должны научиться это слайсить.

Ну, там еще куча инструментов разных, вы их прекрасно знаете.

Какая у этого всего подоплека? Что, по сути, эти инструменты позволяют сделать, для того чтобы решить проблему с тем, что мы не то отдаем заказчику.

• Найти ошибку на ранней стадии.
• Контролировать процессы.
• Вовремя корректировать цели.
• Заставить заказчика подробно и корректно формулировать задачу.
• Стать одной командой.

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

Кому-то может показаться, что эта формулировка звучит глупо, но, по сути, это лежит в основе механики гибких процессов. Как можно более быстрый цикл обратной связи.

Что обычно происходит в водопадном проекте? Мы, например, пилим продукт, через год, в лучшем случае, выпускаем релиз, и дальше начинается самое интересное. Все не то. Начинаются change requests, поэтому люди из классического управления придумали процедуры специального управления change requests, которые из заказчиков еще деньги выбивают и т.д.

Наша задача – сделать так, чтобы мы двигались маленькими шажками и постоянно узнавали что-то новое о технических рисках, об инфраструктурных каких-то вещах, о бизнесе, вообще, о клиентах, об их потребностях и т.д. Все, что угодно. Чем больше у нас информации, тем более качественное решение мы можем придумать. И движение короткими итерациями позволяет нам на каждой следующей итерации немножко свернуть в нужную сторону.

С этим понятно – как можно раньше узнавать то, что мы раньше не знали.

И у меня к вам вопрос на засыпку. У вас у большинства, наверняка, сложные проекты. А что, если заявку за две недели нельзя реализовать, бизнесовое требование? Оно не декомпозируется, чтобы была какая-то ценность на выходе. Как быть в этой ситуации? Это вам просто как домашнее задание – подумать…

Давайте усложним пример. Мы сделали выводы из того, что заказчику показали не совсем то, что ему нужно. И решили делать демонстрации часто. Снова ему показываем, на выходе опять получается не совсем то.

«Плохой заказчик» – первое, что приходит на ум. А второе, что приходит на ум – это тоже стандартная тема – «Agile нам не подходит». Типа, мы попробовали, это все в стартапах будет хорошо работать, но в нашем энтерпрайз окружении вообще никак не работает.

В чем здесь проблема? Очень важная и интересная проблема. В том, как мы думаем. Если вы посмотрите любое видео, или почитаете книжку про то, как мозг думает, то вам расскажут, что мозг, вообще, не любит думать. Думать для него – это сложно, больно, неприятно и т.д. Поэтому мозг всегда генерит шаблонные решения. Он просто берет, ищет паттерны, и ваш рот их выплевывает. Т.е. вы столкнулись с проблемой, и чего будем делать? Раз, и моментально есть решение, через наносекунду. Моментальное готовое решение. Ну, Agile нам не подходит, ок. Понятно, давай так, давайте что-нибудь другое. Или там: «О, я точно знаю, как это исправить, давайте сделаем вот так». И мы бежим, делаем, и получаются у нас процессные «костыли».

Идея следующая. Индустрия разработки вот до чего дошла. Давайте мы попытаемся заставить наш мозг думать, как бы это ни было неприятно. И кстати, водичка помогает, помогает ему не пересыхать, помогает ему думать.

Есть хорошая практика, «A3 Thinking» называется, или простой пример дерева причинно-следственных связей. Там пять «почему?».

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

Пример одного из проектов. Долго шли приемо-сдаточные испытания. Т.е. мы фигачим-фигачим бизнес-требования, делаем-делаем, и на этапе приемки они у нас все зависают, не идет дальше ничего. Блин, ну почему так, мы же так старались, вроде бы бизнес приходил, говорил: «Срочно!» и т.д. Начинаем анализировать, почему долго ПСИ? Потому что у бизнеса нет ресурсов на то, чтобы осуществить эту приемку. ОК, почему у них нет ресурсов? Потому что у них есть более важные задачи. Хорошо. Почему у них есть более важные задачи? Потому что по этим задачам, которые мы сделали, потерялся приоритет, пока мы их делали. Например, потому что мы их делали месяц или полгода, либо по каким-то другим причинам слишком долго делали. Либо изначально не было приоритета у этих задач. Интересно, а почему так произошло? А потому что бизнес, как бы, сказал делать, и мы начали делать. А почему они сказали делать? Потому что других задач у них сейчас не было под рукой, чтобы нам дать. Мы внезапно освободились, и бизнес говорит: «Ну, ребята, вы же не можете простаивать, фигачьте вот это». И в итоге, мы делали-делали, тратили время, и потом это все в продакшн не идет, потому что никому не нужно. Проблема? Проблема.

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

Тут еще интересная особенность – готовы ли вы делать такой причинно следственный анализ в одиночку, готовы ли вы смотреть за процессом, что-то делать в одиночку? Скорее всего, нет. Подавляющее большинство людей, 99,9% не готовы. Поэтому придумали объединять людей в команды.

ОК, ты Java-разработчик, у тебя свой кусок кода, а у него – свой кусок кода… Но давайте мы будем учиться работать все вместе. Не просто каждый сделает свои задачки, будем учиться как можно быстрее и качественнее деливерить какую-то бизнес-ценность. И тогда уже мы будем видеть эти проблемы, тогда будем вместе их анализировать и будем придумывать, как можно их исправить.

И пример с ретроспективой. Это встроенный в Scrum инструмент непрерывного анализа, выявления, глубинного анализа и решения проблемы. В Kanban нет ретроспектив, но там наверняка что-то есть, связанное с проблемами.

Итак, второй навык я бы так сформулировал: научиться нам, как команде, вовремя видеть, не прятать под стол, а вытаскивать, наоборот, наружу, обязательно анализировать, не решать симптомы проблемы, а копать корневую причину, и после этого уже решать эту возникшую проблему.

ОК, хорошо, допустим научились это делать. И все делаем, но опять заказчик недоволен, т.е. на приемке оказалось, что мы сделали опять не то, что ему нужно на выходе. Как такое может быть? Что еще мы не учли? Заказчика не научили правильно смотреть. Т.е. вина в заказчике? Или в нас? В нас.

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

Помните шутку: заказчик прибегает в комнату (а у него же приоритет всегда наивысший) и говорит: «Ребята, срочно выстрелите мне в ногу». Они берут и стреляют ему: «Бах!». У него в коленке дырка, он плачет, истекает кровью, прыгает на одной ноге. Когда напряг немного прошел, они его спрашивают: «А что случилось-то?». Он говорит: «Да у меня чего-то под коленкой чесалось». Весь окровавленный, с дыркой в коленке. Они: «Так, может, тебе нужно было почесать?». А он в ответ на это: «А что, так можно было? Я не знал, я думал, только стрелять».

Это примерная иллюстрация подхода, когда мы делаем то, что нас просят. У аналитиков, кстати, есть такое понятие – «снимаем требования с заказчика», т.е. приходим к заказчику с диктофоном, садимся и начинаем выуживать из него то, что он хочет. Блин, ну круто! А он же хочет решить свою бизнес-потребность. Он понятия не имеет, как это должно быть реализовано в продукте, или имеет, но это понятие шаблонное у него. И в этом смысле давайте попробуем научиться помогать заказчику думать. Вне зависимости от того, кто мы в команде – отдельно взятый разработчик, аналитик, тестировщик, менеджер или кто угодно. Мы как команда или как отдел внутренней разработки, который решает бизнес-потребности клиентов, должны помогать им думать, как максимально хорошим способом реализовать то, что им нужно.

Пример. В одном из банков. Мы уже анализировали, потом писали. Когда зафакапились, бизнес пришел и говорит: «Ребята, во всех системах есть Dashboard, давайте запилим Dashboard». Аналитики: «Давайте! Что ты имеешь в виду под Dashboard?». Заказчик: «Ну, это когда цифры здесь, графики тут, это можно сюда, это туда». Аналитики: «Да не вопрос!». Хорошие аналитики сели, написали 200 страниц документации, два месяца согласовывали со всеми подразделениями, разработчики пошли, сделали, выкатили, и что оказалось? А это был B2B продукт. И оказалось, что странно, удивительное дело, но клиенты нашего продукта, хоть они и всей компанией юр. лица российские, оказалось, что большинству из них такой Dashboard, вообще, не нужен в том виде, в котором есть. Некоторым, вообще, не нужен никакой Dashboard. Почему? Потому что клиенты все разные. Есть ИП «Дима», например, у которого одни потребности в Dashboard. И, например, есть ООО «HeadHunter», у которого другие потребности, а есть ритейлер, у которого отличные от первых двух потребности в Dashboard, совершенно другая информация и по-другому должна отображаться. Поэтому фича оказалась никому не нужна.

Мы думали: «Блин, как это сделано в других системах? Может, надо было лучше смотреть, определить, кто действующие лица, для чего нужен Dashboard клиенту?». И был в команде один архитектор, он как настоящий архитектор, очень хороший, был молчалив, слова лишнего не скажет, но когда скажет, – прям бомбил. Ребята обсуждали, вся команда в течение получаса вот-вот-вот, и он такой говорит: «Ребята, а почему вообще Dashboard? Почему, вообще, нужно было сделать Dashboard? Какую проблему мы хотели решить?».

И вот третий навык нас как хорошей, классной, крутой команды заключается в том, чтобы мы помогали заказчику, задавая, например, такие вопросы, или своим опытом, своими знаниями предметной области. Задавая вопросы, на которые нет быстрого ответа. Заказчик прибегает: «Ребята, сделайте Dashboard», а мы ему говорим: «Не вопрос, сделаем. А скажи, пожалуйста, почему Dashboard?». А заказчик такой: «Ну, как? Потому что в других системах есть». А мы ему: «Какой-то слабоватый аргумент. Давай-ка подумаем, для кого он нужен и т.д.». И начинаем эти вопросы обсуждать.

Давайте посмотрим, кто наш конечный пользователь, какие есть сегменты целевой аудитории, какие у них есть потребности, проблемы, как мы можем эти проблемы решить? И для ребят из банка в этом B2B проекте, о котором я говорил, для аналитиков было невозможным даже подумать о том, что в компанию можно прийти и поговорить с будущими пользователями – с финансовым директором, например, или с бухгалтерами. Для них это был «безликий Юрик» какой-то, про которого они ничего не знали. А, оказывается, через клиентских менеджеров, если попытаться, то даже в большом банке можно выйти на конечных пользователей. Они когда это поняли, рты раскрыли и не могли в это поверить. И после этого начали делать.

И второй шаг:

Когда мы глубоко поняли проблематику, тогда мы уже можем проектировать решение. А лучше не одно решение, лучше несколько. И эти решения уже не просто потому что заказчик пришел и сказал «Ребята, сделайте Dashboard», а потому что мы понимаем, кому и зачем этот Dashboard нужен, и как им будут пользоваться.

Разумно звучит?

Третий навык можно сформулировать так: помогать бизнесу добиваться лучших результатов из возможных. Под возможными я имею в виду лучшие из тех, которые мы как IT и бизнес могли придумать, работая вместе. И за те деньги, которые нам дали, или которые мы попросили.

Возвращаясь к вопросу, как сделать, чтобы Agile заработал? Если у всех в команде или хотя бы у большинства будет понимание глубинных механизмов того, как это работает, что мы должны постоянно искать feedback, как можно быстрее узнавать то, чего мы еще не знаем, что мы должны непрерывно выявлять проблемы, глубоко их анализировать и решать, что мы должны помогать заказчику достигать лучших результатов, помогать ему думать. Вот тогда можно подбирать контекстные практики, не unified какие-то вещи, а именно те, которые сегодня у нас заработают.

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

Наша задача – не следовать unified процессам, а имея в основе, например, Scrum или Kanban как базовые фреймворки, каждый день выбирать себе новые инструменты, новые практики или даже придумывать такие, которые будут делать наш процесс еще более хорошим.

Все процессы в Agile-мире эмпирические, основанные на предыдущем опыте, т.е. мы что-то сделали, у нас что-то не получилось, где-то мы зафакапились быстро и дешево, раз – придумали, как можно это исправить.

Ну, и можете проверить, если у вас Agile, Scrum, Kanban, эти две вещи у вас выполняются? Хотя бы эти две. Ориентированы ли вы на бизнес, на то, чтобы помогать ему, а не просто делать то, что он просит, не просто делать фичи, а именно решать его проблемы? Заложены ли у вас механизмы в любом их виде – хоть на стендапах вы проблемы выявляете, анализируете, решаете, хоть на ретроспективах – где угодно. Делаете ли вы это на регулярной основе или нет? И в этом, как раз, и есть успех современных команд.

Контакты

» dlobasev@gmail.com
» lobasev.ru
» ldmitry

Этот доклад — расшифровка одного из лучших выступлений на конференции по управлению и предпринимательству Whalerider.
Мы уже начали подготовку к 2017 году, кстати :)

Дополнительные материалы прошлых лет Вы можете получить, подписавшись на список рассылки конференции WhaleRider.

Автор:

Источник