Тема_16_Гибкие_меÑ‚одологии_Agile

1.

Тема 2. Agile

2.

История
11-13 февраля 2001 года 17 известных экспертов-практиков разработки
программного обеспечения собрались в кондоминиуме The Lodge
горнолыжного курорта Snowbird в горах Уосатч в штате Юта.
Каждый практиковал какую-то альтернативу тяжеловесным процессам,
основанным на документации. Они собрались поговорить, покататься на
лыжах, отдохнуть и найти то общее, что объединяет их процессы/методы,
которые в то время уже называли lightweight/легковесными
Extreme Programming,
Scrum,
DSDM, Dynamic Systems Development Method,
Adaptive Software Development,
Семейство Crystal, вкл. Clear,
FDD, Feature-Driven Development,
Pragmatic Programming,
и другие

3.

4.

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

5.

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

6.

Agile: Манифест
Люди
и взаимодействие
Важнее
Процессов
и инструментов
Сотрудничество
с заказчиком
Важнее
Согласования
контракта
Работающий
продукт
Важнее
Исчерпывающей
документации
Готовность
к изменениям
Важнее
Следования
плану

7.

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

8.

Работающая программа важнее
исчерпывающей документации
Команда обязана подготовить понятные человеку документы, в которых
бы описывалась система и обосновывались принятые проектные
решения
Слишком много документации хуже, чем слишком мало
На создание огромных томов документации уходит много времени и
еще больше – на синхронизацию их с кодом
Если же документация не соответствует коду, то становится большой и
запутанной ложью и источником дезинформации
Необходимо избегать WO (write only) документации
Agile-команды не очень любят бумажную работу. Для управления
данными, отчетами и обновлениями статуса они предпочитают
использовать гибкие программные решения, а не традиционную
документацию
Необходимо использовать инструменты компактного изложения
информации и ее быстрой модификации (например, графические
нотации и иные подходы и инструменты)

9.

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

10.

Реагирование на изменение
важнее следования плану
Изменение – не форс-мажор, изменение – это норма
Строя планы, необходимо следить за тем, чтобы они были гибкими
и могли адаптироваться к изменениям в бизнесе и технологиях
Ход работы над проектом нельзя планировать на длительный срок
Agile-команды чутко реагируют на изменения и успешно
адаптируются к новым условиям и вызовам
Готовность к изменениям – это когда команда понимает: «Да мы
сделали не то, но мы же здравые люди, давайте поменяем нашу
модель поведения и все исправим»

11.

Agile: 12 принципов
Удовлетворение
заказчика
Изменения
приветствуются
Быстрая
доставка
Работать
вместе
Расширение
полномочий
Эффективные
коммуникации
Работающий
продукт
Устойчивый
процесс
Техническое
совершенство
Простота
Самоорганизующиеся
команды
Систематические
улучшения

12.

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

13.

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

14.

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

15.

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

16.

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

17.

Принцип: Расширение полномочий
Над проектом должны работать мотивированные профессионалы. Чтобы
работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им
Проекты работают лучше, когда каждый в компании признает, что
команда создает значимый продукт, и ее члены, в том числе владелец
продукта, понимают, что придает продукту значимость и делает его
ценным для компании
Производительность каждого специалиста должна основываться на
достижениях команды, а не на тех ролях, которые они играют в проекте
Не должно быть жестких функциональных разграничений в команде.
Хорошие условия работы будут стимулировать программиста, который
распознает часть бизнес-задачи и решит ее, или тестировщика,
увидевшего недочеты кода либо архитектуры и устранившего их.
Leadership - Поощряйте лидерство на всех уровнях. Лидеров в командах
может быть много. Идеально, каждый член команды должен быть
лидером

18.

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

19.

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

20.

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

21.

Принцип: Устойчивый процесс
Инвесторы, разработчики и пользователи должны иметь возможность
поддерживать постоянный ритм бесконечно. Agile помогает наладить
такой устойчивый процесс разработки
Agile-команды стремятся к сохранению устойчивого темпа. Они планируют
выполнение задания, которое действительно можно сделать за выделенное для
него время.
Планирование итерации позволяет избегать переработок и выгорания членов
команды. Они планируют выполнение задания, которое действительно можно
сделать за выделенное для него время
Agile-команды постоянно отслеживают свой прогресс (анализ запланированных
и выполненных работ)
Команда всегда должна измерять свою «скорость прожигания денег» и следить
за тем, чтобы она соответствовала количеству business value, которое команда
поставляет. Просто быть счастливой командой — это не то, что предлагает
Манифест

22.

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

23.

Принцип: Простота
Простота — искусство минимизации лишней работы — крайне
необходима
KISS (Keep It Simple, Stupid) — принцип проектирования, принятый в ВМС США
в 1960. Принцип KISS утверждает, что большинство систем работают лучше
всего, если они остаются простыми, а не усложняются. Чем сложнее система,
тем больше у нее точек отказа
Огромные задачи — самая большая угроза управляемости любой команды.
Простая задача — это четко определенная маленькая выполнимая инструкция
Жесткие зависимости между системами, объектами, услугами и прочим делают
продукт более сложным и трудно изменяемым: зависимости повышают
вероятность того, что одно изменение может привести к каскадным изменениям
в другой части системы, которые, в свою очередь, вызовут изменения в третьей,
создавая эффект домино с возрастающей сложностью для каждого изменения.
Если функция не является ценной, то в долгосрочной перспективе для компании
дешевле не создавать ее вовсе. Потому что расходы на содержание
дополнительной функции выше, чем стоимость самой разработки.

24.

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

25.

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

26.

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

27.

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

28.

Манифест не
содержит готовых
практик по
воплощению проектов
в жизнь. Для этого
нужно использовать
инструментарий других
методов управления
проектами (например,
SCRUM, Crystal,
Kanban и др.)

29.

Lean и Agile схожи
Безжалостно
избавляйтесь
от
всего,
дополнительной ценности: бесполезные
документацию
что
не
собрания,
добавляет
задачи и
Улучшайте всю систему в целом, а не ее отдельные элементы
Уважайте людей! Дайте возможность им делать то, что они лучше
всего умеют и хотят делать