Метрики в Scrum

[olegstepanov]

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

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

Comments

[shisha_hwguy]

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

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

2. Когда делаешь метрики, надо всегда держать в голове не то, что ты хочешь нечто запретить, а то, что людям надо подсказать, как делать правильно. Иначе ты будешь регулярно попадать в ситуацию "Неправо пойдешь коня потеряешь, налево пойдешь ..." когда вообще не понятно а что делать то.

3. И еще надо всегда помнить о человеческой лени. Надо делать так, чтобы правильный путь, был наиболее прост и приятен. Тогда людям не придет в голову с него сходить, ведь им будет просто лень искать способы обхода запретов, когда легально все делается просто.

4. Сроки сдачи функционала действительно стоят на первом месте. И когда он сдается, важно чтобы все работало, а как написан код дело не очень принципиальное, ведь от этого прибыль не зависит.

5. Писать код сразу красиво и правильно зачастую невозможно, т.к. требования могут меняться очень быстро. Это еще одна причина почему на красоту в начале забивают.

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

[olegstepanov]

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

[shisha_hwguy]

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