Цель книги: познакомить читателя с методами Agile, а так же ценностями и принципами, проповедующими гибкие подходы к разработке программного обеспечения
Лично мне, книга интересна тем, что на ее страницах раскрываются тайны таких модных понятий как Agile, Scrum, XP, Lean, Kanban как обособленно, так и в сравнении, а, точнее, в гармоничных комбинациях. Другими словами эти методологии и философии дополняют друг друга или лучше раскрывают…
Основные понятия, которые для себя отметил описываются ниже.
Agile
Именно изменение образа мыслей превращает группу сотрудников, добавляющую в свою работу несколько agile-методов, в настоящую команду, которая действительно улучшает способ создания ПО
Манифест гибкой разработки программного обеспечения:
— Люди и взаимодействия важнее процессов и инструментов
— Работающий программный продукт важнее исчерпывающей документации
— Сотрудничество с заказчиками важнее согласования условий контракта
— Готовность к изменениям важнее следования первоначальному плану
12 принципов гибкой разработки программного обеспечения
- Наш наивысший приоритет — это удовлетворение заказчика при помощи частых и непрерывных поставок ценного для него программного обеспечения.
Agile-команды удовлетворяют своих клиентов, получая обратную связь на ранних этапах проекта, и непрерывно поставляют программное обеспечение, чтобы сохранить эту связь актуальной
- Мы принимаем изменения в требованиях даже на поздних этапах реализации проекта. Agile-процессы позволяют использовать изменения для повышения конкурентоспособности продукта.
Agile-команды одобряют изменения, рассматривая их как положительные и полезные события для проекта
- Мы стремимся поставлять полностью рабочее программное обеспечение каждые несколько недель, в крайнем случае — каждые несколько месяцев. Чем чаще, тем лучше.
Используя ограниченную продолжительность итераций при частой поставке работающего программного обеспечения, agile-команды постоянно корректируют проект, поэтому он обеспечивает наибольшую ценность для потребителя
- Наиболее эффективный и действенный способ передачи информации — это встреча членов команды разработки ПО.
Наиболее эффективное общение между членами agile-команды происходит тогда, когда они сосредоточены на разговоре лицом к лицу и опираются на минимальное количество документации, необходимой для реализации проекта
- Представители бизнеса и команда разработки должны работать над проектом вместе.
Для достижения наибольшей ценности программного продукта разработчики ежедневно общаются с бизнес-пользователями
- Проекты строятся вокруг мотивированных людей. Создайте для них подходящую окружающую среду, снабдите всем необходимым и доверьте сделать свою работ
Каждый член agile-команды чувствует свою ответственность за проект и отвечает за успех
- Рабочее программное обеспечение — это главная мера прогресса проекта.
Наиболее эффективный способ коммуникации в ходе реализации проекта — поставка рабочего программного обеспечения и передача его в руки пользователя
- Гибкие процессы способствуют непрерывному развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп работы в течение неопределенного срока.
Наиболее продуктивно команды работают в устойчивом темпе, без ненужного героизма и сверхурочных
- Постоянное внимание к техническому совершенству и качественной архитектуре способствует гибкости.
Хорошо разработанное и реализованное программное обеспечение намного быстрее поставляется клиенту, потому что в него проще вносить изменения
- Простота — это искусство не делать лишней работы.
Гибкие команды создают максимально простые решения, избегая ненужных функций или чрезмерно сложного программного обеспечения
- Лучшая архитектура, требования и дизайн создаются в самоорганизующихся командах.
Самоорганизующиеся команды разделяют ответственность за все аспекты проекта, начиная с замысла создания продукта и заканчивая его реализацией
- Команда постоянно ищет способы стать более эффективной путем настройки и коррекции своих действий
Выделяя время на то, чтобы обсудить уроки, которые они получили после каждой итерации и в конце проекта, agile-команды постоянно улучшают свои компетенции в области разработки программного обеспечения
Scrum
Правила Scrum
— В scrum-проекте существует три основные роли: владелец продукта, scrum-мастер и член команды.
— Владелец продукта работает с остальной частью команды, чтобы поддерживать и определять приоритеты функций и требований продуктового бэклога, которые необходимо реализовать.
— Программное обеспечение строится с использованием ограниченных по времени итераций, называемых спринтами. В начале каждой такой итерации команда выполняет планирование спринта, чтобы определить, какие функции из бэклога они будут реализовывать. Это называется бэклог спринта. На протяжении спринта команда работает над созданием всех тех функций, которые в него вошли.
— Ежедневно все члены команды участвуют в короткой встрече (Daily Scrum — ежедневный scrum-митинг), чтобы рассказать друг другу о достижениях и обсудить то, что препятствует дальнейшей работе. Каждый человек отвечает на три вопроса: что я сделал с момента последнего ежедневного совещания? Что буду делать вплоть до следующего ежедневного совещания? Какие препятствия есть на моем пути?
— Scrum-мастер поддерживает правильное направление работы над проектом, устраняет препятствия на пути команды и помогает ей, если есть просьбы о помощи. В конце спринта работающее ПО показывают владельцу продукта и стейкхолдерам проекта. Команда проводит одновременно обзор итогов спринта и ретроспективный обзор, чтобы выяснить ошибки. Таким образом удается улучшить сам процесс спринта и качество создания программного продукта в будущем.
Чтобы работать по Scrum, команда должна глубоко и на интуитивном уровне понимать коллективную ответственность и самоорганизацию
Каждый разработчик должен чувствовать себя комфортно, отвечая за работу, под которой он подписался. А поскольку команда исповедует принцип «это наше общее дело», комфортно должен чувствовать себя каждый ее участник
Пользовательская история эффективна, поскольку делает очевидными три важные особенности:
— Кто наш пользователь: «постоянный посетитель сайта, имеющий длинный список друзей».
— Что хочет сделать пользователь: «номинировать видео одного из своих друзей на достижение».
— Почему пользователь хочет это сделать: «чтобы все наши общие друзья смогли за него проголосовать».
Экстремальное программирование
Две основные практики XP — разработка через тестирование и парное программирование
Lean (бережливое мышление)
Lean — это мышление, а не методология
Команды при помощи бережливого мышления ведут работу по ликвидации потерь, находя любые виды деятельности, которые напрямую не способствуют построению ценных продуктов, и устраняя их
Любая деятельность, которая явно не добавляет ценности проекту, считается потерями. Lean-команды стремятся увидеть их и исключить из проектов, насколько это возможно.
Канбан
Канбан — это метод улучшения процессов, используемых гибкими командами
Канбан отличается от гибких методологий, таких как Scrum и ХР.
Scrum преимущественно ориентирован на управление проектами: объем работы, который должен быть проделан, чтобы эта работа была выполнена, и результат, необходимый пользователям и стейкхолдерам.
ХР ориентирована на разработку программного обеспечения, ее ценности и практики строятся вокруг создания благоприятных условий для развития и формирования привычек, помогающих разработчику писать простой и легко изменяемый код.
Канбан помогает команде улучшить способы разработки программного обеспечения. Команда, использующая этот метод, имеет четкое представление о том, какие действия совершает при создании программного продукта, как взаимодействует с остальной компанией, как образуются потери, вызванные неэффективностью и неравномерностью, и каким образом со временем исправить ситуацию, устранив основную причину этих потерь.
Во-первых, следуйте основополагающим принципам:
— Начните с того, что вы делаете сейчас, уважайте имеющиеся роли, обязанности и должностные инструкции.
Другими словами, первый этап в улучшении процесса — это понимание того, как в настоящее время работает команда.
— Договоритесь об эволюционном развитии.
— Поощряйте лидерство на всех уровнях.
Затем принимайтесь за основные практики:
— визуализацию;
— ограничение числа задач в работе (WIP);
— управление потоком;
— сделайте правила явными;
— введите петли обратной связи;
— развивайтесь совместно и экспериментируйте (используя моделирование или научный подход).
Типичная канбан-доска показывает крупные рабочие элементы, а не отдельные задачи
