Ital в agile: Мастер-класс Бориса Вольфсона. Основы Agile / Блог компании Mail.ru Group / Хабр

Мастер-класс Бориса Вольфсона. Основы Agile / Блог компании Mail.ru Group / Хабр

Этот пост написан по мотивам мастер-класса Бориса Вольфсона (директора по развитию HeadHunter), посвященного (сюрприз!) основам Agile. Материал будет полезен всем, кто либо совсем не знаком с данной методологией разработки сложного ПО, либо имеет о ней смутное представление.

Доктор Ройс создал так называемую водопадную модель разработки программных продуктов. Она быстро завоевала популярность на Западе, и некоторое время назад по этой модели работало подавляющее большинство компаний-разработчиков. Что она собой представляет? Разработка продукта проходит через ряд этапов:

• сбор требований;
• их анализ;
• создание архитектуры;
• создание дизайна системы;
• кодирование;
• тестирование;
• выкладка;
• эксплуатация.

В идеальном мире мы прошли бы по этим уровням сверху вниз, как течет водопад, и в конце у нас получилась бы хорошая система. В чем заключалось решение доктора Ройса? Он предложил писать много документации, обрабатывать риски, повторять по несколько раз какие-то этапы. В итоге получилась тяжеловесная водопадная модель. Вся индустрия коммерческого софта сформировалась в 1990-х годах. И если в Европе и США существовали тяжелые методологии, то у нас не было никаких. Собиралась группа людей, которые просто пытались сделать хороший софт. Обе проблемы — отсутствие методологии у нас и тяжеловесные схемы на Западе — хорошо решает Agile.
Итак, для чего же применяется методология Agile?

• Ускорение вывода продукта на рынок. Если вы хотите что-то сделать быстрее, нужно делать это в соответствии с Agile. Очень простой пример. Есть две компании, у них примерно одинаковый бизнес. Одна пишет ТЗ, затем проектирует систему и рисует дизайн — это водопадная модель, на разработку которой может уйти несколько месяцев. Во второй компании, работающей по Agile, к этому времени может быть уже запущен сайт, выпущено ПО, она начнет зарабатывать деньги и захватывать рынок, что самое главное.
• Управление изменениями в приоритетах. Это, пожалуй, весьма болезненная проблема практически для всех компаний. Если вы делаете проект, который длится хотя бы несколько месяцев, то у вас обязательно поменяются требования. Конечно, если это не софт, например, для спутника или марсохода. Хотя даже спутникам и марсоходам обычно заливают свежую версию софта, когда они прилетают в точку назначения. Если говорить про коммерческую разработку, то проблема в том, что мы, программисты, аналитики и дизайнеры, никогда не знаем, что нужно не только заказчику, который нам платит, но и пользователям. Обычно все подходят к вопросу так: пока пользователь не попробует функционал сайта или приложения, вы не знаете, нужен он или нет.
• Улучшение взаимодействия между IT и бизнесом. Это головная боль, особенно для крупных компаний, ведь у бизнеса периодически меняются требования, каждый говорит на своем языке. В результате стороны друг друга не понимают.

Ответом на все эти вызовы явился Манифест гибкой разработки ПО.
Он состоит из нескольких частей. Первая часть называется «Ценности» (Values). Это четыре «взвешивания»:

• Если вы хотите построить гибкий процесс, вам нужно взаимодействовать и общаться между собой. В чем это выражается — рассмотрим ниже на примере Scrum. При этом вы можете (и обязательно будете) использовать какие-то инструменты и процессы, например, трекеры — JIRA, Redmine и т.д. Но ваша работа должна опираться на различные митинги, встречи и взаимодействие, а не на настройки трекеров или TFS (если говорить про Microsoft стэк).
• Работающий продукт, который мы делаем, намного важнее, чем документация по нему. Выше был приведен пример с двумя компаниями: у одной имеется готовый продукт, который можно дать пользователям, заказчику, захватив рынок; а вторая пишет ТЗ, рисует макеты и т.д. Вся эта документация, которую пользователь не может применить по причине не готовности продукта, не приносит ценности этому пользователю. Если мы научимся работать, минимизируя эти шаги, либо делая их небольшими кусочками, то у нас получится более гибкий процесс.
• Сотрудничество и взаимодействие с заказчиком важнее жестких контрактных ограничений. Обычно подписывается договор, в котором указано, что к конкретной дате за определенную сумму разработчик обязуется выполнить оговоренный объем работ. Естественно, к договору прикладывается ТЗ. То есть фиксируется время, объем работ и сроки. Это называется Fixed Price. Такой подход не очень хорош, если вы хотите работать на долгосрочную перспективу и быть гибкими. В этом случае правильнее выстраивать партнерские отношения с заказчиком. Если говорить про контрактные оформления, то обычно это выливается в контракты по схеме «время — материалы», когда разработчику просто оплачивается потраченное время. Самое главное, что здесь начинается поиск партнерства и ситуации Win-Win, когда побеждает и заказчик, и его подрядчик.
• Готовность к изменениям во взвешивании со следованием первоначальному плану.

В Agile есть план, оценки и прогнозы. Но если у вас есть какой-то первоначальный план для годового проекта, а вы через три месяца уже предоставили какую-то версию продукта, пользователи его пощупали, вы сняли метрики, посмотрели, что и как они используют, узнали что-то новое, то после этого первоначальный план можно почти полностью поменять.

Приведу свежий пример. Мы выкатили небольшую фичу на HeadHunter, когда ваши навыки может подтверждать любой — поставил вам плюсик, и появится надпись, что столько-то человек подтвердило ваш навык. У меня Scrum подтвердило 18 человек. Мы специально запустили это в очень простом виде, чтобы посмотреть, как к этому отнесутся пользователи. Мы исходили из логики, что будет взаимодействие а-ля LinkedIn или Хабр, где пользователи друг друга плюсуют. Сняли статистику, и оказалось, что у нас эти плюсики ставят, вероятно, после собеседований HR. То есть дальше мы можем развивать эту фичу в сторону HR, либо как-то ее модифицировать, чтобы она была более полезна соискателям. Таким образом, в Agile существует четыре ценности:

• люди и взаимодействие между ними;
• рабочий продукт;
• сотрудничество и выстраивание партнерских отношений с заказчиком;
• готовность к изменениям.

Ценности влекут за собой 12 принципов Agile:

1. Наивысшая ценность — это удовлетворение потребностей заказчика благодаря регулярной и максимально ранней поставке ценного для него ПО. Если заказчик хочет получить от нас большого слона, но мы можем дать ему часть этого слона не через год, а через три месяца, потом еще через три месяца еще одну часть, а затее ежемесячно выдавать кусочки, то чем чаще мы это будем делать и чем раньше, тем лучше.
2. Мы всегда готовы изменять требования, даже на поздних стадиях проекта, если узнаем что-то новое. Таким образом, мы создаем бизнесу или внешнему заказчику конкурентное преимущество. Допустим, работают две компании: одна написала ТЗ и за год сделала продукт, а мы сделали концепцию продукта (неважно, в каком виде) и постепенно его выкатываем и раскатываем. Тогда наш продукт будет больше соответствовать требованиям заказчиков, пользователей и рынка в целом.
3. При использовании Agile работающий продукт выпускают максимально часто. В манифесте прописаны сроки — от пары недель до пары месяцев. На самом деле это неделя/месяц, если вы используете Scrum. В России чаще всего каждые две недели выпускается что-то новое. А если делают какой-то веб-проект, то обычно используют одну из вариаций Kanban, значит, релизы можно делать каждый день. В HeadHunter обычно ежедневно выходит несколько релизов, что создает большие проблемы для наших конкурентов. Это могут быть правки багов, но мы умеем добавлять что-то ценное для наших пользователей.
4. Бизнес обязательно должен работать вместе с программистами, помогать им понять специфику данного рынка. Например, программисты в HeadHunter должны понимать, как работает HR, и как соискатели ищут работу. Если вы работаете в банке, то вам требуется понимание принципа работы банка в целом и очень подробные сведения о той сфере, за которую вы отвечаете. Наиболее частой проблемой, по моему опыту, является недоступность бизнеса — когда разработчик не может получить у сотрудника нужную информацию. При использовании Agile важно избегать возникновения подобных ситуаций.
5. Команда — один из краеугольных камней Agile. Наилучших результатов достигает команда замотивированных профессионалов. Есть гениальное замечание о том, что эффективность Scrum зависит от руководителя. В Agile руководитель прежде всего должен создавать условия для команды и обеспечивать всестороннюю поддержку, проводить коучинг, следить за атмосферой в коллективе.
6. Есть много исследований, которые показывают, что лучшее общение — лицом к лицу. Причем желательно, чтобы было какое-то средство визуализации, на котором можно писать: лист бумаги, доска со стикерами и т.д. Самый простой и эффективный способ узнать требования клиента, заказчика или пользователя — поговорить с ними.
7. Работающий продукт. Про него повторяться не буду. Степень готовности проекта должна измеряться не словами, о том, что ТЗ уже написано и 50% макетов нарисовано, а количеством функционала, выпущенного в production.
8. В Agile важен ритм, постоянные улучшения. Бизнес и программисты всегда должны иметь возможность делать процесс устойчивым, постоянно его улучшать.
9. Про этот пункт менеджеры обычно не любят говорить разработчикам, но Agile вообще не будет работать, если вы написали быдло-код. У вас должна быть хорошая гибкая архитектура, в которую можно добавлять разные элементы и при необходимости легко их изменять. И если команда не будет уделять максимум внимания техническому качеству (писать хороший код, использовать инженерные практики, автоматизировать процессы), то никакого Agile у вас не будет.
10. Простота. Она проявляется в технической составляющей, в дизайне. Это один из принципов экстремального программирования. Простота очень важна также с точки зрения выпуска продукта: когда вы хотите «нарезать» того «слона», лучше начать с простой части.
11. Менеджер (руководитель, Scrum-коуч, Agile-коуч) в команде меняет свою роль: он не столько занимается организацией процесса, сколько учит команду, поэтому команда должна быть самоорганизованной. Есть специальные стратегии, как из группы людей сделать самоорганизованную команду.
12. Команда должна постоянно анализировать свою работу, процессы: что получилось, как они этого добились, и постоянно улучшать организацию работ.

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

Итак, у нас получается пирамида, состоящая из четырех ценностей, на которых выстроено 12 принципов. Теперь появляются конкретные практики.

Одна из ценностей Agile гласит: мы должны выстраивать рабочий процесс, налаживая взаимодействие и коммуникации между людьми. Это выливается в практические шаги. Например, в утренние стендапы, когда команда устно синхронизирует свою деятельность на предстоящий день. Можно вместо стендапов каждому писать отчет о проделанном вчера, но это уже будет не Agile, потому что возникает поток малозначимой документации. Какие же практики чаще всего используются в компаниях, практикующих гибкую разработку?

1. На первом месте стендапы. В России, даже если компания полностью зафейлила внедрение, использование и адаптацию Agile, обычно все равно остаются стендапы. Если у вас не получается их использовать, значит, у вас совсем не организованная команда. Практика простая: каждый день в определенное время команда собирается и синхронизирует свою деятельность.
2. На втором месте планирование итераций, когда команда планирует объем работ на ближайшую итерацию. Это к вопросу о том, что в Agile нет планирования. Если у нас итерация идет две недели, то мы пытаемся сделать план, декомпозицию, может быть, разбить бизнес-задачи на задачи технические.
3. Unit-тестирование — одна из самых простых инженерных практик, которую можно достаточно быстро начать использовать. При наличии проблем с качеством порядка 60—70% багов можно отловить unit-тестированием.
4. Планирование релизов. Здесь мы уже планируем большими кусками — что и когда выпустим. Если речь идет о Scrum, то измеряем большими мазками, в спринтах.

Давайте посмотрим, как можно графически представить итеративность выполнения работ.

Нам надо дойти из точки А в точку Б. «Дойти» — означает «получить обратную связь». Допустим, у меня есть GPS, я могу дойти до какой-то точки и свериться, правильно ли я дошел. Водопадная модель — фактически, один большой шаг. То есть я куда-то пришел, выпустил на рынок продукт, и только после этого могу понять, то ли я сделал. Итеративная модель — это серия шагов. Я делаю первый шаг, снимаю метрики, что у меня используется в продукте, затем корректирую дальнейшие шаги. Пусть я приду не в точку Б, но окажусь в ее окрестностях.

При коммерческой разработке у нас постоянно меняются условия: выходят новые законы, изменяются бизнес-требования, конкуренты вдруг выпускают что-то, что мы должны сделать лучше, чем они. В итоге получается, что мы из точки А должны дойти не в точку Б, а в точку В. Итеративная модель подразумевает, что после выпуска первого релиза мы снимаем метрики, что-то переделываем, делаем следующий релиз, и т.д. И на каком-то этапе понимаем, что конкурент выпустил какую-то фичу, и нам нужно идти не туда. В этот момент мы можем остановиться, принять другие требования и начать двигаться в точку В. При высокой изменчивости условий в процессе создания продукта вы все время будете узнавать что-то новое. И в этом одно из преимуществ итеративной модели.

Еще важный момент: когда менеджеры (и даже разработчики) не очень глубоко погружены в техническую часть, им кажется, что можно итеративно сделать программу, собрать по кусочкам, как паззл. Это заблуждение. Разработчик должен представлять целиком и в деталях каждый элемент картины, и начать его делать за пять шагов. При этом надо иметь в виду, что условия могут поменяться. Это называется инкрементальным подходом («инкремент» — добавление чего-то).

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

Если вы работаете по «водопаду», то обычно у вас фиксировано содержание проекта. Вам говорят: «Хочу, чтобы вы сделали это. Я точно знаю, чего хочу я и мои пользователи. Оцените, сколько человек вам для этого нужно и сколько времени на это уйдет». В Agile мы действуем по-другому: у нас есть команда и фиксированные отрезки времени (я говорю про Scrum), например, двухнедельные итерации. Исходя из этого, мы планируем объем работ, который мы можем выполнить за это время.

Если взять классический подход и спросить: «Вы сделали этот проект успешно или нет? Как это понять?». Я должен его сделать вовремя, не превысив бюджет, и полностью сделать содержание. Если мы смотрим с позиции Agile, то наш проект тем успешнее, чем больше мы поставили ценностей заказчику.

У Хенрика Книберга есть такая метафора — Agile-зонтик. Это те методологии, которые являются гибкими. Самая большая — Scrum, экстремальное программирование (XP), DSDM, Crystal, FDD, Kanban. Более половины компаний, применяющих Agile, используют Scrum. На втором месте комбинация Scrum и XP, когда берутся управленческие практики из Scrum и добавляются инженерные. Отдельно отмечу, что комбинация Scrum и Kanban используется примерно в 8% компаний. Сейчас это один из трендов, мода. Название Scrum пришло из регби и переводится как «схватка». Проще говоря, при возникновении спорной ситуации команды выстраиваются, вбрасывается мячик, и нужно друг друга перетолкать. К разработке продукции этот термин впервые применили в 1980-х годах два японца — Хиротака Такэути и Икудзиро Нонака. Это хорошие исследователи в области менеджмента. В частности, они написали документ «The New New Product Development Game». Здесь употребление слова «new» 2 раза не является ошибкой. Просто название переводится как «Новая игра для разработки новых продуктов». Что сделали эти два японца? Они проанализировали, как различные компании создают свои продукты. Причем даже не ПО, а всевозможную технику и электронику. Авторы разделили выявленные подходы на три типа.

• Первый тип (A): у нас есть фаза разработки, все жестко, последовательно и хорошо.
• Второй тип (B): связи пересекаются, есть возможность получить обратную связь. Я запрограммировал что-то, программирую еще, отдаю тестировщику, он дает свои комментарии, я успеваю их обработать до завершения своей работы.
• Третий тип ©: каждая фаза пересекается более чем с одной другой фазой. Я программирую еще что-то, а мои первые задачи тестируются, выкладываются в production, с них снимаются метрики, я могу внести изменения.

Тип C двое японцев сравнили с ситуацией в регби. Почему? Смысл игры в том, чтобы взять мяч и донести его до линии поля противника, преодолевая сопротивление. Но в регби нельзя кидать мяч вперед. Когда ты бежишь и понимаешь, что сейчас тебя положат наземь, то мяч можно отдать назад члену своей команды. Он его ловит и бежит дальше. Если не может преодолеть сопротивление, то бежит назад.

Современный Scrum создан двумя айтишниками — Кеном Швабером и Джефом Сазерлендом. На официальном сайте www.scrumguides.org вы можете ознакомиться с официальным описанием Scrum. Так выглядит общая схема Scrum:

Итак, мы хотим делать какой-то продукт. Он разрезан на отдельные кусочки, которые называются бэклогом (backlog) продукта. Это требование. То есть у нас нет технического задания или какого-то обширного документа, который все заранее описывает. Обычно чем важнее какие-то требования, тем качественнее они разбиты и описаны. Этим занимается владелец продукта (product owner).

Среднестатистическая команда состоит из семи человек (плюс-минус два человека). Если сильно меньше, то, скорее всего, в команде не хватает каких-то специалистов, потому что подразумевается, что Scrum-команда может самостоятельно сделать из бэклога готовый продукт с новой функциональностью. Например, в команде может не быть фронтэнд-программиста. Если вы используете Scrum и проект подразумевает фронтэнд-разработку, то этого специалиста нужно включить в команду.

Роли

Scrum-команда состоит из команды разработки, владельца продукта и Scrum-мастера.

• Почему мы говорим, что Scrum — это гибкий Agile-фреймворк? Потому что он напрямую реализует ценности и принципы, описанные в начале публикации. Команда в Scrum должна быть самоорганизующейся, а Scrum-мастер помогает ей такой стать, учит, как можно быстрее и качественнее из элементов бэклога создать инкремент продукта — новую версию софта. Scrum-мастер отвечает за то, чтобы все процессы работали, чтобы участники понимали, зачем и как это делается.
• Владелец продукта, product manager — человек, ответственный за максимизацию ценности продукта, он отвечает за продукт (например, Стив Джобс).
• Команда разработки должна состоять из мотивированных профессионалов, которые могут в течение каждого спринта делать поставку, то есть на основании требований создавать готовый продукт.

Процессы

• Ежедневный скрам — это планерка, на которой члены команды рассказывают, что сделано, с какими проблемами столкнулись, что планируется сделать в ближайшее время, чтобы каждый понимал, кто и что делает.
• Спринт — итерация с фиксированным сроком, то есть в Scrum должен быть ритм.
• Планирование спринта. Перед началом спринта все собираются и определяют, что нужно сделать в течение спринта и в каком виде.
• Обзор спринта или демонстрация: все собираются и демонстрируют, что нового в инкременте продукта, смотрят, фиксируют замечания, может быть, меняют ближайшие планы.
• Ретроспектива: все собираются и думают, что можно улучшить в следующем спринте. Например, было много багов, пользователи недовольны. Давайте попробуем в следующем спринте использовать модульное тестирование. Пробуем, на следующей ретроспективе смотрим, помогло или нет, придумываем что-то еще.

Бэклог спринта — верхняя часть бэклога. Количество элементов обычно определяется скоростью команды на мероприятии, которое называется «планирование спринта», и проводится перед началом самого этапа спринта. Спринт длится 1—4 недели (чаще всего 2 недели). Чем быстрее и дешевле можно релизить, тем меньше продолжительность данного этапа.

Каждый день команда проводит 15-минутный стендап, Scrum-митинг, на котором все члены команды синхронизируют свои действия. Зачастую эти встречи называют просто «скрамами».

После завершения спринта проводится демонстрация — «Обзор», смысл которой заключается в том, что команда показывает сделанную работу владельцу продукта или кому-то еще. Затем проводится ретроспектива, на которой команда обсуждает, что получилось, а что нет, происходит разбор рабочих процессов, атмосферы в коллективе, предпринимаются попытки что-то улучшить. После этого запускается следующий спринт. В итоге работу Scrum-команды можно представить как цепочку множества спринтов.

Артефакты

Это могут быть карточки на доске с кратким описанием, что собой представляет конкретный функционал. При этом содержание карточки может представлять собой обсуждения с владельцем продукта. Обычно это выливается в тикеты в трекере, который вы используйте — JIRA, Redmine и т.д.

• Бэклог продукта — это все тикеты, карточки или иные требования в виде элементов бэклога, которые есть в вашем продукте.
• Бэклог спринта — самые ценные и приоритетные требования.

Здесь не будет канонического/кошерного/ванильного Scrum’а, который описан Швабером и Сазерлендом, и про который можно почитать здесь: www.scrumguides.org. Расскажу о реальных практиках, используемых командами. Есть тяжеловесные, якобы точные методы все «правильно» посчитать и сделать. Но практически все большие проекты выбиваются из сроков. И это касается не только IT. Например, был случай, когда аэропорт не могли запустить в эксплуатацию из-за того, что не был готов софт, отвечающий за автоматическое распределение багажа. Если вы используете гибкие методологии, а также то, о чем я сейчас расскажу, то можете спокойно запускать проекты, без геройства. Один из наших больших проектов, который закончился в сентябре, фактически был готов на production за две недели до официального запуска. Я много наблюдал, как команда, тимлиды и менеджеры пытаются предсказать, когда у них будет готов проект. Это примерно то же самое, что подойти к команде и попросить назвать случайное число.

Agile и Scrum предлагают использовать такую практику: делать относительные оценки, то есть «измерять в попугаях». Это значит, что я оцениваю время, которое у меня уйдет на решение задачи, и сколько она займет попугаев. Их обычно называют story point. Эти story point лучше не привязывать ни к каким временным промежуткам. Каким образом делать такую оценку, почему она называется относительной? Обычно берут какую-то задачу, небольшую, стандартную и понятную всем, и объявляют ее мерой, эталоном — она занимает 1 попугай, 1 story point. Берется следующая задача, сравнивается с первой — она оказывается в 2 раза больше. Сколько она занимает? 2 story point. И таким образом мы раскладываем все задачи. В итоге мы не оцениваем каждую задачу по времени, а сравниваем их между собой. Если где-то ошибаемся, то это нормально. Главное, чтобы во всех задачах ошибались одинаково. Оценка делается командой и в рамках команды.

Что мы можем сделать после этого? Например, запустить двухнедельный спринт и взять верхние задачи без каких-то оценок. Когда спринт закончится, на выходе получим инкремент продукта, в который будет включено какое-то количество задач. Посчитаем, сколько story point мы сделали, и на следующий спринт просто можем планировать такое же количество story point. Подобная оценка получается относительной и эмпирической. Мы не предполагаем, как любят делать управленцы, что программист Вася работает 8 часов и с одинаковой эффективностью, а реально измеряем, сколько команда может проживать story point за спринт. Шкала оценок обычно подбирается так, чтобы различать задачи разных классов.

Если приглядеться, то похоже на числа Фибоначчи, либо на степени двойки. При этом оцениваются обычно действительно большие задачи, которые дальше разбиваются на более мелкие. Для формирования оценок обычно используется покер-планирование. Это модификация метода Delphi. Каждому члену команды дается колода карточек с числами от 0 до 100. Есть еще карточка с надписью «Я не понимаю, что это за задача» и карточка с кофе («Давайте сделаем перерыв, я уже замучился заниматься этой оценкой»). После этого берем задачу номер такой-то, читаем и обсуждаем, что она собой представляет: «Пользователь вводит логин-пароль для того, чтобы авторизоваться на сайте». Обсуждаем, как эта авторизация происходит, где мы храним пользователей. Затем каждый член команды рубашкой вверх кладет карту с оценкой, которую считает нужной. При этом разные члены команды друг на друга никак не влияют, потому что обычно в команде есть тимлид, ведущий, старший разработчик, на которого равняется большинство. После этого происходит вскрытие карт и обсуждение.

Согласно методу Delphi, обсуждение происходит между теми, кто поставил наибольшую и наименьшую оценки. Поставивший наибольшую обычно видит какие-то риски, которые не заметили другие члены команды. Он скажет: «Вы знаете, в эту базу, где у нас хранятся логины и пароли, мы давно не заходили. Там надо что-то отрефакторить, добавить колонку, применить другой хэш» и т.д. А человек, поставивший наименьшую оценку, либо не понимает задачу, либо видит способ сделать быстрее, либо уже делал что-то подобное. После этого происходит второй этап обсуждения: опять все кладут карточки рубашками вверх, потом вскрывают их. Обычно оценки более-менее сглаживаются. Снова проходит этап обсуждения, приходят к консенсусу. В результате записывается в трекер, в тикет-систему, либо прямо на карточку, что у нас эта задача на 3 story point.

Почему это очень хороший Agile-подход? Мы беседовали, обсуждали содержание задачи, основывали наши действия на взаимодействии людей, а не на каких-то формальных процессах. Если кому-то интересны процессные вещи — обратитесь к методу оценки Кокома. Чем еще хорош данный метод? Здесь получается некая командная ответственность за размер задачи. Все берут на себя ответственность за то, что задача действительно такого «размера». Если же вы будете измерять трудоемкость задач, скажем, в днях, то будут ситуации, когда кто-то в команде оценит ее в 8 дней и она попадет к нему, то он ее и будет делать 8 дней.

Что делать в том случае, если заказчик хочет понять, сколько времени займет реализация проекта и просит сразу дать ему оценку? Идеальный вариант — работать с заказчиком по системе «время — материалы». Если заказчик новый, то можно один проект сделать по Fixed Price, убедиться, что заказчик адекватный, и дальше придерживаться системы «время — материалы». Если заказчик не соглашается сразу на данную систему, то можно ее скорректировать: например, если вы заканчиваете проект к определенной дате, то получаете какой-то бонус. На эту тему в сети тоже есть презентации.

Мы берем каждый спринт, измеряем, сколько story point сделали. И если нам надо спланировать девятый спринт, то просто берем среднее значение из предыдущих спринтов. Это называется «принцип вчерашней погоды». Здесь важно то, что мы набираем наиболее важные или ценные задачи исходя из скорости команды.

Если какая-то задача не помещается по размеру, то ее можно разбить на более мелкие, либо пометить, что она не войдет, либо отказаться от ее решения. Надо понимать, что скорость не будет равномерной. Люди работают с переменной интенсивностью, кто-то заболевает, кто-то работает медленнее из-за проблем дома, кому-то надо срочно пообщаться в соцсети, кто-то взял отпуск. Всегда нужно прямо и однозначно говорить владельцу продукта: «У нас есть задачи A, B, C, мы их точно успеем сделать, они попадают в нашу самую низкую скорость. Есть также задача D, которую мы, скорее всего, успеем сделать. Но есть и задача F, которая может выпасть». Кажется, что это неточность, и владелец скажет: «Вы что? Надо все успеть». На самом деле, когда вы ему говорите точно, что самые важные задачи будут сделаны, то это увеличивает доверие между вами и владельцем продукта или заказчиком, и он для каждого спринта сможет выбирать самые важные задачи и гарантированно их получать.

Как во время спринта контролировать, что у нас все идет хорошо? Мы спланировали спринт и начали его реализацию. Для контроля используется диаграмма сгорания Burn Down Charts.

По горизонтали отмечаем дни — это двухнедельный спринт, 10 рабочих дней. По вертикали с одной стороны отложены story point, с другой — истории пользователей или элементы бэклога. Если бы мы с вами были роботами, а задачи маленькими и разбитыми на кусочки, то мы шли бы по пунктирной линии — это линия идеального Burn Down Charts. Что эти линии означают? Верхняя — сколько мы сделали историй пользователей, нижняя — количество story point. Такие графики автоматически строятся во многих системах для трекинга задач.

Как их читать? Если ваш график находится над линией идеального Burn Down, то вы отстаете, медленно работаете. Тогда к концу спринта будет не ноль задачек или story point, а где-то 20—25. Можно в Excel построить тренд или регрессию и посмотреть, сколько у вас получится задач с такой скоростью — очень просто и наглядно. Если команда видит, что она идет поверх идеального Burn Down, то надо принимать меры. На практике обычно получается вот так.

Идут небольшие отставания, но это у хорошей команды. Другой вариант встречается реже, когда Burn Down ниже диагональной линии. Это означает, что вы идете с опережением, то есть, скорее всего, вы просто взяли мало задач.

Очевидно, что надо увеличить объем работ. В крайнем случае, здесь можно еще снять задачки, но это повод обсудить на ретроспективе, почему у вас так получилось. Этот график — артефакт, который можно в конце двухнедельной итерации проанализировать и сделать выводы.

Обычно в Scrum используют доски задач, хотя они не являются обязательным элементом. Команда распределяет задачи по отдельным этапам и размещает на доске в виде отдельных карточек. Есть электронные реализации досок задач, плагины для JIRA и т.д. Задачи упорядочиваются по степени важности. Когда команда собирается с утра, обновляются статусы задач, их переносят на другие этапы, смотрят, есть ли где-то затыки.
На этой встрече по мере возможности участвуют все заинтересованные стороны: разработчики, пользователи, служба поддержки, системные администраторы и т.д. Обзор спринта нужен для того, чтобы запустить цикл обратной связи. Вы показываете владельцу продукта разработанный инкремент. Он смотрит, делает замечания, вносит предложения, отдает их вам обратно в бэклог. Вы берете в работу, создаете новый инкремент, через одну-четыре недели показываете и снова получаете дополнительные изменения в требованиях. То есть запускаете цикл, который в итоге приведет вас к продукту, который хочет получить его владелец.
Ретроспектива нужна для постоянных улучшений. Гуру менеджмента Эдвард Деминг когда-то сказал, что совершенствоваться необязательно, выживание — дело добровольное. Ретроспектива — как раз тот этап, на котором вы можете заняться совершенствованием. Как это происходит? Вся команда собирается и обсуждает все ступени до самой ретроспективы. Обычно это длится от часа до четырех, может длиться даже день. Если вы посмотрите олдскульные книжки, там есть ретроспектива даже на несколько дней.

Начинается ретроспектива с открытия. Обычно она занимает 5% времени. Задача — растормошить всех присутствующих на ретроспективе, потому что очень часто в командах, особенно айтишных, присутствуют не очень общительные люди, но порой имеющие блестящие мысли. Задача ведущего заключается в том, чтобы разговорить этих людей. Второй этап — сбор данных, он занимает до половины времени. Команда ищет какие-то факты. Их можно вспомнить, достать из трекера, распечатать. Также можно собрать статистику по багам, кто репортил, каков их статус — вариантов множество. После сбора фактов начинается мозговой штурм: нужно понять, в чем проблема, проникнуть в суть, сгенерить идеи, которые помогут ее решить. На это уходит до трети времени. Например, если у нас много мелких багов, возникающих не на уровне интеграции системы, а в коде разработчиков, то можно предложить использовать модульное тестирование. Если у нас очень плохое качество, как его улучшить? Можно попробовать парное программирование, какие-то инструменты, которые делают автоматизированную проверку кода, еще что-то. Обычно набирается 5—10 идей. Далее нужно воплотить эти идеи в жизнь. Мы не можем сразу внедрить code review, разработать какие-то инструменты. Поэтому выбирается максимум одна-две идеи, реализацию которых надо запланировать на следующий спринт. После этого благодарим всех и закрываем ретроспективу. А еще через две недели можно оценить, получилось у нас это или нет, изучить другие проблемы.

На ретроспективе можно также понять моральный дух команды — для этого тоже есть инструменты. Можно просто начертить временную линию спринта, чтобы каждый член команды вспомнил, что происходило в этот день, наклеил стикер с фактом «закончил разрабатывать задачу», «исправлял быдло-код», «применил новую технологию Machine learning». После этого по каждому факту можно внизу нарисовать, насколько этот факт был для человека интересным, или, наоборот, отстойным. После этого построить медиану, которая отразит состояние и динамику морального духа команды.

Есть такое понятие, как «Цикл Деминга». Он состоит из четырех этапов: Plan — Do — Check (Study) — Act.

• Планирование (Plan).
• Реализация (Do).
• Проверка (изучение) (Check (Study)).
• Изменение (Act).

В ходе ретроспективы можно создать план, что вы будете дальше изменять. Скажем, внедряем unit-тестирование — как внедряем, какой инструмент используем, какое покрытие кода тестами хотим получить. Потом наступает этап реализации (это обычно спринт, если мы говорим про Scrum), когда мы воплощаем решение в жизнь. На следующей ретроспективе можем проверить, действительно ли нам удалось достичь нужной степени покрытия. Можем посмотреть, убавилось ли у нас количество багов в тех местах, которые мы покрыли тестами.

После этого можем вносить изменения: например, хотели сделать покрытие 50% — сделали, количество багов уменьшилось, но они еще остались — давайте поднимем до 70%. Или сделали 70%, цикл прокрутили второй раз, проверяем — улучшилось. Давайте сделаем 90%. Еще раз прокрутили: количество багов не уменьшилось, а затрат на написание и поддержку тестов получается много. Давайте сделаем более слабую границу. Благодаря этому циклу команда постепенно улучшает какую-то часть процессов. Самый простой вариант ретроспективы — Real-Time Board Service.

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

Надо сказать, что Scrum, как и все гибкие методологии, лучше работает в командах, которые сидят в одной комнате. Тем не менее в сети можно найти сотни презентаций о том, как применять гибкие методологии в распределенных командах, когда люди работают на удаленке. Здесь идея такая: вместо реального общения максимально использовать программные и аппаратные инструменты. Что обычно используют? Во-первых, общий трекер, что-то типа JIRA. Это действительно помогает. Популярны программистские чаты, например, HipChat. Для общения — Skype, Hangout. Главное, чтобы была видеосвязь, и чтобы можно было демонстрировать экраны своих компьютеров.
Это вторая по популярности методика. Ряд компаний работают одновременно по Scrum и Kanban, получается Scrumban. Наверное, это один из будущих трендов. Историческая справка: Kanban появился в Японии. Этим словом называлась бумажка с пул-запросом на какие-то действия. Например, мне нужна какая-то деталь, на нее делается отдельный канбан. Но в IT это все-таки применяется немножко в другом виде.
В айтишном виде Kanban появился в 2010 г., то есть это достаточно свежая, хорошо описанная методология. Ее автор — Дэвид Андерсон. В следующем году, скорее всего, выйдет обновленная версия методологии. Если Scrum подразумевает жестко предписанные процессы, которые должны сломать то, что было в организации до этого, то есть «Так, все мы теперь работаем по спринтам, с утра приходим, стендапимся, в конце спринта показываем демонстрацию», то Kanban подразумевает более эволюционные изменения.

• Начинаем с того, что есть сейчас, и дальше путем эволюции и постепенных изменений делаем из этого непонятного хаоса четко настроенную Kanban-систему. При этом стараемся только эволюционно изменять роли, зоны ответственности и обязанности. Поощряем инициативные действия на всех уровнях организации. Главная практика — визуализация, обычно в виде доски. Работа каждого члена команды должна быть визуализирована, видна всем.
• Количество работы в каждом процессе ограничивается. То есть в работе одновременно может быть не более какого-то количества задач. Это нужно для исключения мультитаскинга, который убивает эффективность. К тому же это дает определенные инструменты управления потоком задач.
• Все правила должны быть явными. Необходимо дать определение завершенности. Например, задача выполнена, если написан код, есть unit-тесты с покрытием 70%, и т.д.
• Необходимо делать улучшения с помощью постоянных экспериментов, используя модели и научный подход, в том числе цикл Деминга.

Обычно используется та же самая доска, что и в Scrum. Самый простой вариант — прото-Kanban. Поток задач разбивается на отдельные этапы. Что-то находится в плане, что-то в аналитике, что-то в разработке, что-то в тестировании, что-то мы уже сделали. При этом реализуется принцип ограничения количества одновременно находящихся в работе задач — WIP (Work in Progress). Есть формула Литтла, которая связывает скорость прохождения задачи в такой системе и количество одновременных задач. Чем меньше WIP, тем быстрее задачи проходят цепочку. Допустим, у нас завал в тестировании, а разработчик сделал следующую задачу. Он видит, что у тестировщиков проблема. Тогда разработчик помогает им что-то сделать, или они идут к руководителю и говорят: «Нам нужен еще тестировщик».

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

Здесь есть те же самые WIP, внизу — критерии готовности (Definition of Done). Столбец делят на две части: «в работе» и «выполненное». Иногда доску делят на дорожки и размещают WIP по горизонтали. Это уже более продвинутая, полноценная Kanban-система. Каждая дорожка соответствует определенному классу обслуживания. Например, есть горячие задачи, когда к вам прибегает начальник и говорит: «Надо сделать это быстрее». Это отдельный класс обслуживания, под него стоит забронировать WIP.

Как и в Scrum, здесь тоже можно создавать диаграммы. Обычно их называют «Диаграммы кумулятивного потока». По горизонтали отмечено время, по вертикали — количество задач. Разными цветами показаны разные этапы. Я упоминал, что улучшение нужно осуществлять на основе цифр, используя научный подход. Эти цифры можно извлечь из диаграмм. Самые важные из них — WIP, то есть количество задач за исключением запланированных и выполненных. Мы его должны сокращать.

Вторые важные критерии — Cycle Time и Lead Time. Определения бывают разными, нужно очень внимательно смотреть. Эти два числа показывают, насколько быстро задачи проходят через вашу Kanban-систему.

В данном случае Lead Time включает в себя ожидание, то есть как воспринимают вашу Kanban-систему заказчики. Cycle Time — насколько быстро задача проходит через Kanban-систему без ожидания, в общем бэклоге. Оба параметра нужно уменьшать, тогда ваша система будет работать быстрее.

Kanban очень хорошо приживается в компаниях с корпоративной командной культурой, когда есть какая-то иерархия. Scrum удобен для команд, которые уже хорошо общаются, в компаниях с плоской структурой, где мало начальников.

Рекомендуемая литература

• «Scrum и XP: заметки с передовой». Автор — Хенрик Книберг, Agile-коуч из компании Spotify. Книга полностью бесплатна и на русском языке. Ее минус — она очень старая. Ее большой плюс — в ней разобрано много инструментов, приведены конкретные ситуации в виде диалогов. Книгу очень любят практики, и для многих, в том числе для меня, это была первая книжка на тему Scrum и Agile. Также в ней описаны элементы экстремального программирования.
• «Scrum и Kanban: выжимаем максимум». Тоже на русском и бесплатная. Можно сказать, что это книга про Scrumban.
• На мой взгляд, лучшей книжкой по Scrum является «Scrum: гибкая разработка ПО» Майка Кона. В ней очень подробно расписано, как внедрить Scrum, кем должны стать менеджеры, архитекторы. Самая подробная книга на эту тему.
• И такая каноническая книга по Kanban Дэвида Андерсона — «Kanban: Successful Evolutionary Change for Your Technology Business». В следующем году выйдет обновленная версия.
• Моя книга «Гибкое управление проектами и продуктами». Она есть в электронном виде от издательства «Питер».
• Напоследок рекомендую работу Ахмеда Сидки «Keystone Habits of Organizational Agility». Очень подробно разобрана эта методология, просто уникальный материал для понимания Agile.

Видеовыступления

• Выступления на конференциях AgileDays и Lean Kanban.
• Доклады, экспириенс-репорты от крупных компаний — «Альфа-Банк», «Яндекс», «Райффайзен», HeadHunter и т.д., а также от небольших стартапов, в которых рассказывается, как они у себя применяли, что работало, что не работало.

SAFe для проектных менеджеров #1 — статья в блоге ScrumTrek

Мы запускаем серию ознакомительных статей про SAFe для менеджеров проектов. В них мы расскажем о преимуществах, структуре и ролях Scaled Agile Framework, а также о том, где проектные менеджеры могут найти себе применение в данном подходе. Первая часть посвящена обзору подхода с точки зрения классического проектного управления.

Часть 1: Место проектов в SAFe

SAFe – один из наиболее популярных в мире подходов для организации работы гибкой компании. Его преимущество перед другими методами состоит в следующем:

В минимальном виде SAFe выглядит как уровни Team + Program. Уровни Portfolio и Large Solution опциональны в зависимости от потребностей организации. В этой статье мы не будем рассматривать уровень Large Solution и сконцентрируемся на трёх основных.

Командный уровень

На уровне команд SAFe придерживается базовых принципов гибкой разработки, описанных в Agile-манифесте и поддерживает итеративно-инкрементальную разработку по фреймворку Scrum или методу Kanban. Команды итеративно разрабатывают элементы продукта двухнедельными итерациями (спринтами) и проводят демонстрации результатов своей работы и ретроспективу.

Единица управления на данном уровне – команда, реализующая пользовательские истории из бэклога. Роли на данном уровне такие же, как и в классическом Scrum: Владелец продукта, Scrum-мастер, член команды разработки.

Программный уровень

Уровень программы является ключевым как со стороны бизнеса, так и с точки зрения координации. На этом уровне все ресурсы, команды, заинтересованные лица кооперируются вокруг одной важной цели, чаще всего представляющую собой поток создания ценности (Value Stream) или продукт. Синхронизируют свою работу команды при помощи совместных сессий планирования (Program Increment Planning) в начале каждого квартала и демонстрации интегрированного инкремента продукта (System Demos) каждые 2 недели и ретроспективы (Inspect & Adapt) в конце каждого квартала.

Соответственно, все роли и процессы ориентированы на поставку ценных элементов функциональности. Метафорой этого процесса является “Поезд” (Agile Release Train).

ART – это долгоживущая группа команд, заинтересованных лиц и других участников, объединённых общей целью, создающая в едином ритме общее решение или его часть. Длина итераций и частота общего планирования внутри поезда фиксирована.

Управляет «Поездом», соответственно, «Машинист» (Release Train Engineer). Он коучит весь «экипаж» поезда для повышения эффективности работы, взаимодействует с заинтересованными сторонами, фасилитирует общие собрания поезда поставки. Он не начальник, он лидер этого поезда. Release Train Engineer больше всего похож на Scrum-мастера, но отвечающего не за одну, а за много команд и их взаимодействие между собой. В терминах PMI «Машинист» соответствует Менеджеру программы по уровню ответственности и исполняемым функциям (The PM role in a lean and agile world).

У поезда также есть главные «пассажиры» –  Представители бизнеса (Business Owners). Это основные заинтересованные лица, которые отвечают за финансовые показатели Поезда. Business Owners – это руководители, которые будут получать выгоду от создаваемого решения, пользоваться им или продавать его.

Управляет продуктом и владеет бэклогом поезда команда Продуктового менеджмента (Product Management). В неё входят Владельцы продуктов отдельных команд, а также Продуктовые менеджеры. Они выявляют потребности клиентов, формируют дорожную карту и приоритезируют элементы функциональности. Говоря простыми словами, Представители бизнеса ставят цели, а команда Продуктового менеджмента стараются их достичь силами команд.

Также на программном уровне есть роль Системного архитектора (System Architect). Архитектор определяет архитектуру будущего решения, направляет работу команды с технической стороны системы, взаимодействия подсистем и нефункциональных требований к системе.

Уровень Портфеля

Цель портфельного уровня – согласование стратегии компании с реализацией портфеля за счёт организации процессов вокруг потоков создания ценности. Этот уровень появляется, если у организации несколько потоков создания ценности.

Портфель в SAFe состоит из Потоков создания ценности. Это могут быть продукты или направления деятельности организации. На этом уровне определяется стратегия инвестирования, бюджеты и показатели эффективности. Также на этом уровне реализуется функция принятия решения самого высокого уровня – портфельное управление (Lean Portfolio Management). И хотя глядя на схему может показаться, что Менеджер портфеля  это некая отдельная роль, но это не так. На самом деле это группа функций, исполняемая людьми, которые могут также исполнять другие высокоуровневые роли в организации.

Корпоративный архитектор (Enterprise Architect) принимает решения относительно архитектуры всех систем в компании и их взаимодействия, для их гармоничного взаимодействия внутри организации.

«Проекты» в SAFe

Как можно заметить из схемы, роли проектного менеджера в SAFe нет, как и отдельного уровня проектов. Все бизнес инициативы связанные с созданием ценности реализуются в рамках «Поездов», уже существующих или созданных под инициативу.

Как же тогда в организациях, практикующих SAFe, реализуются инициативы по автоматизации, внедрению новых систем, затрагивающих всю организацию и многие «Поезда»? Для таких случаев в SAFe существует понятие Эпика (Epic). И он больше всего похож на классический проект.

Если возникает такая необходимость, Владелец эпика (Epic Owner) определяет описание Эпика и его Минимальный Жизнеспособный Продукт (Minimum Viable Product). Затем он взаимодействует напрямую с заинтересованными сторонами и «Машинистами» соответствующих «Поездов» для реализации Эпика.

Главное отличие от классического проекта в том, что разработка Эпика ведётся итеративно-инкрементально, а фокус функций Владельца Эпика смещается с управления командой на координацию взаимодействия с командами разных «Поездов». Реализация Эпика, как и у классического проекта, ограничена во времени. В отличие от потока создания ценности, развитие которого, как правило не останавливается.

Особенность эпика, вероятно повлиявшая на название (от англ. — «эпически, грандиозный»), в его масштабе. Это по-настоящему колоссальная инициатива, «прошивающая» большую часть организации. А потому Владельцем эпика чаще всего выступает кто-то близкий к C-уровню менеджмента в организации. Простому менеджеру проекта Эпик доверят вряд ли.

Что делать менеджерам проектов дальше?

Цифровизация, ускорение запуска инноваций, продолжающийся рост роли Интернета привели к тому, что уровень неопределённости бизнеса в целом и проектов в частности вырос. И предпосылок для замедления этого роста не наблюдается. Технологии, потребности, конкурентное окружение и прочие факторы меняются не только постоянно, но и с высокой скоростью. Со временем всё меньше организаций будут предпочитать классическое проектное управление гибким подходам в качестве инструмента развития своего бизнеса. А в большинстве Agile-методологий нет роли менеджера проекта. Увы, но это так.

Если организация хочет сохранить ценных, опытных и компетентных менеджеров проектов и использовать их потенциал в своём бизнесе, ей придётся приспособить их для исполнения новых функций. А менеджерам проектов, чтобы остаться в игре, придётся освоить новые роли и навыки. Какие, мы расскажем во второй части нашей статьи.

Полезные ссылки:

Как agile-подходы помогают создавать современную стратегию для бизнеса и продукта

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

Такой тезис можно услышать на конференциях или в разговорах с предпринимателями. На самом деле, стратегия может строиться по agile-принципам. Владимир Алешин, руководитель департамента образовательных инициатив ВКонтакте, рассказал, как принципы гибкой разработки помогают создавать стратегию, которая не устаревает в быстро меняющемся мире.

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

Поэтому для начала пообщайтесь с ключевыми стейкхолдерами и поймите, зачем вашей компании стратегия. Если окажется, что у вас более простые задачи, то не стоит «стрелять из пушки по воробьям» — реализация стратегического процесса повлечет за собой полную трансформацию компании.

Как раньше создавали стратегию

• Лидеры собирались на стратсессию и представляли какое-то светлое будущее — фактически, галлюциировали.
• После стратсессии они несколько месяцев декомпозировали задачи на разные структурные подразделения.
• Декомпозированные задачи собирали в один документ, синтезировали стратегию.
• Еще через неско

Agile и Scrum для работы в Digital агентстве | Блог

Наверное вы уже что-то слышали об Agile.  Может даже пытались применять у себя в проектах. Ну или хотя бы ради интереса посмотрели парочку видео на ютубе. Однако так и не поняли как сделать работу над проектом проще и эффективнее?

Это Андрей и он тоже не понял.

У Андрея своя Web-студия. Он работает 24/7, прикладывает колоссальные усилия, но студию уже 2 года как прогресс покинул. Мелкие проекты тянутся полгода, оплата поступает не всегда вовремя, у коллектива не горят глаза. Андрей твердо решил что так продолжаться не может. 

Давайте, поможем Андрею и его команде разобраться в терминах и войти в прекрасный мир Agile методологии.

Что же мы имеем в виду под Agile? Многое о нем говорит перевод слова, с английского — гибкий, способный адаптироваться под различные ситуации, быстрый. Отсюда происходит и второе название — гибкие методологии.

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

В документ вошли 4 идеи:

● Люди и взаимодействие важнее процессов и инструментов;

● Работающий продукт важнее исчерпывающей документации;

● Сотрудничество с заказчиком важнее согласования условий контракта;

● Готовность к изменениям важнее следования первоначальному плану.

«Да, нашли тут дурака! Документаций нам не надо, контракта мы не придерживаемся, на инструменты наплевать! Так и создается из визитки интернет магазин с бюджетом в 5 тысяч. Знаем, плавали» — разочарованно подумал Андрей. 

Наш герой, как и многие, изначально понимает Agile манифест некорректно, полностью откидывая правую часть предложения. Однако это неправильное восприятие сути.

«Мы признаем ценность того, что находится справа, но для нас более ценно то, что слева. Это не взаимоисключающие вещи, просто акцент делается на людях, взаимодействиях, сотрудничестве и работающем продукте» — объясняет Agile манифест.

Тут Андрей понимает, что по сути, Agile это своего рода философия, которую ему нужно не внедрить, а лишь принять.

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

Окей, с теорией разобрались, но что же Андрей получает на практике?

Пошаговую разработку продукта из небольших подзадач, а не одной большой задачи. На каждом этапе Андрею нужно спланировать определенный объем задач, проанализировать требования, спроектировать, разработать и протестировать “кусочек” проекта, задокументировать процесс, согласовать с заказчиком. 

– Слишком сложно! — опять пробурчит Андрей.

– Минимизирует риски! — ответим мы.

И обоснуем. По окончанию каждого этапа мы имеем какой-то готовый  функционал. Готовую версию подпродукта. Его можно просмотреть, оценить, протестировать, сделать выводы в каком направлении двигаться дальше, согласовать все на промежуточном этапе! А дальше скорректировать недочеты, подвести итоги и приступить к следующему. 

«Хорошо, я допускаю, что это может сработать, но мне нужна конкретная методика по управлению проектами» — резонно замечает Андрей.

Давайте расскажем ему об одной из самых распространенных  методик Agile.

Scrum

В центре SCRUM находится команда, у каждого есть четкая роль. Условно, команда делится на 3 вида ролей:

1. Product Owner (владелец продукта) — человек, понимающий каким продукт должен получится на выходе. Он собирает и приоритезирует требования. Общается с клиентом или клиентами. Рассказывает о ним команде. Вот кстати интересный факт: Product owner это не всегда клиент. Это запросто может быть человек в команде разработки.

2. SCRUM Мастер — это “сердце команды”, задача этой роли в том, чтобы создать для команды максимально комфортные условия работы, мотивировать и помогать. Роли мастера и владельца продукта ни в коем случае не должны пересекаться.

3.  Непосредственно команда, которая выполняет проект: дизайнер, Front-end, Back-end.

“А кто головой отвечать будет??!” — восклицает Андрей.

В SCRUM нет распределяющей шляпы, которая говорит кто что делает и несет за это всю ответственность, как обычно принято. С точки зрения технологий Agile, команда является самоорганизующийся. Лидеры появляются в зависимости от той задачи, которую в данный момент решаем. А зависит это от итерации на которой находимся.

Андрею нужно изначально разбить время на отрезки, собрать команду, желательно до 7 человек на конкретный проект, все содержание проекта разделить на части, примерно равные по размеру. А что, как и когда делать, каждый решает для себя сам, при поддержке Scrum мастера и на условиях выдвинутых Владельцем продукта. 

Как пользоваться Scrum

1. Формирование бэклога

Это список требований (задач), которые нужны для реализации проекта, включает в себя как технические, так и функциональные требования. Product Owner отвечает за бэклог, наполняет его и расставляет приоритеты. Именно такой подход к делу решает одну из основных задач Андрея, ведь часто для его команды все задачи одинаково приоритетны, что приводит за собой “застой” в разработке проекта.

Задачи в бэклоге обычно формируются на языке пользователя и включают в себя все требования заказчика.

2. Спринт планирование

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

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

To Do — задачи, которые нужно сделать;

WIP — задачи в процессе выполнения;

Done — выполненные задачи;

Изначально каждую пользовательскую задачу следует разбить на подзадачи и распределить по сотрудникам. Планирование спринта определяет чем Андрей и его команда будут заниматься в ближайшее.

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

Когда задачи на неделю спланированы, посчитаны и распределены — они переносятся в колонку To DO и блокируются. Это значит, что в течении рабочей недели команда работает по заранее согласованному плану.

Когда колонки сформированы — Андрей получает ясную картинку, четко понимает на каком этапе находится, что нужно делать и сколько это будет стоить. А затем идет с этой информацией к клиенту. Ясные сроки и ясные средства.  Так же ясно это понимает и вся команда. Здорово, правда?

Для визуализации задач удобнее всего использовать дополнительные программы. Андрею вот  приглянулся WEEEK.

3.  Ежедневные Скрам-встречи — митапы

Они просто должны быть. Каждый день. Но не более 15 минут. Поэтому их часто проводят стоя на ногах, чтобы не задержаться на удобном диване невзначай.

Проводить такие встречи нужно в начале рабочего дня. В процессе команда не решает вопросы и проблемы, просто каждый отвечает на три вопроса SCRUM Мастера: что сделал вчера, что планирует сделать сегодня и с какими проблемами столкнулся. Так команда видит, что все идет по плану. А если не по плану, то мастер может оперативно это исправить.

За время собрания успеваем перенести сделанные задачи в колонку Done , а те, которые планируются на сегодня из To Do перемещаем в WIP.

Вывод: задача команды за один спринта все задачи из колонки To Do перенести в колонку Done. Если не все задачи успели дойти до этой колонки, то задачи переносятся на следующий спринт, а на следующем планировании проводится корректировка рабочих часов на задачи.

– Ох, ну зачем каждое утро, то? – недоволен Андрей.

– Чтобы понимать, где находимся –  отвечаем мы.

4. Ретроспективы. 

Не смотря на то, что команды являются самоорганизующимися, кто-то должен отслеживать, что все идет по плану. Ретроспективы проводятся после каждого спринта. На них рассказываются и обсуждаются текущие продуктивные показатели команды и результаты спринта. Часто они игнорируются, но без них очень сложно понять, что в команде все работает именно так как нужно и ничего не нужно корректировать. 

5. Демонстрация и релиз

Спринты должны быть распределены так, чтобы спустя какое-то количество спринтов получить логически законченную часть продукта или полностью готовый продукт. Стандартно — один релиз это 4 спринта.

Так, спустя  4 недели Андрей уже имеет “осязаемую” часть, а может даже и весь продукт. Может показать его клиенту и обсудить возможные правки, собрать новые требования, и даже получить процент оплаты 🙂

Что делать Андрею и его команде дальше?

С собранными требованиями после демонстрации вернуться к этапу бэклога и повторить цикл. Профит.

Протестировав, Андрей понял, что при соблюдении правил, результат работы получается качественным и в короткие сроки. А использовать WEEEK намного удобнее вместо, хоть и ламповой, но громоздкой пробковой доски и стикеров.

Что еще нужно знать?

Многие из тех, кто пытался внедрить Scrum потерпели фиаско. Scrum — гибкий и одновременно относительно жестко регламентированный фреймворк.

Он четко объясняет правила, которые необходимо соблюдать, чтобы все работало. Но гибок в том, что для каждой команды и проекта Scrum будет разный. У кого-то между спринтами будет регулярный полуспринт на правки. У кого-то будут релизы каждую неделю. У кого-то спринты по 2 недели. А у кого-то дополнительная строка под внеплановые задачи. Никто не знает как удобно работать вам и вашей команде. Нужно пробовать, тестировать и внедрять.

Scrum чек-лист 

1.   Собираем команду, распределяем роли.

2.   Формируем бэклог, разбиваем его на части по приоритету.

3.   Одному спринту отводим определенный объем задач.Оформляем и наполняем колонки To Do.

4.   Каждое утро проводим митап, по его результатам переносим задачи в нужную колонку.

5.   В конце спринта проводим ретроспективы.

6.   Общаемся с клиентом, показываем что сделали, собираем новые требования, правки.

7. После нескольких спринтов, проводим релиз, заливаем готовую часть продукта или функцию.

8.   Колесо Сансары дало оборот.

Начнем? 

__________

Текст: Анастасия Евдокимова

читаем и качаем книги по гибкой методологии —

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

Внедрение Scrum для компаний, которым нужны быстрые процессы.

Книги, переведенные на русский:

Асхат Уразбаев, Никита Филиппов
Ag;)eChecklist Очень краткое описание практик гибкой разработки
https://www.pmoffice.by/wp-content/uploads/2016/07/agilechecklist20.pdf

Хенрик Книберг
Scrum XP записки с передовой. Как мы делаем Scrum
https://www.pmoffice.by/wp-content/uploads/2016/07/Scrum-XP-zapiski-s-peredovoy.pdf

Разрабатывается и поддерживается Кеном Швабером и Джеффом Сазерлендом
Исчерпывающее руководство по Скраму: Правила Игры
https://www.pmoffice.by/wp-content/uploads/2016/07/Scrum-Guide-RUS.pdf

Джефф Сазерленд “Scrum. Революционный метод управления проектами”http://www.ozon.ru/context/detail/id/34376940/

Алексей Кривитский “Быстрый старт в agile ретроспективы”
https://leanpub.com/agile-retrospective-kickstarter-ru

Джил Конрат: Гибкие продажи. Как продавать в эпоху перемен
http://www.labirint.ru/books/482675/

Эрик Рис “Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели”
http://www.ozon.ru/context/detail/id/18322266/

Синди Альварес “Продукт, который купят. Метод Lean Customer Development” –http://www.ozon.ru/context/detail/id/34432645/

Майкл Томас Вейдер “Инструменты бережливого производства. Мини-руководство по внедрению методик бережливого производства”
http://www.ozon.ru/context/detail/id/32218895/

Майкл Томас Вейдер “Инструменты бережливого производства II. Карманное руководство по практике применения Lean”
http://www.ozon.ru/context/detail/id/34350832/

Книги на английском:

Roland Smart “The Agile marketer”
http://www.ozon.ru/context/detail/id/136235544/

Scott Brinker “Hacking Marketing: Agile Practices to Make Marketing Smarter, Faster, and More Innovative”
https://www.amazon.com/Hacking-Marketing-Practices-Smarter-Innovative/dp/1119183170/

Anthony Freeling “Agile Marketing”
https://www.amazon.com/Agile-Marketing-Anthony-Freeling/dp/1456491091/

David Meerman Scott “The New Rules of Sales and Service: How to Use Agile Selling, Real-Time Customer Engagement, Big Data, Content, and Storytelling to Grow Your Business”
https://www.amazon.com/New-Rules-Sales-Service-Storytelling/dp/1118827856/

Agile руководство шаг за шагом, внедряем эджайл 5+ шагов

Agile как методология гибкого управления становится очень популярной, уже можно с уверенностью сказать, что 100% компаний из списка Forbes применяет Agile в своей работе или по крайне мере думает о том как применить. Почему?

Методы гибкого управления Agile (эджайл) позволяют достигать сверхпоказателей в реализации задуманных целей, при этом ключевую работу выполняет ваш текущий персонал имеющимися ресурсами. Согласитесь, что звучит данное высказывание очень интересно, а конкретизацию я даю на бизнес-консультации или корпоративном тренинге: Agile в управлении и продажах.

Agile очень прост для понимания, но сложен для внедрения, так как требует изменение мышления и некоторых корректировок в бизнес-процессах — для быстрого понимания специфики Agile для своей компании закажите разработку бизнес-квеста и вы получите превосходный корпоративный тренинг.

Как эффективно внедрить Agile

Гибкие методы управления используются давно, можно сказать всегда, только назывались они по другому — хитрость и смекалка.

В Agile входит много разных методологий Scrum, Канбан, ХР, Lean, а также множество интересных методик, которые можно использовать по отдельности.

Модель Водопада — Waterfall Model

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

Для этого используем Agile — комплекс методов гибкого управления, с возможностью доработки, разработки, адаптации непосредственно под вашу конкретику. Лично мне очень нравится Agile, так как дает возможность решать множество сложнейших задач простым способом и смотреть на проблемные ситуации под другим углом. Интересно? Обратитесь за индивидуальным решением.  Конечно есть Agile манифест, но он не является ни аксиомой, ни теоремой, это просто свод правил для ориентирования в методах гибкого управления, с одной стороны определяющей границы, а с другой дающий ориентиры — именно так мы будем понимать термин Эджайл манифест.

Зачем внедрять Agile методы гибкого управления в компании

Agile манифест

Методология Agile, как и в целом концепция гибкого управления выражается в следующих простых принципах:

• умение работать с людьми; находить,… воспитывать и управлять талантами.
• выстраивать систему деловых коммуникаций, как с клиентами, так и с партнерами.
• уметь управлять изменениями, девиз: «подвижный в подвижной среде» очень хорошо подходит для Agile команд.

Принципы методов гибкого управления Agile

Распространенные заблуждения по методологии Эджайл

Я намеренно написал Agile в русском произношении Эджайл, что бы акцентировать ваше внимание на следующие факторы, акцент на которые может привести ваш проект к провалу несмотря на методы гибкого управления:

Документация в Agile

Отсутствие документации, игнорирование документации или создание большого объема документации — вот ключевые камни преткновения при работе с документацией и в Agile работать с документацией нужно, главное чтобы документация не создавалась ради документации.

Цель документации не бюрократия, а стандартизация процессов, закрепление новых технологий и выявление критических факторов.

Документация в Agile это дневник капитана корабля, а в серьезных проектах черный ящик, который фиксирует все и вся, возможно и не так явно, как кажется.

Договор в Agile

Любой юрист Вам скажет к чему приводит игнорирование договора, конечно возможно вам повезет, а возможно нет, так что? — есть желание игнорировать контракт или может быть потратим немного времени и составим приложение к нашему договор, чтобы потом не было обидно.

Agile управление в компании

Основная задача методов гибкого управления заключается в минимизации рисков и увеличении прибыли при работе в  условиях постоянных изменений и кризиса, казалось бы все тривиально, но здесь появляется отличительная особенность Agile от других методов управления:

• очень пристальное внимание уделяется командообразованию.
• работа осуществляется в коротких циклах.
• построенная система обратной связи даёт возможность производить практически мгновенные корректировки.

Agile это военная операция в условиях высокой неопределенности

Управление по Agile дает возможность быстро корректировать под требования рынка ваш продукт или услугу, менять упаковку, изменять маркетинг, сервис и систему продаж. Agile отлично работает с точки зрения управления рисками и в современном риск-менеджменте без Agile не обойтись.

Какие отличия Agile от других систем управления

Рекомендую ознакомиться:

Agile позволяет улучшить коммуникации внутри компании и снизить возникновение конфликтных ситуаций.

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

Примеры Agile в компании

Могу ли я привести примеры успешных команд, которые работали по Agile? — да могу, но многие руководители даже не осознают, что частично применяли методы гибкого управления.

Может ли Agile привести к хаосу — да, а хаос к системе? Ответ тоже Да, почему?

Конечно, есть исследования, которые говорят нам о том, что гибкие методы управления позволяют увеличить вероятность реализации проектов в несколько раз, но не надо забывать «про прочие равные условия» и про то, что проекты делают люди, а следовательно то, что сработало у вас может не сработать в других компаниях. Поэтому будьте очень аккуратны с оптимистическими прогнозами по Agile и проводите корпоративное обучение  сотрудников в виде тренингов и семинаров.

Scrum методика гибкого управления

Scrum (Скрам) пожалуй одна из популярных и простых методик гибкого управления, мы знаем про Scrum от Джеффа Сазерленда.

Алгоритм реализации Scrum в компании довольно простой:

• определите владельца продукта.
• сформируйте команду от 2-10 человек.
• найдите наставника или скрам-мастера.
• составьте требования к продукту и цели, которые вы хотите достичь, зафиксировав данные в бэклог продукта.
• проведите оценку данных вместе со всей командой, зафиксировав сколько времени потребуется на выполнение.
• определитесь с периодом спринтов, отрезки времени, которые необходимы для внедрения выделенного объема задач. Спринты проводятся до момента завершения проекта.
• проводите ежедневные встречи, 15-20 минут, кратко обозначая следующие вопросы: что делал вчера, что будем делать сегодня и какие трудности мешают.

Дополнительно вы можете делать:

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

7 шагов внедрения SCRUM в компании

Что-то новое? Скорее всего нет, хорошо забытое старое. Agile и Scrum позволяет немного по-другому посмотреть на текущую работу, но это дает совершенно другие результаты. Мы видим новые подходы в лидерстве, командообразовании, управлении проектами и командной работе. Методы гибкого управления могут быть использованы в любых проектах, позволяют повысить эффективность и производительность рабочих команд, снизив при этом вероятность возникновения рисков.

Agile (Эджайл) краткое руководство по внедрению шаг за шагом

Die Experten für agile Methoden

StartseiteAusbildung

• Scrum Master
  • Scrum Foundations
  • Сертифицированный ScrumMaster (CSM)
  • Advanced Certified Scrum Master (A-CSM)
  • Certified Scrum Professional — Scrum Master (CSP-SM)
  • Meeting-Moderation

  -Модерация

  • Retrospektiven-Training
  • Visualisierungs-Training
  • Konfliktbearbeitung
  • Agile Fluency Game
  • Agile Fluency Diagnostic
  • Das agile Mindset
  • 00030003
  • Überbanslick Foundations
  • Überbanslick
  • Certified Scrum Product Owner (CSPO)
  • Advanced Certified Scrum Product Owner (A-CSPO)
  • Fit for Purpose
  • Agile Tuning Tag
• Führungskräfte
  • Das Ausbildung6sprogramm
  • Сертифицированный Agile Leadershi p II (CAL-II)
  • Wirkungsvoll führen und coachen mit «Процесс ответственности»
  • Leadership Circle 360 ​​° Profile
  • Leading Collaborative Culture
  • Überblick Skalierungsansätze
  • Agiles Change Management

  .0 Основы

  • Тег Agile Tuning
• Entwickler
  • Kurzüberblick Agile Entwicklungspraktiken
  • Сертифицированный разработчик Scrum (CSD)
  • Flexible Architekturen
  • Рефакторинг
  • Entwickler
  • Рефакторинг Entwickler
  • Рефакторинг Legacyr
  • Kanban
    • Kanban Practitioner (TKP)
    • Kanban Management Professional 1 (KMP I)
    • Kanban Management Professional 2 (KMP II)
    • Модель зрелости Kanban (KMM)
    • Kanban Coaching Practices (fü000r) Projektleiter
    • Agile Tuning Tag
  • Эшелоны полета
    • Проектирование потока эшелонов
    • Архитектура системы уровней полета
  • Spezialisierung
    • Agile Fluency® Game Facilitator

    durch pfiffige Führung

  • Unsere Schulungen bei Ihnen
  • Online Schulungen (mit Videokonferenz)
  • Scrum Zertifikate erneuern
  • Unser Online-Shop ↗
  • E-Learning
  • Unser
  • E-Learning
  • Unserbab
  • Unserbach
  • Unserbach
  • Unserbach
    Был ли ist agile Produktentwicklung?
    • Был ли это проворным?
    • Wie unterscheidet sich Agilität zu klassischem Projektmanagement?
    • Была ли команда ist ein agiles?
    • Был ли bedeutet agiles Arbeiten?
    • Был ли проворный Prozesse?
    • Была ли Agiles Unternehmen гибкой организацией?
    • Был ли heißt es, eine agile Haltung zu haben?
    • Scrum
    • Kanban
    • Agile Fluency
    • Agile Leadersheep
  • Agile Organisationen
    • Führungskräfte und Manager in der agilen Welt
    • Agile Princesses 9000 9000 9000 Agile Princesses ™ Leaders 9000 9000 9000 Agile Princesses ™ Leaders 6 Профиль 360 °
    • Оценка коллективного лидерства
  • Agile Teams
    • Retrospektiven
    • Schätzen
    • Определение готовности
    • Agile Skalierung
    • Agiles Arbeiten 9000 9000 9000 9000 Teams 6

    Что такое управление продуктом? | Atlassian Agile Coach

    Как член продуктовой группы, я ежедневно работаю с менеджерами по продуктам и побеседовал с десятками об их ролях и обязанностях.Несмотря на этот совет, я понял, что не существует единого способа применения принципов управления продуктом. У каждого продукта есть свои цели и задачи, которые требуют уникального индивидуального подхода к управлению продуктом. Мартин Эрикссон классно описал управление продуктом как пересечение бизнеса, взаимодействия с пользователем и технологий.

    • Бизнес — Управление продуктами помогает командам достичь своих бизнес-целей, устраняя разрыв в коммуникации между разработчиком, дизайном, заказчиком и бизнесом.

    • UX — Управление продуктом фокусируется на опыте пользователя и представляет клиента внутри организации. Отличный UX — вот как проявляется эта направленность.

    • Технологии — Управление продуктом происходит изо дня в день в инженерном отделе. Глубокое понимание информатики имеет первостепенное значение.

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

    Повествование

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

    Маркетинг

    Ориентация на клиента Product Management также влияет на маркетинговые усилия. Вместо того, чтобы придерживаться бренда и использовать установленные методы, группы управления продуктами (часто включая менеджеров по маркетингу продуктов) интегрируют язык своих клиентов в сообщения о своем продукте.Кроме того, знание конкурентной среды и способность выделяться и дифференцироваться приносят дивиденды в долгосрочной перспективе. Понимание основных концепций маркетинга и позиционирования поможет менеджерам по продукту выпускать продукты, которые люди могут найти и к которым они будут относиться.

    Эмпатия

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

    История управления продуктом

    Управление продуктом зародилось во время великой депрессии, когда 27-летний маркетолог предложил идею «брендового человека» — сотрудника, который будет управлять конкретным продуктом, а не традиционным бизнес-роль.С 1930-х годов постоянный успех этой функции привел к росту товарных организаций в разных отраслях и регионах.

    • 1931 — Нил Х. МакЭлрой, менеджер по маркетингу в Proctor & Gamble, пишет 300-страничную памятку о потребности в «брендменах», которые управляют определенными продуктами.
    • Конец 1930-х годов — МакЭлрой — советник в Стэнфордском университете, где он оказывает влияние на двух молодых провидцев: Билла Хьюлетта и Дэвида Паккарда.
    • 1943–1993 — Hewlett-Packard поддерживает 50-летний рост на 20% год к году, внедряя в своей новой компании философию «брендмена».
    • Конец 1940-х годов — Toyota разрабатывает принципы производства JIT, которые позже были приняты Hewlett-Packard.
    • 1953 — Toyota разрабатывает метод канбан.
    • 1970-е годы — Технологические компании в США начинают разрабатывать облегченные процессы в противовес громоздким процессам, возникающим в обрабатывающих отраслях.
    • 1980-е годы — Разработка гибких процессов в сочетании с более широким принятием ролей «бренд-менеджмент» распространяется во многих технологических и программных компаниях.
    • 2001 — Написан Agile Manifesto, который по большей части разрушил разрозненность отделов и устаревшие процессы, чтобы освободить место для единой роли управления продуктом.

    Трудно недооценить роль гибкой разработки программного обеспечения в росте управления продуктами. В Agile Manifesto, написанном в 2001 году, изложено двенадцать принципов, один из которых гласит: «Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта». На эту роль вышли менеджеры по продуктам, и с развитием гибкой разработки последовал рост управления продуктами.Сегодня спрос технологических компаний на квалифицированных «специалистов по продуктам» привел к взрыву новых программ в университетах и ​​школах программирования, которые только ускорят этот рост.

    Роли управления продуктом: менеджер по продукту и не только

    В некоторых случаях управление продуктом для одного продукта или семейства продуктов выполняется одним менеджером по продукту. Этот человек должен обладать глубокими знаниями, по крайней мере, в одной из областей, которые касаются управления продуктом, и иметь увлеченность или свободное владение другими.Чаще всего это проявляется в одном из двух случаев: опытный бизнес-маркетолог, стремящийся к выдающемуся пользовательскому опыту и свободно владеющий техническим жаргоном, или руководитель технического развития, который настолько хорошо разбирается в продукте, что может начать его создание. Эти люди оказались настолько редкими и ценными, что за управление продуктами теперь приходится самая высокая зарплата во всей сфере технологий.

    Поскольку действительно трудно найти людей, свободно владеющих обеими областями, зачастую управление продуктом осуществляется небольшой группой специалистов.В Atlassian мы сформировали триаду, в которой лидеры из области разработки, дизайна и бизнеса работают вместе, чтобы руководить продуктовой стратегией. Триаду поддерживают PM, PMM и многие другие роли, указанные ниже:

    • Главный директор по продукту (CPO) — Руководит функцией продукта на организационном уровне. Гарантирует, что о каждом продукте заботятся опытные менеджеры по маркетингу и их команды.
    • Владелец продукта — играет более активную роль в разработке продукта, управляя отставанием инженерной группы и ее взаимодействием с другими заинтересованными сторонами.
    • Менеджер по маркетингу продукта (PMM) — Повышает способность продуктовых групп находить клиентов и учиться у них с помощью маркетинговых кампаний, ориентированных на продукт, и предоставляемой ими информации.
    • Исследователь пользовательского опыта (UX) — UX является одной из основных обязанностей менеджера по маркетингу, но специализированный исследователь UX, который изучает поведение пользователей и дает рекомендации по удобству использования, является отличным дополнением к любой команде разработчиков.

    Поскольку нет четкого пути к управлению продуктом, многие соискатели eagar вместо этого сосредотачиваются на основных профессиональных качествах работы.Например, я изучал новую специальность «Управление информацией» в Университете Колорадо в Боулдере. Я взял половину курсов по управлению бизнесом и половину по информатике с целью научиться говорить на обоих «языках» и преодолеть коммуникационный разрыв между двумя мирами. Аналогичные навыки, которые следует учитывать, относятся к анализу данных (в частности, SQL), управлению проектами и стратегии. Эти навыки управления продуктом активно продаются школами программирования, университетами и учебными курсами по профессиональному развитию по всему миру, доказывая здесь, что управление продуктом никуда не денется.

    Что такое гибкое управление продуктом?

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

    Одна из основных концепций гибкой разработки заключается в том, что объем проекта изменчив, а ресурсы остаются неизменными. Таким образом, при гибком управлении продуктом команда тратит меньше времени на определение продукта заранее и открыта для изменений в процессе.Продукт создается по одной итерации за раз, что позволяет использовать данные о клиентах и ​​командные ретроспективы для перехода к следующему этапу. Таким образом, гибкое управление продуктом — это скорее руководство командой разработчиков через циклы, поддержание видения продукта и интеграция информации о клиентах на этом пути.

    Таким образом, менеджеры по гибким продуктам более интегрированы в технологические группы, чем бизнес-команды. В Atlassian наши менеджеры по работе с клиентами непосредственно входят в состав инженерной организации и в первую очередь защищают команды разработчиков.Это критически важно для гибкого подхода Atlassian. PM поддерживают команды менеджеров и PMM (менеджеры по продуктовому маркетингу), чтобы дополнить продуктовую дисциплину и обосновать свою практику в отношении рыночных данных и бизнес-целей. Эта организация хорошо работает для Atlassian, но не для всех. Многие команды могут добиться успеха, делая прямо противоположное.

    Представляя будущее управления продуктом

    Управление продуктом — это междисциплинарная задача, которая столь же труднодостижима, насколько и мрачно проста.Менеджеры по продукту вызывают сочувствие к покупателю и сообщают о своих потребностях всей организации. Они наиболее тесно работают с командами разработчиков, но им также необходимо заручиться поддержкой маркетинга, дизайна и менеджмента. Их особый соус — способность понимать и общаться с самыми разными людьми, говорящими на разных языках.

    Я надеюсь, что в будущем продуктового менеджмента будет меньше менеджеров по продуктам, которые лучше выполняют свою работу. Как только гибкое управление продуктами стало модным, каждому продукту внезапно потребовался PM, и каждому PM потребовался заказчик на поставку, который нуждался в PMM, которым все управляли CPO.Это распространение привело к созданию нечетких, частично совпадающих ролей и добавило больше процессов, чем они достигли прогресса.

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

    Max Rehkopf

    Как самопровозглашенный «марионетка хаоса» я обращаюсь к гибким методам и принципам бережливого производства, чтобы навести порядок в моей повседневной жизни. Мне доставляет удовольствие делиться этими уроками с другими через множество статей, выступлений и видео, которые я делаю для Atlassian

    Использование гибкой разработки в непрограммных отраслях

    Agile — огромное модное слово в разработке программного обеспечения.Другие термины включают «Scrum», спринт, итерацию, встречи, устав проекта и т. Д.

    Хотя предприятия, не связанные с разработкой программного обеспечения, могут не использовать эти термины, они включили многие основы гибкой разработки в свое собственное управление проектами. . Фактически, многие из методов гибкой разработки годами использовались в областях, не связанных с ИТ — стоячие встречи, визуальное управление, приоритезация и разделение проектов на более мелкие итерации.

    К определению

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

    У гибкого управления есть проблемы, чтобы быть уверенным:

    • Управление масштабом проекта: изменения приходят быстро и должны быть реализованы так же быстро
    • Планирование может быть проблемой: потому что гибкие проекты требуют, чтобы группа работала одновременно по их собственным «частям», и ускоренное отслеживание, которое работает.
    • Запросы на изменение и утверждение: они происходят быстро и могут повлиять на всех членов команды.
    • Коммуникация: члены команды должны взаимодействовать регулярно и часто в незапланированное время, потому что быстрые изменения происходят на протяжении всего проекта, и каждый должен адаптироваться.

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

    Раннее использование

    В 1986 г., The Harvard Business Review (январь.1986), два японских исследователя опубликовали статью под названием «Игра в разработку новых продуктов». В нем они говорили о новом процессе разработки продукта (не в области ИТ) и сначала использовали терминологию «схватка» и «спринт» — методология, предполагающая производство в небольших быстрых итеративных циклах.

    Разработка программного обеспечения становится естественной для Agile

    По мере того как шли годы, и Scrum становился все более предметом обсуждения, компании, занимающиеся разработкой программного обеспечения, начали осознавать ценность, которую он привносит в проекты командной разработки.Они ухватились за это, добавили другие аспекты и придумали то, что стало известно как «гибкая разработка». Этот метод оказался очень эффективным, позволяя командам определять короткие итерации для разработки, быстро их разрабатывать, экспериментировать и тестировать, а затем быстро переходить к следующей итерации.

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

    Ценность гибкой разработки в других отраслях

    Проектные группы и руководство во всех отраслях, а также руководители проектов теперь начинают осознавать ценность гибкой разработки в своих нишах. Одними из самых популярных областей использования гибкой разработки являются разработка новых продуктов / услуг, маркетинговые кампании, реорганизация и слияния, проектирование и даже строительство. Общим фактором всех этих инициатив является то, что они включают в себя изменения, часто на высоком уровне, различные уровни сопротивления изменениям и, следовательно, необходимость быстрой адаптации.А Agile — это все, что нужно для перемен, борьбы с непредсказуемым и посевного материала.

    Некоторые примеры использования Agile за пределами ИТ

    Несмотря на то, что существует не так много тематических исследований предприятий, не связанных с ИТ, использующих Agile, их немного. Вот два из них.

    1. Lonely Planet

    Lonely Planet — крупнейший в мире издатель путеводителей. Сейчас он принадлежит NC2 Media.

    В 2012 году команда юристов Lonely Planet приняла решение применить гибкий подход — использовать доски и карточки задач, проводить встречи, проводить еженедельные итерации.

    2. Shamrock Foods

    Эта компания является дистрибьютором продуктов питания со штаб-квартирой в Аризоне. Высшее руководство решило перенять некоторые аспекты гибкой разработки. В частности, они стали проводить ежеквартальные собрания. Во время этих встреч эта команда будет рассматривать все задачи, которые были выполнены в предыдущем квартале, анализировать и корректировать свои стратегии, а также определять приоритеты следующих повторяющихся действий. Каждый менеджер возвращался на свое место с карточками заданий. Согласно описанию этого тематического исследования в Sloan Management Review, с момента принятия этого решения компания процветала.

    Использование / прогнозируемое использование Agile

    Есть несколько отраслей, в которых некоторые аспекты гибкой разработки уже используются, оценка Agile

    для пользовательских историй

    перейти к содержанию

    Индия [email protected] +91 8800842559

    Поиск:

    Поиск

    • войти в систему
    • Зарегистрироваться

    Войти

    Страница YouTube открывается в новом окне Страница Linkedin открывается в новом окне Страница Facebook открывается в новом окне Страница Twitter открывается в новом окне Страница Instagram открывается в новом окне Страница Whatsapp открывается в новом окне События и календарь

    0

    Просмотр корзиныОформить заказ

    • Нет товаров в корзине.

    Промежуточный итог: ₹ 0,00

    Просмотр корзиныОформить заказ

    Войти

    Agile Digest

    Ловкость в обучении