2. Давайте знакомиться
Денис Петелин
Успел попробовать себя во всех ролях софтверных проектов – от
разработчика до владельца компании и Заказчика.
Поскольку во всех ролях работал успешно, то имею востребованный
опыт, который передаю другим.
В последнее время все больше выступаю в роли Заказчика, где
применяю изученные у Заказчиков грязные трюки
Denis_petelin@epam.com
http://www.seadmex.ru/custo
SEADMEX
mers/epam
3. Окей, мы все через это прошли
29.10.2007 V 2.021 3
5. Управление ожиданиями
• Agile – это не методология типа
RUP, это фрэймворк
• Моя задача – рассказать ЧТО
должно быть сделано, КАК вы
будете это делать – это ваш
выбор
• Я расскажу как МЫ делаем Agile
• (Это не значит, что ВЫ будете
делать Agile также)
• Я не расскажу вам все в деталях
(но дам доп. Материалы)
7. Рабочие соглашения
• Сотовые – выключить
• Почту – не читать
• Коллег – не перебивать
• Говорить – строго по одному
29.10.2007 V 2.021 7
8. Потенциальные проблемы
• Некоторые слайды
«перегружены»
• Говорю слишком быстро или
слишком медленно
• Говорю слишком громко или
слишком тихо
• Непонятные моменты
• Телефоны и пейджеры
• Просьба о перерыве
9. Орг. Вопросы
• Туалеты – влево и вниз по лестнице
• Формат работы: 1,5 часа – перерыв Х 4
• Вопросы – задавать любые, даже не по
теме тренинга
• Материалы – будут выложены на Office Live
16.01.2008 V 2.021 9
10. Вопрос
• Зачем я сюда пришел (пришла)?
– Пример: Завтра мне начинать проект по Agile.
С чего начать?
• Что я хочу узнать?
– Пример: Хочу чтоб в голове сложилось
последовательность действий менеджера,
устанавливающего Agile на проекте.
29.10.2007 V 2.021 10
12. Начнем – с начала
Алиса: «Не подскажете, каким
путем мне идти, чтобы отсюда
выбраться?»
Кот: «Ну, это в значительной
степени определяется тем, куда
вы хотите попасть.»
Алиса: «Мне, в общем-то, все
равно...»
Кот: «Тогда не имеет никакого
значения, каким путем идти.»
Алиса в Зазеркалье,
Льюис Кэррол
29.10.2007 V 2.021 12
13. Что такое проект?
Проект – уникальный
набор скоординированных
действий, имеющий
начальную и конечную
точки, направленный на
получение определенного
конечного результата в
рамках ограничений
времени, цены, качества и
объема работ.
29.10.2007 V 2.021 13
14. Успешный проект
• Проект – уникальный набор скоординированных действий, имеющий
начальную и конечную точки, направленный на получение
определенного конечного результата в рамках ограничений времени,
цены, качества и объема работ.
Чтобы быть успешным, проект должен:
1. Произвести конечный результат (решить задачу), который бы
устраивал всех заинтересованных участников проекта.
2. Закончиться не позже запланированной даты (вовремя).
3. Остаться при этом в рамках требований качества, ограничений
бюджета и объема работ.
29.10.2007 V 2.021 14
15. Измерения успешности
• Набор основных измерений
– Требования (Scope)
• Запланировано = реализовано
• Заказчик доволен
– График (Schedule)
• Продолжительность план = продолжительность
факт
– Бюджет (Budget)
• Трудозатраты план = трудозатраты факт
• Бюджет план = бюджет факт
– Качество (Quality)
• Покрытие тестами ~100%
• «Критическийсерьезный» дефекты = 0
16. Проектный треугольник
Задачи Люди
Время
• Мастер ($100/день) делает 1 кресло в день
• Нам нужно 1 кресло (у нас есть день и $100)
• Нет заноз и кресло не разваливается
17. «Почему у нас никак не получается?!!»
• «Потому что строем
не ходите!»
– делали вещи посложнее
– невероятные требования к
надежности
– сроки выдерживали
• Потому что
методология!
– MIL-STD (2167…)
– DOD-STD (498…)
29.10.2007 V 2.021 17
18. «Водопад»
Концепция
(с) Steve McConnel. «Rapid Development»
Сбор Требований
Разработка Архитектуры
Проработка Архитектуры
Кодирование и отладка
Тестирование
29.10.2007 V 2.021 18
20. Как следствие
• Наблюдения за 3 года:
– Средняя задержка – 20%
– Среднее превышение бюджета – 30%
– Сделано больше чем планировалось
– Заказчик все равно недоволен
– Качество сделанного ПО оставляет желать
лучшего
– Разработчики еще почему-то ругают
руководство и Заказчика
16.01.2008 V 2.021 20
21. «Мы совсем неплохо оцениваем»
«Большинство руководителей
проектов по созданию ПО
проделывают приемлемую
работу по предсказанию задач,
которые должны быть
выполнены, и слабую работу
по предсказанию задач,
которые может потребоваться
выполнить.»
Том де Марко. «Вальсируя с медведями»
23. Agile Manifesto
• Нужды Заказчика – прежде всего
• Требования должны меняться
• Разработчики и Заказчик работают вместе
• Релизы должны происходить часто
• Коммуникации – лучшая документация
• Команда – основная ценность
• Совершенство заключается в простоте
• Постоянно стремиться сделать для Заказчика
больше
16.01.2008 V 2.021 23
25. Смысл один и тот же
Баги, неучтенные риски, изменения
билд билд билд билд Релиз
«Предел возможностей»
Время
26. Ценности Agile
• Коммуникации вместо длинных контрактов
• Рабочий софт вместо длинных спек
• Ответ на изменение вместо следования
плану
• Храбрость и принятие ответственности
16.01.2008 V 2.021 26
27. Как устроен Agile-проект?
Пользователи пишут Администраторы Заказчики
«хотелки» и тесты для устанавливают удостоверяются, что
них программу на сервер программа работает
Заказчик выбирает из
длинного списка Программисты Заказчики пишут новые
короткий - «сделать в исправляют ошибки требования
эту итерацию»
Программисты пишут
Тестеры проверяют
программу вместе с
наличие ошибок и
Заказчиком, [Переходим в начало]
сообщают
консультируясь с
программистам
Заказчиком
28. Итого
• Agile – не «процесс», а набор ценностей
• Agile использует старые добрые
проверенные временем практики
• Agile предлагает сокращать длину итерации
• + гибкость в принятии изменений, что
приятно и Заказчику, и Разработчикам
16.01.2008 V 2.021 28
31. Как устроен проект?
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и [Переходим в
пишут программу
сообщают начало]
вместе с Заказчиком
программистам
32. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и [Переходим в
пишут программу
сообщают начало]
вместе с Заказчиком
программистам
33. Роли в Agile
Заказчик (Product Owner)
– Пишет «хотелки», тесты и примеры к ним
– Объясняет «хотелки» и расставляет приоритеты
– Общается с пользователями
– Решает, что важно и что нет
Разработчик
– Определяет задачи для реализации «хотелки»
– Дает оценки объема работ
– Реализует в коде «хотелки» и юнит-тесты к ним
Scrum Master
– Собирает и контролирует встречи
– Информирует Спонсора
– Платит за пиццу
– Убирает препятствия (Impediments)
16.01.2008 V 2.021 33
34. С чего все начинается?
Заказчик Scrum Master
«хотелки» пользователей Задачи программистам
Пользователи
Заказчик (Product Owner) Scrum Master:
1. Собирает 1. Поддерживает список
информацию от всех «хотелок»
2. Отсекает явно 2. Управляет
ненужное обсуждением и
3. Утверждает «хотелки» процессом оценки
3. Не оценивает
35. Работа с Заказиком
Сколько времени займет дорисовать кнопку?
(Сколько это будет стоить?)
36. Определение user story
«Хотелка» – это наиболее простая
формулировка, позволяющая всем
присутствующим согласиться с тем, что
существует нечто, что необходимо сделать в
рамках проекта.
16.01.2008 V 2.021 36
39. Превосходная «хотелка»
Независима и самодостаточна
Может обсуждаться с разработчиком и
корректироваться, уточняться
Определяет свойство системы, нужное
пользователям/заказчикам
Позволяет оценить трудоемкость
Невелика по объему
Определяет свойство системы, которое
может быть протестировано
16.01.2008 V 2.021 39
41. Важность тестов
• «Рассказы» должны формулироваться так, чтобы
соответствующие возможности системы могли быть
протестированы
• При невозможности тестирования невозможно
определить окончание разработки
• По возможности, тесты должны быть
автоматизируемыми
– Пример нетестируемой «хотелки»: Пользователь не
должен слишком долго ждать появления диалогового окна.
– Более корректно:
Новое окно появляется в течение 2 секунд в 95% случаев
16.01.2008 V 2.021 41
42. Зачем нужен бэклог?
• Бэклог – это форма
записи требований
– Без бэклога нельзя
сделать Заказчика
счастливым
• Бэклог – это форма
коммуникации
– Если бэклог непонятен
Заказчику –
коммуникация не
состоялась
16.01.2008 V 2.021 42
43. «Хотелка» в бэклоге
ID Название Формулировка Источ Тест № Кто Оценка
ник
56 Hot keys в Должна быть ALVO СоAgileанить 5 SEGI 2
форме «Заказ» возможность заказ F2,
выполнить все Перейти к
следующему
действия по
полю – Tab,
вводу нового Ctrl-Enter -
заказа сохранить и
посредством отправить
клавиатуры, заказ в
без участия работу?
мыши. Escape -
выход без
сохранения
заказа (с
подтвержден
ием)
29.10.2007 V 2.021 43
44. Бэклог продукта
«Хотелки»+ оценки
Оценка: 4 часа Заказчик
Scrum Master Оценка: 2 часа
1. «Принесет нам миллион»
Оценка: 0,5 часа
2. «Сэкономит нам миллион»
Оценка: 0,25 часа
3. «Даст 100 новых клиентов»
Оценка: 8 часов
Бэклог спринта
Оценка: 16 часов
Оценка: 1 час
...
Программист
Итого:
100 000 часов
46. Преимущества
• Переработаем до
приемлемого вида очень
быстро
• Изменения стоят копейки
• Разберемся в деталях
• Точно поставим задачу и
программист поймет ее
правильно
• Получим удобную Программу
с первого раза
47. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
48. Бэклог продукта
«Хотелки»+ оценки
Оценка: 4 часа Заказчик
Scrum Master Оценка: 2 часа
1. «Принесет нам миллион»
Оценка: 0,5 часа
2. «Сэкономит нам миллион»
Оценка: 0,25 часа
3. «Даст 100 новых клиентов»
Оценка: 8 часов
Бэклог спринта
Оценка: 16 часов
Оценка: 1 час
...
Программист
Итого:
100 000 часов
49. Вспоминаем почему так:
• Мастер ($100/день) делает 1 кресло в день
• Нам нужно 1 кресло (у нас есть день и $100)
Задачи Люди
Время
50. Процесс оценки
• Оценка «в пингвинах»
– Выбираем эталон в 5 пингвинов
– Оцениваем все «хотелки» сравнивая с эталоном
– Отталкиваясь от известного «быстродействия»
отбираем нужное количество «хотелок»
• Оценка «в часах»
– Знаем емкость команды в часах (160 * N человек)
– Оцениваем каждую задачу в часах
– Отнимаем от общей емкости команды оценки до тех
пор, пока не получится ноль
16.01.2008 V 2.021 50
51. «Плэннинг покер»
1. Все смотрят на эталон
2. Заказчик объясняет новую
«хотелку»
3. Все выбрасывают по карте
Эталон
4. Оценка совпала – вписываем
5. Оценка сильно не не совпала:
1. Высказывается поставивший
самую маленькую оценку
2. Высказывается поставивший
самую высокую оценку
3. Просим пояснений у Заказчика
Обсуждаем
6. GO TO 4
16.01.2008 V 2.021 51
53. Оценка в часах
• Чем меньше задача – тем
точнее оценка
– Разбивайте большие
«хотелки» на меньшие
– Для каждой «хотелки»
расписывайте набор задач
– Оценивайте каждую задачу
– Оценивает тот, кто будет
делать задачу
29.10.2007 V 2.021 53
54. «Хотелка» и «задача»
Задача №00234
• «Парни, я хочу хранить для участка
информацию о том, какие конкретно ПИ
там живут!»
55. Балансируем треугольник
Быстройдествие = 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 55
56. Роли в Agile
Тестер
– Пишет и прогоняет тесты
– Оформляет результаты так, чтобы всем было
понятно
Пессимист
– Напоминает всем по риски
– Следит, чтобы мы не принимали желаемое за
действительное
16.01.2008 V 2.021 56
57. Преимущества
• То, что реально важно,
всегда делается
• Скорость – очень высокая
• Это происходит из-за
высокой эффективности
работы, а не за счет
качества
• Себестоимость при этом
получается - ниже
58. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
60. Definition Of Done
• Story сделан
– Код в SVN, с комментарием
– Юнит-тест в проекте
– Юнит-тесты проекта прошли
– Глупых ошибок на UI нет
• Story закрывает тот, кто его открыл
– Если он недоволен по любой причине – он не
закрывает кейс
– Daily Scrum: 10:00, 75-4
SEADMEX
61. Происходит работа...
• Daily Scrum
• Программисты делают
сессии по дизайну
• Пишут вместе тесты
• Потом код
• Юнит-тесты проверяют их
работоспособность
• Программа сборки делает из
него билды
• Тестеры тестируют билды
заглядывая в список What’s
New
• До тех пор, пока не сделаны
все «хотелки» итерации
63. Роли в Agile
Трэкер
– Собирает со всех информацию об успехах
– При необходимости зовет на помощь Тренера
или другого разработчика
Тренер
– Наблюдает и дает советы
– В явном виде помогает
– «Свертывает газету» при необходимости
16.01.2008 V 2.021 63
67. «Хотелка» для обсуждения
• User Stories не считаются «высеченными в камне». Детали
«хотелок» могут и должны обсуждаться между заказчиком и
разработчиком.
– Правильнее считать «хотелки» напоминанием
• В момент начала работы над «рассказом» разработчик
уточняет у заказчика необходимые подробности
http://www.seadmex.ru/custo
SEADMEX
mers/ibs
68. Постоянная интеграция
Компилируется
проект
Разработчик
делает коммит Запускаются
юнит-тесты
Результаты Запуск процедуры
Билд
появляются в развертывания и
успешен -
дашборде обновления
Приложение и база
обновлены
16.01.2008 V 2.021 68
69. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
70. Имплементация story
Программист Задачи по исправлению ошибок
Тестовые примеры
Заказчик
Список выполненных задач +
Тестер
Тестовые данные
результирующая программа
Надежная программа
71. Тестовые сценарии
• Тестовый пример: Ввести номенклатуру
изделия, Программа пишет расшифровку кода
номенклатуры, при этом обрабатывает
несуществующие коды и замены.
• Проверить с тестовыми данными:
– 005Е6789: «немыслимый шаровой клапан»
– 005N0000: «код не существует»
– 005Т0098: «снят с производства, возможна замена
на 005T0198»
72. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
73. Исправление ошибок
• Ошибки сделанные программистом
– НИКОГДА Заказик не платит за исправление
ошибок, которые сделал наши программисты
• Ошибки как следствие новых Задач
– ВСЕГДА платит за исправление ошибок,
внесенных измененными иили
противоречивыми, новыми, неправильно
сформулированными «хотелками»
74. Преимущества
• Менеджер и Заказчик думают
о том, как должно работать
правильно
• Тестер думает о том, что
может работать неправильно
• Тестер думает заранее
• Как следствие Программа
(почти) всегда работает как
надо
75. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
78. Преимущества
• Всегда есть версия
программы, которая
работает
• Тестирование любой
степени извращенности не
ломает рабочую версию
программы
79. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
81. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
82. Мы рекомендуем
• Собрать набор пожеланий по итогам
просмотра в виде «хотелок»
• Реализовывать только самые необходимые
новые «хотелки»
• (При необходимости с них можно начать
следующую итерацию)
85. По шагам
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
86. Преимущества
• Нет вероятности
«передалать» работающую
программу в неработающую
• Работающая программа будет
установлена на сервер и будет
работать (и приносить деньги)
• В это время будут делаться
переделки, новые «хотелки» и
т.д.
87. Итого
• Спринт устроен очень просто
Администраторы
Пользователи пишут Заказчики
устанавливают
«хотелки» и тесты удостоверяются, что
программу на
для них программа работает
сервер
Заказчик выбирает
из длинного списка Программисты Заказчики пишут
короткий - «сделать исправляют ошибки новые требования
в эту итерацию»
Тестеры проверяют
Программисты
наличие ошибок и
пишут программу [Новая итерация]
сообщают
вместе с Заказчиком
программистам
16.01.2008 V 2.021 87
89. Вырабатываем
«хотелки»
Практика
16.01.2008 V 2.021 89
90. Превосходная «хотелка»
Независима и самодостаточна
Может обсуждаться с разработчиком и
корректироваться, уточняться
Определяет свойство системы, нужное
пользователям/заказчикам
Позволяет оценить трудоемкость
Невелика по объему
Определяет свойство системы, которое
может быть протестировано
16.01.2008 V 2.021 90
91. «Независимость хотелки»
• Следует избегать зависимостей между
«хотелки», насколько это возможно.
• Зависимости порождают проблемы при
определении приоритетов и планировании.
• Как добиваться независимости:
– Объединять «хотелки» в более крупные, но
независимые
– Подбирать разбивку функциональности
системы на независимые «хотелки»
16.01.2008 V 2.021 91
92. «Хотелки»: небольшой объем
• Слишком объемные и слишком маленькие «рассказы»
сложно использовать для планирования
– Объемный «рассказ» может реально включать несколько user stories
• «Правильный» объем зависит от возможностей команды и
применяемых технологий
• Правило: максимальный размер хотелки должен быть
таким, чтобы одна пара разработчиков могла полностью
реализовать его в течение одной итерации.
SEADMEX
93. Небольшой объем «хотелки»
• Слишком объемный «рассказ» обычно является:
– Составным. Представляет собой набор
менее объемных «рассказов».
либо
– Сложным. Действительно большой и не
может быть легко разбит на меньшие
«рассказы».
16.01.2008 V 2.021 93
94. Составная «хотелка» - пример
• Слишком объемная «хотелка»:
– Пользователь может разместить на сайте свое резюме.
• Реально это означает:
± Резюме может включать образование, предыдущие
работы, историю зарплаты, публикации, цель поиска
работы
± Пользователь может пометить резюме как неактивное
± Пользователь может одновременно разместить
несколько своих резюме
± Пользователь может редактировать резюме
± Пользователь может удалить резюме
16.01.2008 V 2.021 94
95. Слишком мелкие «хотелки»
• Например:
– Пользователь может ввести даты начала и
окончания для каждого места работы в резюме
– Пользователь может редактировать даты начала
и окончания для каждого места работы в резюме
– Пользователь может ввести даты начала и
окончания для каждого места учебы в резюме
– Пользователь может ввести даты начала и
окончания для каждого места учебы в резюме
– ...
SEADMEX
96. Сложные «хотелки»
• Сложные «рассказы» действительно велики и
не могут быть легко разбиты на меньшие
«хотелки»
• Можно разбить «рассказ» на следующие
задачи:
1. Исследовательская работа по «хотелке» (в заданных
временных рамках) для оценки трудоемкости
2. Планирование в соответствии с полученной
оценкой и реализация «хотелки»
16.01.2008 V 2.021 96
97. «Хотелки» и ЗаказчикPO
• Официальное правило: пожелания записывает на карточки
заказчик.
• Если заказчик не может или не хочет записывать, вы можете
помочь ему в этом; если записывать пожелания на карточку
будет кто-то другой, заказчик будет чувствовать себя
увереннее.
• В процессе работы заказчик может обрести уверенность и
начать сам записывать «рассказы».
• В любом случае карточки принадлежат заказчику и только
он имеет право формировать «рассказы» либо вносить
изменения.
98. Разработчицкие «хотелки»
Важно только для разработчиков:
1. Все коннекты к БД выполняются только через пул
соединений
2. Вся обработка и протоколирование ошибок реализованы в
специальном наборе классов
Более корректный вариант, понятный Заказчику:
1. С приложением, имеющим лицензию на 5 пользователей
СУБД, должны работать до 15 пользователей.
2. Все ошибки представляются пользователю и
протоколируются единообразно.
16.01.2008 V 2.021 98
99. Метафора
CRM – это система, благодаря
которой ни одно обращение
Заказчиков не остается без ответа
– Все входящие письма на
customer.care@seadmex.ru регистрируются в
системе и не могут остаться без ответа
– Из писем можно создавать «Сделки»
– В сделки вносится ответственный, вероятность,
ожидаемая сумма и т.д.
– У сделок есть история, включая письма, задачи
60 мин и ответственных, встречи в календаре
– Система умеет генерировать отчет «Наш
бизнес», в котором я могу видеть перечень
сделок на месяц, выигранные и проигранные,
что по ним делалось и что запланировано
16.01.2008 V 2.021 99
101. Сейчас мы проделаем 4 спринта
• Я – спонсор Х проектов
– Выберите Product Owner
– Определите кто Scrum Master
– Разбейтесь на команды по
симпатиям
– Заказчики, подходите ко мне за
бэклогом продукта и
90 мин инструктажем
16.01.2008 V 2.021 101
102. Планирование
• Возьмите бэклог продукта
• Произведите оценку (управляет Scrum Master)
• Попробуйте прикинуть свою
производительность (спринт = 10мин)
• Отберите набор «хотелок» на спринт
• Подготовьте бэклог спринта
• По готовности всех команд – начинаем!
16.01.2008 V 2.021 102
103. Конец итерации
• Сообщите мне, какая была рассчетная
производительность
• Теперь посчитайте реальную
производительность
• Ретроспектива – что можно сделать лучше?
• Начинайте новый цикл планирования
16.01.2008 V 2.021 103
104. Выводы
• Какие будут сложности
с использованием
этого подхода в вашей
компании?
16.01.2008 V 2.021 104
106. Причина неудач внедрений
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 106
107. Успешный проект
Чтобы быть успешным, проект должен:
1. Произвести конечный результат (deliverable(s)),
который бы устраивал всех заинтересованных
участников проекта.
2. Закончиться не позже запланированной даты.
3. Остаться при этом в рамках требований качества,
ограничений бюджета и объема работ.
109. Управление проектом
• Управление проектом - это
применение знаний, навыков,
методов, средств и технологий к
проектной деятельности в целях
удовлетворения требований,
достижения или превышения
ожиданий участников проекта, т.е.
обеспечения выполнения работ с
заданным уровнем качества, в
заданный срок и в рамках
выделенных средств.
PM BoK, PMI
110. Scrum Master
• Scrum Master –
человек, полностью
ответственный за успех
или неудачу проекта –
удовлетворение или
превышение ожиданий
всех участников
проекта.
112. Вспоминаем почему так:
• Мастер ($100/день) делает 1 кресло в день
• Нам нужно 1 кресло (у нас есть день и $100)
Задачи Люди = деньги
Время
113. Простые выводы
• Чем мы торгуем?
• Откуда мы узнаем, сколько часов
должно быть продано?
• Что будет, если мы изначально
неправильно определили
количество часов?
• Что будет, если впоследствии
количествотип стульев будет
изменено?
• Что будет, если мастер работает
плохо (по любой причине)?
115. Советы по отбору проектов
• Старайтесь заложить
большую маржу
• Еще лучше – продавайте
проекты с
«помесячной» оплатой
• Проекты с маленькой
маржой должны быть
не просто гибкими, а
супергибкими
29.10.2007 V 2.021 115
117. Не начинайте с инструментов!
• Выберите команду, которая горит
желанием делать Agile
• Соберите всю команду вместе
• Поместите Заказчика рядом
• Внедряйте одну практику за раз
• Внедряйте все практики
16.01.2008 V 2.021 117
118. Внедряйте все практики
«Типа Возможно,
спецификация» «релиз»
Это не Agile!
16.01.2008 V 2.021 118
120. Типичная ситуация
Новая
практика
Удовольствие Непонимание
Освоение Злость
16.01.2008 V 2.021 120
121. Причины недовольства
• Требования без объяснений
• Предыдущий опыт
• Отсутствие мотивации
• Страх изменения
• Страх неудачи
• Синдром «старой собаки»
• Физическоеумственное состояние
16.01.2008 V 2.021 121
122. Коучинг
• В идеале – менеджер:
– Может заменить любого
члена команды
– Может учить по любой
теме
– Готов взять на себя
самую тяжелуюнудную
часть работы
16.01.2008 V 2.021 122
123. Естественный отбор
«Командные
игроки»
«Одиночки»
«Гики»
16.01.2008 V 2.021 123
125. Итого
• Помните, зачем делается проект - деньги
• Agile – это 12* (двенадцать) практик
• Иначе это не Agile
• Не надо перегружать Agile документами, его
прелесть в простоте
• Простота достигается за счет коммуникаций
• Для этого команда и Заказчик должны
работать вместе
• Остальное – (сравнительно) просто
16.01.2008 V 2.021 125
126. Рекомендую к прочтению
• Agile Project
Management with
SCRUM
• (Ken Schwaber)
16.01.2008 V 2.021 126
128. Рефлексия
• Зачем я сюда пришел (пришла)?
– Есть ощущение удовлетворения этой
потребности?
• Что я хочу узнать?
– Получили нужную информацию и источники?
29.10.2007 V 2.021 128