Сразу бы хотелось отметить, что книга не рассчитана на людей, которые с нуля (для таких ребят, советую начать с другой книги, представленной в моей статье) хотят разобраться в гибких методологиях, скорее, она (книга) для тех, кто уже успел опробовать какие то методологии и проявляет интерес к этой области. А еще лучше подойдет тем, кто сомневается, правильно ли организованы Agile процессы в команде, так как автор отмечает, что многие организации не понимают или внедряют методы не верно (что может только усугубить проблемы процессов).
Книга написана человеком, который стоял у истоков создания манифеста гибких методологий.
Все началось со знаковой встречи семнадцати профессионалов разработки программного обеспечения в феврале 2001, чтобы поделиться своими мыслями по поводу эффективности разработки и, в итоге, сформировать Манифест Agile. И за два десятка лет понимание этих принципов претерпело изменения, по мнению автора, далеко не все положительные.
Мысли автора описаны в неформально-разговорном стиле, поэтому некоторые выражения могут показаться не совсем корректными.
Книга не большая по объему, так как Agile — небольшая идея, предназначенная для решения небольших задач, поставленных небольшими командами программистов, которые выполняют небольшую работу. (Agile не рассчитан на решение крупных задач больших команд программистов, которые занимаются крупными проектами). Здесь представлены основные принципы Agile. И производные от Agile — это уже не сам Agile. Это дополненный Agile со своими опциями.
Вся суть Agile в четырех предложениях Манифеста:
Люди и взаимодействия важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
Автор отмечает интересный факт, что некоторые думают, что Agile способствует скорости выполнения проекта. Это не так. Agile никогда не ставил своей целью выполнить и сдать проект поскорее. Agile помогает вовремя понять то, где и насколько мы облажались. Другими словами, главная цель Agile — защита от самообмана, мы применяем Agile, точны избавиться от ложных надежд, которые в итоге приведут проект к краху.
По мнению Роберта Мартина наиболее подходящий метод Agile — метод экстремального программирования. Из всех методологий Agile это наиболее определенная, исчерпывающая и наименее запутанная методология. В книге этой методологии уделяется, непосредственно, много страниц. Некоторые другие важные методы: метафора, 40-часовая рабочая неделя, коллективное владение и непрерывная интеграция.
Один из наиболее важных методов экстремального программирования — разработка через тестирование. Ее можно описать тремя простыми правилами:
Не пишите готовый код до того, как напишите тест, который не получится пройти из-за нехватки этого кода
Не пишите тестов больше, чем это необходимо для неудачи, — сбой при компиляции также считается неудачей
Не пишите рогового кода больше, чем достаточно для прохождения теста, который был провален до этого
Еще один важный метод экстремального программирования — парное программирование. Многие отрицательно воспринимают мысль о том, что два (или более) человека могут плодотворно работать над одной и той же задачей. Однако, работа в паре не обязательна. Никого не стоит принуждать. А еще, работа в паре не обязательно постоянна. Существует много веских причин работать в одиночестве. Право выбора сколько времени работать в паре принадлежит членам команды, самим программистам.
В финале, хотелось бы отметить мысли автора по поводу нового Манифеста Agile, который дополняет оригинальный манифест и расширяет его с точки гения подхода Высшего мастерства разработки.
Являясь устремленными к совершенству мастерами разработки ПО, мы повышаем уровень профессиональной разработки ПО, делая это сами и помогая другим осваивать наше ремесло.
Занимаясь этой деятельностью, мы прежде всего научились ценить:
Не только работающий продукт, но также и искусно разработанный продукт.
Не только готовность к изменениям, но также и постоянное увеличение ценности.
Не только людей и взаимодействие, но также и содружество профессионалов.
Не только сотрудничество с заказчиком, но также и плодотворное партнерство.
Цель книги: познакомить читателя с методами 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); — управление потоком; — сделайте правила явными; — введите петли обратной связи; — развивайтесь совместно и экспериментируйте (используя моделирование или научный подход).
Типичная канбан-доска показывает крупные рабочие элементы, а не отдельные задачи
