День 96. Оценивание в аутсорсных командах (I)

Оригинал: https://medium.com/@Liliya.Sabitova/estimation-process-in-outsourced-teams-ae082dd57dbf

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

Что такое оценивание?

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

Давайте подробнее опишем, в чем состоит процесс оценивания:

1. команда разработки получила требования

2. проведен предварительный анализ — выявлены пробелы в описании и кейсы, упущенные из виду. Мы называем эту стадию «Вопросы и ответы»

3. начальный митинг с заинтересованными лицами проводится для того, чтобы донести до всех пользу предлагаемой фичи и ее ценность для бизнеса, ограничения при ее разработке и необходимые ресурсы

4. отчет о том, как эта разработка повлияет на существующий функционал

5. делаем эту информацию максимально прозрачной для заказчика — отправляем отчет ему и получаем обратную связь

6. задача разбивается на подзадачи

7. созданные таски согласуются с техническим представителем заказчика

8. проводится покерное планирование (команда обсуждает каждую задачу и оценивает ее в сторипойнтах)

9. основываясь на истории прошлых спринтов, прогнозируем дату релиза

Вы можете спросить, для чего необходимо так много этапов (предварительный анализ, начальный митинг, согласование с заказчиком)?

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

Тогда как оставшиеся разработчики продолжают работу в штатном режиме над своими задачами.

Далее мы планируем совещание заказчика со всей командой. Но прежде каждый просматривает требования и формирует свои представления о целях проекта.

Предварительная подготовка позволяет сократить продолжительность виртуальных обсуждений до 1 часа.

Конечным итогом становится техническое задание, которое формируется командой и согласуется заказчиком.

Другие варианты

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

— для стартапов характерен более сжатый workflow, где пункты 3, 4, 5 и 7 пропускаются. Из причин этого можно выделить более сжатые финансовые ограничения для стартапов и незнание конечных целей, которые открываются и меняются в ходе работы над проектом.

— компании, занимающиеся enterprise (а именно таких большинство в Ижевске. От одного из директоров я даже слышал выражение «Ижевск — город кровавого интерпрайза»), напротив, стремятся к построению формализованного workflow, снижающего риски разработки при изменяющихся требованиях. В таких проектах большую роль играют описанные шаги 5 и 7.

Кроме того, заказчик не только принимает участие в согласовании бизнес-требований, но и тестирует продукт, а также может обсуждать его архитектуру, масштабирование и поддерживаемость.

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

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

Методы

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

Для сопровождения существующего продукта больше подойдет Kanban, поскольку имеется большая обратная связь и четкие userstory.

Для зрелых компаний и сложных приложений стоит попробовать какой-то свой гибридный подход, сочетающий гибкость SCRUM с выстроенным потоком Kanban.

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

Обсудить у себя 0
Комментарии (0)
Чтобы комментировать надо зарегистрироваться или если вы уже регистрировались войти в свой аккаунт.

Войти через социальные сети:

Сахаров Денис
Сахаров Денис
сейчас на сайте
Читателей: 21 Опыт: 786.781 Карма: 6.74063
все 22 Мои друзья