Lesson 204

И сам не заметил как перевалил за вторую сотню...
Надеюсь, до лета успею перевести все.

Слово Канеру

Поэтапные отчеты полезны, когда этапы четко определены.

Некоторые компании ведут свои проекты по этапам и делают тщательную оценку статуса продукта на каждом этапе. Другие этого не делают.

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

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

Если вас попросили оценить прогресс относительно этапа у которого нет определения, мы предполагаем, что вы добьетесь от руководства согласия с определением и лишь затем дадите оценку относительно него. Если у вас просят совета по определению этапа, то можно сделать предположение, что этап это завершение итерации. Каковы критерии ее завершения? ( или каковы критерии начала следующей итерации?) Работа Lawrence и Johnson's (1998) в этом плане очень полезна и распространяется бесплатно.

См. http://www.coyotevalley.com/plc/builder.htm -полезные примеры подобных определений. Мы не считаем их «правильными» и мы не думаем, что Lawrence или Johnson считают их «правильными». Они лишь иллюстрируют критерии, которые могут быть применимы для определения этапов и которые являются хорошей отправной точкой для компаний, которые находятся на этапе создания своих определений.