Как объяснить бабушке, что такое Agile за 15 минут с картинками / Edison corporate blog / Habr

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера
Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.

Перевод сделан при поддержке компании EDISON.

В зависимости от проекта мы успешно применяем каскадный или гибкий цикл разработки.

Роли

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

Пропускная способность

Так как команда использует гибкую методологию разработки, они не копят все эти истории до большого релиза, наоборот, они выпускают их сразу и как можно чаще. Обычно они выпускают 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 Product Ownership in a nutshell

видео на английском

видео на русском

habr.com

Что такое Agile-подход и зачем он нужен бизнесу? — статья в блоге ScrumTrek

Agile («аджайл») — слово, которое последнее время звучит из каждого утюга. Но что такое Agile и, главное, зачем этот Agile нужен?

Если открыть толковый словарь, например, Оксфордский, то можно прочитать там, как минимум, два определения:

1. Able to move quickly and easily.
2. Able to think and understand quickly.

То есть, чтобы быть agile, надо уметь быстро и легко двигаться и быстро соображать. Кажется, довольно полезные качества, особенно в бизнесе. Быстро соображать и быстро реагировать — это именно то, что доктор прописал, для нашего времени, иначе просто не выжить: конкуренты сожрут. В мире всё меньше отраслей, где этих конкурентов, нет. Да ещё скорость копирования практически лишает возможности вывести продукт на рынок и почивать на лаврах. Без способности быстро адаптироваться к изменениям, которую даёт так называемая «методология Agile», выживать всё сложнее.

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

1. Фокусируют команду на нуждах и целях клиентов.
2. Упрощают оргструктуру и процессы.
3. Предлагают работу короткими циклами.
4. Активно используют обратную связь.
5. Предполагают повышение полномочий сотрудников.
6. Имеют в своей основе гуманистический подход.
7. Не являются конечным состоянием, а, скорее, образом мышления и жизни.

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

Фокусировка на нуждах и целях клиентов

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

Самое главное, что фокусировка на клиенте при Agile-подходе появляется не в одной только голове владельца бизнеса (она там и так уже есть), а у всех, кто работает над созданием продукта или сервиса. Каждый участник процесса должен понимать, кто клиент, чего он хочет, какие его проблемы мы решаем своим продуктом, что он любит, чего боится и так далее. Такая всеобщая фокусировка позволяет создавать на порядок более качественные решения. Я неоднократно сталкивался с ситуацией, когда люди, раньше отвечавшие за какой-то маленький кусочек работы, поняв цели клиента, начинали выдавать замечательные идеи, а люди, которые отвечают за разработку продукта, с удивлением за ними записывали. Или — как на групповых сессиях проработки продукта подобные идеи оттачиваются разными людьми и дополняют друг друга, из просто хороших превращаясь в отличные. И, конечно, как они потом реализуются.

«Инструменты работы» в данном случае — это непродолжительные по времени, но насыщенные сессии (встречи) всех участников работы или ключевого большинства, где происходит генерация и тестирование различных идей. Эти же встречи служат для выравнивания понимания и фокусировки: все участники встречи на выходе понимают, что они делают, зачем, и почему это важно для клиента. А демократичный формат воркшопа, в отличие от скучных презентаций, гарантирует большее включение и мотивацию всех участников.

Примеры подобных инструментов — Lean Canvas, Impact Mapping, User Story Mapping и другие Agile-методы описания гипотез и процессов.

Упрощение оргструктуры и процессов

Один из краеугольных камней Agile — это предельная простота. И оргструктура организации, и процессы, по которым работают люди, и правила должны быть настолько простыми, насколько это возможно. Это позволит людям сфокусироваться на своей работе, на ценности, которую они создают, а не на соблюдении регламентов и правил. Прекрасные примеры такого подхода можно найти во множестве команд, работающих по Scrum — самому популярному способу организации рабочего процесса в Agile. Фактически, все договорённости и правила команды в 10-11 человек, текущие задачи на пару недель, цели, а также стратегические планы легко могут поместиться на 2-3 листа бумаги А0. На одном листе может быть так называемый «бэклог спринта», перечень всего, что команда собирается сделать в ближайшую итерацию. Если повесить такой в помещении, где идёт работа, можно избавить себя от необходимости всё это запоминать. То же самое касается и процессов. Скажем, в Скраме место и время проведения всех встреч жестко фиксируются. Любой участник точно знает, что, например, в понедельник в 10-00 планируется ближайшая итерация, а в пятницу в 17-30 — встреча по улучшению процесса работы.

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

Примеры упрощения (и уплощения, но это тема отдельного разговора) в Agile — Scrum, Nexus, LeSS (Large-Scale Scrum, или Скрам на больших масштабах), а также сам Agile-манифест.

Работа короткими циклами

В мире Agile не принято запираться в мастерской на три года, чтобы точить там что-то интересное. Очень уж велик риск, потратить море сил и времени на то, что никому не нужно или устарело.

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

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

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

Ещё одно преимущество такого подхода, помимо раннего выхода на рынок и внесения изменений на ранних стадиях работы, — это возможность более точно измерять прогресс. Мы не просто «сделали 15% всей работы», что довольно абстрактно. Мы «сделали 15% функционала», который уже работает.

Все процессные подходы в Agile имеют короткие циклы, будь то упомянутые ранее Scrum, Nexus, LeSS, SAFe или XP, плюс необходимость работы такими циклами упомянута и в самом манифесте Agile.

Активное, системное использование обратной связи

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

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

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

Примеры, опять-таки, есть везде: ретроспективные встречи в Scrum, Kanban, Nexus и LeSS, циклы I&A в SAFe, подход к созданию продуктов Design Thinking, циклы обратной связи в DevOps и т.д.

Повышение полномочий сотрудников

Зачем давать больше полномочий, когда можно дать бумажку с инструкцией? Есть, как минимум, три причины это делать.

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

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

В-третьих, это всё та же скорость. Если человек может сам, на своём месте, никого не спрашивая, решить какую-то проблему, это сокращает время принятия решений. Не надо больше отправлять вопрос «вверх» и ждать ответа от менеджмента. Это преимущество не так заметно, если у вас работает 3 человека, но если вас 30, или 300, или 3000… В больших организациях, построенных сугубо на иерархическом принятии решений, паралич воли может быть довольно частым явлением.

Популярные способы построения работы в Agile, особенно базирующиеся на фреймворке Scrum, предполагают систему самоорганизованных команд и поощряют лидерство на любых уровнях.

Гуманистический подход

Зачем относиться к людям по-человечески? То есть, моральная сторона дела ясна, а какую пользу это принесёт владельцу предприятия?

Ответ довольно простой. Если создание того, что вы продаёте, не требует умственного труда, а только механический действий — можете не заморачиваться. Просто платите соразмерно сделанной работе, и всё. Но как только в дело вступает мозг работников — придётся считаться с принципами мотивации умственного труда. А они говорят, что для людей важны возможность самореализации, повышения своего мастерства, принесения чего-то ценного в мир, самостоятельности в решениях и ещё ряда факторов. И человек мотивированный (не путать с человеком простимулированным!) будет вкладываться в работу сильнее, и результат будет качественнее и быстрее. Да и в целом, приятная обстановка на работе добавляет желания туда приходить и работать — с этим тоже вряд ли кто поспорит.

И, что приятно, если копнуть в тот же Скрам, то окажется, что все ключевые факторы мотивации работника умственного и/или творческого труда в него уже включены. В каждой итерации («спринте») мы ставим цель, которой хотим достичь; нам даётся возможность решать, как именно достигать цели; в конце мы смотрим, насколько мы стали лучше (или хуже) работать, чем раньше; видим людей, которые заинтересованы в продукте, и их эмоции от знакомства с ним. Особенно хорошо, если эти эмоции положительные.

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

Agile — это не конечное состояние, а образ мышления и жизни

Этот пункт о том, что применение Agile в целом — путь, а не цель. Нельзя «внедрить» Agile и расслабиться. Если вы выбираете этот путь, у вас всегда будет что-то ещё, что можно сделать лучше, какой-то ещё вызов, которому надо ответить, какая-то ещё проблема, которую надо решить, ещё одна высота, которую надо покорить… Это движение бесконечно, потому что нет идеального процесса или продукта, развитие и конкуренция не останавливаются никогда, как никогда не прекращается борьба за выживание в природе.

И если всё удалось: люди в компании понимают и разделяют ценности и принципы Agile и работают согласно им, — тогда менеджменту не придётся «тащить» на себе любые изменения или «пинать» работников, чтобы они начали что-то делать по-другому. Предприятие станет единым организмом, управление которым будет отнимать меньше сил и приносить больше удовольствия.
А там, где больше удовольствия от работы, и результат выше. Это касается не только специалистов, но и менеджмента, причём в ещё большей степени.

На этом наше обзорное знакомство с принципами Agile заканчивается. Какие цели ставятся перед Agile в России и каких реальных результатов достигают компании, переходящие на гибкие методологии, можно узнать, познакомившись с отчётом исследования ScrumTrek об использовании Agile в России от 2017 года.

scrumtrek.ru

AGILE – гибкая система управления проектами

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

Однако существенно упростить работу над проектом и научиться им управлять, тем самым повысив эффективность команды, можно при помощи системы гибкого управления проектами под названием Agile («Аджайл» или «Эджайл»). Вообще, мы уже вкратце рассказывали о ней в нашем курсе по управлению проектами (четвертый урок), но сейчас поговорим на эту тему более подробно.

Метод Agile: определение и краткая история

Как бы непривычно это ни звучало, но серьезно разрабатывать программное обеспечение и управлять проектами начали уже в 70-х годах прошлого века. Именно в 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии (как, например, делается в автомобильном производстве), где новые детали по очереди добавляются в последовательные фазы.

Вместо того чтобы ждать, пока будут поочередно завершены все этапы (фазы), Ройс предложил применять фазовый подход. Суть его в том, что изначально собираются все требования, необходимые для проекта, после чего завершается вся архитектура, создается дизайн, записывается код и т.д.

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:

• В 1991 году появился метод быстрой разработки приложений RAD
• В 1994 году появился метод разработки динамических систем DSDM
• В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
• В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
• В 1997 году появилась итеративная методология разработки ПО FDD

Все вместе эти методы объединились под общим названием гибких методов разработки ПО.

Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.

Манифест Agile

Манифест, созданный программистами, включает в себя 4 базовых идеи и 12 принципов эффективного управления проектами. Любая из систем управления проектами на основе Эджайл (о системах мы поговорим позже) опирается именно на эти идеи и принципы, хотя и использует их в разных вариациях.

Идеи Agile:

1. Люди и их взаимодействие важнее, чем процессы и инструменты
2. Рабочее ПО важнее, чем документация
3. Клиенты и сотрудничество с ними важнее, чем контракт и обсуждение условий
4. Готовность к внесению изменений важнее, чем первоначальный план

Принципы Agile:

1. Удовлетворять клиентов, заблаговременно и постоянно поставляя ПО (клиенты довольны, когда рабочее ПО поступает к ним регулярно и через одинаковые промежутки времени)
2. Изменять требования к конечному продукту в течение всего цикла его разработки
3. Поставлять рабочее ПО как можно чаще (раз в неделю, в две недели, в месяц и т.д.)
4. Поддерживать сотрудничество между разработчиками и заказчиком в течение всего цикла разработки
5. Поддерживать и мотивировать всех, кто вовлечен в проект (если команда мотивирована, она намного лучше справляется со своими задачами, нежели команда, члены которой условиями труда недовольны)
6. Обеспечивать непосредственное взаимодействие между разработчиками (возможность прямого контакта способствует более успешной коммуникации)
7. Измерять прогресс только посредством рабочего ПО (клиенты должны получать только функциональное и рабочее программное обеспечение)
8. Поддерживать непрерывный темп работы (команда должна выработать оптимальную и поддерживаемую скорость работы)
9. Уделять внимание дизайну и техническим деталям (благодаря эффективным навыкам и хорошему дизайну команда проекта получает возможность постоянного совершенствования продукта и работы над его улучшением)
10. Стараться сделать рабочий процесс максимально простым, а ПО – простым и понятным
11. Позволять членам команды самостоятельно принимать решения (если разработчики могут сами принимать решения, самоорганизовываться и общаться с другими членами коллектива, обмениваясь с ними идеями, вероятность создания качественного продукта существенно возрастает)
12. Постоянно адаптироваться к меняющейся среде (благодаря этому конченый продукт будет более конкурентоспособен)

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

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

Ключевые моменты в применении Agile

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

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

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

Особое внимание нужно уделить руководителю проекта. Его нельзя назвать человеком, раздающим указания налево и направо. Руководитель здесь выступает скорее в роли лидера, который задает направление и определяет правила сотрудничества и работы. Другими словами, Agile-управление является адаптируемым.

Еще одним важным моментом Agile-методологии является разделение всего объема проекта на несколько более мелких составных частей. Такой подход многократно упрощает процесс разработки, а отдельные группы команды могут фокусироваться каждая на своей конкретной задаче.

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

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

Если же мы разделим все время, отведенное на проект, на несколько спринтов, получим конкретное их количество; пусть их будет 15. Каждый спринт длится, к примеру, две недели. Вот как раз в течение этих двух недель (времени, отведенного на спринт) участники каждый день встречаются для обсуждения процесса и прогресса.

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

• Что я делал вчера?
• Чем я буду занят сегодня?
• Что мешает мне работать?

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

1. Четко обозначается значение проекта
2. В процессе реализации активно участвует клиент
3. Общий объем работ выполняется пошагово
4. Ориентироваться следует на конкретный результат
5. Численность одной рабочей группы: от 7 до 9 человек

В настоящее время проект-менеджмент с поддержкой Аджайл по большей части распространен в IT-сфере, однако и деловая сфера его начинает осваивать. Эта система применяется в обучении, маркетинге, бизнесе. Гибкое управление проектами берется на вооружение множеством компаний и государственных структур.

Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo (производство печенья), компания Aviasales (крупнейший поисковик авиабилетов), компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк» (наверное, знаете, что это).

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

Популярные методы управления проектами

Существует немало методов проект-менеджмента, которые применяются разными современными компаниями. Но самыми известными и востребованными среди них по праву считаются Scrum (Скрам) и Kanban (Канбан).

Метод Scrum

Среди всех методов системы Agile Scrum отличается тем, что делает основной упор на качественный контроль рабочего процесса. Впервые описавшие его японские специалисты по стратегическому менеджменту Хиротака Такуэти и профессор в области научно-технических знаний Икуджиро Нонака называют метод «подходом в рэгби», где Scrum является «борьбой за мяч».

Метод заключается в том, что разработка проекта разделяется на спринты, по окончании которых клиент получает улучшенное ПО. Спринты строго фиксируются по времени, и могут длиться от 2 до 4 недель. Рабочий процесс в одном спринте включает в себя несколько стадий:

• Определяются объемы работы
• Каждый день проводятся 15-минутные встречи, чтобы члены команды могли скорректировать свою работу и подвести промежуточные итоги
• Демонстрируются полученные результаты
• Спринты обсуждаются для поиска удачных и неудачных решений и действий

В большинстве случаев Скрам применяется в работе со сложным ПО и для разработки продукта с использованием инкрементных и итеративных методов. Благодаря ему серьезно повышается производительность команды и сокращаются временные затраты на достижение цели.

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

Метод Kanban

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

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

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

Это лишь примеры основных методов управления проектами, основанных на Agile. Но не стоит пренебрегать и другими методами, такими как PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall и другие. К тому же у Аджайл, наряду с преимуществами, есть и некоторые недостатки.

Плюсы и минусы Agile

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

В первую очередь стоит отметить, что Agile-управление очень гибкое. Если, например, традиционная методология указывает на конкретные этапы работы, то Эджайл легко подстраивается под потребителя конечного продукта и требования заказчика.

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

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

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

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

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

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

Внедрение Agile

Примеров внедрения Эджайл в работу компаний есть достаточно много. И практически все они говорят, что оно требует целого комплекса важных мероприятий.

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

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

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

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

Заключение

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

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

4brain.ru

Как рассказать что такое Agile на заводе? Топ 5 самых популярных Agile-практик

Если оторваться от Хабра, заглянуть в реальную российскую компанию старше 30 лет и больше чем с тысячью сотрудников и произнести слово Agile, то реакция будет как минимум настороженная. Люди там уже слышали истории похожие на «Как рассказать бабушке» или «Как рассказать дедушке» и посмотрели все выступления Грефа, получили с десяток предложений внедрить гибкость за неделю, кто-то из сотрудников даже поработал год со Scrum, но остается один вопрос:

«Что с этим нам делать то, у нас из программирования только сайт?»

В итоге примерно для 100% компаний Agile смахивает на шарлатанство.

Но вот парадокс — в мире 77% компаний*, использующих Agile в проектах, занимаются совсем не разработкой программного обеспечения.

_{*Из большого ежегодного опроса компаний от VersionOne}

Под катом практика того, как Agile становится понятным в крупных компаниях и проектных командах без разработки. Мы делаем систему управления проектами, но когда общаемся с относительно крупным клиентом напрямую, большую часть времени обсуждаем гибкую методологию и подходы к автоматизации управления проектами. Этим опытом хочется поделиться.

Вместо определения. Что сказать про Agile, когда собрались разные люди из разных отделов

Agile — это не метод разработки программного обеспечения. Википедийные определения плохо годятся для понимания, если ты не разработчик.

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

Команда в игре «Что? Где? Когда?» существует по принципам Agile. Взаимодействиям отдана ключевая роль. Капитан выполняет роль заказчика продукта (верного ответа), 2-3 эрудита перебирают массивы информации, кто-то следит за временем, есть человек, который анализирует, задает вопросы и побуждает общение, любой может высказаться и привести к результату или все провалить, за пределами игры есть разбор полетов (ретроспектива).

Противовес Agile — это конвейерный (каскадный) метод с жесткой иерархией и точными задачами поставленными как можно ближе к SMART. По этим принципам в «Что? Где? Когда?» капитан должен был бы раздавать точные задачи — кому в каком направлении думать и пытаться собрать это в ответ. Каждый участник должен был бы соблюдать приличия и высказываться когда дойдет очередь. В случае провала нужно было бы кому-нибудь понизить мотивацию или уволить и принимать это решение будет капитан.

Главной причиной появления и развития Agile является то, что все больше проектов не имеют 100% понимания, что должно быть в конце. Расписать точные задачи попросту невозможно. И решили, что свободные взаимодействия важнее инструкций, а готовность к изменениям важнее планов.

Гибкие методологии — это ответ на неопределенность; до конца неизвестно, что нужно сделать и что должно получиться в результате. Казалось бы, а что непонятного в разработке, например, сайта или в строительстве дома или в приготовлении гамбургера в Макдональдсе? Эти проекты поставлены на поток, где неопределенность?

Но. Даже если вы веб-студия и для вас это тысячный сайт, для клиента это первый раз. И его желания останутся неопределенностью до самого конца. Многие студии делают 3-4 варианта главной страницы и закладывают неделю на непредвиденные доработки. У всех, кого я знаю, работа разбита на итерации, после каждого есть демонстрация и обсуждение. Общение с заказчиком важнее подписанного контракта.

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

Хорошо, в изготовлении гамбургера в Макдональдсе нет никакой неопределенности. Процесс отработан за 70 лет и воспроизведен в 125 странах. Да, это конвейер, куда лучше не влезать с гибкостью. Agile не применим в хорошо отлаженных годами процессах. Правда, открытие нового ресторана по очень точной франшизе — это всегда уникальный проект. Где к месту будет итеративный подход, сокращение итераций, распределение ролей, открытое взаимодействие, визуализация проекта на Agile-доске, ретроспектива, ежедневные планерки.

Итого ключевые ценности Agile (манифест):

• свободное взаимодействие в команде
• результативность проекта (классный продукт)
• партнерское общение с клиентом
• готовность к изменениям

Что такое команды с ролями?

В привычной команде есть две роли: Начальник и Подчиненный, один умный другой дурак. В Agile принципиально важны три: Заказчик продукта, Методист, Участник команды.

В упрощенной форме:

Заказчик — рассказывает какой продукт нужен, для чего он нужен, устраивает обсуждения вокруг запросов с рынка, принимает решения по приоритетам.
Методист — следит за тем, чтобы заказчик не превратился в начальника. Ну и еще за выполнением остальных практик, например, чтобы все задачи были с оценкой или чтобы оценки задач не превышали 80% от имеющегося времени, если есть такая договоренность.
Команда — оценивает, распределяет и реализует задачи. Всегда демонстрирует версию продукта, а не отдельные выполненные кусочки.

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

Со стороны гибкая команда от привычной отличается именно наличием или отсутствием так называемого повествовательного диалога (narrative collaboration).
Если идет обсуждение вопроса «Как реализовать продукт?» на всех уровнях, значит команда гибкая. Если ищут кто виноват, что не выполнен список конкретных задач, значит все как обычно.

Главный вопрос: «Как управлять ресурсами когда все так гибко?»

Все эти рассказы про ответственные команды и истории появления метода воспринимаются как полная фигня, если нет ответа на вопросы:

«А как точнее управлять ресурсами?», «Как раньше понять, что в проекте ресурсов стало не хватать для окончания?», «Мы всегда ставили и распределяли задачи по исполнителям и могли прогнозировать результат, а что теперь?». Что бы рассказать про Agile, можно раскрыть только этот вопрос.

Надо отметить, что вообще весь Agile сконструирован именно для решения вопроса с ресурсами «Как эффективно управлять ресурсами в проекте с непредсказуемостью» Методология бы не родилась, если главной задачей был бы комфорт и свобода людей в команде.

Есть несколько важных принципов и методов, явно направленных именно на прогнозирование ресурсов:

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

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

2. Приоритеты и бэклог. При планировании учитывается, что не все задачи удастся закрыть за выделенный отрезок времени. Всегда есть список того, что надо сделать обязательно и того, что сделать хорошо бы (это и есть бэклог). Приоритеты проставляет команда в обсуждении с внутренним заказчиком продукта. Если так случается, что остается время, решаются задачи второй степени важности, если не успевают закрыть даже задачи с отметкой Обязательно (Critical) команда напрягается дополнительно.

3. Короткие итерации (спринты). Этот подход, как никакой другой позволяет компаниям пробовать что-то из Agile. Руководство согласно на промежуточный результат через пару недель без того, чтобы влезать и всем проставлять задачи. Согласиться на такой режим работы на полгода было бы невозможно.

Спринт (итерация) — это отрезок времени в несколько недель. У нас чаще всего это 2 недели. Самое важное в спринте — это определение того, какой промежуточный результат должен быть получен. Этим результатом хорошо называть итерацию, например, «Выпуск досок с правами» или «Выпустить сайт на тест». Если работа идет по отрезкам времени, но каждый отрезок не приводит к какому-то конкретному результату, то это уже не итерационный подход.

4. Оценка задач в размерах футболок. Люди не слишком любят давать точные оценки задачам, но оценивать примерно, по шкале большая, средняя, маленькая для большинства нормально. Ниже самые популярные в мире способы оценки задач без высокой точности. С процентами по частоте использования.

Мы используем третий, но оценки бывают только 1h, 2h, 4h, 8h.

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

5. Burndown chart (график сгорания)
Очень простая вещь — это график с двумя линиями; первая — сколько времени сгорело и это всегда прямая, на второй — сколько задач в пересчете на ресурсы закрыто и тут возможны колебания. Фактически это графический ответ на вопрос идет ли команда по плану или отстает.

Здесь изложены только общие подходы без деталей, возможно, стоит написать отдельный материал с подробностями управления ресурсом. Но если резюмировать здесь в две строчки, то получится:

• самая частая ошибка — попытка попадать в оценки очень точно, команда перестает работать на результат
• самый успешный подход — заложить запас по времени, планировать на 80% ресурсов

Инсайд из самой большой, старой и известной seo-студии в России — они закладывают запас в ресурсах два раза, первый при обсуждении с клиентом, второй при внутреннем планировании.

Топ 5 самых популярных Agile-практик понятных всем

Еще раз подчеркну, Agile на базовом уровне применения — это просто. Нет никаких сверхсложных приемов, которые надо долго изучать. Ниже для примера приведено 5 самых популярных практик (по данным все того же опроса от VersionOne)

Все они применимы в проектах из любой области и достаточно просты для мгновенного использования. Все объединены общей идеей итерационного подхода.

1. Итерационное планирование — спринты (90% команд используют)
Работать небольшими забегами с промежуточным результатом — хорошая практика. Спринт — это несколько недель. Слишком короткие или слишком длинные отрезки — плохо. Одинаковый интервал на все случаи жизни тоже не годится. У спринта должна быть максимально точная цель, исходя из этого и определяется длительность.

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

2. Ежедневные планерки (88% команд используют)
Задача — чтобы каждый день команда подтверждала единое направление движение всех участников.

По классическому описанию каждый в команде раскрывает три вопроса:
Что сделано к этому моменту из спринта?
Что планируется на сегодня?
Какие проблемы возникли или что мешает?

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

Менять время планерки — 6 мес. утром, 6 мес. вечером.
Каждый раз менять ведущего планерки, не должно быть лица перед которым отчитываются. Отличный вариант если ведущий разыгрывается жребием.
Заказчик продукта, делиться историями о клиентах в начале планерки.
Обсуждать общие темы и только потом переходить к вопросам.
Не пускать на планерки никого кроме участников команды.

3. Ретроспективы (83% команд используют)
Совещание в конце итерации. Обсуждение, что получилось, а что не очень. Самая важная цель — сделать выводы о том, как меняться.

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

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

4. Итерационные показы (81% команд используют)
Это демонстрация от команды раз в несколько итераций результатов проекта, как правило, в виде выступления. Главный смысл в том, чтобы была «сессия» и ничего страшного, если это станет похоже на отчетность перед руководством.

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

5. Короткие итерации (71% команд используют)
Смысл в том, что нужно постоянно стараться сокращать цикл получения маленьких промежуточных результатов. Если этого не делать, циклы будут естественным образом расти или будет постоянными, независимо от промежуточных целей. Чем короче цикл, тем меньше ошибок при итерационном планировании.

Это задача методиста, стоит вспоминать про это хотя бы раз в полгода.

Как понять ведется ли проект по Agile-методологии или еще нет?

Диаграмма того, сколько компаний меняют Agile под себя выглядит так:

Гибкость подхода распространяется и на сам подход. Это первое, что стоит узнать команде, если им предстоит стать гибче. Нельзя быть на 100% Agile, выполняя все предписания. Никто строго не соблюдает правила в чистом виде, на практике у каждой компании есть свои модификации.

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

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

Комбинация гибкости и жесткости всегда индивидуальна и зависит от множества факторов: руководителя, сложности проекта, размера команды, бюджета и тд. Но если осмысленно внедрен хоть один подход, то эта компания работает по Agile-методологии и будет не лишним гордо сообщать об этом внутри коллектива.

P.S. Опрос: Agile в России 2017

В статье приводится несколько фактов о распространении Agile в мире, взятых из опроса от компании VersionOne.
Проблема в том, что эти данные имеют мало общего с нашей действительностью.
Мы в YouGile проводим большой опрос о гибкой методологии в России.

Примите участие — пройдите опрос «Agile в России 2017»
10 вопросов, 3 минуты

Результаты обязательно будут опубликованы на Хабрахабр.

habr.com

Agile/Scrum для начинающих. Что такое гибкая методология?

Что такое Agile и Scrum?

Что такое Agile?

В переводе с английского языка «agile» означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «agile» понимают набор подходов по “гибкой” разработке программного обеспечения.

Agile Manifest

Суть agile-подхода изложена в “манифесте”, но для заказчика ее можно коротко сформулировать так:

• разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;
• в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;
• команда разработки сотрудничает с Заказчиком в ходе всего проекта;
• изменения в проекте приветствуются и быстро включаются в работу.

В настоящее время agile-принципы используются в работе десятки тысяч команд по всему миру.

Основополагающие принципы Agile.

Краткое видео о том, что такое Scrum (english).

Что такое Scrum?

Scrum – это одна из нескольких методологий гибкой разработки ПО:

• • Scrum
  • Lean
  • Feature Driving Development
  • Extreme Programming

Scrum процесс на одном листе

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

Артефакты в Scrum

В скрам используется всего четыре артефакта:

• Product Backlog
• Sprint Backlog
• Sprint Goal
• Sprint Burndown Chart.

Я рекомендую вам посетить наш тренинг “Scrum для проектных команд“. Тренинг помогает изучить Scrum-процесс от начала и до последних нюансов.

Product backlog:

• Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
• Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
• Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
• Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

На снимке ниже представлен Backlog проекта. Команда проекта выбрала 2 требования в Sprint#3.

Project Backlog (JIRA)

Sprint backlog:

• Это список всех требований, которые нужно сделать в ближайший спринт.
• В течение спринта, новые требования не могут появится в Sprint backlog.
• Все требования должны быть разделены на задачи и оценены.

Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на Kanban-доске.

Kanban Доска в Спринте

Sprint Goal

• это краткое описание того, ради чего выполняется данный спринт.
• цель на спринт помогает команде принимать обоснованные решения.

Этот артефакт необходим для того, чтобы команда проекта могла самостоятельно принимать решение в случае появления альтернативных путей решения задачи. Чтобы решения команды были осознанными, Product Owner определяет цель спринта.

Sprint Burndown Chart

• дословно “диаграмма сгорания”
• в качестве “сгорающих” элементов выступают человеко-часы или идеальные единицы (Story Points).
• диаграмма обновляется каждый раз, когда завершается какая-либо задача.

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

Burndown диаграмма в Jira

Если есть время, посмотрите мою запись о книгах, которые можно скачать для изучения Agile/Scrum.

Роли в Scrum

В скрам используется всего три роли:

• Product Owner
• Scrum Master
• Team.

Роль Product Owner

• формулирует требования
• приоритезирует требования
• корректирует приоритеты на каждом спринте
• несет персональную ответственность за ценность требований для рынка/пользователей
• отвечает за взаимодействие с рынком
• только один человек

Product Owner – это представитель подразделения, которое владеет разрабатываемым продуктом. Например в банке это может быть Департамент карточных продуктов. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

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

В некоторых случаях допустимо назначить более одного человека на роль Product Owner. Но в этом случае необходимо назначить среди них “главного”, который будет авторизовать требования в Bcaklog’e и лично расставлять приоритеты.

Роль Scrum Master

• следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
• организует работу команды и обеспечивает её всем необходимым
• защищает команду, несёт ответственность за её эффективность
• только один человек.

Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет “администратор”. Скрам Мастер организовывает работу команды проекта, но не вмешивается в её работу.

• Скрам мастер не назначает людей на задачи – это делает сама команда;
• Мастер не заставляет людей делать работу – это ответственность команды;
• Мастер не указывает Product Owner какие требования он должен написать – это работа владельца продукта.

Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

Функции Scrum Master’a существенно шире, но чтобы пояснить их все нужна отдельная статья. Пишите в комментариях, если таковая нужна.

Team (команда проекта)

• кросс-функциональная
• взаимозаменяемая
• самоорганизующаяся
• с фиксированным составом (в ходе спринта)
• 4-10 человек.

Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

• продолжительность спринта
• емкость (capacity) команды
• размер её фокус фактора (коэффициент слаженности)
• трудоемкость требований, которые будут реализованы в спринте
• очередность выполнения задач и много другое.

Команда НЕ принимает решений:

• какие требования являются приоритетными – это делает Product Owner.

На снимке ниже команда проекта проводит обязательный “ритуал” – Daily Meeting (см. ниже).

Команда проводит “ритуал” Daily Meeting

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

Ритуалы (процессы в Scrum)

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

Ритуалы в скрам это:

• Sprint Planning Meeting
• Daily Meeting
• Sprint Review
• Retrospective

Sprint Planning Meeting (встреча по планированию спринта)

• выполняется всей командой перед началом спринта
• команда выбирает требования из Product Backlog и формирует Sprint Backlog
• если требуется учесть взаимосвязи между операциями, то это делается здесь
• команда декомпозирует требования на задачи (tasks)
• каждая задача проходит оценку в трудозатратах или универсальных единицах
• во время встречи Product Owner отвечает на вопросы команды.

Встреча, которая проводится перед началом каждого спринта. Структура встречи:

• представление и пояснение Product Owner’ом списка требований
• вопросы со стороны команды
• /рекомендуется перерыв/
• декомпозиция требований на задачи (tasks)
• оценка задач по методу Planning Poker.

Встреча простая по сути, но крайне сложная по содержанию. В начале проекта может занимать 5-6 часов. И только после 3-4 спринта встреча становится более оперативной и длится 2-3 часа. Крепитесь.

Daily Meeting (ежедневная встреча команды).

Из названия понятно, что встреча проводится ежедневно. Основные принципы:

• проходит ежедневно и только в одно и то же время;
• встреча проходит только стоя;
• поэтому длительность встречи не более 15 минут;
• чтобы успеть каждый должен ответить всего на 3 вопроса: что я делал вчера, чем я занимаюсь сегодня, какие есть проблемы?

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

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

Встреча команды эффективно проводить напротив Kanban доски, на которой отражены все задачи спринта.

Kanban Board во время спринта

Sprint Review – сдача спринта Product Owner

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

Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

Структура встречи:

• команда зачитывает требования из Sprint Backlog
• по каждому критерию приемки происходит демонстрация полученных результатов
• каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
• каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

На встрече могут присутствовать любые сотрудники организации или просто заинтересованные лица. Важно, чтобы право голоса имели только участники Scrum процесса (Produt Owner, Team, Scrum Master).

Никаких презентаций в PowerPoint на встрече, если вы правильно меня поняли!

Retrospective

Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.

Методика проведения встречи варьируется в зависимости от проекта, его команды и просто традиций в коллективе. Тем не менее, должны быть озвучены ответы на следующие вопросы:

• какие решения должна принять команда, чтобы сделать процесс более предсказуемым?
• какие проблемы мешают команде выполнять взятые на себя обязательства?
• как улучшить взаимодействие с Product Owner’ом?
• какие ошибки совершает команда и почему.

Решения должны быть записаны на отдельной доске. После всеобщего голосования решения принимаются к исполнению со следующего спринта. Scrum Master контролирует ход встречи и следит за её регламентом.
Ознакомьтесь со списком наших курсов по управлению проектами.

Почему появился Agile?

Теперь немного слов о том, как и зачем появился этот подход? История возникновения этого подхода стала ответом на запросы отрасли:

1. Заказчик не может сформировать четкие требования к ПО;
2. Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе;
3. Заказчики и разработчики ПО не удовлетворены процессом взаимодействия.

#1 Заказчик не может сформировать четкие требования к ПО

В начальной фазе проекта заказчик не может сформулировать исчерпывающие требования к продукту. Этому есть несколько причин:

• у Заказчика существует только идея приложения и он не представляет всю его функциональность;
• у группы проекта есть разный взгляд на функциональность приложения;
• команда не может договориться, как же будет удобнее/разумнее реализовать ту или иную часть функциональности приложения.

Один из принципов Agile гласит «Используйте прототипы и делайте поставки продукта как можно чаще». Это позволит снять неопределенность в требованиях и проверить, как с ней будут работать реальные пользователи.

В традиционных «водопадных» моделях руководитель проекта минимизирует изменения в проекте, используя для этого отдельные процессы – управление изменениями. Но если требования будут меняться раз в месяц, то управление изменениями становится трудоемким и замедляет ход проекта.

В Agile реакция на изменения важнее, чем следование плану. В Agile приветствуется, когда заказчик и пользователи вносят новые требования, чтобы сделать продукт более конкурентноспособным.

#2 Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе

К середине 90-х разрабатываемое ПО было в основном десктопным и его требовалось устанавливать на каждый отдельный компьютер (например, MS Word). С появлением веб-приложений внедрение новой функциональности стало происходить быстрее: требовалось развернуть приложение только на сервере и все пользователи получали к нему доступ. Эта инновация серьезно усилила конкуренцию между компаниями: тот, кто применил новую технологию раньше других – выигрывает рынок и клиентов.

Подход Agile предоставил бизнесу главное преимущество – быстрые поставки новой функциональности. Это позволило каждый месяц выпускать продукт и оперативно получать обратную связь от пользователей.

#3 Заказчики и разработчики не удовлетворены процессом взаимодействия

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

Основная идея agile – сотрудничество с заказчиком важнее, чем контрактные обязательства. И поэтому agile-методы стремятся к уменьшению объема документации. Это позволяет Заказчику платить только за результат, имеющий ценность для бизнеса.

При этом agile не отказывается от формулирования требований. Заказчик (в agile – владелец продукта, product owner) предъявляет требования в упрощенном виде и на сценариях работы пользователей.

Резюме

Agile-философия проста. Agile-принципы разумны. Но переход к реальному применению agile – это серьезный вызов для каждой команды. Требуется не только освоить новый подход к управлению проектами, но также подобрать людей, способных работать в agile режиме.

0 91 100 36 Закрыть

Большое спасибо, что нашли время написать отзыв!

• Содержание статьи

• Актуальность информации

• Содержание статьи

• Актуальность информации

Очень познавательно

• Содержание статьи

• Актуальность информации

Понятно,доступно,емко,спасибо.

• Содержание статьи

• Актуальность информации

Спасибо! Все изложено в доступной форме!

• Содержание статьи

• Актуальность информации

Очень содержательно и последовательно!

• Содержание статьи

• Актуальность информации

Thanks a lot for your article! It was very helpful to me.

• Содержание статьи

• Актуальность информации

• Содержание статьи

• Актуальность информации

• Содержание статьи

• Актуальность информации

• Содержание статьи

• Актуальность информации

Очень информативно и структурировано!

• Содержание статьи

• Актуальность информации

www.pmoffice.by

кратко о методологиях Agile / ИТ Гильдия corporate blog / Habr

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

Но все принимаемые решения нужно как-то «синхронизировать». Один из резидентов Hacker News отметил, что ему приходилось наблюдать за тем, как пяти сотням разработчиков в одной крупной компании разрешили самостоятельно принимать некоторые решения в «отрыве» от команды. По его словам, это был хаос. И хотя команда начала работать быстрее, она двигалась в никуда, потому что позднее возникали проблемы на этапах поддержки ПО.

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

Поэтому мы решили начать серию постов о «гибких» методологиях, чтобы еще раз рассмотреть их особенности, сравнить варианты и помочь вашим компаниям оптимизировать процессы. Сегодня мы говорим о Scrum, канбан и экстремальном программировании.

/ Flickr / Sebastian Sikora / CC

Scrum

Scrum — это фреймворк гибкой разработки ПО, который считается методологией «по умолчанию». Для многих является синонимом Agile. По статистике за 2016 год, предоставленной VersionOne, Scrum используют 58% «гибких» компаний. При этом её поддерживают многие SaaS-платформы. Например, решение ServiceNow, частью которого является инструмент Agile Development.

Методология была разработана в конце 80-х — начале 90-х годов. Процесс управления состоит из фиксированных коротких итераций — спринтов (sprints).

Используя методологию Scrum, представитель заказчика плотно работает с командой разработки, расставляя приоритеты в списке требований к продукту (Product Backlog). Этот список состоит из баг-фиксов, функциональных и нефункциональных требований — из всего, что нужно сделать для реализации рабочего приложения.

Функциональные элементы, добавляемые в бэклог, называют историями. Каждая задача оценивается в определенное количество очков. Очки являются абстрактной метрикой и для её оценки могут использоваться самые разные шкалы (например, ряд Фибоначчи или степени двойки).

На основании списка требований заказчика команда определяет функции, которые хочет реализовать, и начинает свой спринт. Обычно он длится 30 дней. В конце подсчитывается общее количество очков, набранных командой за спринт (скорость). Это позволяет более четко планировать следующие спринты.

За последние десять лет программисты Кен Швабер (Ken Schwaber), Майк Бидл (Mike Beedle) и Джефф Сазерленд (Jeff Sutherland) приложили множество усилий для развития Scrum. Кен Швабер — наиболее активный сторонник фреймворка, и его сайт — хорошее место, чтобы начать свое знакомство с методологией. Он также выпустил книгу.

Scrum за все время существования приобрел огромную популярность и используется командами разработчиков даже в крупных компаниях. Однако сообщество за это время выявило и определенные её недостатки.

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

Однако здесь скрывается проблема: поскольку работа разработчиков оценивается в баллах, они будут стараться заработать их побольше и оптимизировать под это свою деятельность. Что не приводит к улучшению кодовой базы, не делает её проще.

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

Что касается неизменности историй во время спринта, то в больших масштабах это также приводит к проблемам. У программистов нет возможности перераспределить работу при обнаружении новых особенностей. Scrum не позволяет перестраивать корабль прямо во время плавания, поэтому приходится ждать окончания сессии, чтобы внести изменения.

Extreme Programming

Особенность Scrum заключается в том, что этот фреймворк уделяет мало внимания практикам разработки. Поэтому некоторые agile-компании (порядка 10%) комбинируют его с экстремальным программированием (XP).

Экстремальное программирование привлекло к себе внимание в конце 90-х. Концепция зародилась в сообществе Smalltalk, а её авторами считаются разработчики Кент Бек (Kent Beck) и Уорд Каннингем (Ward Cunningham), которые хотели сформировать новые практики в разработке ПО, сделанные для людей.

Первым проектом, созданным по методологии Extreme Programming, стала система контроля платежей Chrysler Comprehensive Compensation (C3) в середине девяностых. Сам термин «экстремальное программирование» появился в 1997 году.

Концепция строится на основании двенадцати приёмов:

1. Разработка через тестирование (Test-driven development)
2. Игра в планирование (Planning game)
3. Заказчик всегда рядом (Onsite customer)
4. Парное программирование (Pair programming)
5. Непрерывная интеграция (Continuous integration)
6. Рефакторинг (Design improvement)
7. Частые небольшие релизы (Small releases)
8. Простота проектирования (Simple design)
9. Метафора системы
10. Коллективное владение кодом (Collective code ownership)
11. Стандарт оформления кода (Coding standard)
12. 40-часовая рабочая неделя (Sustainable pace)

XP сильно напоминает Scrum и предполагает, что заказчик плотно взаимодействует с командой разработчиков, расставляя приоритеты (истории). Программисты также оценивают, планируют и реализуют задачи короткими итерациями.

Однако Extreme Programming делает сильный упор на тестирование, что отличает её от Scrum. Методология гласит, что разработчик не может сказать, что код написан правильно до тех пор, пока не пройдут все модульные тесты. Поэтому часто XP идет рука об руку с техникой разработки Test Driven Development (TDD), когда сперва пишется тест, а затем логика для его прохождения.

Но такая «тестоориентированность» одновременно и недостаток подхода. Чтобы адаптировать XP, нужно инвестировать в создание инфраструктуры автоматизированных тестов и непрерывного развертывания ПО.

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

/ Flickr / U.S. Army / CC

Канбан

Scrum по-прежнему остается эффективной методологией, которая пользуется популярностью. Особенно в комбинации с экстремальным программированием. Вместе их процент использования среди Agile-команд достигает 68%.

Однако сегодня многие команды рассматривают иные варианты и обращают внимание на другие методологии. Одной из них стал канбан. CTO ConvertKit Грант Аммонс (Grant Ammons) говорит, что компании сперва адаптируют Scrum, который учит их необходимым дисциплинам для разработки ПО, а затем ищут более удобную альтернативу и обращаются к канбану.

Канбан — это техника для управления разработкой, где процесс разработки рассматривается как конвейер с запросами на реализацию функций, с которого сходит улучшенное программное обеспечение.

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

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

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

Однако, как отмечают в сообществе HN, у такого подхода тоже есть определённые недостатки. В том же Scrum короткие спринты положительно сказываются на мотивации разработчиков. Программисты знают, что работа над продуктом закончится, когда весь список требований на 30 дней будет выполнен. В случае с канбаном — это постоянный и нескончаемый поток заданий. Однако есть выход — краткое обсуждение списков задач на неделю (или две).

Также ввиду своей специфики, канбан плохо подходит для долгосрочного планирования и неудобен в работе для крупных команд разработки (больше пяти человек).

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

P.S. Еще несколько статей из нашего корпоративного блога:

habr.com

Что такое Agile — методология управления проектами

Вадим Гринёв из LeadStartup, от 24 декабря 2019 г.

Agile в управлении проектами — это применение принципов гибкой разработки в проектном менеджменте с высокой степенью неопределенности и рисков.

Agile (англ. – проворный) – это семейство «гибких» подходов к разработке программного обеспечения.

Многим до сих пор непонятно это слово. Давайте разберёмся и поймём, что это не страшно, а даже классно и полезно.

Agile – не методология!

Это не пошаговый алгоритм действий. Последовательность, очерёдность, хронология – эти термины можно отнести к водопадному подходу в работе. Там есть цикл, и в нём мы двигаемся по его фазам.

На стадии инициации проекта нужна большая часть информации о производстве продукта. Чем ближе к нулю времени, тем больше гипотез и меньше результата.

«Водопадный» подход описывает метафора автономной подводной лодки, которая уходит в плавание в Северный Ледовитый океан. Загрузили команду, продукты, отдано боевое задание. Всё готово, инструктаж проведён, и лодка ушла под лёд на 3 месяца. Там она что-то делает-выполняет без всякой связи с внешним миром. Через 90 дней экипаж прибывает обратно и отчитывается о проделанной работе.

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

Нам проще и быстрее понять, что нужно сделать по-другому

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

Мы привыкли мыслить водопадными проектами

Хотя они основаны на мнимой вере в результат. Нам кажется, если мы за один раз сделаем всю работу, и больше к ней не будем возвращаться, то так будет лучше. Но у Вселенной не всегда такие же планы, как у нас. Поэтому нам нужны соответствующие инструменты решения задач, которые учитывают (по крайней мере, всеми силами пытаются это сделать) переменные факторы.

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

Совсем не обязательно в конце одной маленькой итерации отдавать клиенту что-то работающее. Смысл в получении обратной связи. Можем показать просто упаковку без продукта внутри. За счёт отклика клиента появится множество возможных вариантов что-то исправить.

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

Поговорим о некоторых тонкостях внутри Agile

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

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

Ребята сделали аналоговый макет стартовой страницы магазина на маркерной доске, поставили рядом с ней человека, который ловил мимо проходящих и просил их протестировать ассортимент, цены, внешний вид сайта. Так предприятие получило много комментариев путём устного анкетирования. Очень быстро и дёшево.

Обратная связь – самое важное, что нужно получать как можно быстрее. Какие бы проекты мы не делали.

Cтруктурная составляющая проекта

В традиционной команде есть руководитель проекта, который за него отвечает. У него есть исполнители, которым нужно раздать задачи: что и в каком объёме сделать. Но не существует управленцев, которые могут создать идеальный план, который будет точь-в-точь совпадать с реальностью.

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

В современном мире «люди-руки» уже изживают себя. Даже в таких крупных индустриальных предприятиях, таких как Северсталь или Сибуре, обычные исполнители не нужны. Если человек не думает, он не приносит ценности. Лучше его роботизировать. Поэтому нужно создать такие условия, при которых будет максимальная вовлечённость и высокая ответственность за конечный результат. Тогда руководитель будет не нужен. Совсем.

У команды должен быть тот, кто её вдохновляет, направляет к цели и говорит, куда и зачем они идут. В Agile-сообществе он часто называется Product Owner (владелец продукта). С ним «люди-руки» становятся «людьми-головами». И для них ВП создаёт такие условия, в которых они могут договариваться. Никто в Agileе не отменяет бюджеты проекта, его сроки. Пусть люди ежедневно встречаются по 10 раз и решают, кому и чем лучше заняться сейчас, чтобы был максимальный результат.

У Agile-команды чаще возникают неорганизационные вопросы

Её интересуют вопросы по продукту, который они будут совместно делать. И ответы знает человек, который понимает, что они создают.

Представьте, что нужно внедрить SAP (автоматизацию бизнес-процессов) и получить на выходе какую-то бизнес-ценность: уменьшить количество ошибок или операций.

Как мы привыкли поступать?

Сначала описываем все требования и отдаём их на разработку подрядчику. Он у себя что-то делает, тестирует и возвращает нам. Готовый результат мы тестируем уже у себя, потом внедряем. Внести изменения в него в случае неудовлетворённости уже сложно, потому что деньги уже уплачены.

Как применить Agile в этом случае?

Очень просто! Есть огромное количество бизнес-процессов, которые можно автоматизировать. Мы даём подрядчику недельный план, в котором указываем, что наиболее важно в данный момент.

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

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

Как быть, если не хватает бюджета на единовременный контракт?

Мы можем договориться с подрядчиком о передаче специалистов в наш офис. Пусть они на месте делают автоматизацию бизнес-процессов. А мы будем платить не по fix-price контракту, а месячную зарплату.

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

Почему это сложно сделать в крупной компании?

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

Например, мы Agile-команда. Мы понимаем, что получим согласование на разработку продукта через 2 недели. Тогда пытаемся командно придумать, как получить одобрение быстрее.

Как правило, есть возможность ускорить реализацию за счёт личных взаимоотношений. Поверьте, это возможно сделать и в Сбербанке, и в Газпроме – компаниях с очень сильной бюрократией. «Люди-руки» получат ответ только через 2 недели, поэтому они не могут конкурировать в эффективности с «людьми-головами».

Как же переходить на новый подход?

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

В Сбербан

leadstartup.ru