Итоги тренинга Certified Agile Professional

Давно хотел посетить тренинг на тему гибкой разработки. Долгие поиски привели меня к компании ScrumTrek. Которая предлагает посетить множество программ на эту тему, но знакомиться с Agile лучше на тренинге Certified Agile Professional.

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

Тренинг длится два дня с 10:00 до 18:00. В стоимость тренинга входит обед и кофе-брейки. Участников было около 20 человек. Тренинг начался со сбора ожиданий участников.

Ядро программы охватывает четыре темы: 

Принципы и ценности 
Scrum 
Kanban 
Ретроспектива

Частично затронули: 

Как продавать 
Как убеждать руководство и клиентов 
Как внедрять

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

Тренинг больше про устройство и механики методологий Lean, Scrum, Kanban. Вы осваиваете фреймворк, понимаете как он работает и уже самостоятельно допиливаете под свой рабочий процесс. Информации в интернете и книгах много, а вот сложить мозаику в единую картинку получилось только благодаря обучению. Отдельный лайк Алексею за многочисленные практические упражнения и игры, благодаря которым мы смогли не только понять новый материал, но и прочувствовать на себе.

так выглядит время обеда

Agile

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

На выходе мы получаем сорванные сроки и заоблачные бюджеты. В Agile вся работа проходит те же самые этапы и здесь правы те, кто говорит, что Agile — это маленький водопад. И ключевое слово «маленький».

Вся суть гибкого подхода — прогонять через производственную цепочку небольшие порции продукта.

А уже как именно прогонять эти порции, зависит от требований к продукту, команде, срокам и т.п. И здесь на помощь приходят Scrum, Lean, Kanban, SAFe, DevOps и много других страшных слов =).

Scrum

Каждый порядочный Scrum начинается с беклога продукта. Это список задач, которые выстроены по цепочке от наиболее важной. Одна задача называется PBI (Product Backlog Item) и записывается в форме шаблона: «Как <роль пользователя>, я хочу <функционал>, чтобы <ценность>».

кликни меня

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

Понятно, что какие-то истории могут быть очень большими. Если это приоритетная история, то она дробится на более мелкие. А если это функционал «на потом», то просто записывается в беклог проекта, чтобы не забыть. Таким образом, самые приоритетные вещи должны быть разбиты на мелкие истории, а в конце беклога допускаются записывать функционал большими кусками и не тратить время на детализацию.

За беклог отвечает Product Owner. Он формирует не только список историй по приоритетам, но и критерии приемки для каждой истории. А дальше все просто: приходит команда (не больше 7-9 человек) оценивает каждый PBI и планирует что влезет в Спринт.

Спринт – это две недели работы. После первой недели происходит планирование и переоценка приоритетов того, что пойдет во второй спринт. Ежедневно команда собирается на 15 минут, и каждый говорит:  

Что было сделано (именно сделано)
Что будет сегодня сделано (именно сделаю) 
Что мешает

За проведением планирования, ежедневных отчетов и т.п. следит Scrum Master. Можете его воспринимать как тренера. Он не вмешивается в разработку, а управляет процессом обсуждения, занимается устранением проблем и всячески оберегает от внутренних и внешних факторов и отвечает за развитие команды.

Условно, можно считать, что в водопадной модели роль Product Owner выполняет Аналитик, а роль Scrum Master – Менеджер.

кликни меня

В конце Спринта команда проводит демонстрацию выполненного продукта заказчику и Product Owner’у. Затем проводит Ретроспективу. Что было сделано хорошо, что плохо и что можно улучшить.

Интересно то, что каждая работа (PBI) оценивается в виртуальных оценках (Story Points) и у команды нет необходимости пытаться заранее предугадать сколько уйдет часов или дней на каждую задачу. С другой стороны, после нескольких спринтов Product Owner может построить график и оценить производительность команды в этих виртуальных оценках, для того чтобы спрогнозировать сколько уйдет времени на оставшуюся работу.

Как именно проводить рефлексию (она же «Ретроспектива»), оценку работ и планирование – это тема для отдельной статьи. На тренинге на это ушло полдня с разбором всех деталей и тонкостей.

и меня кликни

Kanban

Если в Scrum мы ограничены объемом команды (не больше 7-9 человек), то здесь этого ограничения нет. Вся работа также бьется на простые истории (PBI). Все этапы нанесены на доску и здесь пропадает такое понятие, как Спринт.

и меня…

Вы просто фигачите задачи, пока они есть. Но есть и ограничения. Каждый этап должен выдавать ограниченное количество готовых PBI, чтобы не создавать завалы невыполненной работы у следующего участка.

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

Ежедневные встречи проводятся так же как и в Scrum, но в другом формате. Работники начинают с конца доски и планируют, какую работу нужно сегодня сделать, чтобы задача (PBI) перешла в другой этап. Другими словами, как сделать так, чтобы задача из статуса «почти готова» перешла в статус «готова».

Если в ходе встречи добираются до колонки «Очередь», то берут новый фукнционал в работу. Т.е. здесь мы в первую очередь работаем над тем, чтобы как можно скорее завершить уже начатую работу.

В Kanban есть такое понятие, как «ускоренная полоса». Когда внезапно появляется задача с наивысшим приоритетом, ее помещают на ускоренную полосу и делают в первую очередь только ее.

Может показаться, что в этом подходе нет никакого планирования, но это не так. Для учета работ строят CFD (Cumulative Flow Diagram), не буду описывать все тонкости, скажу лишь, что изначально задачи оцениваются все в тех же Story Points или просто разбиваются на равноценные по трудоемкости. Фиксируется время перехода каждой задачи и время нахождения в очереди.

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

Kanban & Scrum

Еще раз о различиях подходов. В Scrum – у нас есть ограничение на размер команды, а в Kanban – нет. Зато Scrum позволяет лучше сфокусироваться на определенной группе задач. С другой стороны, Kanban гораздо проще внедрить. Мне кажется, что производительность команды и будущее планирование легче делать в Scrum.

Когда непонятно с чего начинать – внедряй Kanban

– Алексей Ильичев

Пара слов о продаже

Очевидно, что ни один подход не позволяет дать фиксированную оценку по срокам и стоимости проекта. И это проблема. Чтобы оценить сроки завершения проекта нужно понять производительность команды. А чтобы оценить производительность, команде нужно реально поработать несколько месяцев.

Но преимуществом для Клиента может стать тот факт, что в конце каждого месяца он получит не кипу планов и оценок стоимости, а готовый кусочек готового продукта. В конечном счете все ценят результат, а не процесс.

Вторым преимуществом будет возможность вносить коррективы в объем работ и менять приоритеты в ходе разработки.

Третье преимущество – это стоимость. На проект выделяется отдельная команда. Стоимость содержания команды плюс/минус фиксированная, легко посчитать сколько потребуется денег на 6-8 месяцев разработки. Здесь важно понимать, что результат вы получаете уже после первого месяца работы, а значит, нужно считать не только затраты, но и пользу, которую вы начинаете получать от продукта уже после первого месяца.

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

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

Ответы на вопросы

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

Как считать проект если просят все и сразу или фиксированные сроки и бюджет (Тендер)?
Если не серийный продукт, то никак. Смирись. В лучшем случае можешь дать вилку основываясь на примерной длительности работы и стоимости команды в месяц.

Как считать и планировать если разработка на стороне клиента а нам только проектирование и дизайн (а если работы ведутся параллельно?)

Все что параллельно – лучше канбан. Если только проектирование и дизайн, то можно запилить User Story Mapping или прописать требования к проекту для оценки примерных сроков,

а потом Scrum.

Как селзы взаимодействуют с менеджерами на этапе пресейла ?
Как выстраивать стратегию продаж?
Как продавать проектирование и дизайн по Agile? (Решетняк)
Как продавать Agile, если другие обещают четкие сроки, стоимость и дешевле? Может ли маркетинг работать по Agile, как синхронизировать работу между отделами? (Решетняк)
Вот это все выходит за рамки тренинга, но Алексей посоветовал книгу “Открывая организации будущего”, там есть интересная информация. Если лень читать, то ждите обзора или поста в блоге.

Какие способы подсчета стоимости есть?

Смотри статью.

Составление ТЗ по Scrum – нужно ли, и как работать без него? (Раджаб Ибрагимов)
Каверзный вопрос. Зависит от того, что имеется ввиду под словом ТЗ. Если это документ в котором написано Что нужно делать и Зачем, а команда сама решает Как, то оно будет полезно. Минимально – нужно накидать пользовательский историй по шаблону (см. статью выше

Как планировать время сотрудников и менеджера на проект, особенно если они на нескольких проектах?
В идеале один сотрудник на одном проекте. Максимум на двух. Забивать человеку рабочий день на 100% – теряешь в эффективности, он либо умрет, либо будет делать меньше. Если поставить несколько проектов, то будет теряться много времени на переключение между ними. В ходе тренинга игра показала, что если проекты делать друг за другом, то в целом они все будут сделаны быстрее, чем если делать все одновременно, но по чуть-чуть.

Как оценивать оценки команды в начале итерации? (а вдруг можно быстрее или нужно медленнее?)
О, это станет понятно по графику сжигания Story Points. В начале проекта – никак, команде нужно проработать какое-то время, чтобы выйти на рабочий режим.

По каким KPI можно награждать аналитиков, дизеов, манагеров…
Ни по каким. Награждать нужно команду, а не отдельных людей в ней. Нельзя кого-то наградить, если проект провалили.

Кадровые перестановки в команде (Арсен)
Болезни, внеплановые отпуски, «влюбился-и-забил-на-всё» (Арсен)
Если это Scrum, то останавливаем спринт и планируем что можем сделать без выпавшего человека. Если человек незаменим, то у тебя проблема, в команде компетенции должны пересекаться, а значит Scrum Master плохо отработал и не работал над развитием команды.

Мотивация (Арсен)
Работать над улучшением процесса, а не искать виноватых. Процесс сжигания Story Poins можно превратить в игру. В команду можно приглашать различных гуру (по мнению команды) для обучения.

Как выявить заказчика изменений? Особенно если меняется ЛПР на третьей итерации? (Станислав Ефимов)
Выходит за рамки тренинга. Но в Scrum это головная боль Product Owner’a – пусть он следит за заказчиками изменений. А так, если появился новый ЛПР, то это не проблема команды. Предыдущему ЛПР отгружали работу как он требовал, если появился новый, то нужно перегруппировать беклог задач с ним и работать дальше.

Как побудить заказчика сфокусироваться на ожиданиях? (Станислав Ефимов)
Показывать беклог, согласовывать задачи на спринт, делать демо продукта в конце спринта.

Интернет магазины делают по аджайлу?
Минимальный уровень проекта для аджайла? (Исаев)
Минимум – 1 неделя работы. Все что меньше – просто берешь и делаешь))) Магазины – можно делать. У магазина есть типовые работы (развернуть площадку, функционал каталога, корзины…) и уникальные (интеграция с конкретной 1С, хитрый механизм рекомендаций…)
В первую очередь пилите типовые, во вторую – уникальные фичи. Причем типовые можно упаковывать в коробку MVP и продавать с фиксированной стоимостью и сроком.

Примеры Lean в РФ? (Решетняк)
Сдаюсь, не знаю. Да и зачем нужны примеры? Тебе это не поможет, просто скопировать не получится.

Кто должен выступать в роли продукт овнера, как это делается в РФ
Тот кто в курсе бизнес-требований продукта и уполномочен принимать решения. Он же собирает и согласовывает требования от всех остальных заказчиков/инвесторов.

Scrum и Рефакторинг (Арсен)
Вообще легко. Либо делаешь в виде PBI на фичу и ставишь в очередь, либо в рамках спирнта закладываешь 20% времени на технический долг.

Внедрение скрама. переходный этап от водопада к сраму
Нет однозначного ответа. Начать проще с Kanban, либо выбрать Product Owner’а, запилить беклог и начать делать (не забываем про Scrum Master’а).

Итоги

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

И я получил все это и даже чуть больше. Мне стало понятно как проводить планирование работы, как именно проводить «Ретроспективу», чтобы это было не просто бла-бла-бла… как собирать первичные требования, когда Клиент сам не знает чего хочет, как определить границы минимально работающего продукта (MVP), как проводить оценку работ (играть в Planning Poker)…

И самое главное – как с помощью Scrum завалить весь процесс разработки к чертовой матери, но это уже совсем другая история =).

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

Большое спасибо ScrumTrek и Ильичеву Алексею за тренинг. Рекомендую.

p.s. Да, в конце тренинга (через 2 дня) дают сертификат от ICAgile. И если вы идете на тренинг только ради сертификата, то не стоит. Он дается в электронном виде и стремно выглядит, никаких красивых рамок или рельефных печатей 🙂

можно кликнуть и сделать такой-же в фотошопе