SCRUM for Practitioners

Давайте знакомитьсяhttp://www.seadmex.ru/customers/epamSEADMEXДенис ПетелинУспел попробовать себя во всех ролях софтверных проектов –от разработчика до владельца компании и Заказчика.Поскольку во всех ролях работал успешно, то имею востребованный опыт, который передаю другим.В последнее время все больше выступаю в роли Заказчика, где применяю изученные у Заказчиков грязные трюки Denis_petelin@epam.comОкей, мы все через это прошли29.10.2007V 2.0213История создания тренинга16.01.2008V 2.0214Управление ожиданиями•Agile–это не методология типа RUP, это фрэймворк•Моя задача –рассказать ЧТО должно быть сделано, КАК вы будете это делать –это ваш выбор•Я расскажу как МЫ делаем Agile•(Это не значит, что ВЫ будете делать Agileтакже)•Я не расскажу вам все в деталях (но дам доп. Материалы)Подход к обучению29.10.2007V 2.0216Рабочие соглашения•Сотовые –выключить•Почту –не читать•Коллег –не перебивать•Говорить –строго по одному29.10.2007V 2.0217Потенциальные проблемы • Некоторые слайды «перегружены» • Говорю слишком быстро или слишком медленно • Говорю слишком громко или слишком тихо • Непонятные моменты • Телефоны и пейджеры • Просьба о перерывеОрг. Вопросы•Туалеты –влево и вниз по лестнице•Формат работы: 1,5 часа –перерыв Х 4•Вопросы –задавать любые, даже не по теме тренинга•Материалы –будут выложены на Office Live16.01.2008V 2.0219Вопрос•Зачем я сюда пришел (пришла)?–Пример: Завтра мне начинать проект по Agile.С чего начать?•Что я хочу узнать?–Пример: Хочу чтоб в голове сложилось последовательность действий менеджера, устанавливающего Agileна проекте.29.10.2007V 2.02110Почему Agile?Лекция 1Начнем –с началаАлиса: «Не подскажете, каким путем мне идти, чтобы отсюда выбраться?»Кот: «Ну, это в значительной степени определяется тем, куда вы хотите попасть.»Алиса: «Мне, в общем-то, все равно...»Кот: «Тогда не имеет никакого значения, каким путем идти.»Алиса в Зазеркалье,Льюис Кэррол29.10.2007V 2.02112Что такое проект?Проект–уникальный набор скоординированных действий, имеющий начальную и конечную точки, направленный на получение определенного конечного результата в рамках ограничений времени, цены, качества и объема работ. 29.10.2007V 2.02113Успешный проект•Проект–уникальный набор скоординированных действий, имеющий начальную и конечную точки, направленный на получение определенного конечного результата в рамках ограничений времени, цены, качества и объема работ. Чтобы быть успешным, проект должен:1.Произвести конечный результат (решить задачу), который бы устраивал всех заинтересованных участников проекта.2.Закончиться не позже запланированной даты (вовремя).3.Остаться при этом в рамках требований качества, ограничений бюджета и объема работ.29.10.2007V 2.02114Измерения успешности•Набор основных измерений–Требования (Scope)•Запланировано = реализовано•Заказчик доволен–График (Schedule)•Продолжительность план = продолжительность факт–Бюджет(Budget)•Трудозатраты план = трудозатраты факт•Бюджет план = бюджет факт–Качество(Quality)•Покрытие тестами ~100%•«Критический\серьезный» дефекты = 0Проектный треугольник • Мастер ($100/день) делает 1 кресло в день • Нам нужно 1 кресло (у нас есть день и $100) • Нет заноз и кресло не разваливается Задачи Время Люди«Почему у нас никак не получается?!!»•«Потому что строем не ходите!»–делали вещи посложнее–невероятные требования к надежности–сроки выдерживали•Потому что методология!–MIL-STD (2167…)–DOD-STD (498…)29.10.2007V 2.02117«Водопад»(с) Steve McConnel. «Rapid Development»КонцепцияСбор ТребованийРазработка АрхитектурыПроработка АрхитектурыКодирование и отладкаТестирование29.10.2007V 2.02118Никогда в жизни не сработает!Как следствие•Наблюдения за 3 года:–Средняя задержка –20%–Среднее превышение бюджета –30%–Сделано больше чем планировалось–Заказчик все равно недоволен–Качество сделанного ПО оставляет желать лучшего–Разработчики еще почему-то ругают руководство и Заказчика16.01.2008V 2.02120«Мы совсем неплохо оцениваем»«Большинство руководителей проектов по созданию ПО проделывают приемлемую работу по предсказанию задач, которые должны быть выполнены, и слабую работу по предсказанию задач, которые может потребоваться выполнить.»Том де Марко. «Вальсируя с медведями»ВремяБаги, неучтенные риски, измененияРелизбилдбилдбилдбилд«Предел возможностей»«Большойвзрыв»Agile Manifesto•Нужды Заказчика –прежде всего•Требования должныменяться•Разработчики и Заказчик работают вместе•Релизы должны происходить часто•Коммуникации –лучшая документация•Команда –основная ценность•Совершенство заключается в простоте•Постоянно стремиться сделать для Заказчика больше16.01.2008V 2.02123Agile-фрэймворки16.01.2008V 2.02124Смысл один и тот жеВремяБаги, неучтенные риски, измененияРелизбилдбилдбилдбилд«Предел возможностей»Ценности Agile•Коммуникациивместо длинных контрактов•Рабочий софт вместо длинных спек•Ответ на изменение вместо следования плану•Храбрость и принятие ответственности16.01.2008V 2.02126Как устроенAgile-проект?Пользователи пишут «хотелки» и тесты для нихЗаказчик выбирает из длинного списка короткий -«сделать в эту итерацию»Программисты пишут программу вместе с Заказчиком, консультируясь с ЗаказчикомТестеры проверяют наличие ошибок и сообщают программистамПрограммисты исправляют ошибкиАдминистраторы устанавливают программу на серверЗаказчики удостоверяются, что программа работаетЗаказчики пишут новые требования[Переходим в начало]Итого•Agile–не «процесс», а набор ценностей•Agileиспользует старые добрые проверенные временем практики•Agileпредлагает сокращать длину итерации •+ гибкость в принятии изменений, что приятно и Заказчику, и Разработчикам16.01.2008V 2.02128Сбор –12:0029.10.2007V 2.02129Один спринт из жизни AgileЛекция 229.10.2007V 2.02130Как устроен проект?Пользователи пишут «хотелки» и тесты для нихЗаказчик выбирает из длинного списка короткий -«сделать в эту итерацию»Программисты пишут программу вместе с ЗаказчикомТестеры проверяют наличие ошибок и сообщают программистамПрограммисты исправляют ошибкиАдминистраторы устанавливают программу на серверЗаказчики удостоверяются, что программа работаетЗаказчики пишут новые требования[Переходим в начало]По шагамПользователи пишут «хотелки» и тесты для нихЗаказчик выбирает из длинного списка короткий -«сделать в эту итерацию»Программисты пишут программу вместе с ЗаказчикомТестеры проверяют наличие ошибок и сообщают программистамПрограммисты исправляют ошибкиАдминистраторы устанавливают программу на серверЗаказчики удостоверяются, что программа работаетЗаказчики пишут новые требования[Переходим в начало]Роли в AgileЗаказчик(Product Owner)–Пишет «хотелки», тесты и примеры к ним–Объясняет «хотелки» и расставляет приоритеты–Общается с пользователями–Решает, что важно и что нетРазработчик–Определяет задачи для реализации «хотелки»–Дает оценки объема работ–Реализует в коде «хотелки» и юнит-тесты к нимScrum Master–Собирает и контролирует встречи–Информирует Спонсора–Платит за пиццу–Убирает препятствия (Impediments)16.01.2008V 2.02133С чего все начинается?ПользователиЗаказчик«хотелки» пользователейScrum MasterЗадачи программистамЗаказчик (Product Owner)1.Собирает информацию от всех2.Отсекает явно ненужное3.Утверждает «хотелки»Scrum Master:1.Поддерживает список «хотелок»2.Управляет обсуждением и процессом оценки3.Не оцениваетРабота с ЗаказикомСколько времени займет дорисовать кнопку?(Сколько это будет стоить?)Определение user story«Хотелка» –это наиболее простая формулировка, позволяющая всем присутствующим согласиться с тем, что существует нечто, что необходимо сделать в рамках проекта.16.01.2008V 2.02136SEADMEXStorycard–Лицевая сторонаIDСуть задачиОбработка «хотелки»Превосходная «хотелка»Независима и самодостаточнаМожет обсуждаться с разработчиком и корректироваться, уточнятьсяОпределяет свойство системы, нужное пользователям/заказчикамПозволяет оценить трудоемкостьНевелика по объемуОпределяет свойство системы, которое может быть протестировано16.01.2008V 2.02139SEADMEXStorycard–Оборотная сторонаТестТестВажность тестов•«Рассказы» должны формулироваться так, чтобы соответствующие возможности системы могли быть протестированы•При невозможности тестирования невозможно определить окончание разработки•По возможности, тесты должны быть автоматизируемыми–Пример нетестируемой«хотелки»: Пользователь не должен слишком долго ждать появления диалогового окна.–Более корректно:Новое окно появляется в течение 2 секунд в 95% случаев16.01.2008V 2.02141Зачем нужен бэклог?•Бэклог–это форма записи требований–Без бэклоганельзя сделать Заказчика счастливым•Бэклог–это форма коммуникации–Если бэклогнепонятен Заказчику –коммуникация не состоялась16.01.2008V 2.02142«Хотелка» в бэклогеIDНазваниеФормулировкаИсточникТест№КтоОценка56Hotkeys в форме «Заказ»Должна быть возможность выполнить все действия по вводу нового заказа посредством клавиатуры, без участия мыши. ALVOСоAgileанитьзаказ F2,Перейти к следующему полю –Tab,Ctrl-Enter -сохранить и отправить заказ в работу?Escape -выход без сохранения заказа (с подтверждением) 5SEGI229.10.2007V 2.02143Бэклог продуктаПрограммист«Хотелки»+ оценкиОценка: 4 часаОценка: 2 часаОценка: 0,5 часаОценка: 0,25 часаОценка: 8 часовОценка: 16 часовОценка: 1 час...Итого: 100 000 часовЗаказчикБэклог спринта1. «Принесет нам миллион»2. «Сэкономит нам миллион»3. «Даст 100 новых клиентов»Scrum MasterОпределяем порядокПреимущества•Переработаем до приемлемого вида очень быстро•Изменения стоят копейки•Разберемся в деталях•Точно поставим задачу и программист поймет ее правильно•Получим удобную Программу с первого разаПо шагамПользователи пишут «хотелки» и тесты для нихЗаказчик выбирает из длинного списка короткий -«сделать в эту итерацию»Программисты пишут программу вместе с ЗаказчикомТестеры проверяют наличие ошибок и сообщают программистамПрограммисты исправляют ошибкиАдминистраторы устанавливают программу на серверЗаказчики удостоверяются, что программа работаетЗаказчики пишут новые требования[Новая итерация]Бэклог продуктаПрограммист«Хотелки»+ оценкиОценка: 4 часаОценка: 2 часаОценка: 0,5 часаОценка: 0,25 часаОценка: 8 часовОценка: 16 часовОценка: 1 час...Итого: 100 000 часовЗаказчикБэклог спринта1. «Принесет нам миллион»2. «Сэкономит нам миллион»3. «Даст 100 новых клиентов»Scrum MasterВспоминаем почему так: • Мастер ($100/день) делает 1 кресло в день • Нам нужно 1 кресло (у нас есть день и $100) Задачи Время ЛюдиПроцесс оценки•Оценка «в пингвинах»–Выбираем эталон в 5 пингвинов–Оцениваем все «хотелки» сравнивая с эталоном–Отталкиваясь от известного «быстродействия» отбираем нужное количество «хотелок»•Оценка «в часах»–Знаем емкость команды в часах (160 * N человек)–Оцениваем каждую задачу в часах–Отнимаем от общей емкости команды оценки до тех пор, пока не получится ноль16.01.2008V 2.02150«Плэннинг покер»1.Все смотрят на эталон2.Заказчик объясняет новую «хотелку»3.Все выбрасывают по карте4.Оценка совпала –вписываем5.Оценка сильно не не совпала:1.Высказывается поставивший самую маленькую оценку2.Высказывается поставивший самую высокую оценку3.Просим пояснений у Заказчика6.GO TO 416.01.2008V 2.02151ЭталонОбсуждаемВ чем давать оценки?29.10.2007V 2.02152Оценка в часах•Чем меньше задача –тем точнее оценка–Разбивайте большие «хотелки» на меньшие–Для каждой «хотелки» расписывайте набор задач–Оценивайте каждую задачу–Оценивает тот, кто будет делать задачу29.10.2007V 2.02153«Хотелка» и «задача»•«Парни, я хочу хранить для участка информацию о том, какие конкретно ПИ там живут!»Задача №00234Быстройдествие= 30Балансируем треугольникБыстройдествие= 3029.10.2007V 2.02155A (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.2008V 2.02156Преимущества•То, что реально важно, всегда делается•Скорость –очень высокая•Это происходит из-за высокой эффективности работы, а не за счет качества•Себестоимость при этом получается -нижеПо шагамПользователи пишут «хотелки» и тесты для нихЗаказчик выбирает из длинного списка короткий -«сделать в эту итерацию»Программисты пишут программу вместе с ЗаказчикомТестеры проверяют наличие ошибок и сообщают программистамПрограммисты исправляют ошибкиАдминистраторы устанавливают программу на серверЗаказчики удостоверяются, что программа работаетЗаказчики пишут новые требования[Новая итерация]Где же менеджер???16.01.2008V 2.02159Definition Of Done•Storyсделан–Код в SVN, с комментарием–Юнит-теств проекте–Юнит-тестыпроекта прошли–Глупых ошибок на UI нет•Storyзакрывает тот, кто его открыл–Если он недоволен по любой причине –он не закрывает кейс–Daily Scrum: 10:00, 75-4SEADMEXПроисходит работа...•Daily Scrum•Программисты делают сессии по дизайну•Пишут вместе тесты•Потом код•Юнит-тесты проверяют их работоспособность•Программа сборки делает из него билды•Тестеры тестируют билды заглядывая в список What’s New•До тех пор, пока не сделаны все «хотелки» итерацииTask Board и его чтение16.01.2008V 2.02162Роли в AgileТрэкер–Собирает со всех информацию об успехах–При необходимости зовет на помощь Тренера или другого разработчикаТренер–Наблюдает и дает советы–В явном виде помогает–«Свертывает газету» при необходимости16.01.2008V 2.02163Scrum!!!16.01.2008V 2.02164Daily Scrum16.01.2008V 2.02165Трэкер и «прозрачность»16.01.2008V 2.02166http://www.seadmex.ru/customers/ibsSEADMEX«Хотелка» для обсуждения•User Storiesне считаются «высеченными в камне». Детали «хотелок» могут и должны обсуждаться между заказчиком и разработчиком.–Правильнее считать «хотелки» напоминанием•В момент начала работы над «рассказом» разработчик уточняет у заказчика необходимые подробностиПостоянная интеграция16.01.2008V 2.02168Разработчик делает коммитКомпилируется проектЗапускаются юнит-тестыРезультаты появляются в дашбордеБилд успешен -Запуск процедуры развертывания и обновленияПриложение и база обновленыПо шагамПользователи пишут «хотелки» и тесты для нихЗаказчик выбирает из длинного списка короткий -«сделать в эту итерацию»Программисты пишут программу вместе с ЗаказчикомТестеры проверяют наличие ошибок и сообщают программистамПрограммисты исправляют ошибкиАдминистраторы устанавливают программу на серверЗаказчики удостоверяются, что программа работаетЗаказчики пишут новые требования[Новая итерация]Имплементация storyПрограммистСписок выполненных задач+ результирующая программаТестерЗадачи по исправлению ошибокЗаказчикТестовые данныеНадежная программаТестовые примерыТестовые сценарии•Тестовый пример: Ввести номенклатуру изделия, Программа пишет расшифровку кода номенклатуры, при этом обрабатывает несуществующие коды и замены.•Проверить с тестовыми данными:–005Е6789: «немыслимый шаровой клапан»–005N0000: «код не существует»–005Т0098: «снят с производства, возможна замена на 005T0198»По шагамПользователи пишут «хотелки» и тесты для нихЗаказчик выбирает из длинного списка короткий -«сделать в эту итерацию»Программисты пишут программу вместе с ЗаказчикомТестеры проверяют наличие ошибок и сообщают программистамПрограммисты исправляют ошибкиАдминистраторы устанавливают программу на серверЗаказчики удостоверяются, что программа работаетЗаказчики пишут новые требования[Новая итерация]Исправление ошибок•Ошибки сделанные программистом–НИКОГДАЗаказик не платит за исправление ошибок, которые сделал наши программисты•Ошибки как следствие новых Задач–ВСЕГДА платит за исправление ошибок, внесенных измененными и\или противоречивыми,новыми, неправильно сформулированными «хотелками»Преимущества•Менеджер и Заказчик думают о том, как должно работать правильно•Тестер думает о том, чтоможет работать неправильно•Тестер думает заранее•Как следствие Программа (почти) всегда работает как надоПо шагамПользователи пишут «хотелки» и тесты для нихЗаказчик выбирает из длинного списка короткий -«сделать в эту итерацию»Программисты пишут программу вместе с ЗаказчикомТестеры проверяют наличие ошибок и сообщают программистамПрограммисты исправляют ошибкиАдминистраторы устанавливают программу на серверЗаказчики удостоверяются, что программа работаетЗаказчики пишут новые требования[Новая итерация]Установка программыДве версииПреимущества•Всегда есть версия программы, которая работает•Тестирование любой степени извращенности не ломает рабочую версию программыПо шагамПользователи пишут «хотелки» и тесты для нихЗаказчик выбирает из длинного списка короткий -«сделать в эту итерацию»Программисты пишут программу вместе с ЗаказчикомТестеры проверяют наличие ошибок и сообщают программистамПрограммисты исправляют ошибкиАдминистраторы устанавливают программу на серверЗаказчики удостоверяются, что программа работаетЗаказчики пишут новые требования[Новая итерация]Демо16.01.2008V 2.02180По шагамПользователи пишут «хотелки» и тесты для нихЗаказчик выбирает из длинного списка короткий -«сделать в эту итерацию»Программисты пишут программу вместе с ЗаказчикомТестеры проверяют наличие ошибок и сообщают программистамПрограммисты исправляют ошибкиАдминистраторы устанавливают программу на серверЗаказчики удостоверяются, что программа работаетЗаказчики пишут новые требования[Новая итерация]Мы рекомендуем•Собрать набор пожеланий по итогам просмотра в виде «хотелок»•Реализовывать только самые необходимые новые «хотелки»•(При необходимости с них можно начать следующую итерацию) Анализ причин и следствий16.01.2008V 2.02183Ретроспектива & Бэклогпрепятствий16.01.2008V 2.02184По шагамПользователи пишут «хотелки» и тесты для нихЗаказчик выбирает из длинного списка короткий -«сделать в эту итерацию»Программисты пишут программу вместе с ЗаказчикомТестеры проверяют наличие ошибок и сообщают программистамПрограммисты исправляют ошибкиАдминистраторы устанавливают программу на серверЗаказчики удостоверяются, что программа работаетЗаказчики пишут новые требования[Новая итерация]Преимущества•Нет вероятности «передалать» работающую программу в неработающую•Работающая программа будет установлена на сервер и будет работать (и приносить деньги)•В это время будут делаться переделки, новые «хотелки» и т.д.Итого•Спринт устроен очень просто16.01.2008V 2.02187Пользователи пишут «хотелки» и тесты для нихЗаказчик выбирает из длинного списка короткий -«сделать в эту итерацию»Программисты пишут программу вместе с ЗаказчикомТестеры проверяют наличие ошибок и сообщают программистамПрограммисты исправляют ошибкиАдминистраторы устанавливают программу на серверЗаказчики удостоверяются, что программа работаетЗаказчики пишут новые требования[Новая итерация]Перерыв –60 минут29.10.2007V 2.02188Вырабатываем «хотелки»Практика16.01.2008V 2.02189Превосходная «хотелка»Независима и самодостаточнаМожет обсуждаться с разработчиком и корректироваться, уточнятьсяОпределяет свойство системы, нужное пользователям/заказчикамПозволяет оценить трудоемкостьНевелика по объемуОпределяет свойство системы, которое может быть протестировано16.01.2008V 2.02190«Независимость хотелки»•Следует избегать зависимостей между «хотелки», насколько это возможно. •Зависимости порождают проблемы при определении приоритетов и планировании.•Как добиваться независимости:–Объединять «хотелки» в более крупные, но независимые–Подбирать разбивку функциональности системы на независимые «хотелки» 16.01.2008V 2.02191SEADMEX«Хотелки»: небольшой объем•Слишком объемные и слишком маленькие «рассказы» сложно использовать для планирования–Объемный «рассказ» может реально включать несколько user stories•«Правильный» объем зависит от возможностей команды и применяемых технологий•Правило: максимальный размер хотелки должен быть таким, чтобы одна пара разработчиков могла полностью реализовать его в течение одной итерации.Небольшой объем «хотелки»•Слишком объемный «рассказ» обычно является:–Составным. Представляет собой набор менее объемных «рассказов».либо–Сложным. Действительно большой и не может быть легко разбит на меньшие «рассказы».16.01.2008V 2.02193Составная«хотелка» -пример•Слишком объемная «хотелка»:–Пользователь может разместить на сайте свое резюме.•Реально это означает:±Резюме может включать образование, предыдущие работы, историю зарплаты, публикации, цель поиска работы±Пользователь может пометить резюме как неактивное±Пользователь может одновременно разместить несколько своих резюме±Пользователь может редактировать резюме±Пользователь может удалить резюме16.01.2008V 2.02194SEADMEXСлишком мелкие «хотелки»•Например:–Пользователь может ввести даты начала и окончания для каждого места работы в резюме –Пользователь может редактировать даты начала и окончания для каждого места работы в резюме–Пользователь может ввести даты начала и окончания для каждого места учебы в резюме–Пользователь может ввести даты начала и окончания для каждого места учебы в резюме–...Сложные «хотелки»•Сложные «рассказы» действительно велики и не могут быть легко разбиты на меньшие «хотелки»•Можно разбить «рассказ» на следующие задачи:1.Исследовательская работа по «хотелке» (в заданных временных рамках) для оценки трудоемкости2.Планирование в соответствии с полученной оценкой и реализация «хотелки»16.01.2008V 2.02196•Официальное правило: пожелания записывает на карточки заказчик.•Если заказчик не может или не хочет записывать, вы можете помочь ему в этом; если записывать пожелания на карточку будет кто-то другой, заказчик будет чувствовать себя увереннее.•В процессе работы заказчик может обрести уверенность и начать сам записывать «рассказы».•В любом случае карточки принадлежат заказчикуи только он имеет право формировать «рассказы» либо вносить изменения.«Хотелки» и Заказчик\POРазработчицкие «хотелки»Важно только для разработчиков:1.Все коннекты к БД выполняются только через пул соединений2.Вся обработка и протоколирование ошибок реализованы в специальном наборе классовБолее корректный вариант, понятный Заказчику:1.С приложением, имеющим лицензию на 5 пользователей СУБД, должны работать до 15 пользователей.2.Все ошибки представляются пользователю и протоколируются единообразно.16.01.2008V 2.02198МетафораCRM –это система, благодаря которой ни одно обращение Заказчиков не остается без ответа–Все входящие письма на customer.care@seadmex.ruрегистрируются в системе и не могут остаться без ответа–Из писем можно создавать «Сделки»–В сделки вносится ответственный, вероятность, ожидаемая сумма и т.д.–У сделок есть история, включая письма, задачи и ответственных, встречи в календаре–Система умеет генерировать отчет «Наш бизнес», в котором я могу видеть перечень сделок на месяц, выигранные и проигранные, что по ним делалось и что запланировано16.01.2008V 2.0219960 мин4 спринта AgileПрактика29.10.2007V 2.021100Сейчас мы проделаем 4 спринта •Я –спонсор Х проектов–Выберите Product Owner–Определите кто Scrum Master–Разбейтесь на команды по симпатиям–Заказчики, подходите ко мне за бэклогом продукта и инструктажем 16.01.2008V 2.02110190 минПланирование•Возьмите бэклог продукта•Произведите оценку (управляет Scrum Master)•Попробуйте прикинуть свою производительность (спринт = 10мин)•Отберите набор «хотелок» на спринт•Подготовьте бэклогспринта•По готовности всех команд –начинаем!16.01.2008V 2.021102Конец итерации•Сообщите мне, какая была рассчетнаяпроизводительность•Теперь посчитайте реальную производительность•Ретроспектива –что можно сделать лучше?•Начинайте новый цикл планирования16.01.2008V 2.021103Выводы•Какие будут сложности с использованием этого подхода в вашей компании?16.01.2008V 2.021104И что дальше?Лекция 429.10.2007V 2.021105Причина неудач внедрений16.01.2008V 2.021106Цели бизнесаЦели внедренияAdoption through execution: Project-levelmentoring to improve software capabilityKurt Bittner, Communities of Practice Architect, IBMSaif Islam, Rational Services Manager, IBM20062007Успешный проектЧтобы быть успешным, проект должен:1.Произвести конечный результат (deliverable(s)), который бы устраивал всех заинтересованных участников проекта.2.Закончиться не позже запланированной даты.3.Остаться при этом в рамках требований качества, ограничений бюджета и объема работ.Проектная деятельность•(Задача: заработать деньги)Проект, duration \workRevenue, $deliverableУправление проектом•Управление проектом-это применение знаний, навыков, методов, средств и технологий к проектной деятельности в целях удовлетворения требований, достижения или превышения ожиданий участников проекта, т.е. обеспечения выполнения работ с заданным уровнем качества, в заданный срок и в рамках выделенных средств.PM BoK, PMIScrum Master•Scrum Master–человек, полностью ответственный за успех или неудачу проекта –удовлетворение или превышение ожиданий всех участников проекта.Не так быстроRevenue, $Cost, $Profit, $ЗадачиВспоминаем почему так: • Мастер ($100/день) делает 1 кресло в день • Нам нужно 1 кресло (у нас есть день и $100) Задачи Время Люди = деньгиПростые выводы•Чем мы торгуем?•Откуда мы узнаем, сколько часов должно быть продано?•Что будет, если мы изначально неправильно определили количество часов?•Что будет, если впоследствии количество\тип стульев будет изменено?•Что будет, если мастер работает плохо (по любой причине)?Проблема Agile16.01.2008V 2.021114Revenue, $Sprint = Cost, $Profit, $Задачи = ?Sprint = Cost, $Sprint = Cost, $Sprint = Cost, $Sprint = Cost, $Sprint = Cost, $Советы по отбору проектов•Старайтесь заложить большую маржу•Еще лучше –продавайте проекты с «помесячной» оплатой•Проекты с маленькой маржой должны быть не просто гибкими, а супергибкими29.10.2007V 2.021115Из личного опыта29.10.2007V 2.021116Не начинайте с инструментов!•Выберите команду, которая горит желанием делать Agile•Соберите всю команду вместе•Поместите Заказчика рядом•Внедряйте одну практику за раз•Внедряйте всепрактики16.01.2008V 2.021117Внедряйте всепрактики16.01.2008V 2.021118«Типа спецификация»Возможно,«релиз»Это неAgile!Проблемы с Заказчиком16.01.2008V 2.021119Skype + SharedViewТипичная ситуацияНовая практикаНепониманиеЗлостьОсвоениеУдовольствие16.01.2008V 2.021120Причины недовольства•Требования без объяснений•Предыдущий опыт•Отсутствие мотивации•Страх изменения•Страх неудачи•Синдром «старой собаки»•Физическое\умственное состояние16.01.2008V 2.021121Коучинг•В идеале –менеджер:–Может заменить любого члена команды–Может учить по любой теме–Готов взять на себя самую тяжелую\нудную часть работы16.01.2008V 2.021122Естественный отбор«Гики»«Одиночки»«Командные игроки»16.01.2008V 2.021123Средства автоматизации16.01.2008V 2.021124Итого•Помните, зачем делается проект -деньги•Agile–это 12*(двенадцать) практик•Иначе это не Agile•Не надо перегружать Agileдокументами, его прелесть в простоте•Простота достигается за счет коммуникаций•Для этого команда и Заказчик должны работать вместе•Остальное –(сравнительно) просто16.01.2008V 2.021125Рекомендую к прочтению•Agile Project Management with SCRUM •(Ken Schwaber)16.01.2008V 2.02112629.10.2007V 2.021127Audaces fortunajuvat!Рефлексия•Зачем я сюда пришел (пришла)?–Есть ощущение удовлетворения этой потребности?•Что я хочу узнать?–Получили нужную информацию и источники?29.10.2007V 2.021128