SlideShare ist ein Scribd-Unternehmen logo
1 von 128
Downloaden Sie, um offline zu lesen
Scrum для практиков
Давайте знакомиться
                Денис Петелин

                Успел попробовать себя во всех ролях софтверных проектов – от
                разработчика до владельца компании и Заказчика.

                Поскольку во всех ролях работал успешно, то имею востребованный
                опыт, который передаю другим.

                В последнее время все больше выступаю в роли Заказчика, где
                применяю изученные у Заказчиков грязные трюки 

                                                             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

Weitere ähnliche Inhalte

Was ist angesagt?

Mapia Presentation at Internet Ukraine 2009
Mapia Presentation at Internet Ukraine 2009Mapia Presentation at Internet Ukraine 2009
Mapia Presentation at Internet Ukraine 2009Maxon Pugovsky
 
Hienadz Drahun Quality & Usability Sef
Hienadz Drahun   Quality & Usability SefHienadz Drahun   Quality & Usability Sef
Hienadz Drahun Quality & Usability Sefsef2009
 
стратегический план презентация
стратегический план презентациястратегический план презентация
стратегический план презентацияdacenkoff
 
в.гарев социальные вирусы 1
в.гарев   социальные вирусы  1в.гарев   социальные вирусы  1
в.гарев социальные вирусы 1guest635945
 
подорож планетою толератності
подорож планетою толератностіподорож планетою толератності
подорож планетою толератностіPoltava municipal lyceum #1
 
Передовые технологии обучения языкам и практика их применения
Передовые технологии обучения языкам и практика их примененияПередовые технологии обучения языкам и практика их применения
Передовые технологии обучения языкам и практика их примененияulmas
 
PROJEKT KOSMOS
PROJEKT  KOSMOSPROJEKT  KOSMOS
PROJEKT KOSMOSwega
 
Огляд судової практики Касаційного цивільного суду у складі Верховного Суду
Огляд судової практики Касаційного цивільного суду у складі Верховного СудуОгляд судової практики Касаційного цивільного суду у складі Верховного Суду
Огляд судової практики Касаційного цивільного суду у складі Верховного СудуPravotv
 
Spyral dynamics in Life Management club (rus)
Spyral dynamics in Life Management club (rus)Spyral dynamics in Life Management club (rus)
Spyral dynamics in Life Management club (rus)dan voronov
 
водні ресурси
водні ресурсиводні ресурси
водні ресурсиAlina Abramova
 
МЭРТ 19_04_2009 МФЦ регионы Astrakhan
МЭРТ 19_04_2009 МФЦ регионы AstrakhanМЭРТ 19_04_2009 МФЦ регионы Astrakhan
МЭРТ 19_04_2009 МФЦ регионы AstrakhanVictor Gridnev
 
Я особистість!
Я  особистість!Я  особистість!
Я особистість!ssuser7f6b71
 
Системный подход в организации и проведении Assessment Center в компании. Под...
Системный подход в организации и проведении Assessment Center в компании. Под...Системный подход в организации и проведении Assessment Center в компании. Под...
Системный подход в организации и проведении Assessment Center в компании. Под...Vitaliy Mazurenko
 
Film Plus Production
Film Plus ProductionFilm Plus Production
Film Plus Productionstudiomed
 
TMPA-2013 Conference Proceedings
TMPA-2013 Conference ProceedingsTMPA-2013 Conference Proceedings
TMPA-2013 Conference ProceedingsIosif Itkin
 
Инновационные технологии Softidea в системе образования, Softidea Vision 2010
Инновационные технологии Softidea в системе образования, Softidea Vision 2010Инновационные технологии Softidea в системе образования, Softidea Vision 2010
Инновационные технологии Softidea в системе образования, Softidea Vision 2010SQALab
 

Was ist angesagt? (20)

Mapia Presentation at Internet Ukraine 2009
Mapia Presentation at Internet Ukraine 2009Mapia Presentation at Internet Ukraine 2009
Mapia Presentation at Internet Ukraine 2009
 
Hienadz Drahun Quality & Usability Sef
Hienadz Drahun   Quality & Usability SefHienadz Drahun   Quality & Usability Sef
Hienadz Drahun Quality & Usability Sef
 
2
22
2
 
стратегический план презентация
стратегический план презентациястратегический план презентация
стратегический план презентация
 
в.гарев социальные вирусы 1
в.гарев   социальные вирусы  1в.гарев   социальные вирусы  1
в.гарев социальные вирусы 1
 
подорож планетою толератності
подорож планетою толератностіподорож планетою толератності
подорож планетою толератності
 
Передовые технологии обучения языкам и практика их применения
Передовые технологии обучения языкам и практика их примененияПередовые технологии обучения языкам и практика их применения
Передовые технологии обучения языкам и практика их применения
 
3
33
3
 
PROJEKT KOSMOS
PROJEKT  KOSMOSPROJEKT  KOSMOS
PROJEKT KOSMOS
 
Огляд судової практики Касаційного цивільного суду у складі Верховного Суду
Огляд судової практики Касаційного цивільного суду у складі Верховного СудуОгляд судової практики Касаційного цивільного суду у складі Верховного Суду
Огляд судової практики Касаційного цивільного суду у складі Верховного Суду
 
Spyral dynamics in Life Management club (rus)
Spyral dynamics in Life Management club (rus)Spyral dynamics in Life Management club (rus)
Spyral dynamics in Life Management club (rus)
 
Openair Presentation
Openair PresentationOpenair Presentation
Openair Presentation
 
водні ресурси
водні ресурсиводні ресурси
водні ресурси
 
МЭРТ 19_04_2009 МФЦ регионы Astrakhan
МЭРТ 19_04_2009 МФЦ регионы AstrakhanМЭРТ 19_04_2009 МФЦ регионы Astrakhan
МЭРТ 19_04_2009 МФЦ регионы Astrakhan
 
Я особистість!
Я  особистість!Я  особистість!
Я особистість!
 
Системный подход в организации и проведении Assessment Center в компании. Под...
Системный подход в организации и проведении Assessment Center в компании. Под...Системный подход в организации и проведении Assessment Center в компании. Под...
Системный подход в организации и проведении Assessment Center в компании. Под...
 
Film Plus Production
Film Plus ProductionFilm Plus Production
Film Plus Production
 
TMPA-2013 Conference Proceedings
TMPA-2013 Conference ProceedingsTMPA-2013 Conference Proceedings
TMPA-2013 Conference Proceedings
 
Инновационные технологии Softidea в системе образования, Softidea Vision 2010
Инновационные технологии Softidea в системе образования, Softidea Vision 2010Инновационные технологии Softidea в системе образования, Softidea Vision 2010
Инновационные технологии Softidea в системе образования, Softidea Vision 2010
 
прогулки
прогулкипрогулки
прогулки
 

Andere mochten auch

多背一公斤设计供应商招标书
多背一公斤设计供应商招标书多背一公斤设计供应商招标书
多背一公斤设计供应商招标书vshowyy
 
Hasana Wahida Tounjik11
Hasana Wahida Tounjik11Hasana Wahida Tounjik11
Hasana Wahida Tounjik11chaabimehdi
 
Nacco proposal with cover letter
Nacco proposal with cover letterNacco proposal with cover letter
Nacco proposal with cover letterNeeraj Mahajan
 
Pla d'acció per al desenvolupament del contract manufacturing en el sector de...
Pla d'acció per al desenvolupament del contract manufacturing en el sector de...Pla d'acció per al desenvolupament del contract manufacturing en el sector de...
Pla d'acció per al desenvolupament del contract manufacturing en el sector de...Biocat, BioRegion of Catalonia
 
Marketing With Twitter
Marketing With TwitterMarketing With Twitter
Marketing With TwitterMichal Geva
 
Momentsalavida 1210002746293600 9
Momentsalavida 1210002746293600 9Momentsalavida 1210002746293600 9
Momentsalavida 1210002746293600 9vicentcerda
 
Mobidm | mobile device management
Mobidm |  mobile device managementMobidm |  mobile device management
Mobidm | mobile device managementMario De Vries
 
The reference interview in a digital reference environment
The reference interview in a digital reference environmentThe reference interview in a digital reference environment
The reference interview in a digital reference environmentipl2: Information You Can Trust
 
FlorianóPoliscele
FlorianóPolisceleFlorianóPoliscele
FlorianóPolisceleguest997182
 
Looking Like Christmas 1229173623609466 2
Looking Like Christmas 1229173623609466 2Looking Like Christmas 1229173623609466 2
Looking Like Christmas 1229173623609466 2José Quispecahuana
 

Andere mochten auch (20)

多背一公斤设计供应商招标书
多背一公斤设计供应商招标书多背一公斤设计供应商招标书
多背一公斤设计供应商招标书
 
Media audit1
Media audit1Media audit1
Media audit1
 
Core4 discipline
Core4 disciplineCore4 discipline
Core4 discipline
 
Hasana Wahida Tounjik11
Hasana Wahida Tounjik11Hasana Wahida Tounjik11
Hasana Wahida Tounjik11
 
Nayansukh
NayansukhNayansukh
Nayansukh
 
Nacco proposal with cover letter
Nacco proposal with cover letterNacco proposal with cover letter
Nacco proposal with cover letter
 
Core1 intro
Core1 introCore1 intro
Core1 intro
 
Rali sical 2010
Rali sical 2010Rali sical 2010
Rali sical 2010
 
Sorat Al Kahf
Sorat Al KahfSorat Al Kahf
Sorat Al Kahf
 
Pla d'acció per al desenvolupament del contract manufacturing en el sector de...
Pla d'acció per al desenvolupament del contract manufacturing en el sector de...Pla d'acció per al desenvolupament del contract manufacturing en el sector de...
Pla d'acció per al desenvolupament del contract manufacturing en el sector de...
 
Marketing With Twitter
Marketing With TwitterMarketing With Twitter
Marketing With Twitter
 
Momentsalavida 1210002746293600 9
Momentsalavida 1210002746293600 9Momentsalavida 1210002746293600 9
Momentsalavida 1210002746293600 9
 
Animals
AnimalsAnimals
Animals
 
Mobidm | mobile device management
Mobidm |  mobile device managementMobidm |  mobile device management
Mobidm | mobile device management
 
Mock exam animals
Mock exam animalsMock exam animals
Mock exam animals
 
QA в Agile
QA в AgileQA в Agile
QA в Agile
 
The reference interview in a digital reference environment
The reference interview in a digital reference environmentThe reference interview in a digital reference environment
The reference interview in a digital reference environment
 
Start Agile 2007
Start Agile 2007Start Agile 2007
Start Agile 2007
 
FlorianóPoliscele
FlorianóPolisceleFlorianóPoliscele
FlorianóPoliscele
 
Looking Like Christmas 1229173623609466 2
Looking Like Christmas 1229173623609466 2Looking Like Christmas 1229173623609466 2
Looking Like Christmas 1229173623609466 2
 

Mehr von Denis Petelin

Hitting the target - how to tame chaos
Hitting the target - how to tame chaosHitting the target - how to tame chaos
Hitting the target - how to tame chaosDenis Petelin
 
Leadership the missed manual
Leadership   the missed manualLeadership   the missed manual
Leadership the missed manualDenis Petelin
 
Деньги, которые не мотивируют
Деньги, которые не мотивируютДеньги, которые не мотивируют
Деньги, которые не мотивируютDenis Petelin
 
Self Organizing Team
Self Organizing TeamSelf Organizing Team
Self Organizing TeamDenis Petelin
 
Slid 3.0 Scrum для практиков на Vsts2008
Slid 3.0 Scrum для практиков на Vsts2008Slid 3.0 Scrum для практиков на Vsts2008
Slid 3.0 Scrum для практиков на Vsts2008Denis Petelin
 
Agile: Больше денег, меньше рисков
Agile: Больше денег, меньше рисковAgile: Больше денег, меньше рисков
Agile: Больше денег, меньше рисковDenis Petelin
 
Design With Agility Workshop
Design With Agility WorkshopDesign With Agility Workshop
Design With Agility WorkshopDenis Petelin
 
Психология в Agile проекте
Психология в Agile проектеПсихология в Agile проекте
Психология в Agile проектеDenis Petelin
 
Внедрение тестирования в Scrum
Внедрение тестирования в ScrumВнедрение тестирования в Scrum
Внедрение тестирования в ScrumDenis Petelin
 
Почему менеджеры любят Agile
Почему менеджеры любят AgileПочему менеджеры любят Agile
Почему менеджеры любят AgileDenis Petelin
 
SCRUM в больших проектах
SCRUM в больших проектахSCRUM в больших проектах
SCRUM в больших проектахDenis Petelin
 
Внедрение тестирования в Scrum
Внедрение тестирования в ScrumВнедрение тестирования в Scrum
Внедрение тестирования в ScrumDenis Petelin
 
Психология в Agile проекте
Психология в Agile проектеПсихология в Agile проекте
Психология в Agile проектеDenis Petelin
 
экономика Agile проекта
экономика Agile проектаэкономика Agile проекта
экономика Agile проектаDenis Petelin
 

Mehr von Denis Petelin (18)

Time management
Time managementTime management
Time management
 
Hitting the target - how to tame chaos
Hitting the target - how to tame chaosHitting the target - how to tame chaos
Hitting the target - how to tame chaos
 
Leadership the missed manual
Leadership   the missed manualLeadership   the missed manual
Leadership the missed manual
 
Who is manager
Who is managerWho is manager
Who is manager
 
Деньги, которые не мотивируют
Деньги, которые не мотивируютДеньги, которые не мотивируют
Деньги, которые не мотивируют
 
Self Organizing Team
Self Organizing TeamSelf Organizing Team
Self Organizing Team
 
Slid 3.0 Scrum для практиков на Vsts2008
Slid 3.0 Scrum для практиков на Vsts2008Slid 3.0 Scrum для практиков на Vsts2008
Slid 3.0 Scrum для практиков на Vsts2008
 
Pre Sales Office
Pre Sales OfficePre Sales Office
Pre Sales Office
 
Agile: Больше денег, меньше рисков
Agile: Больше денег, меньше рисковAgile: Больше денег, меньше рисков
Agile: Больше денег, меньше рисков
 
Design With Agility Workshop
Design With Agility WorkshopDesign With Agility Workshop
Design With Agility Workshop
 
Qa In Agile
Qa In AgileQa In Agile
Qa In Agile
 
Психология в Agile проекте
Психология в Agile проектеПсихология в Agile проекте
Психология в Agile проекте
 
Внедрение тестирования в Scrum
Внедрение тестирования в ScrumВнедрение тестирования в Scrum
Внедрение тестирования в Scrum
 
Почему менеджеры любят Agile
Почему менеджеры любят AgileПочему менеджеры любят Agile
Почему менеджеры любят Agile
 
SCRUM в больших проектах
SCRUM в больших проектахSCRUM в больших проектах
SCRUM в больших проектах
 
Внедрение тестирования в Scrum
Внедрение тестирования в ScrumВнедрение тестирования в Scrum
Внедрение тестирования в Scrum
 
Психология в Agile проекте
Психология в Agile проектеПсихология в Agile проекте
Психология в Agile проекте
 
экономика Agile проекта
экономика Agile проектаэкономика Agile проекта
экономика Agile проекта
 

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

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