Случайные мысли по поводу Scrum

  1. Не обязательно на 100% следовать методологии и внедрять сразу все ее элементы. Команда должна сама найти для себя то, что может быть выполнено в текущих реалиях.

  2. Работая над проектом, вы создаете некое ментальное пространство. Поэтому, если возможно, нанимайте людей на проект исходя из этого. Вы должны знать какой специалист вам нужен и какими качествами он(а) обладает.

  3. Размер команды играет значение. Оптимальный вариант – 5-7 человек (см. pizza size team).

  4. Первым делом ищите владельца продукта для реализации своей идеи. Еще раз: не технического директора, не тимлида, не разработчиков, а владельца продукта! Без него велик шанс прошляпить концепцию и, как следствие, приоритизацию задач и сроки.

  1. Без Scrum–мастера можно жить! Особенно если продакт и, например, тимлид могут вести команду к непрерывному совершенствованию, регулярно искать ответ на вопрос: «Как нам сделать еще лучше то, что мы делаем уже хорошо?», а также устранять помехи, мешающие команде двигаться вперед. К слову, самые крутые команды сами себе Scrum-мастер.

  2. Оценить сроки проекта можно только после того, как увидели насколько эффективно работает команда и как меняется ее динамика. Обычно на это уходит несколько спринтов. Оценка сроков перед стартом работ над проектом или в самом его начале в большинстве случаев будет ошибочна.

  3. Только тот, кто непосредственно выполняет проект / задачу, знает, сколько на это потребуется времени и сил. В этом вопросе доверяйте команде, а не людям со стороны.

  4. Приоритезируйте. А на этапе MVP вообще старайтесь выбросить все, что не приносит ценности для пользователя. Как мы все знаем, 80% успеха и ценности любого продукта заложены в 20% его функциональности. Довольно часто функции, считающиеся важными, в результате таковыми не являются.

  5. Приоритезируя, объясняйте команде зачем нужна та или иная функция и какую ценность она несет.

  6. На этапе грумминга задач команда должна ответить на вопросы:

    1. Выполнима ли задача в принципе?
    2. Достаточно ли информации, чтобы выполнить задачу?
    3. Можно ли ее оценить?
    4. Есть ли критерии выполненности?
    5. Создается ли при этом действительная ценность?
  7. Команды, которое придерживаются открытости и не боятся, что кто-то со стороны внутри компании может увидеть на каком этапе находится их работа над продуктом, как правило, более продуктивны.

  8. Ежедневные стендапы – это не отчетность перед менеджером, а инструмент синхронизации команды.

  9. Не беритесь за все сразу. В режиме многозадачности очень сложно работать. В конечном итоге можно получить посредственное качество продукта и выгорание.

  10. Ретроспектива – не менее важный инструмент процесса разработки. Периодически задавайте себе, как команде, следующий вопрос: «Что может повысить эффективность ежедневной работы и ее ценность?». О важности улучшения повседневных рабочих процессов есть замечательная книга «The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win». На ретроспективе нужно обсуждать не продукт, а каким образом он делается, т.е. выявлять факторы, замедляющие трудовой процесс, и избавляться от них в каждом последующем спринте.

  11. Сделанная наполовину фича никому не нужна. Результат либо есть, либо его нет. Поэтому часы, отражающие лишь затраты, ценности не несут. Гораздо важнее уметь измерить скорость и качество.

  12. Нужно дать людям свободу, уважение, право делать свое дело самостоятельно и не сходить с ума по работе.

  13. Тимлидам и прочим менеджерам стоит стремиться делать так, чтобы команда и без них работала успешно.

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

  15. Не нужно слушать циников, которые говорят вам, что что-то не может быть сделано. «В этой компании так не работает» – знакомая фраза, да? 🙂

Похожие заметки