— закон Хофштадтера
Самый просматриваемый ролик на 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 Product Ownership in a nutshell
Читать еще
2 ноября — самый айтишный день в году
Поддержка публикации — компания Edison, которая разрабатывает электронные системы продаж билетов и федеральный каталог товаров и услуг.
А вот так в Edison разрабатывают продукты по гибкой методологии:
Комментарии (33)
Mixxer
25.10.2016 17:24+1Очень часто руководители занимаются подобной «ерундой», особенно когда проблема в условиях труда и оплате, а не в режиме работы. Тут как не работай, сотрудники работать не мотивированы.
ad1Dima
25.10.2016 21:27Бывает и наоборот, когда начальство занимается "мотивацией" сотрудников, в ущерб постановке процесса. Всего должно быть в меру.
zenkz
25.10.2016 19:54+1Лучшее применение Agile-подобной методологии для меня следующее:
— Ретроспектива не проводится. (Вернее занимает 5 минут при планировании следующего релиза)
— Планирование: долгосрочное — на 1 доставку (обычно около 2х месяцев). Краткосрочное — на этапе разбора задач на спринт
— Спринты — 2 недели.
— Сбор требований и демо заказчику проводит Бизнес-аналитик (в этой модели он для команды Product Owner)
— Стендапы — каждый день или 1 раз в 2 дня (зависит от размера команды и интенсивности работы)
Преимущества такого подхода:
— Минимизируется время совещаний.
— Каждый занимается своим делом (т.е. программисты не тратят время на демо и не общаются с заказчиком напрямую)
Недостатки данного подхода:
— Нужен хороший бизнес-аналитик, чтобы взаимодействие не превращалось в «глухой телефон»
— Чуть меньше виден результат работы для программистов (т.к. они не видят/слышат реакцию заказчика на сделанные изменения). Хотя для меня лично лучший мотиватор — это сданный в срок проект и премия за сдачу проекта.
И самое главное: любая методология потерпит крах, если использовать её с целью «заставить» команду работать (часто с применением репрессивных механизмов). Agile нужен, чтобы иметь чёткую модель взаимодействия в команде и скоординировать работу.
rboots
25.10.2016 21:08+1Agile это не методология, а прилагательное. То, что американцы называют «проворный», «гибкий» (дословный перевод agile), русские возвели в культ и назвали методологией. То же самое, как если бы русское выражение «эффективный менеджмент» какие-нибудь испанцы возвели в культ и хвастались, что следуют методологии «Эффективный». Agile manifesto это не о том, каким правилам следовать, а о том, как достигнуть этой характеристики, сборник практических советов и не более. Тошно читать такие статьи, честное слово.
s-kozlov
26.10.2016 09:42+1Не обращайте внимания, это просто buzzword, вот его и лепят куда надо и не надо.
Genoik
25.10.2016 21:47Возможно меня многие не поддержат, но смотря на современные продукты иногда возникает ощущение, что подобные подходы к разработке далеки от реальности, а применимо все это только в идеальном каком-то мире. Что фичи (как тут сказано) делаются ради фич. Когда делают не то, что реально нужно и просят пользователи, а то, что скажет менеджер продукта.
zenkz
25.10.2016 22:59Поддержу вас в вашем взгляде. Часто после разбивки проекта на фичи, вся команда фокусируется на разработке этих самых фич, но не думает о том как эти фичи будут интегрированы между собой.
Чтобы этого не происходило — у системы должен быть архитектор, который должен видеть систему целиком, а не просто набор фич.
Хороший пример agile-ада — это интерфейс Facebook (а вернее то, как там сделаны настройки) есть меню настроек, есть настройки каждого раздела, есть настройки каждого элемента. Вроде всё красиво и функционально, но абсолютно неинтуитивно для пользователя. Т.е. фичи реализованы, а системного подхода нет.Genoik
25.10.2016 23:16+1Скажу больше, особенно сильно возникает такое ощущение, когда привычный всем интерфейс зачем-то меняют, причем эти перемены не несут в себе каких-то кардинально новых возможностей, а скорее перемены ради перемен. Создается ощущение, что программистов нечем занять, и чтоб не сокращать штат, вводится что-то подобное…
В идеальном мире, который тут описан якобы все фичи и изменения должны идти от самих пользователей, но я, увы, этого не наблюдаю в большинстве случаев.zenkz
26.10.2016 00:15В последнее время интересами пользователя никто не интересуется — все пилят фичи…
То что обновление приложения нельзя отключить уже стало нормой (хотя я никак к этому не привыкну).
Но сегодня, к примеру, мой скайп решил установить обновление и перезагрузиться ВО ВРЕМЯ звонка.
indestructable
26.10.2016 00:45+1Ну это уже проблемы менеджера, а не разработчиков, и уж никак не методологии.
theRavel
25.10.2016 22:34Раздел «несколько команд» очень эпичный, я никогда такого не видел и не представляю как это может у кого-то работать.
Там появляются технические зависимости от других команд, планирование больше невозможно провести на уровне PO, это превратится в митинги с большим количеством участников, оценки будут скакать в зависимости от того насколько подкоманда знакома с модулем, упадет предсказуемость или же подкоманды будут стремиться к технической изоляции, что приведет к разному стилю в разных модулях и бесконечному перекидывает багами.
indestructable
26.10.2016 01:12На мой взгляд, гибкий процесс разработки сам по себе хорош.
Проблемы с ним возникают из-за плохого внедрения.
В методологии есть приемы и техники для каждой роли, и каждый из них дает полномочия и рычаги одной роли, и накладывает обязательства на другую.
Например, ежедневные митинги высоко котируются заказчиком, поскольку дают ему больше осведомленности о процессе, и накладывают обязательства на разработчика по поддержанию определенной скорости разработки и графика работы.
Другой пример: фиксированный объем спринта дает больше свободы разработчикам (они могут работать в более свободном темпе, например, растянуть задачи равномерно на спринт, или напрячься, но освободить день или два), и накладывает ограничения на стейкхолдеров и владельца продукта (вынуждая их подавлять позывы "АААА ПРОСТОЙ РЕСУРСА!!!!!1").
В принципе, любая часть методологии так или иначе "выгодна" одной из ролей, и "невыгодна" другой. ("Выгодна" в кавычках, поскольку цель у команды одна, и выгода одна тоже, но количество усилий и действий может сильно различаться в зависимости от внедренных частей аджайла).
Так вот, к чему я веду: чтобы аджайл внедрился успешно, нужен баланс обязательств и привилегий. Однако, на практике в 90% случаев есть перекос, и угадайте, в чью сторону (посильнее нагрузить разработчиков, и дать побольше инструментов контроля заказчику). В достижении конечной цели это мешает всем, но с точки зрения морали на проекте страдают сильнее всего исполнители, заказчики же получают иллюзию контроля (Опять же, это именно иллюзия, разработчик при желании сможет выкроить себе нужно количество свободного времени, и проверить факт, что он намеренно затянул разработку, невозможно.).
Хуже того, наиболее важные части, такие как приоритезация бэклога, фиксированные спринты, минимизация регрессии при выборе фич, добавление только фич, которые можно использовать по окончании спринта — это все обычно отбрасывается как "неважное" (не дающее дополнительных рычагов менеджменту). Превращение стенд-апов из инструмента координации и информирования в отчетность и инструмент контроля — из той же серии.
В итоге внедряется особый,
галерный"аутсорсинговый" вариант аджайла, который справедливо воспринимается разработчиками как меньшее, конечно, по сравнению с совковым менеджментом, зло, но все же с изрядным скептицизмом.
lamo4ok
26.10.2016 02:35+4В этом уже классическом ролике гораздо быстрее и понятнее объясняется суть agile-метода.
Другие методологии правда тоже не лучше.
Wolonter
26.10.2016 09:46+1ручном регрессивном тестировании
правильно «регрессионном»
«автоматическим тестированием»
правильно «автоматизированным»
Очень ждал увидеть в статье ограничения применимости. Когда нужно применять гибкие методологии, а когда их применять ни в коем случае нельзя. Аналогично — ограничения на размер и состав команды.
nickmarlou
27.10.2016 14:17-1Доброй день, друзья.
Провожу небольшое исследование командной работы для магистерской диссертации. Если работаете в команде, то предлагаю пройти опрос. Занимает минут 7-8, максимум — 10.
https://goo.gl/forms/arPC9tPPxXY3mgNM2
P.S.: Если будут вопросы по методологии. Готов рассказать какие исследования брал в качестве основы.
euroconic
27.10.2016 14:17Извините, но название статьи не соответствует контенту статьи. Не нужно приплетать Agile mindset к методологии разработки SCRUM и вносить путаницу.
lamo4ok
27.10.2016 16:47Ну вы не приплетаете, а вот другие приплетают — погуглите, хотя бы, как взаимосвязаны эти две вещи. Строго говоря, Agile — это манифест, он так в оригинале и называется (в той его версии, в которой он сейчас существует), то есть это просто некое заявление о том, что нужно и можно преследовать в работе командой. А Scrum — это конкретно методология, следующая принципам, объявленным в Agile Manifesto. Собственно, Швабер, который серьезно вложился в формализацию манифеста, а заодно и подписал его с другими 16 разработчиками, впоследствии написал книгу Agile software development with Scrum (в соавторстве с каким-то еще чуваком).
NewsPR
27.10.2016 14:17-1Покажи ей деньги секс радикулит она я думаю сама все поймет! И без слов! )))))
PkXwmpgN
Все Agile-методологии выглядят просто потрясающе: на бумаге, в книжках, в презентациях, на видео.
Но в один прекрасный момент ты осознаешь себя сидящем на 4х часовом митинге, рядом с другими, такими же программистами с грустными глазами и мы все вместе раскрашиваем цветные бумажки, играем в карты и голосуем за фичи "ногами", просто потому что так "веселей".
indestructable
Какая по-вашему идеальная методология?
uniqm
Дак не может быть этой самой, идеальной. В Аджайле есть приятные моменты, для меня это скорость обратной связи и вообще нацеленность на неё. Наличие ответственного за продукт.
Остальное не особо профитное из моего опыта. Оценка задач, а в особенности ПользовательскихИсторий(плохая проработка задачи) — это пальцем в небо (ну когда задачи не точь в точь близнецы прямо). А с этого момента начинается крах подхода, ИМХО.
indestructable
Я только за аджайл, и считаю его передовой методологией сегодня.
Но прочитав комментарий PkXwmpgN я подумал, может я что-то пропустил, и бывают методологии без выматывающих митингов и нелепых действий?
indestructable
Немного уточню: митинги и дурацкие ритуалы можно привнести в любую методологию разработки, к сожалению.
uniqm
Забавно, но мы как то быстро проехали этап выматывающих митингов.
Почти каждый день минут 20 на всех с утра что делал, что будешь. Мне, как аналитику в проекте, очень полезно понимать чем живет команда в данный момент.
Спринт 4 недели, ретро примерно час-полтора, опять же по проблемам вырабатываем пути улучшения и пишем на доске перед глазами.
Планированием занимается руководитель, совещаясь с причастными. Это сильно лучше, чем по началу с картами. Вот там прогеры и тестировщики «помирали», а я точнее чем они оценивал их же задачи =)
PkXwmpgN
А по-вашему существует идеальная методология?
Лично мне близка точка зрения Cord, изложенная здесь.
SleepyTails
Нет идеальной методологии. Идеальная методология как таблетка от всех болезней. Выбор методологии должен определяться исходя из конкретных потребностей проекта и даже изменяться в течении жизненного цикла проекта (если проект не короткосрочный), если у проекта меняются приоритеты.
Aingis
Это ошибка — искать идеальную методологию. Всё зависит не от методологии, а от людей, и в первую очередь от тех, кто принимает решения. Если управление хорошее, то у вас будет успех при любой методологии, нужные процессы сами выработаются в ходе работы. И никакие процессы не спасут плохой менеджмент. Впрочем, проблема качественного менеджмента стоит во всём мире.
P.S. Если что, я не знаю примеров идеального менеджмента в IT — везде есть свои проблемы.
senpay
Мне кажется, ключевая особенность Agile (по русски правильнее говорить не «Гибкий» а «Адаптивный») как раз, в адаптации, в постоянном фокусе на улучшении (кстати, ничего не нашел про ретроспективу в статье, а жаль). В случае, как вы описали, скорее всего именно момент адаптации и постоянного улучшения процесса не учитывается полностью.
Вообще, уже было давно справедливо замечено, что Agile работает не во всех случаях и не у всех команд. Многие внедряют Agile квадратно-гнездовым методом, из серии, «А теперь, в дополнение к delivery, у нас еще будут stand up, planning и retrospecitve, ура!», а на самих этих евентах ничего не происходит, на planning — как сказал PO или SM, так и будет, на retrospective постоянно ищут «кто нафакапил в этот раз», вместо того чтобы думать как не факапить в будущем. В общем, если у вас не работает Agile, может быть вы просто не умеете его готовить? ;)
indestructable
Поддержу.
Особенный случай — это когда инициатива внедрения аджайл исходит от заказчика. Во всех виденных мною случаях это значит daily meeting и все.
s-kozlov
Если у вас не работает универсальная синяя таблетка от всех болезней, которую я вам прописал, может, вы просто не умеете пить?
senpay
Я наверное, не совсем верно выразился, еще раз подчеркну, что я не считаю Agile «универсальной синей таблеткой».
Так что, скорее, метафорически, моя мысль должна звучать так:
1) «если вы пьете таблетку головной боли, когда у вас понос, наверное вы что-то делаете не так»
2) «если вы пьете таблетку от головной боли не руководствуясь инструкцией, головная боль может не пройти»