Что бы мне почитать, чтобы в общих чертах разобраться? например, чтобы понять, стоит ли внедрять Agile в моей организации… Или быть готовым, если что, к работе в Agile команде?
Ну, то есть понятно, что по-хорошему стоит пойти учиться на курсы, но что делать, если к этому пока не готов?...
Давайте попробую дать ответ.
Во-первых, Agile - это общий подход, если хотите, мировоззрение. Кстати, “Agile” и “Гибкие методы управления проектом/продуктом” - это синонимы, если вдруг вы не в курсе. В рамках Agile рассматриваются уже конкретные методики для работы - например, Скрам, Канбан, экстремальное программирование (методики - не очень корректное слово, меня сейчас адепты закидают тухлыми помидорами, общепринятое правильное слово - фреймворк, то есть “структура”, но уж очень оно коряво на русском звучит).
Суть подхода Agile описана в Agile манифесте, который лежит в открытом доступе на всех возможных языках, и с чтения которого я и рекомендую начать.
Все остальные статьи, книги, материалы и прочее по Agile, собственно, от него отталкиваются.
Agile-манифест содержит в себе много довольно очевидных тезисов, с большинством из которых сложно спорить (разве что самоорганизующихся команд многие боятся) - как и с тезисом, что лучше быть здоровым и богатым, чем бедным и больным. Вопрос в том, что из этого следует смещение фокуса внимания и стиля работы. Если совсем кратко - в центре подхода Agile находится работа над сложными продуктами короткими итерациями в самоуправляемых командах в тесном сотрудничестве с бизнес-заказчиком.
Во-вторых, Agile - это один из подходов к реализации проектов (сейчас более принято говорить к созданию продуктов, но я, простите, буду по старинке). И важно понимать, что (согласно теории запутанности Дейва Сноудена по модели Киневин) применять Agile целесообразно, когда у вас достаточно сложный продукт и высокая степень неопределенности. Потому что если с проектом все просто и понятно, Agile избыточен, чего тут усложнять - наливай да пей!..
- Какие вообще бывают подходы к управлению проектами, и как выбрать из них подходящий - я рассказала в статье Можно ли объять необъятное или чем Agile отличается от водопада?
- И логическое продолжение этой статьи: Почему Agile превращается в Тяп-ляп. Кто виноват и что делать?
Если лучше воспринимаются короткие видео - могу порекомендовать на Ютубе Алексея Таченкова: “Подходы к управлению проектами”, “Agile” и т. п. Алексей вообще очень неплохо и доходчиво говорит - не случайно на митапе Инфостарта “Инструментарий руководителя проекта” его доклад занял первое место в рейтинге… Ждем его доклад на ближайшем Infostart Event… Но это я отклонилась от темы.
Если хочется разобраться в Agile подробнее - рекомендую книгу Бориса Вольфсона “Гибкие методологии разработки”. Можно свободно скачать. Книга довольно старая, то есть не надо там искать новейшие методики и т. п., но общую идею, что такое Agile показывает вполне верно. Борис, кстати, нередко выступает на различных конференциях и мероприятиях, когда я выступала на 13-ой конференции Agile Days мы с ним пересеклись, и могу его искренне рекомендовать как хорошего популяризатора.
Выше я уже говорила о том, что Agile - это общие принципы и подход к созданию продукта. А если команда планирует работать по Agile, то она скорее всего выберет конкретную методику (я опять готова ловить тухлые помидоры - но не буду я употреблять слово “фреймворк” в статье под заголовком Agile для чайников, хоть режьте меня).
И в большинстве случаев выбранным методом будет Скрам.
Что почитать про Скрам? Конечно же, начать надо с Руководства по Скрам. Тем более, что буквально в ноябре вышла новая версия Руководства. Это недлинный документ, где четко описываются правила игры:
- Команда - от 3 до 9 человек, 3 обязательные роли (разработчик, Скрам-мастер, Владелец продукта)
- Спринты - промежутки времени от 1 до 4 недель
- Бэклог Спринта и Бэклог Продукта - постоянно пополняемый список требований
- Инкремент - готовый к поставке продукт в конце каждого спринта
- Мероприятия - Планирование Спринта, Ежедневный Скрам, Обзор Спринта и Ретроспектива
Тем, кому проще воспринимать картинку, чем текст - рекомендую короткий мультфильм про Скрам (тоже есть в открытом доступе на Ютуб), который мы всегда смотрим на курсе по управлению ИТ-проектами. В мультфильме есть несколько фактических ошибок, некоторые из них - грубые (в частности, Скрам-мастер не назначает задачи и не порицает лентяев), но лучшего способа за 5 минут объяснить, что такое Скрам - я не знаю.
Если хочется вникнуть в Скрам более подробно и понять его идею, можно почитать “красную книжку” Джеффа Сазерленда “Скрам: Революционный метод управления проектами”.
Но мне, если честно, при внедрении Скрама в первый раз в жизни гораздо больше помогла книжка Хенрика Книберга “Скрам и XP: Заметки с передовой” - доступна в Интернете в открытом доступе на русском языке. Ребята честно поделились, как они внедряли Скрам и экстремальное программирование на практике, что у них пошло, что пошло не очень… Не во всем они соответствуют букве Руководства по Скрам, но зато это живой и рабочий опыт.
Есть некоторое количество общепринятых инструментов и техник, которые не описаны в Руководстве, но часто применяются на практике в командах работающих по Скрам, и не только. Не буду подробно их сейчас описывать, просто упомяну.
- Сбор требований в формате пользовательских историй (user story - Мне, как _____ надо ________, для того чтобы ________ (+ критерии приемки)
- Измерение работы в условных единицах (Стори-пойнты) вместо человеко-часов или денег. Совместная оценка трудоемкости при помощи покера планирования.
- Измерение velocity (скорость или мощность команды) на основе уже выполненных задач. Оценка на Burn down chart (диаграмма сгорания работ)
- Доска, по которой перемещаются задачи (физическая или электронная). Самые популярные инструменты для электронной доски - Jira, Trello, Redmine.
Ну и дальше очевидно - если хочется почитать поподробнее про тот или иной инструмент или практику - да спасет вас Гугл. На английском, как правило, информации больше и она толковее. Но если с английском туго, то на русском тоже достаточно.
Следующий по известности гибкий подход к управлению - это Канбан. Строго говоря, Канбан - это способ работы не только над проектами, повседневную операционную деятельность так тоже можно осуществлять. Канбан (впрочем, как и Agile) относится к подходу Lean - так называемому “Бережливому” подходу. Не путать с Канбан-доской - доска - это просто инструмент (самый популярный из всех инструментов Agile). А Канбан-система - это подход, основанный на ограничении входящего потока задач.
У меня на тему Канбан тоже есть пара статей:
Канбан в условиях российской действительности - про общие принципы Канбан.
Ну и продолжаю тему - описание практического опыта работы по Канбан в немецком банке: Что немцу хорошо, то русскому... Как минимум, небезынтересно.
Если читать всерьез - то читать, конечно, автора методики - Дэвид Андерсон. Канбан: альтернативный путь в Agile.
Скрамом и Канбаном методы Agile, естественно не исчерпываются, их гораздо больше. Но эти самые популярные (если считать еще и их гибрид - Скрамбан). 1С:Технология быстрого результата (1С:ТБР), кстати, тоже относится к методам работы по Agile. Ибо все принципы Agile манифеста в ней реализованы.
Выше я сказала, что команда, использующая Agile, скорее всего возьмет конкретную методику. На самом деле, это, конечно, упрощение. Исследования Agile-команд в мире показывают, что порядка 9% используют “свои собственные” или гибридные методы. А такие же исследования в России, как не трудно предсказать, показывают, что “своим путем” идет в два раза больше команд - что по разным причинам можно считать вполне логичным.
Адепты Скрам даже придумали специальный термин для тех, кто “работает по Скрам, но не совсем” - ScrumBut - то есть “Скрам, но”...
Теперь давайте от общих слов вернемся к конкретике. Вот, команда работает (или хочет работать) по Agile. Какие конкретные вещи из этого следуют?
А следует из этого, во-первых, что она изменяет формат организации работы (короткие поставки, тесное сотрудничество с бизнес-заказчиком, самоорганизующиеся команды).
А во-вторых, применение различных инструментов, практик и техник. И инструменты эти и есть, на мой взгляд, самое интересное в Agile. Существует их великое множество, большую часть популярных я уже упомянула выше, когда говорила про Скрам и Канбан. Скажем, ретроспективы, демонстрации, ежедневные стендап-совещания применяют далеко не только в Скрам.
Добавить хочу, пожалуй “карты”:
- Product roadmapping (дорожная карта продукта)
- Story mapping (карта пользовательских историй)
- И инженерные практики - это тема для отдельного подробного разговора. И тесно привязанная к конкретным используемым инструментам, языкам программирования и т. п. Чтобы не закопаться, приведу здесь просто статистику отчета 14th state of Agile от Version One - интересное исследование про Agile в мире, (рекомендую ознакомиться, кому интересно - хотя не факт, что это самое ценное, что стоит почитать про Agile чайнику)...
Еще одна из “фишек” Agile - это активное применение DevOps-практик. Суть DevOps - в плотной интеграции разработки, тестирования и внедрения. Про DevOps можно, например, посмотреть видео доклада Эмиля Карапетяна: Организация DevOps в команде специалистов 1С или сказ о том, как желтые котики хотели лучше работать - неплохой практический рассказ в привязке именно к 1С.
Кажется, в двух словах - всё. Желаю успеха в освоении мира Agile. Если интересно - продолжение следует, только пишите в комментариях, в каком формате, и что хочется конкретно узнать...
P. S. Спасибо Алексею, сподобившему меня написать эту статью ))).
P. P.S. Ну и если интересно разбираться всерьез - приходите учиться на мои курсы на Инфостарте. )))
Про Agile я рассказываю во всех трех курсах, как это ни странно, даже в рамках ближайшего - Продвинутый курс по управлению ИТ-проектами по PMBoK, стартует 10 декабря (присоединяйтесь к открытому вебинару в четверг 10 декабря в 12:00). Дело в том, что, как я уже рассказывала, на сертификацию PMP требуется знание Agile ото всех. Хотя ближайший набор на курс именно по Agile стартует в марте 2021 года.
