Обзор методов 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 (интересная аббревиатура получится). Бережливая разработка ПО. Прекрасная книга ссылка.

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

И вот почему.

В феврале 2001 года большинство основателей разных методологий, указанных выше, собрались на горнолыжном курорте Сноуберд в Юте. Первоначальной идеей было создать одну самую крутую методику разработки, такую чтобы все ей пользовались, мир был лучше и ИТ двигало всю планету. Что уж там происходило известно только участникам: секс, наркотики и рок-н-ролл или заседание великих умов планеты. Факт в том, что это были 17 успешных в своей области мужчин в самом расцвете сил на курорте. По итогу дебатов, появился манифест — свод 4 ценностей и 12 принципов разработки ПО. На этом и порешали, назвали его Agile — от английских слов быстрый, гибкий, проворный, динамичный, ловкий и т.д. В России прижилось «гибкий».

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 вида систем с разной степенью неопределенности:

1. Упорядоченные простые

2. Упорядоченные сложные

3. Комплексные

4. Хаотичные

Упорядоченные простые.

Здесь понятны: цель, результат, ресурсы, есть опыт у команды, понятен контекст задачи.

Например: производство чего-то простого, например, мебели. Методы управления: каскадный, waterfalls.

Упорядоченные сложные.

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

Например: запуск ракеты, строительство многоквартирного дома.

Методы управления: PMBok, Prince2, PMI

Комплексные системы.

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

Пример: стартап

Методы: scrum, другие методы agile.

Хаотичные системы.

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

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

Я пообщался с двумя людьми из разных сфер и с разным опытом.

"Мы традиционно работали по каскадной модели, начиная с 90х годов. Имеем огромную ветвистую структуру. Где по большей части общаются на уровнях, middle менеджмент с middle менеджментом, линейные сотрудники с линейными. Данная структура позволяет достичь предсказуемого результата. Но для мотивированных и идейных сотрудников это представляет собой проблему. Как бы ты не лез из кожи вон, на каком-то уровне ты столкнёшься с усреднением. На твою идею не бросят все ресурсы, а усреднят как функцию. Поэтому развитие будет таким же, как у всех.

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

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

За полгода внедрения, по моим наблюдениям, продукты развиваются лучше, выросла скорость производства, повысилась ответственность. Безусловно из-за перестроения есть люди, которые уходят, они не готовы к изменениям. Приходят новые, с ними проще. Работаем".

Мы поговорили с ним о его опыте работы в сфере авиасообщения, финансовом секторе РФ, ритейле и финансовом секторе международном.

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

«Тут использовали scrum. На уровне бизнеса и теоретическом уровне, может как-то работало, а на уровне разработки нет. Был слабый product owner, сосредоточенный на дизайне, прогибающийся под бизнес, и по сути за полгода ничего не произошло. Больше и рассказывать нечего».

«Сначала мы пошли по scrum. Но постоянно смещались релизы, мы не уделяли внимания техническому долгу, цели спринта были часто размыты. Постоянно бизнес вставлял хотелки, которые не позволяли выпустить вовремя релиз. Нам добавили scrum master. У нас стало получаться лучше, спринт шел по классике 2 недели, но проблема с бизнесом осталась. Появлялись хотелки »срочно-важно«. Через какой-то момент scrum-master нас покинул, но мы уже готовы были работать самостоятельно. Попробовали перейти на kanban. В нем нашли компромисс между бизнесом и разработкой, мы стали включать задачи по техническому долгу. Делали ретроспективу. А »срочные-важные« хотелки бизнеса мы выделяли в отдельный коридор. Таким образом у нас было 5 коридоров, с которыми мы успешно справлялись. Мы встраивались в имеющуюся структуру, тут нам тоже отлично подошел Kanban. Наверное, здесь была лучшая реализация гибких методов».

"Работаю сейчас в международном проекте с полностью распределенной командой. Несколько человек в РФ, Украине, США, Доминикане. Мы работает по agile, некой адаптацией scrum. Dailly у нас превратился в weekly, длина спринта 1 месяц. Главная особенность, которую я заметил, очень большая и регулярная поставка бизнес-ценности. Технической реализации внимания уделяется меньше. Риски: все участники должны быть очень высококвалифицированы и мотивированы, для того чтобы это работало. Есть опасения по поводу архитектуры. Все очень лояльны к ошибкам и смещению сроков, но если ты пообещал сделать к какому-то сроку, ты должен привести очень веские аргументы.

Выводы. Все зависит от людей, а не методики. Scrum работает при условии, если вся компания этим живет. Если задача превышает 4 часа, значит, она не до конца декомпозирована".

Добавлю свою историю. Во время работы на стыке ИТ и автобизнеса, собственник бизнеса называл меня бренд-директор, директор по развитию и т.д. А ИТ направление — product owner. Эта неопределенность позиции меня немного смущала. Все дело в том, что моя должность была точкой схождения двух методов управления. Топ-менеджмент работал по каскадной системе, ИТ производство по agile. Скажу, что конфликтов на этой почве была масса. На 5часовых совещаниях ИТ директор под конец убегал с трясущимися руками и воплями «неучи тупые», «что я тут бисер мечу перед свиньями» или «прежде, чем сделать что-то автоматически, продумайте это логически», а управленцы других направлений сыпали "ИТшники криворукие, вся система работает через ж@ #у ". Тем не менее, компания была успешна и являлась лидером в своем сегменте. Вывод за меня озвучил мой собеседник выше.

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

Hewlett-Packard. история про трансформацию направления принтеров laserjet книга, куда без нее, но можно читать в электронном виде. Или статья.

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

Подытожу свой обзорник. Главное — это твоя команда. С крутой командой можно пройти всё.