Планирование и оценка в SCRUM

В последние несколько лет использование SCRUM как схемы для простроения работы команды разработчиков стало трендом в разного рода IT-компаниях. В данной статье мы не будем рассматривать эту систему целиком, но коснемся одного из вопросов, который в ее рамках поставлен: планирование работы по поставленной задаче и оценка сроков ее реализации.


Планирования имеет место быть внутри почти что любой команды разработчиков, в любых размеров и любой направленности компаниях.
Очевидно, что для аутсорс-компаний оценка задач играет очень важную роль: ведь итоговая стоимость проекта или его части всегда оценивается исходя из часов, потраченных на ее решение специалистами. Помимо этого, результатом планирования является также подход к решению задачи и определение сроков ее решения. Те, кто работал в компаниях, занимающихся разработкой, знает, что на практике сроки выполнения почти всегда являются больной темой, часто могут не соблюдаться, срываться и создавать менеджерам немало головной боли. Потому предлагаем Вам несколько практических советов по планированию от опытного тимлида, имеющего основательный опыт работы с использованием методологии SCRUM.

Во-первых давайте определимся с тем, что же такое правильная оценка работ:

  1. Это оценка объемов и сроков работ, которая с приемлемой вероятностью (90-99%) будет соответствовать фактическим срокам.
  2. Это оценка, приемлемая для заказчика (для аутсорс компаний), или для старшего менеджера (для компаний продуктовых).

 

Человеческий фактор, или что важно знать

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

Иногда бывает так, что некоторые из поставленных задач не изучены ни одним из участвующих в проекте специалистов. Как можно поступить в таком случае: постарайтесь выделять время на исследование сложной задачи. Лучше всего утверждать с заказчиком возможность этого исследования заранее. И, что достаточно полезно, стоит периодически просматривать backlog проекта на наличие такого рода задач.

Недопонимание

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

  1. Постарайтесь объяснять задачу как можно проще, на общем для всех участников процесса планирования уровне.
  2. Задавайте уточняющие вопросы. Например, “Правильно ли я понял, что …?” или “Уточни, что должно получиться в итоге?”. Просто поймите, что лучше спросить и уточнить все вопросы до начала работ, чем переделывать что-либо после.

 

Баги

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

Сложные системы

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

  1. Обязательно привлекайте к планированию тех, кто уже работал с данным проектом, либо экспертов, у которых есть опыт работы с подобного рода системами.
  2. Поощряйте парное программирование: связанную работу специалиста в системе и новичка. Так со временем у вас в команде будет два специалиста.
  3. Говорите о проблемных местах системы и участках кода на ретроспективном совещании — это будет полезным в дальнейшей работе.
  4. При оценке рефакторинга не упускайте из виду тот факт, что некоторые части либо всю задачу можно быстрее и проще написать с нуля.

 

Принцип обратной связи

И самое главное, не стоит забывать, что для успешного планирования необходимо постоянно практиковаться и анализировать свой опыт. Универсальной схемы для составления точной оценки объема и сроков работ нет, ведь в ней, увы, участвуют люди. Но развиваться в этой области можно, как и в любой другой: берите обратную связь после окончания каждого проекта, анализируйте и корректируйте свои действия при последующем планировании, оценке новых задач и проектов.

via Alex Korotkiy, Team leader at Ciklum

автор: /  Оставить комментарий 4729

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *