Startup Class - Введение и использование SCRUM для командной...

SCRUMPlaycer

среда, 11 апреля 2012 г.

ПОЧЕМУ• Нерегулярные и непонятные релизы, нет дат

•Много багов в не сложных по сути вещах

•Отсутствие «прозрачных» планов при большом количестве «формальностей»

• Усталость команды

• Не видно результатов работы

• Полученное не соответствует ожидаемому


ЧЕГО Я ХОЧУ

• Регулярные качественные релизы

• Гибкость в добавлении новых «фич»

•Меньше формальностей - лучше работа

• Команда, а не сотрудники

• Видеть прогресс каждый день

• Получать то, что было задумано


SCRUMспасибо Оле


• Хорошая реализация Scrum'а важна для команд, которые хотят получить инвестиции

• Будущие инвестиции требуют знания собственной производительности

• Если команда не знает собственной производительности, product owner не может разработать стратегический план развития продукта с достоверными датами релизов

• Предоставлять версии работающего программного обеспечения как можно чаще и раньше


http://www.infoq.com/minibooks/scrum-xp-from-the-trenches




ОСНОВНЫЕ ПОНЯТИЯ

• Scrum master• Product owner• Sprint• Product backlog• User story• Story points• Burndown diagram


PRODUCT BACKLOG

• Product backlog – функциональностей (user story), которые упорядочены по степени важности (Importance). При этом все требования описаны на понятном для заказчика (product owner, user) языке.


• id = (release version)+(who)+(number in sprint)=041V2• Title - однозначно, понятно всем, легко различать, от 2 до

10 слов.• Importance != приоритет• Initial estimate - начальная оценка работ (в story

points) - человеко-дни?• Demo - “Сделайте это, сделайте то – должно получиться то-то”/тест кейсы

• Категория (по назначению или модулю) - refactoring, optimization, admin, market, core, place, builder, etc.

• Компоненты - (подсистема или модуль) которые также будут затронуты при реализации (core, database, init script, notification, security, mobile, api, html-side / market, reward, builder, place и другие модули)


СПИСОК ЗАПРЕЩЕННЫХ СЛОВ ДЛЯ НАЗВАНИЯ

•

•

•

•

•


Важность Тип Описание и действия

100 Criticalисправить сразу после обсуждения, сделать билд

>90 Urgentсделать в течении 1 дня, сделать билд сразу

>70 Importantвысокий приоритет, делать в первую очередь

>50 Common обычная фича

>20 CommonОбычная фича, с более низким приоритетом

>1 Not importantНе очень важное (делать в последнюю очередь)


ПЛАНИРОВАНИЕ СПРИНТА

• Составить расписание.

• Заинтересованные лица могут добавлять user story в product backlog, они не имеют права присваивать им уровень важности и объем работ. Это прерогатива product owner’а.

• Трудозатраты это прерогатива команды. Именно команда решает, сколько историй войдёт в спринт. Ни product owner, ни кто-нибудь ещё.


• 11:00 -11:30. Введение. Product owner разъясняет цель спринта и рассказывает про бизнес-процессы из product backlog’а. Обсуждается время и место проведения демо.

• 11:30 -12:00. Обсуждение историй. Каждый по отдельности сначала, а потом команда разработчиков проводит оценку времени по каждому user story, в том числе разбивая его на задачи.

• 12:00 - 13:00. Выбор историй. Сообщают PO трудозатраты. В некоторых случаях product owner может изменить приоритет их исполнения. Выясняем все интересующие нас вопросы. Для наиболее важных заполняем поле «Как продемонстрировать». Команда определяет набор user story, которые войдут в следующий спринт. Чтобы проверить насколько это реально, вычисляем производительность команды.

• 13:00 - 14:00. Детальное планирование. Договариваемся о времени и месте проведения ежедневного Scrum’а (если они изменились по сравнению с прошлым спринтом). После чего приступаем к разбиению user story на задачи и внесению их в PM-систему.

ПЛАНИРОВАНИЕ СПРИНТАПятница/Суббота/Понедельник?


ВЫБОР ИСТОРИЙ


ПРОИЗВОДИТЕЛЬНОСТЬ


УЧЕТНЫЕ КАРТОЧКИ


PLANNING POKER


ИСТОРИИ И ЗАДАЧИ


ИТОГ ПЛАНИРОВАНИЯ

• Цель спринта

• Бэклог спринта

• Дата и место демонстрации

• Список еженедельных митингов, место и время


SPRINT BACKLOG


BURNDOWN


ОБУСТРОЙСТВО КОМНАТЫ


LIFE CYCLE


А ТАКЖЕ

• ежедневные scrum митинги• выбор названия команды• Инженерные дни• Демо• Парное программирование• TDD (test-driven development)• стандарты кодирования Sun: http://java.sun.com/docs/

codeconv/html/CodeConvTOC.doc.html


http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html




NOKIA SCRUM MANIFEST

• У Scrum-команды должен быть один product owner и команда должна знать, кто это

• У product owner'а должен быть один product backlog с историями и их оценками, выполненными командой

• У команды должна быть burndown-диаграмма, а сама команда должна знать свою производительность.

• На протяжении спринта никто не должен вмешиваться в работу команды


АКСИОМЫ• Аксиома 1: Команда должна предоставить пользователю вполне осязаемый кусок работы на демонстрации в конце каждого спринта

• Аксиома 2: Scrum – это не методология, это фреймворк. В каждом отдельном случае необходимо адаптировать.

• Аксиома 3: У системы с высоким внутренним качеством иногда может быть довольно низкое внешнее качество. Но наоборот бывает крайне редко. Внутреннее качество не может быть предметом дискуссий.

• Аксиома 4: В Scrum’е всё ограничено по времени.

• Аксиома 5: Ценность реализованной наполовину истории нулевая (а то и отрицательная).


Startup Class - Введение и использование SCRUM для командной...

Business

Transcript of Startup Class - Введение и использование SCRUM для командной...