Нужны советы о том, как расставить приоритеты и запланировать кучу рабочих элементов - PullRequest
2 голосов
/ 25 ноября 2008

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

Список насчитывает почти 1000 наименований.

Мы - команда из 3 человек, и нам каким-то образом удалось добиться этого, используя MindMeister, Google Docs, @todos в коде и т. Д. Теперь у меня все аккуратно сгруппировано по функциям, но как мне расставить приоритеты для всех это и превратить это в график?

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

Ответы [ 3 ]

3 голосов
/ 25 ноября 2008

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

Для каждого элемента или функции вы должны ответить на вопрос: может ли продукт вообще использоваться или использоваться без этого? Если да, это может подождать; все остальное уходит в начало очереди.

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

1 голос
/ 25 ноября 2008

Мой рекомендуемый подход будет основан на лучших методиках Agile методологии ...

Итак, у вас есть то, что в терминах Agile называется «отставание» - это здорово - и важный первый шаг.

Хорошим быстрым темпом, который обычно используется, является 2-3-недельная итерация ... и в конце у вас есть набор высвобождаемых функций. Это установит «сердцебиение» вашего процесса развития. Затем вы решите, как организовать и сгруппировать функции в Истории и Задачи.

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

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

Можете ли вы сгруппировать набор функций в функциональные категории, которые могут естественно эволюционировать, чтобы описать релиз 1.0 как Систему Систем? Например, административные функции, управление профилями пользователей, отчеты, внешние слои интеграции, объекты доступа к базе данных и т. Д.

Какие простейшие сценарии / варианты использования, которые вы можете написать, будут сопоставлены с некоторыми из ~ 1000 функций / требований, которые вы определили? Выберите набор историй (или отдельные задачи из истории - если сама история слишком велика, чтобы ее можно было реализовать за одно целое). Это потребует дополнительных усилий, но важно перекомпоновать ваши требования в набор историй / задач.

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

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

0 голосов
/ 25 ноября 2008

Поскольку вы указываете, что все эти элементы необходимы, я предполагаю, что у вас мало шансов выбросить элементы из списка (по крайней мере, на данный момент). Учитывая это, у вас есть 2 большие задачи - решить, когда делать предметы, и определить, сколько времени потребуется, чтобы их выполнить.

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

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

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

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

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

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

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

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

...