ScrumWorks™ Basic Edition это инструмент для автоматизации процесса разработки с исспользованием гибкой методолгоии, который позволяет команде самоорганизовываться и увеличивать продуктивность. В основе ScrumWorks™ Basic лежит процесс Scrum, ведущий фреймворк для гибкого (agile) процессa разработки, который может быть применен в маркетинге и продажах, разработке ПО и новых продуктов.

Приложение включает в себя:

- Бэклог продукта и управление релизами
- Категоризацию Бэклог артифактов
- Управление задачами в текущем Спринте
- Трекингом проблем
- Импорт-зкспорт в майкрософт эксель
и многое другое.

Скрум собрание: Детали

Скрум собрания это пульс Скрума и проекта. Каждый рабочий день, в одном и том же месте и время, проводиться собрание с членами команды по кругу, на котором одни и теже специальные Скрум вопросы, на которые отвечает каждый из команды:

1. Что ты сделал со времени последнего Скрума?
2. Что ты будешь делать начиная с текущего момента до следующего Скрума?
3. Что происходит на пути к достижению целей итерации?
4. Есть ли задания для добавления в спринт резерв? (пропущеные задания, не новые требования)
5. Изучил или решил что нибудь новое, важное для кого нибудь из команды? (технические детали, требования, …)

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

Другие важные моменты:

• Собрание идеально проводить стоя в кругу, чтобы показать его краткость.
• В среднем, 15 или 20 минут для 7-10 человек. Более длинные собрания бывают в начале итерации.
• Не члены команды (цыплята) стоят за кругом.
• Он происходит около доски на которой написанны и докладываются все проблемные блоки. Скрум Мастер только стирает блок как только он разрешился.
• Должен быть спикерфон для участия офсайт людей—это обязательно.
• Скрум Матстер следит чтобы все шло по правилам, и готовит место для эффективного собрания.
• Должен начинатся во время. 
• Применяется правило Цыплят и Свиней: Не члены команды не говорят и не задают вопросов.
• Не допускается других дисскусий между 3 (или5) вопросом. Скрум Мастер обладает власью сменить фокус дисскусии.
• Если другие проблемы требуют обсуждения, происходит второе собрание сразу после Скрум собрания, обычно с частью команды. Например во время собрания я могу сказать Джо во время его отчета, “Мы должны поговорить об этом, давай встретимся после Скрума.”

Ценность Скрум собрания

1: Так как мы имеем, на время итерации, самоорганизующуюся команду, без менеджера, направляющего работников или решающего проблемы (пока не попросят), Скрум митинг создает ежедневный механизм, для быстрого информирования команды о состоянии проекта и людей. Затем люди могут действовать. Внешние люди могут присутсвовать на ежедневном Скруме для получения точного, временного и богатого информацией измерения прогресса и проблем. Это поддерживает активность.
2: Когда человек говорит, что он делает на следующий день, он дает в в некотором виде обещание команде. Это увеличивает ответсвенность и доведение дел до конца.
3: Скрум основывается на понимании, что разработка ПО это креативный и непредсказуемый процесс, и необходимы скорее эмпирические чем предопределенные методы. Скрум собрание обеспечивает часто измеримый и адаптивный механизм отклика, что и требуют методики основанные на опыте.
4: Риски проекта включают в себя учет не всех заданий, плохие прогнозы, и медленное разрешение проблем. Скрум митинг обеспечивает ежедневный обсуждение обновлений заданий, определение и удаление помех.
5: Постоянное улучшение и изучение людей и команд очень важно. Скрум митинг помогает в этом, особенное добавление 5-го вопроса. Невысказанная (или подразумеваемая) информация и знания становятся высказанной и общей.
6: Общий язык, ценности и практики помогают команде разработчиков. Это создается и укрепляется ежедневным скрумом.

Скрум также допускает комбинацию с другимим методологиями, например с унифицированными процессами (UP). Он допускает создание видения проетка (vision) или списка рисков.

Другие практики и ценности

• работники ежедневно обновляют спринт резерв—С тех пор как задание в разработке, разработчик ответсвенен за ежедневные обновления и оценку оставшегося времени для своих заданий
• Перт диаграммы не допуситимы—Перт диаграммы строятся с предположением что все задания в проекте выявлены, расставлены по порядку, и достоверно оценены, что будут минимальные изменения и шум в системе, и главное что определенный процесс будет применятся. Это коренным образом не совместимо с пониманием всех итеративных и гибких методологий, что ПО это полу-хаотичная разработка нового продукта с большой степенью изменений и помех, и строго определенные процессы не могут быть применены.

Общие ошибки и недопонимания или как завалить Скрум проект

Не самонаправляемые команды; менеджер или Скрум Мастер направляет или организовывает команду— У менеджеров часто возникает желание приставать к команде, во время итерации, с советами как работать, как решать проблемы. Многие менеджеры делают упор на задании направления и планировании, чем на их роли в Скрум: быстро решать проблемы, обеспечивать ресурсами, буть фильтром между командой и компанией, но однако не стоять на пути. Это особенно справедливо для Скрум Мастера во время скрум митинга, когда естественная тенденция, чтобы выглядить лидером для команды определяющим направления и решения.
Не ежедневное обновление Спринт резерва разработчиками.
Новая работа добавляется к итерации или индивидуму—В море постоянных изменений требуется некоторая стабильность. Не изменять требования для однажды начатой итерации, это точка контроля Скрума.
Владелец продукта не вовлечен или не принимает решений—Скрум это мотодология управляемая заказчиком. Владелец продукта должен решить как приотизоровать бэклог продукта, и выбрать требования для следующей итерации.
Нет Спринт оценки (review)—Скрум строится на обратной связи и адаптации; демонстрация и оценка(review) необходима, чтобы проинформировать заказчика, чтобы он мог откоректировать следующую итерацию.
Много хозяев—Скрум требует один голос для требований из резерва свойств продукта, расставление приоритетов и выбор работ для следующей итерации обязанности владелца продукта.
Проектирование и создание диаграмм— Скрум более прогматичный в вопрсое командного подхода к проектированию: Если команда находит полезным некоторое пред-программное проектирование или создание диаграмм, во время итерации, они это делают
Вся команда (включая заказчиков и менеджмент) обрезают Скрум методологию и ее ценноости – что недопустимо.
Скрум собрание слишком длинное или не сфокусированно – Держите его в рамках 20 минут, и в рамках Скрум вопросов.
Каждая итерация заканчивается выпуском продукта в жизнь (production)—Хотя Скрум итерация может заканчиватся выпуском в жизнь (production release), это не требование. Это может потребовать несколько итераций перед выпуском ПО готового для исспользования пользователями.
Будущее планирование; планирование Перт диаграммами—Это неправильное понимание, создавать планы описывающие в точности, как много будет итераций для длинного проекта, и что будет происходить в каждой, или создавать Перт диаграммы показывающими много заданий, их порядок и предпологаемую длительность.

Вы не понимаете Скрум если…

• Вы думаете что менеджер или Скрум Мастер должен говорить команде что делать, или как решать их проблемы.
• Заказчик не вовлечен в каждую итерацию, не расставляет приоритеты для требований, не уделяет внимание каждой демонстрации, и не выбираете наиболее значимые бизнес функциональность для следующей итерации.
• Новые требования или дополнительные задания добавляются членам команды во время итерации.
• Вы создаете план описывающий как много итераций будет в проекте, и что будет происходить в каждой итерации.
• Вы создаете Перт график или план зависимости, выстраиваете порядок заданий, с предварительными оценками продолжительности.

“Agile and Iterative Development: A Manager’s Guide” – Craig Larman

Ссылки по теме:
http://en.wikipedia.org/wiki/SCRUM – Скрум в википедия.
http://scrumwiki.org/ – вики для Скрума
http://www.scrumalliance.org/ – Скрум альянс
http://www.controlchaos.com/ – сайт одного из создателей скрума Кена Швабера
http://groups.yahoo.com/group/scrumdevelopment/message/2116 – Tools, Tools, Scrum Tools!

Глоссарий

Предопределенный процесс (Defined process)
Предопределенный процесс ведущий к получению предсказуемого результата.

Эмпирический процесс (Empirical process)
Частая проверка и адаптация деятельности, чтобы удовлетворить желаемым результатам.

Итеративная разработка (Iterative development)
Разработка ПО которая представляет собой короткие и повторяемые циклы, с обратной связью от заказчика после каждой итерации.

Скрум Мастер (Scrum Master)
Менеджер проекта

Свинья (Pig)
Явный член проекта.

Цыпленок (Chicken)
Внешний наблюдатель Скрум проекта.

Спринт (Sprint)
30 дневная итерация с заранее определенным набором функциональности.
Результат Спринта это рабочее и демонстрируемое ПО.

Резерв свойств продукта (Product Backlog)
Репозитарий функционала ПО

Резерв свойств Спринта (Sprint backlog)
Функционал и требования в границах Спринта

Активность Зонта (Umbrella activity)
Администратиывные задания, которые не относятся на прямую к текущему программному продукту.

История

Корни Скрума произростают из статьи суммирующей общие лучшие практики в 10 инновационных японских компаниях, “The New New Product Development Game,” Harvard Business Review, январь 1986, написанной Такеши (Takeuchi) и Нонака (Nonaka). Они ввели термин Sashimi (slices) для IID (итеративной инкрементной разработки), и Скрум (Scrum) для адаптивных и само направляемых командных практик.

Название было взято из игры регби, из-за командного поведения передвигающего по полю мяч. Джеф Сазерленд (Jeff Sutherland) один из создателей Скрума и бывший вице-президентом в Easel Corp., в 1994-ом он представил свои методы, под влиянием отчета о гипер-продуктивных проектах в Borland Corp, которые эффективно использовали структурированные ежедневные митинги В 1996 Сазерленд перешел в Individual Inc., и попросил Кена Швабера (Ken Schwaber) помочь в адаптации идей Скрума. Швабер и Сазерленд отшлифовали и расширили Скрум.

Scrum – с англ. драка за мяч (в регби)

Введение

Скрум строго рекомендует творческую адаптацию техник, чтобы соответсвовать местным требованиям, и избегать следования преопределенным и формальным процессам, без ясной мотивации для проекта.

Ключевая тема Скрума – это сделать акцент на эмпирическом, а не на преопределенном процессе; т.е. на адаптивном подходе управляемым частой обратной связью, чем следавать набору предсказуемых и определенных задач, чья длительность и порядок может быть определен только на частично.

Основные характиристики:

• самонаправляющаяся и самоорганизующаяся команда
• дополнительная работа не добавляется во время выбранной итерации
• ежедневные стоячие митинги со специальными вопросами
• строго 30 дневные итерации
• демонтрации приложения заказчикам в конце каждой итерации
• каждую итерацию, заказчик заново расставляет приоритеты требованиям и выбирает цели для следующей итерации

Роли

Заказчик

Владелец продукта (Product Owner)

• один человек кто отвечает за создание и расстановку приоритетов в “Резерве свойств продукта”
• выбирает цели (из “Резерве свойств продукта”) для следующего Спринта
• совместно с другими заинтересованными лицами проверяет систему в конце каждого Спринта

Разработка

Скрум Команда (Scrum Team)

• работает над “Резервом свойств Спринта”
• нет других явных позиций кроме “член команды “

Управление

Скрум Мастер (Scrum Master)

• следит чтобы Скрум ценности и практики применялись
• буфер между менеджментом и Скрум командой
• следит за прогрессом и удаляет помехи
• руководит ежедневным Скрумом
• решает неразрешенные вопросы во время ежедневного Скрума
• проводит рецензию Спринта

Обязательства – Скрум комананда придерживается определенных целей в каждой итерации, она имеет власть и автономию, чтобы для себя решить, как этих целей лучше достичь. Руководство и Скрум Мастер обязуются не добавлять новой работы во время итерции, избегают направлять команду, и работают чтобы предоставить ресурсы и быстро удалять сделанные блоки из “резерва свойств Спринта” о которых сообщает команда во время ежедневного Скрум собрания. Владелец продукта определяет и расставляет приоритеты “резерва свойств продукта”, руководствуясь целями выбранными для следующей итерации, проверяет и предоставляет отзывы по результатам каждой итерации.

Фокус—Скрум команда должна иметь возможнотсь сфокусироваться на установленных целях, без отвлечения внимания. Поэтому, руководство и скрум мастер фокусируются на предостовлении команде ресурсов, удалении блоков, и избегают прерывать команду дополнительными запросами о работе.

Открытость—Открыто доступный “резерв свойств продукта” делает видимым объем работ и приоритеты. Ежедневные Скрумы делают видимым общий и индивидуальный вклад и состояние дел. Рабочий курс (Work trend) и скорость становиться видимым при помощи графика резерва свойств.

Уважение—Командная ответсвенность предпочтительее козлов отпущения. Отдельные члены команды отвечают за различные сильные и слабые стороны, но нет отвественного за провал итерации. Целая команда, а не менеджер, бросает свои силы, для решения “индивидуальных” проблем в группе, а также команда обладает властью и ресурсами реагировать на трудности, например нанимать консультанта-специалиста чтобы компенсировать отсутсвие экспертов.

Смелость—Руководство должно иметь смелость планировать и руководить, адаптируясь и доверяя индивидуалам и команде избегая говорить им что делать, чтобы итерация была сделана. Команда должна имеет смелость взять на себя ответсвенность, для самонаправления и самоуправления.

Основные практики

Спринт (Sprint)

Работа организовывается итерациями по 30 календарных дней, каждая из которых называется Спринт.

Самонаправляющиеся и самоорганизующиеся команды

Во время итерации, руководство и Скрум Мастер не направляют команду как выполнить цели итерации, не решают их проблем (кроме как принять решение когда запросить и удалить выполненный блок), не планируют и сортируют работу. Команда наделена правами, властью и ресурсами в поисках своего пути, и решении собственных проблем. Подход “руки прочь” на 30 дней, за исключением обеспечения ресурсами и удаления блоков, это возможно наиболее трудный аспект для руководителей адоптирующих Скрум.

Скрум собрание (Scrum Meeting)

Каждый рабочий день в одно и то же время на одном и том-же месте, собирается собрание членов команды, на котором даются ответы на специальные Скрум вопросы каждым членом команды.

Не добовлять к итерации (Don’t Add to Iteration)

Во время итерации , руководство не добавляет работу команде и индивидуальным разработчикам. Поддерживается непрерывный фокус. Но, перед каждой новой итерацией владедец продукта и руководство имеет право и обязанность перерасставитть приоритеты “резерва свойств продукта”, и обозначить, что делать в следующей итерации, до тех пор пока количество работ не превысит существующие ресурсы.

Скрум мастер экран (Scrum Master Firewall)

Скрум Мастер наблюдает, чтобы команду не прерывали рабочими запросами, другие внешние стороны, и если это произошло, удаляет эти запросы и разбирается со всеми политическими и внешними управленческими проблемами. Скрум Мастер также должен контролировать, что применятся методика Скрум, удалять сделанные блоки, обеспечивать ресурсами, и принимать решения когда они потребуется.

Решение за час

Блоки определенные на скрум митинге которые требуют решения Скрум Мастера идеально его сразу же и получают, или в течении 1 часа. Пропогандируеся ценность “плохое решение лучше чем никакое, и также обратное”.

Блок уходит за 1 день

Блоки определенные к разработке на Скрум собрании идеально удаляются на следующем митинге.

Цыплята и свиньи

Во время Скрум собрания, только Срум Команда может говорить (свиньи). Все остальные кто присутствует на митинге, должны молчать (цыплята), даже CEO.

Пред игровое планирование

Во время пред игрового планирования, все заинтересованные лица могут вносить свои предложения в создание списка возможной функциональности, use cases, улучшения, дефекты, и т.п., записываемые в резерв продукта. Назначается один владелец продукта, и запросы проходят через него. Во время этой сессии, как минимум, работа достаточная для первой итерации должна быть сгенерирована, и возможно на много больше. Владелец продукта начиная с этого собрания, и далее постоянно, должен быть вовлечен в идентификацию резерва продукта для выпуска, подмножества резерва, продукта который войдет в следующий выпуск продукта.

Планирование Спринта

Перед началом каждой итерации—или Спринта—проводится два последовательных митинга. На первом, заинтересованные стороны встречаются чтобы детализировать и расставить приоритеты резерву свойств продукта и резерву свойств текушего выпуска, выбрать цели для следующей итерации, обычно руководствуясь важнейшими бизнес задачами и рисками. На втором митинге, Скрум команда и владелец продукта встречаются чтобы обсудить как достичь поставленых целей и создать резерв заданий Спринта (в 4-16 часовом разбиении). Если оцененный усилия превышают ресурсы, происходит другой цикл планирования. Резерв Спринта коректируется, часто ежедневно на ранней стадии итерации, как только обнаруживаются новые задания и когда итерация заканчивается. С ростом истории по многим спринт резервам, команда улучшает качество создания своих новых спринтов.

Команда Семерых

Скрум можно масштабировать до больших проектов, но рекомендуют в одной команде иметь максимум до 7 человек. Большие проекты это несколько команд.

Общая комната

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

Ежедневные билды

Как минимум ежедневная интеграция и регрессионное тестирование всего нового кода для проекта. XP практика непрерывной интеграции (Continuous Integration) еще лучше.

Проверка Спринта (Sprint Review)

В конце каждой итерации, проводится собрание для проверки (максимум 4 часа) проводимое Скрум Мастером. Команда, Владелец Продукта, и другие заинтересованные лица присутсвуют на собрании. Показывается демо продукта. Цели собрания включают информирование о фунциях системы, дизайне, сильных и слабых сторонах, достижений команды и обнаруженных будущих проблемных местах. Собираются отзывы и проводится мозговой штурм будущих направлений, но не дается ни каких обязательств во время митинга. Позже на следующем собрании планировании Спринта, команда и заказчики принимают на себя обязательства. “PowerPoint” презентации запрещены. При подготовке делается акцент на показе продукта.

Продолжение следует: Scrum (часть 2)