Upload
sergey-gelmetdinov
View
784
Download
2
Embed Size (px)
DESCRIPTION
Citation preview
1
Scrum Framework практика использования
Гельметдинов Сергей
Проблемы создания ПО
2
• Все что нам нужно:• Сделать «правильную систему» нужным
способом• Поставить программное обеспечение в срок• Сделать организацию счастливее от того,
что сделали
• Кусок пирога, верно?
Понятия
3
Основы SCRUM Люди Продукт Действие
Плюс еще немного … Сделать «не хуже» чем было Нужно попытаться, первый шаг за Вами…
Люди+
ДействиеПродукт
SCRUM
4
5
Как это было• Agile Manifesto разработан и принят 11-13
февраля 2001• Agile Manifesto cодержит 4 ценности, 12
принципов и не содержит практик
5
6
Как это было: ПодходПодход включает ценности, значимость которых
нивелирована:[3]
личности и их взаимодействия важнее, чем процессы и инструменты;
работающее программное обеспечение важнее, чем полная документация;
сотрудничество с заказчиком важнее, чем контрактные обязательства;
реакция на изменения важнее, чем следование плану.
6
7
Как это было: ПринципыПринципы, которые разъясняет Agile Manifesto[4]:
удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО; приветствие изменения требований, даже в конце разработки ( это может повысить
конкурентоспособность полученного продукта); частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще); тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта; проектом занимаются мотивированные личности, которые обеспечены нужными
условиями работы, поддержкой и доверием; рекомендуемый метод передачи информации — личный разговор (лицом к лицу); работающее ПО — лучший измеритель прогресса; спонсоры, разработчики и пользователи должны иметь возможность поддерживать
постоянный темп на неопределенный срок; постоянное внимание на улучшение технического мастерства и удобный дизайн; простота — искусство НЕ делать лишней работы; лучшие архитектура, требования и дизайн получаются у самоорганизованной команды; постоянная (частая) адаптация (улучшение эффективности работы) к изменяющимся
обстоятельствам.
7
Сравним “Agile vs. Waterfall”
8
Сравним
• SCRUM против «Итеративной разработки»
9
Сравним
Водопад
Итеративный водопад Agile
SCRUM это -
• Простой фреймворк, который может быть изучен и внедрен за несколько дней
• Призван решать комплексные задачи• Получение выгод от взаимодействия
разработчиков и заказчиков• Инструмент (оболочка) для управления
инженерными практиками с выгодой получения готовых продуктов с определенным интервалом
11
SCRUM это не -
• Серебряная пуля• Не новейшая технология• SCRUM не имеет плана действий для
непредвиденных обстоятельств
“Scrum is not a methodology – it is a pathway” (Ken Schwaber)
12
Сравним “Agile vs. Waterfall”
13
ВОДОПАД
Требования
СтоимостьСрок
AGILE
СрокСтоимость
Требования
Фиксируем это:
Оцениваем это:
Два ключевых принципа в SCRUM
• Эмпирический продвижение – детализированное предварительное планирование и определенность в ходе работ заменяют постоянные проверки и замкнутые циклы• Детальная проработка заданий• Исполнение всех артефактов процесса• Максимально адаптировать процесс под себя и себя под
процесс
• Самоорганизация – команды являются самоорганизованными и организуют себя для достижения цели в заданных рамках
14
SCRUM Workflow
15
Роли
Product owner (владелец продукта) – олицетворение пожеланий заказчика
Scrum Master – …
Команда – самоорганизующаяся группа, в состав которой входят разработчики, дизайнеры, тестировщики, документаторы
16
ЗаказчикВладелец бизнеса
SME (ЭСО)
SME (ЭСО)SME (ЭСО)
SME (ЭСО)
17
Больше о ролях
Термины
User Story – описание требований
Размер
Стоимость
Соглашение
Task – декомпозированная задача
Icebox – Список требований без приоритетов
Backlog – Сформированный список требованийProduct Backlog – сформированный список требований на
несколько итераций
Sprint Backlog – сформированный, приоритеризированный список требований на одну итерацию разработки
Sprint – Итерация разработки
Результат (продукт) – работающий, проверенный и интегрированный код, документация
18
Еще немного терминов
Daily (Stand-Up) Meeting - Ежедневная «летучка»
Sprint Review (Demo)
Ретроспектива
Story Point
Burn-down Chart
19
ProductOwner (Владелец продукта)Определение
Владелец Продукта ответственный за то, что разрабатывает команда и оптимизацию стоимостной составляющей (“The enterprise and SCRUM”, 2008)
Product Owner – is the “single, wringable, neck”
Принимает решения и учитывает риски:Требования заказчиков
Что войдет в продукт (Стратегически и Тактическая)
Будет ли прибавка функциональности дорогой с точки зрения экономических и временных показателей
20
Обязанности Product OwnerСоздавать User Stories
Описать условия приема истории
Оценить ценность истории
Ответственный за риски вложений (ROI) – знает нужды бизнеса и нужды заказчиков
Приоритезировать список разработки согласно требованиям заказчиков с учетом стоимости разработки
Абсолютный арбитраж в описании требований
Аналитики команды работают на Product Owner
Определять условия готовности и рекомендации с учетом мнения команды
Принимает решение о необходимости разработки
Может изменять требования и приоритеты каждую итерацию
21
Scrum MasterСледит за исполнением разработки
Управляет внутренней динамикой внутри команды
Следит за исполнением «правил» SCRUM
Следит за вовлечением всех участников во все митинги
Делает все процессы видимыми
Использовать лучшие практики (технические, а также опыт SCRUM)
Защищает команду от внешнего воздействия
Способствовать разрешению проблем (без возможности руководить)
22
Product Owner и Scrum MasterPO – это человек, который ответственен за то, что
команда делает, а также за оптимизацию расходов на разработку
SM – ответственен за исполнение процессов SCRUM, его правильное внедрение и максимизацию преимуществ
По сути, Scrum Master – это человек, который учит Product Owner как максимально эффективно сделать задачу посредством SCRUM силами команды
PO vs. SM точно также вместе как:
Ром и кока-кола (Д. Дибров)
Жиглов и Шарапов ()
Дед мороз и снегурочка (Снежинка)
23
Команда
Многофункциональная, небольшая (7±2 чел.) – одна команда может содержать разработчиков, тестировщиков, дизайнеров, документаторов
Имеют представление о том, что делать, знают о рамках выполняемой задачи, характеристиках проекта для выполнения своих обязанностей
В рамках представленных задач могут выбрать чем заниматься
Самоорганизованная
Располагаются в одном помещении (в идеале)
24
Команда
25
Ключевые митингиSpring Planning – PO и команда разработчиков
декомпозируют User Stories, определяют время реализации. Результатом является сформированный Sprint Backlog.
Sprint Review – Обзор текущей итерации. Демонстрация функциональных новинок. Открытый для заинтересованных лиц
Daily Meeting – ежедневное собрание для того, чтобы обсудить текущее состояние выполнения задач
Ретроспектива – собрание на котором участники команды могут скорректировать процессы внутри SCRUM
26
Что сделать чтобы начать?
Набрать 3-9 человек в команду
Команда должна иметь опыт в различных областях
Заставить комнату работать
Выбрать продукт
Выбрать Product Owner
Выбрать Scrum Master
ВПЕРЕД!
27
Не так сразу …
Получить упорядоченный Backlog
Представить видение развития настолько насколько возможно
Научиться писать правильные User Story
28
И даже место имеет значение
Не просто комната, а приспособленное местоSCRUM room как артефактНеобходимость в постоянном общении и постоянного
взаимодействияКоммуникативные каналы• Прямое общение• Видеоконференция• Аудио-конференция• Instance Messenger (jabber, icq, и тд)• Электронная почта• Статичные документы
29
Если не существует Product Backlog – ничего не существует
Backlog – это список требований для команды SCRUM, который будет реализован как действительная ценность продукта
Все известные и потенциальные ошибкиo Часто встречаемые ошибкиo Вновь открытые ошибкиo Необходимость в аналитической работеo Необходимость рефакторинга кода
А что же не включать в беклог?
30
Пример User Story
31
Архитектура и дизайн
32 часа
Функциональные тесты
12 часа
Определить unit-test
12 часов
Задачи
Пример User Story
32
Пример User Story
33
Пример User Story
34
Пример User Story
35
Планирование Sprint’a
36
1. Product Owner (с помощью команды) приоритезирует истории в Backlog
2. Команда вместе с Product Owner – добавляет секции «Соглашения» в Истории с максимальным приоритетом
3. Команда без Product Owner – делит истории на задачи
4. Команда без Product Owner – решает, если она сможет ли реализовать историю в текущем спринте (путем голосования)
• Если не сможет, останавливается, рисуем полоску в Sprint Backlog над историей, которая была декомпозирована, но не команда не согласна, что успеет ее сделать в срок
* можно с согласованием PO передвинуть наверх более короткую историю и вернутся к шагу 2
• Если да, то спрашиваем команду полная ли История• Если да – останавливаемся• Если нет, начинаем со шага 2 новую Историю
Пример User Story
37
BacklogПриоритезированный список функциональных,
технологических или аналитических «историй»
Должен быть выстроен согласно приоритетам
Не бывает двух одинаково важных «историй»
Все приоритезированно, измерено по времени и стомости разработки
Технически понятные и полные описания
Каждый может согласованно расширить описание/требование
Владелец продукта ответственный за приоритеты
38
Backlog
39
«Истории» правильного размера – мелкие и понятныеБольшие истории (Epic) – большие, составные или рискованные
Все «истории» мы берем из списка Icebox
Backlog
40
Backlog
41
42
Визуализация – доска задач
43
Доска задач
44
Доска задач (программное средство)
45
Daily meeting (дневной митинг)Назначение: Для команды понять в каком статусе находятся задачи,
для своевременного реагирования на проблемы
Три вопроса: Что было сделано с прошлого митинга? Что будет сделано до следующего? Какие трудности предполагаются при выполнении?
А также: Нужно собрать метрики для графика «сгорания»
burndown chart Нужно ответить на вопросы, которые возникают по
ходу процесса
46
Опять доска?А используется ли доска в процессе?
47
Sprint Review MeetingМитинг для подведения итогов итерации
Команда вместе с Владельцем Продукта просматривают, что же было сделано за итерацию
ПО СУТИ – это митинг Владельца Продукта Рассчитывается продуктивность команды (velocity) Рассчитываются экономические показатели (при необходимости)
Делаются три вещи: Демонстрирует заказчикам продукт, который сделала команда, и показывает,
что все идет правильно Демонстрирует заказчикам нужды команды, чтобы понимать что они
собираются делать и делать это правильно Согласовываются детали и цели следующего Спринта
Добавляются новые истории в Backlog, если это необходимо
«Де-монстрация» – изгонение монстров из софта?
48
Определение продуктивности команды и экономических показателей
Магическое SPs & FP
Мы действительно хотим знать сколько может сделать наша команда (сколько SPs, сможет сделать за один спринт)
Мы не знаем этого … и мы считаем – сколько StoryPoints мы сделали за спринт
Сколько мы сделали за прошлый спринт Посчитать среднюю оценку Поверить в результат или иметь причины не верить
Итак, какова продуктивность команды?
49
Определение продуктивности команды и экономических показателей
Магическое SPs & FP
Мы действительно хотим знать сколько может сделать наша команда (сколько SPs, сможет сделать за один спринт)
Мы не знаем этого … и мы считаем – сколько StoryPoints мы сделали за спринт
Сколько мы сделали за прошлый спринт Посчитать среднюю оценку Поверить в результат или иметь причины не верить
Итак, какова продуктивность команды?
50
Ретроспектива Команда берет на себя проведения такого митинга
Что было хорошо и что не нужно менять Что может быть улучшено и как?
• ScrumMaster ведет такого рода митинг
Охватываемые проблемы: Постоянно команда решает какие-то сложности ScrumMaster вместе с Владельцем продукта выбирает время для
разрешения таких проблем Список задач команды ScrumMaster – «ScrumMaster’s Community»
ScrumMaster работает на преодоление любых проблем вне команды Сделать жизнь лучше со SCRUM Проработать с руководством по поводу поставки лимонада для улучшения
работы, экспериментом над продуктом
51
Что такое StoryPoints? Не бывает одинаковых по уровню разработки
историй Это относительная оценка каждой истории
степень двойки для оценки( 2, 4, 8...) ряд Фибоначчи (1, 2, 3, 5, 8...)
Самая легкая и самая тяжелая истории Возможно применение Planning Poker Не нужно оценивать весь список событий, а
только на несколько итераций
А почему не часах или днях?
52
Показатели исполнения
53
Показатели исполнения: Release Burndown Chart
54
Расчет производительности Посчитать количество завершенных SPs в каждом спринте
SP1, SP2, SP3…SPn
Среднее арифметический расчет Veln = (SP1+SP2+SP3+…+SPn)/n
Транзакционный расчет (несколько последних) Veln = (Veln-1+SPn)/2, or
Veln = (Veln-2+Veln-1+SPn)/3
55
Показатели исполнения
Оценка скорости разработки на основе имеющихся данных за несколько итераций. Для текущих данных – количество ошибок при оценке Средняя погрешность 19%; последние 3 – 17%; последние 2 – 13%
56
Agile Водопад
Разработчики Кросс функциональная команда,
Жесткое разделение на узкоспециализированных специалистов
Процесс Немедленная реакция на события (например тестировщик - разработчик)
Требуется прошествие большого количества времени для опеределение неисправностей
Качество Контроль с технической составляющей, возможность просматривать код и писать автоматические тесты
Тестирование происходит по принципу черного ящика, в основном заканчивается проверкой GUI
Заказчики Возможность взаимодействия в проекте и влиять на разработку
Клиенты никак не взаимодействуют в процессе разработки, а только заинтересованы в конечном продукте
Стиль управления Управляющие функции Контролирующие функции
Проект Сфокусирован на своевременность реагирования на потребности заказчиков
Сфокусирован на сроках сдачи проекта и принятых контрактах
57
Компании практикующие SCRUM/Agile в производстве Adobe Amazone Google Hewlett Packard Intel Microsoft Motorolla Oracle Yahoo БАРС Груп
58
Вопросы?