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

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

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

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

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

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

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

Есть стандартный способ сделать это? Как мне это сделать? Совершенно запутался.

Спасибо.


person Alec Smart    schedule 03.04.2009    source источник


Ответы (5)


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

Говоря об этом, вот как мы используем Trac в одном большом проекте, охватывающем несколько лет, который состоит из нескольких более мелких подпроектов.

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

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

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

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

    • Bug reporting tickets contain description of bug and steps to reproduce (almost always).
    • Тикеты функций содержат подробное описание функции, которая должна быть реализована. Один билет содержит работу до 6 часов. Когда мы планируем работу, мы разделяем функции в диапазоне от 1 до 6 часов работы. Если мы оценим, что для этой функции требуется больше времени, мы разделим ее на несколько тикетов, чтобы каждая из них могла уместиться в 1-6 часов работы. Мы выбрали 6 часов, потому что считаем, что это максимум, который мы можем оценить с ошибкой не более 30% (это означает, что эта 6-часовая оценка почти всегда может быть сделана в диапазоне от 4 до 8 часов). Конечно, из этой статистики есть исключения. По нашему опыту, основная причина неправильных оценок кроется в плохих спецификациях, которые мы написали. Это почти всегда происходит из-за того, что мы (разработчики) неправильно понимаем бизнес-требования наших пользователей.
  • Есть несколько плагинов Trac для оценки и отслеживания времени. Проверьте эту страницу: http://trac.edgewall.org/wiki/TimeTracking. Мы используем подключаемый модуль времени и оценки. Вы можете ввести расчетное время для заявки и время, потраченное на работу над заявкой. Затем вы можете получать отчеты, сколько времени вы потратили на тикеты / вехи и сколько времени вам нужно, чтобы закончить.

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

person zendar    schedule 09.04.2009

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

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

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

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

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

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

http://officeadd.in/Images/articles/ProjectMilestones-scribblea.png

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

person Mark Nold    schedule 10.04.2009

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

person Harper Shelby    schedule 03.04.2009
comment
А как насчет билетов? На что будет похож каждый билет? - person Alec Smart; 04.04.2009

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

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

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

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

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

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

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

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

person Community    schedule 07.04.2009

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

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

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

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

person Max Kosyakov    schedule 10.04.2009