none
TFS Cloud 2011 - учет времени в SCRUM 2.0 RRS feed

  • Вопрос

  • Начали активно использовать SCRUM в TFS Cloud. Руководство тут же потребовало отчет о затраченном времени на каждую задачу, а именно, сколько планировали и сколько фактически потрачено.

    Мы работаем следующим образом:

    1. Все будущие работы хранятся в специальном спринте "Future Releases" как элементы PBI.

    2. На следующий спринт мы переносим эти работы из "Future Releases" и уточняем Effort (не в часах - может быть нужно было и в часах)

    3. Затем каждая работа (PBI) декомпозируется на несколько задач (Task) с указанием времени "Remaining Work" (в часах) и раздается на разных сотрудников.

    4. По ходу выполнения "Remaining Work" уменьшаем вручную или меняем статус на DONE и это поле обнуляется.

    5. Для всех членов команды указано capacity (8 ч/д) на текущий спринт.

    Вопросы:

    • Где найти первоначальное время, которое выделялось на работу? Какой должен быть правильный подход, кроме вычисления Velocity?
    • Почему в Agile-проекте это есть?
    • И в чем идеологическая разница между типами проектов Agile и SCRUM?
    • Есть ли возможность "допилить" проект под себя в облаке или эта фича доступна для стандартной установки?
    • Изменено SergPn 8 мая 2012 г. 9:59

Ответы

  • Давайте я вам раскажу страшную штуку по Scrum.

    Если вы планируете спринт. Количество фич руководство устраивает. Вы все фичи реализовали. То посылайте руководство с его желанием узнать сколько часов это заняло. Часы, нужны только в процессе, для тимлида и команды, чтобы оценить, не пора ли начать напрягаться, чтобы все успеть.

    Допилить облако нельзя. По крайней мере так сказали на ALM самите: Это не баг, это фича."

    • Помечено в качестве ответа SergPn 9 мая 2012 г. 11:45
    Отвечающий
  • Effort для таска не имеет смысла. Effort - это грубая оценка фичи (в попугаях, идеальных часах). А таск - это небольшой, предсказуемый кусок работы, с размером в до 16 часов.

    Сам смысл именно PBI для оценки Velocity - исключить из Velocity фичи, которые недоделаны. Написано, но не протестировано == "не сделано", 0. А если вы начнете проставлять и учитывать Effort по таскам - то быстро получите картину типа "все сделано, велосити зашкаливает. но ничего не готово - нужно еще исправить баги и задеплоить".

    • Помечено в качестве ответа SergPn 9 мая 2012 г. 11:45
    • Снята пометка об ответе SergPn 9 мая 2012 г. 12:22
    • Помечено в качестве ответа SergPn 9 мая 2012 г. 12:22
    Модератор
  • Согласен с PashaPash. Вы немного путаете понятия. PBI = некая полезность для конечного пользователя (ну или для всего проекта в целом, например, повышение производительности). Task - это конкретная задача, для получения PBI. У нас, например, в команде и документописатель и тестировщик. Поэтому PBI в 4 Effort может иметь вот такие задачи:

    1. Поправить модель базы данных, добавив сущность ... - 1 час

    2. В компонент ... добавить отображение сущности ... - 2 часа

    3. В приложение администрирования добавить функционал заполнения ... - 3 часа

    4. Протестировать добавление и просмотр ... - 1 час

    5. Внести изменения в пользовательские инструкции ... - 1 час

    Смотрим на SprintBurnDown и понимаем, сколько нам еще часо необходимо отработать.

    А когда заказчик фичу принял, мы понимаем, что 6 Effort-ов добавляеться к производительности команды за этот Sprint. Почитайте что нибудь про Scrum.

    Мне очень понравилась книжка "SCRUM И KANBAN: ВЫЖИМАЕМ МАКСИМУМ" от Хенрика Книберга и Маттаса Скарина (рус)
    "Scrum и XP: заметки с передовой" от одного Хенрика Книберга (рус)
    Спорно, но интересно: 10 kanban досок и их контекст


    Отвечающий
  • Команда должна реализовывать фичи! Никакого подушевого учета! Это демотивирует! Все оценки только команде. Премия? На всю команду! Выговор? Всей команде! Так и только так, вы добьетесь сплоченности.

    По поводу тестировщика, если у него есть время (а оно есть, как минимум в начале, пока ни один PBI не закончен), он может писать Test Case для PBI которые еще в работе, планировать тестирование, помогать документописателю, участвовать с архитектором в проработке архитектуры (чтобы потом можно было протестировать тебования предъявляемые к ней). В конце, когда программисты уже закончили основную часть работы и сидят на исправлении багов, никто не мешает им помочь тестировщику проверить функционирование по уже написанным Test Case.

    Пробуйте, экспереминтируйте, но запомните: все за пределами команды должны рассматривать ее как единое целое. У вас команда 5 человек, спринт 2 недели. Вот, считайте, у вас 5*5*8*2 = 400 часов (минут больничные, отпуска и прочие риски). Если заказчика устраивает функционал/400 часов, все, расслабтесь и получайте удовольствие. Если нет, то повышайте эффективность команды (но не за счет введения новых людей, будет только хуже).

    • Помечено в качестве ответа SergPn 9 мая 2012 г. 12:08
    Отвечающий

Все ответы

  • Давайте я вам раскажу страшную штуку по Scrum.

    Если вы планируете спринт. Количество фич руководство устраивает. Вы все фичи реализовали. То посылайте руководство с его желанием узнать сколько часов это заняло. Часы, нужны только в процессе, для тимлида и команды, чтобы оценить, не пора ли начать напрягаться, чтобы все успеть.

    Допилить облако нельзя. По крайней мере так сказали на ALM самите: Это не баг, это фича."

    • Помечено в качестве ответа SergPn 9 мая 2012 г. 11:45
    Отвечающий
  • Спасибо :-)

    Хотя было бы неплохо иметь возможность указывать Effort для Task, чтобы не плодить PBI для оценки velocity...


    SergPn

  • Effort для таска не имеет смысла. Effort - это грубая оценка фичи (в попугаях, идеальных часах). А таск - это небольшой, предсказуемый кусок работы, с размером в до 16 часов.

    Сам смысл именно PBI для оценки Velocity - исключить из Velocity фичи, которые недоделаны. Написано, но не протестировано == "не сделано", 0. А если вы начнете проставлять и учитывать Effort по таскам - то быстро получите картину типа "все сделано, велосити зашкаливает. но ничего не готово - нужно еще исправить баги и задеплоить".

    • Помечено в качестве ответа SergPn 9 мая 2012 г. 11:45
    • Снята пометка об ответе SergPn 9 мая 2012 г. 12:22
    • Помечено в качестве ответа SergPn 9 мая 2012 г. 12:22
    Модератор
  • Согласен с PashaPash. Вы немного путаете понятия. PBI = некая полезность для конечного пользователя (ну или для всего проекта в целом, например, повышение производительности). Task - это конкретная задача, для получения PBI. У нас, например, в команде и документописатель и тестировщик. Поэтому PBI в 4 Effort может иметь вот такие задачи:

    1. Поправить модель базы данных, добавив сущность ... - 1 час

    2. В компонент ... добавить отображение сущности ... - 2 часа

    3. В приложение администрирования добавить функционал заполнения ... - 3 часа

    4. Протестировать добавление и просмотр ... - 1 час

    5. Внести изменения в пользовательские инструкции ... - 1 час

    Смотрим на SprintBurnDown и понимаем, сколько нам еще часо необходимо отработать.

    А когда заказчик фичу принял, мы понимаем, что 6 Effort-ов добавляеться к производительности команды за этот Sprint. Почитайте что нибудь про Scrum.

    Мне очень понравилась книжка "SCRUM И KANBAN: ВЫЖИМАЕМ МАКСИМУМ" от Хенрика Книберга и Маттаса Скарина (рус)
    "Scrum и XP: заметки с передовой" от одного Хенрика Книберга (рус)
    Спорно, но интересно: 10 kanban досок и их контекст


    Отвечающий
  • С Пашей согласен.

    В общем мы так и делаем, как описал Алексей. Нас смущает только один момент. Задача после окончания теряет информацию сколько часов на нее выделялось и в итоге мы не можем оценить индивидуальные затраты времени (кто 1 час, кто 2 часа) участников команды: разработчика БД, разработчика клиентской части, тестировщика и т.д. Если взять пример Алексея, то тестировщик был занят на фичу 1 час. Если за спринт было 5 фич, то загрузка тестировщика была всего 5 часов. В текущей реализации SCRUM 2.0 по окончании спринта мы не увидим фактическую загрузку людей. Поэтому для планирования человеческих ресурсов нужно использовать дополнительные инструменты, а хотелось бы иметь все в одном месте. 

    Еще хотелось бы увидеть корреляцию между Effort на фичу и часами на задачи, которые эту фичу реализовуют.


    SergPn


    • Изменено SergPn 9 мая 2012 г. 12:06
  • Команда должна реализовывать фичи! Никакого подушевого учета! Это демотивирует! Все оценки только команде. Премия? На всю команду! Выговор? Всей команде! Так и только так, вы добьетесь сплоченности.

    По поводу тестировщика, если у него есть время (а оно есть, как минимум в начале, пока ни один PBI не закончен), он может писать Test Case для PBI которые еще в работе, планировать тестирование, помогать документописателю, участвовать с архитектором в проработке архитектуры (чтобы потом можно было протестировать тебования предъявляемые к ней). В конце, когда программисты уже закончили основную часть работы и сидят на исправлении багов, никто не мешает им помочь тестировщику проверить функционирование по уже написанным Test Case.

    Пробуйте, экспереминтируйте, но запомните: все за пределами команды должны рассматривать ее как единое целое. У вас команда 5 человек, спринт 2 недели. Вот, считайте, у вас 5*5*8*2 = 400 часов (минут больничные, отпуска и прочие риски). Если заказчика устраивает функционал/400 часов, все, расслабтесь и получайте удовольствие. Если нет, то повышайте эффективность команды (но не за счет введения новых людей, будет только хуже).

    • Помечено в качестве ответа SergPn 9 мая 2012 г. 12:08
    Отвечающий
  • Команда должна реализовывать фичи! Никакого подушевого учета! Это демотивирует! Все оценки только команде. Премия? На всю команду! Выговор? Всей команде! Так и только так, вы добьетесь сплоченности.

    По поводу тестировщика, если у него есть время (а оно есть, как минимум в начале, пока ни один PBI не закончен), он может писать Test Case для PBI которые еще в работе, планировать тестирование, помогать документописателю, участвовать с архитектором в проработке архитектуры (чтобы потом можно было протестировать тебования предъявляемые к ней). В конце, когда программисты уже закончили основную часть работы и сидят на исправлении багов, никто не мешает им помочь тестировщику проверить функционирование по уже написанным Test Case.

    Пробуйте, экспереминтируйте, но запомните: все за пределами команды должны рассматривать ее как единое целое. У вас команда 5 человек, спринт 2 недели. Вот, считайте, у вас 5*5*8*2 = 400 часов (минут больничные, отпуска и прочие риски). Если заказчика устраивает функционал/400 часов, все, расслабтесь и получайте удовольствие. Если нет, то повышайте эффективность команды (но не за счет введения новых людей, будет только хуже).

    Отличный принцип. Двумя руками за!

    SergPn