Лучшие практики Agile от разработчиков DST Global

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

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

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

История Agile-манифеста

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

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

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

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

Ниже приведены четыре ценности Agile:

1. Индивиды и взаимодействия важнее процессов и инструментов.

2. Рабочее программное обеспечение по обширной документации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое Agile?

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

Преимущества работы с Agile командами разработки

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

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

Как они этого достигают?

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

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

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

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

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

Что такое гибкие подходы и методы

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

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

Две стратегии для реализации ценностей и принципов Agile.

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

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

Различные типы гибкой методологии

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

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

Скрам

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

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

Экстремальное программирование (XP)

Другая популярная методология Agile, Extreme Programming (XP), делает упор на скорость и непрерывность доставки. Как и Scrum, XP позволяет тесно сотрудничающим командам создавать рабочие версии программного обеспечения через короткие промежутки времени, обычно каждые 1–3 недели. XP рассчитывает на то, что клиенты сообщат о наиболее ценных функциях программного продукта, а разработчики будут работать над реализацией этой обратной связи.

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

Бережливая разработка программного обеспечения

Бережливая разработка программного обеспечения — это применение методов Бережливого производства. Lean более гибок, чем Scrum или XP, и имеет менее строгие инструкции и правила. Принципы бережливого производства были внедрены в производственной сфере в середине 20-го века с целью оптимизации производственных отходов, обеспечения ценности и эффективности производства, а также максимальной выгоды для клиента.

Lean опирается на семь принципов бережливого управления:

1. Определите ценность и устраните потери

2. Качество сборки

3. Значение карты потока

4. Создайте непрерывный рабочий процесс

5. Создайте систему вытягивания

6. Постоянное улучшение

7. Уважайте людей

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

Канбан

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

Методология Kanban Agile опирается на шесть основных практик:

1. Визуализируйте рабочие процессы

2. Ограничить незавершенную работу

3. Управляйте потоком

4. Сделайте политику процесса явной.

5. Реализуйте циклы обратной связи

6. Совершенствуйтесь совместно

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

Кристалл

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

Crystal классифицирует проекты по трем критериям:

1. Размер команды

2. Критичность системы

3. Приоритеты проекта

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

Разработка, основанная на функциях (FDD)

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

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

Метод разработки динамических систем (DSDM)

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

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

Масштабирование Agile фреймворков

Помимо методологий Agile, организации полагаются на фреймворки для масштабирования Agile по всему предприятию. К ним относятся Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), Disciplined Agile (DA), Scrum@Scale и другие. Эти методы и структуры дополняют методы Agile, описанные выше.

Масштабируемая Agile Framework (SAFe)

SAFe — это «база знаний интегрированных принципов, проверенных практик и компетенций для достижения гибкости бизнеса с использованием внедрения Agile, Lean и DevOps».

Это устоявшийся и строгий подход к масштабированию Agile, включая планирование команды, программы и портфеля. В рамках этой структуры была представлена концепция Agile Release Train (ART) для структурирования работы в командах из 50–125 человек, во главе которой стоит инженер Release Train (RTE). SAFe требует последовательных двух- и десятинедельных итераций, что может хорошо подойти для команд, проектов или организаций с более устоявшейся практикой Agile. Это может оказаться амбициозным для новых организаций.

Дисциплинированный Agile (DA) (XP)

Disciplined Agile ранее назывался Disciplined Agile Delivery (DAD). Это «человекоориентированный, ориентированный на обучение гибридный гибкий подход к разработке ИТ-решений». DA менее предписывающий, чем SAFe, и более сфокусированный в качестве основополагающего подхода. Он подчеркивает командные роли и целенаправленный подход, что делает его более гибким, чем другие методы масштабирования Agile.

Крупномасштабный Scrum (LeSS)

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

Смешение подходов к гибкой разработке

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

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

Примером наиболее распространенных сочетаний является скоординированное использование структуры Scrum, метода Kanban и элементов метода экстремального программирования (XP). В этом,

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

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

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

Жизненный цикл гибкой разработки

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

Шесть этапов жизненного цикла гибкой разработки:

1. Концепция

2. Зарождение

3. Итерация

4. Тестирование

5. Обслуживание

6. Выход на пенсию

Концепция

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

Зарождение

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

Итерация

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

Тестирование

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

Обслуживание

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

Выход на пенсию

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

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

Вот типичные характеристики жизненного цикла проекта Agile:

- Требования жизненного цикла Agile динамичны.

- Действия повторяются до тех пор, пока не будет выполнено правильное действие.

- Доставка наблюдается в частых и меньших патронах.

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

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

1. Итеративный Agile

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

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

2. Agile, основанный на потоке

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

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

Внедрение Agile в организации

Реализация Agile включает в себя создание среды разработки Agile и последующую реализацию в созданной среде Agile.

Создание гибкой среды

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

Создание гибкого мышления

Первым шагом к созданию Agile-среды является формирование гибкого мышления. Управление проектом с использованием гибкого подхода к разработке требует от команды проекта принятия гибкого мышления. Ответы на следующие вопросы помогут разработать стратегию реализации:

- Как команда проекта может применить Agile-подход?

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

- Как команда может работать прозрачно?

- Какой работы можно избежать, чтобы сосредоточиться на первоочередных задачах?

- Как подход лидерства-слуги может способствовать достижению командой своих целей?

Лидерство Слуги

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

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

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

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

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

Состав команды

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

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

Межфункциональная команда

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

Владелец продукта

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

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

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

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

Фасилитатор команды

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

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

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

Общие практики гибкой разработки от разработчиков DST Global

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

Ретроспектива

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

Он отражает один из 12 принципов Agile-манифеста:

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

Отставание

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

Уточнение бэклога

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

Ежедневные стендапы

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

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

- Что я успел сделать с момента последнего стендапа?

- Что я планирую завершить между настоящим моментом и следующим стендапом?

- Каковы мои препятствия (или риски или проблемы)?

Обзор

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

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

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

Тема

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

Эпосы

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

Истории

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

Задания

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

Стратегии измерения в гибкой разработке

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

Сюжетная точка

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

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

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

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144

Один — это минимум, а большее число — максимум.

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

Оценка сюжетных точек

В процессе оценки баллов истории есть три важнейших фактора:

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

2. Риск: Какие риски существуют? Риски могут включать неопределенность или зависимость от другой команды.

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

Все эти элементы должны сочетаться для точной оценки сюжетных точек.

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

Диаграмма выгорания

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

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

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

Введение в Скрам

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

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

Давайте разберемся в этом на примере бизнеса.

- Постановка задачи: Построить новую финансовую платформу для клиентов.

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

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

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

Различия: Agile и Scrum

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

Scrum — наиболее широко используемый Agile-метод. Канбан, бережливое производство, экстремальное программирование (XP), Crystal, метод разработки динамических систем (DSDM) и разработка на основе функций (FDD) — это другие методологии разработки Agile. Многие организации обычно используют сочетание этих гибких методологий для организации своих команд и бизнес-инициатив.

Некоторые части принципов Scrum отражают философию Agile, а некоторые моменты выделяют ее среди философии Agile.

Ключевые сходства между Scrum и Agile, которые делают Scrum Agile-процессом:

- Короткие циклы разработки.

- Отдавайте приоритет людям, сотрудничеству и общению.

- Реагирование на изменения и учет обратной связи.

Указатели, которые отличают Scrum от других методов Agile-разработки:

- Работа разбита на 2-4-недельные спринты.

- Журнал невыполненных работ по продукту отслеживает, какую работу еще предстоит выполнить.

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

- Ежедневный звонок Scrum, который представляет собой короткую 15-минутную встречу для получения обновлений.

Разрушение мифов о Scrum

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

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

- Менеджеры не играют никакой роли в Agile Scrum.

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

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

- Заинтересованные стороны/владельцы продукта могут вносить изменения, когда захотят.

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

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

- Каждый в scrum-команде должен быть мастером во всем.

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

- Скрам-команды создают продукты без архитектурного плана.

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

Лучшие практики Agile от разработчиков DST Global

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

- Создайте резервную копию продукта: создайте приоритетный список функций и требований, которые необходимо разработать.

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

- Проводите ежедневные встречи: проводите короткие ежедневные встречи для обсуждения прогресса, проблем и планов.

- Используйте диаграмму выработки: отслеживайте прогресс, измеряя объем работы, выполняемой ежедневно.

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

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

- Используйте ретроспективы для постоянного улучшения: регулярно анализируйте процесс и вносите улучшения.

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

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

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

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

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

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

Разнообразие и инклюзивность в мире гибкого развития

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

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

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

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

Заключение

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

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