Как выглядит идеальный отчет о состоянии?

Question

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

Я хочу узнать:

• детали выполнены и сколько времени было потрачено на каждый
• проблем, с которыми сталкиваются и сколько времени было потрачено на каждый
• Элементы, которые будут разработаны на следующем, их оценки (в человеко-часах) и их целевые даты
• Вопросы они на работе

Я ищу формат, который будет предоставлять эту информацию во время:

• Будучи быстро для разработчиков, чтобы завершить (5-10 минут, не думая слишком много)
• Легко для меня читать и просматривать быстро
• едина для каждого разработчика

Что бы вы предлагать?

Answer 1

Использование Scrum. Создайте резервную копию спринта, создайте таблицу с задачами и столбцом для каждого дня спринта. Попросите людей ежедневно заполнять часы работы по каждой задаче. Отправляйте ежедневный отчет, начинающийся с графика сжигания для спринта, а затем коротких двух лайнеров для каждого члена - последний раз работал и работал дальше. Отправляйте еженедельный отчет с графиком сжигания, красным/желтым/зеленым статусом для каждой основной функции (и блокировки проблем и заметок, если она не зеленая), и оставшиеся элементы в отстающем отставании.

У меня нет ссылки на образцы, но вот некоторые проекты:

 
10/02/2008 - Product A daily status 

<Burndown chart> 

Team member A 
Last 24: feature A 
Next 24: feature A unit tests 

Team member B 
Last 24: bug jail 
Next 24: feature B 

Team member C 
Last 24: feature C 
Next 24: feature C 
Blocked on: Dependency D - still waiting on the redist from team D 

 
10/02/2008 - Product A weekly status 

<Burndown chart> 

**Feature A** - Green 
[note: red/yellow/green represents status; use background color as well for better visualisation] 
On track 

**Feature B** - Yellow 
[note: red/yellow/green represents status; use background color as well for better visualisation] 
Slipping a day due to bug jail 
Mitigation: will load balance unit tests on team member A 

**Feature C** - Red 
[note: red/yellow/green represents status; use background color as well for better visualisation] 
Feature is blocked on external dependency from team D. No ETA on unblock. 
Mitigation: consider cutting the feature for this sprint 

**Milestone schedule:** 
Planning complete - 9/15 (two weeks of planning) 
Code complete - 10/15 (four weeks of coding) 
RC - 10/30 (two weeks stabilization and testing) 

Answer 2

Просто дайте им шаблон, выложенный в формате, который вы ожидаете увидеть возвращенными данными. Вы также можете подумать о том, чтобы увеличить время, которое они собираются посвятить этому, и снять предложение «не слишком много думая», если вы требуются оценки для будущей работы. Я бы не стал доверять оценке, которую кто-то придумал через 5 минут. не думая.

Если вы в настоящее время используете какое-либо программное обеспечение для управления проектами, разработчикам должно быть тривиально записывать и анализировать (или даже просто помнить), что они сделали для его компиляции. В идеале они будут записывать вопросы или вопросы в течение дня и не пытаться придумать их, чтобы заполнить отчет.

Кажется, что ваш список «Я хочу узнать» - отличная отправная точка для создания шаблона. Только вы узнаете, какой для вас идеальный формат.

Answer 3

Похоже, что вы хотите сделать Extreme Programming стоять встречи.

http://www.extremeprogramming.org/rules/standupmeeting.html

Вы можете поговорить кремовый членов команды сайта с помощью телефона с laudspeaker, или какой-то VOIP.

Answer 4

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

Существует множество вариантов для достижения этой цели, но все они рискуют сделать процесс более сложным и трудоемким. Некоторые из них могут быть следующими:

Онлайн-форма с разделами для каждой или нескольких листов, каждая из которых является секцией.

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

Альтернативой этому может быть использование некоторого инструмента управления проектами, который подрядчики заполнили, пока они работают, и о котором вы могли бы сообщить в любое время. Я бы порекомендовал Thoughtworks Studio Mingle, но он полагается на гибкий процесс.

Answer 5

вы, вероятно, не хотят слышать это, но здесь это так или иначе -

я был в этой ситуации по обе стороны стола, и пришли к выводу, что эти виды отчетов закатанными состояния это полная трата времени для вас и разработчиков. Вот почему:

• разработчики должны работать на особенности/результатов с заданными сроками
• разработчики должны задавать вопросы, когда они происходят
• коммуникация должна протекать в обоих направлениях по мере необходимости

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

на девелопменте операционная сторона забора - «быстрый пятиминутный статус» [я ненавижу эту фразу, пять минут не быстро!] прерывает поток разработчика, вызывая потерю пятнадцати минут (или более) производительности (joel даже пишет об этом блоге думать). Но даже если это на самом деле всего пять минут, если у вас есть дюжина разработчиков, то вы тратите пять человеко-часов в неделю на Administrivia (и это, вероятно, больше как 20)

на менеджера стороне забора - свертывание отчетов о статусе отдельных лиц в команды по проекту и т. д. - непроизводительная работа, которая также тратит ваше время. Скорее всего, никто даже не читает отчеты.

, но вот настоящая проблема: этот вид отчетности и свертывания может указывать на реактивное управление вместо активного управления. Другими словами, не имеет значения, какая методология используется - scrum, xp, agile, rational, waterfall, home-grow или что-то еще - если проект правильно спланирован и выполнен, то вы уже должны знать, что делают все, потому что планировалось заранее. И неважно, планировалось ли это утром или полгода назад.

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

Что касается требований клиента, если они абсолютно настаивают на этом тинете [и я знаю, что, например, некоторые государственные учреждения делают], то лучшим вариантом является предоставление веб-интерфейса или другого приложения для автоматизации скуки это сделает вам сверток. Вы все равно будете тратить время разработчиков, но, по крайней мере, вы не будете тратить свое время ;-)

ах, и чтобы ответить на ваш вопрос буквально: в отчете о совершенном статусе говорится: «На цель с планом проекта », и ничего более ;-)