Weekly linkdump #55

Интересные ссылки за неделю:

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

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

Andrey Khavryuchenko Founder в DevNullAI 20.09.2010 19:06

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

Відповісти

Підтримати