2. Давайте знакомиться
Денис Петелин
Успел попробовать себя во всех ролях софтверных проектов – от
разработчика до владельца компании и Заказчика.
Поскольку во всех ролях работал успешно, то имею востребованный
опыт, который передаю другим.
В последнее время все больше выступаю в роли Заказчика, где
применяю изученные у Заказчиков грязные трюки
Попутно являюсь Product Owner для одного стартапа, Scrum Master для
еще одной команды, Agile Coach для двух проектов.
Denis_petelin@epam.com
http://www.seadmex.ru/custo
SEADMEX
mers/epam
3.
4. Окей, мы все через это прошли
29.10.2007 V 2.021 4
6. Vision Scope
• Вы уже повозились с Team System и теперь
по какой-то причине вам интересно, как мы
делаем agile (scrum) в Team System 2008:
1. Я – менеджер, и могу говорить только за agile и
Team System для менеджеров
2. Я собираюсь его обзорно показать вам в разрезе
«процесс»
3. Я собираюсь вам его обзорно показать в разрезе
«инструмент»
16.01.2008 V 2.021 6
7. Vision Scope
• У меня на это дело есть один день:
1. Я собираюсь его обзорно показать вам в разрезе
«процесс»
a) Это не тренинг по agile-методологиям
b) Я не собираюсь вас убеждать что agile работает
2. Я собираюсь вам его обзорно показать в разрезе
«инструмент»
a) Я (почти) не буду показывать администрирование
b) Мы не будем конфигурировать сервер упражняться
16.01.2008 V 2.021 7
8. Disclaimer
• Мы не делаем ничего сверхъестественного
• Я – не супер-мега-гуру Team System 2008
• Да, есть много способов делать все лучше в
Team System 2008
• Да, есть много других инструментов кроме
Team System 2008
• Да, вы могли бы сделать все в 10 раз лучше
16.01.2008 V 2.021 8
9. Limitations of liability
1. Показанное не значит, что наш путь
единственно верный
2. Это не значит даже, что он подойдет вам
3. Используя эти соображения и подходы – вы
делаете это на свой страх и риск, ни я ни кто-
либо другой не несем за это ответственности
4. Пытаясь их тупо скопировать без понимания
зачем оно вам надо – вы гарантированно
огребете проблем
16.01.2008 V 2.021 9
10. 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
11. Рабочие соглашения
Сотовые – Почту – не
выключить читать
Говорить –
Коллег –
строго по
не гнобить
одному
29.10.2007 V 2.021 11
12. Орг. Вопросы
• Формат работы: 1,5 часа Х 4 спринта
• Перерыв: 20 минут
• Обед: после 2х спринтов, 1 час
• Вопросы – задавать любые, даже не по
теме тренинга
• Вопросы не по теме – на перерывах
• Материалы – будут выложены на Office Live
16.01.2008 V 2.021 12
13. Вопрос (1 минута подумать)
• Зачем я сюда пришел (пришла)?
– Пример: Завтра мне начинать проект на Team
System. С чего начать?
• Что я хочу узнать?
– Пример: Хочу чтоб в голове сложилось
последовательность действий менеджера,
устанавливающего Agile на проекте.
• Опыт использования софта для управления?
– Пример: FogBugz – 5 лет, OnTime – 3 года, TFS – 20
лет
29.10.2007 V 2.021 13
15. Начнем – с начала
Алиса: «Не подскажете, каким
путем мне идти, чтобы отсюда
выбраться?»
Кот: «Ну, это в значительной
степени определяется тем, куда
вы хотите попасть.»
Алиса: «Мне, в общем-то, все
равно...»
Кот: «Тогда не имеет никакого
значения, каким путем идти.»
Алиса в Зазеркалье,
Льюис Кэррол
29.10.2007 V 2.021 15
16. Что такое проект?
Проект – уникальный
набор скоординированных
действий, имеющий
начальную и конечную
точки, направленный на
получение определенного
конечного результата в
рамках ограничений
времени, цены, качества и
объема работ.
29.10.2007 V 2.021 16
17. Успешный проект
• Проект – уникальный набор скоординированных действий, имеющий
начальную и конечную точки, направленный на получение
определенного конечного результата в рамках ограничений времени,
цены, качества и объема работ.
Чтобы быть успешным, проект должен:
1. Произвести конечный результат (решить задачу), который бы
устраивал всех заинтересованных участников проекта.
2. Закончиться не позже запланированной даты (вовремя).
3. Остаться при этом в рамках требований качества, ограничений
бюджета и объема работ.
29.10.2007 V 2.021 17
18. Измерения успешности
• Набор основных измерений
– Требования (Scope)
• Запланировано = реализовано
• Заказчик доволен
– График (Schedule)
• Продолжительность план = продолжительность
факт
– Бюджет (Budget)
• Трудозатраты план = трудозатраты факт
• Бюджет план = бюджет факт
– Качество (Quality)
• Покрытие тестами ~100%
• «Критическийсерьезный» дефекты = 0
19. Проектный треугольник
Задачи Люди
Время
• Мастер ($100/день) делает 1 кресло в день
• Нам нужно 1 кресло (у нас есть день и $100)
• Нет заноз и кресло не разваливается
20. «Почему у нас никак не получается?!!»
• «Потому что строем
не ходите!»
– делали вещи посложнее
– невероятные требования к
надежности
– сроки выдерживали
• Потому что
методология!
– MIL-STD (2167…)
– DOD-STD (498…)
29.10.2007 V 2.021 20
21. «Водопад»
Концепция
(с) Steve McConnel. «Rapid Development»
Сбор Требований
Разработка Архитектуры
Проработка Архитектуры
Кодирование и отладка
Тестирование
29.10.2007 V 2.021 21
23. Как следствие
• Наблюдения за 3 года:
– Средняя задержка – 20%
– Среднее превышение бюджета – 30%
– Сделано больше чем планировалось
– Заказчик все равно недоволен
– Качество сделанного ПО оставляет желать
лучшего
– Разработчики еще почему-то ругают
руководство и Заказчика
16.01.2008 V 2.021 23
24. «Мы совсем неплохо оцениваем»
«Большинство руководителей
проектов по созданию ПО
проделывают приемлемую
работу по предсказанию задач,
которые должны быть
выполнены, и слабую работу
по предсказанию задач,
которые может потребоваться
выполнить.»
Том де Марко. «Вальсируя с медведями»
26. Agile Manifesto
• Нужды Заказчика – прежде всего
• Требования должны меняться
• Разработчики и Заказчик работают вместе
• Релизы должны происходить часто
• Коммуникации – лучшая документация
• Команда – основная ценность
• Совершенство заключается в простоте
• Постоянно стремиться сделать для Заказчика
больше
16.01.2008 V 2.021 26
28. Смысл один и тот же
Баги, неучтенные риски, изменения
билд билд билд билд Релиз
«Предел возможностей»
Время
29. Ценности Agile
• Коммуникации вместо длинных контрактов
• Рабочий софт вместо длинных спек
• Ответ на изменение вместо следования
плану
• Храбрость и принятие ответственности
16.01.2008 V 2.021 29
30. Как устроен Agile-проект?
Пользователи пишут Администраторы Заказчики
«хотелки» и тесты для устанавливают удостоверяются, что
них программу на сервер программа работает
Заказчик выбирает из
длинного списка Программисты Заказчики пишут новые
короткий - «сделать в исправляют ошибки требования
эту итерацию»
Программисты пишут
Тестеры проверяют
программу вместе с
наличие ошибок и
Заказчиком, [Переходим в начало]
сообщают
консультируясь с
программистам
Заказчиком
33. Коучинг
• В идеале – менеджер:
– Может заменить любого
члена команды
– Может учить по любой
теме
– Готов взять на себя
самую тяжелуюнудную
часть работы
16.01.2008 V 2.021 33
34. Ключевой вопрос – «почему»
Цель проекта
Цель проекта
Цель человека
Цель
человека
35. Попробуйте представить…
• Заказчик намеренно хочет вытрясти из вас
максимум за фиксированную цену
• Заказчик вообще не хочет чтобы
приложение зарелизилось
• Заказчику нужно чтоб никто никогда не
узнал что он не понимает чего хочет
• Заказчику нужно грамотно перевести
стрелки и назначить виноватого
16.01.2008 V 2.021 35
38. Когда появляется инструмент?
Команда распределена географически –
целиком или частично
Команда распределена во времени – целиком
или частично
Команда совмещает проекты или
периодически уходит в suspend
Требуется предоставить прозрачность –
инвестору (продукт) или спонсору (аутсорс)
Команда отладила процесс и желает его
ускорить
16.01.2008 V 2.021 38
39. Team System как такой инструмент
Clients & API
Team
Explorer Process Template -> Project
Reporting
Services
Process Engine
Data Logic & Rules
Office Tools
Apps
16.01.2008 V 2.021 39
40. 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
41. Итого
• Agile – не «процесс», а набор ценностей
• Agile использует старые добрые
проверенные временем практики
• Agile предлагает сокращать длину итерации
• + гибкость в принятии изменений, что
приятно и Заказчику, и Разработчикам
16.01.2008 V 2.021 41
44. Как устроен проект?
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и [Переходим в
пишут программу
сообщают начало]
вместе с Заказчиком
программистам
47. Scrum for Team System 2008
http://www.scrumforteamsystem.com/
16.01.2008 V 2.021 47
48. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и [Переходим в
пишут программу
сообщают начало]
вместе с Заказчиком
программистам
49. Роли в Agile
Заказчик (Product Owner)
– Пишет «хотелки», тесты и примеры к ним
– Объясняет «хотелки» и расставляет приоритеты
– Общается с пользователями
– Решает, что важно и что нет
Разработчик
– Определяет задачи для реализации «хотелки»
– Дает оценки объема работ
– Реализует в коде «хотелки» и юнит-тесты к ним
Scrum Master
– Собирает и контролирует встречи
– Информирует Спонсора
– Платит за пиццу
– Убирает препятствия (Impediments)
16.01.2008 V 2.021 49
50. С чего все начинается?
Заказчик Scrum Master
«хотелки» пользователей Задачи программистам
Пользователи
Заказчик (Product Owner) Scrum Master:
1. Собирает 1. Поддерживает список
информацию от всех «хотелок»
2. Отсекает явно 2. Управляет
ненужное обсуждением и
3. Утверждает «хотелки» процессом оценки
3. Не оценивает
51. Определение Product Backlog Item
«Хотелка» – это наиболее простая
формулировка, позволяющая всем
присутствующим согласиться с тем, что
существует нечто, что необходимо сделать в
рамках проекта.
16.01.2008 V 2.021 51
53. Превосходная «хотелка»
Независима и самодостаточна
Может обсуждаться с разработчиком и
корректироваться, уточняться
Определяет свойство системы, нужное
пользователям/заказчикам
Позволяет оценить трудоемкость
Невелика по объему
Определяет свойство системы, которое
может быть протестировано
16.01.2008 V 2.021 53
60. Типы Fixtures
Column Action
Row
29.10.2007 V 2.021 60
61. Роли в Agile
Тестер
– Пишет и прогоняет * тесты
– Оформляет результаты так, чтобы всем было
понятно
Пессимист
– Напоминает всем по риски
– Следит, чтобы мы не принимали желаемое за
действительное
16.01.2008 V 2.021 61
62. Зачем нужен бэклог?
• Бэклог – это форма
записи требований
– Без бэклога нельзя
сделать Заказчика
счастливым
• Бэклог – это форма
коммуникации
– Если бэклог непонятен
Заказчику –
коммуникация не
состоялась
16.01.2008 V 2.021 62
63. Преимущества
• Переработаем до
приемлемого вида очень
быстро
• Изменения стоят копейки
• Разберемся в деталях
• Точно поставим задачу и
программист поймет ее
правильно
• Получим удобную Программу
с первого раза
64. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
66. Product Backlog
«Хотелки»+ оценки
Программист
Оценка: 4 часа
Scrum Master Оценка: 2 часа
Добавить в базу
Оценка: 6 часов Обновить orm
«Принесет
Оценка: 0,25 часа
нам миллион» Прикрутить фиксчи
Заказчик Оценка: 8 часов
Итого:
Оценка: 16 часов 40 часов
Sprint Backlog
Оценка: 1 час
...
Итого:
100 000 часов
67. Оценка в часах
• Чем меньше задача – тем
точнее оценка
– Разбивайте большие
«хотелки» на меньшие
– Для каждой «хотелки»
расписывайте набор задач
– Оценивайте каждую задачу
– Оценивает тот, кто будет
делать задачу
29.10.2007 V 2.021 67
68. «Хотелка» и «задача»
Задача №00234
• «Парни, я хочу хранить для участка
информацию о том, какие конкретно ПИ
там живут!»
69. Формируем Sprint Backlog
«Хотелки»+ оценки
Оценка: 4 часа Заказчик
Scrum Master Оценка: 2 часа
1. «Принесет нам миллион»
Оценка: 0,5 часа
2. «Сэкономит нам миллион»
Оценка: 0,25 часа
3. «Даст 100 новых клиентов»
Оценка: 8 часов
Product Backlog Items
Оценка: 16 часов For this Sprint
Оценка: 1 час
...
Программист
Итого:
100 000 часов
73. Балансируем треугольник
Быстройдествие = 30 Быстройдествие = 30 Быстройдествие = 30
A (15) A (15) A (15)
D (5)
B (10) B (10)
C (5)
C (5) D (5) E (5)
D (5) C (5)
29.10.2007 V 2.021 73
74. Преимущества
• То, что реально важно,
всегда делается
• Скорость – очень высокая
• Это происходит из-за
высокой эффективности
работы, а не за счет
качества
• Себестоимость при этом
получается - ниже
75. Концептуальные связи
Backlog
Sprint
Item
Sprint
Backlog Bug
Item
16.01.2008 V 2.021 75
77. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
78. Definition Of Done
• Backlog Item сделан
– Код в TFS, с комментарием
– Юнит-тест в проекте
– Юнит-тесты проекта прошли
– Глупых ошибок на UI нет
• Backlog Item закрывает тот, кто его открыл
– Если он недоволен по любой причине – он не
закрывает его
– Daily Scrum: 9:00, 75-4
SEADMEX
82. Происходит работа...
• Daily Scrum
• Программисты делают сессии
по дизайну
• Пишут вместе тесты
• Потом код
• Юнит-тесты проверяют
работоспособность кода
• Team Build делает из него
билды, которые тут же
тестируются
• Тестеры тестируют билды
заглядывая в список What’s New
• До тех пор, пока не сделаны все
«хотелки» спринта
89. Роли в Agile
Трэкер
– Собирает со всех информацию об успехах
– При необходимости зовет на помощь Тренера
или другого разработчика
Коуч
– Наблюдает и дает советы
– В явном виде помогает
– «Свертывает газету» при необходимости
16.01.2008 V 2.021 89
94. Постоянная интеграция
Компилируется
проект
TS2008 SCC
Разработчик
Любой Запускаются
делает коммит
девелопер юнит-тесты
Репортинг и
нотификации
BVT
Team Build Запуск процедуры
Результаты
появляются в Билд развертывания и
дашборде успешен - обновления
Приложение и база
обновлены
16.01.2008 V 2.021 94
97. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
98. Имплементация Backlog Item
Программист Задачи по исправлению ошибок
Тестовые примеры
Заказчик
Список выполненных задач +
Тестер
Тестовые данные
результирующая программа
Надежная программа
99. Тестовые сценарии
• Тестовый пример: Ввести номенклатуру
изделия, Программа пишет расшифровку кода
номенклатуры, при этом обрабатывает
несуществующие коды и замены.
• Проверить с тестовыми данными:
– 005Е6789: «немыслимый шаровой клапан»
– 005N0000: «код не существует»
– 005Т0098: «снят с производства, возможна замена
на 005T0198»
104. Прикольный отчет
Fail Builds Successful Builds
Postio Person Total % Total % Total Builds
n
1 Aliaksandr 0 0.00 % 12 100.00 % 12
Baradyntsau
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
105. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
107. Преимущества
• Менеджер и Заказчик думают
о том, как должно работать
правильно
• Тестер думает о том, что
может работать неправильно
• Тестер думает заранее
• Как следствие Программа
(почти) всегда работает как
надо
108. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
111. Преимущества
• Всегда есть версия
программы, которая
работает
• Тестирование любой
степени извращенности не
ломает рабочую версию
программы
112. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
114. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
118. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
119. Преимущества
• Нет вероятности
«передалать» работающую
программу в неработающую
• Работающая программа будет
установлена на сервер и будет
работать (и приносить деньги)
• В это время будут делаться
переделки, новые «хотелки» и
т.д.
120. Итого
• Спринт устроен очень просто
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
16.01.2008 V 2.021 120
124. Внедряйте все практики
«Типа Возможно,
спецификация» «релиз»
Это не Agile!
16.01.2008 V 2.021 124
125. Причина неудач внедрений
2006 2007
Цели
бизнеса
Цели
внедрения
Adoption through execution: Project-level mentoring to improve software capability
Kurt Bittner, Communities of Practice Architect, IBM
Saif Islam, Rational Services Manager, IBM
16.01.2008 V 2.021 125
127. Не начинайте с инструментов!
• Выберите команду, которая горит
желанием делать Agile
• Соберите всю команду вместе
• Поместите Заказчика рядом
• Внедряйте одну практику за раз
• Внедряйте все практики
16.01.2008 V 2.021 127
128. Типичная ситуация
Новая
практика
Удовольствие Непонимание
Освоение Злость
16.01.2008 V 2.021 128
129. Причины недовольства
• Требования без объяснений
• Предыдущий опыт
• Отсутствие мотивации
• Страх изменения
• Страх неудачи
• Синдром «старой собаки»
• Физическоеумственное состояние
16.01.2008 V 2.021 129
130. Итого
• Помните, зачем делается проект – деньги
• Помните, что требуется личная
заинтересованность
• В том числе Заказчика
• У каждого фрэймворка – свой обязательный
сет практик
• Иначе это не Agile
• Простота достигается за счет коммуникаций
• Инструменты – в самом конце
16.01.2008 V 2.021 130
131. Рекомендую к прочтению
• Agile Project
Management with
SCRUM
• (Ken Schwaber)
16.01.2008 V 2.021 131
132. Рекомендую к прочтению
• Better Software
Development
• for Agile Teams
• Will Stott
• James Newkirk
16.01.2008 V 2.021 132
134. Рефлексия
• Зачем я сюда пришел (пришла)?
– Есть ощущение удовлетворения этой
потребности?
• Что я хочу узнать?
– Получили нужную информацию и источники?
29.10.2007 V 2.021 134
