12. Agile-манифест разработки программного
обеспечения
Мы постоянно открываем для себя более совершенные методы разработки
программного обеспечения, занимаясь разработкой непосредственно и помогая
в этом другим. Благодаря проделанной работе мы смогли осознать, что:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то,
что слева.
http://www.agilemanifesto.org/iso/ru/
13. Ценности Agile
Мы постоянно открываем для себя более совершенные методы разработки
программного обеспечения, занимаясь разработкой непосредственно и помогая
в этом другим. Благодаря проделанной работе мы смогли осознать, что:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то,
что слева.
http://www.agilemanifesto.org/iso/ru/
14. Принципы Agile
1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика,
благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-
процессы позволяют использовать изменения для обеспечения заказчику конкурентного
преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары
недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно
работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была
сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом
обмена информацией как с самой командой, так и внутри команды.
15. Принципы Agile
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать
постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс
разработки.
9. Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.
10.Простота — искусство минимизации лишней работы — крайне необходима.
11.Самые лучшие требования, архитектурные и технические решения рождаются у
самоорганизующихся команд.
12.Команда должна систематически анализировать возможные способы улучшения
эффективности и соответственно корректировать стиль своей работы.
36. Scrum в двух словах
Беклог продукта Беклог спринта
Скам-митинг
15 минут
Готовый продукт с
новой
функциональностью
Владелец
продукта
Владелец
продукта
8 часов
Спринт
1-4 недели
Ретроспектива
Обзор спринта
Планирование
спринта
Скрам-мастер
Команда
7±2 человек
37. Определение
Фреймворк, в рамках которого возможно решать
сложные адаптивные проблемы и в то же время
продуктивно и креативно разрабатывать продукты
наивысшего качества.
38. Элементы Scrum
Роли
• Владелец
продукта
• Скрам-мастер
• Команда
разработки
• Команда
Артефакты
• Бэклог
продукта
• Бэклог
спринта
• Инкремент
продукта
Процессы
• Планирование
спринта
• Обзор спринта
• Ретроспектива
• Скрам-митинг
• Спринт
39. Роли
• Скрам Команда состоит из Владельца Продукта, Команды
Разработки и Скрам Мастера. Скрам Команды являются
самоорганизующимися и кросс-функциональными
Скрам Команда
• Владелец Продукта ответственен за достижение максимальной
ценности продукта и работы, выполняемой Командой
Разработки.
Владелец
Продукта
• Команда Разработки состоит из профессионалов, выполняющих
работу по разработке потенциально “Готового” к выпуску
Инкремента продукта каждый Спринт
Команда
Разработки
• Скрам Мастер отвечает за то, чтобы Скрам был понят всеми
участниками и работал.Скрам Мастер
40. Процессы
• Сердцем Скрама является Спринт длительностью в один месяц или менее, в течение
которого создается потенциально готовый̆ к выпуску и использованию Инкремент
продукта.
Спринт
• Работа на предстоящий Спринт планируется во время Планирования Спринта. План
действий создается при совместной работе всей Скрам Команды.Планирование Спринта
• Ежедневные Скрамы –это 15-минутные мероприятия для Команды Разработки с целью
синхронизации действий и создания плана работы на ближайшие 24 часа.Ежедневный Скрам
• Встреча по Обзору Спринта проводится в конце Спринта для инспекции Инкремента и
при необходимости адаптации Беклога Продукта. Во время Обзора Спринта Скрам
Команда и заинтересованные лица обсуждают выполненную во время Спринта работу
Обзор Спринта
• Ретроспектива Спринта дает Скрам Команде возможность инспектировать себя и создать
план улучшений для следующего Спринта.Ретроспектива Спринта
41. Артефакты
• Упорядоченный список всего, что может быть нужным в
продукте, он является единственным источником требований
для любых изменений, которые может потребоваться внести в
продукт.
Беклог
Продукта
• Набор Элементов Беклога Продукта, выбранных для
выполнения в текущем Спринте, а также план разработки
Инкремента продукта
Беклог
Спринта
• Сумма всех выполненных требований Беклога Продукта,
реализованных во время текущего Спринта, и ценности всех
предыдущих Спринтов
Инкремент
59. Ретроспектива
Не хочешь пропустить со
мной по пиву?
Не могу, я делаю
список, в чем я
могу
усовершенствовать
себя в следующем
году
Не-
плохая
идея,
сделаю
тоже
самое
Ничего.
Совершенство достигнуто
Мда, вот
это
конструк-
тивность.
Какая едкая
зависть,
тебе бы
поработать
над этим
«Совершенствоваться не
обязательно. Выживание – дело
добровольное»
66. Принципы
1. Начать с того, что делаем сейчас
2. Придти к соглашению идти путём
эволюционных перемен
3. Изначально уважать существующие роли,
должности и обязанности
4. Поощрять инициативные действия на всех
уровнях организации
67. Практики
Визуализация
Ограничение работы в процессе
Управление потоком
Явные правила
Обратные связи
Улучшения с помощью экспериментов,
используя модели и научный подход
Организуйте работу в вашей организации в небольших кроссфункциональных командах, которые содержат всех необходимых специалистов для реализации проекта. Выделите человека - скрам-мастера, который будет отвечать за соблюдение процессов в команде и конструктивную атмосферу.
Требования разбейте на небольшие, ориентированные на пользователей, функциональные части, которые максимально независимы друг от друга, в результате чего получите бэклог продукта. Затем упорядочите элементы бэклога по их важности и произведите относительную оценку объемов каждого элемента. Выделите отдельного человека – владельца продукта, который будет отвечать за требования и их приоритеты, работая с заинтересованными лицами.
Всю работу ведите короткими (от 1 до 4 недель) фиксированными итерациями – спринтами, поставляя в конце каждого из них законченный функционал, который можно при необходимости вывести на рынок – инкремент продукта. Команда согласно своей скорости набирает задачи на неизменяемую по времени итерацию – спринт. Каждый день проводится скрам-митинг, на котором команда синхронизирует свою работу и обсуждает проблемы. В процессе работы члены команды берут в работу элементы бэклога согласно приоритету.
В конце каждого спринта проводите обзор спринта, чтобы получить обратную связь от владельца продукта, и ретроспективу спринта, чтобы оптимизировать ваши процессы. После этого владелец продукта может изменить требования и их приоритеты и запустить новый спринт.
Роли
В Scrum принято выделять три основных роли, которые составляют в Scrum-команду: владелец продукта, скрам-мастер и команда разработки.
Владелец продукта (Product owner, Продукт оунер, Менеджер продукта) – это член команды, ответственный за максимизацию ценности продукта и управление бэклогом продукта;
Скрам-мастер (Scrum Master) – член команды, который дополнительно отвечает за процессы, координацию работы команды и поддержание социальной атмосферы в команде.
Команда разработки (Development Team) – это кроссфункциональная и самоорганизующаяся группа специалистов, которая создает инкремент продукта.
Владелец продукта
Основной задачей владельца продукта является максимизация ценности продукта через управление бэклогом продукта включая:
Создание и обработку элементов бэклога;
Приоритезацию элементов бэклога;
Выработку понимания элементов бэклога у команды;
Часть из этих задач владелец продукта может делегировать членам команды, но он остается ответственным за них. Кроме того, владелец продукта – это всегда один человек, а не группы или комитет, и все требования в виде элементов бэклога поступают команде через него.
Команда разработки
Команда разработки каждый спринт поставляет потенциально готовый к релизу продукт. Она состоит из кроссфункциональных специалистов без разделение на профессии, хотя возможны специализации отдельных ее членов, но ответственность за поставку все равно лежит на команде в целом.
Важным свойством команды разработки является ее самоорганизация: она сама определяет способ, которым сделает из элементов бэклога инкремент продукта.
Минимальный размер команды разработки – 3 человека, не считая владельца продукта и скрам-мастера, если они непосредственно не участвуют в создании инкремента. Максимальный размер команды - 9 человек, так как при дальнейшем увеличении теряется эффективность.
Скрам-мастер
Скрам-мастер – это член команды, который ответственен за понимание и реализацию Scrum’а, и помогает в этом следующим субъектам:
Владелец продукта
Помогает в планировании и оценке элементов бэклога
По необходимости помогает в организации процессов
Команда разработки
Обучает команду самоорганизации и кроссфункциональности
Устраняет внешние препятсвия
По необходимости помогает в организации процессов
Организация в целом
Адаптирует Scrum в соответствии с потребностями организации
Помогает понять внешним к команде людям Scrum
Обменивается лучшими практиками с другими скрам-мастерами
К сожалению даже в 21-ом веке оценки программных проектов производятся очень плохо. Фактически менеджер просто высказывает догадки на основе своего опыта…
Фундаментальная проблема лежит в области того, что я бы назвал «корпоративной психологии». Дело в том, что для оценки DM-проектов необходимо база знаний не по обычным проектам (да и такие базы не всегда ведутся в наших компаниях), а именно формализованные знания по DM-проектам. Но компании предпочитают как можно быстрей забывать про такие проекты, как на уровне менеджмента, так и на уровне команд.
Таким образом, использую опыт обычных проектов оценки делают достаточно оптимистичные, что еще больше загоняет проект в разряд неподъемных.
В долгосрочном плане ретроспективы (или сокращенно «ретро») являются самой важной практикой Scrum: ведь именно они позволяют адаптировать и кастомизировать Scrum, делая из него по-настоящему гибкий фреймворк для управления проектами.
Ретроспективу традиционно проводят после обзора спринта спустя небольшое количество времени, чтобы оперативно получить фидбек. Скрам-мастер собирают всю команду для обсуждения результатов спринта. Рекомендуется на ретроспективу приглашать владельца продукта для получения дополнительной обратной связи.
Структура ретроспективы
Обычно ретроспектива занимает от 30 минут до 4 часов и ее продолжительность зависит от следующих факторов:
Длина спринта: чем длиннее спринт, тем больше команда успевает сделать и тем больше материала для обсуждения;
Размер команды: чем команда больше, тем больше надо времени, чтобы у каждого ее члена была возможность высказаться и тем больше функционала команда успевает сделать;
Наличие проблем: со временем команда решает проблемы и ретроспективы сокращаются по времени.
В процентном соотношении принято выделять такую структуру.
Также традиционным является формат по сбору данных, который заключается в ответах каждого участника на три вопроса:
Что было сделано хорошо?
Что можно улучшить?
Какие улучшения будем делать?
Количество улучшений, которые команда берет в реализацию, не должно превышать 2-3, чтобы не снизить скорость реализации бизнес-функционала и не потерять фокус. Команда должна обязательно в том или ином виде составить план улучшений для контроля их исполнения.
Для максимальной открытости и прозрачности обсуждения необходимо использовать основное правило ретроспективы, которое можно озвучивать в начале:
«В независимости от того, что удастся выяснить в результате ретроспективы, каждый член команды сделал всё, чтобы добиться успеха»
Если у команды отсутствуют яркие проблемы, то желательно следующие темы обсудить на ретроспективе:
скорость команды и ее изменение по сравнению с предыдущими спринтами;
нереализованные истории пользователей и причины опоздания;
дефекты и их причины;
качество процессов (нарушения, отступления).
К паттернам можно отнести анализ сделанных улучшений за несколько прошлых спринтов. Такая «ретроспектива ретроспектив» может проводить раз в 4 спринта и позволяет контролировать уровень сделанных улучшений.
Акцент делаем на научном подходе.
Plan (планирование)
Производится анализ системы и вырабатываются возможные подходы к улучшениям и определяются желаемые результаты
Do (исполнение)
Решения, выработанные на предыдущем шаге, реализуются.
Check (проверка)
Производится анализ, полученных результатов, на предыдущем шаге.
Act (корректировка)
Выполняются корректирующие действия, для уменьшения отклонений от плана.
