Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,356 views

Published on

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

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

  1. 1. Давайте знакомиться Денис Петелин Успел попробовать себя во всех ролях софтверных проектов – от разработчика до владельца компании и Заказчика. Поскольку во всех ролях работал успешно, то имею востребованный опыт, который передаю другим. В последнее время все больше выступаю в роли Заказчика, где применяю изученные у Заказчиков грязные трюки  Denis_petelin@epam.com http://www.seadmex.ru/custo SEADMEX mers/epam
  2. 2. Окей, мы все через это прошли 29.10.2007 V 2.021 3
  3. 3. История создания тренинга 16.01.2008 V 2.021 4
  4. 4. Управление ожиданиями • Agile – это не методология типа RUP, это фрэймворк • Моя задача – рассказать ЧТО должно быть сделано, КАК вы будете это делать – это ваш выбор • Я расскажу как МЫ делаем Agile • (Это не значит, что ВЫ будете делать Agile также) • Я не расскажу вам все в деталях (но дам доп. Материалы)
  5. 5. Подход к обучению 29.10.2007 V 2.021 6
  6. 6. Рабочие соглашения • Сотовые – выключить • Почту – не читать • Коллег – не перебивать • Говорить – строго по одному 29.10.2007 V 2.021 7
  7. 7. Потенциальные проблемы • Некоторые слайды «перегружены» • Говорю слишком быстро или слишком медленно • Говорю слишком громко или слишком тихо • Непонятные моменты • Телефоны и пейджеры • Просьба о перерыве
  8. 8. Орг. Вопросы • Туалеты – влево и вниз по лестнице • Формат работы: 1,5 часа – перерыв Х 4 • Вопросы – задавать любые, даже не по теме тренинга • Материалы – будут выложены на Office Live 16.01.2008 V 2.021 9
  9. 9. Вопрос • Зачем я сюда пришел (пришла)? – Пример: Завтра мне начинать проект по Agile. С чего начать? • Что я хочу узнать? – Пример: Хочу чтоб в голове сложилось последовательность действий менеджера, устанавливающего Agile на проекте. 29.10.2007 V 2.021 10
  10. 10. Лекция 1 Почему Agile?
  11. 11. Начнем – с начала Алиса: «Не подскажете, каким путем мне идти, чтобы отсюда выбраться?» Кот: «Ну, это в значительной степени определяется тем, куда вы хотите попасть.» Алиса: «Мне, в общем-то, все равно...» Кот: «Тогда не имеет никакого значения, каким путем идти.» Алиса в Зазеркалье, Льюис Кэррол 29.10.2007 V 2.021 12
  12. 12. Что такое проект? Проект – уникальный набор скоординированных действий, имеющий начальную и конечную точки, направленный на получение определенного конечного результата в рамках ограничений времени, цены, качества и объема работ. 29.10.2007 V 2.021 13
  13. 13. Успешный проект • Проект – уникальный набор скоординированных действий, имеющий начальную и конечную точки, направленный на получение определенного конечного результата в рамках ограничений времени, цены, качества и объема работ. Чтобы быть успешным, проект должен: 1. Произвести конечный результат (решить задачу), который бы устраивал всех заинтересованных участников проекта. 2. Закончиться не позже запланированной даты (вовремя). 3. Остаться при этом в рамках требований качества, ограничений бюджета и объема работ. 29.10.2007 V 2.021 14
  14. 14. Измерения успешности • Набор основных измерений – Требования (Scope) • Запланировано = реализовано • Заказчик доволен – График (Schedule) • Продолжительность план = продолжительность факт – Бюджет (Budget) • Трудозатраты план = трудозатраты факт • Бюджет план = бюджет факт – Качество (Quality) • Покрытие тестами ~100% • «Критическийсерьезный» дефекты = 0
  15. 15. Проектный треугольник Задачи Люди Время • Мастер ($100/день) делает 1 кресло в день • Нам нужно 1 кресло (у нас есть день и $100) • Нет заноз и кресло не разваливается
  16. 16. «Почему у нас никак не получается?!!» • «Потому что строем не ходите!» – делали вещи посложнее – невероятные требования к надежности – сроки выдерживали • Потому что методология! – MIL-STD (2167…) – DOD-STD (498…) 29.10.2007 V 2.021 17
  17. 17. «Водопад» Концепция (с) Steve McConnel. «Rapid Development» Сбор Требований Разработка Архитектуры Проработка Архитектуры Кодирование и отладка Тестирование 29.10.2007 V 2.021 18
  18. 18. Никогда в жизни не сработает!
  19. 19. Как следствие • Наблюдения за 3 года: – Средняя задержка – 20% – Среднее превышение бюджета – 30% – Сделано больше чем планировалось – Заказчик все равно недоволен – Качество сделанного ПО оставляет желать лучшего – Разработчики еще почему-то ругают руководство и Заказчика 16.01.2008 V 2.021 20
  20. 20. «Мы совсем неплохо оцениваем» «Большинство руководителей проектов по созданию ПО проделывают приемлемую работу по предсказанию задач, которые должны быть выполнены, и слабую работу по предсказанию задач, которые может потребоваться выполнить.» Том де Марко. «Вальсируя с медведями»
  21. 21. «Большой взрыв» Баги, неучтенные риски, изменения Релиз билд билд билд билд «Предел возможностей» Время
  22. 22. Agile Manifesto • Нужды Заказчика – прежде всего • Требования должны меняться • Разработчики и Заказчик работают вместе • Релизы должны происходить часто • Коммуникации – лучшая документация • Команда – основная ценность • Совершенство заключается в простоте • Постоянно стремиться сделать для Заказчика больше 16.01.2008 V 2.021 23
  23. 23. Agile-фрэймворки 16.01.2008 V 2.021 24
  24. 24. Смысл один и тот же Баги, неучтенные риски, изменения билд билд билд билд Релиз «Предел возможностей» Время
  25. 25. Ценности Agile • Коммуникации вместо длинных контрактов • Рабочий софт вместо длинных спек • Ответ на изменение вместо следования плану • Храбрость и принятие ответственности 16.01.2008 V 2.021 26
  26. 26. Как устроен Agile-проект? Пользователи пишут Администраторы Заказчики «хотелки» и тесты для устанавливают удостоверяются, что них программу на сервер программа работает Заказчик выбирает из длинного списка Программисты Заказчики пишут новые короткий - «сделать в исправляют ошибки требования эту итерацию» Программисты пишут Тестеры проверяют программу вместе с наличие ошибок и Заказчиком, [Переходим в начало] сообщают консультируясь с программистам Заказчиком
  27. 27. Итого • Agile – не «процесс», а набор ценностей • Agile использует старые добрые проверенные временем практики • Agile предлагает сокращать длину итерации • + гибкость в принятии изменений, что приятно и Заказчику, и Разработчикам 16.01.2008 V 2.021 28
  28. 28. Сбор – 12:00 29.10.2007 V 2.021 29
  29. 29. Лекция 2 Один спринт из жизни Agile 29.10.2007 V 2.021 30
  30. 30. Как устроен проект? Администраторы Пользователи пишут Заказчики устанавливают «хотелки» и тесты удостоверяются, что программу на для них программа работает сервер Заказчик выбирает из длинного списка Программисты Заказчики пишут короткий - «сделать исправляют ошибки новые требования в эту итерацию» Тестеры проверяют Программисты наличие ошибок и [Переходим в пишут программу сообщают начало] вместе с Заказчиком программистам
  31. 31. По шагам Администраторы Пользователи пишут Заказчики устанавливают «хотелки» и тесты удостоверяются, что программу на для них программа работает сервер Заказчик выбирает из длинного списка Программисты Заказчики пишут короткий - «сделать исправляют ошибки новые требования в эту итерацию» Тестеры проверяют Программисты наличие ошибок и [Переходим в пишут программу сообщают начало] вместе с Заказчиком программистам
  32. 32. Роли в Agile Заказчик (Product Owner) – Пишет «хотелки», тесты и примеры к ним – Объясняет «хотелки» и расставляет приоритеты – Общается с пользователями – Решает, что важно и что нет Разработчик – Определяет задачи для реализации «хотелки» – Дает оценки объема работ – Реализует в коде «хотелки» и юнит-тесты к ним Scrum Master – Собирает и контролирует встречи – Информирует Спонсора – Платит за пиццу – Убирает препятствия (Impediments) 16.01.2008 V 2.021 33
  33. 33. С чего все начинается? Заказчик Scrum Master «хотелки» пользователей Задачи программистам Пользователи Заказчик (Product Owner) Scrum Master: 1. Собирает 1. Поддерживает список информацию от всех «хотелок» 2. Отсекает явно 2. Управляет ненужное обсуждением и 3. Утверждает «хотелки» процессом оценки 3. Не оценивает
  34. 34. Работа с Заказиком Сколько времени займет дорисовать кнопку? (Сколько это будет стоить?)
  35. 35. Определение user story «Хотелка» – это наиболее простая формулировка, позволяющая всем присутствующим согласиться с тем, что существует нечто, что необходимо сделать в рамках проекта. 16.01.2008 V 2.021 36
  36. 36. Storycard – Лицевая сторона ID Суть задачи SEADMEX
  37. 37. Обработка «хотелки»
  38. 38. Превосходная «хотелка» Независима и самодостаточна Может обсуждаться с разработчиком и корректироваться, уточняться Определяет свойство системы, нужное пользователям/заказчикам Позволяет оценить трудоемкость Невелика по объему Определяет свойство системы, которое может быть протестировано 16.01.2008 V 2.021 39
  39. 39. Storycard – Оборотная сторона Тест Тест SEADMEX
  40. 40. Важность тестов • «Рассказы» должны формулироваться так, чтобы соответствующие возможности системы могли быть протестированы • При невозможности тестирования невозможно определить окончание разработки • По возможности, тесты должны быть автоматизируемыми – Пример нетестируемой «хотелки»: Пользователь не должен слишком долго ждать появления диалогового окна. – Более корректно: Новое окно появляется в течение 2 секунд в 95% случаев 16.01.2008 V 2.021 41
  41. 41. Зачем нужен бэклог? • Бэклог – это форма записи требований – Без бэклога нельзя сделать Заказчика счастливым • Бэклог – это форма коммуникации – Если бэклог непонятен Заказчику – коммуникация не состоялась 16.01.2008 V 2.021 42
  42. 42. «Хотелка» в бэклоге ID Название Формулировка Источ Тест № Кто Оценка ник 56 Hot keys в Должна быть ALVO СоAgileанить 5 SEGI 2 форме «Заказ» возможность заказ F2, выполнить все Перейти к следующему действия по полю – Tab, вводу нового Ctrl-Enter - заказа сохранить и посредством отправить клавиатуры, заказ в без участия работу? мыши. Escape - выход без сохранения заказа (с подтвержден ием) 29.10.2007 V 2.021 43
  43. 43. Бэклог продукта «Хотелки»+ оценки Оценка: 4 часа Заказчик Scrum Master Оценка: 2 часа 1. «Принесет нам миллион» Оценка: 0,5 часа 2. «Сэкономит нам миллион» Оценка: 0,25 часа 3. «Даст 100 новых клиентов» Оценка: 8 часов Бэклог спринта Оценка: 16 часов Оценка: 1 час ... Программист Итого: 100 000 часов
  44. 44. Определяем порядок
  45. 45. Преимущества • Переработаем до приемлемого вида очень быстро • Изменения стоят копейки • Разберемся в деталях • Точно поставим задачу и программист поймет ее правильно • Получим удобную Программу с первого раза
  46. 46. По шагам Администраторы Пользователи пишут Заказчики устанавливают «хотелки» и тесты удостоверяются, что программу на для них программа работает сервер Заказчик выбирает из длинного списка Программисты Заказчики пишут короткий - «сделать исправляют ошибки новые требования в эту итерацию» Тестеры проверяют Программисты наличие ошибок и пишут программу [Новая итерация] сообщают вместе с Заказчиком программистам
  47. 47. Бэклог продукта «Хотелки»+ оценки Оценка: 4 часа Заказчик Scrum Master Оценка: 2 часа 1. «Принесет нам миллион» Оценка: 0,5 часа 2. «Сэкономит нам миллион» Оценка: 0,25 часа 3. «Даст 100 новых клиентов» Оценка: 8 часов Бэклог спринта Оценка: 16 часов Оценка: 1 час ... Программист Итого: 100 000 часов
  48. 48. Вспоминаем почему так: • Мастер ($100/день) делает 1 кресло в день • Нам нужно 1 кресло (у нас есть день и $100) Задачи Люди Время
  49. 49. Процесс оценки • Оценка «в пингвинах» – Выбираем эталон в 5 пингвинов – Оцениваем все «хотелки» сравнивая с эталоном – Отталкиваясь от известного «быстродействия» отбираем нужное количество «хотелок» • Оценка «в часах» – Знаем емкость команды в часах (160 * N человек) – Оцениваем каждую задачу в часах – Отнимаем от общей емкости команды оценки до тех пор, пока не получится ноль 16.01.2008 V 2.021 50
  50. 50. «Плэннинг покер» 1. Все смотрят на эталон 2. Заказчик объясняет новую «хотелку» 3. Все выбрасывают по карте Эталон 4. Оценка совпала – вписываем 5. Оценка сильно не не совпала: 1. Высказывается поставивший самую маленькую оценку 2. Высказывается поставивший самую высокую оценку 3. Просим пояснений у Заказчика Обсуждаем 6. GO TO 4 16.01.2008 V 2.021 51
  51. 51. В чем давать оценки? 29.10.2007 V 2.021 52
  52. 52. Оценка в часах • Чем меньше задача – тем точнее оценка – Разбивайте большие «хотелки» на меньшие – Для каждой «хотелки» расписывайте набор задач – Оценивайте каждую задачу – Оценивает тот, кто будет делать задачу 29.10.2007 V 2.021 53
  53. 53. «Хотелка» и «задача» Задача №00234 • «Парни, я хочу хранить для участка информацию о том, какие конкретно ПИ там живут!»
  54. 54. Балансируем треугольник Быстройдествие = 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
  55. 55. Роли в Agile Тестер – Пишет и прогоняет тесты – Оформляет результаты так, чтобы всем было понятно Пессимист – Напоминает всем по риски – Следит, чтобы мы не принимали желаемое за действительное 16.01.2008 V 2.021 56
  56. 56. Преимущества • То, что реально важно, всегда делается • Скорость – очень высокая • Это происходит из-за высокой эффективности работы, а не за счет качества • Себестоимость при этом получается - ниже
  57. 57. По шагам Администраторы Пользователи пишут Заказчики устанавливают «хотелки» и тесты удостоверяются, что программу на для них программа работает сервер Заказчик выбирает из длинного списка Программисты Заказчики пишут короткий - «сделать исправляют ошибки новые требования в эту итерацию» Тестеры проверяют Программисты наличие ошибок и пишут программу [Новая итерация] сообщают вместе с Заказчиком программистам
  58. 58. Где же менеджер??? 16.01.2008 V 2.021 59
  59. 59. Definition Of Done • Story сделан – Код в SVN, с комментарием – Юнит-тест в проекте – Юнит-тесты проекта прошли – Глупых ошибок на UI нет • Story закрывает тот, кто его открыл – Если он недоволен по любой причине – он не закрывает кейс – Daily Scrum: 10:00, 75-4 SEADMEX
  60. 60. Происходит работа... • Daily Scrum • Программисты делают сессии по дизайну • Пишут вместе тесты • Потом код • Юнит-тесты проверяют их работоспособность • Программа сборки делает из него билды • Тестеры тестируют билды заглядывая в список What’s New • До тех пор, пока не сделаны все «хотелки» итерации
  61. 61. Task Board и его чтение 16.01.2008 V 2.021 62
  62. 62. Роли в Agile Трэкер – Собирает со всех информацию об успехах – При необходимости зовет на помощь Тренера или другого разработчика Тренер – Наблюдает и дает советы – В явном виде помогает – «Свертывает газету» при необходимости 16.01.2008 V 2.021 63
  63. 63. Scrum!!! 16.01.2008 V 2.021 64
  64. 64. Daily Scrum 16.01.2008 V 2.021 65
  65. 65. Трэкер и «прозрачность» 16.01.2008 V 2.021 66
  66. 66. «Хотелка» для обсуждения • User Stories не считаются «высеченными в камне». Детали «хотелок» могут и должны обсуждаться между заказчиком и разработчиком. – Правильнее считать «хотелки» напоминанием • В момент начала работы над «рассказом» разработчик уточняет у заказчика необходимые подробности http://www.seadmex.ru/custo SEADMEX mers/ibs
  67. 67. Постоянная интеграция Компилируется проект Разработчик делает коммит Запускаются юнит-тесты Результаты Запуск процедуры Билд появляются в развертывания и успешен - дашборде обновления Приложение и база обновлены 16.01.2008 V 2.021 68
  68. 68. По шагам Администраторы Пользователи пишут Заказчики устанавливают «хотелки» и тесты удостоверяются, что программу на для них программа работает сервер Заказчик выбирает из длинного списка Программисты Заказчики пишут короткий - «сделать исправляют ошибки новые требования в эту итерацию» Тестеры проверяют Программисты наличие ошибок и пишут программу [Новая итерация] сообщают вместе с Заказчиком программистам
  69. 69. Имплементация story Программист Задачи по исправлению ошибок Тестовые примеры Заказчик Список выполненных задач + Тестер Тестовые данные результирующая программа Надежная программа
  70. 70. Тестовые сценарии • Тестовый пример: Ввести номенклатуру изделия, Программа пишет расшифровку кода номенклатуры, при этом обрабатывает несуществующие коды и замены. • Проверить с тестовыми данными: – 005Е6789: «немыслимый шаровой клапан» – 005N0000: «код не существует» – 005Т0098: «снят с производства, возможна замена на 005T0198»
  71. 71. По шагам Администраторы Пользователи пишут Заказчики устанавливают «хотелки» и тесты удостоверяются, что программу на для них программа работает сервер Заказчик выбирает из длинного списка Программисты Заказчики пишут короткий - «сделать исправляют ошибки новые требования в эту итерацию» Тестеры проверяют Программисты наличие ошибок и пишут программу [Новая итерация] сообщают вместе с Заказчиком программистам
  72. 72. Исправление ошибок • Ошибки сделанные программистом – НИКОГДА Заказик не платит за исправление ошибок, которые сделал наши программисты • Ошибки как следствие новых Задач – ВСЕГДА платит за исправление ошибок, внесенных измененными иили противоречивыми, новыми, неправильно сформулированными «хотелками»
  73. 73. Преимущества • Менеджер и Заказчик думают о том, как должно работать правильно • Тестер думает о том, что может работать неправильно • Тестер думает заранее • Как следствие Программа (почти) всегда работает как надо
  74. 74. По шагам Администраторы Пользователи пишут Заказчики устанавливают «хотелки» и тесты удостоверяются, что программу на для них программа работает сервер Заказчик выбирает из длинного списка Программисты Заказчики пишут короткий - «сделать исправляют ошибки новые требования в эту итерацию» Тестеры проверяют Программисты наличие ошибок и пишут программу [Новая итерация] сообщают вместе с Заказчиком программистам
  75. 75. Установка программы
  76. 76. Две версии
  77. 77. Преимущества • Всегда есть версия программы, которая работает • Тестирование любой степени извращенности не ломает рабочую версию программы
  78. 78. По шагам Администраторы Пользователи пишут Заказчики устанавливают «хотелки» и тесты удостоверяются, что программу на для них программа работает сервер Заказчик выбирает из длинного списка Программисты Заказчики пишут короткий - «сделать исправляют ошибки новые требования в эту итерацию» Тестеры проверяют Программисты наличие ошибок и пишут программу [Новая итерация] сообщают вместе с Заказчиком программистам
  79. 79. Демо 16.01.2008 V 2.021 80
  80. 80. По шагам Администраторы Пользователи пишут Заказчики устанавливают «хотелки» и тесты удостоверяются, что программу на для них программа работает сервер Заказчик выбирает из длинного списка Программисты Заказчики пишут короткий - «сделать исправляют ошибки новые требования в эту итерацию» Тестеры проверяют Программисты наличие ошибок и пишут программу [Новая итерация] сообщают вместе с Заказчиком программистам
  81. 81. Мы рекомендуем • Собрать набор пожеланий по итогам просмотра в виде «хотелок» • Реализовывать только самые необходимые новые «хотелки» • (При необходимости с них можно начать следующую итерацию)
  82. 82. Анализ причин и следствий 16.01.2008 V 2.021 83
  83. 83. Ретроспектива & Бэклог препятствий 16.01.2008 V 2.021 84
  84. 84. По шагам Администраторы Пользователи пишут Заказчики устанавливают «хотелки» и тесты удостоверяются, что программу на для них программа работает сервер Заказчик выбирает из длинного списка Программисты Заказчики пишут короткий - «сделать исправляют ошибки новые требования в эту итерацию» Тестеры проверяют Программисты наличие ошибок и пишут программу [Новая итерация] сообщают вместе с Заказчиком программистам
  85. 85. Преимущества • Нет вероятности «передалать» работающую программу в неработающую • Работающая программа будет установлена на сервер и будет работать (и приносить деньги) • В это время будут делаться переделки, новые «хотелки» и т.д.
  86. 86. Итого • Спринт устроен очень просто Администраторы Пользователи пишут Заказчики устанавливают «хотелки» и тесты удостоверяются, что программу на для них программа работает сервер Заказчик выбирает из длинного списка Программисты Заказчики пишут короткий - «сделать исправляют ошибки новые требования в эту итерацию» Тестеры проверяют Программисты наличие ошибок и пишут программу [Новая итерация] сообщают вместе с Заказчиком программистам 16.01.2008 V 2.021 87
  87. 87. Перерыв – 60 минут 29.10.2007 V 2.021 88
  88. 88. Вырабатываем «хотелки» Практика 16.01.2008 V 2.021 89
  89. 89. Превосходная «хотелка» Независима и самодостаточна Может обсуждаться с разработчиком и корректироваться, уточняться Определяет свойство системы, нужное пользователям/заказчикам Позволяет оценить трудоемкость Невелика по объему Определяет свойство системы, которое может быть протестировано 16.01.2008 V 2.021 90
  90. 90. «Независимость хотелки» • Следует избегать зависимостей между «хотелки», насколько это возможно. • Зависимости порождают проблемы при определении приоритетов и планировании. • Как добиваться независимости: – Объединять «хотелки» в более крупные, но независимые – Подбирать разбивку функциональности системы на независимые «хотелки» 16.01.2008 V 2.021 91
  91. 91. «Хотелки»: небольшой объем • Слишком объемные и слишком маленькие «рассказы» сложно использовать для планирования – Объемный «рассказ» может реально включать несколько user stories • «Правильный» объем зависит от возможностей команды и применяемых технологий • Правило: максимальный размер хотелки должен быть таким, чтобы одна пара разработчиков могла полностью реализовать его в течение одной итерации. SEADMEX
  92. 92. Небольшой объем «хотелки» • Слишком объемный «рассказ» обычно является: – Составным. Представляет собой набор менее объемных «рассказов». либо – Сложным. Действительно большой и не может быть легко разбит на меньшие «рассказы». 16.01.2008 V 2.021 93
  93. 93. Составная «хотелка» - пример • Слишком объемная «хотелка»: – Пользователь может разместить на сайте свое резюме. • Реально это означает: ± Резюме может включать образование, предыдущие работы, историю зарплаты, публикации, цель поиска работы ± Пользователь может пометить резюме как неактивное ± Пользователь может одновременно разместить несколько своих резюме ± Пользователь может редактировать резюме ± Пользователь может удалить резюме 16.01.2008 V 2.021 94
  94. 94. Слишком мелкие «хотелки» • Например: – Пользователь может ввести даты начала и окончания для каждого места работы в резюме – Пользователь может редактировать даты начала и окончания для каждого места работы в резюме – Пользователь может ввести даты начала и окончания для каждого места учебы в резюме – Пользователь может ввести даты начала и окончания для каждого места учебы в резюме – ... SEADMEX
  95. 95. Сложные «хотелки» • Сложные «рассказы» действительно велики и не могут быть легко разбиты на меньшие «хотелки» • Можно разбить «рассказ» на следующие задачи: 1. Исследовательская работа по «хотелке» (в заданных временных рамках) для оценки трудоемкости 2. Планирование в соответствии с полученной оценкой и реализация «хотелки» 16.01.2008 V 2.021 96
  96. 96. «Хотелки» и ЗаказчикPO • Официальное правило: пожелания записывает на карточки заказчик. • Если заказчик не может или не хочет записывать, вы можете помочь ему в этом; если записывать пожелания на карточку будет кто-то другой, заказчик будет чувствовать себя увереннее. • В процессе работы заказчик может обрести уверенность и начать сам записывать «рассказы». • В любом случае карточки принадлежат заказчику и только он имеет право формировать «рассказы» либо вносить изменения.
  97. 97. Разработчицкие «хотелки» Важно только для разработчиков: 1. Все коннекты к БД выполняются только через пул соединений 2. Вся обработка и протоколирование ошибок реализованы в специальном наборе классов Более корректный вариант, понятный Заказчику: 1. С приложением, имеющим лицензию на 5 пользователей СУБД, должны работать до 15 пользователей. 2. Все ошибки представляются пользователю и протоколируются единообразно. 16.01.2008 V 2.021 98
  98. 98. Метафора CRM – это система, благодаря которой ни одно обращение Заказчиков не остается без ответа – Все входящие письма на customer.care@seadmex.ru регистрируются в системе и не могут остаться без ответа – Из писем можно создавать «Сделки» – В сделки вносится ответственный, вероятность, ожидаемая сумма и т.д. – У сделок есть история, включая письма, задачи 60 мин и ответственных, встречи в календаре – Система умеет генерировать отчет «Наш бизнес», в котором я могу видеть перечень сделок на месяц, выигранные и проигранные, что по ним делалось и что запланировано 16.01.2008 V 2.021 99
  99. 99. Практика 4 спринта Agile 29.10.2007 V 2.021 100
  100. 100. Сейчас мы проделаем 4 спринта • Я – спонсор Х проектов – Выберите Product Owner – Определите кто Scrum Master – Разбейтесь на команды по симпатиям – Заказчики, подходите ко мне за бэклогом продукта и 90 мин инструктажем  16.01.2008 V 2.021 101
  101. 101. Планирование • Возьмите бэклог продукта • Произведите оценку (управляет Scrum Master) • Попробуйте прикинуть свою производительность (спринт = 10мин) • Отберите набор «хотелок» на спринт • Подготовьте бэклог спринта • По готовности всех команд – начинаем! 16.01.2008 V 2.021 102
  102. 102. Конец итерации • Сообщите мне, какая была рассчетная производительность • Теперь посчитайте реальную производительность • Ретроспектива – что можно сделать лучше? • Начинайте новый цикл планирования 16.01.2008 V 2.021 103
  103. 103. Выводы • Какие будут сложности с использованием этого подхода в вашей компании? 16.01.2008 V 2.021 104
  104. 104. И что дальше? Лекция 4 29.10.2007 V 2.021 105
  105. 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
  106. 106. Успешный проект Чтобы быть успешным, проект должен: 1. Произвести конечный результат (deliverable(s)), который бы устраивал всех заинтересованных участников проекта. 2. Закончиться не позже запланированной даты. 3. Остаться при этом в рамках требований качества, ограничений бюджета и объема работ.
  107. 107. Проектная деятельность • (Задача: заработать деньги) Revenue, $ Проект, duration work deliverable
  108. 108. Управление проектом • Управление проектом - это применение знаний, навыков, методов, средств и технологий к проектной деятельности в целях удовлетворения требований, достижения или превышения ожиданий участников проекта, т.е. обеспечения выполнения работ с заданным уровнем качества, в заданный срок и в рамках выделенных средств. PM BoK, PMI
  109. 109. Scrum Master • Scrum Master – человек, полностью ответственный за успех или неудачу проекта – удовлетворение или превышение ожиданий всех участников проекта.
  110. 110. Не так быстро Profit, $ Revenue, $ Задачи Cost, $
  111. 111. Вспоминаем почему так: • Мастер ($100/день) делает 1 кресло в день • Нам нужно 1 кресло (у нас есть день и $100) Задачи Люди = деньги Время
  112. 112. Простые выводы • Чем мы торгуем? • Откуда мы узнаем, сколько часов должно быть продано? • Что будет, если мы изначально неправильно определили количество часов? • Что будет, если впоследствии количествотип стульев будет изменено? • Что будет, если мастер работает плохо (по любой причине)?
  113. 113. Проблема Agile Profit, $ Sprint = Cost, $ Sprint = Cost, $ Sprint = Cost, $ Revenue, $ Задачи = ? Sprint = Cost, $ Sprint = Cost, $ Sprint = Cost, $ 16.01.2008 V 2.021 114
  114. 114. Советы по отбору проектов • Старайтесь заложить большую маржу • Еще лучше – продавайте проекты с «помесячной» оплатой • Проекты с маленькой маржой должны быть не просто гибкими, а супергибкими 29.10.2007 V 2.021 115
  115. 115. Из личного опыта 29.10.2007 V 2.021 116
  116. 116. Не начинайте с инструментов! • Выберите команду, которая горит желанием делать Agile • Соберите всю команду вместе • Поместите Заказчика рядом • Внедряйте одну практику за раз • Внедряйте все практики 16.01.2008 V 2.021 117
  117. 117. Внедряйте все практики «Типа Возможно, спецификация» «релиз» Это не Agile! 16.01.2008 V 2.021 118
  118. 118. Проблемы с Заказчиком Skype + SharedView 16.01.2008 V 2.021 119
  119. 119. Типичная ситуация Новая практика Удовольствие Непонимание Освоение Злость 16.01.2008 V 2.021 120
  120. 120. Причины недовольства • Требования без объяснений • Предыдущий опыт • Отсутствие мотивации • Страх изменения • Страх неудачи • Синдром «старой собаки» • Физическоеумственное состояние 16.01.2008 V 2.021 121
  121. 121. Коучинг • В идеале – менеджер: – Может заменить любого члена команды – Может учить по любой теме – Готов взять на себя самую тяжелуюнудную часть работы 16.01.2008 V 2.021 122
  122. 122. Естественный отбор «Командные игроки» «Одиночки» «Гики» 16.01.2008 V 2.021 123
  123. 123. Средства автоматизации 16.01.2008 V 2.021 124
  124. 124. Итого • Помните, зачем делается проект - деньги • Agile – это 12* (двенадцать) практик • Иначе это не Agile • Не надо перегружать Agile документами, его прелесть в простоте • Простота достигается за счет коммуникаций • Для этого команда и Заказчик должны работать вместе • Остальное – (сравнительно) просто 16.01.2008 V 2.021 125
  125. 125. Рекомендую к прочтению • Agile Project Management with SCRUM • (Ken Schwaber) 16.01.2008 V 2.021 126
  126. 126. Audaces fortuna juvat! 29.10.2007 V 2.021 127
  127. 127. Рефлексия • Зачем я сюда пришел (пришла)? – Есть ощущение удовлетворения этой потребности? • Что я хочу узнать? – Получили нужную информацию и источники? 29.10.2007 V 2.021 128

×