Управление вехами и проект веб-разработки

Question

Я пытаюсь реализовать Trac + SVN. Но я столкнулся с проблемой управления проектом. Чтобы дать вам представление, большинство моих проектов связаны с веб-разработкой (они проходят через такие фазы, как дизайн, программирование, тестирование и т. Д.).

Сейчас я внедряю Trac для своих проектов. Теперь проблема в том, что я должен поставить как вехи и билеты. Для билетов, как гранулированный я должен получить? например Должен ли я сказать, сделать X частью функции Y или только функцией Y. Чем больше билетов я делаю, тем больше времени я трачу на их изготовление.

Кроме того, для вех я видел такие проекты, как CakePHP и т. Д. Когда они используют Trac, они устанавливают вехи в качестве номеров версий (соответствующих тегам в SVN). Это лучший способ?

Скажем, у меня есть клиент, конечный срок которого - X date. Затем я установил веху как 1.0 с крайним сроком как X. Но тогда как мне отслеживать проект, скажем, еженедельно? Потому что я не хочу осознавать, что за день до релиза осталось слишком много. Я хочу как-то еженедельно проверять.

Также я хочу принять во внимание улучшения / ошибки также как билеты и объединить их в вехи.

Я представлял себе что-то вроде 1.x.x, где первый x соответствует группе улучшений функций, а второй x соответствует исправлениям ошибок. Есть ли способ лучше? Как мне управлять еженедельным статусом в такой системе?

Есть ли стандартный способ сделать это? Как мне это сделать? Я полностью сбит с толку.

Спасибо.

Answer 1

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

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

• Вехи определены как точки, где у нас есть некоторые функции в подпроекте, готовом к поставке. Первый этап в каждом подпроекте обычно самый длинный. Мы обычно называем вехи как «Имя подпроекта v0.01». Версии - это просто приращения 0,01, 0,02, ... Когда мы реализуем все, что ожидается для подпроекта, мы отмечаем последний этап как v1.00. Последующие исправления ошибок ведут к вехе, которую мы отмечаем «Имя подпроекта - v1.00 - исправление»

• Описание этапа содержит только список новых функций или исправлений ошибок. Документация написана в вики и в тикетах.

• Trac Wiki обычно содержит по крайней мере одну страницу о новых функциях, которые будут реализованы в определенной вехе. Обычно это более высокий уровень описания ожидаемого поведения приложения. Часто встречаются примеры ожидаемых результатов, которые должно привести к применению.

• Билеты содержат подробное описание функции или ошибки, которые должны быть реализованы.

  • Билеты с отчетами об ошибках содержат описание ошибки и действия по ее воспроизведению (почти всегда).
  • Билеты на функции содержат подробное описание функции, которая должна быть реализована. Один билет содержит работы до 6 часов . Когда мы планируем работу, мы делим функции на диапазон от 1 до 6 часов работы. Если мы оцениваем, что эта функция требует больше времени, чем разделить ее на несколько билетов, чтобы каждый из них мог уйти за 1-6 часов работы. Мы выбрали 6 часов, потому что считаем, что это вершина, которую мы можем оценить с ошибкой не более 30% (это означает, что эта 6-часовая оценка почти всегда может быть сделана в диапазоне от 4 до 8 часов). Конечно, есть исключения из этой статистики. По нашему опыту, главная причина неправильных оценок - плохие спецификации, которые мы написали. Это почти всегда происходит потому, что мы (разработчики) неправильно понимаем бизнес-требования наших пользователей.

• Существует несколько плагинов Trac для оценки и отслеживания времени. Проверьте эту страницу: http://trac.edgewall.org/wiki/TimeTracking. Мы используем Плагин синхронизации и оценки , Вы можете ввести расчетное время для билета и время, потраченное на работу с билетом. Затем вы можете получить отчеты о том, сколько времени вы потратили на билеты / этапы и сколько времени вам нужно закончить.

Через два года мы можем довольно точно оценить время, необходимое для выполнения некоторой работы. Когда мы правильно понимаем потребности и требования пользователей, мы обычно можем выполнить их в обещанные сроки. В настоящее время наша статистика показывает, что мы переоцениваем время, необходимое для билетов, примерно на 10%.

Answer 2

Небольшое предостережение: я понятия не имею об использовании Trac ... или SVN. Я думаю, что ваши вехи не должны устанавливаться системой контроля версий / отслеживания ошибок.

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

Я склонен использовать график и задания для работы с командой. Отметьте задачи, как они сделаны. Для всех остальных я просто сообщаю о вехах. Мы собираемся сделать UAT к 15 мая? Да, мы.

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

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

Магической формулы не существует, но проекты с сотнями задач и тысячами человеко-часов могут иметь только 4 этапа.

альтернативный текст http://officeadd.in/Images/articles/ProjectMilestones-scribblea.png

Извините, это не имеет отношения к Trac и SVN напрямую, но, надеюсь, это даст вам приблизительное представление о том, как обычно используются вехи. Ох, и заранее прошу прощения за злоупотребление Comic Sans ... чёрт.

Answer 3

Я использую Trac / SVN уже два с половиной года.

Вот что я предлагаю:

• Разделите производство версии программного обеспечения на несколько итераций: начало, разработка, переход (или называйте их как хотите)
• Планирование функций для самой первой итерации. Для других улучшения плана и исправления ошибок
• Задачи (билеты) должны быть как можно более детальными, при условии, что каждый билет имеет ценный для клиента результат
• Экономия времени на создании билетов не очень хорошая идея. Более детальные и мелкие задачи - больше контроля над ходом. Таким образом, более раннее обнаружение недостатков планирования и больше времени для управления.
• Билеты могут разделяться, даже если они выполняются. Если разработчик достиг результата, который может быть показан заказчику, но не выполнил всю задачу, тогда разработчик может разделить задачу и пометить завершенную часть как «закрытую» или «решенную», что дает более детальный контроль.
• Отслеживайте прогресс ежедневно, а не еженедельно (или хотя бы несколько раз в неделю)

Trac - очень хороший инструмент. Лучшая особенность или Trac - это возможность размещать WikiLinks везде, включая комментарии к ревизиям. Если вы требуете указать номер билета в комментарии набора изменений, а затем добавить номер ревизии в комментарий к заявке, это связывает задачи и изменения с кодом. Позже эти ссылки облегчают отслеживать эволюцию программного обеспечения. Это спасение жизни, особенно если проект длится более пары месяцев.

Answer 4

Я вижу, у вас есть несколько вариантов и пара решений.

Можно подумать о Разработка, управляемая функциями . Вы можете использовать trac для поддержки связи, а не контроля. Крупнозернистые задания, детализированные билеты и ранние выпуски.

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

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

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

Отчет об ошибке не обязательно должен быть под любым из них, и может содержать столько деталей, сколько необходимо. Это мелкозернистые. Они не определяют ритм развития. Единственное исключение - спринт с ошибками, устраняющий шоу-стопперы. Публикуйте имена разработчиков с более назначенными и нерешенными ошибками, чтобы заставить их решить проблемы.

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

Я считаю, что для большинства случаев достаточно двухзначного номера версии. Первое число обозначает совместимость, а второе - выпуск. Но есть несколько переменных, которые могут быть внутри номера версии: совместимость исходного кода, двоичная совместимость, уровень исправления ошибок, выпуск, версия сопутствующего продукта (ala oracle), совместимость протокола и т. Д.

Answer 5

Установка вехи 1.0 на дату доставки - это хорошо, но вы захотите определить более ранние вехи - делайте их еженедельно, если это хороший интервал для вас, и нумеруйте их соответствующим образом. Для 4-недельного проекта, возможно, сработают 0,2, 0,5, 0,7 и 1,0. Перечислите соответствующие биты на каждом этапе: «Проект завершен», «Кодирование завершено», «Тестирование завершено» и т. Д. Если вы не достигли цели, тогда начинается настоящая работа по управлению проектом!