Книга: Scrum и XP: заметки с передовой

Изменения. Быть или не быть

Изменения. Быть или не быть

Предположим, команда пришла к выводу, что «мы слишком слабо общались внутри команды, поэтому мы постоянно мешали друг другу и переделывали архитектурные решения».

Что нам с этим делать? Организовать ежедневные встречи для обсуждения архитектуры? Внедрить новые средства, чтобы упростить общение? Создать больше страниц в wiki? Может, и да. А может, и нет.

Оказалось, что достаточно всего лишь четко определить проблему, и она часто решается сама собой в следующем спринте. В особенности, если на стене в рабочей комнате повесить записи по ретроспективе спринта (что, к нашему стыду, мы так часто забываем сделать!) Имейте в виду, что каждое изменение имеет свою цену, поэтому перед тем как его внедрять, подумайте, может, стоит ничего не делать вообще и надеяться, что проблема станет меньше или исчезнет совсем.

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

Если в ответ на каждую жалобу пытаться что-то делать, народ с неохотой будет рассказывать про свои даже самые мелкие проблемы, которые могут быть ужасными.

Оглавление книги