Принцип agile: Четыре ценности и 12 принципов Agile-управления проектами

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

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

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

Уделяйте меньше внимания правилам и сосредоточьтесь на результатах.

Советы практиков Agile

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

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

Текст: Хоа Лоранджер
Перевод, дизайн и верстка: Светлана Граудт

Если материал вам понравился, расскажите о нем друзьям. Спасибо!

Читайте также:

#madeontilda Лаборатория дизайн-мышления Wonderfull

Визуальная иерархия сайта: оформление и организация контента

Как стать дизайнером — 3 составляющие профессии дизайнера

Как привлечь новых пользователей с подходом Jobs To Be Done

Что такое UX дизайн?

В чем заключается работа дизайнера — правильный дизайн от Дэниэла Бурка

Основы сторителлинга для UX

15 навыков для успешной коммуникации с клиентами

Опыт работы с брендингом и запуском стартапов в агентстве Red Antler

Пол Адамс, Intercom: «Цели дают силы сказать „нет“ вещам, которые отвлекают»

Дизайн сайтов — тренды 2018: 6 трендов в создании сайтов для небольших компаний

Сторителлинг — как использовать силу историй для продвижения бренда

Agile ― что это такое, для чего нужен принцип аджайл и как его внедрить в управление продуктами

По данным исследования компании Digital. ai, в 2021 году 86% команд разработчиков программного обеспечения используют Agile-методики. Также, по данным ежегодного отчёта Scrumtrek, 33% финансовых компаний активно пробуют приёмы Аджайл-технологии. В этой статье мы расскажем, что же это такое и почему популярно.

Что такое Аджайл простыми словами

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

Как появился Agile и какие ценности он продвигает

Agile родился в головах IT-специалистов. К 2000-м годам программирование начало активно развиваться. Система создания ПО обросла огромной документацией и длинным путём к созданию готового продукта. Стало ясно, что в индустрии нужно что-то менять. Нужны качественно новые практики организации рабочих процессов. С конца 90-х годов программисты со всего мира делились своими идеями. Уже в то время родилась теория экстремального программирования, о которой мы ещё поговорим подробнее. Но знаковой оказалась встреча в 2001 году, которая и положила начало новой философии.

11-13 февраля 2001 года группа программистов в очередной раз решила собраться для обсуждения проблем. Местом встречи они выбрали горнолыжный курорт Snowbird в горах Уосатч в штате Юта. Они собрались не только покататься на лыжах, отдохнуть, но и общими усилиями найти решения проблем в организации процесса разработки ПО. Из 20 приглашённых приехало 17 специалистов. В результате этой встречи родились не просто идеи нового подхода к программированию, а целый манифест. Тогда же участники и назвали его Agile.

Agile-манифест

Философия Agile, отражённая в манифесте, состоит из 4-х ценностей и 12-ти принципов.

Ценности:

1. Взаимодействие с людьми важнее рабочих процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с заказчиком важнее, чем согласование контракта.
4. Быстрая реакция на изменения важнее первоначального плана.

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

Принципы:

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

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

Принцип Agile и его методики

Итак, для чего нужен Agile? В рамках философии Agile появились конкретные методики, которые должны были помочь компаниям улучшить свои рабочие процессы. В список методик для управления продуктами вошли:

1. Экстремальное программирование (XP).
2. Kanban.
3. Scrum.
4. Бережливое производство (Lean).

Теперь по порядку рассмотрим каждую из этих методик.

Экстремальное программирование, или Extreme Programming

Эта методика появилась раньше манифеста Agile (1990-х годах), но отлично вписалась в концепцию. XP предназначена только для разработки ПО. Оно не может быть использовано в другом бизнесе или бытовых задачах. Главная цель методики ― сделать рабочий продукт быстро. В начале планирования итерации решается вопрос, какой функционал должно приобрести ПО в итоге. На этом планировании обязательно присутствует заказчик. Именно он должен согласовать цель итерации.

Внутри этой методологии есть 12 практик, которые позволяют ускорить программирование. Для примера в XP рекомендуют использовать парное программирование, рефакторинг (оптимизация кода), коллективное владение кодом.

Kanban

Kanban ― это подход к визуализации рабочего процесса. В рамках Kanban создаётся рабочая доска, на которой отражены все задачи команды. Доска разделена на этапы работы. Задачи перемещают между этими этапами. Благодаря такой визуализации каждый член команды и руководитель всегда видят, как продвигается работа. В нужный момент любой может присоединиться и помочь. После выпуска продукта можно подробно рассмотреть все этапы работы и выявить недочёты.

Scrum

Весь рабочий процесс состоит из коротких итераций ― спринтов. Спринты обычно длятся 1-4 недели. В начале каждого спринта проходит планирование задач. Команды должны быть маленькие не более 10 человек. В команду входят:

• Product Owner (владелец продукта). Общается с заказчиками и потребителями, планирует задачи.
• Scrum Master. Анализирует выполненные задачи и ищет способы улучшить процесс работы. Также проводит собрания и решает проблемы в команде.
• Development Team (команда специалистов). Это вся остальная команда, которая выполняет задачи по созданию продукта. Состоит из специалистов различного профиля.

Для Scrum характерны некоторые специфические правила и мероприятия.

В общем, Scrum продвигает идею небольших забегов. Цель каждого забега ― создать продукт или модернизировать его.

Бережливое производство, или Lean

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

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

Положительные и отрицательные стороны

Гибкий подход к разработке рабочего процесса приводит к некоторым очевидным преимуществам:

1. Продукты быстрее выходят на рынок. За счёт того, что на рынок выпускается более или менее готовый продукт и только потом дорабатывается, прибыль приходит раньше.
2. Высокое качество продукта. Из-за постоянно доработки по итогу качество продукта намного выше, чем когда версия продукта выпускается единожды.
3. Прозрачность работы. Так как и сотрудники, и заказчики, и пользователи постоянно взаимодействуют, весь процесс создания продукта становится прозрачным.
4. Увеличение прибыли. Так как продукт постоянно совершенствуется, в дальнейшем есть возможность легитимно повышать цену.

Несмотря на продвинутость и всеобщее признание подхода, у Agile есть и недостатки:

1. Мало предсказуемости. В самом начале проекта трудно понять, сколько времени и ресурсов вы в итоге потратите на разработку продукта. Если команда только переходит к гибкому подходу, это может посеять страх среди сотрудников. Не все готовы оперативно исправлять ошибки и внедрять идеи в продукт.
2. Много коммуникации. Не все готовы на постоянное и тесное сотрудничество. Чтобы разработчики быстро могли приступить к обновлениям и доработкам, заказчик должен быть доступен 24/7, ревьюить идеи и работу на каждом этапе. Это занимает много времени, и далеко не каждый к этому готов.
3. Есть риск переделывания работы. В любой момент заказчик или пользователь может в корне изменить свои желания и по правилам Agile нужно будет всё переделывать.
4. Снижение качества продукта для ускорения выпуска. Пытаясь успеть как можно раньше выпустить продукт, разработчики часто выводят в свет откровенно сырой продукт, который потом собирает негатив от пользователей.

Каким компаниям подходит Agile-подход

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

Для небольших проектов, например, создание рекламного баннера, скорее всего, внедрение сложных технологий не потребуется. Есть ТЗ и понятные этапы работы. Разве что можно создать доску, если проектов несколько. Такой подход добавит наглядности. Однако необходимости внедрения методологий Agile нет.

Однако есть проекты, которым обязательно нужен помощник в организации работы:

1. Проект обещает быть крупным и сложным. В этой ситуации вам нужно будет декомпозировать задачи и пытаться не потеряться в проекте.
2. Работа будет долгой. В процессе реализации долгого проекта может понадобиться много изменений. Только гибкий подход к процессам разработки поможет выпустить актуальный для пользователей продукт.
3. В проекте много неопределённости. Разработчики и производители гонятся за новизной. А там, где новизна, есть и неопределённость. Вы просто не сможете прописать путь создания продукта от начала и до конца. В этом случае лучше продвигаться маленькими шагами. Так вы точно сделаете меньше ошибок.

Этапы внедрения Agile

1. Выберите метод. Подробно изучите каждый метод и определите, какой поможет именно вашей команде.
2. Расскажите всей команде об Agile. Каждый сотрудник должен знать, в чём заключается суть концепции. Проведите обучение всей команды. Если есть возможность, пригласите сторонних специалистов, у которых есть опыт по внедрению Аджаил.
3. Организуйте процесс. Даже если все сотрудники будут разбираться в Agile-философии, всё равно нужен человек, который возьмёт на себя ответственность организовать процесс. Скорее всего, вам понадобится создать рабочие доски. Это может делать Scrum-мастер или руководитель отдела.
4. После первых нескольких итераций проанализируйте эффективность налаженной системы. У вас вряд ли с первого раза получится создать идеальную систему. Первое время придётся постоянно перестраивать процессы.

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

кому подходит, а кому нет

В статье рассказывается: 

1. Что такое методология Agile
2. Краткая история методологии Agile
3. Отличия Agile от Waterfall
4. 12 принципов метода Agile
5. Плюсы и минусы Agile
6. Где используется Agile
7. Нужен ли вашей команде Agile
8. Ключевые моменты в применении Agile
9. Когда не следует применять метод Agile
10. Книги про Agile

Что это такое? Методология Agile – это эффективная схема управления проектами. Ее разработали в 1990-х годах, но усовершенствовали чуть больше 20 лет назад. Изначально Agile придумали для работы над ПО, но со временем метод распространился и в других сферах деятельности. Существует много примеров, где схема зарекомендовала себя с положительной стороны. Ее обкатали Microsoft, Spotify, М.Видео, Иннополис и другие известные компании.

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

Что такое методология Agile

Итак, что такое Agile простыми словами? Agile – это особая продуктивная система управления проектами, в которой задействуется четыре ценности и 12 основополагающих принципов.

Упомянутые четыре ценности изложены в документе под названием манифест Agile (Agile Manifesto). Суть их в следующем:

1. В первую очередь, внимание к людям, их взаимодействиям. И лишь потом – к процессам и инструментам.
2. Главное – не документация к продукту, а его корректная работа.
3. Важнее на деле наладить плодотворное сотрудничество с заказчиком, чем тщательно выверять условия договора.
4. Важнее уметь оперативно подстраиваться под обстоятельства, чем строго следовать намеченному плану.

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

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

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

Для реализации Agile-проектов чаще всего применяются следующие фреймворки:

• Scrum;
• DSDM;
• Kanban;
• Экстремальное программирование.

Краткая история методологии Agile

По поводу момента зарождения принципов Agile сведения из разных источников неодинаковы. Как отправные точки указываются и 1960-е, и 1975-й, и 1990-е годы. Но все сходятся в одном: начало было положено Манифестом гибкой разработки программных продуктов, который так и называли — манифест Agile.

Год первого издания манифеста Agile – 2001. Ведущие разработчики специально собрались в штате Юта для того, чтобы обсудить проблемы отрасли (в частности – найти новые способы управления процессами разработок ПО) и подготовили текст манифеста.

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

Решение было найдено такое: проект следует разбивать на итерации (спринты). Тогда и разработка, и тестирование пойдет быстрее. Нужно показывать клиенту результаты каждой итерации (а не весь продукт целиком) и по результатам отзыва (ретроспективы) тут же вносить корректировки.

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

Отличия Agile от Waterfall

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

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

Вот основополагающие принципы Waterfall:

• Все требования должны быть сформулированы заблаговременно.
• Все этапы работ заранее определены, структурированы и упорядочены.
• Тестирование проводится по завершении работы над продуктом.

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

Топ-30 самых востребованных и высокооплачиваемых профессий 2022

Поможет разобраться в актуальной ситуации на рынке труда

Подборка 50+ ресурсов об IT-сфере

Только лучшие телеграм-каналы, каналы Youtube, подкасты, форумы и многое другое для того, чтобы узнавать новое про IT

ТОП 50+ сервисов и приложений от Geekbrains

Безопасные и надежные программы для работы в наши дни

pdf 3,7mb

doc 1,7mb

Уже скачали 14891

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

12 принципов метода Agile

Манифест Agile включает в себя 12 основных принципов планирования, обязательных к исполнению при работе над проектами. Эти принципы такие:

1. Приоритетная цель – быстрое и регулярное предоставление программного обеспечение заказчику, то есть, оперативное удовлетворение его интересов. Имеется в виду, что клиент получает по итогу не весь продукт целиком, а периодически и может видеть и оценивать промежуточные результаты.
2. Agile – это методология, при которой изменения возможны (и даже приветствуются) вплоть до завершающего этапа разработки. Эти изменения должны в итоге давать заказчику возможность успешно конкурировать. Разработчики манифеста обратили внимание, что при традиционном подходе вносить корректировки на поздних стадиях достаточно трудно. В то время как Agile позволяет максимально оперативно адаптировать проект к любым вновь появляющимся требованиям.
3. Желательно почаще запускать продукт в работу, с периодом от двух недель до двух месяцев. Интервальное планирование при подобном подходе позволяет это делать. Чаще всего команды, работающие по системе Agile, делят проект на спринты и по завершении каждого выдают готовый к работе продукт. Длительность этих спринтов варьируется в промежутке от 1 до 4 недель.
4. Заказчик и разработчики должны тесно сотрудничать на протяжении всего срока реализации проекта. Лишь при таком подходе методология Agile действительно покажет свою эффективность, а результатом станет отличный, качественный продукт. Совещания рекомендуется проводить каждый день с привлечением к ним команды Agile, представителей заказчика и прочих заинтересованных сторон.
5. Специалистов, занимающихся проектом, непременно необходимо хорошо замотивировать. Хотите получить качественный результат – доверьтесь профессионалам, обеспечьте им соответствующие условия для работы и всестороннюю поддержку. Концепция применения Agile подразумевает следующее: необходимо грамотно подобрать исполнителей на каждый участок проекта и дать им полную свободу действий. Специалисты при этом приглашаются с учетом их навыков, опыта, вне зависимости от занимаемых должностей. Задача менеджера проекта – не «давить» жёстким контролем, а давать максимальную поддержку и мотивацию.
6. Лучший способ взаимодействия и обмена данными (с самой командой и внутри неё) – это тесное общение. Разработчики манифеста придавали этому особое значение. Подчеркивалось, что участники должны иметь возможность работать в непосредственной близости друг от друга. Телефонные переговоры или переписка по e-mail не дают такого эффекта, как личный контакт. Если команда не может быть размещена в общем офисе, то для обеспечения невербального взаимодействия организовывайте видео-совещания.
7. Главный показатель результативности – это работающий продукт. Подход Agile подразумевает регулярную его демонстрацию. Именно это ставится во главу угла, а все прочие сопутствующие требования (вроде подготовки документации по проекту, соблюдения сроков и т.п.) отодвигаются на второй план.
8. Все заинтересованные стороны (разработчики, инвесторы, заказчики) должны быть готовы к бесконечному поддержанию рабочего ритма. И благодаря Agile это возможно. Данный принцип означает, что работа над проектом должна вестись в стабильном темпе, от одного шага итерации – к последующему и так далее. При таком подходе (с разбивкой всего процесса на части) возможность переработок сводится к минимуму, и сроки тоже, как правило, остаются соблюденными, если функционирующий результат регулярно демонстрируется. Плюс разбивка помогает организовать рабочие циклы, которые членам команды останется лишь повторять столько, сколько потребуется.
9. Повышению технических характеристик и в целом качеству разработок здесь уделяется большое внимание, что делает весь проект более гибким. На первом месте тут улучшение окончательного результата с постоянным прогрессированием. Задача команды – внедрять и внедрять инновации, улучшая каждую итерацию шаг за шагом.
10. Подчеркивается необходимость сведения к минимуму лишних действий, то есть, чем проще – тем лучше. Согласно принципам Agile, результат должен получиться рабочим и отвечать заявленным требованиям. Всё, что не имеет важности для клиента, или неоправданно увеличивает объёмы работ (дополнительные шаги, процессы, документы, задачи и т.п.), следует исключить.
11. Команды, которым предоставлена возможность самоорганизации, как правило, способны генерировать лучшие решения (и архитектурные, и технические). Один из принципов Agile состоит в том, чтобы привлекать к работе над проектом высококвалифицированных, самостоятельных профессионалов, давать достаточную мотивацию и широкие полномочия для формирования необходимой структуры. Им следует предоставить свободу действий, не контролировать слишком плотно, позволить самим принимать решения касательно внедрения инноваций.
12. Одна из задач команды – постоянно вносить корректировки в работу с целью повышения эффективности. Для этого требуется систематически анализировать процесс. Команда сама способна обеспечить достаточный рост, если у неё хороший уровень самомотивации, есть способность совершенствовать собственные навыки и применять их. Регулярные обсуждения результатов и возможных улучшений тут обязательны.

Плюсы и минусы Agile

Положительные аспекты:

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

Слабые стороны:

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

Где используется Agile

Изначально Agile использовался больше для разработки ПО, компьютерных игр, программных интерфейсов. Это были Google, Netflix, Microsoft, WordPress, Magna International, Spotify, Intronis, Ericsson, Dell, Adobe, Accenture, Riot Games, CH Robinson, Scrum Alliance.

Интенсив «Путь в IT» поможет:

• За 3 часа разбираться в IT лучше, чем 90% новичков.
• Понять, что действительно ждет IT-индустрию в ближайшие 10 лет.
• Узнать как по шагам c нуля выйти на доход в 200 000 ₽ в IT.

При регистрации вы получите в подарок:

«Колесо компетенций»

Тест, в котором вы оцениваете свои качества и узнаете, какая профессия в IT подходит именно вам

«Критические ошибки, которые могут разрушить карьеру»

Собрали 7 типичных ошибок, четвертую должен знать каждый!

Тест «Есть ли у вас синдром самозванца?»

Мини-тест из 11 вопросов поможет вам увидеть своего внутреннего критика

Хотите сделать первый шаг и погрузиться в мир информационных технологий? Регистрируйтесь и смотрите интенсив:

Только до 3 октября

Осталось 17 мест

На сегодняшний день Agile применяется уже значительно шире. К примеру, в производстве истребителей (Saab), сельскохозяйственной техники (General Electric и John Deere).

В России Agile стал востребован лишь спустя несколько лет (после появления на Западе), но его популярность здесь, пожалуй, ничуть не меньше, чем за рубежом. Данный подход к планированию успешно задействуется в сфере IT, на производственных предприятиях, в банках, ритейл-компаниях, во всевозможных онлайн-службах. В частности, это: First Line Software (сфера деятельности – разработка ПО), «М.Видео» (торговля электронной техникой), Dostаевский (компания по организации доставок), IVI (онлайн-кинотеатр), 12 Storeez (модный бренд одежды), НМЛК (сталелитейная компания).

ScrumTrek каждый год анализирует использование Agile в России. Результаты за 2020 год (были собраны данные по тысяче участников из 80 российских городов) следующие:

• Географически: 41 % исследованных команд работают в Москве, 14 % в Санкт-Петербурге, далее, в Перми – 6,4 %, в Казани и Иннополисе (специализированный научный IT-кластер) – 5,5 %, в Новосибирске – 5,4 %.
• По отраслям: сфера деятельность 42 % участников, использующих Agile – это IT, далее 18 % приходится на финансовые учреждения, 8 % — на промышленные предприятия, 7 % — на ритейл, 4,8 % — на телекоммуникации, 3,2 % — на энергетическую отрасль и 2,8 % — на консалтинг.
• 33 % команд применяют Agile при планировании проектов внутри собственной компании и при организации услуг для своих клиентов.
• 41 % применяют в качестве фреймворка от Agile систему Scrum. Это на 7 % меньше, чем в прошлом году, и на 9 % меньше, чем в 2018. Далее, Kanban в рамках Agile-подхода используют 23 % опрошенных. Это на 8 % больше, чем в 2019 и на 13 % больше, чем в 2018. Получается, что популярность Kanban постепенно растет, приближаясь к показателям к Scrum. А вот в мире рост использования Scrum составил с 54 % до 58 %, а Kanban – с 5 % до 7 % (что, кстати, втрое ниже, чем в России).
• 60 % предпочитают совмещать разные подходы, а 30 % имеют собственные методики или комбинированные варианты;

• 22 % считают себя высококомпетентными в применении Agile. В сравнении с прошлым годом это на 9 % больше. Многие пару лет назад были едва знакомы с принципами Agile, а теперь свободно ими владеют, задействуют разные подходы, разрабатывают собственные. Впрочем, данные исследования ведутся всего лишь в течение трех лет, и тут еще рано делать выводы о ценности и результативности Agile.

Нужен ли вашей команде Agile

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

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

По сути, Agile отличный инструмент для стартапов, но не для крупных компаний с множеством процессов, работа которых уже давно отлажена. Тут эффективнее себя показывают доступные для масштабирования элементы Agile вроде SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum).

Кстати, и для IT-сфеы Agile-подход – не панацея, тут отлично работает, например, DevOps. Это когда налаживается интеграция всех рабочих процессов и тесное взаимодействие между исполнителями.

А для тестирования новых идей (без многократного повторения всех этапов разработки) отлично годятся методики типа Customer Development, Design Thinking и др.

Есть еще более обобщенный метод Business Agility (ему буквально 2-3 года, переводится как «гибкость в бизнесе»). В его основе – тоже принципы Agile (подразумевающие быструю разработку продукта), плюс еще быстрое реагирование на изменение внешних условий, гибкий подход к постановке целей и задействию ресурсов.

Ключевые моменты в применении Agile

Система Agile применима для самых разных сфер бизнеса. Но прежде, чем внедрять, нужно «разложить по полочкам» порядок её практического применения.

Распределение ролей по Agile

Роли тут следующие:

1. Собственник продукта. Не вникает в технические тонкости процесса, но имеет точное представление о том, с какой целью и для кого этот продукт создается.
2. Координатор. Организует рабочий процесс, придает нужное направление действиям сотрудников.
3. Группа специалистов. Технические разработчики продукта.

Система иерархии в Agile

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

Пропускная способность процесса

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

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

Тут имеет значение сфера деятельности. В частности, на первом месте может быть:

• Value Based. То есть, оценивается, насколько задача прибыльна и полезна для бизнеса, помогает ли повышать его репутацию, решать проблемы пользователей.
• Technology Risk Based. Оценивается, насколько велики технологические риски в ходе выполнения задачи. К примеру, выдвигается слишком много требований, или велико воздействие внешних факторов и т. п.

График выполнения задач

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

Внедрение методологии Agile

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

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

Когда не следует применять метод Agile

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

Ниже описано четыре примера, в которых использовать Agile нет смысла:

• Результат проекта четко определен и не может быть изменен

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

• Изначально ставится задача многократного повторения результатов проекта

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

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

• Заинтересованные стороны отказываются от применения Agile

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

• Вы сами не готовы к использованию Agile

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

Понять, что компания не готова задействовать Agile, можно по следующим пяти признакам:

1. Суть гибкой методологии недопонята. Члены группы разработки не обучены, или не понимают в полной мере принципы, методы и модели Agile, то есть, полноценно применить данный инструмент они не могут.
2. Какая-то из заинтересованных сторон (заказчик, инвестор, исполнитель) не хотят задействовать Agile. Это следует обсудить еще до начала работы над проектом.
3. У вашей компании нет возможностей для ежедневного взаимодействия. Тогда сотрудничество вряд ли получится плодотворным, и от использования Agile лучше отказаться.
4. Между отделами компании нет тесного взаимодействия. При внедрении Agile оно обязательно должно быть, тут не обойтись без совместных совещаний, обсуждений деталей проекта. В противном случае успеха в реализации не ждите.
5. Компания перегружена документацией, правила требуют отражать любое действие в куче отчетов. Тогда Agile может обойтись слишком дорого. Уменьшение количества отчетов, требований и контрольных матриц как раз входит в приведенный выше список принципов Agile.

Книги про Agile

• Роб Коул и Эдвард Скотчер: «Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban». Подойдет тем, кто решил начать внедрять у себя в компании гибкий менеджмент проектирования.
• Стивен Деннинг: «Эпоха Agile. Как умные компании меняются и достигают результатов». Автор учит постановке целей и работе по ним с применением гибких методологий на всех управленческих уровнях.
• Джеф Сазерленд: «Scrum. Революционный метод управления проектами». Фреймворк Scrum — это именно его детище. Книга полезна для Scrum-мастеров, желающих разбираться в данном инструменте и использовать его в работе.
• Хенрик Книберг и Маттиас Скарин: «Scrum и Kanban: выжимаем максимум». По сути – сравнительная характеристика двух методологий с описанием их достоинств и недостатков, приведением примеров применения.
• Составленный специалистами концерна Toyota сборник статей «Канбан и «точно вовремя» на Toyota. Менеджмент начинается на рабочем месте». Тут описывается процесс внедрения инструмента Kanban в компании, где смешаны американская и японская системы управления. Описывается, как поменялись в результате этого внутренние процессы.
• Майк Кон: «Agile: Оценка и планирование проектов». О каком бы проекте ни шла речь, в нем обязательно должно присутствовать планирование и оценка результатов. Конечно, бывает и такое, что планы оказываются не совсем реалистичными. Автор книги с системой Agile, что называется, «на ты». Он учит применять эту методику к самым разным по масштабам проектам, грамотно планировать их и оценивать.

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

Продвижение блога — Генератор продаж

Рейтинг: 5

( голосов 8 )

Поделиться статьей

Анализ и оценка методов разработки программного обеспечения (Agile)

Главная / Менеджмент / Анализ и оценка методов разработки программного обеспечения (Agile) / Тест 4

Упражнение 1:

Номер 1

Какие утверждения справедливы по отношению к понятию "принцип" в программной инженерии:

Ответ:

&nbsp(1) Принцип задает общее правило разработки ПО&nbsp

&nbsp(2) Правило, которое задает принцип, должно быть конкретным&nbsp

&nbsp(3) Правило, которое задает принцип, должно быть абстрактным, применимым во всех случаях&nbsp

&nbsp(4) Принцип должен быть нетривиальным. Это означает, что можно привести разумные доводы против применения принципа в тех или иных ситуациях&nbsp

&nbsp(5) Правило «Создавайте качественный продукт» является принципом&nbsp

Номер 2

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

Ответ:

&nbsp(1) Над проектом должны работать мотивированные профессионалы&nbsp

&nbsp(2) Работающий продукт – основной показатель прогресса&nbsp

&nbsp(3) Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта&nbsp

&nbsp(4) Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы&nbsp

Номер 3

Автор книги вводит собственную классификацию принципов Agile, отличную от официальной.  Какие принципы введены автором?

Ответ:

&nbsp(1) Простота – искусство минимизации лишней работы – крайне необходима&nbsp

&nbsp(2) Разрабатывать минимально необходимое ПО&nbsp

&nbsp(3) Сохранять устойчивый темп разработки&nbsp

&nbsp(4) Наивысшим приоритетом для нас является удовлетворение потребностей клиента&nbsp

Упражнение 2:

Номер 1

"Поддерживайте устойчивый темп" - важный принцип Agile. Какие утверждения, связанные с этим принципом, считаются справедливыми в Agile:

Ответ:

&nbsp(1) Передача команде важных полномочий по управлению проектом, обеспечение программистам необходимых условий для работы позволяет отказаться от «маршей смерти»&nbsp

&nbsp(2) Всем членам команды следует обеспечить «персональную безопасность»&nbsp

&nbsp(3) При планировании работ следует предусматривать Geek Week недели&nbsp

&nbsp(4) Членов команды, не выдерживающих нужные сроки выполнения работ, следует удалять из команды&nbsp

Номер 2

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

Ответ:

&nbsp(1) Взаимодействие с клиентами должно осуществляться в течение всего проекта&nbsp

&nbsp(2) Взаимодействие с клиентами заменяет требования&nbsp

&nbsp(3) Сопричастники (разные группы пользователей проекта) имеют зачастую противоположные интересы. Единственный представитель клиентов в команде не может отразить все разнообразие интересов&nbsp

&nbsp(4) Представитель клиентов, включаемый в команду, является экспертом высокой квалификации и способен выразить интересы всех групп пользователей&nbsp

Номер 3

"Разрешать самоорганизацию команды" - важный принцип Agile. Какие утверждения, связанные с этим принципом, считаются справедливыми в Agile:

Ответ:

&nbsp(1) Необходимо поставить менеджмент на положенное ему место. На первом месте должны быть люди, фактически делающие работу&nbsp

&nbsp(2) Самоорганизуемой команде может требоваться тренер и наставник, но не требуется контроль и приказы&nbsp

&nbsp(3) Большинство проектов нуждается в менеджере, исповедующем стиль «Командуй и контролируй»&nbsp

&nbsp(4) Успехи команды Стива Джобса связаны с тем, что команда была саморганизуемой&nbsp

&nbsp(5) Традиционные для менеджера обязанности, такие как распределение задач, могут быть переданы команде&nbsp

Упражнение 3:

Номер 1

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

Ответ:

&nbsp(1) Большинство программных систем страдает избыточностью&nbsp

&nbsp(2) Продукт должен содержать не более пяти различных функций&nbsp

&nbsp(3) Каждую функцию продукта должны использовать не менее 90 % пользователей&nbsp

&nbsp(4) Следуйте лозунгу YAGNI Экстремального программирования – «Тебе Это Не Понадобится»&nbsp

&nbsp(5) Если код сегодня не требуется, то помещать его в систему – расточительство&nbsp

Номер 2

"Разрабатывайте минимальный продукт" - важный принцип Agile.  Реализуя этот принцип, следует создавать только запрашиваемый продукт. Какие утверждения, связанные с этим принципом, считаются справедливыми в Agile:

Ответ:

&nbsp(1) Создавайте архитектуру, поддерживающую будущие расширения&nbsp

&nbsp(2) Создавайте программные элементы настолько общими, насколько это возможно&nbsp

&nbsp(3) Делайте простейшую вещь, которая может еще выполнять работу&nbsp

&nbsp(4) Заботьтесь только о том, что нужно здесь и сейчас&nbsp

Номер 3

"Разрабатывайте минимальный продукт" - важный принцип Agile. Реализуя этот принцип, следует создавать только код и тесты. Какие утверждения, связанные с этим принципом, считаются справедливыми в Agile:

Ответ:

&nbsp(1) Документы, диаграммы, модели являются расходными материалами, не являясь частью финального продукта. Необходимость каждого расходного материала должна быть предметом тщательного анализа&nbsp

&nbsp(2) Архитекторы проекта должны построить общую архитектуру проекта, представляющую важную часть продукта&nbsp

&nbsp(3) Тесты представляют важную часть продукта&nbsp

&nbsp(4) Для финального продукта только код и тесты имеют ценность&nbsp

Упражнение 4:

Номер 1

Какие утверждения справедливы относительно "роли документов":

Ответ:

&nbsp(1) Пользователя мало волнуют расходные материалы. Поскольку документы относятся к расходным материалам, то создавать их не следует&nbsp

&nbsp(2) Важно не только то, что важно для пользователя, но и то, что важно для разработчика&nbsp

&nbsp(3) Критика «устаревания документов» справедлива, поскольку внесение изменений в код зачастую не сопровождается внесением изменений в документы&nbsp

&nbsp(4) Существуют современные инструментальные средства, позволяющие синхронизировать изменения кода и документов&nbsp

&nbsp(5) Если нет инструментария, синхронизирующего изменения кода и документов, то использовать документы нецелесообразно&nbsp

Номер 2

Какие утверждения, связанные со сложностью проекта, справедливы:

Ответ:

&nbsp(1) Последовательное добавление новой функциональности в проект возможно для проектов с аддитивной сложностью&nbsp

&nbsp(2) Последовательное добавление новой функциональности в проект возможно для проектов с мультипликативной сложностью&nbsp

&nbsp(3) Любой проект с мультипликативной сложностью можно преобразовать в проект с аддитивной сложностью&nbsp

&nbsp(4) Простой итеративный подход, начинающийся с базовой функционирующей системы, в которую последовательно добавляется новый функционал, может привести к краху системы&nbsp

&nbsp(5) Для систем с мультипликативной сложностью необходимо «дальнее предвидение»&nbsp

Номер 3

"Простота" - один из принципов Agile.  Но понимание этого принципа в Agile не всегда совпадает с пониманием "простоты" в классической программной инженерии. Какие высказывания о простоте согласуются с Agile видением:

Ответ:

&nbsp(1) Простота в ясном концептуальном базисе и хорошо продуманной структуре системы&nbsp

&nbsp(2) Наиболее сложный аспект проектирования системы состоит в декомпозиции на модули&nbsp

&nbsp(3) Избегайте работы, которая не является необходимой&nbsp

&nbsp(4) Откладывайте решения настолько, насколько это возможно&nbsp

&nbsp(5) Совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять&nbsp

&nbsp(6) Достижение простоты – это добавление работы и иногда существенное&nbsp

Упражнение 5:

Номер 1

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

Ответ:

&nbsp(1) Срок итерации не должен превышать 2 – 4 недели&nbsp

&nbsp(2) Если функциональность, запланированная на итерации, не достигнута, то срок итерации расширяется&nbsp

&nbsp(3) Если функциональность, запланированная на итерации, не достигнута, то срок итерации не изменяется, а функциональность либо отклоняется, либо переносится на следующую итерацию&nbsp

Номер 2

Разработка программного продукта в Agile является итеративной. Какие утверждения справедливы по отношению к характеру этой разработки:

Ответ:

&nbsp(1) Итеративная разработка Agile является «вертикальной» разработкой, когда проектируется вначале базовый слой, а затем последующие слои, использующие уже построенные компоненты&nbsp

&nbsp(2) Итеративная разработка Agile является «горизонтальной» разработкой, когда проектируется полностью функционирующая система с минимальной функциональностью, а затем последовательно расширяется функциональность системы&nbsp

&nbsp(3) Итеративный стиль разработки Agile хорошо подходит для систем с аддитивной сложностью&nbsp

&nbsp(4) Итеративный стиль разработки Agile хорошо подходит для систем с мультипликативной сложностью&nbsp

Номер 3

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

Ответ:

&nbsp(1) Построение системы тестов, связанных с каждой функциональностью&nbsp

&nbsp(2) Следование принципу YAGNI – «Это Тебе Не Понадобится»&nbsp

&nbsp(3) Применение практики «Закрытого окна», когда внесение изменений запрещается в ходе выполнения очередной итерации&nbsp

&nbsp(4) Если код сегодня не требуется, то помещать его в систему – расточительство&nbsp

Упражнение 6:

Номер 1

В инженерии ПО тестирование является основным способом обеспечения качества проекта. Какие утверждения справедливы по отношению тестирования:

Ответ:

&nbsp(1) Тестирование позволяет доказать наличие ошибки, но не может доказать их отсутствия&nbsp

&nbsp(2) Для Agile тесты представляют основной ресурс проекта&nbsp

&nbsp(3) Регрессионное тестирование отвергается в Agile как затратное&nbsp

&nbsp(4) Современный инструментарий позволяет автоматизировать систему прохождения тестов&nbsp

Номер 2

Какие стратегии разработки проекта приносят успех в большинстве ситуаций по мнению автора книги:

Ответ:

&nbsp(1) Поставлять на каждой итерации работающую систему&nbsp

&nbsp(2) Вначале следует построить ядро системы, наращивая его до построения полнофункциональной работающей системы&nbsp

&nbsp(3) Применять стратегию «дуальной разработки»&nbsp

&nbsp(4) На ранних стадиях проекта следует заниматься трудными базисными проблемами&nbsp

&nbsp(5) Когда основная инфраструктура построена, следует сосредоточиться на построении работающих версий системы, постепенно наращивая их функциональность&nbsp

Номер 3

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

Ответ:

&nbsp(1) Важнейшую по Значимости – Первой&nbsp

&nbsp(2) Простейшую – Первой, Самую Трудную – Второй&nbsp

&nbsp(3) Самую Трудную – Первой&nbsp

&nbsp(4) Простейшую – Первой&nbsp

Упражнение 7:

Номер 1

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

Ответ:

&nbsp(1) Задается документ требований&nbsp

&nbsp(2) Задаются сценарии – варианты использования, описывающие варианты прохода по системе&nbsp

&nbsp(3) Задаются сценарии – пользовательские истории, описывающие некоторые ситуации в процессе работы системы&nbsp

&nbsp(4) Задаются формальные спецификации, строго описывающие требования пользователей&nbsp

Номер 2

В Agile тестирование является основным способом обеспечения качества проекта.  Какие утверждения справедливы по отношению тестирования в Agile:

Ответ:

&nbsp(1) Нет кода без теста&nbsp

&nbsp(2) Вначале тест, затем код&nbsp

&nbsp(3) Вначале код, затем тест&nbsp

&nbsp(4) Код и тест создаются параллельно&nbsp

Номер 3

Что представляет собой набор регрессионных тестов в Agile:

Ответ:

&nbsp(1) В этот набор включаются тесты, на которых система успешно завершает выполнение&nbsp

&nbsp(2) В этот набор включаются тесты, при выполнении которых система ломается&nbsp

&nbsp(3) Согласно стратегии Agile «вначале тест, затем код» в набор регрессионных тестов попадают все создаваемые тесты&nbsp

&nbsp(4) В набор попадают тщательно отобранные тесты, соответствующие значимым сценариям работы системы&nbsp

Главная / Менеджмент / Анализ и оценка методов разработки программного обеспечения (Agile) / Тест 4

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

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

Каковы 12 принципов Agile?

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

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

Ключевые ценности Agile

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

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

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

Связанный: Лучшее программное обеспечение Kanban 2022 года

12 принципов Agile

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

1. Удовлетворить клиента за счет раннего и непрерывного предоставления ценного программного обеспечения

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

2. Приветствуем изменение требований даже на поздних стадиях разработки

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

3. Часто доставляйте работающее программное обеспечение

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

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

4. Деловые люди и разработчики должны работать вместе

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

5. Создавайте проекты вокруг мотивированных людей

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

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

6. Продвижение личных бесед

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

7. Рабочее программное обеспечение — основной показатель прогресса

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

8. Гибкие процессы способствуют устойчивому развитию

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

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

Работаете ли вы над кодом или над чем-то более конкретным, вы хотите убедиться, что после каждой итерации он улучшается. Вы не хотите возвращаться и исправлять ситуацию позже. Исправьте их сейчас. Еще лучше, убедитесь, что они становятся лучше. Используйте scrum, agile-фреймворк для выполнения сложных проектов, чтобы анализировать и поддерживать развитие проекта.

10. Простота — искусство максимизировать объем незавершенной работы — имеет важное значение

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

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

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

12. Имейте регулярные интервалы

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

Гибкие шаблоны управления проектами

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

Шаблон элементов действий

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

Шаблон Agile Sprint Planner

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

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

Как ProjectManager помогает с Agile

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

Автоматизация работы

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

См. информационные панели реального времени

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

Создание отчетов нажатием клавиши

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

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

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

Принципы Agile | 12 Принципы Agile

• Введение
• 1. Своевременная и непрерывная поставка ценного программного обеспечения
• 2. Принятие изменений
• 3. Частая поставка
• 4. Сотрудничество
• 5. Улучшение автономности и мотивации
• 0 9.290 600190
• 0 9.290 7. Рабочее программное обеспечение
• 8. Стабильная рабочая среда
• 9. Обеспечение качества
• 10. Простота
• 11. Самоорганизующиеся команды
• 12. Анализ и корректировка
• Почему важны принципы Agile
• Инфографика принципов Agile

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

Agile базируется на 4 ключевых ценностях и 12 ключевых принципах. В то время как agile-ценности дают руководителям проектов и разработчикам очень общее представление о том, что значит быть «гибким», и помогают направлять agile-процесс, 12 agile-принципов дают примеры того, как следует внедрять agile.

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

1. Ранняя и непрерывная поставка ценного программного обеспечения

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

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

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

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

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

2. Примите перемены

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

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

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

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

3. Частая доставка

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

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

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

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

4. Сотрудничество

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

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

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

5. Автономия и мотивация

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

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

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

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

6. Улучшение связи

Самый действенный и действенный метод информирования о разработке и в рамках разработки — беседа лицом к лицу.

Технологии предоставляют предприятиям сотни различных способов общения с сотрудниками, но ни один из них не может быть лучше, чем общение лицом к лицу. 2020 год коренным образом изменил то, как мы работаем: все больше сотрудников работают удаленно, чем когда-либо прежде, предприятия все больше полагаются на такие средства связи, как Skype и Microsoft Teams. Хотя этого может быть достаточно, изменения ошибок увеличиваются, когда командам не хватает фактического общения. Информация теряется при переводе, электронные письма и заметки прячутся во входящих и т. д.

7. Рабочее ПО

Работающее программное обеспечение является основным мерилом прогресса.

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

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

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

8. Стабильные условия труда

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

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

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

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

Это помогает снизить стресс и избежать «выгорания» сотрудников.

9. Обеспечение качества

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

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

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

10. Простота

Простота — искусство максимизировать количество невыполненной работы — имеет важное значение.

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

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

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

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

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

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

Этот принцип аналогичен пункту 5: автономия и мотивация. Разница здесь заключается в сравнении agile-команд с традиционными командами разработчиков. Традиционные методы часто разделяют их команды разработчиков. Например, «Команда А» выполняет одну задачу, а затем передает ее «Команде Б», которая накладывает свой вклад поверх этого и т. д.

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

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

12. Отражение и настройка

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

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

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

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

Почему принципы Agile важны

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

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

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

НАВЕРХ

Как 12 принципов Agile Manifesto работают в реальной жизни

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим изображение ниже. Левая часть изображения представляет собой традиционный способ предоставления ценности клиенту, который представляет собой большой результат, предоставляемый после того, как все, что предусмотрено в конечном продукте, завершено. Сравните это с правой частью изображения, которая показывает итеративный (частый), инкрементальный (Готово) подход к созданию ценности. Каждая часть того, что доставлено, можно использовать, но это меньшая часть большой головоломки.

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

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

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

Agile отличается. Заинтересованные стороны бизнеса регулярно встречаются с agile-командой на более низком уровне взаимодействия. В Scrum это взаимодействие может иметь место на встречах по уточнению или на обзоре спринта. В других agile-фреймворках это взаимодействие может принимать форму совещаний по пополнению запасов. Несмотря на вовлеченность и, следовательно, видимость 90 125, 90 126 непрерывны в гибкой среде.

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

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

Руководители, работающие с agile-командами, сосредотачиваются на том, чтобы у команд была поддержка (инструменты, доступ, ресурсы) и среда (культура, люди, внешние процессы), в которых они нуждаются, а затем доверяют им выполнение работы. Этот принцип может отпугнуть некоторых руководителей, предпочитающих командно-контрольный стиль управления. Они задаются вопросом, как они узнают, преуспела ли их команда и сосредоточилась ли она на правильных вещах. Мой ответ на эти опасения заключается в том, чтобы сосредоточиться на результатах команды. Часто ли они доставляют рабочий продукт? Продвигаются ли они к своим целям? Это те показатели, которые заслуживают внимания. Это необходимый сдвиг в мировоззрении и мышлении, и это то, что лидеры, а также agile-команды должны сделать для достижения наилучших результатов. Чтобы узнать больше о том, как поддерживать agile-команды, руководителям следует подумать о посещении курса Professional Agile Leadership — Essential.

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

6.

С более широким распространением Zoom и других платформ для встреч слова лицом к лицу 9В последнее время 0126 приобрели немного другое значение, но идея, лежащая в основе этого принципа, осталась. Лучший способ передать информацию — вести беседу в режиме реального времени, а не обмениваться сообщениями по электронной почте или в приложении для обмена сообщениями. Для agile-команд это может означать, что те, кто выполняет работу, общаются напрямую с теми, кто ее использует. Или это может означать, что те, кто выполняет работу, сотрудничают друг с другом для решения своих проблем. Каждая agile-команда определяет, как лучше всего следовать этому принципу в соответствии со своей уникальной ситуацией. Важно то, что сотрудничество имеет решающее значение для всех Agile-команд.

Лучший способ сотрудничества — это беседа.

7. Работающее программное обеспечение является основным мерилом прогресса.

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

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

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

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

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

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

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

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

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

10. Простота — искусство максимизировать объем незавершенной работы — имеет важное значение.

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

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

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

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

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

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

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

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

Заключение

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

Мэри обучила более 1000 человек Agile, Scrum и Kanban. Она руководила трансформацией Agile для организаций с более чем 60 командами и руководила созданием новых продуктов от определения продукта до самоорганизации и запуска. Мэри является основателем Rebel Scrum, консалтинговой компании, которая помогает командам переходить на Agile и предоставляет услуги по обучению и коучингу, основанные на практическом опыте. Rebel Scrum имеет опыт крупномасштабных гибких преобразований в различных средах, включая технологические и бизнес-преобразования. Запишитесь на один из предстоящих общедоступных учебных курсов Rebel Scrum или свяжитесь с нами, чтобы обсудить варианты частного обучения и консультаций по Scrum для вашей организации.

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

Запись на один из предстоящих занятий Rebel Scrum:

• Применение профессионального Scrum
  • Вводный урок для новичков в Scrum
• Профессиональный скрам-мастер
  • Ориентирован на тренерские команды Scrum Masters 
• Профессиональный скрам-мастер II
  • Расширенный курс для скрам-мастеров 
• Профессиональное Agile-лидерство
  • Для лидеров и менеджеров Agile-команд
• Профессиональный владелец продукта Scrum
  • Для владельцев продуктов
• Профессиональный владелец продукта Scrum — продвинутый уровень
  • Продвинутый курс для владельцев продуктов
• Профессиональный Scrum с Канбан
  • Для всех, кто интересуется внедрением принципов Канбан в Скрам-команде
• Масштабируемый профессиональный Scrum с Nexus
  • Для трех или более групп, работающих вместе над одним продуктом

Доступны как публичные, так и частные занятия. Чтобы узнать больше, свяжитесь с Rebel Scrum.

Поделитесь с вашей сетью

Определения и примеры для разработки программного обеспечения

Table of Contents

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

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

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

Что такое Agile?

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

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

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

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

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

Благодаря 4 основным ценностям и 12 принципам Agile стал всемирно признанным подходом к управлению проектами.

4 ценности Agile

Манифест Agile содержит 4 ценности и 12 поддерживающих принципов, лежащих в основе гибкого подхода к разработке программного обеспечения.

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

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

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

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

3. Сотрудничество с клиентами вместо переговоров по контракту

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

4. Реагирование на изменения вместо следования плану

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

Объяснение 12 принципов Agile

Каковы 12 принципов Agile?

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

Вот 12 объясненных принципов Agile:

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

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

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

Пример:

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

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

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

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

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

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

Пример:

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

3. «Часто доставляйте работающее программное обеспечение, от пары недель до пары месяцев, отдавая предпочтение более коротким срокам».

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

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

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

Пример:

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

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

Четвертый принцип Agile фокусируется на объединении отделов, регулярно отдавая приоритет сотрудничеству. Идея заключается в том, что клиенты, ключевые заинтересованные стороны и руководство работают рука об руку с разработчиками, укрепляя каналы связи, чтобы все были на одной волне.

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

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

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

Пример:

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

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

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

Принцип Agile 5 подчеркивает важность выбора правильных людей с правильными навыками и ролями для участия в проекте для достижения успеха. И это также побуждает руководителей групп предоставлять им необходимые инструменты и ресурсы.

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

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

Пример:

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

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

6. «Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — личное общение».

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

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

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

Пример:

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

7. «Работающее программное обеспечение является основным мерилом прогресса».

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

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

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

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

Пример:

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

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

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

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

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

Пример:

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

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

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

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

Пример:

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

10. «Простота — искусство максимизировать объем незавершенной работы — имеет важное значение».

Этот принцип Agile направлен на максимальное упрощение процессов. Другими словами, речь идет о том, чтобы работать с умом, а не усердно.

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

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

Пример:

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

11. «Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами».

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

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

Пример:

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

12. «Команда регулярно размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение».

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

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

Пример:

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

Ключевые выводы

Принципы Agile сосредоточены на предоставлении руководящих указаний, позволяющих командам сосредоточиться на правильных вещах. Это 12 Agile-принципов, которые объясняются проще:

1. Удовлетворенность клиентов за счет своевременной и непрерывной поставки программного обеспечения.

2. Сосредоточьтесь на работе над более мелкими и достижимыми задачами.

3. Соблюдать сроки поставки рабочего продукта.

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

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

6. Постоянная коммуникация — ключ к успеху проекта.

7. Прогресс измеряется работающим программным обеспечением.

8. Поддерживайте постоянный и реалистичный темп развития.

9. Всегда следите за техническими деталями.

10. Простота — это ключ к успеху.

11. Способствовать самоорганизации.

12. Думайте о работе команды, чтобы продолжать совершенствоваться.

Заключение

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

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

12 принципов Agile и их преимущества

В этой статье рассматриваются:

1. Что такое 12 принципов Agile?
2. Какие команды Agile Principle чаще всего практикуют?
3. Чем не являются Agile-принципы?
4. Какие выгоды получит компания от применения принципов Agile?

Принципы Agile Определение

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

Гибкая методология, стандартная современная методология управления проектами, основана на 12 основных принципах гибкой разработки.

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

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

Команды разработчиков программного обеспечения ссылаются на 12 основных принципов или 12 гибких принципов.

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

Специалисты по Agile, разработавшие принципы Agile, заявили, что Agile — это не методология.

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

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

Каковы 12 принципов Agile?

Принцип Agile 1

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

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

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

Специалисты по Agile сосредоточены на «ранней и непрерывной доставке ценного программного обеспечения». Agile-разработчики не откладывают дела на потом и стараются выполнить их в оптимальное время с оптимальным качеством.

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

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

Agile Principle 2

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

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

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

Команда разработчиков принимает эту стратегию через скрамы (встречи между agile-подгруппами), которые помогают им преодолеть проблемы, с которыми сталкиваются разработчики, работая над разными модулями одного и того же проекта.

Специалисты по Agile следуют манифесту Agile, принципам и практикам, таким как парное программирование и разработка через тестирование (TDD).

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

Принцип Agile 3

Поставляйте работающее программное обеспечение часто, от нескольких недель до нескольких месяцев, с предпочтением более коротких сроков: 

Гибкий процесс быстро реагирует на меняющиеся требования клиентов.

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

Эти команды вовлекают всю команду в процесс создания продукта с помощью гибких процессов: 

• Сотрудничество
• Самоорганизация команд
• Рефлексия
• Реагирование на изменения вместо следования плану

Например, разработка программного обеспечения

методы, ориентированные на гибкое мышление.

Часть Agile заключается в том, чтобы приветствовать изменения и рассматривать каждое требование как «список пожеланий», оставляя место для роста и масштабирования.

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

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

Принцип Agile 4

Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта:

Сотрудничество играет ключевую роль в Agile.

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

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

Принцип Agile 5

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

Мотивированные сотрудники более продуктивны, чем немотивированные, работающие в составе пассивной толпы.

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

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

Вам следует использовать самоорганизующиеся команды, а не структуры управления и контроля.

Гибкие процессы способствуют устойчивому развитию.

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

Принцип Agile 6

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

Процессы Agile способствуют личному общению внутри команды.

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

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

Принцип Agile 7

Работающее программное обеспечение является основным показателем прогресса: 

Agile-процессы поддерживают создание и поставку работающего программного обеспечения.

Гибкие процессы, таким образом, оптимизируют скорость, улучшают распределение ресурсов разработки и повышают рентабельность инвестиций.

Поэтому способствует лучшему росту.

Agile Principle 8

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

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

Постоянный темп поддерживает постоянный рост.

Принцип Agile 9

Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность :

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

Гибкие процессы способствуют достижению инновационных и продуктивных целей.

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

Принцип гибкости 10

Простота — искусство максимизировать объем незавершенной работы — имеет важное значение : 

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

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

Гибкие процессы также максимизируют самоорганизацию и поощряют решения «снизу вверх», а не проектирование «сверху вниз».

Этот принцип способствует простоте, что, в свою очередь, повышает производительность.

Принцип Agile 11

Лучшие архитектуры, требования и проекты объединяются самоорганизующимися командами :  

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

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

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

Принцип Agile 12

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

Agile-методологии поощряют постоянное совершенствование как процесса команды, так и конечного продукта.

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

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

Какие команды Agile Principle практикуют больше всего?

Команды разработчиков применяют 12 принципов Agile по мере возникновения конкретной ситуации.

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

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

Если мы говорим о командах по управлению продуктом и их задачах по приоритизации, то наиболее практикуемым agile-принципом будет agile-принцип №10.

Мы считаем, что простота важна во всех аспектах, особенно в работе.

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

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

Правило расстановки приоритетов 80/20 гласит, что команды разработчиков получают 80 % результатов своего продукта, выполняя 20 % работы.

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

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

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

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

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

Что не является Agile-принципами?

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

• XP
• AUP
• 4GT

Объяснением может быть подход 4GT. И это потому, что 4GT не включает непрерывную обратную связь и итерации. И, как мы знаем, фундаментальным аспектом гибких принципов является обратная связь и итерации.

Какие выгоды получит компания от применения принципов Agile?

Принципы Agile помогают достичь высокого качества продукции, и этот процесс предлагает различные преимущества. Вот некоторые из них:

Команды могут достичь целей за ограниченное время:

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

Принципы Agile Помощь в обеспечении гибкости и адаптивности:

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

Agile-принципы также способствуют более строгому контролю внутри команд над своими проектами:

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

Роли и обязанности заранее определены, что устраняет сложности и обеспечивает контроль.

Agile-команды итеративно работают над созданием программного обеспечения и Agile-принципов Объекты:

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

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

Agile-принципы в разработке продуктов Помощь в достижении высокой рентабельности инвестиций (ROI):

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

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

Наконец, можно сказать, что Agile-принципы помогают сохранить конкурентное преимущество:

Преимущества сотрудничества на всех уровнях. Прямой переход от клиентов и разработчиков к ИТ и бизнесу приводит к следующим преимуществам:

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

Все эти преимущества в совокупности помогают получить огромное конкурентное преимущество в магазин.

Простота — искусство максимизировать невыполненную работу

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

В этом посте я хотел бы поделиться тем, что я понял и узнал из общения с этими людьми: Стив Эш, Чарльз Брэдли, Линн Шрусбери, Рууд Ритвельд, Филип Леджервуд, Джон Хебли, Джефф МакКенна, Джордж Динвидди, Адам Срока, Майкл Джеймс, Мэтт Андерсон и Касс Далтон.

Простота — высшая степень изысканности. ~ Леонардо да Винчи

Расхламление — следствие Простоты. Простота приводит к:

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

Философия Scrum работы в небольших командах, небольшие спринты, небольшие истории впитывают простоту мышления – Продуманное сокращение.

Стремление к простоте иногда выражается как принцип KISS.

• Делайте сегодня только то, что вам абсолютно необходимо сделать сегодня. Никакой «заделки на будущее». Никакой «позолоты».
• Достичь едва ли достаточно хорошего (JBGE). JBGE на самом деле является наиболее эффективным из возможных.

Спасибо Скотту Амблеру за то, что он поделился этим термином JBGE. Подробнее об этом можно прочитать в моем предыдущем посте. Гибкость — это определение и достижение «достаточно хорошего»

Наступает момент, когда любые дополнительные усилия, вложенные в рабочий продукт, увеличивают его стоимость, не увеличивая его ценность. Если не ноль, увеличение стоимости может быть незначительным по сравнению с увеличением стоимости. Это момент, чтобы остановиться! (достижение JBGE).

Легко продолжать разработку продукта после определенного момента. Опрос Standish Group, проведенный в 2009 году, показал, что более 70% функций никогда или редко используются. Не делать эту работу — отличная возможность заняться более ценной работой.

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

Несколько подходов и практик Agile, которые приходят мне на ум:

• Разработка через тестирование следует за простотой . Вы правы достаточно кода, чтобы пройти тесты. Определив сначала меру успеха, а затем кодируя ее (и только ее), вы избавляетесь от большого количества ненужной работы.
• Сборка рабочего программного обеспечения, достаточного для получения обратной связи .
• Написание достаточного количества документации для удовлетворения потребности.
• Использование карточек историй (Как клиент, я хочу что-то сделать, чтобы получить какую-то ценность). Вы ничего не делаете, если не можете четко указать ценность.
• Использование простых досок задач для измерения прогресса.
• Уточнение невыполненной работы : Владелец продукта наводит порядок в невыполненной работе, чтобы определить функции, которые сделают его продукт успешным. Проверьте мой предыдущий пост Владелец продукта Scrum должен перецеловать множество лягушек, чтобы найти принца
• Иметь всего 3 роли в Scrum (Команда, ScrumMaster и Владелец Продукта) в команде — это просто.
• Вдумчивое снижение иерархии внутри организации — это шаг к простоте.

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

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

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

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

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

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

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

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

No related posts.