Slid 3.0 Scrum для практиков на Vsts2008

Давайте знакомиться

http://www.seadmex.ru/customers/epam

SEADMEX

Денис Петелин

Успел попробовать себя во всех ролях софтверных проектов – от разработчика до владельца компании и Заказчика.

Поскольку во всех ролях работал успешно, то имею востребованный опыт, который передаю другим.

В последнее время все больше выступаю в роли Заказчика, где применяю изученные у Заказчиков грязные трюки

Попутно являюсь Product Owner для одного стартапа, Scrum Master для еще одной команды, Agile Coach для двух проектов.

Denis_petelin@epam.com

Окей, мы все через это прошли

29.10.2007 V 2.021 4

История создания тренинга

16.01.2008 V 2.021 5

Vision \ Scope

• Вы уже повозились с Team System и теперь по какой-то причине вам интересно, как мыделаем agile (scrum) в Team System 2008:

1. Я – менеджер, и могу говорить только за agile и Team System для менеджеров

2. Я собираюсь его обзорно показать вам в разрезе «процесс»

3. Я собираюсь вам его обзорно показать в разрезе «инструмент»

16.01.2008 V 2.021 6

Vision \ Scope

• У меня на это дело есть один день:

1. Я собираюсь его обзорно показать вам в разрезе «процесс»

a) Это не тренинг по agile-методологиям

b) Я не собираюсь вас убеждать что agile работает

2. Я собираюсь вам его обзорно показать в разрезе «инструмент»

a) Я (почти) не буду показывать администрирование

b) Мы не будем конфигурировать сервер \ упражняться

16.01.2008 V 2.021 7

Disclaimer

• Мы не делаем ничего сверхъестественного

• Я – не супер-мега-гуру Team System 2008

• Да, есть много способов делать все лучше в Team System 2008

• Да, есть много других инструментов кроме Team System 2008

• Да, вы могли бы сделать все в 10 раз лучше

16.01.2008 V 2.021 8

Limitations of liability

1. Показанное не значит, что наш путь единственно верный

2. Это не значит даже, что он подойдет вам

3. Используя эти соображения и подходы – вы делаете это на свой страх и риск, ни я ни кто-либо другой не несем за это ответственности

4. Пытаясь их тупо скопировать без понимания зачем оно вам надо – вы гарантированно огребете проблем

16.01.2008 V 2.021 9

Release Planning

• Release 1 – базовое понимание как сделать agile средствами Team System

– Sprint 1 – Объясню почему agile работает

– Sprint 2 – Объясню Customer Involvement

– Sprint 3 – Объясню TDD + ATDD

– Sprint 4 – Объясню CI + AD

16.01.2008 V 2.021 10

Рабочие соглашения

Сотовые –выключить

Почту – не читать

Коллег –не гнобить

Говорить –строго по одному

29.10.2007 V 2.021 11

Орг. Вопросы

• Формат работы: 1,5 часа Х 4 спринта

• Перерыв: 20 минут

• Обед: после 2х спринтов, 1 час

• Вопросы – задавать любые, даже не по теме тренинга

• Вопросы не по теме – на перерывах

• Материалы – будут выложены на Office Live

16.01.2008 V 2.021 12

Вопрос (1 минута подумать)

• Зачем я сюда пришел (пришла)?– Пример: Завтра мне начинать проект на Team

System. С чего начать?

• Что я хочу узнать?– Пример: Хочу чтоб в голове сложилось

последовательность действий менеджера, устанавливающего Agile на проекте.

• Опыт использования софта для управления?– Пример: FogBugz – 5 лет, OnTime – 3 года, TFS – 20

лет

29.10.2007 V 2.021 13

Почему Agile?Лекция 1

Начнем – с начала

Алиса: «Не подскажете, каким путем мне идти, чтобы отсюда выбраться?»

Кот: «Ну, это в значительной степени определяется тем, куда вы хотите попасть.»

Алиса: «Мне, в общем-то, все равно...»

Кот: «Тогда не имеет никакого значения, каким путем идти.»

Алиса в Зазеркалье,

Льюис Кэррол

29.10.2007 V 2.021 15

Что такое проект?

Проект – уникальный набор скоординированных действий, имеющий начальную и конечную точки, направленный на получение определенного конечного результата в рамках ограничений времени, цены, качества и объема работ.

29.10.2007 V 2.021 16

Успешный проект

• Проект – уникальный набор скоординированных действий, имеющий начальную и конечную точки, направленный на получение определенного конечного результата в рамках ограничений времени, цены, качества и объема работ.

Чтобы быть успешным, проект должен:

1. Произвести конечный результат (решить задачу), который бы устраивал всех заинтересованных участников проекта.

2. Закончиться не позже запланированной даты (вовремя).

3. Остаться при этом в рамках требований качества, ограничений бюджета и объема работ.

29.10.2007 V 2.021 17

Измерения успешности• Набор основных измерений

– Требования (Scope)• Запланировано = реализовано

• Заказчик доволен

– График (Schedule)• Продолжительность план = продолжительность

факт

– Бюджет (Budget)• Трудозатраты план = трудозатраты факт

• Бюджет план = бюджет факт

– Качество (Quality)• Покрытие тестами ~100%

• «Критический\серьезный» дефекты = 0

Проектный треугольник

• Мастер ($100/день) делает 1 кресло в день• Нам нужно 1 кресло (у нас есть день и $100)• Нет заноз и кресло не разваливается

Задачи

Время

Люди

«Почему у нас никак не получается?!!»

• «Потому что строем не ходите!»– делали вещи посложнее

– невероятные требования к надежности

– сроки выдерживали

• Потому что методология!– MIL-STD (2167…)

– DOD-STD (498…)

29.10.2007 V 2.021 20

«Водопад»

(с) Steve McConnel. «Rapid Development»

Концепция

Сбор Требований

Разработка Архитектуры

Проработка Архитектуры

Кодирование и отладка

Тестирование

29.10.2007 V 2.021 21

Никогда в жизни не сработает!

Как следствие

• Наблюдения за 3 года:

– Средняя задержка – 20%

– Среднее превышение бюджета – 30%

– Сделано больше чем планировалось

– Заказчик все равно недоволен

– Качество сделанного ПО оставляет желать лучшего

– Разработчики еще почему-то ругают руководство и Заказчика

16.01.2008 V 2.021 23

«Мы совсем неплохо оцениваем»

«Большинство руководителей проектов по созданию ПО проделывают приемлемую работу по предсказанию задач, которые должны быть выполнены, и слабую работу по предсказанию задач, которые может потребоваться выполнить.»

Том де Марко. «Вальсируя с медведями»

Время

ги, н

еуч

тен

иск

и, и

ия Релиз билд билд билд билд

«Предел возможностей»

«Большой взрыв»

Agile Manifesto

• Нужды Заказчика – прежде всего

• Требования должны меняться

• Разработчики и Заказчик работают вместе

• Релизы должны происходить часто

• Коммуникации – лучшая документация

• Команда – основная ценность

• Совершенство заключается в простоте

• Постоянно стремиться сделать для Заказчика больше

16.01.2008 V 2.021 26

Agile-фрэймворки

16.01.2008 V 2.021 27

Смысл один и тот же

Время

ги, н

еуч

тен

иск

и, и

Релизбилдбилд билд билд

«Предел возможностей»

Ценности Agile

• Коммуникации вместо длинных контрактов

• Рабочий софт вместо длинных спек

• Ответ на изменение вместо следования плану

• Храбрость и принятие ответственности

16.01.2008 V 2.021 29

Как устроен Agile-проект?

Пользователи пишут «хотелки» и тесты для

них

Заказчик выбирает из длинного списка

короткий - «сделать в эту итерацию»

Программисты пишут программу вместе с

Заказчиком, консультируясь с

Заказчиком

Тестеры проверяют наличие ошибок и

сообщают программистам

Программисты исправляют ошибки

Администраторы устанавливают

программу на сервер

Заказчики удостоверяются, что программа работает

Заказчики пишут новые требования

[Переходим в начало]

Process Guidance

16.01.2008 V 2.021 31

Где же менеджер???

16.01.2008 V 2.021 32

Коучинг

• В идеале – менеджер:

– Может заменить любого члена команды

– Может учить по любой теме

– Готов взять на себя самую тяжелую\нудную часть работы

16.01.2008 V 2.021 33

Ключевой вопрос – «почему»

Цель проектаЦель человека

Цель проекта

Цель человека

Попробуйте представить…

• Заказчик намеренно хочет вытрясти из вас максимум за фиксированную цену

• Заказчик вообще не хочет чтобы приложение зарелизилось

• Заказчику нужно чтоб никто никогда не узнал что он не понимает чего хочет

• Заказчику нужно грамотно перевести стрелки и назначить виноватого

16.01.2008 V 2.021 35

Ключевое условие

16.01.2008 V 2.021 36

А причем здесь инструмент?

16.01.2008 V 2.021 37

Когда появляется инструмент?

Команда распределена географически –целиком или частично

Команда распределена во времени – целиком или частично

Команда совмещает проекты или периодически уходит в suspend

Требуется предоставить прозрачность –инвестору (продукт) или спонсору (аутсорс)

Команда отладила процесс и желает его ускорить

16.01.2008 V 2.021 38

Team System как такой инструмент

Clients & API

Team Explorer

Reporting Services

Office Apps

Process Template -> Project

Process

Engine

Data Logic & Rules

16.01.2008 V 2.021 39

2 основных process templates

Нужная фича MSF for Agile 4.2 Scrum for Team System 2.0

Backlog

Burndown

Task board

Zero-bug mindset

Checkin Policy

Agile Reports

Extended Reports

16.01.2008 V 2.021 40

Итого

• Agile – не «процесс», а набор ценностей

• Agile использует старые добрые проверенные временем практики

• Agile предлагает сокращать длину итерации

• + гибкость в принятии изменений, что приятно и Заказчику, и Разработчикам

16.01.2008 V 2.021 41

Перерыв – 20 минут

29.10.2007 V 2.021 42

Один спринт из жизни AgileЛекция 2

29.10.2007 V 2.021 43

Как устроен проект?

Пользователи пишут «хотелки» и тесты

для них

Заказчик выбирает из длинного списка короткий - «сделать

в эту итерацию»

Программисты пишут программу

вместе с Заказчиком

Администраторы устанавливают программу на

сервер

Проект Concretica

16.01.2008 V 2.021 45

Elevator pitch

16.01.2008 V 2.021 46

Scrum for Team System 2008

16.01.2008 V 2.021 47

http://www.scrumforteamsystem.com/

По шагам

для них

сервер

Роли в Agile

Заказчик (Product Owner)– Пишет «хотелки», тесты и примеры к ним– Объясняет «хотелки» и расставляет приоритеты– Общается с пользователями– Решает, что важно и что нет

Разработчик– Определяет задачи для реализации «хотелки»– Дает оценки объема работ– Реализует в коде «хотелки» и юнит-тесты к ним

Scrum Master– Собирает и контролирует встречи– Информирует Спонсора– Платит за пиццу– Убирает препятствия (Impediments)

16.01.2008 V 2.021 49

С чего все начинается?

Пользователи

Заказчик

«хотелки» пользователей

Scrum Master

Задачи программистам

Заказчик (Product Owner)1. Собирает

информацию от всех2. Отсекает явно

ненужное3. Утверждает «хотелки»

Scrum Master:1. Поддерживает список

«хотелок»2. Управляет

обсуждением и процессом оценки

3. Не оценивает

Определение Product Backlog Item

«Хотелка» – это наиболее простая формулировка, позволяющая всем присутствующим согласиться с тем, что существует нечто, что необходимо сделать в рамках проекта.

16.01.2008 V 2.021 51

SEADMEX

Storycard – Лицевая сторонаID

Суть задачи

Превосходная «хотелка»

Независима и самодостаточна

Может обсуждаться с разработчиком и корректироваться, уточняться

Определяет свойство системы, нужное пользователям/заказчикам

Позволяет оценить трудоемкость

Невелика по объему

Определяет свойство системы, которое может быть протестировано

16.01.2008 V 2.021 53

SEADMEX

Storycard – Оборотная сторона

Тест

Работа с Заказиком

Сколько времени займет дорисовать кнопку?

(Сколько это будет стоить?)

Документация

16.01.2008 V 2.021 56

Если проект большой

16.01.2008 V 2.021 57

«Хотелка» в Product Backlog

29.10.2007 V 2.021 58

Acceptance Test Driven Development

29.10.2007 V 2.021 59

Типы Fixtures

29.10.2007 V 2.021 60

Action

Column

Роли в Agile

Тестер

– Пишет и прогоняет * тесты

– Оформляет результаты так, чтобы всем было понятно

Пессимист

– Напоминает всем по риски

– Следит, чтобы мы не принимали желаемое за действительное

16.01.2008 V 2.021 61

Зачем нужен бэклог?

• Бэклог – это форма записи требований

– Без бэклога нельзя сделать Заказчика счастливым

• Бэклог – это форма коммуникации

– Если бэклог непонятен Заказчику –коммуникация не состоялась

16.01.2008 V 2.021 62

Преимущества

• Переработаем до приемлемого вида очень быстро

• Изменения стоят копейки• Разберемся в деталях• Точно поставим задачу и

программист поймет ее правильно

• Получим удобную Программу с первого раза

По шагам

для них

сервер

[Новая итерация]

Определяем порядок

Product BacklogПрограммист

«Хотелки»+ оценки

Оценка: 4 часа

Оценка: 6 часов

Оценка: 0,25 часа

Оценка: 1 час

Итого: 100 000 часов

Заказчик

Sprint Backlog

«Принесет нам миллион»

Добавить в базуScrum Master

Обновить orm

Прикрутить фиксчи

Итого: 40 часов

Оценка в часах

• Чем меньше задача – тем точнее оценка

– Разбивайте большие «хотелки» на меньшие

– Для каждой «хотелки» расписывайте набор задач

– Оценивайте каждую задачу

– Оценивает тот, кто будет делать задачу

29.10.2007 V 2.021 67

«Хотелка» и «задача»

• «Парни, я хочу хранить для участка информацию о том, какие конкретно ПИ там живут!»

Задача №00234

Формируем Sprint Backlog

Программист

«Хотелки»+ оценки

Оценка: 1 час

Итого: 100 000 часов

Заказчик

Product Backlog ItemsFor this Sprint

1. «Принесет нам миллион»

2. «Сэкономит нам миллион»

3. «Даст 100 новых клиентов»

Scrum Master

Когда останавливаться?

16.01.2008 V 2.021 70

Вспоминаем почему так:

• Мастер ($100/день) делает 1 кресло в день

• Нам нужно 1 кресло (у нас есть день и $100)

Задачи

Время

Люди

Принцип отбора в спринт

16.01.2008 V 2.021 72

Быстройдествие = 30

Балансируем треугольникБыстройдествие = 30

29.10.2007 V 2.021 73

A (15)

B (10)

A (15)

B (10)

A (15)

Быстройдествие = 30

• То, что реально важно, всегда делается

• Скорость – очень высокая

• Это происходит из-за высокой эффективности работы, а не за счет качества

• Себестоимость при этом получается - ниже

Концептуальные связи

16.01.2008 V 2.021 75

SprintBacklog

Sprint Backlog

ItemBug

29.10.2007 V 2.021 76

По шагам

для них

сервер

Definition Of Done

• Backlog Item сделан

– Код в TFS, с комментарием

– Юнит-тест в проекте

– Юнит-тесты проекта прошли

– Глупых ошибок на UI нет

• Backlog Item закрывает тот, кто его открыл

– Если он недоволен по любой причине – он не закрывает его

– Daily Scrum: 9:00, 75-4

SEADMEX

Project Portal

16.01.2008 V 2.021 79

Definition of done + Process

16.01.2008 V 2.021 80

Сессии по дизайну

16.01.2008 V 2.021 81

Происходит работа...

• Daily Scrum• Программисты делают сессии

по дизайну• Пишут вместе тесты• Потом код• Юнит-тесты проверяют

работоспособность кода• Team Build делает из него

билды, которые тут же тестируются

• Тестеры тестируют билды заглядывая в список What’s New

• До тех пор, пока не сделаны все «хотелки» спринта

Scrum!!!

16.01.2008 V 2.021 83

Daily Scrum

16.01.2008 V 2.021 84

Task Board и его чтение

16.01.2008 V 2.021 85

Task Board в Team System

16.01.2008 V 2.021 86

Как сделать чтоб обновлялись оперативно:

http://msdn.microsoft.com/en-us/library/ms400787.aspx

Спецплагин Task Board

16.01.2008 V 2.021 87

http://www.scrumforteamsystem.com/en/TaskBoard/default.aspx

Мегамонитор

16.01.2008 V 2.021 88

Роли в Agile

Трэкер

– Собирает со всех информацию об успехах

– При необходимости зовет на помощь Тренера или другого разработчика

Коуч

– Наблюдает и дает советы

– В явном виде помогает

– «Свертывает газету» при необходимости

16.01.2008 V 2.021 89

Трэкер и «прозрачность»

16.01.2008 V 2.021 90

Sprint Burndown

16.01.2008 V 2.021 91

Распределенная работа

16.01.2008 V 2.021 92

Удаленный Product Owner

16.01.2008 V 2.021 93

Skype + SharedView

Постоянная интеграция

16.01.2008 V 2.021 94

Разработчик

делает коммит

Компилируется

проект

Запускаются

юнит-тесты

Билд

успешен -

Запуск процедуры

развертывания и

обновления

Приложение и база

обновлены

Team BuildBVT

Любой

девелопер

TS2008 SCC

Репортинг и

нотификации

Результаты

появляются в

дашборде

Защита от г…кодеров

16.01.2008 V 2.021 95

Самый классный метод

16.01.2008 V 2.021 96

По шагам

для них

сервер

Имплементация Backlog Item

Программист

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

Тестер

Задачи по исправлению ошибок

Заказчик

Тестовые данные

Надежная программа

Тестовые примеры

Тестовые сценарии

• Тестовый пример: Ввести номенклатуру изделия, Программа пишет расшифровку кода номенклатуры, при этом обрабатывает несуществующие коды и замены.

• Проверить с тестовыми данными:

– 005Е6789: «немыслимый шаровой клапан»

– 005N0000: «код не существует»

– 005Т0098: «снят с производства, возможна замена на 005T0198»

Использование FIT

16.01.2008 V 2.021 100

Сломанный билд

16.01.2008 V 2.021 101

Чуть где что не так

16.01.2008 V 2.021 102

Выясняем причину

16.01.2008 V 2.021 103

Прикольный отчет

Fail Builds Successful Builds

Postion

Person Total % Total % Total Builds

1 Aliaksandr Baradyntsau

0 0.00 % 12 100.00 % 12

2 Aliaksei Stankevich 4 20.00 % 16 80.00 % 20

3 Ivan Kirkorau 1 10.00 % 1 90.00 % 10

16.01.2008 V 2.021 104

По шагам

для них

сервер

Zero-bug mindset

16.01.2008 V 2.021 106

• Менеджер и Заказчик думают о том, как должно работать правильно

• Тестер думает о том, чтоможет работать неправильно

• Тестер думает заранее

• Как следствие Программа (почти) всегда работает как надо

По шагам

для них

сервер

Установка программы

Две версии

• Всегда есть версия программы, которая работает

• Тестирование любой степени извращенности не ломает рабочую версию программы

По шагам

для них

сервер

Демо

16.01.2008 V 2.021 113

По шагам

для них

сервер

Ретроспектива & Бэклог препятствий

16.01.2008 V 2.021 115

Анализ причин и следствий

16.01.2008 V 2.021 116

Ретроспектива

16.01.2008 V 2.021 117

По шагам

для них

сервер

• Нет вероятности «передалать» работающую программу в неработающую

• Работающая программа будет установлена на сервер и будет работать (и приносить деньги)

• В это время будут делаться переделки, новые «хотелки» и т.д.

Итого

• Спринт устроен очень просто

16.01.2008 V 2.021 120

для них

сервер

29.10.2007 V 2.021 121

И что дальше?Соображения о внедрении

29.10.2007 V 2.021 122

Из личного опыта

29.10.2007 V 2.021 123

Внедряйте все практики

16.01.2008 V 2.021 124

«Типа

спецификация»

Возможно,

«релиз»

Это не Agile!

Причина неудач внедрений

16.01.2008 V 2.021 125

Цели

бизнеса

Цели

внедрения

Adoption through execution: Project-level mentoring to improve software capability

Kurt Bittner, Communities of Practice Architect, IBM

Saif Islam, Rational Services Manager, IBM

2006 2007

Вот это - Scrum

16.01.2008 V 2.021 126

Не начинайте с инструментов!

• Выберите команду, которая горит желанием делать Agile

• Соберите всю команду вместе

• Поместите Заказчика рядом

• Внедряйте одну практику за раз

• Внедряйте все практики

16.01.2008 V 2.021 127

Типичная ситуация

Новая практика

Непонимание

ЗлостьОсвоение

Удовольствие

16.01.2008 V 2.021 128

Причины недовольства

• Требования без объяснений

• Предыдущий опыт

• Отсутствие мотивации

• Страх изменения

• Страх неудачи

• Синдром «старой собаки»

• Физическое\умственное состояние

16.01.2008 V 2.021 129

Итого

• Помните, зачем делается проект – деньги

• Помните, что требуется личная заинтересованность

• В том числе Заказчика

• У каждого фрэймворка – свой обязательныйсет практик

• Иначе это не Agile

• Простота достигается за счет коммуникаций

• Инструменты – в самом конце

16.01.2008 V 2.021 130

Рекомендую к прочтению

• Agile Project Management with SCRUM

• (Ken Schwaber)

16.01.2008 V 2.021 131

Рекомендую к прочтению

• Better Software Development

• for Agile Teams

• Will Stott

• James Newkirk

16.01.2008 V 2.021 132

29.10.2007 V 2.021 133

Audaces fortuna juvat!

Рефлексия• Зачем я сюда пришел (пришла)?

– Есть ощущение удовлетворения этой потребности?

• Что я хочу узнать?

– Получили нужную информацию и источники?

29.10.2007 V 2.021 134

Сессия вопросов и ответов

16.01.2008 V 2.021 135

Slid 3.0 Scrum для практиков на Vsts2008

Documents

Enzimas slid

Paso doble slid

Slid Eta 06

Возможности контекстной рекламы от практиков рынка, Софья Елисеева, РА ADLABS

Slid forever

Apresentar slid eyoutube

Enfermedades Prevalentes Slid

Bateria tiristores slid

Slid estrategia pedagógicas.pptx

slid. dr. mechanism

Kapuklook slid

Pres100318 Ving Slid

Slid Eta 10

Slid juliana nicole

Slid Eta 03

Slid e presentasi

Slid Eta 07

Slid Pajsk

Slid hotel revmanager

Proinfo slid- célia