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

3,051 views
2,975 views

Published on

Published in: Technology
2 Comments
6 Likes
Statistics
Notes
  • Еще вызывает серьезные вопросы слайд №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
No Downloads
Views
Total views
3,051
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
188
Comments
2
Likes
6
Embeds 0
No embeds

No notes for slide

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

×