Как Microsoft Devdiv Использует Tfs — Части 4 И 5



Планирование выпуска В предыдущих постах я рассказывал о том, как мы используем TFS для реализации процессов.

В этом мы поговорим о том, как мы планировали релиз.

В записи рабочего элемента «Функция» мы добавили вкладку «Планирование»:

Как Microsoft DevDiv использует TFS — части 4 и 5

Давайте увеличим:

Как Microsoft DevDiv использует TFS — части 4 и 5

Мы просили людей рассчитать ориентировочную стоимость каждой функции в рабочем элементе.

Затем мы перенесли их в таблицу с рейтингом, как показано ниже:

Как Microsoft DevDiv использует TFS — части 4 и 5

Эта электронная таблица Excel напрямую связана с TFS. Важно отметить следующее:

  1. Этот показатель (как и все другие данные) поступает непосредственно из TFS. И это здорово, так как все расчетные данные вносились независимо друг от друга, но могут быть выведены в единый документ, что упрощает планирование.

  2. Мы ранжировали весь функционал сверху вниз.

  3. Мы добавили в таблицу логику, чтобы можно было сравнить общую нагрузку с потенциалом команды.

    Команды выделяются желтым цветом, если они используют более 70% своих резервов, и красным, если они используют более 100%.

Такой подход позволяет нам быстро понять, что можно, а что нельзя делать, не возясь с электронными таблицами.

Это помогло нам найти слабые места и спланировать, изменив приоритеты функциональности для достижения комфортного уровня нагрузки.

Например, мы переместили некоторые крупные функции вниз, чтобы в релиз вошли несколько небольших функций.

Честно говоря, через некоторое время это становится похоже на видеоигру.

Мы назвали это «желто-красной игрой», потому что было интересно увидеть, насколько нам удалось уменьшить количество желтого и красного! :) Следующий пост: как мы контролировали ход работ. Грегг Боер.

Ссылка на оригинал .



Мониторинг хода работы

Прежде чем мы начнем говорить об управлении производительностью, будет полезно рассмотреть жизненный цикл функциональности, который обсуждался в разделе предыдущий пост .

Изображение ниже станет отправной точкой для этого поста.



Как Microsoft DevDiv использует TFS — части 4 и 5

На рисунке ниже показана вкладка «Прогресс» рабочего элемента типа «Функция».



Как Microsoft DevDiv использует TFS — части 4 и 5

Проще говоря, вот мой отчет о состоянии.

Мне как человеку, работающему над функционалом, нужно было заполнять такой отчет раз в неделю.

Не было необходимости использовать электронную почту или создавать документы, я просто обновил поля в этом разделе.

Когда подразделение разработчиков решило внедрить модель команды разработки фичи, а также все характеристики качества (в оригинале — Quality Gates), мы решили не вмешиваться в процессы управления, которые команды разработки фичи приняли для себя.

Кто-то использовал метод «водопада» с MS Project, кто-то — SCRUM, кто-то — Excel или клеил стикеры, а кто-то просто рисовал на доске.

На самом деле это не имело никакого значения для подразделения в целом, если вы обновляли информацию в разделе, показанном выше.

Вкладка «Прогресс» стала стандартом департамента для предоставления минимального набора информации, необходимой для еженедельного общения.

Глядя на эту закладку, можно подумать, что это слишком примитивная и простая игра.

Однако факт в том, что он стал очень полезным инструментом отчетности.

И об этом будет подробно сказано в последующих публикациях.

Давайте подробнее рассмотрим все элементы этой картинки.

  1. Ключевые даты.

    Мы отслеживали четыре ключевые даты: начало и конец работы над функцией и две промежуточные даты.

    ВАЖНОЕ ПРИМЕЧАНИЕ: прежде чем приступить к реализации функционала, команда должна исправить контрольная дата № 1 и оценивать наступления контрольной даты №2, а также даты завершения данной работы.

    Когда наступает контрольная дата № 1, команда исправления контрольная дата №2 и оценивает дата завершения работы.

    Я считаю, что эта модель сработала хорошо.

  2. Процент выполнения — просто ожидаемая и завершенная работа по всем функциям.

    Поскольку мы не вмешивались в процессы управления внутри команд, мы требовали, чтобы они четко понимали, сколько уже сделано и сколько еще предстоит сделать.

  3. Уровень риска – первое поле, как у классического светофора, в индикаторе риска.

    Зеленый = мы соблюдаем сроки, Желтый = есть риск срыва сроков, Красный = мы пропустили сроки.

    Второе поле содержит текстовые комментарии.

  4. Дополнительные важные даты.

  5. Текстовые заметки о статусе работы.

В следующем посте я покажу вам, как мы использовали описанную выше информацию для контроля реализации нескольких функций одновременно, а также уроки, которые мы извлекли.

Теги: #microsoft #tfs

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.