Scrum для практиков

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

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

SEADMEX

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

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

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

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

[email protected]

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

29.10.2007 V 2.021 3

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

16.01.2008 V 2.021 4

Управление ожиданиями

• Agile – это не методология типа RUP, это фрэймворк

• Моя задача – рассказать ЧТО должно быть сделано, КАК вы будете это делать – это ваш выбор

• Я расскажу как МЫ делаем Agile• (Это не значит, что ВЫ будете

делать Agile также)• Я не расскажу вам все в деталях

(но дам доп. Материалы)

Подход к обучению

29.10.2007 V 2.021 6

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

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

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

• Коллег – не перебивать

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

29.10.2007 V 2.021 7

Потенциальные проблемы

• Некоторые слайды «перегружены»

• Говорю слишком быстро или слишком медленно

• Говорю слишком громко или слишком тихо

• Непонятные моменты

• Телефоны и пейджеры

• Просьба о перерыве

Орг. Вопросы

• Туалеты – влево и вниз по лестнице

• Формат работы: 1,5 часа – перерыв Х 4

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

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

16.01.2008 V 2.021 9

Вопрос

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

– Пример: Завтра мне начинать проект по Agile.С чего начать?

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

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

29.10.2007 V 2.021 10

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

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

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

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

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

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

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

Льюис Кэррол

29.10.2007 V 2.021 12

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

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

29.10.2007 V 2.021 13

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

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

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

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

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

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

29.10.2007 V 2.021 14

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

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

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

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

факт

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

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

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

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

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

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

Задачи

Время

Люди

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

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

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

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

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

– DOD-STD (498…)

29.10.2007 V 2.021 17

«Водопад»

(с) Steve McConnel. «Rapid Development»

Концепция

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

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

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

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

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

29.10.2007 V 2.021 18

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

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

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

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

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

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

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

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

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

16.01.2008 V 2.021 20

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

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

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

Время

Ба

ги, н

еуч

тен

ны

е р

иск

и, и

зм

ен

ен

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

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

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

Agile Manifesto

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

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

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

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

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

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

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

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

16.01.2008 V 2.021 23

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

16.01.2008 V 2.021 24

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

Время

Ба

ги, н

еуч

тен

ны

е р

иск

и, и

зм

ен

ен

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

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

Ценности Agile

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

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

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

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

16.01.2008 V 2.021 26

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

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

них

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

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

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

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

Заказчиком

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

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

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

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

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

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

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

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

Итого

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

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

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

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

16.01.2008 V 2.021 28

Сбор – 12:00

29.10.2007 V 2.021 29

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

29.10.2007 V 2.021 30

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

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

для них

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

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

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

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




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

сервер




По шагам


для них









сервер




Роли в Agile

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

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

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

16.01.2008 V 2.021 33

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

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

Заказчик

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

Scrum Master

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

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

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

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

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

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

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

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

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

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

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

Определение user story

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

16.01.2008 V 2.021 36

SEADMEX

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

Суть задачи

Обработка «хотелки»

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

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

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

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

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

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

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

16.01.2008 V 2.021 39

SEADMEX

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

Тест

Тест

Важность тестов• «Рассказы» должны формулироваться так, чтобы

соответствующие возможности системы могли быть протестированы

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

• По возможности, тесты должны быть автоматизируемыми– Пример нетестируемой «хотелки»: Пользователь не

должен слишком долго ждать появления диалогового окна.

– Более корректно:Новое окно появляется в течение 2 секунд в 95% случаев

16.01.2008 V 2.021 41

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

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

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

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

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

16.01.2008 V 2.021 42

«Хотелка» в бэклогеID Название Формулировка Источ

никТест № Кто Оценка

56 Hot keys в форме «Заказ»

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

ALVO СоAgileанитьзаказ F2,Перейти к следующему полю – Tab,Ctrl-Enter -сохранить и отправить заказ в работу?Escape -выход без сохранения заказа (с подтверждением)

5 SEGI 2

29.10.2007 V 2.021 43

Бэклог продукта

Программист

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

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


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


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


Оценка: 1 час

...

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

Заказчик

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

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

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

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

Scrum Master

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

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

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

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

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

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

По шагам


для них









сервер



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

Бэклог продукта


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







Оценка: 1 час

...

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

Заказчик

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

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

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

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

Scrum Master

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

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

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

Задачи

Время

Люди

Процесс оценки

• Оценка «в пингвинах»– Выбираем эталон в 5 пингвинов

– Оцениваем все «хотелки» сравнивая с эталоном

– Отталкиваясь от известного «быстродействия» отбираем нужное количество «хотелок»

• Оценка «в часах»– Знаем емкость команды в часах (160 * N человек)

– Оцениваем каждую задачу в часах

– Отнимаем от общей емкости команды оценки до тех пор, пока не получится ноль

16.01.2008 V 2.021 50

«Плэннинг покер»

1. Все смотрят на эталон

2. Заказчик объясняет новую «хотелку»

3. Все выбрасывают по карте

4. Оценка совпала – вписываем

5. Оценка сильно не не совпала:1. Высказывается поставивший

самую маленькую оценку

2. Высказывается поставивший самую высокую оценку

3. Просим пояснений у Заказчика

6. GO TO 4

16.01.2008 V 2.021 51

Эталон

Обсуждаем

В чем давать оценки?

29.10.2007 V 2.021 52

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

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

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

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

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

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

29.10.2007 V 2.021 53

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

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

Задача №00234

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

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

29.10.2007 V 2.021 55

A (15)

B (10)

C (5)

D (5)

A (15)

B (10)

D (5)

C (5)

A (15)

D (5)

C (5)

E (5)

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

Роли в Agile

Тестер

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

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

Пессимист

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

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

16.01.2008 V 2.021 56


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

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

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

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

По шагам


для них









сервер




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

16.01.2008 V 2.021 59

Definition Of Done

• Story сделан

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

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

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

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

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

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

– Daily Scrum: 10:00, 75-4

SEADMEX

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

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

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

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

него билды• Тестеры тестируют билды

заглядывая в список What’s New

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

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

16.01.2008 V 2.021 62

Роли в Agile

Трэкер

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

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

Тренер

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

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

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

16.01.2008 V 2.021 63

Scrum!!!

16.01.2008 V 2.021 64

Daily Scrum

16.01.2008 V 2.021 65

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

16.01.2008 V 2.021 66

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

SEADMEX

«Хотелка» для обсуждения• User Stories не считаются «высеченными в камне». Детали

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

• В момент начала работы над «рассказом» разработчик уточняет у заказчика необходимые подробности

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

16.01.2008 V 2.021 68

Разработчик

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

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

проект

Запускаются

юнит-тесты

Результаты

появляются в

дашборде

Билд

успешен -

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

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

обновления

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

обновлены

По шагам


для них









сервер




Имплементация story


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

Тестер

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

Заказчик

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

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

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

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

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

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

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

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

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

По шагам


для них









сервер




Исправление ошибок

• Ошибки сделанные программистом

– НИКОГДА Заказик не платит за исправление ошибок, которые сделал наши программисты

• Ошибки как следствие новых Задач

– ВСЕГДА платит за исправление ошибок, внесенных измененными и\или противоречивыми, новыми, неправильно сформулированными «хотелками»


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

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

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

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

По шагам


для них









сервер




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

Две версии


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

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

По шагам


для них









сервер




Демо

16.01.2008 V 2.021 80

По шагам


для них









сервер




Мы рекомендуем

• Собрать набор пожеланий по итогам просмотра в виде «хотелок»

• Реализовывать только самые необходимые новые «хотелки»

• (При необходимости с них можно начать следующую итерацию)

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

16.01.2008 V 2.021 83

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

16.01.2008 V 2.021 84

По шагам


для них









сервер





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

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

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

Итого

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

16.01.2008 V 2.021 87


для них









сервер




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

29.10.2007 V 2.021 88

Вырабатываем «хотелки»Практика

16.01.2008 V 2.021 89

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

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

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

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

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

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

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

16.01.2008 V 2.021 90

«Независимость хотелки»

• Следует избегать зависимостей между «хотелки», насколько это возможно.

• Зависимости порождают проблемы при определении приоритетов и планировании.

• Как добиваться независимости:

– Объединять «хотелки» в более крупные, но независимые

– Подбирать разбивку функциональности системы на независимые «хотелки»

16.01.2008 V 2.021 91

SEADMEX

«Хотелки»: небольшой объем

• Слишком объемные и слишком маленькие «рассказы» сложно использовать для планирования– Объемный «рассказ» может реально включать несколько user stories

• «Правильный» объем зависит от возможностей команды и применяемых технологий

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

Небольшой объем «хотелки»

• Слишком объемный «рассказ» обычно является:

– Составным. Представляет собой набор менее объемных «рассказов».

либо

– Сложным. Действительно большой и не может быть легко разбит на меньшие «рассказы».

16.01.2008 V 2.021 93

Составная «хотелка» - пример• Слишком объемная «хотелка»:

– Пользователь может разместить на сайте свое резюме.

• Реально это означает:± Резюме может включать образование, предыдущие

работы, историю зарплаты, публикации, цель поиска работы

± Пользователь может пометить резюме как неактивное

± Пользователь может одновременно разместить несколько своих резюме

± Пользователь может редактировать резюме

± Пользователь может удалить резюме

16.01.2008 V 2.021 94

SEADMEX

Слишком мелкие «хотелки»• Например:

– Пользователь может ввести даты начала и окончания для каждого места работы в резюме

– Пользователь может редактировать даты начала и окончания для каждого места работы в резюме

– Пользователь может ввести даты начала и окончания для каждого места учебы в резюме

– Пользователь может ввести даты начала и окончания для каждого места учебы в резюме

– ...

Сложные «хотелки»• Сложные «рассказы» действительно велики и

не могут быть легко разбиты на меньшие «хотелки»

• Можно разбить «рассказ» на следующие задачи:

1. Исследовательская работа по «хотелке» (в заданных временных рамках) для оценки трудоемкости

2. Планирование в соответствии с полученной оценкой и реализация «хотелки»

16.01.2008 V 2.021 96

• Официальное правило: пожелания записывает на карточки заказчик.

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

• В процессе работы заказчик может обрести уверенность и начать сам записывать «рассказы».

• В любом случае карточки принадлежат заказчику и только он имеет право формировать «рассказы» либо вносить изменения.

«Хотелки» и Заказчик\PO

Разработчицкие «хотелки»

Важно только для разработчиков:

1. Все коннекты к БД выполняются только через пул соединений

2. Вся обработка и протоколирование ошибок реализованы в специальном наборе классов

Более корректный вариант, понятный Заказчику:

1. С приложением, имеющим лицензию на 5 пользователей СУБД, должны работать до 15 пользователей.

2. Все ошибки представляются пользователю и протоколируются единообразно.

16.01.2008 V 2.021 98

Метафора

CRM – это система, благодаря которой ни одно обращение Заказчиков не остается без ответа– Все входящие письма на

[email protected] регистрируются в системе и не могут остаться без ответа

– Из писем можно создавать «Сделки»– В сделки вносится ответственный, вероятность,

ожидаемая сумма и т.д.– У сделок есть история, включая письма, задачи

и ответственных, встречи в календаре– Система умеет генерировать отчет «Наш

бизнес», в котором я могу видеть перечень сделок на месяц, выигранные и проигранные, что по ним делалось и что запланировано

16.01.2008 V 2.021 99

60 мин

mailto:[email protected]

4 спринта AgileПрактика

29.10.2007 V 2.021 100

Сейчас мы проделаем 4 спринта • Я – спонсор Х проектов

– Выберите Product Owner

– Определите кто Scrum Master

– Разбейтесь на команды по симпатиям

– Заказчики, подходите ко мне за бэклогом продукта и инструктажем

16.01.2008 V 2.021 101

90 мин

Планирование

• Возьмите бэклог продукта

• Произведите оценку (управляет Scrum Master)

• Попробуйте прикинуть свою производительность (спринт = 10мин)

• Отберите набор «хотелок» на спринт

• Подготовьте бэклог спринта

• По готовности всех команд – начинаем!

16.01.2008 V 2.021 102

Конец итерации

• Сообщите мне, какая была рассчетнаяпроизводительность

• Теперь посчитайте реальную производительность

• Ретроспектива – что можно сделать лучше?

• Начинайте новый цикл планирования

16.01.2008 V 2.021 103

Выводы

•Какие будут сложности с использованием этого подхода в вашей компании?

16.01.2008 V 2.021 104

И что дальше?Лекция 4

29.10.2007 V 2.021 105

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

16.01.2008 V 2.021 106

Цели

бизнеса

Цели

внедрения

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

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

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

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

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

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

Проектная деятельность

• (Задача: заработать деньги)

Проект, duration \ work

Revenue, $

deliverable

Управление проектом

• Управление проектом - это

применение знаний, навыков,

методов, средств и технологий к

проектной деятельности в целях

удовлетворения требований,

достижения или превышения

ожиданий участников проекта, т.е.

обеспечения выполнения работ с

заданным уровнем качества, в

заданный срок и в рамках

выделенных средств.

PM BoK, PMI

Scrum Master

• Scrum Master –

человек, полностью

ответственный за успех

или неудачу проекта –

удовлетворение или

превышение ожиданий

всех участников

проекта.

Не так быстро

Revenue, $Cost, $

Profit, $

Задачи

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

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

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

Задачи

Время

Люди = деньги

Простые выводы

• Чем мы торгуем?• Откуда мы узнаем, сколько часов

должно быть продано?• Что будет, если мы изначально

неправильно определили количество часов?

• Что будет, если впоследствии количество\тип стульев будет изменено?

• Что будет, если мастер работает плохо (по любой причине)?

Проблема Agile

16.01.2008 V 2.021 114

Revenue, $

Sprint = Cost, $

Profit, $

Задачи = ?Sprint = Cost, $Sprint = Cost, $Sprint = Cost, $Sprint = Cost, $

Sprint = Cost, $

Советы по отбору проектов

• Старайтесь заложить большую маржу

• Еще лучше – продавайте проекты с «помесячной» оплатой

• Проекты с маленькой маржой должны быть не просто гибкими, а супергибкими

29.10.2007 V 2.021 115

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

29.10.2007 V 2.021 116

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

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

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

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

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

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

16.01.2008 V 2.021 117

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

16.01.2008 V 2.021 118

«Типа

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

Возможно,

«релиз»

Это не Agile!

Проблемы с Заказчиком

16.01.2008 V 2.021 119

Skype + SharedView

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

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

Непонимание

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

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

16.01.2008 V 2.021 120

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

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

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

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

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

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

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

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

16.01.2008 V 2.021 121

Коучинг

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

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

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

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

16.01.2008 V 2.021 122

Естественный отбор

«Гики»

«Одиночки»

«Командные игроки»

16.01.2008 V 2.021 123

Средства автоматизации

16.01.2008 V 2.021 124

Итого

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

• Agile – это 12* (двенадцать) практик

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

• Не надо перегружать Agile документами, его прелесть в простоте

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

• Для этого команда и Заказчик должны работать вместе

• Остальное – (сравнительно) просто

16.01.2008 V 2.021 125

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

• Agile Project Management with SCRUM

• (Ken Schwaber)

16.01.2008 V 2.021 126

29.10.2007 V 2.021 127

Audaces fortuna juvat!

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

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

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

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

29.10.2007 V 2.021 128

Technology

Scrum для практиков