Agile для чайников: Agilе для чайников: семь тезисов о методе, который любит Герман Греф

Agile/Scrum для начинающих

Что такое Agile и Scrum?

Что такое Agile?

В переводе с английского языка «agile» означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «agile» понимают набор подходов по “гибкой” разработке программного обеспечения.

Суть agile-подхода изложена в “манифесте”, но для заказчика ее можно коротко сформулировать так:

• разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;
• в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;
• команда разработки сотрудничает с Заказчиком в ходе всего проекта;
• изменения в проекте приветствуются и быстро включаются в работу.

В настоящее время agile-принципы используются в работе десятки тысяч команд по всему миру.

Основополагающие принципы Agile-манифеста 

Мы следуем таким принципам: 

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. 

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

3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. 

4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. 

5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. 

6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.  

7. Работающий продукт — основной показатель прогресса. 

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

9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. 

10.Простота — искусство минимизации лишней работы — крайне необходима.

 11.Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. 

12.Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Краткое видео о том, что такое Scrum (english):

Что такое Scrum?

Scrum – это одна из нескольких методологий гибкой разработки ПО:

• Scrum
• Lean
• Feature Driving Development
• Extreme Programming
  

Scrum процесс на одном листе:

Scrum – это спортивный термин, который пришел к нам из регби, и представляет собой фигуру, которую образуют игроки перед началом игры.

Артефакты в Scrum

В скрам используется всего четыре артефакта:

• Product Backlog
• Sprint Backlog
• Sprint Goal
• Sprint Burndown Chart

Product backlog:

• Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
• Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
• Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
• Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

На скриншоте ниже представлен Backlog проекта. Команда проекта выбрала 2 требования в Sprint#3 (Project Backlog в JIRA):

Sprint backlog:

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

Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на Kanban-доске.

Sprint Goal

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

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

Sprint Burndown Chart

• дословно “диаграмма сгорания”
• в качестве “сгорающих” элементов выступают человеко-часы или идеальные единицы (Story Points).
• диаграмма обновляется каждый раз, когда завершается какая-либо задача.

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

Роли в Scrum

В скрам используется всего три роли:

• Product Owner
• Scrum Master
• Team.

Роль Product Owner

• формулирует требования
• приоритезирует требования
• корректирует приоритеты на каждом спринте
• несет персональную ответственность за ценность требований для рынка/пользователей
• отвечает за взаимодействие с рынком
• только один человек

Product Owner – это представитель подразделения, которое владеет разрабатываемым продуктом. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

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

В некоторых случаях допустимо назначить более одного человека на роль Product Owner.

Но в этом случае необходимо назначить среди них “главного”, который будет авторизовать требования в Bcaklog’e и лично расставлять приоритеты.

Роль Scrum Master

• следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
• организует работу команды и обеспечивает её всем необходимым
• защищает команду, несёт ответственность за её эффективность
• только один человек.

Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет “администратор”. Скрам Мастер организует работу команды проекта, но не вмешивается в её работу.

• Скрам мастер не назначает людей на задачи – это делает сама команда;
• Мастер не заставляет людей делать работу – это ответственность команды;
• Мастер не указывает Product Owner какие требования он должен написать – это работа владельца продукта.

Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

Функции Scrum Master’a существенно шире, но чтобы пояснить их все нужна отдельная статья. Пишите в комментариях, если таковая нужна.

Team (команда проекта)

• кросс-функциональная
• взаимозаменяемая
• самоорганизующаяся
• с фиксированным составом (в ходе спринта)
• 4-10 человек.

Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

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

Команда НЕ принимает решений:

• какие требования являются приоритетными – это делает Product Owner.

Ритуалы (процессы в Scrum)

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

Ритуалы в скрам это:

• Sprint Planning Meeting
• Daily Meeting
• Sprint Review
• Retrospective

Sprint Planning Meeting (встреча по планированию спринта)

• выполняется всей командой перед началом спринта
• команда выбирает требования из Product Backlog и формирует Sprint Backlog
• если требуется учесть взаимосвязи между операциями, то это делается здесь
• команда декомпозирует требования на задачи (tasks)
• каждая задача проходит оценку в трудозатратах или универсальных единицах
• во время встречи Product Owner отвечает на вопросы команды.

Встреча, которая проводится перед началом каждого спринта. Структура встречи:

• представление и пояснение Product Owner’ом списка требований
• вопросы со стороны команды
• /рекомендуется перерыв/
• декомпозиция требований на задачи (tasks)
• оценка задач по методу Planning Poker.

Встреча простая по сути, но крайне сложная по содержанию. В начале проекта может занимать 5-6 часов. И только после 3-4 спринта встреча становится более оперативной и длится 2-3 часа. Крепитесь.

Daily Meeting (ежедневная встреча команды).

Из названия понятно, что встреча проводится ежедневно. Основные принципы:

• проходит ежедневно и только в одно и то же время;
• встреча проходит только стоя;
• поэтому длительность встречи не более 15 минут;
• чтобы успеть каждый должен ответить всего на 3 вопроса: что я делал вчера, чем я занимаюсь сегодня, какие есть проблемы?

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

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

Встреча команды эффективно проводить напротив Kanban доски, на которой отражены все задачи спринта.

Sprint Review – сдача спринта Product Owner

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

Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

Структура встречи:

• команда зачитывает требования из Sprint Backlog
• по каждому критерию приемки происходит демонстрация полученных результатов
• каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
• каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

На встрече могут присутствовать любые сотрудники организации или просто заинтересованные лица. Важно, чтобы право голоса имели только участники Scrum процесса (Produt Owner, Team, Scrum Master).

Никаких презентаций в PowerPoint на встрече, если вы правильно меня поняли!

Retrospective

Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.

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

• какие решения должна принять команда, чтобы сделать процесс более предсказуемым?
• какие проблемы мешают команде выполнять взятые на себя обязательства?
• как улучшить взаимодействие с Product Owner’ом?
• какие ошибки совершает команда и почему.

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

Почему появился Agile?

Теперь немного слов о том, как и зачем появился этот подход? История возникновения этого подхода стала ответом на запросы отрасли:

1. Заказчик не может сформировать четкие требования к ПО;
2. Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе;
3. Заказчики и разработчики ПО не удовлетворены процессом взаимодействия.

#1 Заказчик не может сформировать четкие требования к ПО

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

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

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

В традиционных «водопадных» моделях руководитель проекта минимизирует изменения в проекте, используя для этого отдельные процессы – управление изменениями. Но если требования будут меняться раз в месяц, то управление изменениями становится трудоемким и замедляет ход проекта.

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

#2 Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе

К середине 90-х разрабатываемое ПО было в основном десктопным и его требовалось устанавливать на каждый отдельный компьютер (например, MS Word). С появлением веб-приложений внедрение новой функциональности стало происходить быстрее: требовалось развернуть приложение только на сервере и все пользователи получали к нему доступ. Эта инновация серьезно усилила конкуренцию между компаниями: тот, кто применил новую технологию раньше других – выигрывает рынок и клиентов.

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

#3 Заказчики и разработчики не удовлетворены процессом взаимодействия

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

Основная идея agile – сотрудничество с заказчиком важнее, чем контрактные обязательства. И поэтому agile-методы стремятся к уменьшению объема документации. Это позволяет Заказчику платить только за результат, имеющий ценность для бизнеса.

При этом agile не отказывается от формулирования требований. Заказчик (в agile – владелец продукта, product owner) предъявляет требования в упрощенном виде и на сценариях работы пользователей.

Резюме

Agile-философия проста. Agile-принципы разумны. Но переход к реальному применению agile – это серьезный вызов для каждой команды. Требуется не только освоить новый подход к управлению проектами, но также подобрать людей, способных работать в agile режиме.

Автор: PM Angel

Методология Agile и Scrum для чайников: в чём разница и преимущества?

Agile и Scrum методология — в чем разница? Их часто путают, но разъясним все подробно, чтобы вы этого не делали.

Agile и Scrum — это гибкие методологии, которые применяют для управления IT-проектами, чтобы правильно контролировать все процессы и организовывать эффективную работу.

 

Методология Agile

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

Agile несет в себе 4 важных свойства:

1. Коммуникация между людьми превыше инструментов.

2. Функционирующий продукт превыше его детального описания.

3. Прямая коммуникация с заказчиком превыше обсуждения письменных договоренностей.

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

Всего таких свойств у Agile насчитывается 12, но именно эти 4 делают данную методологию популярной и отличной от остальных. Главным образом привлекает «динамичность» этой методологии, потому что во многих проектах изменения могут вноситься ежедневно, особенно если проект — это стартап. Поэтому всем нужно быть готовыми быстро адаптироваться к новым условиям разработки. Не каждая методология дает такие возможности. При этом подобный динамичный подход к разработке имеет и свои минусы. Например, невозможно точно установить сроки и возможный бюджет разработки, потому что в любой день может что-то измениться. Поэтому Agile не рекомендуют применять, если в проекте жестко контролируются сроки и бюджет.

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

• нет необходимости составлять подробное техническое задание перед стартом разработки, так как вместо этого просто формируется перечень задач с приоритетом их выполнения;

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

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

 

Методология Scrum 

Методология Scrum входит в философию Agile. По Scrum работают в небольших проектах, где можно задействовать 7-9 специалистов.

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

 

Как работает методология Scrum 

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

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

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

 

Методология Scrum: распределение ролей

Методология Scrum подразумевает следующее распределение ролей:

1. Product Owner. Это заказчик программного продукта, который является посредником между разработчиками и пользователями продукта. Он знает о будущем продукте все, так как именно он формирует требования к программному продукту. 

2. Scrum Master. Это один человек из команды разработчиков, который, по сути, является лидером команды. Именно он следит за качественным и своевременным исполнением задач по разработке программного продукта. Также этот специалист отчитывается от лица команды перед вышестоящими руководителями.

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

Методология Scrum к команде разработчиков предъявляет свои требования, например:

• удаленно у Scrum практически никто не работает;

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

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

• профессионализм, стабильность, постоянство, ответственность и т. д. — это само собой подразумевается.

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

Для контроля Scrum-команд применяют 2 свойства:

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

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

 

Методология Scrum и Agile: роль визуальных досок

Отличительная особенность данных методологий — это применение визуальных досок. Доски могут быть разные: настенные или онлайн. Главная причина их применения — чтобы у команды перед глазами всегда был прогресс и результат их работы.

Визуальная доска — это «рабочая область» всей команды. В зависимости от проекта в роли таких досок могут выступать разные инструменты: 

 

Отличие Scrum от Agile

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

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

Agile Project Management For Dummies Cheat Sheet

Авторы: Mark C. Layton and

Обновлено: 03-11-2021

Из книги: Agile Project Management For10000 Dummies 90

Посмотреть книгу Купить на Amazon

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

Гибкая разработка продуктов направлена ​​на постоянное совершенствование, гибкость масштаба, вклад команды и получение важных ценных результатов. Гибкие подходы к разработке включают схватку как основу для демонстрации прогресса, экстремальное программирование (XP) для предварительного повышения качества и бережливое мышление для устранения потерь. Эти и многие другие инструменты и методы помогают организациям, командам и отдельным лицам придерживаться Agile-манифеста и 12 принципов Agile, в которых основное внимание уделяется небольшим, долгоживущим, самоорганизующимся командам, эффективным коммуникациям, постоянно выпускаемому продукту и гибкости.

© Rawpixel. com / Shutterstock.com

Манифест гибкой разработки программного обеспечения

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

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

• Индивиды и взаимодействие через процессы и инструменты
• Рабочее программное обеспечение поверх исчерпывающей документации
• Сотрудничество с клиентами по поводу переговоров по контракту
• Реагирование на переход по плану

То есть, хотя предметы справа имеют ценность, мы больше ценим предметы слева».

© Agile Manifesto Copyright 2001: Кент Бек, Майк Бидл, Ари ван Беннекум, Алистер Кокберн, Уорд Каннингем, Мартин Фаулер, Джеймс Греннинг, Джим Хайсмит, Эндрю Хант, Рон Джеффрис, Джон Керн, Брайан Марик, Роберт С. Мартин, Стив Меллор, Кен Швабер, Джефф Сазерленд, Дэйв Томас.

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

12 Принципов Agile

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

1. Наивысшим приоритетом для нас является удовлетворение клиента за счет своевременной и непрерывной поставки ценного программного обеспечения.
2. Приветствуйте меняющиеся требования, даже на поздних стадиях разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента.
3. Доставляйте работающее программное обеспечение часто, от нескольких недель до нескольких месяцев, отдавая предпочтение более коротким временным рамкам.
4. Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.
5. Создавайте проекты вокруг целеустремленных людей. Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы.
6. Самый эффективный и действенный метод передачи информации команде разработчиков и внутри нее — беседа лицом к лицу.
7. Работающее программное обеспечение является основным мерилом прогресса.
8. Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок.
9. Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
10. Простота — искусство максимального увеличения объема незавершенной работы — имеет важное значение.
11. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
12. Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.

Дорожная карта достижения ценности Platinum Edge

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

Дорожная карта к ценности.

Ниже приводится описание этапов Дорожной карты по достижению ценности:

• На этапе 1 владелец продукта определяет видение продукта. Видение продукта — это пункт назначения или конечная цель вашего продукта. Видение продукта включает в себя внешние границы того, каким будет ваш продукт, чем продукт отличается от продуктов конкурентов, как продукт будет поддерживать стратегию вашей компании или организации, кто будет использовать продукт и почему люди будут использовать продукт. При более длительных усилиях по разработке пересматривайте видение продукта не реже одного раза в год.
• На этапе 2 владелец продукта создает дорожную карту продукта. Дорожная карта продукта — это высокоуровневое представление требований к продукту с общими временными рамками, когда вы будете разрабатывать эти требования. Это также дает контекст для видения, показывая материальные функции, которые будут созданы во время разработки. Определение требований к продукту, а затем определение приоритетов и приблизительная оценка усилий по этим требованиям позволяют установить темы требований и выявить пробелы в требованиях. Владелец продукта при поддержке команды разработчиков и заинтересованных сторон должен пересматривать дорожную карту продукта не реже одного раза в полгода.
• На этапе 3 владелец продукта создает план выпуска. План выпуска определяет общий график выпуска рабочих функций для заказчика. Релиз служит промежуточной границей, относительно которой скрам-команда может мобилизоваться. Продукт, разработанный с использованием гибких методов, будет иметь много выпусков, причем функции с наивысшим приоритетом появятся в первую очередь. Вы создаете план выпуска в начале каждого выпуска, который обычно составляется не реже одного раза в квартал. Релизы также могут происходить чаще. Некоторые организации выпускают несколько раз в день.
• На этапе 4 владелец продукта, команда разработчиков и скрам-мастер планируют итерации, также называемые спринтами, и начинают создавать функциональные возможности продукта в этих спринтах. Сеансы планирования спринта проводятся в начале каждого спринта. Во время планирования спринта скрам-команда определяет цель спринта, которая устанавливает непосредственные границы работы, которую команда прогнозирует выполнить в течение спринта, с требованиями, которые поддерживают цель и могут быть выполнены в спринте. Скрам-команда также описывает, как выполнить эти требования.
• На этапе 5 команда разработчиков проводит ежедневные схватки во время каждого спринта для согласования приоритетов дня. На ежедневном скрам-совещании вы обсуждаете, что вы завершили вчера, что повлияет на работу, которую предстоит выполнить сегодня, над чем вы будете работать сегодня, а также любые препятствия, которые у вас есть, чтобы вы могли немедленно решать проблемы.
• На этапе 6 скрам-команда проводит обзор спринта в конце каждого спринта. В обзоре спринта вы демонстрируете работающую функциональность заинтересованным сторонам продукта.
• На этапе 7 схваточная команда проводит ретроспективу спринта. Ретроспектива спринта — это собрание, на котором скрам-команда обсуждает завершенный спринт с точки зрения своих процессов и среды и строит планы по улучшению процессов в следующем спринте. Как и обзор спринта для проверки и адаптации продукта, ретроспектива спринта проводится в конце каждого спринта для проверки и адаптации процессов и среды команды.

Роли в гибкой разработке продуктов

Для успешной разработки продукта требуется совместная и совместная команда людей. Agile-команды по продуктам состоят из многих людей и включают следующие пять ролей:

• Владелец продукта: Лицо, ответственное за преодоление разрыва между заказчиком, заинтересованными сторонами бизнеса и командой разработчиков, способствуя сотрудничеству между всеми тремя ролями. Владелец продукта является экспертом по продукту, потребностям и приоритетам клиента. Владелец продукта ежедневно работает с командой разработчиков, помогая прояснить требования и оградить их от шума бизнес-приоритизации. Владелец продукта, прежде всего, должен иметь право быть решительным, каждый день принимая трудные бизнес-решения.
• Члены команды разработчиков: Люди, которые создают продукт. Разработчики, программисты, аналитики, тестировщики, дизайнеры, писатели, инженеры, редакторы и все, кто непосредственно участвует в создании продукта, являются членами команды разработчиков. Члены команды разработчиков являются кросс-функциональными и обладают множеством навыков, которые они вносят в работу по разработке продукта. Что наиболее важно, члены команды разработчиков универсальны и могут разными способами способствовать достижению целей продукта.
• Скрам-мастер: Лицо, ответственное за поддержку команды разработчиков, устранение организационных препятствий и помощь команде и организации в принятии и внедрении гибких ценностей и принципов в их практике и процессах. Скрам-мастера — это лидеры-слуги, и они наиболее эффективны, когда обладают организационным влиянием, то есть способностью влиять на изменения в организации без официальных полномочий.
• Заинтересованные стороны: Любой, кто интересуется продуктом. Заинтересованные стороны не несут окончательной ответственности за продукт, но они вносят свой вклад и зависят от результата продукта. Группа заинтересованных сторон разнообразна и может включать людей из разных отделов или даже разных компаний. Чтобы усилия по разработке продукта были успешными, необходимо вовлекать заинтересованные стороны, предоставляя регулярную обратную связь и поддержку команде разработчиков и владельцу продукта. Эта роль не входит в состав скрам-команды, но мы прямо признаем участие этой роли в повышении успеха скрам-команды.
• Наставник или коуч по Agile: Кто-то, кто имеет опыт внедрения методов гибкой разработки продуктов и может поделиться этим опытом с организацией. Agile-наставник может предоставить ценную обратную связь и совет новым командам и командам, которые хотят работать на более высоком уровне. Хотя agile-наставники не несут ответственности за выполнение разработки продукта, они должны иметь опыт применения agile-принципов в реальности и быть осведомленными о многих agile-подходах и методах. Эта роль не входит в состав скрам-команды, но мы явно признаем участие этой роли, чтобы помочь улучшить командный успех.

Артефакты гибкой разработки продукта

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

.

• Заявление о видении продукта: Вдохновляющая презентация или краткое изложение, чтобы сообщить, каким будет ваш продукт и как ваш продукт поддерживает стратегии компании или организации. В заявлении о видении должны быть сформулированы цели продукта. Этот артефакт находится за пределами схватки, но повышает успех скрам-команды.
• Дорожная карта продукта: Дорожная карта продукта — это высокоуровневое начальное представление бэклога продукта, необходимого для реализации видения продукта. Это также позволяет команде Scrum наметить общие сроки, когда вы будете разрабатывать и публиковать эти требования. Дорожная карта продукта — это первоначальный и высокоуровневый обзор невыполненной работы по продукту, в котором выявляются пробелы и схожие функции, что позволяет комитету по финансированию принимать решения с достаточно полной картиной. Этот артефакт находится за пределами схватки, но повышает успех скрам-команды.
• Бэклог продукта: Список дел по продукту — полный список того, что входит в объем работ по вашему продукту, отсортированный по приоритету. После того, как у вас есть первое требование, у вас есть бэклог продукта.
• План выпуска : Общий график следующего набора функций для выпуска для заказчика. Этот артефакт находится за пределами схватки, но повышает успех скрам-команды.
• Журнал спринта: Цель, пользовательские истории и задачи, связанные с текущим спринтом.
• Приращение: Работающая функциональность продукта, продемонстрированная заинтересованным сторонам в конце спринта, которая потенциально может быть отправлена ​​заказчику.

Мероприятия по гибкой разработке продуктов

Большинство продуктов используют различные уровни планирования. Усилия по гибкой разработке продуктов включают семь повторяющихся событий:

• Планирование продукта: Первоначальное планирование вашего продукта. Планирование продукта включает в себя создание заявления о видении продукта и дорожной карты продукта и может быть выполнено всего за полдня. Это мероприятие не относится к схватке, но способствует успеху скрам-команды.
• Планирование выпуска: Планирование следующего набора функций продукта для выпуска и определение ближайшей даты запуска продукта, вокруг которой может мобилизоваться команда scrum. При гибкой разработке продукта вы планируете по одному выпуску за раз. Это мероприятие не относится к схватке, но способствует успеху скрам-команды.
• Спринт: Короткий цикл разработки, в ходе которого команда создает потенциально готовую к поставке функциональность продукта. Спринты, термин scrum для итераций, обычно длятся от одной до четырех недель. Спринты могут длиться всего один день, но не более четырех недель. Спринты должны оставаться одинаковой продолжительности на протяжении всей разработки продукта, что позволяет командам более точно планировать будущую работу на основе их прошлых результатов.
• Планирование спринта: Встреча в начале каждого спринта, на которой скрам-команда определяет цель спринта. Они также определяют требования, которые поддерживают эту цель и будут частью спринта, а также отдельные задачи, которые необходимо выполнить для выполнения каждого требования.
• Ежедневная схватка: 15-минутное совещание по координации и синхронизации, проводимое каждый день в рамках спринта, на котором члены команды разработчиков сообщают, что они завершили накануне, что влияет на работу, которую необходимо выполнить сегодня, что они завершат в текущий день, и есть ли у них блокпосты.
• Обзор спринта: Встреча в конце каждого спринта, представляемая владельцем продукта, на которой команда разработчиков демонстрирует заинтересованным сторонам рабочие функции продукта, реализованные в ходе спринта, а владелец продукта собирает отзывы для обновления списка невыполненных работ.
• Ретроспектива спринта: Встреча в конце каждого спринта, на которой скрам-команда проверяет и адаптирует свои процессы, инструменты, среду, навыки, общение и отвлекающие факторы; обсуждает, что прошло хорошо, а что можно изменить; и составляет план внедрения улучшений в следующем спринте.

Ресурсы, организации и сертификаты для разработки продуктов Agile

Существует большой мир разработки продуктов Agile. Вот несколько полезных ссылок на членов сообщества практиков Agile:

• Scrum For Dummies : В 2018 году мы опубликовали второе издание Scrum For Dummies (Wiley) в качестве практического руководства не только по Scrum, но и по Scrum в отраслях и бизнес-функциях за пределами информации. технологии (ИТ) и разработка программного обеспечения. Скрам можно применять в любой ситуации, когда вам нужна ранняя эмпирическая обратная связь о том, что вы строите или преследуете.
• Scrum Alliance : Scrum Alliance — это некоммерческая профессиональная членская организация, которая способствует пониманию и использованию Scrum. Альянс достигает этой цели, продвигая курсы обучения и сертификации по Scrum, проводя международные и региональные встречи по Scrum и поддерживая местные сообщества пользователей Scrum. Чтобы найти группу пользователей scrum в вашем регионе, выполните поиск по своему местоположению.
• Agile Alliance : Agile Alliance — первоначальное глобальное agile-сообщество, миссией которого является помощь в продвижении 12 agile-принципов и общих agile-практик, независимо от подхода. На сайте Agile Alliance есть обширный раздел ресурсов, который включает статьи, видео и презентации. Найдите список независимых и местных групп сообщества agile по всему миру.
• Международный консорциум Agile (ICAgile ): ICAgile — это общественная организация, помогающая людям стать гибкими посредством обучения, повышения осведомленности и сертификации. Его дорожная карта обучения обеспечивает поддержку карьерного роста в области гибкости бизнеса, корпоративного и группового коучинга, управления стоимостью, управления доставкой, человеческих ресурсов, гибкого проектирования, гибкого тестирования и DevOps.
• Помните о продукте и емкости для продукта : Mind the Product — крупнейшее в мире сообщество людей, увлеченных продуктом. Они также организовали встречи ProductTank, чтобы лидеры продуктов могли общаться, делиться информацией и учиться друг у друга. Насчитывая более 150 000 участников по всему миру, они предлагают блоги, глобальные, региональные и местные мероприятия, местные встречи и обучение от ведущих экспертов по управлению продуктами со всего мира. Ресурсы в ProductTank, как правило, высокого качества, а контент уникален и актуален для задач, стоящих перед agile-командами по разработке продуктов. Найдите местную встречу ProductTank в вашем районе.
• Институт бережливого производства : Институт бережливого производства публикует книги, блоги, базы знаний, новости и мероприятия для более широкого сообщества мыслителей и практиков бережливого производства. Когда вы занимаетесь гибкой разработкой продукта, не забывайте включать бережливое мышление во все, что вы делаете. Lean.org — это хорошая стартовая площадка для изучения тем бережливого производства, имеющих отношение к вашей ситуации.
• Экстремальное программирование: Рон Джеффрис был одним из создателей подхода к разработке экстремального программирования (XP) вместе с Кентом Беком и Уордом Каннингемом. Рон предоставляет ресурсы и услуги для поддержки развития XP на своем сайте ronjeffries.com. «Что такое экстремальное программирование?» раздел сайта обобщает основные понятия XP. Другие статьи и ресурсы по экстремальному программированию также доступны в формате вики.
• PMI Agile Community : Институт управления проектами (PMI) является крупнейшей в мире некоммерческой ассоциацией по управлению проектами. С почти 3 миллионами членов в большинстве стран по всему миру. PMI поддерживает agile-сообщество практиков и несколько agile-сертификатов, в том числе PMI Agile Certified Practitioner (PMI-ACP) и серию сертификатов Disciplined Agile (DA).
• Platinum Edge : Компания Platinum Edge, основанная в 2001 году, является одним из первых agile-трансформаторов. Их блог предоставляет информацию о методах, инструментах и ​​инновационных решениях, появившихся в результате их работы с клиентами и более широким agile-сообществом. Вы также можете узнать о следующих услугах, которые помогут сделать ваш переход успешным:
• Agile-аудиты: Оценка вашей текущей организационной структуры и процессов для создания гибкой стратегии внедрения. Эта оценка может включать предоставление отзывов о ваших текущих усилиях по переходу на Agile, чтобы помочь вам оценить, приносят ли сделанные вами инвестиции ожидаемые результаты.
• Recruiting: Помощь в поиске подходящих людей для запуска ваших scrum-команд, включая scrum-мастеров, владельцев продуктов, разработчиков и agile-наставников.
• Обучение: Публичное и частное обучение и сертификация Agile и Scrum, включая Certified ScrumMaster (CSM), Advanced Certified ScrumMaster (A-CSM), Certified Scrum Product Owner (CSPO), Certified Scrum Developer (CSD), LeSS, [email protected ], подходы SAFe к масштабированию и подготовка к тесту PMI Agile Certified Practitioner (PMI-ACP).
• Трансформация: Ничто не является более важным фактором будущего успеха, чем надлежащее В качестве продолжения agile-обучения в вашу организацию внедряются профессиональные agile-наставничество и коучинг, чтобы обеспечить применение правильных практик в реальном мире.

Об этой статье

Эта статья взята из книги:

• Agile Project Management For Dummies,

Об авторах книги:

Марк С. Лейтон, «Mr. Agile 4, 8 9028» исполнительный директор и советник Совета директоров. Он является председателем Agile Leadership Network в Лос-Анджелесе, сертифицированным тренером по Scrum (CST) и основателем компании Platinum Edge, занимающейся agile-трансформациями. Марк также является соавтором книги Agile Project Management For Dummies. Дэвид Морроу — сертифицированный специалист по Scrum (CSP), сертифицированный коуч по Agile (ICP-ACC) и коуч по Agile для руководителей.

Марк С. Лейтон, «Мистер Agile ^® », является исполнительным директором и советником Совета директоров. Он является председателем Agile Leadership Network в Лос-Анджелесе, сертифицированным тренером по Scrum (CST) и основателем компании Platinum Edge, занимающейся agile-трансформациями. Марк также является соавтором книги Agile Project Management For Dummies. Дэвид Морроу — сертифицированный специалист по Scrum (CSP), сертифицированный коуч по Agile (ICP-ACC) и коуч по Agile для руководителей.

Марк К. Лейтон, «Мистер Agile ^® », является исполнительным директором и советником Совета директоров. Он является председателем Agile Leadership Network в Лос-Анджелесе, сертифицированным тренером по Scrum (CST) и основателем компании Platinum Edge, занимающейся agile-трансформациями. Марк также является соавтором книги Agile Project Management For Dummies. Дэвид Морроу — сертифицированный специалист по Scrum (CSP), сертифицированный коуч по Agile (ICP-ACC) и коуч по Agile для руководителей.

Этот артикул находится в категории:

• Управление проектами ,

Гибкое управление проектами для чайников — лучшие практики и советы!

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

Гибкое управление проектами для чайников.

Что такое Agile?

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

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

«Мы находим лучшие способы разработки программного обеспечения
, делая это и помогая в этом другим.
Благодаря этой работе мы пришли к ценности:

Люди и взаимодействие важнее процессов и инструментов
Рабочее программное обеспечение важнее всеобъемлющей документации
Сотрудничество с клиентами важнее переговоров по контракту
Реагирование на изменения важнее следования плану

То есть, в то время как предметы на
справа имеют ценность, мы больше ценим предметы слева».

Четыре элемента справа являются основой 12 принципов (шагов) Agile. Что это такое и как их использование может принести пользу вам и вашему проекту? Хотите стать скрам-мастером?

12 принципов гибкой разработки

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

1. Удовлетворенность клиентов превыше всего

При использовании гибкого управления проектами важно помнить, что удовлетворенность клиентов превыше всего. И лучший способ удовлетворить клиента – это непрерывная поставка качественного программного обеспечения. Такой подход способствует не только отличному программному обеспечению, но и хорошим, дружеским отношениям с клиентами. Видение продукта должно быть ясным для команды и клиента! Четкие вопросы могут помочь менеджеру создать лучший продукт.

2. Ценить и адаптироваться к изменениям

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

3. Быстрая и постоянная доставка

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

4. Командная работа – проектная команда!

Четвертый принцип гласит, что «Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта». Это означает, что гибкий метод ценит командную работу и необходимость включения всех людей, вовлеченных в проект . Проект, управляемый с помощью agile, подобен машине, состоящей из множества отдельных частей, но когда они собраны вместе, все работает идеально! Распечатайте обзор (или добавьте его в свои заметки!) — слушайте команду! Личные истории очень важны для хорошей атмосферы -> пусть ваша команда чувствует себя хорошо с вами! У вас с ними много общего! Конечно!

5. Доверяйте и верьте в свою команду

Эта методология направлена ​​на создание отличных команд мотивированных, профессиональных и опытных людей. Вот почему вам нужно доверять им и верить в них. Авторы манифеста отмечают, что вам нужно поддерживать свою команду всеми необходимыми ресурсами и доверять им, когда дело доходит до выполнения работы. Важно, чтобы клиент верил в команду, которую он выбрал, но гибкая методология также предполагает, что все члены команды поддерживают друг друга. Когда команда работает таким образом, они делают свою работу лучше – просто и понятно! Это очень поможет вашей компании!

6. Личные беседы

Агилист считают , что личные беседы являются наиболее эффективным и действенным методом общения . И это касается как вашего общения со своей командой, так и общения внутри самой команды. Лучшее общение = лучшее сообщество. Передача информации таким образом обеспечивает успешные проекты и отличные продукты?

7. Работающее ПО как показатель прогресса

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

8. Устойчивое развитие

Еще одним важным моментом гибкой методологии является устойчивое развитие. Все люди, вовлеченные в проект — разработчики, спонсоры или пользователи — должны иметь возможность «[…]поддерживать постоянный темп на неопределенный срок». Это обеспечивает непрерывность процесса и делает его в целом более плавным.

9. Техническое совершенство и хороший дизайн

Управление этим проектом уделяет большое внимание отличной разработке и дизайну. Почему? Потому что подстроиться под изменения проще, когда то, что ты настраиваешь (программный продукт) , сделано не просто правильно, а почти идеально . Как заявляют авторы Agile Manifesto: «Постоянное внимание к техническому совершенству и хорошему дизайну повышает гибкость». И мы верим, что это правда!

10. Простота

Простота не зависит от программного обеспечения — оно может быть настолько сложным, насколько вам нужно. Но если что-то можно сделать лучше с меньшими затратами — так и надо делать. Речь идет о максимизации количества невыполненной работы. Завершить и внедрить. Будьте уверены в точности разработки и невыполненной работы по продукту. Agile-лидерство — это внедрение Agile в вашу повседневную жизнь.

11. Самоорганизующиеся команды

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

12. Постоянное совершенствование

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

Основные преимущества гибкого управления проектами

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

• Повышенная гибкость
• Повышенная производительность
• Повышенная прозрачность
• Результаты более высокого качества
• Ретроспективное исследование

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