Управление этапами и проектом веб-разработки
Я пытаюсь реализовать Trac+SVN. Но я сталкиваюсь с проблемой управления проектом. Чтобы дать вам фон, большинство моих проектов связаны с веб-разработкой (они проходят через этапы, такие как дизайн, программирование, тестирование и т. д.).
теперь я реализую Trac для своих проектов. Теперь проблема в том, что я должен разместить в качестве вех и билетов. Для билетов, как гранулированный я должен получить? например, я должен сказать, сделать X частью y-функции или сделать y-функцию только. Чем больше билетов я делаю, больше времени я трачу на изготовление билетов.
кроме того, для этапов я видел такие проекты, как CakePHP и т. д. Когда они используют Trac, они устанавливают свои вехи как номера версий (соответствующие тегам в SVN). Это лучший способ?
Итак, скажем, у меня есть клиент, конечный срок которого-дата X. Затем я установил свою веху как 1.0 с крайним сроком Как X. Но тогда как я могу отслеживать проект, скажем, еженедельно? Потому что я не хочу осознавать за день до даты релиза, что это слишком много. оставил. Я хочу иметь еженедельные чеки.
также я хочу учитывать улучшения / ошибки также как билеты и объединять их вместе как вехи.
Я представлял себе что-то вроде 1.X. x, где первый x соответствует группе улучшений функций, а второй x соответствует исправлениям ошибок. Есть ли лучший способ? Как управлять еженедельным статусом в такой системе?
есть ли стандартный способ сделать это? Как мне это сделать? Я полностью смущенный.
спасибо.
5 ответов
Ну, это зависит от. Вы не уточнили, насколько большой проект, сколько программистов будет работать, как часто вы планируете поставить.
заявляя, что, вот как мы используем Trac на одном большом проекте, охватывающем несколько лет, который состоит из числа небольших подпроектов.
этапы определяются как точки, где у нас есть некоторые функции в подпроекте, готовые к доставке. Первая веха в каждом подпроекте обычно самая длинная. Мы обычно имя вехи как " имя подпроекта v0.01". Версии только с шагом 0.01, 0.02, ... Когда мы реализуем все, что ожидается для подпроекта, мы отмечаем последнюю веху как v1.00. Последующие исправления ошибок переходят к этапу, который мы отмечаем " имя подпроекта-v1.00-исправление"
описание Milestone содержит только список новых функций или исправлений ошибок. Документация написана в wiki и в билетах.
Trac Wiki обычно имеют хотя бы одну страницу о новых функциях, которые будут реализованы в конкретной milestone. Обычно это описание ожидаемого поведения приложения на более высоком уровне. Часто встречаются примеры ожидаемых результатов, которые должно дать применение.
-
авиабилеты содержит подробное описание объекта или ошибки, которые должны быть реализованы.
- сообщения об ошибках билеты содержат описание ошибки и шаги для воспроизведения (почти всегда).
- характеристика билеты содержат подробное описание функции, которая должна быть реализована. Один билет содержит работа до 6 часов. Когда мы планируем работу, мы разделяем функции, чтобы быть в диапазоне от 1 до 6 часов работы. Если мы оценим, что функция требует больше времени, чем мы разделим ее на несколько билетов, чтобы каждый из них мог поместиться в 1-6 часов работы. Мы выбрали 6 часов, потому что мы чувствуем, что это вершина, которую мы можем оценить с ошибкой не более 30% (это означает, что эта оценка 6 часов почти всегда может быть сделано в диапазоне от 4-8 часов). Конечно, есть исключения из этой статистики. По нашему опыту, основная причина неправильных оценок заключается в плохих спецификациях, которые мы написали. Это, почти всегда, происходит потому, что мы (разработчики) неправильно поняли бизнес-требования наших пользователей.
есть несколько плагинов Trac для оценки и отслеживания времени. Проверьте эту страницу:http://trac.edgewall.org/wiki/TimeTracking . Мы используем Сроки И Плагин Оценки . Вы можете ввести расчетное время для билета и время, потраченное на работу над билетом. Затем вы можете получить отчеты о том, сколько времени вы потратили на билеты/вехи и сколько времени вам нужно закончить.
через два года мы можем довольно точно оценить время, необходимое для выполнения некоторой работы. Когда мы правильно понимаем потребности и требования пользователей, мы обычно можем доставить в обещанные сроки. В настоящее время наша статистика показывает, что мы переоцениваем время, необходимое для билеты примерно на 10%.
маленький нюанс: я понятия не имею об использовании трафика... или SVN. Я думаю, что ваши вехи не должны быть установлены системой контроля версий / отслеживания ошибок.
обычно вехи - это просто значимые события в вашем проекте. Они должны быть значимыми для всех заинтересованных сторон. Завершение крупного мероприятия является важной вехой. Завершение нескольких функций не является. Подписание всех планов и контрактов является значительным событием, но завершение 10 макетов нет.
Я предпочитаю использовать расписание и задачи для работы с командой. Отметьте задачи по мере их выполнения. Всем остальным я просто сообщаю о вехах. Мы собираемся сделать UAT к 15 мая? Да мы.
с вехи инструменты для отчетности перед спонсорами и другими заинтересованными сторонами, вы должны установить их, чтобы быть, что они считают важным. Мои спонсоры захотят узнать, когда будет завершен определенный основной набор функций, так что это веха. Они захотят узнать, когда UAT подписан, так что это веха.
слишком мало вех и никто не будет знать, как вы прогрессирует до конца. Установите слишком много, и значение будет потеряно.
нет волшебной формулы, но проекты с сотнями задач и тысячами человеко-часов могут иметь только 4 вехи.
alt текст http://officeadd.in/Images/articles/ProjectMilestones-scribblea.png
извините, это не относится к Trac и SVN непосредственно, но, надеюсь, это даст вам приблизительное представление о том, как обычно используются вехи. О, и заранее извиняюсь за чрезмерное использование Comic Sans... фу.
установка вашей вехи 1.0 на дату доставки в порядке, но вы захотите определить более ранние вехи - сделайте их еженедельными, если это хороший интервал для вас, и пронумеруйте их соответствующим образом. Для 4-недельного проекта, возможно, 0.2, 0.5, 0.7 и 1.0 будут работать. Перечислите соответствующие биты на каждой вехе: "дизайн завершен", "кодирование завершено", "тестирование завершено" и т. д. Если вы не на цели, то начинается настоящая работа по управлению проектами!
Я вижу, у вас есть несколько вариантов и несколько решений.
вы могли бы подумать о Особенность Driven Развития. Вы можете использовать trac для поддержки связи, а не для контроля. Крупнозернистые задачи, мелкозернистые билеты и ранние релизы.
составьте список функций, которые должны быть разработаны и заявить, что релиз, скажем... версия 1.0, происходит, когда все функции разработаны и испытаны. Сделайте билеты umbrella для всех функций. Там являются крупнозернистыми и будут определять ритм развития.
теперь определите несколько этапов на основе количества запланированных функций и времени. Первая веха должна содержать хотя бы одну функцию, так как целью вехи является создание проекта для тестирования и обратной связи. Определите одну или несколько вех, чтобы отметить, когда все функции будут завершены, назовите их "бета-версией", "кандидатом на выпуск" или как угодно.
Если во время разработки возникает необходимость в более тонких задачах, не стесняйся их делать. И поставьте задачи зонтика в зависимость от этих новых билетов.
отчет об ошибке не должен быть ни под одним из них, и может иметь столько деталей, сколько необходимо. Они мелкозернистые. Эти не определить ритм развития. Одним из исключений является ошибка squashing sprint для устранения showstoppers. Публикуйте имена разработчиков с более назначенными и не решенными ошибками, чтобы заставить их решить проблемы.
часть процесса чтобы сделать веху, бета-версия или релиз-кандидат помечают источник, чтобы сделать процесс повторяемым и иметь возможность обнаруживать ошибки, даже если источник магистрали уже изменился. На SVN обычный способ тега состоит в копировании источника магистрали в каталог на "теги" и убедитесь, что никто не фиксируется в этой ветви.
Я считаю, что номер версии с двумя номерами достаточно для большинства случаев. Первое число обозначает совместимость, а второе-выпуск. Но есть несколько переменных, которые может быть внутри номера версии: исходная совместимость, бинарная совместимость, уровень исправления, выпуск, версия сопутствующего продукта (ALA oracle), совместимость протоколов и т. д.
Я использую Trac / SVN уже два с половиной года.
вот что я предлагаю:
- разделите производство версии программного обеспечения на несколько итераций: начало, разработка, переход (или назовите их как хотите)
- планирование функций для самой первой итерации. Для других план улучшения и исправления
- задачи (билеты) должны быть максимально зернистыми при условии, что каждый билет имеет клиента-ценный результат
- экономия времени при создании билета-не очень хорошая идея. Более зернистые и более небольшие задачи - - - больше контроля над прогрессом. Таким образом, более раннее обнаружение недостатков планирования и больше времени для управления.
- билеты могут разделяться даже в процессе. Если разработчик достиг результата, который может быть показан заказчику, но не выполнил всю задачу, разработчик может разделить задачу и отметить завершенную часть как " закрытую "или" разрешенную", что дает более подробную информацию управление.
- отслеживать ежедневно, а не раз в неделю (или по крайней мере несколько раз в неделю)
Trac-очень хороший инструмент. Лучшая функция или Trac-возможность размещать WikiLinks везде, включая комментарии к набору изменений. Если вы требуете поместить тикет # в комментарий набора изменений, а затем поместить номер набора изменений в комментарий тикета, это свяжет задачи и изменения в коде. Позже эти ссылки облегчают отслеживание эволюции программного обеспечения. Это Спаситель жизни особенно, если проект выходит за рамки пары месяцев по продолжительности.