Из выпуска с продукт-менеджером Amazon на нашем YouTube-канале.
«Scrum – метод приоритизации задач на следующие 2-3 недели – на спринт.
Спринт – это такой краткосрочной забег, в котором ты говоришь: «Окей, следующие две недели мы сделаем вот эти 10 тасков. И будем работать только над ними и больше ни над чем». В этом есть свои плюсы и минусы. С одной стороны ты не отвлекаешься на другие задачи. Но приходится постоянно вносить дополнения, а их собирается за спринт довольно много.
В программировании нет такого, что ты просто сел и начал писать код. Сначала продукт-менеджер собирает все требования, описывает функции нового продукта. Затем все отправляется в дизайн. Программисты садятся и описывают, что им нужно будет сделать, исходя из требований, например, заинтегрироваться с системой, сделать определенный фреймворк и т.д. Третий этап – код в прогрессе, где сотрудник уже садится и начинает писать код. Затем тестирование. И последний этап – релиз.
И вот Kanban – это методология, в которой ты ставишь лимиты на каждый этап. В группе «требований» не может быть больше 3-х функций. Пока я не перенесу какую-нибудь из требований в дизайн, я не могу добавлять новые задачи.
То есть происходит регуляция потока задач. Если у тебя больше разработчиков, можно расширить задачи. Плюсы методологии в том, что она гибкая. Минус – может постоянно меняться приоритезация в отличие от Scrum. В любой момент можно включить задачу, которой до этого не было.
Оба подхода относятся к методологии Agile. Смысл ее в том, что ты все время разбиваешь большой релиз на маленькие куски и выпускаешь их как можно чаще, чтобы не делать то, что пользователю не нужно.
В Scrum мы каждую задачу оцениваем в поинтах. Их ничем не измеришь, это больше относительная величина. Например, задача на 4 поинта больше задачи, оцениваемой на 2. Такие поинты позволяют посмотреть, на сколько разработчик закрыл свою задачу.
В Kanban это сложнее.
Другое наше правило – брать в работу только 3 задачи. Если в команде 10 разработчиков, то все работают над этими задачами, никто не может взять новую. Потому что если каждый девелопер возьмет по одной задаче, которая займет по времени 2 месяца разработки, то релизов в месяц будет всего 2 соответственно.
Именно поэтому ставятся ограничения на минимум 3 задачи, над каждой из которых работает по 3 разработчика. При этом если кто-то освобождается, то он не может браться за новый проект. Он должен помочь коллегам завершить остальные поставленные на спринт задачи. И только после того, как проект ушел в релиз, можно брать новые таски»