Upload
denis-petelin
View
3.505
Download
1
Embed Size (px)
DESCRIPTION
Citation preview
Давайте знакомиться
http://www.seadmex.ru/customers/epam
SEADMEX
Денис Петелин
Успел попробовать себя во всех ролях софтверных проектов – от разработчика до владельца компании и Заказчика.
Поскольку во всех ролях работал успешно, то имею востребованный опыт, который передаю другим.
В последнее время все больше выступаю в роли Заказчика, где применяю изученные у Заказчиков грязные трюки
Окей, мы все через это прошли
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 часа
Оценка: 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.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 мин
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