Recommended
Recommended
More Related Content
Viewers also liked
Similar to Вводный курс по SCRUM
Similar to Вводный курс по SCRUM (20)
Вводный курс по SCRUM
- 1. it-ip.ru | Интеллект-Партнёр | 2015 День первый
- 2. Каскадная модель it-ip.ru | Интеллект-Партнёр | 2015 Проектирование Разработка Анализ требований Тестирование Ввод в эксплуатацию Сопровождение Так запроектировали Мы заказывали маяк!!!! А лампа зачем?
- 3. it-ip.ru | Интеллект-Партнёр | 2015 Итерационная модель Проектирование Разработка Анализ требований Тестирование Проектирование Разработка Анализ требований Тестирование Проектирование Разработка Анализ требований Тестирование Развертывание Развертывание ЭксплуатацияА почему так долго??? Согласовывал и платформу Часто менялись требования Специалист был в отпуске С# or Java? Подбирали цвет
- 4. it-ip.ru | Интеллект-Партнёр | 2015 Code-and-fix
- 5. it-ip.ru | Интеллект-Партнёр | 2015
- 6. it-ip.ru | Интеллект-Партнёр | 2015 Роли Хватит за мной ходить!!! Идите все сюда!!! Team Product owner Scrum master Кто все эти люди? Самоорганизовывается; Самоуправляется. Несет ответственность; Мотивирует команду; Знает стратегию. Создает атмосферу; Проводит Stand-Up; Следит за SCRUM.
- 7. it-ip.ru | Интеллект-Партнёр | 2015 Цель – самоорганизация Это моя задача Это наш проект
- 8. it-ip.ru | Интеллект-Партнёр | 2015 TaskBoard
- 9. it-ip.ru | Интеллект-Партнёр | 2015 День второй
- 10. it-ip.ru | Интеллект-Партнёр | 2015 Product Backlog И так, хочу…
- 11. it-ip.ru | Интеллект-Партнёр | 2015 Priority Release Next releases Sprint
- 12. it-ip.ru | Интеллект-Партнёр | 2015 User story «Будучи пользователем <тип_пользователя> я хочу сделать <действие>, чтобы получить <результат>» Важность Трудозатраты
- 13. it-ip.ru | Интеллект-Партнёр | 2015 Story points
- 14. it-ip.ru | Интеллект-Партнёр | 2015 Story points
- 15. it-ip.ru | Интеллект-Партнёр | 2015 Sprint Planning Цель1: Определить цель спринта (Sprint Goal) и Sprint Backlog - функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта. Т.е. какие User Story будут реализованы. Цель2: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность.
- 16. It-ip.ru | Интеллект-Партнёр | 2015 День третий
- 17. it-ip.ru | Интеллект-Партнёр | 2015 Sprint 2-4 weeks
- 18. it-ip.ru | Интеллект-Партнёр | 2015 Stand-Up Что я сделал сегодня Что я планирую сделать завтра Какие были проблемы
- 19. it-ip.ru | Интеллект-Партнёр | 2015 BurnDown 2 points
- 20. Demo или sprint review Команда демонстрирует прирост функциональности продукта всем заинтересованным лицам Привлекается максимальное количество зрителей Нельзя демонстрировать незавершенную функциональность it-ip.ru | Интеллект-Партнёр | 2015
- 21. it-ip.ru | Интеллект-Партнёр | 2015 Ретроспектива Улучшение не продукта, а процесса: 1. Выполнили ли мы цель спринта? 2. Выполнены ли все задачи из Sprint Backlog? 3. Какие у нас были выявлены проблемы? 4. Что было хорошего? 5. Что было плохого? 6. Что можно улучшить? 7. Что изменилось с прошлой ретроспективы?
- 22. Спасибо за внимание! Вопросы? телефон +7(343) 266-29-00 cайт it-ip.ru it-ip.ru | Интеллект-Партнёр | 2015
Editor's Notes
- Каскадная модель жизненного цикла («модель водопада», англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Традиционно состоит из этапов (читаю с экрана) В настоящее время используется в некоторых Государственных структурах из-за формализма, тщательного документирования и возможности безболезненно поменять подрядчика. Click Но у этой модели есть существенный недостаток, если на любом из этапов произойдет отклонение от требуемого функционала, то это будет выявлено только на этапе сопровождения.
- При программировании, например, может обнаружиться, что реализация некоторой функции очень громоздка, неэффективна и вступает в противоречие с требуемой от системы производительностью. В этом случае требуется перепроектирование, а может быть, и переделка спецификаций. Потребность в перепроектировании возникает регулярно на любом этапе жизненного цикла как из-за допущенных на предыдущих шагах ошибок и неточностей, так и из-за изменений внешних требований к условиям эксплуатации системы. Процесс итеративной (или инкрементальной) разработки стал эволюционным развитием модели водопада. Процесс состоит из серии повторяющихся итераций, каждая из которых фактически является полноценным мини-проектом с фазами определения требований, анализа, дизайна и т.д. В результате очередной итерации продукт приобретает новую функциональность или улучшения в существующей функциональности. Итеративная модель используется во многих фреймворках разработки, включая OMU (Oracle Unified Method), RUP (Rational Unified Process) компании IBM и MSF (Microsoft Solutions Framework). Это тяжеловесные Enterprise-стандарты, которые включают десятки ролей, множество различных процессов, документов, спецификаций, моделей. Click именно в противовес этой модели были созданы гибкие модели разработки (Agile) или модели быстрой разработки (RAD - rapid application development).
- Click Однако необдуманная погоня за скоростью и гибкостью может создать серьезные проблемы. Используя Code-and-Fix, мы только пишем код. Здесь все очень просто: нет необходимости что-либо планировать, нет необходимости что-либо документировать. Как показал опыт, такой подход очень скоро приводит к коду, который невозможно поддерживать: исправление одной ошибки приводит к появлению нескольких новых; внесение минимальных изменений в одну из частей программы, приводит к разрушению функций, реализуемых другими частями.
- Scrum (Скрам) — это не аббревиатура, этот термин взят из регби, который обозначает схватку вокруг мяча. На диаграмме изображены основные артефакты SCRUM, а именно роли – Product Owner, Team, Scrum-master; Пулы функциональности – Product Backlog, Sprint Backlog; Коммуникации – Sprint Planning Meeting, Stand-Up, Sprint Review, ретроспектива. И главное, цикл Sprint.
- И так, прошу ответить – Кто эти люди? Click Это основные роли. Основные роли полностью включены в проект и в скрам-процесс. Click К ним относятся: Скрам-мастер (ScrumMaster) — проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Руководитель проекта скорее относится к владельцу проекта и не должен фигурировать в качестве скрам-мастера. Владелец проекта (Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон – это тот, кто видит цель продукта или кому кажется, что он видит цель продукта, но важно то, что он может ее сформулировать и начать процесс движения к ее достижению Скрам-команда (Scrum Team) — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет 7±2 человека. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Дополнительные роли: Пользователи (End-Users) Клиенты, Продавцы (Customers, Stakeholders) — лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту. Управляющие (Managers) — люди, которые управляют персоналом. Эксперты-консультанты (Consulting Experts) Иногда основные роли называют – свиньи, а дополнительные – куры.
- Без комментариев (30 сек) Click
- Традиционно на доске задач отображаются колонки – «В планах», «В процессе», «Готово», но также могут быть представлены и другие колонки, например, тестирование. Существует возможность использовать разный цвет карточек, например, когда мы использовали patterns microsoft, разными цветами показывали слои приложения – слой доступа к данным, слой представления, слой бизнес-логики, слой сквозной функциональности. Но использование цветов – дело вкуса команды, главное, чтобы все понимали значение цвета и стикеры были в наличии (какой-нибудь фиолетовый стикер). Click Далее карточки перемещаются слева-направо. Основная цель такого процесса – в любой момент времени, любое заинтересованное лицо должно понимать в каком состоянии находится проект, лишь взглянув на TaskBoard. Click Таким образом можно проводить анализ, основываясь на местах скопления карточек и диаграммы BurnDown – примеры, большое количество незапланированных задач, задачи выполняются без учета их приоритета, появились неразрешимые задачи, задачи решаются слишком быстро. Мы получили первое представление о доске задач, про то как попадают задачи на доску, чем отличаются карточки и что на них изображено, кто и когда перемещает карточки, а также что изображено на диаграмме справа – мы поговорим завтра.
- Product backlog – это основа Scrum’а. С него все начинается. По существу, product backlog является списком функциональных требований, которые упорядочены по степени важности. При этом все требования описаны на понятном для заказчика языке. Также описание каждого элемента списка включает в себя следующие поля: • ID – уникальный идентификатор. Применяется для идентификации в случае переименования. • Название – краткое описание, например, “Просмотр журнала своих транзакций”. Оно должно быть однозначным, чтобы разработчики и product owner могли примерно понять, о чем идет речь, и отличить одну историю от другой. • Важность (Importance) – степень важности данной задачи, по мнению product owner'а. Например, 10. Или 150. Чем больше значение, тем выше важность. Все элементы, которые, по мнению product owner’а имеют гипотетическую возможность попасть в следующий спринт, должны иметь уникальное значение важности. • Предварительная оценка (initial estimate) – начальная оценка объема работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story point’ах. • Как продемонстрировать (how to demo) – краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. По сути, это простой тестовый сценарий типа “Сделайте это, сделайте то – должно получиться то-то”. • Примечания – любая другая информация: пояснения, ссылки на дополнительные источники информации, и т.д. Обычно она представлена в форме кратких тезисов.
- Реальная производительность рассчитывается на основании начальной оценки каждой истории. Любые изменения оценки в течение спринта игнорируются. Я уже слышу ваши возражения: “Какая от этого польза? Высокий или низкий уровень производительности зависит от миллиона факторов! Недалёкие программисты, неправильная начальная оценка, изменение объёма работ, незапланированные потрясения в ходе спринта и т.д.” Согласен, производительность – это приблизительная величина. Но, тем не менее, очень полезная. Она лучше, чем ничего. Производительность даёт нам следующее: “Независимо от причин, мы имеем разницу между запланированным и выполненным объемом работ”. А что, если история была почти закончена? Почему мы не используем дробные значения для таких историй при подсчете реальной производительности? Потому, что Scrum (как и гибкая разработка (agile), да и бережливое производство (lean)) ориентирован на то, чтобы создавать законченный, готовый к поставке продукт! Ценность реализованной наполовину истории нулевая (а то и отрицательная). См. книгу “Managing the Design Factory” автора Donald Reinertsen или одну из книг авторов Mary Poppendieck и Tom Poppendieck. Так каким же магическим способом мы оцениваем производительность? Проще всего оценить производительность, проанализировав предыдущие результаты команды. Какая производительность была в течение нескольких последних спринтов? Приблизительно такой же она будет и в следующем спринте.
- Истории должны быть не слишком маленькими, но и не слишком большими (в смысле оценок). Если вы получили кучу историй в половину story point’а, то вы наверняка падёте жертвой микроменеджмента. С другой стороны, история в 40 story point’ов несёт в себе риск того, что к концу спринта её успеют закончить лишь частично, а незавершённая история не представляет ценности для вашей компании, она только увеличивает накладные расходы. Дальше – больше: если ваша прогнозируемая производительность 70 story point’ов, а две наиболее важные истории оценены в 40, то планирование несколько усложнится. Команда станет перед выбором: или расслабиться (т.е. включить в спринт только одну историю), или взять на себя невыполнимые обязательства (т.е. включить обе). Я считаю, что практически всегда есть возможность разбить историю на более мелкие. Однако, в этом случае нужно следить за тем, чтобы меньшие истории всё ещё представляли ценность с точки зрения бизнеса.
- Планирование спринта – наиболее важная часть Scrum’a. Плохо проведённое планирование может испортить весь спринт. Цель планирования заключается в том, чтобы, с одной стороны, дать команде достаточно информации для спокойной работы в течение нескольких недель, а с другой – убедить product owner’а в том, что команда сможет сделать свою работу. Хорошо-хорошо, это было весьма расплывчатое определение. Давайте лучше поговорим о том, что должно быть итогом планирования: • Цель спринта. • Список участников команды (и степень их занятости, если она не стопроцентная). • Sprint backlog (список историй, которые вошли в спринт). • Дата демонстрации. • Место и время проведения ежедневного Scrum’а Определение даты демо. А это значит, что вам придётся определиться с длиной спринта. Какая же длина оптимальна? Короткие спринты – удобны. Они позволяют компании быть максимально “гибкой”, а значит готовой часто корректировать свои планы. Короткий спринт = короткий цикл обратной связи = частые релизы = быстрые отзывы от клиентов = меньше времени тратится на работу в неправильном направлении = быстрое обучение, совершенствование и т.д. Но с другой стороны длинные спринты тоже хороши. У команды остаётся больше времени, чтобы набрать темп, больше пространства для манёвров, чтобы решить возникшие проблемы, а также больше времени для достижения цели спринта, а у вас меньше накладных расходов, таких как планирование спринта, демо и т.д. В основном короткие спринты больше нравятся product owner’у, а длинные – разработчикам. Поэтому длина спринта – это всегда компромисс. Но общепризнанной длинной спринта является от двух до четырех недель.
- Цикл выпуска продукта в Scrum состоит из ряда итераций, которые называются спринтами. Спринт имеет фиксированную длительность и обычно составляет от 2 до 4 недель. Во время спринта происходят ежедневные скрам-митинги и вся команда добивается выполнения цели спринта. В реальной жизни невозможно постоянно бежать как спринтер. Между забегами вам в любом случае нужен отдых. Если вы бежите с постоянной максимальной скоростью, то, по сути, вы просто бежите трусцой. То же самое наблюдается в Scrum'е, да и в разработке программного обеспечения в целом. Спринты очень изматывают. Как у разработчика, у вас никогда нет времени, чтобы расслабиться, каждый день вы должны стоять на этом проклятом Scrum-митинге и рассказывать всем, чего вы добились вчера.
- Это собрание, которое в среднем длится 10-20 минут, на котором существует правило: не члены команды не говорят и не задают вопросов. Это собрание позволяет каждому участнику команды быть вовлеченным в процесс. Лучшие ежедневные Скрам-митинги происходят когда: Начинается всегда в одно и тоже время; Команда стоит напротив своей физической доски задач полукругом, другие заинтересованные лица за полукругом; Участники передают друг другу “говорящий маркер” – тот, кто держит маркер говорит. Остальные слушают и задают уточняющие вопросы; Скрам-мастер стоит в стороне в полоборота к команде и записывает на доске основные проблемы и горячие темы. Он это делает для команды. Иногда он прерывает говорящего словами: “Похоже, это горячая тема. Для кого это еще важно? Вы хотели бы ее обсудить отдельно после митинга? ОК. Записал. Идем дальше?” Время от времени Скрам-мастер вставляет короткие вопросы, направляющие команду ко взаимодействию:- Понятна ли всем суть проблемы?- Для кого это еще является проблемой?- Кто мог бы помочь?- Чем я мог бы помочь?- Что еще важного нам стоит сегодня обсудить, пока мы все вместе? После встречи Скрам-мастер может предложить команде пройтись по каждой задаче в To Do и убедиться, что они в работе. Или провести мини-ретроспективу самого Скрам-митинга, повысив его пользу для всей команды.
- Диаграмма сгорания задач — диаграмма, показывающая количество сделанной и оставшейся работы. Является основным инструментом Scrum для отслеживания прогресса итерации. Суть Burndown графика легко объяснить: Ось X показывает дни в Спринте (итерации) Ось Y показывает количество оставшейся работы (в чем бы вы ее не измеряли: Пункты (Story Points), идеальные часы, идеальные дни или даже просто количество задач). Идеальная линия показывает ожидаемый прогресс Реальная линия показывает реальный прогресс и количество оставшейся работ Несмотря на свою простоту – BurnDown диаграмма является мощным инструментом аналитики скрам-процесса. Что мы видим на этой диаграмме? Click Правильно, осталось три дня, а мы отстаем на 2 StoryPoints. Если копнуть глубже – в прошлую пятницу работа остановилась – мы не учли в спринте корпоратив? Или может столкнулись с неразрешимой проблемой? Или незапланированные задачи, которые не отображаются на диаграмме, останавливают весь процесс? Кстати, чтобы были видны незапланированные задачи можно использовать диаграмму BurnUp
- Демонстрация спринта – очень важная часть Scrum'а, которую многие все же недооценивают. "Ой, а нам что, обязательно делать демо? Мы все равно ничего интересного не покажем!" "У меня куча работы, не хватало еще смотреть чужие демо!" Хорошо выполненное демо оказывает огромное воздействие, даже если оно не показалось захватывающим. • Положительная оценка работы воодушевляет команду. • Все остальные узнают, чем занимается ваша команда. • На демо заинтересованные стороны обмениваются жизненно важными отзывами. • Демо проходит в дружеской атмосфере, поэтому разные команды могут свободно общаться между собой и обсуждать насущные вопросы. Это ценный опыт. • Проведение демо заставляет команду действительно доделывать задачи и выпускать их (даже если это всего лишь на тестовый сервер). Без демо мы постоянно оказывались с кучей на 99% сделанной работы. Проводя демо, мы можем получить меньше сделанных задач, но они будут действительно закончены, что (в нашем случае) намного лучше, чем куча функционала, который "типа" сделан и будет болтаться под ногами в следующем спринте. Если команду заставлять проводить демо, когда у них ничего толком не работает, им будет не по себе. Команда будет запинаться и спотыкаться, показывая функциональность. Это очень неприятно. В следующем спринте команда действительно постарается все доделать! Они будут думать "ладно, может, в следующем спринте стоит показать всего две вещи вместо пяти, но, черт возьми, в этот раз они будут РАБОТАТЬ!". Команда знает, что демо придется проводить несмотря ни на что, и благодаря этому шансы увидеть там что-то пристойное значительно возрастают.
- Наиболее важная вещь в отношении ретроспектив – это их проведение. По некоторым причинам команды не проявляют должного интереса к проведению ретроспектив. Без небольшого давления со стороны многие команды часто пропускают ретроспективу и сразу переходят к следующему спринту. Хотя при этом все вроде соглашаются, что ретроспективы крайне полезны. Я бы даже сказал, что ретроспектива является вторым по значимости мероприятием в Scrum'e (первое – это планирование спринта), потому что это самый подходящий момент для начала улучшений! Конечно, чтобы возникла хорошая идея, вам не нужна ретроспектива, она может прийти к вам в голову, когда вы дома в душевой кабинке! Но поддержит ли команда вашу идею? Может быть, но вероятность значительно выше, если идея рождается внутри команды, то есть, во время ретроспективы, когда каждый может сделать свой вклад в обсуждение идеи. Без ретроспектив вы обнаружите, что команда наступает на одни и те же грабли снова и снова.