Scrum для практиков
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 3,404 views

 

Statistics

Views

Total Views
3,404
Views on SlideShare
3,398
Embed Views
6

Actions

Likes
6
Downloads
174
Comments
2

2 Embeds 6

http://www.slideshare.net 4
http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Еще вызывает серьезные вопросы слайд №73. 'НИКОГДА Заказчик не платит за ошибки, которые сделали наши программисты' - это как?? те дни, которые они их фиксают, не проходят по ведомости как billable? а если была вина аналитика и он натупил с требованиями, а программист теперь переделывает, то он ему отдает часть своей з/п?? И вообще разве в такой сверх-комплексной среде, как разработка ПО (см. Cynefin framework) всегда можно четко определить, кто виноват??? А всегда ли можно это доказать, если у нас по Аджайлу customer collaboration over comprehensive docs? Если не прописывать все до последней йоты в документации (тем самым нарушая этот принцип, порождая кучу excessive up-front detalization & waste) - то НИКАК! В правильном Скраме критические ошибки исправляются по ходу спринта, не критические и не трудоемкие - тоже, а вот некритические и трудоемкие идут в беклог продукта на приоритезацию. Таким образом, если команда будет допускать много ошибок, то у них будет низкая velocity, которой может быть недоволен заказчик, менеджмент и т.д. Для этого предусмотрены ретроспективы, чтобы вместе с РО проанализировать bottle-necks и улучшить процесс, чтобы уменьшить число ошибок, а не тупо наказывать за их кол-во, борясь с последствиями, но не первопричинами...
    Are you sure you want to
    Your message goes here
    Processing…
  • 'Scrum Master - человек, полностью ответственный за успех или неудачу проекта - удовлетворение или превышение ожиданий всех участников проекта' (слайд №110) - у меня вопрос: где автор услышал или прочитал этот бред, и утруждал ли он себя прочтением хотя бы одной книги от создателей Скрама или на худой конец 16-страничный официальный Scrum Guide?..
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • Давайте знакомиться Денис Петелин Успел попробовать себя во всех ролях софтверных проектов – от разработчика до владельца компании и Заказчика. Поскольку во всех ролях работал успешно, то имею востребованный опыт, который передаю другим. В последнее время все больше выступаю в роли Заказчика, где применяю изученные у Заказчиков грязные трюки  Denis_petelin@epam.com http://www.seadmex.ru/custo SEADMEX mers/epam
  • Окей, мы все через это прошли 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
  • Лекция 1 Почему Agile?
  • Начнем – с начала Алиса: «Не подскажете, каким путем мне идти, чтобы отсюда выбраться?» Кот: «Ну, это в значительной степени определяется тем, куда вы хотите попасть.» Алиса: «Мне, в общем-то, все равно...» Кот: «Тогда не имеет никакого значения, каким путем идти.» Алиса в Зазеркалье, Льюис Кэррол 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
  • Лекция 2 Один спринт из жизни Agile 29.10.2007 V 2.021 30
  • Как устроен проект? Администраторы Пользователи пишут Заказчики устанавливают «хотелки» и тесты удостоверяются, что программу на для них программа работает сервер Заказчик выбирает из длинного списка Программисты Заказчики пишут короткий - «сделать исправляют ошибки новые требования в эту итерацию» Тестеры проверяют Программисты наличие ошибок и [Переходим в пишут программу сообщают начало] вместе с Заказчиком программистам
  • По шагам Администраторы Пользователи пишут Заказчики устанавливают «хотелки» и тесты удостоверяются, что программу на для них программа работает сервер Заказчик выбирает из длинного списка Программисты Заказчики пишут короткий - «сделать исправляют ошибки новые требования в эту итерацию» Тестеры проверяют Программисты наличие ошибок и [Переходим в пишут программу сообщают начало] вместе с Заказчиком программистам
  • Роли в Agile Заказчик (Product Owner) – Пишет «хотелки», тесты и примеры к ним – Объясняет «хотелки» и расставляет приоритеты – Общается с пользователями – Решает, что важно и что нет Разработчик – Определяет задачи для реализации «хотелки» – Дает оценки объема работ – Реализует в коде «хотелки» и юнит-тесты к ним Scrum Master – Собирает и контролирует встречи – Информирует Спонсора – Платит за пиццу – Убирает препятствия (Impediments) 16.01.2008 V 2.021 33
  • С чего все начинается? Заказчик Scrum Master «хотелки» пользователей Задачи программистам Пользователи Заказчик (Product Owner) Scrum Master: 1. Собирает 1. Поддерживает список информацию от всех «хотелок» 2. Отсекает явно 2. Управляет ненужное обсуждением и 3. Утверждает «хотелки» процессом оценки 3. Не оценивает
  • Работа с Заказиком Сколько времени займет дорисовать кнопку? (Сколько это будет стоить?)
  • Определение user story «Хотелка» – это наиболее простая формулировка, позволяющая всем присутствующим согласиться с тем, что существует нечто, что необходимо сделать в рамках проекта. 16.01.2008 V 2.021 36
  • Storycard – Лицевая сторона ID Суть задачи SEADMEX
  • Обработка «хотелки»
  • Превосходная «хотелка» Независима и самодостаточна Может обсуждаться с разработчиком и корректироваться, уточняться Определяет свойство системы, нужное пользователям/заказчикам Позволяет оценить трудоемкость Невелика по объему Определяет свойство системы, которое может быть протестировано 16.01.2008 V 2.021 39
  • Storycard – Оборотная сторона Тест Тест SEADMEX
  • Важность тестов • «Рассказы» должны формулироваться так, чтобы соответствующие возможности системы могли быть протестированы • При невозможности тестирования невозможно определить окончание разработки • По возможности, тесты должны быть автоматизируемыми – Пример нетестируемой «хотелки»: Пользователь не должен слишком долго ждать появления диалогового окна. – Более корректно: Новое окно появляется в течение 2 секунд в 95% случаев 16.01.2008 V 2.021 41
  • Зачем нужен бэклог? • Бэклог – это форма записи требований – Без бэклога нельзя сделать Заказчика счастливым • Бэклог – это форма коммуникации – Если бэклог непонятен Заказчику – коммуникация не состоялась 16.01.2008 V 2.021 42
  • «Хотелка» в бэклоге ID Название Формулировка Источ Тест № Кто Оценка ник 56 Hot keys в Должна быть ALVO СоAgileанить 5 SEGI 2 форме «Заказ» возможность заказ F2, выполнить все Перейти к следующему действия по полю – Tab, вводу нового Ctrl-Enter - заказа сохранить и посредством отправить клавиатуры, заказ в без участия работу? мыши. Escape - выход без сохранения заказа (с подтвержден ием) 29.10.2007 V 2.021 43
  • Бэклог продукта «Хотелки»+ оценки Оценка: 4 часа Заказчик Scrum Master Оценка: 2 часа 1. «Принесет нам миллион» Оценка: 0,5 часа 2. «Сэкономит нам миллион» Оценка: 0,25 часа 3. «Даст 100 новых клиентов» Оценка: 8 часов Бэклог спринта Оценка: 16 часов Оценка: 1 час ... Программист Итого: 100 000 часов
  • Определяем порядок
  • Преимущества • Переработаем до приемлемого вида очень быстро • Изменения стоят копейки • Разберемся в деталях • Точно поставим задачу и программист поймет ее правильно • Получим удобную Программу с первого раза
  • По шагам Администраторы Пользователи пишут Заказчики устанавливают «хотелки» и тесты удостоверяются, что программу на для них программа работает сервер Заказчик выбирает из длинного списка Программисты Заказчики пишут короткий - «сделать исправляют ошибки новые требования в эту итерацию» Тестеры проверяют Программисты наличие ошибок и пишут программу [Новая итерация] сообщают вместе с Заказчиком программистам
  • Бэклог продукта «Хотелки»+ оценки Оценка: 4 часа Заказчик Scrum Master Оценка: 2 часа 1. «Принесет нам миллион» Оценка: 0,5 часа 2. «Сэкономит нам миллион» Оценка: 0,25 часа 3. «Даст 100 новых клиентов» Оценка: 8 часов Бэклог спринта Оценка: 16 часов Оценка: 1 час ... Программист Итого: 100 000 часов
  • Вспоминаем почему так: • Мастер ($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 Быстройдествие = 30 A (15) A (15) A (15) D (5) B (10) B (10) C (5) C (5) D (5) E (5) D (5) C (5) 29.10.2007 V 2.021 55
  • Роли в 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
  • «Хотелка» для обсуждения • User Stories не считаются «высеченными в камне». Детали «хотелок» могут и должны обсуждаться между заказчиком и разработчиком. – Правильнее считать «хотелки» напоминанием • В момент начала работы над «рассказом» разработчик уточняет у заказчика необходимые подробности http://www.seadmex.ru/custo SEADMEX mers/ibs
  • Постоянная интеграция Компилируется проект Разработчик делает коммит Запускаются юнит-тесты Результаты Запуск процедуры Билд появляются в развертывания и успешен - дашборде обновления Приложение и база обновлены 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
  • «Хотелки»: небольшой объем • Слишком объемные и слишком маленькие «рассказы» сложно использовать для планирования – Объемный «рассказ» может реально включать несколько user stories • «Правильный» объем зависит от возможностей команды и применяемых технологий • Правило: максимальный размер хотелки должен быть таким, чтобы одна пара разработчиков могла полностью реализовать его в течение одной итерации. SEADMEX
  • Небольшой объем «хотелки» • Слишком объемный «рассказ» обычно является: – Составным. Представляет собой набор менее объемных «рассказов». либо – Сложным. Действительно большой и не может быть легко разбит на меньшие «рассказы». 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 – это система, благодаря которой ни одно обращение Заказчиков не остается без ответа – Все входящие письма на customer.care@seadmex.ru регистрируются в системе и не могут остаться без ответа – Из писем можно создавать «Сделки» – В сделки вносится ответственный, вероятность, ожидаемая сумма и т.д. – У сделок есть история, включая письма, задачи 60 мин и ответственных, встречи в календаре – Система умеет генерировать отчет «Наш бизнес», в котором я могу видеть перечень сделок на месяц, выигранные и проигранные, что по ним делалось и что запланировано 16.01.2008 V 2.021 99
  • Практика 4 спринта Agile 29.10.2007 V 2.021 100
  • Сейчас мы проделаем 4 спринта • Я – спонсор Х проектов – Выберите Product Owner – Определите кто Scrum Master – Разбейтесь на команды по симпатиям – Заказчики, подходите ко мне за бэклогом продукта и 90 мин инструктажем  16.01.2008 V 2.021 101
  • Планирование • Возьмите бэклог продукта • Произведите оценку (управляет 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
  • Причина неудач внедрений 2006 2007 Цели бизнеса Цели внедрения Adoption through execution: Project-level mentoring to improve software capability Kurt Bittner, Communities of Practice Architect, IBM Saif Islam, Rational Services Manager, IBM 16.01.2008 V 2.021 106
  • Успешный проект Чтобы быть успешным, проект должен: 1. Произвести конечный результат (deliverable(s)), который бы устраивал всех заинтересованных участников проекта. 2. Закончиться не позже запланированной даты. 3. Остаться при этом в рамках требований качества, ограничений бюджета и объема работ.
  • Проектная деятельность • (Задача: заработать деньги) Revenue, $ Проект, duration work deliverable
  • Управление проектом • Управление проектом - это применение знаний, навыков, методов, средств и технологий к проектной деятельности в целях удовлетворения требований, достижения или превышения ожиданий участников проекта, т.е. обеспечения выполнения работ с заданным уровнем качества, в заданный срок и в рамках выделенных средств. PM BoK, PMI
  • Scrum Master • Scrum Master – человек, полностью ответственный за успех или неудачу проекта – удовлетворение или превышение ожиданий всех участников проекта.
  • Не так быстро Profit, $ Revenue, $ Задачи Cost, $
  • Вспоминаем почему так: • Мастер ($100/день) делает 1 кресло в день • Нам нужно 1 кресло (у нас есть день и $100) Задачи Люди = деньги Время
  • Простые выводы • Чем мы торгуем? • Откуда мы узнаем, сколько часов должно быть продано? • Что будет, если мы изначально неправильно определили количество часов? • Что будет, если впоследствии количествотип стульев будет изменено? • Что будет, если мастер работает плохо (по любой причине)?
  • Проблема Agile Profit, $ Sprint = Cost, $ Sprint = Cost, $ Sprint = Cost, $ Revenue, $ Задачи = ? Sprint = Cost, $ Sprint = Cost, $ Sprint = Cost, $ 16.01.2008 V 2.021 114
  • Советы по отбору проектов • Старайтесь заложить большую маржу • Еще лучше – продавайте проекты с «помесячной» оплатой • Проекты с маленькой маржой должны быть не просто гибкими, а супергибкими 29.10.2007 V 2.021 115
  • Из личного опыта 29.10.2007 V 2.021 116
  • Не начинайте с инструментов! • Выберите команду, которая горит желанием делать Agile • Соберите всю команду вместе • Поместите Заказчика рядом • Внедряйте одну практику за раз • Внедряйте все практики 16.01.2008 V 2.021 117
  • Внедряйте все практики «Типа Возможно, спецификация» «релиз» Это не Agile! 16.01.2008 V 2.021 118
  • Проблемы с Заказчиком Skype + SharedView 16.01.2008 V 2.021 119
  • Типичная ситуация Новая практика Удовольствие Непонимание Освоение Злость 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
  • Audaces fortuna juvat! 29.10.2007 V 2.021 127
  • Рефлексия • Зачем я сюда пришел (пришла)? – Есть ощущение удовлетворения этой потребности? • Что я хочу узнать? – Получили нужную информацию и источники? 29.10.2007 V 2.021 128