Pull to refresh

Comments 8

UFO just landed and posted this here
Как я понял предложенная методика никак не ограничивает и не обязывает использование или неиспользование парного программирования (ПП). В случае ПП можно назначать задачи на участников, а можно и не назначать.
UFO just landed and posted this here
Экстримальное программирование — это часть семейства Agile, так что вы совершенно правы в том, что понятия скорость и «принцип вчерашней погоды» заимствованы оттуда, однако похожими понятиями пользуются и другие методологии из семейства.

Однако, приведенной в моей статье формулы вы там не встретите, и вообще в «планировании» все очень абстрактно описано, как идея — замечательно, но как это использовать… я представил свой вариант практического применения.
Практика показывает что заказчиков куда как проще настроить на нечеткие сроки завершения работ, если они регулярно видят прогресс в разработке продукта
расшифруйте пожалуйста «нечеткие» — это погрешность в день или месяц?

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

а если говорить о заказной разработке (не r&d), то заказчика всегда интересует срок и стоимость, имхо, даже если есть видимость прогресса
хоть день, хоть месяц. Мало какие проекты не могут быть не завершены в некий час Х. Многие из них могут терпеть отсрочки.

А заказчику, имхо, на мой взгляд важнее знать как движется проект, нежели узнать что в назначенный срок проект еще не готов и все равно ждать те-же дополнитнльные несколько недель или месяцев. В первом случае он сможет подготовиться к этому, а во втором — уже нет. И будет так, что тетр заказан, концерт оплачен, а дирежер напился.
Только нужно учитывать что команда даст хорошую оценку только в том случае если задача хорошо формализована.
Sign up to leave a comment.