Что такое poclac в agile
Обзор методов agile
Я назову этот текст обзором методов agile, расскажу как выбирать между agile и каскадной методологией разработки, дам ссылки на подробные статьи и книги о методах, так как каждую часть этого обзора можно писать как отдельную статью. Буду писать иногда сумбурно, иногда субъективно. Я не журналист, который стремится показать разные точки зрения. А мудрый читатель с высокоразвитым критическим мышлением придет к своему «правильному» ответу. Поэтому, точка зрения авторская. Любые совпадения считать верными, додумки и стереотипы точными. Шутка.) Главной задачей ставлю себе написать простым языком для начинающих знакомиться с миром Agile. Тем более я сейчас сам начинающий продакт-менеджер, учусь в product University. Когда буду давать ссылки на разную литературу и источники, увы много на английском. Зато прокачаете язык. Для будущего продакт-менеджера — это хороший навык.
Начнем с истории методов. Я привык читать и слышать бизнес истории о том, как много работали и придумывали методы. Много табличек, экспериментов, компаний пилотников. После всего, через 100500 лет, появилась методика, которую внедряли, через жуткое сопротивление сотрудников, полусуициидальные настроения топов и т.д. История про Agile, по-моему, вообще не про это. В начале стоит сказать, что Agile — это не метод, а группа методов управления проектами. Что самое крутое, большинство методов появилось раньше самого семейства agile.
Оговорочка: то, что в себя включает Agile не всегда именно метод, это может быть подгруппа, свод правил, набор инструментов и, Боже упаси, фреймворк.
Все методы раскрывать не буду. Если вдруг сюда попадут спецы, есть ссылки на литературу, можно зачитаться. Мне важно раскрыть самые распространенные из них и показать хронологию событий.
1. 1992 – Crystal Methods. Позже в 1997 году упростили до Crystal. Скажем спасибо Алистеру Коберну, за его идеи в своём подходе, потому что именно они легли в основу начала движения Agile. В его методе мы также можем увидеть основы agile-манифеста, о нем чуть позже. Его подход базировался на принципах разумного улучшения, частой поставке кода и работа в группах 6-8 человек, активной коммуникации в группе разработчиков.
2. 1993 – Refactoring. Об этом методе можно прочитать в оригинале жми сюда
3. 1994 – Dynamic Systems Development Method (DSDM). Разработан консорциумом и отличнно раскрыт здесь
4. 1995 – Scrum and Pair Development. Вот он мой любимчик. Основан Джефом Сазерлендом и Кеном Швабером. Но здесь важно еще упомянуть одного человека — Майк Бидл (Mike Beedleв оригинале), который продвинул идеи SCRUM в массы. И по сути именно этот метод больше всего ассоциируется с Agile, а иногда даже считается синонимом.
5. 1997 – Feature Driven Development (FDD). Под эту методологию есть целая книга ссылочка.
6. 1999 – Adaptive Software Development и снова книга
7. 1999 (или 1996, по разным источникам) — XP (экстремальное программирование) книга и сайт. Этот метод дал нам User Stories и релизы.
8. 1999 — The Pragmatic Programmer — опять книга. Эта методология нам дала понимание early adopters (ранних последователей)
9. 2001 — Выпуск agile-manifesto. Вот ссылка на сайт, где опубликован сам манифест и история его создания. А также, воспоминания Мартина Фаулера, одного из соавторов о создании манифеста. Были еще несколько публичных заметок участников, но что-то пошло не так и теперь домены не доступны.
10. 2002 — Test Driven Development (TDD). Книга, как же без нее. Спасибо, за то что это методология дала нам сначала тест, потом уже в боевую версию.
11. 2003 – Lean Software Development (интересная аббревиатура получится). Бережливая разработка ПО. Прекрасная книга ссылка.
Каждый из этих подходов имеет своего автора или группу авторов. Каждый из них творил что хотел, но в целом они все очень умные и классные парни.
1. Люди и взаимодействие важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с клиентом важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.
1. Наивысшим приоритетом является удовлетворение потребностей клиента, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима. 11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы
Классная инфографика на эту тему от scrumteck
Хотя авторы под ценностями подписали, что считают важнее то, что слева, но не стоит забывать о том, что с права. Я же писал, что они умные. Некоторые эти принципы и ценности трактуют буквально. Я сталкивался с тем, что ПО работает, все хотелки клиента удовлетворены, никто не следил за документацией и все счастливы, мы в agile.
Интересно наблюдать баталии в комментариях к статьям последователей и противников Agile. Одни считают это заповедями на скрижалях, другие покушением на инженерную святыню, к которой притронулись садомиты.
Что же круче? Agile — как единственный метод разработки ПО и новый метод работы любого бизнеса в современном мире. Или whaterfalls — как фундамент и единственный метод правильного построения бизнеса и ПО. Я расскажу чуть позже.
Пока писал эту статью узнал о том, что оказывается гуляет в интернетах версия манифеста 2.1. Но это тема отдельного трактата.
Как мы видим широко прижились scrum, kanban, lean. Даже есть scrumban, дитя любви scrum и kanban. Симпатичный получился метод.
Как писал выше, ассоциируется с agile, почти что синонимы. Scrum — это регбийный термин, обозначающий борьбу за мяч.
Коротко о методе. Разработка делится на спринты, короткие дистанции разработки фиксированной длительностью 1-4 недели, наверняка есть и другие. У спринта есть стадии: 1. ежедневные короткие встречи, где обсуждается что сделано, что будет сделано, какие проблемы. Эти встречи не должны длиться часами. Как правило это 15-20 минут. 2. процесс разработки, 3. демонстрация, 4. ретроспектива — переосмысление того, что можно сделать лучше. Важно знать. Есть backlog — список требований к продукту. Есть роли, нет должностей. У srumteck есть классная инфографикана эту тему
Эти два метода имеют общую ДНК. Уходит все корнями в Японию, философию бизнеса Кайдзен и Тойоту.
Про Канбан я нашел упоминания от 1959 года. Этим методом стремились повысить прозрачность процессов производства, вовлеченность сотрудников и их мотивацию, организовать таким образом процесс непрерывного улучшения. Главный момент в Канбане — визуализация процесса, канбан-доска. Где есть шаги, статусы, коридоры и задачи. Принципы: вовлеченность всей команды, строгий контроль времени выполнения.
Ну, и конечно классная инфографика для наглядного примера и резюме.
Lean. Мне трудно его описать как метод, для меня это больше способ мышления, свод правил и рекомендаций. Эта философия бизнеса и подхода к разработке описана в двух книгах Эрик Рис Lean startup и Масааки Имаи Кайдзен.
Характерным для Lean будет:
1. Устранять в продукте все, что не приносит ценности клиенту.
2. Самый эффективный инструмент решения задач — постоянное обучение команды
3. Принятие решения как можно позже.
4. Быстрая доставка изменений.
5. Основа успеха в сильной команде.
6. Экономия ресурсов достигается через изначально качественный продукт.
7. Важна целостная картина. Придание ее частям целей, контроль статусов и видение общей стратегии развития ПО.
Scrumban. Совмещение Kanban и Scrum. Это когда в процессе спринта используется канбан-доска для визуализации работы над задачами.
Мы разобрали некоторые методы agile. А что такое watrefalls или каскадный метод разработки ПО, пока нет. Исправим это. Это последовательная разработка ПО, где компетентные и умные сотрудники все делают без привлечения клиентов. Только полностью завершив производство показывают продукт. Как автомобиль демонстрируют и продают клиенту только после того, как он готов. Кузов без обшивки и покраски ведь не показывают, и если что-то не так, не вносят корректировки. Каскадный метод был предложен в 1970 году Уинстоном Ройсом. Некоторые наметки agile были и раньше предложенного Ройсом метода. В тоже время каскадный метод стал гораздо более распространенным, чем agile. Это связано с тем, что раньше порог входа в любой бизнес и в разработку в частности был очень высок. Нужно было быть терминатором на каждом этапе. Соответсвенно, и мания величия участников высокая — как так допустить неучей-клиентов к инженерному производству. Сейчас огромные скорости обучения и выхода новых продуктов. Пользователь имеет большой опыт и требования, сценарии взаимодействия другие, код проще писать, колоссальный массив знаний в открытом доступе. Да и многие поняли, что команда сильнее самого крутого терминатора (даже если отдельно это не самые лучшие специалисты). Спасибо Аристотелю с его Метафизикой, спустя столько веков въехали, что он имел ввиду.
Ранее упоминал, что забавно наблюдать баталии сторонников и противников обоих методов. Каждый приводит убедительные аргументы и не слышит другого. Все правы и никто не прав. Хвала вселенной, которая послала нам модель cynefin.
Согласно изречению Эдварда Деминга, потребитель – самый главный элемент производственного процесса.
И что? Потребитель есть разный, где-то он знает что хочет, где-то не знает. Есть производитель, который близок к своему потребителю или далек. Знает как удовлетворить потребность или не знает. Много всяких условий и контекста.
И у нас возникает определенный конфликт. Waterfalls — традиционный подход к проектам с длительным планированием или Agile — где все быстро и все меняется со скоростью света.
Товарищ Сноуден, не тот о котором можно подумать, а Дейв, в начале 2000х разработал удобную управленческую модель для работы с проектами. Эта модель успокоила фанатов традиционных способов управления проектами и сбила спеси с любителей agile. В эту модель укладывается всё, уживаются рядом и waterfalls и agile.
В модели описываются 4 вида систем с разной степенью неопределенности:
Как объяснить бабушке, что такое Agile за 15 минут с картинками
«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера
Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.
Это Пэт, владелец продукта. Она не знает технических деталей, зато обладает видением общей картинки, знает, зачем мы делаем продукт, какие проблемы он будет решать и для кого.
Это заинтересованные лица. Они будут использовать продукт, поддерживать его или будут как-то еще вовлечены в разработку.
Это пользовательские истории. В них выражены пожелания заинтересованных лиц. Например, «у системы бронирования авиабилетов у пользователя должен быть поиск по рейсам».
У заинтересованных лиц много идей, и Пэт помогает сделать из идей пользовательские истории.
Это команда разработчиков. Те, кто будет строить рабочую систему.
Пропускная способность
Так как команда использует гибкую методологию разработки, они не копят все эти истории до большого релиза, наоборот, они выпускают их сразу и как можно чаще. Обычно они выпускают 4-6 пользовательских историй в неделю. Это их пропускная способность. Ее очень просто измерить — количество пользовательских историй за 7 дней.
Некоторые истории большие, их можно считать за две, некоторые маленькие, их можно считать за половину.
Для того чтобы поддерживать этот ритм и чтобы не завязнуть в ручном регрессивном тестировании, команда усиленно работает над автоматическим тестированиеми постоянной интеграцией. Поэтому на каждую фичу приходится писать автотесты, и большая часть кода имеет встроенные автотесты.
Проблема заключается в том, что заинтересованных лиц очень много и их запросы невозможно удовлетворить 4-6 историями в неделю.
Каждый раз когда мы реализуем пользовательскую историю, у них появляется еще несколько идей, из которых вытекает еще больше запросов.
Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.
Допустим, команда возьмется сделать 10 новых историй за эту неделю.Если на входе 10 а на выходе 4-6, то команда будет перегружена. Будет спешить, переключаться между задачами, терять мотивацию, в итоге снижается производительность и качество. Это заведомо проигрышная стратегия.
Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”
Задача владельца продукта в том, чтобы грамотно выбирать, какие именно пользовательские истории будут реализованы на этой неделе.
Kanban рекомендует ограничиться несколькими задачами — WIP limit. Допустим команда решает, что 5 — это приемлемое количество пользовательских историй, над которыми они смогут работать одновременно без перегруза, не перескакивая с одной на другую.
Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.
Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.
Есть только один способ держать список задач под контролем — это слово “нет”
Это наиболее важное слово для владельца продуктом. Он должен тренировать его каждый день перед зеркалом.
Сказать “да” — легко. Но более важная задача — решать, что не надо делать и нести за это ответственность. Владелец продукта так же определяет последовательность, что делаем сейчас, а что позже. Это сложная работа и выполнять ее следует вместе с командой разработки и минимум одним заинтересованным лицом.
Для того, чтобы правильно расставить приоритеты, владелец продукта должен понимать ценность каждой истории и ее объем.
Принятие решений
Некоторые истории крайне необходимы, а некоторые просто бонусные фичи. На разработку одних историй уйдет пару часов, на разработку других — месяцы.
Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи — вот что помогает Пэт расставлять приоритеты.
Как владелец продукта определяет ценность и объем истории? Никак. Это игра в угадайку. И лучше в ней участвовать всем. Пэт постоянно общается с заинтересованными лицами, чтобы знать ценность каждой истории, общается с командой разработчиков, чтобы знать объем работ, но все это приблизительные догадки, никаких точных цифр. Вначале всегда будут промахи и это нормально. Гораздо большую ценность представляет общение, чем сверхточные цифры.
Каждый раз когда разработчики выпускают что то новое, мы узнаем больше информации и можем лучше ориентироваться.
Одной приоритезации недостаточно. Чтобы выпускать истории быстро и часто, нужно разбивать на кусочки, которые можно сделать за пару дней. Мы хотим чтобы в начале воронки были маленькие и четкие истории а в конце — большие и неопределенные. Вовремя делать такую разбивку мы можем воспользоваться нашими последними открытиями относительно продукта и нужд пользователя. Это все называется очистка Backlogа.
Пэт проводит встречу по очистке Backlogа каждую среду с 11 до 12. Обычно на ней собирается вся команда и иногда несколько заинтересованных лиц. Содержание встреч бывает разным. Фокусировка на оценке, на разбивке историй, на критериях приемки.
Владелец ИТ-продукта должен постоянно со всеми общаться
Матерые владельцы продукта выделяют 2 компонента успеха: страсть к работе и общение. Какие задачи владелец продукта решает месте с командой.
Баланс между сложностью разработки и ценностью пользовательской истории
На ранней стадии балансу угрожает неопределенность и сразу несколько рисков.
Риски
Бизнес риск: «Правильную ли вещь мы делаем?»
Социальный риск: «Сможем ли мы сделать то что нужно?»
Технический риск: «Будет ли проект работать на данной платформе?»
Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»
Знание можно рассматривать как противоположность риску. Когда неопределенность большая, мы фокусируемся на приобретении знаний — прототипах интерфейса, технических экспериментах,
Компромисс между ценностями знания и ценностями для клиента
С точки зрения заказчика кривая выглядит вот так:
С точки зрения ценности для заказчика эта кривая выглядит вот так. По мере того как неопределенности снижаются, мы можем концентрироваться на ценностях для заказчика. Мы знаем что и как делать. Остается только сделать. После того как реализовали основные истории, будем делать бонусные фичи или запускать новый проект.
Компромисс между краткосрочным и долгосрочным мышлением
Что реализовать в первую очередь? Срочно устранять ошибки или начать разрабатывать сногсшибательную фичу, которая поразит пользователей. Или делать сложный апгрейд платформы, который ускорит работу в будущем. Необходимо постоянно соблюдать баланс между реактивной и проактивной работой.
Делать правильные вещи, делать вещи правильно или делать быстро?
В идеале — все три одновременно, но в реальности приходится выбирать.
Предположим мы здесь. Пытаемся создать идеальный продукт с помощью идеальной архитектуры. Если мы потратим много времени, мы можем не попасть в «маркетинговое окно» и у нас появятся проблемы с деньгами.
Мы делаем быстро прототип продукта. Для краткосрочной перспективы это неплохо. В долгосрочной — мы получаем технический риск. И скорость разработки снизится до нуля.
Мы вот здесь, создаем прекрасный храм в рекордные сроки. Но пользователю не нужен был храм, ему нужен был жилой фургон.
Между ролями в Scrum существует здоровое противостояние
Владелец продукта фокусируется на построении правильных вещей. Команда фокусируется на том, чтобы строить вещи правильно. Scrum-мастер или agile-тренер фокусируется на сокращении цикла обратной связи.
Отдельно стоит подчеркнуть важность скорости, так ккак короткий цикл обратной связи ускоряет обучение. Это позволяет нам быстрее узнавать какие вещи правильные и как их правильно построить.
Компромисс между разработкой нового продукта и улучшением старого
Продукт никогда не может быть полностью завершен, потому что ему постоянно нужны изменения. Когда команда начинает работу над новым продуктом, что происходит со старым? Передача продукта от одной команды к другой — очень затратно и рискованно. Обычно команда поддерживает старый продукт, разрабатывая новый. Поэтому скорее понятие “Backlog” относится не к продукту а к команде. Backlog — это список вещей, которые хочет владелец продукта от команды. И набор историй для разных продуктов. Владельце продукта нужно постоянно выбирать актуальные для реализации.
График уничтожения историй
Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.
Два тренда — оптимистичный и пессимистичный (можно на глаз). Расстояние между трендами показывает насколько нестабильна скорость работы команды. Со временем эти тренды стабилизируются и конус неопределенности будет уменьшаться.
Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?
Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.
Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.
Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»
Обычно лучше уменьшать содержимое проекта, чем увеличивать время. Если мы уменьшаем содержание, у нас будет возможность отодвинуть сроки. Мы можем выпустить кое-что здесь, а остальное — позже.
Владелец продукта делает расчеты еженедельно и использует исключительно эмпирические данные, а не выдает желаемое за действительное. Он честно говорит о неопределенности. Команда поддерживает темп работы, а Пэт не давит на них, заставляя ускориться.
Несколько команд
Пусть у нас несколько владельцев продукта и несколько команд. Модель та же — управление пропускной способностью, коммуникация с заинтересованными лицами, принятие решений по поводу отклонения пользовательских историй. Скорость равна сумме скоростей всех команд. Прогнозирование может быть общее или по каждой команде. У владельцев продуктов появляется дополнительная задача — общение с другими владельцами продукта. Нужно организовать работу над Backlogами так, чтобы минимизировать зависимости и обеспечить синхронизацию. В больших проектах требуется Главный владелец продукта (CPO), чтобы синхронизировать всех остальных.