Комментарии 26
Никак. Отвлекая - тоже никак.
И то верно.
А Пастернака стоит почитать ;)
я тоже надеялся открыть статью и прочитать крупную надпись "НИКАК" :)
Женщины рожают живого ребенка за 9 месяцев с вероятностью 0,9942. С вероятностью 0,8 - за 8 месяцев. Да, за 8 он получается недоношенным и требует специального ухода на протяжении оставшегося времени с применением дорогостоящей аппаратуры и высококлассных специалистов.
И тут приходит заказчик с вопросом: ок, а столько вам надо времени/денег, чтобы сделать вот такусенького голубоглазого негретенка?
С юмором написано. Но предметная область и класс задач явно не подходит под предлагаемый метод расчёта ;)
Ну и да, ответ на вопрос заказчика известен даже из школьного курса по биологии :)
Описание методики должно начинаться с области применимости и классов задач, где она имеет предсказательную силу. А тут получилось в лучших традициях консалта: вот есть линейка, ей можно измерять - попробуйте и вы (что там у вас? сантиметры, километры, килограммы, сила тока, скрам, канбан? - начинайте).
Если говорить об учебниках, то про Lead/Cycle time есть в каждой методичке по канбану. Вне контекста это вообще не имеет ни какого смысла.
По сути, статистические методы работают там, где есть возможность ставить много одинаковых экспериментов. Сделать чернокожего ребенка с любыми глазами в масштабе планеты нет ни какой проблемы. Но в рамках отдельно взятой семьи это может оказаться неразрешимой задачей. Если у вас частые однотипные поставки по одним и тем же маршрутам - считайте время и оптимизируйте сколько душе угодно. Для маленького бизнеса, с одним-двумя проектами в год, когда условно зимой вы составляете ТЗ, весной - кодите, летом - тестируете, а осенью - занимаетесь внедрением, - за всю жизнь не наберёте статистически значимых данных. Каждый новый проект будет уникальным.
Да, вы правы. Область применимости стоило указать. Упущение.
>Вне контекста это вообще не имеет ни какого смысла.
Позволю себе заметить, что в статье как раз задан контекст работы.
>Для маленького бизнеса, с одним-двумя проектами в год, когда условно зимой вы
>составляете ТЗ, весной - кодите, летом - тестируете, а осенью - занимаетесь
>внедрением, - за всю жизнь не наберёте статистически значимых данных.
Ну зависит от размера проекта, правда? Два проекта в котором миллион задач на анализ, разработку, тестирование - вполне себе массив данных.
Хотя конечно, в приведенном вами кейсе все сложно.
Но вычленить 80% процентиль можно имея уже 5 измерений. На двух не получится - там только 50 на 50. На трех - не больше 66%. На четырех 75%. А вот на 5-ти уже можно и 80%
Но вычленить 80% процентиль можно имея уже 5 измерений. На двух не получится - там только 50 на 50. На трех - не больше 66%. На четырех 75%. А вот на 5-ти уже можно и 80%
В каком контексте? Если у вас есть априорные знания о том, что процесс квазистабильный (рутина, поставки), а отклонения определяются в основном какими-то локальными возмущениями то да. А если задачи нетиповые в роде R&D, вокруг вас сплошная VUCA (ну или там играете на бирже), то делать далеко идущие выводы по 5 измерениям ну так себе стратегия)
Спасибо! Я тот самый пресловутый бизнес-заказчик PO, которому всегда нужны сроки. Попробую этот способ сам
Очень рад.
Вот полная запись доклады моего на TeamLeadConf на основе которого эта статья сделана. Там я отвечаю на вопросы и презентация там лучше видна https://www.youtube.com/watch?v=ZueVf6T8gdM
Строить прогнозы на основании таких данных (Тип работы "правка modulename", которая обычно занимала от X до Y времени) - это очень смешно.
Заказчик: Сколько у вас займёт задача "Починить поломанное ХЗ в ХЗ"?
Специалист: ХЗ
Менеджер: В 80% мы уложимся в "Х", а в 20 - в "З"!
Специалист (недоумевая): А что изменилось?
Менеджер: тссс!
Анекдот хороший, спасибо
Честно говоря необычно, что статью прочитали именно так.
Делить данные по типам работ - это уже второй или даже третий шаг. Сперва стоит посмотреть на весь массив данных, и график распределения времени выполнения. Сам график даст понимание - надо делить данные по типам работ или нет.
А уже вторым шагом можно анализировать локальные экстремумы, и смотреть, что объединяет типы работ, которые формируют эти экстремумы. Может быть там проявится классическое "фича", "баг", "мелкая правка". А может быть предлагаемое вами деление на правки в разных модулях.
Пока не посмотрим на весь массив данных и его распределение по времени, не поймём, какие типы работ можно статистически обоснованно выделить
А моих кейсах это ратоиань6и очно облегчает жизнь при разговоре с заказчиком.
Делить данные по типам работ - это уже второй или даже третий шаг. Сперва стоит <...>
Не стоит, потому что единственное для чего это нужно это
облегчает жизнь при разговоре с заказчиком
облегчает, потому что ему нравится ощущать, что у него все под контролем. для этого вообще нет нужды что то считать, можете сделать шаблон, и вместо всех рассчитанных циферок подставлять те, что называли раньше (оценка специалистов + заложенный вами запас), ничего не изменится
Del (дубль)
Рекомендую к описанной практике добавить еще и максимальную декомпозицию задач.
80% задач в разработке программного обеспечения делятся на совершенно однотипные задачи типа: реализовать представление (вью), добавить валидаторы вводимых данных, реализовать пару-тройку запросов, реализовать преобразование данных из формата, вводимого пользователем в формат понимаемый сервером и обратно, реализовать бизнес логику и т.д.
80% этого дробления легко уложится в вашу практику. При этом все эти задачи будут атомарными и выполняться за полдня-день. Если задачи занимают больше времени, то их просто надо раздробить еще. До тех пор, пока они не станут размером в полдня-день.
После этого Вашу практику можно смело применять и в Scrum. В таком случае у вас будет в спринте не 1 задача, которая еще может и не влезть. А набор мелких задач, которые легко оцениваются на основании статистики и истории. И по этому набору мы можем уже гораздо более точно сказать, а влезет ли задача в спринт целиком, или какой-то ее кусок все же придется перетащить в следующий спринт.
После прихода в Вашу вселенную конкурентов, Ваши сроки будут пересмотрены.
Как тимлиду достоверно знать срок выполнения задач, не отвлекая подчиненных