Weekly linkdump #55
Макс ИщенкоОпубликовано 17.11.2006 в Ссылки
Интересные ссылки за неделю:
- ChangeLogs writing How-To — как писать commit messages and changelogs
- Rigid Agile? — негибкая “гибкая” разработка
- And Sun Said, Set My Java Free: The Open Source Q&A — GPL Java, безусловно, событие года
- RailsVsDjango — объемный документ, претендующий на нейтральную точку зрения.
- Top10 лжи о Web 2.0 (БлоGнот)
- BlueScreen Screen Saver v3.2 — хороший скринсейвер от Microsoft
Понравилась статья? Подпишись на обновления по RSS/E-mail

Re “Rigid Agile”. tail -f /dev/mind: No such device found.
Аналіз, зроблений на AgileAdvice, абсолютно вірний. І до тих пір, доки не вдасться звести разом:
– сейлза, що хоче “двогодинну” фічу “на вчора”
– замовника поточного проекту
– розробників
якого-небуть пристойного рішення знайдено не буде.
Більше того, навіть за наявності такого спілкування, наприклад коли сейлз і замовник поточного проекту – одна і та ж людина, неможливо гарантувати що буде розроблено домовленність, що влаштує всіх.
А відбувається це тому, що замовник поточного проекту оцінює будь-які слова, сказані розробниками як обіцянку. Навіть якщо тричі письмово 24-м кеглем було написано, що це тільки оцінка
І, звичайно, питаючи чи можна додати ще й “термінову маленьку двогодинну фічу”, він очікує на те, що всі попередні зобов’язання будуть виконані. НАВІТЬ ЯКЩО ВІН КАЖЕ ПРОТИЛЕЖНЕ! (невже хтось чекає, що він _своїм_ замовникам скаже що він власноруч віддалив результат? ха! завжди крайніми будуть розробники!)
Отже. Єдиним _чистим_ рішенням, якщо це трапляється на початку ітерації – це злити план в /dev/null і перепланувати ітерацію. Перезаключивши всі домовленності по ній.
Або дійсно, сказати, що нічого на цій ітерації не гарантується.
А для тих, хто вважає що є інше рішення, у мене є чудовий проект “з фіксованими вимогами”. І Бруклинській міст в придачу.
Вдалої розробки!