База знаний

Agile

Agile – это комплексная методика организации процесса разработки ПО, которая включает в себя целую семью отдельных подходов, или, как их еще называют, фреймворков (Scrum, Kanban, Lean, DSDM, XP, FDD, Crystal). Она использует итеративный подход к управлению проектами и разработке ПО, что позволяет командам ускорить и организовать процесс. Вместо того чтобы выпускать весь продукт полностью, agile команда выполняет работу в рамках небольших инструментов. Требования, планы и результаты постоянно проходят проверку актуальности, благодаря чему команды могут быстро реагировать на изменения. Основной областью, где используется Agile, является разработка программного обеспечения. Но в современном мире Agile можно применить к любой организации любой отрасли.
Философия Agile включает в себя: Agile Manifesto, и 12 принципов.
Agile Manifesto:
1. Люди и сотрудничество важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Положительное сотрудничество с заказчиком важнее обязанностей по контракту.
4. Готовность к изменениям важнее соблюдения плана.

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

А теперь рассмотрим некоторые методики Agile в отдельности.
Scrum – это методика, помогающая команде профессионалов организовать свою работу максимально эффективно. Как спортивная команда готовится к решающей игре (кстати, scrum — англ. «битва»), так и Scrum-команда должна извлекать уроки из приобретенного опыта, овладевая принципами самоорганизации, работая над решением проблемы, анализировать свои успехи и провалы, чтобы постоянно совершенствоваться. Scrum способствует этому.
Методику Scrum чаще всего применяют команды разработчиков приложений, но принципы и опыт ее использования применимы к командной работе любого рода. Это одна из причин такой популярности методики. Участники команды Scrum проводят собрание, используют специальные инструменты и берут на себя особые роли, чтобы организовать работу и управлять ею.
Понятия Scrum и Agile часто путают, потому что Scrum строится вокруг идеи о постоянном совершенствовании, которое является главным принципом Agile. И все же Scrum – это методика работы, а Agile – это образ мышления. Перейти на Agile не так-то просто; вся команда должна стремиться изменить свой подход к созданию ценности для клиентов. Но можно начать употреблять методику, такую как Scrum. Это направит мышление в нужное русло и поможет практиковать принципы Agile в повседневном общении и работе.
Методика Scrum по своей сути эвристическая. В ее основе лежит постоянное обучение и адаптация к изменяющимся факторам. Согласно Scrum, команда не знает всего в начале проекта, но будет развиваться, изучая уроки по опыту. В структуре Scrum заложена свобода, с которой команды приспосабливаются к изменяющимся условиям и требованиям пользователей. Рабочий процесс предполагает изменение приоритетов и короткие циклы релиза, что способствует постоянному обучению и усовершенствованию команды.
Структурированность не мешает методологии Scrum быть гибкой. Ее можно адаптировать к потребностям организации. Существует множество теорий о том, как следует применять Scrum для достижения успеха, но независимо от того, какую методологию вы выберете, ее главными принципами должны быть ясность коммуникации, прозрачность и стремление к постоянному совершенствованию. Остальные вы свободны выбирать сами.

Ценности Scrum:
1. Обязательство. Члены команды лично обязуются добиться командных целей.
2. Мужество. Члены команды делают правильные вещи и трудятся над сложными проблемами.
3. Фокус. Сосредоточенность на работе, определенной для спринта, и целях команды.
4. Открытость. Члены команды и заинтересованные стороны открыто рассказывают о работе и вызовах, с которыми сталкивается команда.
5. Уважение. Все члены команды уважают друг друга.

Принципы Scrum:
1. Прозрачность. Команда должна работать в среде, где каждый знает, с какими проблемами сталкиваются другие члены команды.
2. Проверка. Частые проверки встроены в структуру процесса, чтобы дать команде возможность обдумать, как работает процесс. К таким пунктам проверки относятся Daily Scrum Meeting и Sprint Review Meeting.
3. Адаптация. Команда постоянно исследует актуальность продуктов и пересматривает не имеющие смысла пункты.

Команда Scrum:
Product Owner. Это заказчик или назначенный им ответственный профессионал. Его задача – понимать требования бизнеса, клиента и рынка. Его задачи:
• Написание и поддержка Product Backlog.
• Тесное сотрудничество с заказчиком и командой Scrum, сообщая каждому участнику значение рабочих задач в Product Backlog.
• Предоставляет команде понятные требования, которые можно протестировать.
• Отвечает за приемку в конце каждой итерации.

Scrum Master – следит за применением принципов Scrum в своих командах. Он обучает команду и заказчика Scrum-процессу и пытается оптимизировать применение этой практики.
Успех Scrum-мастера зависит от того, насколько хорошо он разбирается в работе, которую выполняет команда, и может помочь команде повысить прозрачность работы и оптимизировать процесс. Это главный координатор, который составляет перечень необходимых ресурсов (кадровых и материально-технических) для сборов по планированию спринта и обзора его итогов, стендапа и ретроспективы спринта.
Development Team – команда, включающая в себя от 3 до 9 максимально квалифицированных профессионалов, умеющих делать все этапы разработки ПО. Она самостоятельна, самоорганизована и максимально мотивирована на результат.

Артефакты Scrum
Артефакт – это то, что мы создаем, например, инструмент для решения проблемы. У Scrum существует три артефакта: бэклог продукта, бэклог спринта и инкремент с вашими критериями готовности. Эти три постоянных присутствуют в каждой команде Scrum.
Product Backlog – это главный перечень задач, их еще называют User Story, которые нужно выполнить. Его ведет Заказчик или Product Owner. Это постоянно изменяющийся перечень функциональных возможностей, требований, улучшений и исправлений, состоящий из задачи для беклога спринта. В общем, это список задач команды. Владелец продукта постоянно обращается к беклогу продукта, изменяет в нем приоритеты и поддерживает его актуальность, так как может появиться новая информация или могут произойти изменения на рынке, поэтому исчезнет смысл выполнять эти задачи или появятся новые способы решения проблем.
Sprint Backlog – это список рабочих задач, историй или исправлений багов, отобранных командой разработчиков из User Story, написанных в Product Backlog. Перед каждым спринтом проводится собрание по планированию спринта (его мы обсудим далее в статье), в котором команда выбирает, какие задачи по бэклогу продукта нужно выполнить в рамках спринта. Беклог спринта может быть фиксированным и может изменяться по ходу спринта. Однако ничто не должно мешать достижению основной цели спринта – того, чего команда хочет достичь за текущий спринт.
Increment – это готовый к использованию конечный продукт по итогам спринта. Инкремент презентуется на демонстрации в конце спринта, где команда показывает, что она сделала спринтом. Его часто определяют как критерий готовности продукта, контрольную точку, цель спринта или даже полную версию или поставленный эпик. Все зависит от того, какими критериями готовности руководствуется ваша команда и как выбираются цели спринта. К примеру, некоторые команды предпочитают выпускать что-то для своих клиентов в конце каждого спринта. Их слово «готово» означает «поставлено». Однако для других команд это может быть непрактичным. Представьте, что вы работаете над серверным продуктом, который можно поставлять клиентам раз в три месяца. Вы по-прежнему можете разбивать работу на двухнедельные спринты, но ваш продукт будет готов, когда вы завершите работу над частью большей версии, которую планируете поставить целиком. Однако не будем забывать, что чем больше времени уходит на выпуск ПО, тем меньше шансов у этого ПО преуспеть.

Ивенты Scrum
Sprint – это промежуток времени, в течение которого команда Scrum совместно работает над созданием готового инкремента. Как правило, спринт длится две недели, хотя некоторые команды выбирают объем спринта в одну неделю или поставить инкремент, имеющий достаточную ценность быстрее. Дэйв Вест из Scrum.org рекомендует планировать спринт тем короче, чем сложнее работа и чем больше в ней неизвестных. Но последнее слово всегда за командой. Не стесняйтесь изменять продолжительность спринта, если кажется, что вам не подходит. В течение этого периода владелец продукта и команда разработчиков могут просмотреть объем спринта, если это необходимо. Это и есть ключ к пониманию эмпирической сущности Scrum.
Все мероприятия по планированию до ретроспективы проводятся в течение спринта. После того, как временный промежуток для спринта определен, он должен оставаться неизменным, пока ведется разработка. Так команда будет извлекать ценные уроки из прошлого опыта и применять выводы к будущим спринтам.
Sprint Planning — на этом собрании, которое длится максимум 8 часов, команда разработчиков под руководством Scrum-мастера планирует работу (объем спринта), которую необходимо выполнить в течение текущего спринта. На нем определяется цель спринта. Затем в Sprint Backlog добавляются конкретные User Story из Product Backlog. Эти истории всегда соотносятся с целями. При этом команда Scrum согласовывает такие истории, которые можно реализовать практически во время спринта.
В конце собрания каждый член команды Scrum должен четко представлять, какие задачи можно выполнить за спринт и как поставить инкремент.
Daily Scrum meeting – это очень короткое ежедневное собрание, которое для удобства проводится в одно и то же время (обычно утром) и в том же месте. Многие команды пытаются уложиться в 15 минут, однако это только рекомендация. Ежедневное Scrum-совещание проводится, чтобы каждый участник команды был в курсе происходящего, не отклонялся от цели и получал план работы на ближайшие 24 часа. На этом собрании каждый участник команды отвечает на вопрос: что он сделал вчера, что он планирует делать сегодня и какие у него возникли проблемы.
Sprint Review – в конце спринта команда собирается для просмотра демонстрации инкремента (или его изучения) в неформальной обстановке. Команда разработчиков представляет заинтересованным сторонам и коллегам завершенные рабочие задания по бэклогу, чтобы собрать отзывы. Владелец продукта решает, следует ли выпускать инкремент.
Во время совещания Product Owner изменяет Product Backlog исходя из результатов последнего завершенного спринта. Этот процесс может перейти в планирование следующего спринта. Совещание длится 3-4 часа.
Sprint Retrospective – проводится, чтобы команда зафиксировала и обсудила все успехи и неудачи спринта, проекта, участников, их взаимоотношений и инструментов. Цель ретроспективы — создать условия, чтобы команда могла оценить все, что удалось и нужно улучшить в следующий раз, и не зацикливалась на неудачах. Продолжается 1-3 часа.

Связаться с нами

    Адрес: г. Киев, 03058, а/я 24