Slid 3.0 Scrum для практиков на Vsts2008
-
Upload
denis-petelin -
Category
Documents
-
view
1.350 -
download
4
description
Transcript of Slid 3.0 Scrum для практиков на Vsts2008
Давайте знакомиться
http://www.seadmex.ru/customers/epam
SEADMEX
Денис Петелин
Успел попробовать себя во всех ролях софтверных проектов – от разработчика до владельца компании и Заказчика.
Поскольку во всех ролях работал успешно, то имею востребованный опыт, который передаю другим.
В последнее время все больше выступаю в роли Заказчика, где применяю изученные у Заказчиков грязные трюки
Попутно являюсь Product Owner для одного стартапа, Scrum Master для еще одной команды, Agile Coach для двух проектов.
Окей, мы все через это прошли
29.10.2007 V 2.021 4
История создания тренинга
16.01.2008 V 2.021 5
Vision \ Scope
• Вы уже повозились с Team System и теперь по какой-то причине вам интересно, как мыделаем agile (scrum) в Team System 2008:
1. Я – менеджер, и могу говорить только за agile и Team System для менеджеров
2. Я собираюсь его обзорно показать вам в разрезе «процесс»
3. Я собираюсь вам его обзорно показать в разрезе «инструмент»
16.01.2008 V 2.021 6
Vision \ Scope
• У меня на это дело есть один день:
1. Я собираюсь его обзорно показать вам в разрезе «процесс»
a) Это не тренинг по agile-методологиям
b) Я не собираюсь вас убеждать что agile работает
2. Я собираюсь вам его обзорно показать в разрезе «инструмент»
a) Я (почти) не буду показывать администрирование
b) Мы не будем конфигурировать сервер \ упражняться
16.01.2008 V 2.021 7
Disclaimer
• Мы не делаем ничего сверхъестественного
• Я – не супер-мега-гуру Team System 2008
• Да, есть много способов делать все лучше в Team System 2008
• Да, есть много других инструментов кроме Team System 2008
• Да, вы могли бы сделать все в 10 раз лучше
16.01.2008 V 2.021 8
Limitations of liability
1. Показанное не значит, что наш путь единственно верный
2. Это не значит даже, что он подойдет вам
3. Используя эти соображения и подходы – вы делаете это на свой страх и риск, ни я ни кто-либо другой не несем за это ответственности
4. Пытаясь их тупо скопировать без понимания зачем оно вам надо – вы гарантированно огребете проблем
16.01.2008 V 2.021 9
Release Planning
• Release 1 – базовое понимание как сделать agile средствами Team System
– Sprint 1 – Объясню почему agile работает
– Sprint 2 – Объясню Customer Involvement
– Sprint 3 – Объясню TDD + ATDD
– Sprint 4 – Объясню CI + AD
16.01.2008 V 2.021 10
Рабочие соглашения
Сотовые –выключить
Почту – не читать
Коллег –не гнобить
Говорить –строго по одному
29.10.2007 V 2.021 11
Орг. Вопросы
• Формат работы: 1,5 часа Х 4 спринта
• Перерыв: 20 минут
• Обед: после 2х спринтов, 1 час
• Вопросы – задавать любые, даже не по теме тренинга
• Вопросы не по теме – на перерывах
• Материалы – будут выложены на Office Live
16.01.2008 V 2.021 12
Вопрос (1 минута подумать)
• Зачем я сюда пришел (пришла)?– Пример: Завтра мне начинать проект на Team
System. С чего начать?
• Что я хочу узнать?– Пример: Хочу чтоб в голове сложилось
последовательность действий менеджера, устанавливающего Agile на проекте.
• Опыт использования софта для управления?– Пример: FogBugz – 5 лет, OnTime – 3 года, TFS – 20
лет
29.10.2007 V 2.021 13
Почему Agile?Лекция 1
Начнем – с начала
Алиса: «Не подскажете, каким путем мне идти, чтобы отсюда выбраться?»
Кот: «Ну, это в значительной степени определяется тем, куда вы хотите попасть.»
Алиса: «Мне, в общем-то, все равно...»
Кот: «Тогда не имеет никакого значения, каким путем идти.»
Алиса в Зазеркалье,
Льюис Кэррол
29.10.2007 V 2.021 15
Что такое проект?
Проект – уникальный набор скоординированных действий, имеющий начальную и конечную точки, направленный на получение определенного конечного результата в рамках ограничений времени, цены, качества и объема работ.
29.10.2007 V 2.021 16
Успешный проект
• Проект – уникальный набор скоординированных действий, имеющий начальную и конечную точки, направленный на получение определенного конечного результата в рамках ограничений времени, цены, качества и объема работ.
Чтобы быть успешным, проект должен:
1. Произвести конечный результат (решить задачу), который бы устраивал всех заинтересованных участников проекта.
2. Закончиться не позже запланированной даты (вовремя).
3. Остаться при этом в рамках требований качества, ограничений бюджета и объема работ.
29.10.2007 V 2.021 17
Измерения успешности• Набор основных измерений
– Требования (Scope)• Запланировано = реализовано
• Заказчик доволен
– График (Schedule)• Продолжительность план = продолжительность
факт
– Бюджет (Budget)• Трудозатраты план = трудозатраты факт
• Бюджет план = бюджет факт
– Качество (Quality)• Покрытие тестами ~100%
• «Критический\серьезный» дефекты = 0
Проектный треугольник
• Мастер ($100/день) делает 1 кресло в день• Нам нужно 1 кресло (у нас есть день и $100)• Нет заноз и кресло не разваливается
Задачи
Время
Люди
«Почему у нас никак не получается?!!»
• «Потому что строем не ходите!»– делали вещи посложнее
– невероятные требования к надежности
– сроки выдерживали
• Потому что методология!– MIL-STD (2167…)
– DOD-STD (498…)
29.10.2007 V 2.021 20
«Водопад»
(с) Steve McConnel. «Rapid Development»
Концепция
Сбор Требований
Разработка Архитектуры
Проработка Архитектуры
Кодирование и отладка
Тестирование
29.10.2007 V 2.021 21
Никогда в жизни не сработает!
Как следствие
• Наблюдения за 3 года:
– Средняя задержка – 20%
– Среднее превышение бюджета – 30%
– Сделано больше чем планировалось
– Заказчик все равно недоволен
– Качество сделанного ПО оставляет желать лучшего
– Разработчики еще почему-то ругают руководство и Заказчика
16.01.2008 V 2.021 23
«Мы совсем неплохо оцениваем»
«Большинство руководителей проектов по созданию ПО проделывают приемлемую работу по предсказанию задач, которые должны быть выполнены, и слабую работу по предсказанию задач, которые может потребоваться выполнить.»
Том де Марко. «Вальсируя с медведями»
Время
Ба
ги, н
еуч
тен
ны
е р
иск
и, и
зм
ен
ен
ия Релиз билд билд билд билд
«Предел возможностей»
«Большой взрыв»
Agile Manifesto
• Нужды Заказчика – прежде всего
• Требования должны меняться
• Разработчики и Заказчик работают вместе
• Релизы должны происходить часто
• Коммуникации – лучшая документация
• Команда – основная ценность
• Совершенство заключается в простоте
• Постоянно стремиться сделать для Заказчика больше
16.01.2008 V 2.021 26
Agile-фрэймворки
16.01.2008 V 2.021 27
Смысл один и тот же
Время
Ба
ги, н
еуч
тен
ны
е р
иск
и, и
зм
ен
ен
ия
Релизбилдбилд билд билд
«Предел возможностей»
Ценности Agile
• Коммуникации вместо длинных контрактов
• Рабочий софт вместо длинных спек
• Ответ на изменение вместо следования плану
• Храбрость и принятие ответственности
16.01.2008 V 2.021 29
Как устроен Agile-проект?
Пользователи пишут «хотелки» и тесты для
них
Заказчик выбирает из длинного списка
короткий - «сделать в эту итерацию»
Программисты пишут программу вместе с
Заказчиком, консультируясь с
Заказчиком
Тестеры проверяют наличие ошибок и
сообщают программистам
Программисты исправляют ошибки
Администраторы устанавливают
программу на сервер
Заказчики удостоверяются, что программа работает
Заказчики пишут новые требования
[Переходим в начало]
Process Guidance
16.01.2008 V 2.021 31
Где же менеджер???
16.01.2008 V 2.021 32
Коучинг
• В идеале – менеджер:
– Может заменить любого члена команды
– Может учить по любой теме
– Готов взять на себя самую тяжелую\нудную часть работы
16.01.2008 V 2.021 33
Ключевой вопрос – «почему»
Цель проектаЦель человека
Цель проекта
Цель человека
Попробуйте представить…
• Заказчик намеренно хочет вытрясти из вас максимум за фиксированную цену
• Заказчик вообще не хочет чтобы приложение зарелизилось
• Заказчику нужно чтоб никто никогда не узнал что он не понимает чего хочет
• Заказчику нужно грамотно перевести стрелки и назначить виноватого
16.01.2008 V 2.021 35
Ключевое условие
16.01.2008 V 2.021 36
А причем здесь инструмент?
16.01.2008 V 2.021 37
Когда появляется инструмент?
Команда распределена географически –целиком или частично
Команда распределена во времени – целиком или частично
Команда совмещает проекты или периодически уходит в suspend
Требуется предоставить прозрачность –инвестору (продукт) или спонсору (аутсорс)
Команда отладила процесс и желает его ускорить
16.01.2008 V 2.021 38
Team System как такой инструмент
Clients & API
Team Explorer
Reporting Services
Office Apps
Process Template -> Project
Process
Tools
Engine
Data Logic & Rules
16.01.2008 V 2.021 39
2 основных process templates
Нужная фича MSF for Agile 4.2 Scrum for Team System 2.0
Backlog
Burndown
Task board
Zero-bug mindset
Checkin Policy
Agile Reports
Extended Reports
16.01.2008 V 2.021 40
Итого
• Agile – не «процесс», а набор ценностей
• Agile использует старые добрые проверенные временем практики
• Agile предлагает сокращать длину итерации
• + гибкость в принятии изменений, что приятно и Заказчику, и Разработчикам
16.01.2008 V 2.021 41
Перерыв – 20 минут
29.10.2007 V 2.021 42
Один спринт из жизни AgileЛекция 2
29.10.2007 V 2.021 43
Как устроен проект?
Пользователи пишут «хотелки» и тесты
для них
Заказчик выбирает из длинного списка короткий - «сделать
в эту итерацию»
Программисты пишут программу
вместе с Заказчиком
Тестеры проверяют наличие ошибок и
сообщают программистам
Программисты исправляют ошибки
Администраторы устанавливают программу на
сервер
Заказчики удостоверяются, что программа работает
Заказчики пишут новые требования
[Переходим в начало]
Проект Concretica
16.01.2008 V 2.021 45
Elevator pitch
16.01.2008 V 2.021 46
Scrum for Team System 2008
16.01.2008 V 2.021 47
http://www.scrumforteamsystem.com/
По шагам
Пользователи пишут «хотелки» и тесты
для них
Заказчик выбирает из длинного списка короткий - «сделать
в эту итерацию»
Программисты пишут программу
вместе с Заказчиком
Тестеры проверяют наличие ошибок и
сообщают программистам
Программисты исправляют ошибки
Администраторы устанавливают программу на
сервер
Заказчики удостоверяются, что программа работает
Заказчики пишут новые требования
[Переходим в начало]
Роли в Agile
Заказчик (Product Owner)– Пишет «хотелки», тесты и примеры к ним– Объясняет «хотелки» и расставляет приоритеты– Общается с пользователями– Решает, что важно и что нет
Разработчик– Определяет задачи для реализации «хотелки»– Дает оценки объема работ– Реализует в коде «хотелки» и юнит-тесты к ним
Scrum Master– Собирает и контролирует встречи– Информирует Спонсора– Платит за пиццу– Убирает препятствия (Impediments)
16.01.2008 V 2.021 49
С чего все начинается?
Пользователи
Заказчик
«хотелки» пользователей
Scrum Master
Задачи программистам
Заказчик (Product Owner)1. Собирает
информацию от всех2. Отсекает явно
ненужное3. Утверждает «хотелки»
Scrum Master:1. Поддерживает список
«хотелок»2. Управляет
обсуждением и процессом оценки
3. Не оценивает
Определение Product Backlog Item
«Хотелка» – это наиболее простая формулировка, позволяющая всем присутствующим согласиться с тем, что существует нечто, что необходимо сделать в рамках проекта.
16.01.2008 V 2.021 51
SEADMEX
Storycard – Лицевая сторонаID
Суть задачи
Превосходная «хотелка»
Независима и самодостаточна
Может обсуждаться с разработчиком и корректироваться, уточняться
Определяет свойство системы, нужное пользователям/заказчикам
Позволяет оценить трудоемкость
Невелика по объему
Определяет свойство системы, которое может быть протестировано
16.01.2008 V 2.021 53
SEADMEX
Storycard – Оборотная сторона
Тест
Тест
Работа с Заказиком
Сколько времени займет дорисовать кнопку?
(Сколько это будет стоить?)
Документация
16.01.2008 V 2.021 56
Если проект большой
16.01.2008 V 2.021 57
«Хотелка» в Product Backlog
29.10.2007 V 2.021 58
Acceptance Test Driven Development
29.10.2007 V 2.021 59
Типы Fixtures
29.10.2007 V 2.021 60
Action
Row
Column
Роли в Agile
Тестер
– Пишет и прогоняет * тесты
– Оформляет результаты так, чтобы всем было понятно
Пессимист
– Напоминает всем по риски
– Следит, чтобы мы не принимали желаемое за действительное
16.01.2008 V 2.021 61
Зачем нужен бэклог?
• Бэклог – это форма записи требований
– Без бэклога нельзя сделать Заказчика счастливым
• Бэклог – это форма коммуникации
– Если бэклог непонятен Заказчику –коммуникация не состоялась
16.01.2008 V 2.021 62
Преимущества
• Переработаем до приемлемого вида очень быстро
• Изменения стоят копейки• Разберемся в деталях• Точно поставим задачу и
программист поймет ее правильно
• Получим удобную Программу с первого раза
По шагам
Пользователи пишут «хотелки» и тесты
для них
Заказчик выбирает из длинного списка короткий - «сделать
в эту итерацию»
Программисты пишут программу
вместе с Заказчиком
Тестеры проверяют наличие ошибок и
сообщают программистам
Программисты исправляют ошибки
Администраторы устанавливают программу на
сервер
Заказчики удостоверяются, что программа работает
Заказчики пишут новые требования
[Новая итерация]
Определяем порядок
Product BacklogПрограммист
«Хотелки»+ оценки
Оценка: 4 часа
Оценка: 2 часа
Оценка: 6 часов
Оценка: 0,25 часа
Оценка: 8 часов
Оценка: 16 часов
Оценка: 1 час
...
Итого: 100 000 часов
Заказчик
Sprint Backlog
«Принесет нам миллион»
Добавить в базуScrum Master
Обновить orm
Прикрутить фиксчи
Итого: 40 часов
Оценка в часах
• Чем меньше задача – тем точнее оценка
– Разбивайте большие «хотелки» на меньшие
– Для каждой «хотелки» расписывайте набор задач
– Оценивайте каждую задачу
– Оценивает тот, кто будет делать задачу
29.10.2007 V 2.021 67
«Хотелка» и «задача»
• «Парни, я хочу хранить для участка информацию о том, какие конкретно ПИ там живут!»
Задача №00234
Формируем Sprint Backlog
Программист
«Хотелки»+ оценки
Оценка: 4 часа
Оценка: 2 часа
Оценка: 0,5 часа
Оценка: 0,25 часа
Оценка: 8 часов
Оценка: 16 часов
Оценка: 1 час
...
Итого: 100 000 часов
Заказчик
Product Backlog ItemsFor this Sprint
1. «Принесет нам миллион»
2. «Сэкономит нам миллион»
3. «Даст 100 новых клиентов»
Scrum Master
Когда останавливаться?
16.01.2008 V 2.021 70
Вспоминаем почему так:
• Мастер ($100/день) делает 1 кресло в день
• Нам нужно 1 кресло (у нас есть день и $100)
Задачи
Время
Люди
Принцип отбора в спринт
16.01.2008 V 2.021 72
Быстройдествие = 30
Балансируем треугольникБыстройдествие = 30
29.10.2007 V 2.021 73
A (15)
B (10)
C (5)
D (5)
A (15)
B (10)
D (5)
C (5)
A (15)
D (5)
C (5)
E (5)
Быстройдествие = 30
Преимущества
• То, что реально важно, всегда делается
• Скорость – очень высокая
• Это происходит из-за высокой эффективности работы, а не за счет качества
• Себестоимость при этом получается - ниже
Концептуальные связи
16.01.2008 V 2.021 75
SprintBacklog
Item
Sprint Backlog
ItemBug
Перерыв – 60 минут
29.10.2007 V 2.021 76
По шагам
Пользователи пишут «хотелки» и тесты
для них
Заказчик выбирает из длинного списка короткий - «сделать
в эту итерацию»
Программисты пишут программу
вместе с Заказчиком
Тестеры проверяют наличие ошибок и
сообщают программистам
Программисты исправляют ошибки
Администраторы устанавливают программу на
сервер
Заказчики удостоверяются, что программа работает
Заказчики пишут новые требования
[Новая итерация]
Definition Of Done
• Backlog Item сделан
– Код в TFS, с комментарием
– Юнит-тест в проекте
– Юнит-тесты проекта прошли
– Глупых ошибок на UI нет
• Backlog Item закрывает тот, кто его открыл
– Если он недоволен по любой причине – он не закрывает его
– Daily Scrum: 9:00, 75-4
SEADMEX
Project Portal
16.01.2008 V 2.021 79
Definition of done + Process
16.01.2008 V 2.021 80
Сессии по дизайну
16.01.2008 V 2.021 81
Происходит работа...
• Daily Scrum• Программисты делают сессии
по дизайну• Пишут вместе тесты• Потом код• Юнит-тесты проверяют
работоспособность кода• Team Build делает из него
билды, которые тут же тестируются
• Тестеры тестируют билды заглядывая в список What’s New
• До тех пор, пока не сделаны все «хотелки» спринта
Scrum!!!
16.01.2008 V 2.021 83
Daily Scrum
16.01.2008 V 2.021 84
Task Board и его чтение
16.01.2008 V 2.021 85
Task Board в Team System
16.01.2008 V 2.021 86
Как сделать чтоб обновлялись оперативно:
http://msdn.microsoft.com/en-us/library/ms400787.aspx
Спецплагин Task Board
16.01.2008 V 2.021 87
http://www.scrumforteamsystem.com/en/TaskBoard/default.aspx
Мегамонитор
16.01.2008 V 2.021 88
Роли в Agile
Трэкер
– Собирает со всех информацию об успехах
– При необходимости зовет на помощь Тренера или другого разработчика
Коуч
– Наблюдает и дает советы
– В явном виде помогает
– «Свертывает газету» при необходимости
16.01.2008 V 2.021 89
Трэкер и «прозрачность»
16.01.2008 V 2.021 90
Sprint Burndown
16.01.2008 V 2.021 91
Распределенная работа
16.01.2008 V 2.021 92
Удаленный Product Owner
16.01.2008 V 2.021 93
Skype + SharedView
Постоянная интеграция
16.01.2008 V 2.021 94
Разработчик
делает коммит
Компилируется
проект
Запускаются
юнит-тесты
Билд
успешен -
Запуск процедуры
развертывания и
обновления
Приложение и база
обновлены
Team BuildBVT
Любой
девелопер
TS2008 SCC
Репортинг и
нотификации
Результаты
появляются в
дашборде
Защита от г…кодеров
16.01.2008 V 2.021 95
Самый классный метод
16.01.2008 V 2.021 96
По шагам
Пользователи пишут «хотелки» и тесты
для них
Заказчик выбирает из длинного списка короткий - «сделать
в эту итерацию»
Программисты пишут программу
вместе с Заказчиком
Тестеры проверяют наличие ошибок и
сообщают программистам
Программисты исправляют ошибки
Администраторы устанавливают программу на
сервер
Заказчики удостоверяются, что программа работает
Заказчики пишут новые требования
[Новая итерация]
Имплементация Backlog Item
Программист
Список выполненных задач + результирующая программа
Тестер
Задачи по исправлению ошибок
Заказчик
Тестовые данные
Надежная программа
Тестовые примеры
Тестовые сценарии
• Тестовый пример: Ввести номенклатуру изделия, Программа пишет расшифровку кода номенклатуры, при этом обрабатывает несуществующие коды и замены.
• Проверить с тестовыми данными:
– 005Е6789: «немыслимый шаровой клапан»
– 005N0000: «код не существует»
– 005Т0098: «снят с производства, возможна замена на 005T0198»
Использование FIT
16.01.2008 V 2.021 100
Сломанный билд
16.01.2008 V 2.021 101
Чуть где что не так
16.01.2008 V 2.021 102
Выясняем причину
16.01.2008 V 2.021 103
Прикольный отчет
Fail Builds Successful Builds
Postion
Person Total % Total % Total Builds
1 Aliaksandr Baradyntsau
0 0.00 % 12 100.00 % 12
2 Aliaksei Stankevich 4 20.00 % 16 80.00 % 20
3 Ivan Kirkorau 1 10.00 % 1 90.00 % 10
16.01.2008 V 2.021 104
По шагам
Пользователи пишут «хотелки» и тесты
для них
Заказчик выбирает из длинного списка короткий - «сделать
в эту итерацию»
Программисты пишут программу
вместе с Заказчиком
Тестеры проверяют наличие ошибок и
сообщают программистам
Программисты исправляют ошибки
Администраторы устанавливают программу на
сервер
Заказчики удостоверяются, что программа работает
Заказчики пишут новые требования
[Новая итерация]
Zero-bug mindset
16.01.2008 V 2.021 106
Преимущества
• Менеджер и Заказчик думают о том, как должно работать правильно
• Тестер думает о том, чтоможет работать неправильно
• Тестер думает заранее
• Как следствие Программа (почти) всегда работает как надо
По шагам
Пользователи пишут «хотелки» и тесты
для них
Заказчик выбирает из длинного списка короткий - «сделать
в эту итерацию»
Программисты пишут программу
вместе с Заказчиком
Тестеры проверяют наличие ошибок и
сообщают программистам
Программисты исправляют ошибки
Администраторы устанавливают программу на
сервер
Заказчики удостоверяются, что программа работает
Заказчики пишут новые требования
[Новая итерация]
Установка программы
Две версии
Преимущества
• Всегда есть версия программы, которая работает
• Тестирование любой степени извращенности не ломает рабочую версию программы
По шагам
Пользователи пишут «хотелки» и тесты
для них
Заказчик выбирает из длинного списка короткий - «сделать
в эту итерацию»
Программисты пишут программу
вместе с Заказчиком
Тестеры проверяют наличие ошибок и
сообщают программистам
Программисты исправляют ошибки
Администраторы устанавливают программу на
сервер
Заказчики удостоверяются, что программа работает
Заказчики пишут новые требования
[Новая итерация]
Демо
16.01.2008 V 2.021 113
По шагам
Пользователи пишут «хотелки» и тесты
для них
Заказчик выбирает из длинного списка короткий - «сделать
в эту итерацию»
Программисты пишут программу
вместе с Заказчиком
Тестеры проверяют наличие ошибок и
сообщают программистам
Программисты исправляют ошибки
Администраторы устанавливают программу на
сервер
Заказчики удостоверяются, что программа работает
Заказчики пишут новые требования
[Новая итерация]
Ретроспектива & Бэклог препятствий
16.01.2008 V 2.021 115
Анализ причин и следствий
16.01.2008 V 2.021 116
Ретроспектива
16.01.2008 V 2.021 117
По шагам
Пользователи пишут «хотелки» и тесты
для них
Заказчик выбирает из длинного списка короткий - «сделать
в эту итерацию»
Программисты пишут программу
вместе с Заказчиком
Тестеры проверяют наличие ошибок и
сообщают программистам
Программисты исправляют ошибки
Администраторы устанавливают программу на
сервер
Заказчики удостоверяются, что программа работает
Заказчики пишут новые требования
[Новая итерация]
Преимущества
• Нет вероятности «передалать» работающую программу в неработающую
• Работающая программа будет установлена на сервер и будет работать (и приносить деньги)
• В это время будут делаться переделки, новые «хотелки» и т.д.
Итого
• Спринт устроен очень просто
16.01.2008 V 2.021 120
Пользователи пишут «хотелки» и тесты
для них
Заказчик выбирает из длинного списка короткий - «сделать
в эту итерацию»
Программисты пишут программу
вместе с Заказчиком
Тестеры проверяют наличие ошибок и
сообщают программистам
Программисты исправляют ошибки
Администраторы устанавливают программу на
сервер
Заказчики удостоверяются, что программа работает
Заказчики пишут новые требования
[Новая итерация]
Перерыв – 20 минут
29.10.2007 V 2.021 121
И что дальше?Соображения о внедрении
29.10.2007 V 2.021 122
Из личного опыта
29.10.2007 V 2.021 123
Внедряйте все практики
16.01.2008 V 2.021 124
«Типа
спецификация»
Возможно,
«релиз»
Это не Agile!
Причина неудач внедрений
16.01.2008 V 2.021 125
Цели
бизнеса
Цели
внедрения
Adoption through execution: Project-level mentoring to improve software capability
Kurt Bittner, Communities of Practice Architect, IBM
Saif Islam, Rational Services Manager, IBM
2006 2007
Вот это - Scrum
16.01.2008 V 2.021 126
Не начинайте с инструментов!
• Выберите команду, которая горит желанием делать Agile
• Соберите всю команду вместе
• Поместите Заказчика рядом
• Внедряйте одну практику за раз
• Внедряйте все практики
16.01.2008 V 2.021 127
Типичная ситуация
Новая практика
Непонимание
ЗлостьОсвоение
Удовольствие
16.01.2008 V 2.021 128
Причины недовольства
• Требования без объяснений
• Предыдущий опыт
• Отсутствие мотивации
• Страх изменения
• Страх неудачи
• Синдром «старой собаки»
• Физическое\умственное состояние
16.01.2008 V 2.021 129
Итого
• Помните, зачем делается проект – деньги
• Помните, что требуется личная заинтересованность
• В том числе Заказчика
• У каждого фрэймворка – свой обязательныйсет практик
• Иначе это не Agile
• Простота достигается за счет коммуникаций
• Инструменты – в самом конце
16.01.2008 V 2.021 130
Рекомендую к прочтению
• Agile Project Management with SCRUM
• (Ken Schwaber)
16.01.2008 V 2.021 131
Рекомендую к прочтению
• Better Software Development
• for Agile Teams
• Will Stott
• James Newkirk
16.01.2008 V 2.021 132
29.10.2007 V 2.021 133
Audaces fortuna juvat!
Рефлексия• Зачем я сюда пришел (пришла)?
– Есть ощущение удовлетворения этой потребности?
• Что я хочу узнать?
– Получили нужную информацию и источники?
29.10.2007 V 2.021 134
Сессия вопросов и ответов
16.01.2008 V 2.021 135