Highload++ 2017 завершён!

Профессиональная конференция разработчиков высоконагруженных систем

СКОЛКОВО, Москва 7 и 8 ноября

11-я ежегодная конференция для разработчиков highload-систем, которая соберет   2 700 участников из разных регионов России и мира. Мероприятие направлено на обмен знаниями о технологиях, позволяющих одновременно обслуживать многие тысячи и миллионы пользователей.

Программа охватывает такие аспекты веб-разработок, как архитектуры крупных проектов, базы данных и системы хранения, системное администрирование, нагрузочное тестирование, эксплуатация крупных проектов и другие направления, связанные с высоконагруженными системами.

  • Главная
  • Управление командой разработки (тимлиды)

Перестаньте тратить время на оценки
Управление командой разработки (тимлиды)

Доклад отклонён
OnAgile

Agile Coach & Lean Product Manager. Ex Agile Software Developer.

Тезисы

Ценность - это то, что мы хотим. Потери - это любая активность, которая не вносит непосредственный вклад в доставку ценности.

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

Бизнесу нужны не оценки сами по себе, а реалистичное прогнозирование. Мы рассмотрим 3 способа прогнозирования:
* На основании абсолютных оценок, которые так или иначе выражены или сводятся ко времени (часы).
* На основании относительных оценок, которые выражают требуемый объем работ, они же Story Points.
* #NoEstimates.

Самым слабым способом прогнозирования является оценивание в часах. Обычно трудно дать оценку, когда будут пожарены сосиски (@see '5 минут турецкий на youtube'), что уж говорить о процессе разработки ПО с его неопределенностью. Часто оценка звучит как "2 дня", или "1-2 дня", или закладываем буфер или фокус-фактор и говорим "4 дня". Такой вид оценки - это всегда обещание, которое нужно давать только при полной уверенности, что это обещание точно можно сдержать.

Сказать. Ответственно отнестись. Сделать.

Обещание состоит из трех частей.
1. Вы говорите, что вы это сделаете.
2. Вы ответственно относитесь к своим словам.
3. Вы выполняете обещанное.

Язык Обещаний, Рой Ошеров.

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

Абсолютная оценка должна быть правильной, что значит должна включать в себя неопределенность и быть диапазоном значений, а также точной - сужать этот диапазон до степени уверенности. Пример: "При наилучшем раскладе работа займет 4 часа, при самом пессимистичном - 5 дней, если будут постоянно отвлекать и внезапно просить поработать над другими задачами. На этой неделе всё спокойно, поэтому с вероятностью 90% задача будет готова через 2 дня, так как подобные задачи обычно решаются за 2 дня".

Необходимо каждый раз хорошо подумать, а также иметь статистику. Напряжно.

Относительные единицы измерения, они же Story Points, рассчитаны на то, чтобы сместить фокус внимания с того, что неважно (время работы над задачей), на то, что важно (что конкретно надо сделать). Этот способ прогнозирования лучше, поскольку позволяет избавить разработчиков от дачи ложных обещаний и сфокусировать их на обсуждении сути задачи.

Инструмент Poker Planning помогает командам обсуждать проблематику, а не что сколько займет времени. Прогнозирование выполняется на основании количества выполненных относительных единиц за отрезок времени и является более точным.

Теперь представим, что у нас вместо классической колоды Planning Poker набор из трех карточек:
* 1 Story Point.
* Слишком большая.
* Задача непонятна.

Достигнув этого этапа, становится возможным свести потери на прогнозирование к минимуму - просто считать количество задач.

Методологии и процессы разработки ПО; Сроки и приоритеты

Другие доклады секции
Управление командой разработки (тимлиды)

Rambler's Top100