Мысли по поводу Scrum

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

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

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

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

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

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

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

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

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

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

    • Выполнима ли задача в принципе?
    • Достаточно ли информации, чтобы выполнить задачу?
    • Можно ли ее оценить?
    • Есть ли критерии выполненности?
    • Создается ли при этом действительная ценность?

11. Команды, которое придерживаются открытости и не боятся, что кто-то со стороны внутри компании может увидеть на каком этапе находится их работа над продуктом, как правило, более продуктивны.

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

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

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

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

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

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

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

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