Если вы поняли это и никто не имеет, и вы хотите, чтобы проект преуспел, то вам решать добавить несколько дополнительных часов и составить план, а затем продать его людям, которые номинально ответственны за принятие решений.
Реальные проекты имеют «перезагрузки». Это не означает, что вы выбрасываете всю свою существующую работу. Это означает, что вы найдете новую оболочку, чтобы она соответствовала деталям этой работы. Это намного проще, если ваша работа - так далеко - состоит из хорошо понятых самосогласованных небольших компонентов, слабо связанных друг с другом. Вот почему люди так работают, потому что они знают по опыту, что им придется переделывать вещи. Почти все функции, добавленные к языкам программирования на протяжении десятилетий, объясняются тем, что мы знаем, что каждый фрагмент кода, который мы пишем, может быть изменен - он может выжить, но, вероятно, придется справиться с множеством незнакомых сред на путешествие в отпуск.
Таким образом, вы заметили, что соответствующая информация возникает постоянно, на протяжении всего проекта. Это не удобно, если вы все показываете в одном пакете прямо перед тем, как начать вводить код. Написание документа спецификации вообще не решает эту проблему. Поэтому вам нужно изменить способ работы, чтобы проект рисовал новую информацию все время - новая новая информация извне - это еда, которая продвигает ваш проект вперед. Постарайтесь с нетерпением ждать каждого нового удивительного откровения и приветствовать его как друга!
Что это значит? Это означает, что «архитектурные» части проекта не более стабильны, чем «маленькие детали». Вы должны иметь возможность изменять архитектуру. Вначале у вас недостаточно информации, чтобы принимать какое-либо постоянное решение.
Основная проблема заключается в том, что у вас есть проект на восемь месяцев. Реальные восьмимесячные проекты (те, которые преуспевают вовремя) на самом деле, если вы внимательно посмотрите, много более коротких проектов: 16 двухнедельных проектов идеально.
Вам необходимо поставить все цели проекта (до сих пор) в большой список в приоритетном порядке. Напишите каждое требование функции с точки зрения пользователя. «Пользователь должен быть в состоянии бла-бла-бла», такого рода вещи. Избегайте говорить о технических проблемах текущего дизайна. Подумайте о том, как пользователь будет иметь дело с отсутствием какого-либо продукта (или того, что они в настоящее время используют), и поговорить о том, как их опыт будет улучшен с помощью определенной функции.
Важным является порядок приоритетов. Цель состоит в том, чтобы иметь возможность сказать: у нас есть только время, чтобы отправить первые 10 предметов. Это лучше, чем 9 предметов, что в свою очередь лучше 8 и т. Д. Но даже с 8 элементами это было бы лучше, чем ничего, потому что каждый элемент является особенностью, которая сама по себе улучшит опыт пользователя.
Этот список называется отставанием.
Если вы сравниваете свою работу с отставанием, вы, как правило, обнаружите, что работаете с низкоприоритетными вещами, потому что, по вашему мнению, вам понадобится это позже. Старайтесь не делать этого с этого момента. Низкий приоритет - низкий приоритет. Что делать, если появляются новые запросы с более высоким приоритетом между датой отправки и отправкой? Они почти наверняка будут! Несмотря на то, что некоторые люди будут требовать («Это будет абсолютно бесполезно без функции A!»), Вы, вероятно, могли бы поставлять ни одну из функций A, ни функцию B. Но если вам нужно было выбрать один, вы бы пошли с функцией A. И вы вполне может потребоваться отправить без функции B из-за нехватки времени. Поэтому не ставьте под угрозу A ради того, чтобы быть «готовым» для добавления B позже. Только подготовитесь заранее, если это будет стоить вам почти ничего - оставьте места, где вы можете добавить вещи, сделать все возможное, но не если это замедлит вас сейчас.
Затем приступайте к работе над новой версией продукта (запрещающей работу, проделанную до сих пор там, где это имеет смысл), которая заботится о первых элементах списка - минимальном минимуме. Не тратьте больше недели на это. Неделя составляет 6,25% от оставшегося времени, поэтому на самом деле это довольно дорого. Но в конце этого вы имеете представление о том, что вы готовы к отправке до сих пор. Это единственный способ измерить ваш прогресс с этого момента.
Остальная часть вашего проекта состоит из:
Многократно проворачивать новые рабочие версии продукта, каждый раз добавляя несколько функций из списка приоритетов. Получите небольшое сообщество пользователей для работы с каждой версией и дайте прямую обратную связь своей команде. Стремитесь сделать новую версию каждые две недели.
Превращение отзывов пользователей в новые «истории» для перехода «на отставание».Это, конечно, связано с их приоритетом.
Вы можете сделать это снова и снова, в коротких итераций, пока не закончится время (вы, вероятно, есть время, чтобы сделать шесть-восемь повторений). В конце каждой итерации у вас есть что-то для доставки, которое «лучше» (имеет более высокоприоритетные функции, содержит больше отзывов), чем то, что было у вас в конце предыдущей итерации. Это прогресс.
Каждый выпуск в конце итерации имеет две цели: показать прогресс и, конечно же, сделать сообщество пользователей более счастливым, но также получить больше отзывов, чтобы узнать новую информацию. Каждая версия - это решение и зонд. Этот двойной характер продолжается после первого публичного выпуска. Публичный релиз - это глубокий космический зонд, который вы отправляете в солнечную систему для отправки фотографий странных новых миров (в виде следов стека исключений).
Все это научное и рациональное. Вы принимаете решения о порядке работы на основе приоритетного порядка. Вы получаете постоянную обратную связь на основе рабочей версии своего продукта, вместо того, чтобы угадывать обратную связь, которую вы получите от воображаемой версии вашего продукта.
Люди будут реагировать на этот подход, заявив, что он будет ужасно «неэффективным». Эффективность - относительный термин. Проекты, которые не работают таким образом, всегда заканчивают работу таким образом, в конце концов. Но «в конце» очень поздно. Обычно существует безумная паника за дополнительные N месяцев после первоначального срока, когда проект продолжает выпускать повторяющиеся версии продукта, которые все «почти правы» или «почти сделаны», в сумасшедшей самообманутой пародии на итеративное развитие.
К счастью, вы можете начать думать и работать таким образом в любое время. Лучше начать на полпути к первоначальному сроку, чем вскоре после него.
Очень хорошая ссылка ... спасибо HotTester. – 2010-02-17 06:59:37