Метрики в Scrum

[olegstepanov]

Вот дядя Боб сетует, что раз в Скраме все нацелены на быстрое производство фич, качество исполнения быстро падает и код превращается в кашу. Это отчасти правда: если так ставить цели, то придем, конечно, к ужасному коду.

Интересно, что в качестве лекарства предлагается куча метрик и привязанная к ним компенсация. При этом общепринятой считается

Comments

[shisha_hwguy]

Мы делали Аллоды как раз по идеям Scrum. И столкнулись с тем, о чем ты говоришь. Но вроде как код у нас не самого плохого качества

[olegstepanov]

Тут два пункта: поддержка и удовлетворенность команты (хорошие люди в говне долго копаться не будут). Мы для выравнивания технических проблем выделяем технические дни, а иногда и технические спринты. Да и вообще у нас скорость не так важна (мы не меряем velocity особо и не рассчитываем, что возьмем в спринте фиксированное число идеальных дней).

[shisha_hwguy]

Копаться в говне это все же некая крайность. Все же доводить до подбного нельзя.
У нас программисты чаще говорят о назревающих рефакторингах. Т.е. ситуации когда они еще не придумали как код надо переписать, но чувствуют, что идея уже рядом.
Технические дни, это не всегда возможно. Крупный кусок за день можно не успеть переписать. А технический спринт вообще очень большая роскошь. Вам можно только завидовать.

[johnny_job]

Скрам в чистом виде применим разве что к обезьянам. Ну, может ещё к индусам :-)