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

  1. Не обязательно на 100% следовать методологии и внедрять сразу все ее элементы. Команда должна сама найти для себя то, что может быть выполнено в текущих реалиях.
  2. Работая над проектом, вы создаете некое ментальное пространство. Поэтому, если возможно, нанимайте людей на проект исходя из этого. Вы должны знать какой специалист вам нужен и какими качествами он(а) обладает.
  3. Размер команды играет значение. Оптимальный вариант – 5-7 человек (см. pizza size team).
  4. Первым делом ищите владельца продукта для реализации своей идеи. Еще раз: не технического директора, не тимлида, не разработчиков, а владельца продукта! Без него велик шанс прошляпить концепцию и, как следствие, приоритизацию задач и сроки.
  5. Без Scrum–мастера можно жить! Особенно если продакт и, например, тимлид могут вести команду к непрерывному совершенствованию, регулярно искать ответ на вопрос: «Как нам сделать еще лучше то, что мы делаем уже хорошо?», а также устранять помехи, мешающие команде двигаться вперед. К слову, самые крутые команды сами себе Scrum-мастер.
  6. Оценить сроки проекта можно только после того, как увидели насколько эффективно работает команда и как меняется ее динамика. Обычно на это уходит несколько спринтов. Оценка сроков перед стартом работ над проектом или в самом его начале в большинстве случаев будет ошибочна.
  7. Только тот, кто непосредственно выполняет проект / задачу, знает, сколько на это потребуется времени и сил. В этом вопросе доверяйте команде, а не людям со стороны.
  8. Приоритезируйте. А на этапе MVP вообще старайтесь выбросить все, что не приносит ценности для пользователя. Как мы все знаем, 80% успеха и ценности любого продукта заложены в 20% его функциональности. Довольно часто функции, считающиеся важными, в результате таковыми не являются.
  9. Приоритезируя, объясняйте команде зачем нужна та или иная функция и какую ценность она несет.
  10. На этапе грумминга задач команда должна ответить на вопросы:
    1. Выполнима ли задача в принципе?
    2. Достаточно ли информации, чтобы выполнить задачу?
    3. Можно ли ее оценить?
    4. Есть ли критерии выполненности?
    5. Создается ли при этом действительная ценность?
  11. Команды, которое придерживаются открытости и не боятся, что кто-то со стороны внутри компании может увидеть на каком этапе находится их работа над продуктом, как правило, более продуктивны.
  12. Ежедневные стендапы – это не отчетность перед менеджером, а инструмент синхронизации команды.
  13. Не беритесь за все сразу. В режиме многозадачности очень сложно работать. В конечном итоге можно получить посредственное качество продукта и выгорание.
  14. Ретроспектива – не менее важный инструмент процесса разработки. Периодически задавайте себе, как команде, следующий вопрос: «Что может повысить эффективность ежедневной работы и ее ценность?». О важности улучшения повседневных рабочих процессов есть замечательная книга «The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win». На ретроспективе нужно обсуждать не продукт, а каким образом он делается, т.е. выявлять факторы, замедляющие трудовой процесс, и избавляться от них в каждом последующем спринте.
  15. Сделанная наполовину фича никому не нужна. Результат либо есть, либо его нет. Поэтому часы, отражающие лишь затраты, ценности не несут. Гораздо важнее уметь измерить скорость и качество.
  16. Нужно дать людям свободу, уважение, право делать свое дело самостоятельно и не сходить с ума по работе.
  17. Тимлидам и прочим менеджерам стоит стремиться делать так, чтобы команда и без них работала успешно.
  18. Важно уметь радоваться своим достижениям по ходу работы как личностно, так и командно. Мудрые люди говорят, что истинное счастье можно найти в пути, а в не в его завершении.
  19. Не нужно слушать циников, которые говорят вам, что что-то не может быть сделано. «В этой компании так не работает» – знакомая фраза, да? 🙂

Related Articles