Нужны советы о том, как распределять приоритеты и планировать кучу рабочих элементов.

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

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

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

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