Что почитать про Agile для чайников?
Продолжаю рубрику “Письма в редакцию”. Ко мне иногда обращаются с вопросом — вот, я, мол, совсем не представляю, что такое Agile…
- Описание
- Подробнее
Описание
Что бы мне почитать, чтобы в общих чертах разобраться? например, чтобы понять, стоит ли внедрять 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 года.