poclac в agile что это значит
Да пребудет с вами Agile: гайд по основным терминам + курсы.
Понятия Agile и Scrum давно и прочно вошли в словарь ИТ-специалистов. Но не каждый, кто руководствуется в своей работе принципами манифеста Agile (или так думает), делает это правильно.
Мы составили краткий гайд по Agile в вопросах и ответах и подготовили список курсов, которые помогут разобраться в том, как организовать настоящую команду Scrum и эффективно применять Agile на практике, даже если вы далеки от ИТ.
Понятия Agile и Scrum давно и прочно вошли в словарь ИТ-специалистов. Но не каждый, кто руководствуется в своей работе принципами манифеста Agile (или так думает), делает это правильно.
Мы составили краткий гайд по Agile в вопросах и ответах и подготовили список курсов, которые помогут разобраться в том, как организовать настоящую команду Scrum и эффективно применять Agile на практике, даже если вы далеки от ИТ.
Содержание
Ищем людей, которые проходили образовательные онлайн-курсы и готовы поделиться отзывом о них. Если это вы, напишите нам в чат-бот.
Что такое Agile?
Agile часто определяют как гибкую методологию разработки, что не совсем верно, т. к. Agile — это подход к разработке ПО, совокупность принципов, которые лежат в основе целого набора конкретных фреймворков. Их объединяет сосредоточенность на клиенте и его целях, работа короткими циклами-итерациями, стремление к максимальному упрощению правил, процессов, структур и т. д., большое значение обратной связи и расширение полномочий сотрудников. Другими словами, Agile — это образ мышления, философия и культура, суть которой изложена в Манифесте Agile.
Кто придумал Agile?
Agile, а точнее Agile Манифест или Манифест гибкой разработки программного обеспечения был сформулирован в 2001 году в США группой Snowbird 17, которая состояла из ИТ-специалистов. Их виденье того, как упростить работу и повысить ее эффективность, и легло в основу Манифеста.
Какие основные идеи и принципы Agile?
Главных идей и принципов Agile, которые составляют суть этого подхода и так или иначе определяют любую гибкую методологию разработки, не так уж много.
4 идеи Agile
12 принципов Agile
Какие методологии разработки основываются на принципах Agile?
Это гибкие методологии Scrum, Kanban, экстремальное программирование (XP), DSDM, Crystal, FDD. Самой популярной из них считается Scrum. Ее используют более половины компаний, которые используют Agile-подход.
Scrum представляет собой набор правил, цель которых — создать условия для гибкой, ускоренной разработки и эффективного выстраивания рабочих процессов. В Scrum продукт создается поэтапно, а за адаптацию всех процессов отвечают одна или несколько самоорганизованных команд. У этого фреймворка есть свой набор ценностей, которые помогают создать атмосферу доверия, необходимую для эффективной работы. Это смелость, сосредоточенность, ответственность, уважение и открытость.
Scrum называют эвристической методологией, т. к. в его основе лежит идея о постоянном совершенствовании через обучение и адаптацию. Команда проекта не знает изначально, как точно он будет развиваться. В процессе работы она осваивает навыки самоорганизации, приспосабливается к меняющимся требованиям, анализирует успехи и неудачи и использует полученный опыт для того, чтобы сделать свою деятельность более эффективной.
Как проходит процесс разработки в Scrum?
Процесс создания продукта начинается не с составления или изучения технического задания, которого в принципе нет в Scrum, а с бэклога.
Бэклог — это список задач, составленный на основе желаний и требований заказчика к системе, ее функциональности. Все задачи располагаются в бэклоге в порядке их приоритетности. Это помогает команде понять, какие из них стоит выполнить в первую очередь. Бэклог не создается раз и навсегда: в него постоянно вносятся изменения, т. к. может возникнуть необходимость в добавлении новой функциональности, измениться приоритеты и т. д.
Весь процесс разработки делится на спринты — итерации фиксированной длинны, в течение которых команда выполняет определенный объем работы. Обычно они занимают от 1 до 4 недель.
Команда забирает из бэклога часть задач, которые согласованны и должны быть выполнены за итерацию, и приступает к их выполнению. Такие задачи называются бэклогом спринта. В идеале в конце каждого спринта создается инкремент продукта — готовый к использованию конечный продукт, например, работающая функция ПО, его прототип и т. п.
Бэклог продукта, бэклог спринта и инкремент объединяются термином «артефакты Scrum» — это работа, которую нужно выполнить, чтобы завершить спринт или проект.
Как организована работа команды?
В Scrum очень важно постоянное обсуждение работы, полученных результатов, проблем и вариантов их решения. Поэтому процесс создания продукта включает набор мероприятий или Scrum-событий, на которых члены команды оценивают свои достижения и возникающие сложности.
К ним относятся:
Как распределяются роли в команде Scrum?
Scrum предусматривает три основные роли, которые определяют структуру Scrum-команды. Это Product Owner (владелец продукта), Scrum Master (Scrum-мастер, Scrum-менеджер) и Scrum Development Team (команда разработки, команда разработчиков). Каждая из этих ролей имеет свой набор функций и зону ответственности.
Владельца продукта можно назвать посредником между заказчиком и разработчиками. Он собирает концепцию продукта на основе требований стейкхолдеров, доносит их до технических специалистов, формулирует задачи, определяет их приоритет, ведет бэклог продукта, управляет релизами и заинтересованными сторонами.
Scrum-мастер отвечает за эффективную реализацию методики Scrum. Он помогает наладить групповую коммуникацию, оптимизировать процесс поставки продукта и «защищает» команду от любых отвлекающих факторов. В зону ответственности Scrum-мастера также входит координирование ежедневных процессов: фиксация начала спринта, дедлайнов, добавление оценок и т. д.
Команда разработчиков — специалисты, которые выполняют все технические задачи по созданию продукта. Т. е. под этим термином понимаются не только программисты, но и дизайнеры, аналитики и другие участники команды. Команда разработчиков обычно состоит из 5–7 человек (иногда встречается формула 6 ± 3). Важно, чтобы команда была стабильной и все члены группы понимали, как работает продукт, ведь именно команда разработчиков отвечает за его поставку и качество.
Зачем применять Agile?
Гибкие методологии разработки позволяют максимально быстро реагировать на изменяющиеся требования заказчиков и ситуацию на рынке, а это дает компании конкурентное преимущество и помогает удержать клиентов. Кроме того Agile и Scrum позволяют снизить экономические издержки без ущерба для эффективности работы. Немаловажен и человеческий фактор. Все гибкие методологии подразумевают гуманистический подход: полномочия (и ответственность) сотрудников растут, стимулируя их мотивацию и давая возможности для самореализации, что положительно влияет на результаты работы.
Где и когда стоит использовать Agile-подход?
Несмотря на то, что в Agile-манифесте речь идет о разработке ПО, применять принципы Agile можно не только в ИТ-сфере. Они будут работать практически в любой области, которая связана с проектной деятельностью. Если вам важна ориентация на клиента, его потребности и командная работа, у вас нет точно сформулированных конечных задач, но есть множество факторов, способных повлиять на итоговый результат, а все члены вашей команды мотивированны и организованны, то Agile вам точно подойдет.
Курсы по Agile
spoiler#handleClick»>Примечание редакции
Стоимость указана на момент подготовки материала и носит ориентировочный характер.
Управление по Agile: Scrum, Kanban, Lean (Нетология)
Курс для проджект-менеджеров, тимлидов и владельцев бизнеса, которые хотят научиться применять Agile в своей работе.
Программа обучения включает знакомство с самыми популярными Agile-подходами и предполагает большое количество практики. Всю теорию вы будете отрабатывать во время выполнения заданий в группах или вместе с экспертами на вебинарах. Студенты научатся Agile-планированию, смогут оценивать и декомпозировать задачи, освоят такие инструменты работы над продуктом, как User Stories, Jobs-To-Be-Done, Lean Canvas.
Занятия проходят в формате предзаписанных видеолекций и онлайн-вебинаров. Преподают на курсе ведущие специалисты и практики Agile. На протяжение всего курса доступна поддержка кураторов и экспертов. Выдается удостоверение о переквалификации установленного образца.
Продолжительность: около 3 месяцев (18 марта — 28 июня).
Agile и Scrum в работе над проектами и продуктами (Coursera)
Курс рассчитан на менеджеров проектов и тимлидов, но пользу от него получат все, кто хочет применять в работе Agile и Scrum, даже далекие от ИТ-сферы люди.
Эта программа — совместный продукт Национального исследовательского Томского госуниверситета, Фонда развития онлайн-образования и ScrumTrek, а преподают на курсе аккредитованные ICAgile коучи и тренеры. За несколько недель на доступных примерах вы разберетесь с системой ценностей Agile и принципами Scrum. Изучите основные преимущества Agile-подходов, особенности процесса разработки в Scrum, познакомитесь с сервисом Trello и поймете, как грамотно организовать работу в Scrum-команде.
Продолжительность: примерно 5 недель (по 1-4 часа в неделю).
Как объяснить бабушке, что такое Agile за 15 минут с картинками
«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера
Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.
Это Пэт, владелец продукта. Она не знает технических деталей, зато обладает видением общей картинки, знает, зачем мы делаем продукт, какие проблемы он будет решать и для кого.
Это заинтересованные лица. Они будут использовать продукт, поддерживать его или будут как-то еще вовлечены в разработку.
Это пользовательские истории. В них выражены пожелания заинтересованных лиц. Например, «у системы бронирования авиабилетов у пользователя должен быть поиск по рейсам».
У заинтересованных лиц много идей, и Пэт помогает сделать из идей пользовательские истории.
Это команда разработчиков. Те, кто будет строить рабочую систему.
Пропускная способность
Так как команда использует гибкую методологию разработки, они не копят все эти истории до большого релиза, наоборот, они выпускают их сразу и как можно чаще. Обычно они выпускают 4-6 пользовательских историй в неделю. Это их пропускная способность. Ее очень просто измерить — количество пользовательских историй за 7 дней.
Некоторые истории большие, их можно считать за две, некоторые маленькие, их можно считать за половину.
Для того чтобы поддерживать этот ритм и чтобы не завязнуть в ручном регрессивном тестировании, команда усиленно работает над автоматическим тестированиеми постоянной интеграцией. Поэтому на каждую фичу приходится писать автотесты, и большая часть кода имеет встроенные автотесты.
Проблема заключается в том, что заинтересованных лиц очень много и их запросы невозможно удовлетворить 4-6 историями в неделю.
Каждый раз когда мы реализуем пользовательскую историю, у них появляется еще несколько идей, из которых вытекает еще больше запросов.
Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.
Допустим, команда возьмется сделать 10 новых историй за эту неделю.Если на входе 10 а на выходе 4-6, то команда будет перегружена. Будет спешить, переключаться между задачами, терять мотивацию, в итоге снижается производительность и качество. Это заведомо проигрышная стратегия.
Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”
Задача владельца продукта в том, чтобы грамотно выбирать, какие именно пользовательские истории будут реализованы на этой неделе.
Kanban рекомендует ограничиться несколькими задачами — WIP limit. Допустим команда решает, что 5 — это приемлемое количество пользовательских историй, над которыми они смогут работать одновременно без перегруза, не перескакивая с одной на другую.
Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.
Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.
Есть только один способ держать список задач под контролем — это слово “нет”
Это наиболее важное слово для владельца продуктом. Он должен тренировать его каждый день перед зеркалом.
Сказать “да” — легко. Но более важная задача — решать, что не надо делать и нести за это ответственность. Владелец продукта так же определяет последовательность, что делаем сейчас, а что позже. Это сложная работа и выполнять ее следует вместе с командой разработки и минимум одним заинтересованным лицом.
Для того, чтобы правильно расставить приоритеты, владелец продукта должен понимать ценность каждой истории и ее объем.
Принятие решений
Некоторые истории крайне необходимы, а некоторые просто бонусные фичи. На разработку одних историй уйдет пару часов, на разработку других — месяцы.
Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи — вот что помогает Пэт расставлять приоритеты.
Как владелец продукта определяет ценность и объем истории? Никак. Это игра в угадайку. И лучше в ней участвовать всем. Пэт постоянно общается с заинтересованными лицами, чтобы знать ценность каждой истории, общается с командой разработчиков, чтобы знать объем работ, но все это приблизительные догадки, никаких точных цифр. Вначале всегда будут промахи и это нормально. Гораздо большую ценность представляет общение, чем сверхточные цифры.
Каждый раз когда разработчики выпускают что то новое, мы узнаем больше информации и можем лучше ориентироваться.
Одной приоритезации недостаточно. Чтобы выпускать истории быстро и часто, нужно разбивать на кусочки, которые можно сделать за пару дней. Мы хотим чтобы в начале воронки были маленькие и четкие истории а в конце — большие и неопределенные. Вовремя делать такую разбивку мы можем воспользоваться нашими последними открытиями относительно продукта и нужд пользователя. Это все называется очистка Backlogа.
Пэт проводит встречу по очистке Backlogа каждую среду с 11 до 12. Обычно на ней собирается вся команда и иногда несколько заинтересованных лиц. Содержание встреч бывает разным. Фокусировка на оценке, на разбивке историй, на критериях приемки.
Владелец ИТ-продукта должен постоянно со всеми общаться
Матерые владельцы продукта выделяют 2 компонента успеха: страсть к работе и общение. Какие задачи владелец продукта решает месте с командой.
Баланс между сложностью разработки и ценностью пользовательской истории
На ранней стадии балансу угрожает неопределенность и сразу несколько рисков.
Риски
Бизнес риск: «Правильную ли вещь мы делаем?»
Социальный риск: «Сможем ли мы сделать то что нужно?»
Технический риск: «Будет ли проект работать на данной платформе?»
Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»
Знание можно рассматривать как противоположность риску. Когда неопределенность большая, мы фокусируемся на приобретении знаний — прототипах интерфейса, технических экспериментах,
Компромисс между ценностями знания и ценностями для клиента
С точки зрения заказчика кривая выглядит вот так:
С точки зрения ценности для заказчика эта кривая выглядит вот так. По мере того как неопределенности снижаются, мы можем концентрироваться на ценностях для заказчика. Мы знаем что и как делать. Остается только сделать. После того как реализовали основные истории, будем делать бонусные фичи или запускать новый проект.
Компромисс между краткосрочным и долгосрочным мышлением
Что реализовать в первую очередь? Срочно устранять ошибки или начать разрабатывать сногсшибательную фичу, которая поразит пользователей. Или делать сложный апгрейд платформы, который ускорит работу в будущем. Необходимо постоянно соблюдать баланс между реактивной и проактивной работой.
Делать правильные вещи, делать вещи правильно или делать быстро?
В идеале — все три одновременно, но в реальности приходится выбирать.
Предположим мы здесь. Пытаемся создать идеальный продукт с помощью идеальной архитектуры. Если мы потратим много времени, мы можем не попасть в «маркетинговое окно» и у нас появятся проблемы с деньгами.
Мы делаем быстро прототип продукта. Для краткосрочной перспективы это неплохо. В долгосрочной — мы получаем технический риск. И скорость разработки снизится до нуля.
Мы вот здесь, создаем прекрасный храм в рекордные сроки. Но пользователю не нужен был храм, ему нужен был жилой фургон.
Между ролями в Scrum существует здоровое противостояние
Владелец продукта фокусируется на построении правильных вещей. Команда фокусируется на том, чтобы строить вещи правильно. Scrum-мастер или agile-тренер фокусируется на сокращении цикла обратной связи.
Отдельно стоит подчеркнуть важность скорости, так ккак короткий цикл обратной связи ускоряет обучение. Это позволяет нам быстрее узнавать какие вещи правильные и как их правильно построить.
Компромисс между разработкой нового продукта и улучшением старого
Продукт никогда не может быть полностью завершен, потому что ему постоянно нужны изменения. Когда команда начинает работу над новым продуктом, что происходит со старым? Передача продукта от одной команды к другой — очень затратно и рискованно. Обычно команда поддерживает старый продукт, разрабатывая новый. Поэтому скорее понятие “Backlog” относится не к продукту а к команде. Backlog — это список вещей, которые хочет владелец продукта от команды. И набор историй для разных продуктов. Владельце продукта нужно постоянно выбирать актуальные для реализации.
График уничтожения историй
Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.
Два тренда — оптимистичный и пессимистичный (можно на глаз). Расстояние между трендами показывает насколько нестабильна скорость работы команды. Со временем эти тренды стабилизируются и конус неопределенности будет уменьшаться.
Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?
Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.
Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.
Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»
Обычно лучше уменьшать содержимое проекта, чем увеличивать время. Если мы уменьшаем содержание, у нас будет возможность отодвинуть сроки. Мы можем выпустить кое-что здесь, а остальное — позже.
Владелец продукта делает расчеты еженедельно и использует исключительно эмпирические данные, а не выдает желаемое за действительное. Он честно говорит о неопределенности. Команда поддерживает темп работы, а Пэт не давит на них, заставляя ускориться.
Несколько команд
Пусть у нас несколько владельцев продукта и несколько команд. Модель та же — управление пропускной способностью, коммуникация с заинтересованными лицами, принятие решений по поводу отклонения пользовательских историй. Скорость равна сумме скоростей всех команд. Прогнозирование может быть общее или по каждой команде. У владельцев продуктов появляется дополнительная задача — общение с другими владельцами продукта. Нужно организовать работу над Backlogами так, чтобы минимизировать зависимости и обеспечить синхронизацию. В больших проектах требуется Главный владелец продукта (CPO), чтобы синхронизировать всех остальных.
Мастер-класс Бориса Вольфсона. Основы Agile
Этот пост написан по мотивам мастер-класса Бориса Вольфсона (директора по развитию HeadHunter), посвященного (сюрприз!) основам Agile. Материал будет полезен всем, кто либо совсем не знаком с данной методологией разработки сложного ПО, либо имеет о ней смутное представление.
Водопадная модель
Доктор Ройс создал так называемую водопадную модель разработки программных продуктов. Она быстро завоевала популярность на Западе, и некоторое время назад по этой модели работало подавляющее большинство компаний-разработчиков. Что она собой представляет? Разработка продукта проходит через ряд этапов:
Для чего нужна методология гибкой разработки?
Итак, для чего же применяется методология Agile?
Манифест гибкой разработки
Он состоит из нескольких частей. Первая часть называется «Ценности» (Values). Это четыре «взвешивания»:
Приведу свежий пример. Мы выкатили небольшую фичу на HeadHunter, когда ваши навыки может подтверждать любой — поставил вам плюсик, и появится надпись, что столько-то человек подтвердило ваш навык. У меня Scrum подтвердило 18 человек. Мы специально запустили это в очень простом виде, чтобы посмотреть, как к этому отнесутся пользователи. Мы исходили из логики, что будет взаимодействие а-ля LinkedIn или Хабр, где пользователи друг друга плюсуют. Сняли статистику, и оказалось, что у нас эти плюсики ставят, вероятно, после собеседований HR. То есть дальше мы можем развивать эту фичу в сторону HR, либо как-то ее модифицировать, чтобы она была более полезна соискателям. Таким образом, в Agile существует четыре ценности:
12 принципов Agile
Ценности влекут за собой 12 принципов Agile:
Итак, у нас получается пирамида, состоящая из четырех ценностей, на которых выстроено 12 принципов. Теперь появляются конкретные практики.
Практики
Одна из ценностей Agile гласит: мы должны выстраивать рабочий процесс, налаживая взаимодействие и коммуникации между людьми. Это выливается в практические шаги. Например, в утренние стендапы, когда команда устно синхронизирует свою деятельность на предстоящий день. Можно вместо стендапов каждому писать отчет о проделанном вчера, но это уже будет не Agile, потому что возникает поток малозначимой документации. Какие же практики чаще всего используются в компаниях, практикующих гибкую разработку?
Нам надо дойти из точки А в точку Б. «Дойти» — означает «получить обратную связь». Допустим, у меня есть GPS, я могу дойти до какой-то точки и свериться, правильно ли я дошел. Водопадная модель — фактически, один большой шаг. То есть я куда-то пришел, выпустил на рынок продукт, и только после этого могу понять, то ли я сделал. Итеративная модель — это серия шагов. Я делаю первый шаг, снимаю метрики, что у меня используется в продукте, затем корректирую дальнейшие шаги. Пусть я приду не в точку Б, но окажусь в ее окрестностях.
При коммерческой разработке у нас постоянно меняются условия: выходят новые законы, изменяются бизнес-требования, конкуренты вдруг выпускают что-то, что мы должны сделать лучше, чем они. В итоге получается, что мы из точки А должны дойти не в точку Б, а в точку В. Итеративная модель подразумевает, что после выпуска первого релиза мы снимаем метрики, что-то переделываем, делаем следующий релиз, и т.д. И на каком-то этапе понимаем, что конкурент выпустил какую-то фичу, и нам нужно идти не туда. В этот момент мы можем остановиться, принять другие требования и начать двигаться в точку В. При высокой изменчивости условий в процессе создания продукта вы все время будете узнавать что-то новое. И в этом одно из преимуществ итеративной модели.
Еще важный момент: когда менеджеры (и даже разработчики) не очень глубоко погружены в техническую часть, им кажется, что можно итеративно сделать программу, собрать по кусочкам, как паззл. Это заблуждение. Разработчик должен представлять целиком и в деталях каждый элемент картины, и начать его делать за пять шагов. При этом надо иметь в виду, что условия могут поменяться. Это называется инкрементальным подходом («инкремент» — добавление чего-то).
Чтобы работать итеративно и инкрементально, нужно действовать немного иначе. У разработчика в голове должна быть какая-то концепция, которую он постепенно прорабатывает.
Если вы работаете по «водопаду», то обычно у вас фиксировано содержание проекта. Вам говорят: «Хочу, чтобы вы сделали это. Я точно знаю, чего хочу я и мои пользователи. Оцените, сколько человек вам для этого нужно и сколько времени на это уйдет». В Agile мы действуем по-другому: у нас есть команда и фиксированные отрезки времени (я говорю про Scrum), например, двухнедельные итерации. Исходя из этого, мы планируем объем работ, который мы можем выполнить за это время.
Если взять классический подход и спросить: «Вы сделали этот проект успешно или нет? Как это понять?». Я должен его сделать вовремя, не превысив бюджет, и полностью сделать содержание. Если мы смотрим с позиции Agile, то наш проект тем успешнее, чем больше мы поставили ценностей заказчику.
Scrum
У Хенрика Книберга есть такая метафора — Agile-зонтик. Это те методологии, которые являются гибкими. Самая большая — Scrum, экстремальное программирование (XP), DSDM, Crystal, FDD, Kanban. Более половины компаний, применяющих Agile, используют Scrum. На втором месте комбинация Scrum и XP, когда берутся управленческие практики из Scrum и добавляются инженерные. Отдельно отмечу, что комбинация Scrum и Kanban используется примерно в 8% компаний. Сейчас это один из трендов, мода. Название Scrum пришло из регби и переводится как «схватка». Проще говоря, при возникновении спорной ситуации команды выстраиваются, вбрасывается мячик, и нужно друг друга перетолкать. К разработке продукции этот термин впервые применили в 1980-х годах два японца — Хиротака Такэути и Икудзиро Нонака. Это хорошие исследователи в области менеджмента. В частности, они написали документ «The New New Product Development Game». Здесь употребление слова «new» 2 раза не является ошибкой. Просто название переводится как «Новая игра для разработки новых продуктов». Что сделали эти два японца? Они проанализировали, как различные компании создают свои продукты. Причем даже не ПО, а всевозможную технику и электронику. Авторы разделили выявленные подходы на три типа.
Тип C двое японцев сравнили с ситуацией в регби. Почему? Смысл игры в том, чтобы взять мяч и донести его до линии поля противника, преодолевая сопротивление. Но в регби нельзя кидать мяч вперед. Когда ты бежишь и понимаешь, что сейчас тебя положат наземь, то мяч можно отдать назад члену своей команды. Он его ловит и бежит дальше. Если не может преодолеть сопротивление, то бежит назад.
Современный Scrum создан двумя айтишниками — Кеном Швабером и Джефом Сазерлендом. На официальном сайте www.scrumguides.org вы можете ознакомиться с официальным описанием Scrum. Так выглядит общая схема Scrum:
Итак, мы хотим делать какой-то продукт. Он разрезан на отдельные кусочки, которые называются бэклогом (backlog) продукта. Это требование. То есть у нас нет технического задания или какого-то обширного документа, который все заранее описывает. Обычно чем важнее какие-то требования, тем качественнее они разбиты и описаны. Этим занимается владелец продукта (product owner).
Среднестатистическая команда состоит из семи человек (плюс-минус два человека). Если сильно меньше, то, скорее всего, в команде не хватает каких-то специалистов, потому что подразумевается, что Scrum-команда может самостоятельно сделать из бэклога готовый продукт с новой функциональностью. Например, в команде может не быть фронтэнд-программиста. Если вы используете Scrum и проект подразумевает фронтэнд-разработку, то этого специалиста нужно включить в команду.
Компоненты Scrum
Роли
Scrum-команда состоит из команды разработки, владельца продукта и Scrum-мастера.
Бэклог спринта — верхняя часть бэклога. Количество элементов обычно определяется скоростью команды на мероприятии, которое называется «планирование спринта», и проводится перед началом самого этапа спринта. Спринт длится 1—4 недели (чаще всего 2 недели). Чем быстрее и дешевле можно релизить, тем меньше продолжительность данного этапа.
Каждый день команда проводит 15-минутный стендап, Scrum-митинг, на котором все члены команды синхронизируют свои действия. Зачастую эти встречи называют просто «скрамами».
После завершения спринта проводится демонстрация — «Обзор», смысл которой заключается в том, что команда показывает сделанную работу владельцу продукта или кому-то еще. Затем проводится ретроспектива, на которой команда обсуждает, что получилось, а что нет, происходит разбор рабочих процессов, атмосферы в коллективе, предпринимаются попытки что-то улучшить. После этого запускается следующий спринт. В итоге работу Scrum-команды можно представить как цепочку множества спринтов.
Артефакты
Это могут быть карточки на доске с кратким описанием, что собой представляет конкретный функционал. При этом содержание карточки может представлять собой обсуждения с владельцем продукта. Обычно это выливается в тикеты в трекере, который вы используйте — JIRA, Redmine и т.д.
Примеры Scrum-практик: оценки
Здесь не будет канонического/кошерного/ванильного Scrum’а, который описан Швабером и Сазерлендом, и про который можно почитать здесь: www.scrumguides.org. Расскажу о реальных практиках, используемых командами. Есть тяжеловесные, якобы точные методы все «правильно» посчитать и сделать. Но практически все большие проекты выбиваются из сроков. И это касается не только IT. Например, был случай, когда аэропорт не могли запустить в эксплуатацию из-за того, что не был готов софт, отвечающий за автоматическое распределение багажа. Если вы используете гибкие методологии, а также то, о чем я сейчас расскажу, то можете спокойно запускать проекты, без геройства. Один из наших больших проектов, который закончился в сентябре, фактически был готов на production за две недели до официального запуска. Я много наблюдал, как команда, тимлиды и менеджеры пытаются предсказать, когда у них будет готов проект. Это примерно то же самое, что подойти к команде и попросить назвать случайное число.
Agile и Scrum предлагают использовать такую практику: делать относительные оценки, то есть «измерять в попугаях». Это значит, что я оцениваю время, которое у меня уйдет на решение задачи, и сколько она займет попугаев. Их обычно называют story point. Эти story point лучше не привязывать ни к каким временным промежуткам. Каким образом делать такую оценку, почему она называется относительной? Обычно берут какую-то задачу, небольшую, стандартную и понятную всем, и объявляют ее мерой, эталоном — она занимает 1 попугай, 1 story point. Берется следующая задача, сравнивается с первой — она оказывается в 2 раза больше. Сколько она занимает? 2 story point. И таким образом мы раскладываем все задачи. В итоге мы не оцениваем каждую задачу по времени, а сравниваем их между собой. Если где-то ошибаемся, то это нормально. Главное, чтобы во всех задачах ошибались одинаково. Оценка делается командой и в рамках команды.
Что мы можем сделать после этого? Например, запустить двухнедельный спринт и взять верхние задачи без каких-то оценок. Когда спринт закончится, на выходе получим инкремент продукта, в который будет включено какое-то количество задач. Посчитаем, сколько story point мы сделали, и на следующий спринт просто можем планировать такое же количество story point. Подобная оценка получается относительной и эмпирической. Мы не предполагаем, как любят делать управленцы, что программист Вася работает 8 часов и с одинаковой эффективностью, а реально измеряем, сколько команда может проживать story point за спринт. Шкала оценок обычно подбирается так, чтобы различать задачи разных классов.
Если приглядеться, то похоже на числа Фибоначчи, либо на степени двойки. При этом оцениваются обычно действительно большие задачи, которые дальше разбиваются на более мелкие. Для формирования оценок обычно используется покер-планирование. Это модификация метода Delphi. Каждому члену команды дается колода карточек с числами от 0 до 100. Есть еще карточка с надписью «Я не понимаю, что это за задача» и карточка с кофе («Давайте сделаем перерыв, я уже замучился заниматься этой оценкой»). После этого берем задачу номер такой-то, читаем и обсуждаем, что она собой представляет: «Пользователь вводит логин-пароль для того, чтобы авторизоваться на сайте». Обсуждаем, как эта авторизация происходит, где мы храним пользователей. Затем каждый член команды рубашкой вверх кладет карту с оценкой, которую считает нужной. При этом разные члены команды друг на друга никак не влияют, потому что обычно в команде есть тимлид, ведущий, старший разработчик, на которого равняется большинство. После этого происходит вскрытие карт и обсуждение.
Согласно методу Delphi, обсуждение происходит между теми, кто поставил наибольшую и наименьшую оценки. Поставивший наибольшую обычно видит какие-то риски, которые не заметили другие члены команды. Он скажет: «Вы знаете, в эту базу, где у нас хранятся логины и пароли, мы давно не заходили. Там надо что-то отрефакторить, добавить колонку, применить другой хэш» и т.д. А человек, поставивший наименьшую оценку, либо не понимает задачу, либо видит способ сделать быстрее, либо уже делал что-то подобное. После этого происходит второй этап обсуждения: опять все кладут карточки рубашками вверх, потом вскрывают их. Обычно оценки более-менее сглаживаются. Снова проходит этап обсуждения, приходят к консенсусу. В результате записывается в трекер, в тикет-систему, либо прямо на карточку, что у нас эта задача на 3 story point.
Почему это очень хороший Agile-подход? Мы беседовали, обсуждали содержание задачи, основывали наши действия на взаимодействии людей, а не на каких-то формальных процессах. Если кому-то интересны процессные вещи — обратитесь к методу оценки Кокома. Чем еще хорош данный метод? Здесь получается некая командная ответственность за размер задачи. Все берут на себя ответственность за то, что задача действительно такого «размера». Если же вы будете измерять трудоемкость задач, скажем, в днях, то будут ситуации, когда кто-то в команде оценит ее в 8 дней и она попадет к нему, то он ее и будет делать 8 дней.
Что делать в том случае, если заказчик хочет понять, сколько времени займет реализация проекта и просит сразу дать ему оценку? Идеальный вариант — работать с заказчиком по системе «время — материалы». Если заказчик новый, то можно один проект сделать по Fixed Price, убедиться, что заказчик адекватный, и дальше придерживаться системы «время — материалы». Если заказчик не соглашается сразу на данную систему, то можно ее скорректировать: например, если вы заканчиваете проект к определенной дате, то получаете какой-то бонус. На эту тему в сети тоже есть презентации.
Примеры Scrum-практик: скорость команды
Мы берем каждый спринт, измеряем, сколько story point сделали. И если нам надо спланировать девятый спринт, то просто берем среднее значение из предыдущих спринтов. Это называется «принцип вчерашней погоды». Здесь важно то, что мы набираем наиболее важные или ценные задачи исходя из скорости команды.
Если какая-то задача не помещается по размеру, то ее можно разбить на более мелкие, либо пометить, что она не войдет, либо отказаться от ее решения. Надо понимать, что скорость не будет равномерной. Люди работают с переменной интенсивностью, кто-то заболевает, кто-то работает медленнее из-за проблем дома, кому-то надо срочно пообщаться в соцсети, кто-то взял отпуск. Всегда нужно прямо и однозначно говорить владельцу продукта: «У нас есть задачи A, B, C, мы их точно успеем сделать, они попадают в нашу самую низкую скорость. Есть также задача D, которую мы, скорее всего, успеем сделать. Но есть и задача F, которая может выпасть». Кажется, что это неточность, и владелец скажет: «Вы что? Надо все успеть». На самом деле, когда вы ему говорите точно, что самые важные задачи будут сделаны, то это увеличивает доверие между вами и владельцем продукта или заказчиком, и он для каждого спринта сможет выбирать самые важные задачи и гарантированно их получать.
Примеры Scrum-практик: путевой контроль
Как во время спринта контролировать, что у нас все идет хорошо? Мы спланировали спринт и начали его реализацию. Для контроля используется диаграмма сгорания Burn Down Charts.
По горизонтали отмечаем дни — это двухнедельный спринт, 10 рабочих дней. По вертикали с одной стороны отложены story point, с другой — истории пользователей или элементы бэклога. Если бы мы с вами были роботами, а задачи маленькими и разбитыми на кусочки, то мы шли бы по пунктирной линии — это линия идеального Burn Down Charts. Что эти линии означают? Верхняя — сколько мы сделали историй пользователей, нижняя — количество story point. Такие графики автоматически строятся во многих системах для трекинга задач.
Как их читать? Если ваш график находится над линией идеального Burn Down, то вы отстаете, медленно работаете. Тогда к концу спринта будет не ноль задачек или story point, а где-то 20—25. Можно в Excel построить тренд или регрессию и посмотреть, сколько у вас получится задач с такой скоростью — очень просто и наглядно. Если команда видит, что она идет поверх идеального Burn Down, то надо принимать меры. На практике обычно получается вот так.
Идут небольшие отставания, но это у хорошей команды. Другой вариант встречается реже, когда Burn Down ниже диагональной линии. Это означает, что вы идете с опережением, то есть, скорее всего, вы просто взяли мало задач.
Очевидно, что надо увеличить объем работ. В крайнем случае, здесь можно еще снять задачки, но это повод обсудить на ретроспективе, почему у вас так получилось. Этот график — артефакт, который можно в конце двухнедельной итерации проанализировать и сделать выводы.
Примеры Scrum-практик: доски задач
Обычно в Scrum используют доски задач, хотя они не являются обязательным элементом. Команда распределяет задачи по отдельным этапам и размещает на доске в виде отдельных карточек. Есть электронные реализации досок задач, плагины для JIRA и т.д. Задачи упорядочиваются по степени важности. Когда команда собирается с утра, обновляются статусы задач, их переносят на другие этапы, смотрят, есть ли где-то затыки.
Примеры Scrum-практик: обзор спринта
На этой встрече по мере возможности участвуют все заинтересованные стороны: разработчики, пользователи, служба поддержки, системные администраторы и т.д. Обзор спринта нужен для того, чтобы запустить цикл обратной связи. Вы показываете владельцу продукта разработанный инкремент. Он смотрит, делает замечания, вносит предложения, отдает их вам обратно в бэклог. Вы берете в работу, создаете новый инкремент, через одну-четыре недели показываете и снова получаете дополнительные изменения в требованиях. То есть запускаете цикл, который в итоге приведет вас к продукту, который хочет получить его владелец.
Примеры Scrum-практик: ретроспектива
Ретроспектива нужна для постоянных улучшений. Гуру менеджмента Эдвард Деминг когда-то сказал, что совершенствоваться необязательно, выживание — дело добровольное. Ретроспектива — как раз тот этап, на котором вы можете заняться совершенствованием. Как это происходит? Вся команда собирается и обсуждает все ступени до самой ретроспективы. Обычно это длится от часа до четырех, может длиться даже день. Если вы посмотрите олдскульные книжки, там есть ретроспектива даже на несколько дней.
Начинается ретроспектива с открытия. Обычно она занимает 5% времени. Задача — растормошить всех присутствующих на ретроспективе, потому что очень часто в командах, особенно айтишных, присутствуют не очень общительные люди, но порой имеющие блестящие мысли. Задача ведущего заключается в том, чтобы разговорить этих людей. Второй этап — сбор данных, он занимает до половины времени. Команда ищет какие-то факты. Их можно вспомнить, достать из трекера, распечатать. Также можно собрать статистику по багам, кто репортил, каков их статус — вариантов множество. После сбора фактов начинается мозговой штурм: нужно понять, в чем проблема, проникнуть в суть, сгенерить идеи, которые помогут ее решить. На это уходит до трети времени. Например, если у нас много мелких багов, возникающих не на уровне интеграции системы, а в коде разработчиков, то можно предложить использовать модульное тестирование. Если у нас очень плохое качество, как его улучшить? Можно попробовать парное программирование, какие-то инструменты, которые делают автоматизированную проверку кода, еще что-то. Обычно набирается 5—10 идей. Далее нужно воплотить эти идеи в жизнь. Мы не можем сразу внедрить code review, разработать какие-то инструменты. Поэтому выбирается максимум одна-две идеи, реализацию которых надо запланировать на следующий спринт. После этого благодарим всех и закрываем ретроспективу. А еще через две недели можно оценить, получилось у нас это или нет, изучить другие проблемы.
На ретроспективе можно также понять моральный дух команды — для этого тоже есть инструменты. Можно просто начертить временную линию спринта, чтобы каждый член команды вспомнил, что происходило в этот день, наклеил стикер с фактом «закончил разрабатывать задачу», «исправлял быдло-код», «применил новую технологию Machine learning». После этого по каждому факту можно внизу нарисовать, насколько этот факт был для человека интересным, или, наоборот, отстойным. После этого построить медиану, которая отразит состояние и динамику морального духа команды.
Есть такое понятие, как «Цикл Деминга». Он состоит из четырех этапов: Plan — Do — Check (Study) — Act.
После этого можем вносить изменения: например, хотели сделать покрытие 50% — сделали, количество багов уменьшилось, но они еще остались — давайте поднимем до 70%. Или сделали 70%, цикл прокрутили второй раз, проверяем — улучшилось. Давайте сделаем 90%. Еще раз прокрутили: количество багов не уменьшилось, а затрат на написание и поддержку тестов получается много. Давайте сделаем более слабую границу. Благодаря этому циклу команда постепенно улучшает какую-то часть процессов. Самый простой вариант ретроспективы — Real-Time Board Service.
Команда вешает стикеры, что ей понравилось, что нет, а что нужно улучшить. Здесь могут быть как мысли вслух: «Все сделали. Это очень круто», «Самостоятельная команда», «Команда маленькая — не нравится», так и технические вещи. На основе этого можно выдвинуть идеи и некоторые из них отобрать на реализацию.
Напоследок о Scrum
Надо сказать, что Scrum, как и все гибкие методологии, лучше работает в командах, которые сидят в одной комнате. Тем не менее в сети можно найти сотни презентаций о том, как применять гибкие методологии в распределенных командах, когда люди работают на удаленке. Здесь идея такая: вместо реального общения максимально использовать программные и аппаратные инструменты. Что обычно используют? Во-первых, общий трекер, что-то типа JIRA. Это действительно помогает. Популярны программистские чаты, например, HipChat. Для общения — Skype, Hangout. Главное, чтобы была видеосвязь, и чтобы можно было демонстрировать экраны своих компьютеров.
Kanban
Это вторая по популярности методика. Ряд компаний работают одновременно по Scrum и Kanban, получается Scrumban. Наверное, это один из будущих трендов. Историческая справка: Kanban появился в Японии. Этим словом называлась бумажка с пул-запросом на какие-то действия. Например, мне нужна какая-то деталь, на нее делается отдельный канбан. Но в IT это все-таки применяется немножко в другом виде.
Ценности и принципы
В айтишном виде Kanban появился в 2010 г., то есть это достаточно свежая, хорошо описанная методология. Ее автор — Дэвид Андерсон. В следующем году, скорее всего, выйдет обновленная версия методологии. Если Scrum подразумевает жестко предписанные процессы, которые должны сломать то, что было в организации до этого, то есть «Так, все мы теперь работаем по спринтам, с утра приходим, стендапимся, в конце спринта показываем демонстрацию», то Kanban подразумевает более эволюционные изменения.
Визуализация
Обычно используется та же самая доска, что и в Scrum. Самый простой вариант — прото-Kanban. Поток задач разбивается на отдельные этапы. Что-то находится в плане, что-то в аналитике, что-то в разработке, что-то в тестировании, что-то мы уже сделали. При этом реализуется принцип ограничения количества одновременно находящихся в работе задач — WIP (Work in Progress). Есть формула Литтла, которая связывает скорость прохождения задачи в такой системе и количество одновременных задач. Чем меньше WIP, тем быстрее задачи проходят цепочку. Допустим, у нас завал в тестировании, а разработчик сделал следующую задачу. Он видит, что у тестировщиков проблема. Тогда разработчик помогает им что-то сделать, или они идут к руководителю и говорят: «Нам нужен еще тестировщик».
Обычно команда начинает с большого ограничения задач в работе, например, не более двух задач на человека. Если у меня один тестировщик — две задачи для разработки, если четыре тестировщика — восемь задач. Постепенно общее количество задач уменьшается, скорость работы возрастает. И доска уже выглядит примерно так.
Здесь есть те же самые WIP, внизу — критерии готовности (Definition of Done). Столбец делят на две части: «в работе» и «выполненное». Иногда доску делят на дорожки и размещают WIP по горизонтали. Это уже более продвинутая, полноценная Kanban-система. Каждая дорожка соответствует определенному классу обслуживания. Например, есть горячие задачи, когда к вам прибегает начальник и говорит: «Надо сделать это быстрее». Это отдельный класс обслуживания, под него стоит забронировать WIP.
Как и в Scrum, здесь тоже можно создавать диаграммы. Обычно их называют «Диаграммы кумулятивного потока». По горизонтали отмечено время, по вертикали — количество задач. Разными цветами показаны разные этапы. Я упоминал, что улучшение нужно осуществлять на основе цифр, используя научный подход. Эти цифры можно извлечь из диаграмм. Самые важные из них — WIP, то есть количество задач за исключением запланированных и выполненных. Мы его должны сокращать.
Вторые важные критерии — Cycle Time и Lead Time. Определения бывают разными, нужно очень внимательно смотреть. Эти два числа показывают, насколько быстро задачи проходят через вашу Kanban-систему.
В данном случае Lead Time включает в себя ожидание, то есть как воспринимают вашу Kanban-систему заказчики. Cycle Time — насколько быстро задача проходит через Kanban-систему без ожидания, в общем бэклоге. Оба параметра нужно уменьшать, тогда ваша система будет работать быстрее.
Kanban очень хорошо приживается в компаниях с корпоративной командной культурой, когда есть какая-то иерархия. Scrum удобен для команд, которые уже хорошо общаются, в компаниях с плоской структурой, где мало начальников.