Comments 400
попросить помощи с фасилитацией встречи
Можно перевести это на русский или английский язык?
"Фасилитировать встречу" означает помогать участникам встречи концентрироваться на её цели, а также мотивировать на активное обсуждение и принятие решений. У нас в Dodo создана школа scrum-мастеров, выпускники которой помогут договориться даже самым молчаливым.
общ. способствовать; содействовать; оказать содействие; поспособствовать
образ. вести, проводить семинар и т.д.
Однако, оказалось, что мы покрыли тестами то, что съедало много времени тестировщика, но при этом практически никогда не менялось разработчиками и слабо влияло на процессы бизнеса.
И где тут ошибка?
Тестировщиков освободили от рутины — профит (больше времени на полезные задачи, выше мотивация). Регрессионные тесты они как раз про то, чтобы не сломать случайно в будущем что-то давно и хорошо работающее и не терять деньги от простоя — профит для бизнеса.
Откуда у вас такая странная информация? У нас действительно есть стажировка на базе пиццерии или учебного центра. Однакээ
Однако стажировка состоит из разных этапов реальной работы сотрудников пиццерий. Про гембу и её пользу мы уже ни один раз писали.
Господи, как я вас всех ненавижу :) Тимлиды с аджайл-коучами и фасилитаторами. Да пропади вы все пропадом!
Я пришел в программирование, чтобы решать технические задачи и радовать пользователя новыми фичами, а сейчас трачу 30% времени рабочего на то, чтобы играть в передвижение гребанных квадратиков по доске, митинги, и прочую дичь. А самое главное — все самые важные проблемы решались просто разговором с нужным человеком, живым ли или перепиской — не важно. Без необходимости отвлекать остальную команду от их дел.
Как достала уже вся эта эффективность вокруг. Все кругом эффективные. Все вокруг полезные. Только софт всё хуже и хуже, а мир все бесчеловечнее.
понятно что каждый специалист хочет делать то что сочтёт нужным за деньги работодателя, но, слава богу, аджайл-коучи нашли решение против этого хаоса
Подобное "решение технических задач" и "радование пользователя новыми фичами" может быть действительно успешным, только если вы работаете в одиночку. Когда в процессе участвует больше одного человека — людям нужно уметь организовываться (или уметь помогать их организовывать), иначе есть большой риск зафейлить выпуск продукта — как по качеству, так и по срокам.
Как бы вам ни хотелось жить в своём розовом мире, в котором "тимлиды с айджайл-коучами и фасилитаторами" не нужны, факты остаются фактами — люди в большинстве своём самоорганизовываться не умеют, и им нужно помогать.
Я и не отрицал необходимость руководства. Просто конкретно двиганье квадратиков по канбан-доске и ежедневные митинги — это полнейшая херня, а ее руководство. А именно этим занимаются 90% менеджеров, что я видел, а сотрудники уж вынуждены коммуникации выстраивать как-то сами. А те, что не страдали херней — не страдали бы ею и без аджайла. Классический waterfall, к слову, не так уж и плох для подавляющего большинства проектов с конечным сроком жизни. Тем не менее, аджайл модно, поэтому каждый божий день приходится сидеть и страдать какой-то и считать сторипоинты в попугаях...
"Двиганье квадратиков" и "сторипойнты в попугаях" (кстати, в попугаях, то есть неких абстрактных единицах — это гораздо правильнее, чем в часах, например) позволяют планировать и прогнозировать, то есть делать то, с чем, скажем так, "традиционные" методы разработки, типа того же waterfall, не справляются от слова никак.
То, что у waterfall нет терминологии для описания скоростей и проблем, а также для процесса перепланирования не означает, что эти процессы и оценки невозможны :) Ну, вот видишь ты, что никак не успеваете по плану, приходишь и говоришь о проблеме — и начнется абсолютно тот же процесс, что и при великом аджайле.
По поводу сторипоинтов в попугаях — полная чушь. Просто невероятный идиотизм. Никогда не видел, чтобы хоть кто-то оценил этих попугаев правильно. Реально, обычно каждый разработчик вырабатывает для себя некий способ конвертации часов в попугаи и просто им пользуется. Например, считает, что 16 рабочих часов == 1 попугай. Так и живем :)
не означает, что эти процессы и оценки невозможны
Дело не в терминологии вовсе. Дело в отсутствии физической способности корректно, достоверно и надежно распланировать проект на месяцы вперед.
Просто невероятный идиотизм
Трудно спорить с подобным attitude, поэтому даже пытаться не буду. Попробуйте самостоятельно разобраться с тем, что такое стори-пойнты (хороший старт даст это видео — https://www.youtube.com/watch?v=Gxf76eGyG5c&list=PLngnoZX8cAn-9tWYxyQQPGoHW7DETBCjK&index=5), а главное — зачем они нужны.
корректно, достоверно и надежно
Будто бы аджайл может сделать это. Дай бог там прогнозы на месяц сбываются.
Трудно спорить с подобным attitude
Вы правда считаете, что если употребить английское слово, вместо прямого и однозначного перевода вы будете выглядеть умнее?
Попробуйте самостоятельно разобраться с тем, что такое стори-пойнты
Я в курсе, что это такое. А еще в курсе, что абсолютно все известные мне программисты ложили болт на это и используют конвертацию в часы работы.
Будто бы аджайл может сделать это.
Я разве это утверждал?
вы будете выглядеть умнее?
Зачем вы додумываете за меня?
Я в курсе, что это такое.
Что?
абсолютно все известные мне программисты
Абсолютно все известные мне программисты, понимающие, что такое SP, и зачем они нужны, умеют ими грамотно пользоваться, не занимаясь абсурдным переводом в часы.
Говнокод, приложения, жрущие ОЗУ гигабайтами
Странно, что Вы вините в этом руководство. Код же пишете Вы, а не менеджеры? Или не Вы? В таком случае вопросов нет.
Эффективность — это не просто слово. Эффективность — это доставка фичи до клиента в сроки, за которые эта фича не теряет актуальности и позволяет бизнесу заработать персонально Вам на зарплату. Если Вам плевать на эффективность и хочется просто "получать удовольствие" — вероятно, Вы зря занимаетесь коммерческой разработкой.
Я разве это утверждал?
Если нет, тогда я не понял, к чему вообще была фраза про наличие инструментов для предсказания сроков.
Зачем вы додумываете за меня?
Затем, что никаких предпосылок не сделать этого я не нашел? Если есть объяснение получше, я бы выслушал.
Абсолютно все известные мне программисты, понимающие, что такое SP, и зачем они нужны, умеют ими грамотно пользоваться, не занимаясь абсурдным переводом в часы.
Абсурдны сами сторипоинты :) Даже если взять ваше же видео. В нём п.2 говорит "используйте объективные оценки". Дело в том, что время объективно. Если задача не сформирована по принцицу "оцените время, когда всё будет хорошо?", а по принципу "сколько времени вам понадобится для добавление кнопки в меню выбора языка", то все сторипоинты нафиг не нужны.
Забавно также, насколько абсурден ключ №3 предлагаемый авторов видео, который приводит в пример тот факт, что расстояние между двумя городами можно оценить как "2 раза проехать до города посередине". Это порождает логичную проблему "а сколько ехать до города посередине?" и в итоге всё снова сводится к часам. Так зачем заниматься этой попугайщиной, если можно просто правильно формулировать вопросы?
Странно, что Вы вините в этом руководство. Код же пишете Вы, а не менеджеры? Или не Вы? В таком случае вопросов нет.
А почему мы его так пишем? Не потому ли. что такой код дешевле и тупо нет времени подумать над более оптимальным решением?
Я еще раз повторюсь, я отлично понимаю как работает бизнес и почему всё так, как есть. Почему дешевые решения лучше хороших, почему существуют все эти методики повышения этой самой эффективности. В конце концов, я ж не тупой) Просто это совсем не отменяет того факта, что всё это дерьмо убило всю прелесть профессии, сделав из настоящих инженеров обезъянок по набору эффективного говнокода.
Если Вам плевать на эффективность и хочется просто "получать удовольствие" — вероятно, Вы зря занимаетесь коммерческой разработкой.
К большому несчастью, выбора-то нет. Или быть эффективным, или просить милостыню. Поэтому я эффективен до усрачки, не помню, чтобы хоть раз кто-то выражал недовольство моей работой. Просто не обязан любить всё это дерьмо.
Я прошу прощения, что приходится разжевывать азы, но нет, ничего не сводится к часам, потому что сторипойнты нужны не для того, чтобы понять, сколько будет делаться одна конкретная задача. Сторипойнты в скраме нужны для того, чтобы понимать скорость работы команды, и, уж простите, но очевидно, что Вы этого НЕ понимаете.
Если Вы будете измерять задачи часами, то Вы, во-первых, будете делать это некорректно, потому что временные затраты — это только часть оценки. Во-вторых, Вы не сможете понять, сколько задач в действительности может сделать команда за один спринт. Следовательно, Вы не можете прогнозировать.
Что касается Вашей персональной эффективности, кто я такой, чтобы в ней сомневаться. Но позволю себе спросить — в чем именно Вы её измеряете? Как Вы понимаете, что Вы эффективны? Почему Вы думаете, что не можете быть еще эффективнее?
Сторипойнты в скраме нужны для того, чтобы понимать скорость работы команды
А как понимать скорость работы команды в сторипоинтах? Какая разница между "ну, мы можем сделать эту задачу за 3 дня" и "это займет 3 сторипоинта"?
что Вы этого НЕ понимаете.
Признаться, я действительно вас не понимаю, потому что пояснения к своей точке зрения даю только я. Если вы объясните мне в чем я конкретно не прав, быть может это будет более продуктивно.
временные затраты — это только часть оценки.
Что-то я не очень понимаю, что является другими частями оценки в вопросе "когда будет готова фича?"
Во-вторых, Вы не сможете понять, сколько задач в действительности может сделать команда за один спринт.
Сторипоинты не проясняют ситуацию ни на йоту. Я не помню ни одного случая, чтобы это работало. Понятные задачи, которые легко оценить в часах, делаются в срок. Задачи, которые невозможно оценить в часах — никогда не делаются в срок. Вот и вся история. Дайте мне какой-нибудь живой пример, который убедит меня в обратном.
Как Вы понимаете, что Вы эффективны?
Достаточно просто — меня не увольняют и не собираются, насколько мне известно. Мне платят выше рынка, в конце концов. Не помню ни одного плохого отзыва о своей работе в анонимной оценке, проходящей в компании раз в год.
Почему Вы думаете, что не можете быть еще эффективнее?
Почему не могу? Могу :) Но я уже несколько раз упомянул, что мне вся эта эффективность поперёк горла, т.к. она измеряется в вещах, которые интересны бизнесу. Персонально мне нет никакого резона быть эффективнее))) Забавно то, что "эффективность" и заработок вещи хоть и коррелирующие между собой, однако зависимость у них далеко не линейная, а скорее логарифмическая)
Сторипоинты выглядят логичнее на уровне члена команда. Пусть джун делает 0.5 поинта в часа, синиор 2 поинта.
Считать что синиор делает 2 часа в одном звучит странно.
Пусть джун делает 0.5 поинта в часа, синиор 2 поинта.
Считать что синиор делает 2 часа в одном звучит странно.
На уровне членов команды каждый член команды дает свою собственную оценку в часах и тогда все ок.
Стори поинты проблему никак не решают, т.к. то, что Вася делает задачу Х вдвое быстрее Пети, не значит совсем, что он вдвое быстрее делает все задачи. Просто (в подавляющем большинстве случаев) у него выше экспертиза как раз в этой области Х. А в области Y будет другая ситуация.
Вообще, к слову, сторипоинты могут иметь смысл — но как оценка полезности задач. То есть, оценивают пользователи, в процессе кардиналистского голосования, а не разработчики.
Что значит это сторипоинт, кроме как маркер отображающий что сеньор в 4 раза круче джуна? Как это поможет в планировании?
Возьмем ситуацию: в команде есть сеньор (2 СП/спринт), миддл (1 СП/спринт) и 2 джуна (0,5 + 0.5 = 1 СП/спринт).
Прилетает задача реализовать новую фичу, скажем, поддержку формирования графиков в системе отчетности, в которой этих графиков отродясь не было.
Её сложность нужно оценить в стопипоинтах. Приведите мне в пример порядок действий и порядок мыслей, как мне оценить задачу не в часах, а сразу в СП.
Что значит это сторипоинт, кроме как маркер отображающий что сеньор в 4 раза круче джуна?
Что значит молоток, кроме как инструмент для забивания гвоздей?
Как это поможет в планировании?
Это поможет примерно оценить сколько времени займет выполнение задачи конкретным сотрудником. Задача в 1 стори пойнт джуном со скоростью 1 СП/спринт будет пилиться 2 спринта. Хотя обычно 1 СП ~ 1 час мидла.
Приведите мне в пример порядок действий и порядок мыслей, как мне оценить задачу не в часах, а сразу в СП.
Чтобы так оценивать, нужна эталонная известная задача. Сторипойнтами удобно оценивать типовые фичи.
Если же задача совершенно новая и аналогов не имеет, то оценивается ее предполагаемая сложность.
Например для тех же графиков можно посмотреть в документацию инструмента. Если используете какую-то платформу отчетности, то наверняка есть возможность делать графики.
Если пилите свой велосипед, то оцениваете сложность как для другого похожего велосипеда когда вам нужно было что-то на фронте изобразить.
Хотя обычно 1 СП ~ 1 час мидла
Мне тут только что втирали про то, что переводить СП в часы — это неправильно. Без часов пожалуйста.
Это поможет примерно оценить сколько времени займет выполнение задачи конкретным сотрудником.
Ни разу не помогало, при условии, что оценку сложности делал один, а исполняет совершенно другой человек.
Задача в 1 стори пойнт джуном со скоростью 1 СП/спринт будет пилиться 2 спринта
У нас новую арифметику завезли? Иначе где логика?)
Чтобы так оценивать, нужна эталонная известная задача.
Что такое "эталонная известная задача". Неужели такое существует? Эталонная известная задача — это задача которую каждый из сотрудников решал в одинаковых условиях независимо от своих коллег, а вы в это время сидели с таймером рядом и измеряли (лол) за сколько часов её сделал каждый из них. В итоге снова всё конвертируются в часы и зачем мне тогда сторипоинты?
Мне тут только что втирали про то, что переводить СП в часы — это неправильно. Без часов пожалуйста.
Я был не прав. В часах действительно неправильно считать. Но 1 СП/спринт тоже нереально. 1 СП это какая-то типичная простейшая эталонная задача. Где вы видели, чтобы простейшие задачи по 2 недели только разрабатывали?
Ни разу не помогало, при условии, что оценку сложности делал один, а исполняет совершенно другой человек.
Потому и не помогало, что оценивал один а делал другой. Оценку сложности делают совместно. При этом договариваются до какой-то одной оценки путем обоснования минимального и максимального. Что то вроде:
- Почему ты 5 СП, когда все сказали 3?
- Потому что тут вылезет вот такая проблема, про которую все забыли.
- Коллеги, ваша оценка изменится от этого факта?
- Да, если это учитывать, то 5 СП.
У нас новую арифметику завезли? Иначе где логика?)
Действительно опечатался. Имел в виду скорость джуна 0,5 СП/спринт.
Что такое "эталонная известная задача". Неужели такое существует?
Когда вы на поддержке какого-то определенного набора похожих продуктов, то существует. Допустим заказчики захотели фичу в продукте 1, вы ее сделали. Потом они ее просят в продукте 2-5 и вы знаете сколько времени ее делать. Причем знаете индивидуальное время каждого специалиста.
В итоге снова всё конвертируются в часы и зачем мне тогда сторипоинты?
В итоге получаются не просто часы, а часы конкретного сотрудника. Как вы с оценкой часами опишете ситуацию, когда опытный может делать за 2 часа, а неопытный за 4?
В итоге получаются не просто часы, а часы конкретного сотрудника. Как вы с оценкой часами опишете ситуацию, когда опытный может делать за 2 часа, а неопытный за 4?
Так у каждого сотрудника в любом случае своя оценка (хоть в часах хоть в SP). Просто не надо среднюю оценку брать, а так и оставлять, списком оценок.
Нет, потому что оценивающий не оценивает задачу саму по себе, а сравнивает её с уже выполненными и оцененными. Мало кто может навскидку сказать, сколько весит слон, но определить, во сколько примерно раз он больше бегемота, способен практически любой.
Мало кто может навскидку сказать, сколько весит слон, но определить, во сколько примерно раз он больше бегемота, способен практически любой.
Но вес — это вполне понятная числовая характеристика. Штука в том, что вы не можете сравнивать сложность, не переведя ее в какую-то числовую характеристику, мозг так не работает.
Так что, на самом деле, абсолютно все при оценке сторипоинтов делают такой перевод. Это не обязательно часы — могут быть строки кода или другие единицы, но главное, что они те, которые поддаются измерению. А сложность неизмерима, по-этому сложность задач саму по себе нельзя сравнить численно. Можно сказать что "задача Х сложнее, чем Y", но нельзя сказать, что она сложнее в 2.5 раза.
абсолютно все при оценке сторипоинтов делают такой перевод
Это абсолютная неправда. Если лично Вы не понимаете, как обходиться без этого, это не значит, что остальные, да еще и все, тоже не понимают.
Это абсолютная неправда.
Это правда, потому что мозг иначе не может получать численные оценки.
Скажите пожалуйста, когда вы говорите, что одна задача 2 сторипоинта, а дургая — 6, то чего именно в этой второй задаче втрое больше и почему именно втрое, а не в 2.5 раз? То есть — как и что вы измерили?
Говорите за себя оО
Когда я говорю, что одна задача 2 сторипойнта, а вторая 6 (хотя мы, как правило, пользуемся рядом фибоначчи, но это не суть), это значит, что первая задача очень похожа на множество задач, оцененных в 2сп, а вторая — на множество задач, оцененных в 6сп. Мы не измеряем, мы сравниваем. Как только вы перестанете пытаться измерять задачу, что действительно невозможно, и начнете сравнивать — у вас всё получится.
это значит, что первая задача очень похожа на множество задач, оцененных в 2сп, а вторая — на множество задач, оцененных в 6сп.
А откуда берется множество задач, оцененных в 6? Каким образом в 6сп была оценена первая задача, оцененная в 6сп?
То, о чем вы говорите сейчас — это ординалистский подход, то есть вы просто берете пул задач, потом упорядочиваете по сложности (x сложнее y а y сложнее z), выбираете к какой из задач ближе ваша конкретная, и устанавливаете ей сложность. С этим подходом, однако, есть одна проблема — вы не имеете права переводить одни задачи в другие. Иными словами у вас есть задача "малого размера" и есть задача "не очень малого размера" и при этом вы не имеете права переводить n задач малого в k задач не очень малого, т.к. это не количественная оценка. То есть, сложить все задачи и получить какую-то сумму в сп вы в данном случае не можете (т.е. у вас получится в конце спринта не "выполнили задач на 100сп", а "выполнили 5 задач по 10сп, 1 задачу 20сп, 5 задач по 5сп, 5 задач по 1сп", и никаких эти сп теперь не сложить). Чтобы это сделать — вам нужна именно количественная оценка.
Ваши сп при таком подходе не могут складываться, это просто названия. То есть 4сп не факт что вдвое (или хотя бы примерно вдвое) больше, чем 2сп. Она может быть больше на 10% или в сто раз.
Понятное дело, что при таких оценках никакого планирования невозможно.
Даже если говорить только о времени чтобы оценить что одна задача займёт в три раза болльше не нужно оценивать одну задачу в часах, другую и смотреть соотношение. То есть временем оперируем, но в часах его не меряем. Это тупо не практично даже: каждый раз по оценке одной задачи давать оценку эталонной.
Мозгу не обязательно знать точные величины сравниваемых метрик, чтобы решить во сколько раз они различаются. Вот стоит у меня на столе сейчас наполовину пустой стакан лимонада. Я не знаю сколько мл стакан, не знаю сколько лимонада, но могу сказать, что это половина.
То есть временем оперируем, но в часах его не меряем.
Ну да, так и делаем. Берем известную задачу, время выполнения которой известно из практики, т.к. мы его пронаблюдали и сравниваем данную задачу с этой известной.
Только, обратите внимание — в данном случае мы можем измерить время выполнения эталонной задачи. Мы знаем, сколько она у нас заняла (ну, точнее мы говорим не о конкретной задаче, а о пуле задач определенного типа, и о том, статистически, сколько времени, исходя из реальной практики, занимает выполнение задач такого рода). СП эталонной задачи измерить нельзя, СП вообще измерить нельзя — в этом проблема СП.
И, повторяю, когда вы оцениваете в СП, вы тоже интуитивно используете некий измеримый показатель для эталонной задачи, пусть и не отдавая себе в этом отчета. Мозг просто не может работать по-другому.
Чтобы сравнить что-то с эталоном, необходима измеримость эталона. Вы не можете сравнивать, например, отризок х с отрезком y, если длина отрезка y не может быть измерена. Если вы не можете измерить эталон — то вы можете только ординалистски заявить: "х больше" или "х меньше". Но вы не сможете сказать, что "х больше в 2.5 раза". Для подобной оценки нужно иметь возможность промерять оригинал.
Проблема оценки типовой задачи в часах в том, что это величина не статическая. Сегодня эталонную сделали за 1 час, а через месяц она будет занимать 43 минуты, но этого точно мы не знаем.
А чтобы сравнивать что-то с эталоном не нужно знать метрику эталона. Измерение отрезка X в метрах мы производим путём подсчёта сколько во сколько раз эталонный отрезок больше или меньше измеряемого. Все наши единицы измерения по сути произвольны и измеряя что-то в них мы считаем во сколько раз что-то больше или меньше эталона. Эталон метра мы не можем измерить в метрах, мы создаём аксиому, что этот эталон имеет длину в 1 метр и измеряем остльное сравнивая длины с эталоном.
Если нас не интересует сколько времени занимает задача, а интересует какой набор задач мы сделаем за 2 недели и планируем мы путём сравнения с эталонной, зная предполгая, что за 2 недели мы сделаем 100 таких задач, то какой смысл сравнивать длительность эталонной задачи с оценваемой, а потом приводит это к эталону часов (не суть, 1/24 суток или сколько-ко там каких-то периодов в микромире), если часы нас не интересуют? Более того, повторюсь, длительность эталонной задачи не константа в часах.
Исходим из гипотезы, что время на эталонную задачу изменяется плюс-минус пропорционально со временем на оцениваемые задачи, то есть растёт или падает скорость команды в эталонных задачах/спринт. Нам не нужны оценки в часах ни эталонной. ни оцениваемых, чтобы сказать сколько мы сделаем за спринт. Это просто лишняя информация. Да, можно посчитать сп/час, но зачем?
Но когда вы говорите, что сделаете условных 100 за 2 недели вы по сути и считаете 100 эталонок на n часов с учетом чая, т.е. одна эталонка в сколько-то часов. Суть то не меняется.
Нет, это можно посчитать сколько часов эталонка займёт, но мы обещаем сделать 100 за 2 недели, пускай это 600 часов, а не 100 по 6 часов на каждую.
Проблема оценки типовой задачи в часах в том, что это величина не статическая. Сегодня эталонную сделали за 1 час, а через месяц она будет занимать 43 минуты, но этого точно мы не знаем.
И в чем тут проблема? Какая нам разница, сколько задача будет занимать через год? Мы же в часах меряем, а не в СП, А часы останутся часами :)
А чтобы сравнивать что-то с эталоном не нужно знать метрику эталона. Измерение отрезка X в метрах мы производим путём подсчёта сколько во сколько раз эталонный отрезок больше или меньше измеряемого.
А для этого должна быть определена метрика, все верно.
Эталон метра мы не можем измерить в метрах, мы создаём аксиому, что этот эталон имеет длину в 1 метр
Вы не поняли. Нам не важно знать, сколько именно чего-то там (других эталонов) в метре, нам важна сама измеримость. И тогда мы можем провернуть этот фокус (взять питона и промерять его в попугаях). Но смысл в том, что, и питон и попугай имеют измеримую длину. Только по-этому все работает. Если бы мы не могли измерить питона или попугая, то мы не смогли бы потом измерить и питона в попугаях (обратите внимание — сравнение размеров питона и попугая есть факт измерения сам по себе). Так вот, абстрактная "сложность задачи" — это величина by design неизмерима. Вы можете сказать, что задача Х сложнее, чем Y, но не можете сказать, что она сложнее "в 2.5 раз". Потому что "питон длиннее попугая в Х раз" — это понятно что значит, это в питона влазит Х попугаев, у нас есть конкретный процесс который позволяет определить как оно влазит и мы можем этот процесс виртуально в голове представить, давая оценку и потом проверить, проведя процесс в реальности. А что значит, что задача Х оценена в сторипоинтах в 2.5 раз больше, чем Y? Почему именно в 2.5 раз больше, откуда взялось это число? Что ИМЕННО сравнивалось? Каков процесс сравнения (ака измерения)? Что вы представляли в голове при сравнении, какой процесс? И как теперь процесс повторить ИРЛ, чтобы проверить результат? Вы виртуально представили ход выполнения задачи, сравнили его с ходом выполнения эталонной и получили, что для Х надо сделать в 2.5 раз больше "дел"? Ну поздравляю — вы как раз часы сейчас и оценили :)
И именно так все часы и оценивают :)
И в чем тут проблема? Какая нам разница, сколько задача будет занимать через год? Мы же в часах меряем, а не в СП, А часы останутся часами :)
Если мы оцениваем в часах как оценка эталонки умнженную на относительную сложность, то нам нужно каждый спринт оценивать эталонку. Если будем считать "эта задача в 10 раз сложнее эталонной, а значит она на 10 часов", то со временем эта оценка может стать завышенной, потому что год назад мы эталонку сделали за час, а сегодня сделали бы за 45 минут. и новую задачу должны оценить в 7,5 часов, а не в 10.
Вы виртуально представили ход выполнения задачи, сравнили его с ходом выполнения эталонной и получили, что для Х надо сделать в 2.5 раз больше "дел"? Ну поздравляю — вы как раз часы сейчас и оценили :)
Нет, не часы. Мы не знаем сколько часов займёт эталонка :)
Если мы оцениваем в часах как оценка эталонки умнженную на относительную сложность, то нам нужно каждый спринт оценивать эталонку.
Зачем? У каждого своя эталонка (и не одна на самом деле — по факту таких эталонок десятки). И каждый у себя в голове с ней сравнивает, чисто интуитивно. И потом говорит часы. Человек сказал: "5 часов", а сколько там у него был эталон — 1 час или 10 или использовалось много эталонов (ага, эта задача как половина задачи Х, треть задачи Y и как две задачи Z, а размер X, Y, Z мне известен, так что будет вот столько) — это не важно вам вообще. У каждого свой опыта и свои эталоны.
Нет, не часы. Мы не знаем сколько часов займёт эталонка :)
Почему не знаем? Знаем, это суть эталонки. Человек эталонки по факту выполнял и, с-но, точно знает, сколько они занимают. Именно те задачи, размер которых заведомо известен, и подбираются, бессознательно, для сравнения. Размер которых известен и те, которые в сумме покрывают процесс решения оцениваемой задачи. Иногда, конечно, точно сложить пазл нельзя — тогда и возникают основные погрешности, ну типа "текущая задача это как задача Х + задача Y + еще кропаль", и вот с оценкой этого кропаля могут возникнуть проблемы, т.к. его не с чем сравнить :)
К слову, единый эталон при определении СП — это тоже очень большой минус, т.к. на практике с этим эталоном можно адекватно сравнивать только очень узкий пул задач. Так что по факту сравнение идет не только с эталоном но и с другими оцененными задачами (иначе никак, т.к. нельзя сравнивать несравниваемое), и тогда погрешность только накапливается. В случае часов накопления погрешности не происходит, т.к. идет постоянная подкрутка — вы всегда ретроспективно обновляете эталонные оценки, подкручивая их под реальные сроки выполнения.
Зачем?
Как раз чтобы привести к единому стандарту, чтобы не у каждого своя была, а более-менее общий пул. При оценеке в СП, конечно. В часах я не понимаю как делать общую более-менее достоверную оценку, применимую для каждого. Ну разве что выбирать исполнителя на этапе планирования и общей оценки вообще не делать, только его оценку и принимать. Иначе составление плана будет адом, в моём понимании. Собственно какой календарный план может быть, если не знаем будет задача делаться час или 10 без сработавших рисков, просто смотря по тому кому она достанется.
Почему не знаем? Знаем, это суть эталонки. Человек эталонки по факту выполнял и, с-но, точно знает, сколько они занимают.
При оценке в СП знания сколько времени занимают эталонки не нужны. А в часах я сомневаюсь, что кто-то считает "в прошлый раз, год назад, подобная задача заняла у меня 1 час 25 минут, так и оценю", скорее будет минимум 1,5 часа, а может и 2 просто "по ощущениям" "за час не уложусь, значит два".
В случае часов накопления погрешности не происходит, т.к. идет постоянная подкрутка — вы всегда ретроспективно обновляете эталонные оценки, подкручивая их под реальные сроки выполнения.
Кто этим реально систематически занимается? А при оценке в СП без привязки к часам и личностям, только к спринту эта подстройка идёт реально автоматически.
К слову, при оценке в СП при таком подходе понятие ошибки в оценке задачи сильно сужается, ошибкой становится "слишком много/мало взяли СП на спринт". То, что задачу в 1 СП делал в два раза дольше чем в 2 СП по сути ошибкой оценки не является, если более-менее точно оценили весь бэклог спринта в целом. Как по мне, то отвязываясь от часов мы улучшаем психологическое состояние команды из-за сужения понятия ошибок и отсутствия дедлайна на каждую конкретную задачу.
Как раз чтобы привести к единому стандарту, чтобы не у каждого своя была, а более-менее общий пул.
Зачем? Это же мешает точной оценке. Какой смысл тратить время на действия, которые гарантированно приносят исключительно вред? Назло маме уши отморозил — что-то из этого разряда? :)
Ну разве что выбирать исполнителя на этапе планирования и общей оценки вообще не делать, только его оценку и принимать.
Икзактли! Вообще говоря, никакая оценка кроме оценки исполнителя смысла не имеет. По-этому описанный вами вариант — это вообще единственно возможный вариант работы. Что в случае часов, что в случае СП, т.к. производительность команды в СП зависит от того, кто и какую взял задачу.
Скорость работы команды (с, с-но, планы) всегда зависит от того, кто и какую задачу делает. Распределите задачи так — будет один план, распределите эдак — другой.
При оценке в СП знания сколько времени занимают эталонки не нужны.
Ну, во-первых, какая разница нужны или нет, если они по факту есть? Ну то есть вам не надо никак усилий прилагать, они просто сразу есть.
Но в любом случае, они конечно нужны — иначе как сравнивать? Если вы не знаете, сколько времени занимает эталонка, то вы никак не сможете заявить, что задача Х занимает вдвое больше, чем эталонка.
А в часах я сомневаюсь, что кто-то считает "в прошлый раз, год назад, подобная задача заняла у меня 1 час 25 минут, так и оценю", скорее будет минимум 1,5 часа, а может и 2 просто "по ощущениям" "за час не уложусь, значит два".
Ну да, по ощущениям. А ощущения берутся на основе опыта решения соответствующих задач, ибо больше им взяться неоткуда. Вся эта работа происходит бессознательно — и потому максимально эффективно.
Кто этим реально систематически занимается?
Все занимаются, автоматически. Никаких усилий для этого прилагать не надо, просто когда у вас есть "ощущение", что за полтора часа, может и не успеете, а за два — успеете, то это вот оно и есть. В этом ощущении учтен ваш опыт, и по мере роста этого опыта (сбора статистики вашим мозгом, то есть) происходит постоянная подкрутка ощущений.
То, что задачу в 1 СП делал в два раза дольше чем в 2 СП по сути ошибкой оценки не является,
Ну в этом суть СП — делайте любую оценка и она в любом случае верна. А если не успели — то это не медленно работали и не плохо оценили, а просто: "много взяли на спринт", возьмем меньше. Только если как вы сами заметили — выполнение по времени 1сп дольше чем 2сп не является ошибкой, то ну взяли вы на следующий спринт не 100сп, а 50сп задач, но выполняли их в итоге двое больше. И что? :)
то отвязываясь от часов мы улучшаем психологическое состояние команды из-за сужения понятия ошибок и отсутствия дедлайна на каждую конкретную задачу.
А, ну это как не ставить детям плохие оценки, а вместо этого рисовать цветочки в тетрадку? Ну да, да. Только вот такая штука — она и в школе-то не очень, а мы вроде про взрослых дядек говорим, не? Которые работают, не? И несут какую-то ответственность, не? И вы предлагаете, чтобы "психологический климат" был лучше просто не учитывать метрики по которым можно про*баться и вместо этого ввести свои, особенные метрики, по которым все молодцы? :)
Сделали в этом спринте больше СП чем в прошлдом? Мы молодцы! Сделали меньше? Ну просто много сп в спринт напихали :)
Это же несерьезно, извините. И неопнятно, как связано с планированием. То есть, допустим, можно принять этот аргумент. Но тогда так и надо говорить — СП они не для планирования, а для того, чтобы поддерживать "психологический климат", чтобы вместо дедлайнов — котятки и цветочки :)
И с этим тогда будет, действительно, трудно спорить.
Зачем? Это же мешает точной оценке. Какой смысл тратить время на действия, которые гарантированно приносят исключительно вред?
Наоборот, это оценку приближает к объективной как к суперпозиции субъективных. Оценку именно сложности, не времени.
Икзактли!
:) Начинаем понимать друг друга
Вообще говоря, никакая оценка кроме оценки исполнителя смысла не имеет. По-этому описанный вами вариант — это вообще единственно возможный вариант работы.
Не единственный. Как с точки зрения авторитарного менеджмента, который дедлайны спускает сверху (часто без особых объективных оснований типа новых законов или каких-то иных внешних событий типа периодов повышенной потребительской или деловой активности), а там как хочешь так крутись и готовься к наказанию. Так и с точки зрения оценки в СП, которая "прячет" разницу в средней производительности членов команды с одной стороны, а, с другой, выявляет пробелы в компетенциях. Когда только исполнитель оценивает, то если он в неё попал (с обоих сторон), то сложно сказать что-то о его компетентности кроме как адекватности оценок. Мнение "я бы эту задачу сделал в 2 раза быстрее" лишь мнение.
Скорость работы команды (с, с-но, планы) всегда зависит от того, кто и какую задачу делает. Распределите задачи так — будет один план, распределите эдак — другой.
А не распределим вообще на этапе планирования (за редким случаем) будет третий, пускай не обеспечивающий максимальную производительность, которую объективно можно было бы запланировать на конкретном спринте, но обеспечивающий такие вещи как: разделение знаний, как следствие снижение бас-фактора и рост "вширь", вплоть до Т и даже Ш специалистов. Снижение количества приоритетных задач которые приходится оставлять в бэклоге, потому что ключевой специалист по какому-то типу задач уже нагружен, а остальные в часах даже оценить не могут. Ну и индивидуальные оценки ставят под вопрос вообще существование команды, может просто группа узкопрофильных специалистов, которые и помочь друг другу толком не могут. То есть в долгосрочной перспективе распределение задач по принципу общей очереди увеличивает производительность команды, выявляя и обычно заполняя пробелы в компетенциях.
Ну, во-первых, какая разница нужны или нет, если они по факту есть? Ну то есть вам не надо никак усилий прилагать, они просто сразу есть.
Нет по факту. Я вот участвовал в оценивании в первый рабочий день на новом месте, ещё ни строчки кода даже не посмотрев. Просто исходя из общего понимания, что изменение текста нескольких сообщений для пользователей должна быть простейшей задачей при более-менее равномерном DX в разных частях системы. Я не мог (да и почти за месяц скоро не могу) оценить её в часах. Но могу сказать, например, что задача добавления новой сущности и создания CRUD ендпоинта будет раз в 10 сложнее на большинстве проектов, если там нет кодогенераторов.
Ну да, по ощущениям. А ощущения берутся на основе опыта решения соответствующих задач, ибо больше им взяться неоткуда.
Ощущения времени могут быть ложными. Просто по факту незнания а сколько задача заняла. Я вот крайне редко анализирую позадачно попал в первоначальную оценку в часах или нет, даже если логирую время. да и вообще сколько времени реально это заняло понимаю только если один раз залогировал, и то посчитав ретроспективно, когда начал и когда закончил, исходя из 8 часов рабочего времени и часа на обед. По крайней мере когда выступаю в роли исключительно разработчика. То есть у меня сознательно получаемой обратной связи о корректности моих прогнозов фактически нет. А вот в сторипоинтах или других попугаях анализирую как разработчик — это интересная мне метрика.
Ну в этом суть СП — делайте любую оценка и она в любом случае верна. А если не успели — то это не медленно работали и не плохо оценили, а просто: "много взяли на спринт", возьмем меньше.
Не в любом, просто сужается область неверности. И если не успели, то анализируем неверно оценили сложность задач или медленно работали, благо что есть агрегированные метрики прошлых спринтов.
Только вот такая штука — она и в школе-то не очень, а мы вроде про взрослых дядек говорим, не? Которые работают, не? И несут какую-то ответственность, не? И вы предлагаете, чтобы "психологический климат" был лучше просто не учитывать метрики по которым можно про*баться и вместо этого ввести свои, особенные метрики, по которым все молодцы? :)
Ответственность-то никуда не девается. Сами говорили, что результат оцениается стейкхолдерами "успели не успели сдать скоуп". Вот за это и ответственность. Анализ причин почему не успели (или много времени свободного осталось) — внутреннее дело команды и общая ответственность перед стейкхолдерами за общий результат. Да, и анализ прежде всего по оценкам. Буквально перед каждым список задач и каждый говорит где в оценках сложности про*бались, а где просто раздолбайничали.
СП они не для планирования, а для того, чтобы поддерживать "психологический климат", чтобы вместо дедлайнов — котятки и цветочки :)
СП для планирования, но для планирования внутри команды, без привлечения менеджмента и стейкхолдеров — они получают только результат планирования по сути. Им неинтересна скорость работы в СП, их либо устраивает скоуп работ которые команда взяла по окончанию планирования или не устраивает. Ну и потом результат, конечно, успели или нет выполнить запланированное.
Если же команда оценивает в часах, то менеджмент очень быстро на практике становится микроменеджментом, те же диаграммы Ганта начинает строить позадачно и персонально и спрашивать каждого лично за несовпадения оценок и фактов. В теории можно без этого, на практике не встречал. Наверное потому что для менеджмента часовые оценки родная стихия, они знают что с ними делать, а вот СП что-то непонятное с одной стороны, а с другой если это даёт устраивающие результаты, то чем бы дитя не тешилось :)
Наоборот, это оценку приближает к объективной как к суперпозиции субъективных. Оценку именно сложности, не времени.
Мы вроде уже выяснили, что сложность оценить нельзя количественно, т.к. она неизмерима. Так что когда вы оцениваете сложность — вы все равно выбираете в итоге какую-то измеримую вещь. Обычно это время.
Но даже если забыть про это — в любом случае ограничение пула задач для сравнению ведет строго к уменьшения точности. При этом то, что пул будет одинаков вообще никаких плюсов не дает.
Я уж не говорю про вырожденные случаи, когда пул состоит из одной задачи и все вообще предельно плохо :)
Не единственный.
Окок. Единственный, который может стабильно давать вменяемые результаты :)
Слишком сильно различается производительность между разными исполнителями, даже если уровень исполнителей один и тот же. Это даже не 2-3 раза — бывает разница, натурально, в десятичный порядок.
Когда только исполнитель оценивает, то если он в неё попал (с обоих сторон), то сложно сказать что-то о его компетентности кроме как адекватности оценок.
Оценивают все, вы же во время оценки не знаете, кто исполнитель. И по этим оценкам сразу видно компетенции. Ну точнее это вообще как происходит — еще на стадии оценки, если Вася ставит больше (меньше) остальных, то его спрашивают — а почему. И тогда сразу выясняется про компетенции все.
А вот когда в итоге вы анализируете выполнение плана (ну и сам план строите) вы, конечно, берете оценку исполнителя за базис, т.к. именно он исполняет и особо тут уже не важно, что остальные наоценивали (разве что с точки зрения статистики потом эту инфу можно использовать).
А не распределим вообще на этапе планирования (за редким случаем) будет третий
Да это все прекрасно, но я ж не о том. Я о том, что нету такой вещи как "производительность команды".
Я говорю про то, что в зависимости от распределения задач у вас меняется СП которые команда может за спринт выполнить, и это "меняется" — это легко разница в разы. С-но "сп в спринт" — абсолютно бесполезный и бессмысленный показатель, который ничего не показывает, по факту. Вот я о чем :)
Нет по факту. Я вот участвовал в оценивании в первый рабочий день на новом месте, ещё ни строчки кода даже не посмотрев.
Полное понимание всеми участниками оценки объема работ, необходимых для выполнения задачи, является в скраме необходимым условием выставления оценки. Пока есть кто-то, кто не понимает — оценки просто не ставятся, происходит уточнение задачи, декомпозиция, возможно вообще перенос на куда-то там. Условно говоря, это тогда просто незадача.
Но могу сказать, например, что задача добавления новой сущности и создания CRUD ендпоинта будет раз в 10 сложнее на большинстве проектов, если там нет кодогенераторов.
Ну вот именно что не можете, если не знаете как устроены соответствующие подсистемы. И, скажу вам, я лично сталкивался с кейзом, в котором сделать новый эндпоинт было гораздо проще, чем изменить "несколько сообщений". Вы просто при своей оценке тут делаете некие предположения о том, как все устроено, и что маловероятно, что оно устроено сильно иначе. Но тут не важно СП или часы — это работает одинаково в обоих случаях.
Когда у вас новый человек — это исключительный кейс, он ничего не может нормально оценить, понятное дело, ни в часах ни в СП вообще никак и этот кейс особым образом в любом случае обрабатывается, пока человек не начнет быть "в теме" и не сможет начать нормально использовать свой опыт.
Ощущения времени могут быть ложными.
Ощущения сложности — тоже. Тем более, что они основываются на ощущениях времени.
Я вот крайне редко анализирую позадачно попал в первоначальную оценку в часах или нет, даже если логирую время.
Для этого не надо ничего оценивать, это же сразу видно. Было поставлено 8ч (например) а вы залогировали 10ч. Что тут анализировать? Во время проставления сразу и видите, что потратили на два часа больше.
А вот в сторипоинтах или других попугаях анализирую как разработчик — это интересная мне метрика.
Ну это уже дело вкуса. Мне во часы более интересны.А стори поинты неинтересны, т.к. они не несут никакой информации.
Буквально перед каждым список задач и каждый говорит где в оценках сложности про*бались, а где просто раздолбайничали.
Так а толку что каждый говорит, если это все только угадайка? :) С часами же сразу видно где беда, не надо угадывать.
Если же команда оценивает в часах, то менеджмент очень быстро на практике становится микроменеджментом
Можно, конечно. Но зачем?
Наверное потому что для менеджмента часовые оценки родная стихия
Слушайте, ну если у вас какой-нибудь аджайл во все поля, то у вас нету никакого менеджмента, который будет делать диаграммы ганта. Ну или вы как член команды можете со всей командой послать этого человека на*уй с его гениальными идеями.
А если у вас менеджмент с диаграммами ганта — то у вас менеджмент с диаграммами ганта, забудьте про сп, разговор в этом контексте не имеет смысла :)
Так что когда вы оцениваете сложность — вы все равно выбираете в итоге какую-то измеримую вещь. Обычно это время.
Некоторые выбирают не только время. Собственно оценка в СП подразумевает, что это не только время и уж точно не время конкретного исполнителя, а какие-то абстрактные человеко-часы. Например часы среднего миддла независимо от позиции оценивающего, если уж время доминирующим оказывается.
Это даже не 2-3 раза — бывает разница, натурально, в десятичный порядок.
Бывает, да. Тут уже на ретроспективе решается почему так получилось и что с этим делать. ОДин из варинтов — не давать задачи такого типа этого исполнителю, но это только один из многих.
А вот когда в итоге вы анализируете выполнение плана (ну и сам план строите) вы, конечно, берете оценку исполнителя за базис, т.к. именно он исполняет и особо тут уже не важно, что остальные наоценивали (разве что с точки зрения статистики потом эту инфу можно использовать).
Если план составляется по общей оценке без назначения исполнителя и учёта его потенциального уровня, то скорее всего часы оценки будут близки к СП. Иначе я не представляю как это работает. Сеньор говорит два часа, джун — 8 часов, на вопрос почему так долго говорит надо будет разобраться с тем-то, то в план же пойдёт часов 5?
С-но "сп в спринт" — абсолютно бесполезный и бессмысленный показатель, который ничего не показывает, по факту. Вот я о чем :)
Показывает по сравнению с планом — верно оценили производительность команды или нет. Если нет, то надо разбираться почему.
Полное понимание всеми участниками оценки объема работ, необходимых для выполнения задачи, является в скраме необходимым условием выставления оценки.
Согласен, самого удивило, что меня позвали. Но полное понимание часто на практике недостижимо из-за разделения труда и разной квалификации.
Вы просто при своей оценке тут делаете некие предположения о том, как все устроено, и что маловероятно, что оно устроено сильно иначе. Но тут не важно СП или часы — это работает одинаково в обоих случаях.
По разному. Оценку в часах я бы просто отказался давать. Потому что по опыту знаю, что на порядки может различаться даже у самого опытного на этих задачах человека в команде. Но по тому же опыту знаю, что у большинства систем сложность равномерно распределена по системе, а если нет, то чаще всего есть кусок легаси, который страшно трогать и есть что-то нормальное. И я задавал вопрос — это легаси или нормально.
Для этого не надо ничего оценивать, это же сразу видно. Было поставлено 8ч (например) а вы залогировали 10ч. Что тут анализировать? Во время проставления сразу и видите, что потратили на два часа больше.
Как минимум это надо посмотреть что было 8, ну или помнить, какую оценку дали. А 10 часов может сложиться из нескольких логов, так что даже считать не будешь, а сколько всего потратил. Я вообще очень радовался, когда логирования времени прямого не было, только статусом задачи манипуляция, которую вообще из IDE делал.
С часами же сразу видно где беда, не надо угадывать.
Ну как сразу видно оценка рабочего времени была неверная или не всё время задачи по факту было рабочим?
А если у вас менеджмент с диаграммами ганта — то у вас менеджмент с диаграммами ганта, забудьте про сп, разговор в этом контексте не имеет смысла :)
Я про то, что если менеджмент видит часы, то он начинает рисовать даиграммы. А если видит непонятные сп, то довольствуется бёрндаун графиком :)
Некоторые выбирают не только время.
Строки кода еще можно.
Я серьезно, встречал такое :)
Сеньор говорит два часа, джун — 8 часов, на вопрос почему так долго говорит надо будет разобраться с тем-то, то в план же пойдёт часов 5?
В план пойдет столько кому задача будет поставлена. Ну какой смысл если исполнитель говорит что "сомневаюсь что сделаю за 5, скорее это 8" давать ему 5 часов? Ну то есть вы можете так сделать, конечно, но, извините, надеяться потом что все будет в срок — будет большая глупость.
Как минимум это надо посмотреть что было 8, ну или помнить, какую оценку дали.
Ну, типа, эта цифра стоит у задачи в вашей джире или что там у вас, как и:
А 10 часов может сложиться из нескольких логов, так что даже считать не будешь, а сколько всего потратил.
Суммарные затраты тоже. Серьезно, 2019. А вы тут про "не помню".
Но полное понимание часто на практике недостижимо из-за разделения труда и разной квалификации.
Ну тогда "нерелевантных" юнитов можно не опращивать. Если человек не представляет объем работ по задаче, он никакой оценки не даст (ни в СП ни в часах), если он при этом не является потенциальным исполнителем (ну работает на другой частью ситсемы, или там он бек, а задача по фронту, или еще что), то, вообще говоря, нету никакой проблемы в том, что он и оценку ставить не будет. Потому что если он и поставит — это оценка-рандом, что в случае часов, что в случае СП. И нет никакой необходимости нервы человеку трепать.
Ну как сразу видно оценка рабочего времени была неверная или не всё время задачи по факту было рабочим?
Если человек говорит что он работал когда не работал, то вам никакое планирование не поможет. Ии в случае СП все еще печальнее, т.к. к этим вариантам добавляются многие другие.
В план пойдет столько кому задача будет поставлена.
От того, чтобы в плане ставить исполнителя и стараемся уходить — это исключительный случай должен быть. Это получается жёсткий план, микроменеджмент. С одной стороны. С другой стороны тратятся ресурсы на само планирование, которое редко бывает точным и вообще выдерживается даже приблизительно. И вообще по сути диаграмма Ганта получается, только критические пути выстроить осталось :)
В план пойдет столько кому задача будет поставлена.
Не получается идею донести :( Я просто не смотрю на на оценки, уже залогированное время и т. п., я ввожу время по завершению задачи или дня и всё. Мне просто неинтересно по конкретным задачам насколько факт отличается от оценки в часах. Когда джира хорошо настроена, я в неё захожу только чтобы задачу прочитать или комментарий оставить: переключение статусов делаю не выходя из IDE, а время само логируется.
Если человек говорит что он работал когда не работал
Логировать каждую минуту это уже не микроменеджмент, а нано менеджмент. Кто-подошёл что-то рассказать, узнать, посоветоваться или попросить показать. Услышал краем уха обсуждение какое-то и влез. Живот прихватило.
От того, чтобы в плане ставить исполнителя и стараемся уходить — это исключительный случай должен быть.
Если исполнителя в плане нет значит задача не выполнена. Потому что если она выполнена — ее кто-то сделал, а если ее кто-то сделал — тот этот кто-то исполнитель, а значит — исполнитель есть.
Логировать каждую минуту это уже не микроменеджмент, а нано менеджмент.
А кто говорит о логировании каждой минуты? Ну отошел/отвлекся и ладно. У нас же речь о том, что человек весь день котиков смотрит, а потом пишет: "работал 8ч".
Мне просто неинтересно по конкретным задачам насколько факт отличается от оценки в часах.
Ну а мне неинтересно сколько в СП. Какая разница, кому что интересно? Это вообще нерелевантный фактор.
Так постоянная коррекция — неотъемлемая часть скрама и вообще аджайла.
Ну так с СП коррекции нет, т.к. нет данных, по которым можно корректировать.
То же, да не совсем. Тратится общее время спринта, а не конкретной задачи и даже не конкретного человека.
Так а какая разница? И там и там в задачу просто включается "восстановление" и все. Это не надо делать явно. Просто если у вас задача, которая делается 8ч, и после нее надо отдохнуть 4ч, просто записывается как 12ч (хотя вообще конечно это в принципе странная штука, что надо "восстанавливаться", это само по себе уникальная ситуация, которую следует отдельно обрабатывать). С-но именно это и происходит при оценке в СП.
Мы не подбираем такой коэффициент. Если не уложились во вроде бы реалистичный план, то анализируем ретроспективно что пошло не так и следующий план составляем с учётом анализа. Без явных персональных коэффициентов на уровне команды — их обычно только менеджеры используют для, грубо говоря, аттестаций.
На одну задачу — увеличивай вдвое, на другую — уменьшай вдвое, третью — пл плану делай. Фишка СП в том, что статистически они друг друга нивелируют. Выбросы могут быть и их нужно анализировать.
На одну задачу — увеличивай вдвое, на другую — уменьшай вдвое, третью — пл плану делай. Фишка СП в том, что статистически они друг друга нивелируют.
Это когнитивное искажение :)
По факту все не так.
Ошибка в данном случае моделируется случайным блужданием, а оно уходит от нулевой отметки пропорционально корню из количества шагов. Т.е. без постоянной коррекции ошибка будет нарастать.
Я бы не сказал, что равносильно. Вы неявно допускаете, что время выполнения эталонной задачи фиксировано и время больше ни на что не тратится — вот это чистаые манипуляции.
Логика и математика из утверждения "за две недели сделаем 100 эталонов" позволяют лишь сделать вывод "в среднем на двухнедельной выборке выполнение эталонной задачи занимает не более 1/50 недели"
Вот только эта оценка никакого практического смысла не имеет, потому ни автоматически, ни вручную делать её не нужно.
Пропорциональность никто не отрицает, вот только пропорциональность эта не для временных отрезков, а для сложности.
Примерно сравнивая количество СП, сделанных в прошлых спринтах и планируемое в текущем.
Например, оценивают задачу в своих в 1 сп. Неизвестно кто будет задачу делать, но понятно, что команда может сделать четыре таких задачи за спринт. А когда джуны до миддл дорастут сможет команда 5 делать. Собственно привязка к сторипоинтам позволяет отслеживать рост проищводительности
Скорость работы в SP понимается очень просто. Ретроспективно мы видим, сколько SP делает команда за спринт. Это позволяет нам понять, сколько SP команда сможет сделать в следующем спринте. Это и есть скорость работы.
Когда мы оцениваем задачу в SP, мы не пытаемся ответить на вопрос "за какое время можно её выполнить", потому что на этот вопрос корректно ответить крайне сложно, и чем больше задача — тем сложнее (см. феномен ошибки планирования). SP — это совокупная оценка трех факторов:
- предполагаемая сложность задачи
- предполагаемое время выполнения задачи
- предполагаемые риски, которые могут повлиять на выполнение задачи (например, плохая постановка, или зависимость от внешних систем).
Оценка в SP является объективной, потому что не ставится от балды, а оценивается в сравнении с другими, уже оцененными задачами.
Вы говорите, что задачи, которые невозможно оценить в часах, никогда не делаются в срок. А задачи, которые типа возможно — разве делаются? Снова отсылаю к феномену ошибки планирования. Ну и я повторюсь, SP нужны не для оценки конкретной задачи, SP служат оценке скорости работы команды в целом. Вам нужен живой пример? Любая компания, грамотно прошедшая agile-трансформацию. Пообщайтесь с Avito, например. Я слышал, у них всё довольно-таки здорово.
Есть agile и без сторипойнтов. Например, Канбан. Но и там мы не пытаемся оценивать задачи в часах. Вместо этого мы, условно говоря, причисляем задачи к разным категориям (например, "маленькая", "средняя" и "большая"; в идеале такая категория должна быть одна, но, разумеется, в IT это практически невозможно), опять же сравнивая её с уже выполненными. После этого, зная за какое время у нас обычно выполняются задачи аналогичной категории, мы можем оценить вероятности выполнения этой задачи в определенные сроки.
Теперь про эффективность. Вы называете критерием эффективности ваше "не увольнение". Тогда как Вы поймете, что стали более эффективны? Вас еще более "не уволят"? Очевидно, это не самая лучшая метрика. 360 тоже сомнительный критерий — оценки субъективны. Выходит, что криитериев эффективности у Вас нет. Как же Вас умудрилось задолбать то, что вы даже не можете измерить?
Ретроспективно мы видим, сколько SP делает команда за спринт. Это позволяет нам понять, сколько SP команда сможет сделать в следующем спринте.
А зачем? Ну вот мы знаем, допустим, что команда делает 100SP за спринт, это что дает? Что с этой информацией потом можно сделать полезного?
С точки зрения бизнеса, оценка скорости команды — это вообще один из следующих вариантов: "успели во время", "почти успели", "что-то не успели", "совсем нихрена не успели".
После того, как вы ко мне пришли и отчитались, что ваша команда за спринт делает 100SP, как мне это перевести в понятные и полезные для бизнеса показатели (те, что выше указаны)?
SP — это совокупная оценка трех факторов:
Вы не поверите, но при оценке в часах тоже учитываются все эти факторы. Причем гораздо более естественным и очевидным образом, чем в SP. Потому что как учесть все это в часах — достаточно очевидно, а вот логика вывода SP у каждого своя и не формализуется.
Берёте уже оценённые в сторипоинтам задачи на 100 sp и говорите делать их в следующем спринте, имея малые риски, что вовремя сделано не будет.
Берёте уже оценённые в сторипоинтам задачи на 100 sp и говорите делать их в следующем спринте, имея малые риски, что вовремя сделано не будет.
А в чем проблема так же взять и делать в следующем спринте задачи, оцененные в часах?
При этом сколько человекочасов команда делает, я и так знаю, мне считать не надо, а вот оценка задач должна быть проведена в обоих случаях. В итоге при оценке в часах получаем тот же результат, но проще, разве нет?
При оценке в часах обычно нельзя просто посчитать, один задачу 4 часа делать будет, а другой 8 часов. Какую оценку ставить, 4, 6, 8?
При оценке в часах обычно нельзя просто посчитать, один задачу 4 часа делать будет, а другой 8 часов.
Так с СП то же самое будет. Даже если принять, что все понимают сторипоинты одинаково, все равно каждый поставит свою оценку (если мы предполагаем, что команда "неровная"). Только на самом деле под сторипоинтами еще и подразумевают все что-то свое, т.к., я уже упоминал — сторипоинты неформализуемы и неизмеримы. Серьезно, как вы можете топить за метрику с подобными свойствами?
Какую оценку ставить, 4, 6, 8?
Так и ставите: "Вася — 4ч, Петя — 8ч".
И нет никакого перевода в сп, есть оценивании в сп и знание сколько команда может делать сп за спринт. Нет никакой двойной конвертации. Две единицы измерения — спринт и сп.
Вы так и не объяснили в чем проблема с часами. Точно так же — оцениваете в часах и знаете, сколько команда может сделать часов за спринт. При этом вот этот второй показатель вам даже измерять не надо, он заранее известен. С-но, неопределенность становится ниже.
Кроме того, оценки в часах просто содержат больше информации для анализа, т.к. вы потом можете измерить — сколько задача выполнялась и сколько планировалась. Т.о., можно определить, что задача была оценена неверно. В случае сторипоинтов вы никогда не узнаете, что оценка была неверной.
Ну а какой в этом смысл? Если стратегически оценить для клиента, что вот этот вот набор фич будет стоить вам примерно X спринтов денег — тут можно хотя бы понять.
А какой смысл переводить задачи в sp, чтобы по факту вместить их в 10 дней?
Неизвестно кто будет задачу делать, но понятно, что команда может сделать четыре таких задачи за спринт
Совершенно не факт. Если у вас 4 клона сидят, то может. Но ведь может получиться, что чей-то уровень не позволит реализовать задачу даже за удвоенные сторипоинты, а если отдать её более опытному — ему не хватит часов. Может быть на длинном пути какие-то задачи окажутся проще и разница нивелируется. Но в чем тогда смысл двойной конвертации на коротких отрезках?
Ну так и есть. Прежде всего "за эти две недели мы сделаем вот этот набор фич". И нет никакого перевода в сп, есть оценивании в сп и знание сколько команда может делать сп за спринт. Нет никакой двойной конвертации. Две единицы измерения — спринт и сп. Если хотите переводите спринт в часы и получите скорость команды сп/час. Если оценивать задачи в часах, то скорость получится час/час и равной 1 при точной оценке. Ну и анализ будет типа работы за 300 часов мы сделали работы на 250 часов, а обещали на 300. Что с этим анализом делать? Давайте в следующий раз на 300 часов пообешаем сделать работы на 250 часов, чтоб не краснеть, что не выполняем обещания?
Ну вот мы знаем, допустим, что команда делает 100SP за спринт, это что дает? Что с этой информацией потом можно сделать полезного?
У вас же еще должен быть список желаемых задач. Та же самая команда их оценивает в SP. Бизнес потом может выбрать столько задач на следующую итерацию, сколько успевает сделать команда.
"успели во время", "почти успели", "что-то не успели", "совсем нихрена не успели".
…
понятные и полезные для бизнеса показатели (те, что выше указаны)?
Почему вдруг эти показатели понятны и полезны для бизнеса?
Бизнесу как раз важно знать сколько денег он потратит и что за это получит. "что-то не успели" это сколько тугриков?
У вас же еще должен быть список желаемых задач. Та же самая команда их оценивает в SP. Бизнес потом может выбрать столько задач на следующую итерацию, сколько успевает сделать команда.
А почему бизнес так же не может выбирать в часах, а не в СП? Смотрите, вы сейчас называете преимущества оценки в СП над отсутствием оценки в принципе. Ну да, лучше в СП, чем никак. Но мы же сравниваем с часами? И по факту, СП, как метрика — это говно. Потому что СП неформулизуемы, субъективны и неизмеримы. С другой стороны — часы это метрика прекрасная, т.к. это вполне определенная физическая величина, которую можно объективно измерить.
Почему вдруг эти показатели понятны и полезны для бизнеса?
Потому что доставка фич в рамках заданных затрат — это единственное, что бизнес волнует. Будет доставлено, или не будет.
"что-то не успели" это сколько тугриков?
Это уже не задача лида такие тугрики считать, у него нет соответствующей информации для расчетов. Вот тот, кому лид отчитывался, потом по "успели это не успели то" сможет посчитать тугрики. А по "планировали 100сп, но сделали 80сп" он ничего посчитать не сможет.
А почему бизнес так же не может выбирать в часах, а не в СП?
Потому что в часах все очень сильно зависит от того, кто будет делать. СП это абстракция с целью нивелировать различие между разными членами команды. Можно конечно взять другую абстракцию и назвать ее "часами среднего миддла", а потом делать поправки вроде "джун делает 2 раза медленнее миддла" или "сеньор делает в 2 раза быстрее миддла". Разница будет только в том, что простейшая типовая задача не будет единицей СП.
часы это метрика прекрасная, т.к. это вполне определенная физическая величина, которую можно объективно измерить.
Часы можно измерить постфактум. А на этапе планирования их никак нельзя измерить.
Потому что СП неформулизуемы, субъективны и неизмеримы.
СП это гипотеза, которая статистически проверяется (обычно) каждые две недели. Чем дольше работает команда, тем точнее оценка в СП. У опытной команды ситуация "планировали 100 СП, сделали 80" говорит о серьезной недооценке задач.
Потому что оценка в часах не учитывает:
- кто будет делать задачу
- риски, возникающие при выполнении задачи
Рекомендую почитать про феномен ошибки планирования.
Потому что доставка фич в рамках заданных затрат — это единственное, что бизнес волнует.
Agile позволяет делать эти прогнозы с большей точностью, чем традиционные подходы. Статистический факт =)
По СП не требуется "успевать", потому что СП не оценивает сроки. Ей-богу, уже начинает надоедать снова и снова повторять в тредах к этому посту — СП != часы, это не связанные друг с другом единицы.
Каким образом вы собираетесь набирать себе задач на 10 рабочих дней, если оцениваете задачи в виде "в лучшем случае я сделаю её за день, в худшем — за 5 дней"? Сколько таких задач вы возьмете? 2? Или 10?
На ваш вопрос уже отвечено тут: https://habr.com/ru/company/dodopizzaio/blog/456068/#comment_20283998
Почему не подходят часы: потому что предполагаемое время выполнения задачи — это только часть оценки, и если оценивать только время, существует измеримый риск недооценить задачу (см. феномен ошибки планирования, на который я уже устал ссылаться).
Оба ваших варианта существенно увеличивают риски недооценки задач и неправильного прогноза их выполнения.
Да, разумеется, с чего-то нужно начинать. Обычно за основу берутся какие-то общепринятые шкалы, коих в интернетах полно. В процессе работы, как правило, принятая шкала корректируется и адаптируется под проект.
Вы всё правильно подумали. Тогда в чем вопрос? Да, для оценки новых задач нужно брать уже оцененные, потому что задачи нужно оценивать не сами по себе, а сравнивая с уже выполненными и оцененными.
Если таковых в проекте еще нет — существуют методики для того, чтобы начать оценку.
Вопрос в том, как именно оценивать конкретную задачу?
Но я уже отвечал на этот вопрос. Оценка задачи проводится путем сравнения её с уже выполненными и оцененными. Несколько первых собраний по оценке разработчику, разумеется, потребуется обращаться к какой-то шпаргалке, но постепенно это становится проще. Причем гораздо проще, чем пытаться оценивать в часах.
Важный момент — оценка проводится коллегиально, как правило, путем голосования. Оценку не ставит один человек.
Пару слов о вышеупомянутой шпаргалке — в наших командах она выглядит, как правило, как таблица, строки которой представляют собой ряд "N SP" — "примерное описание типовых задач" — "примеры задач, оцененных в N SP".
А кто мешает так же делать, ну, для оценки в часах?
Извините, но я больше не хочу говорить про часы. В обсуждении к этому посту примерно миллиард раз было сказано, чем плоха оценка в часах, и я не хочу повторяться.
А смысл, если я спец по плюсам, Васян спец по рекуррентным нейросетям для NLP, Колян спец по питону
Это какой-то абстрактный набор слов, или у Вас действительно есть некий проект, в котором работает ровно три человека с настолько разными наборами компетенций?
Нет, никакой магии.
Сторипойнт — это объективная (за счет коллегиальной оценки) и относительная (за счет сравнения с другими задачами) единица измерения. Да, ретроспективно можно посчитать вероятность, с которой задача, оцененная в N сторипойнтов будет выполнена за определенное количество часов, но зачем? Оценка нужна для того, чтобы решить, брать задачу в спринт или не брать. Да, в конкретной задаче можно ошибиться с оценкой, но задач в спринте много, и ошибки нивелируют друг друга.
Разумеется, вы можете попытаться использовать такую шкалу, в которой 1 сторипойнт будет соответствовать, например 85% вероятности успеть сделать задачу за 1 час, ради бога (хотя на больших задачах начнутся проблемы). Вы даже можете называть эти сторипойнты часами. Но для того, чтобы корректно выстроить такую шкалу, понадобится сделать кучу работы и ради чего? Ради того, чтобы научиться точно оценивать задачу в часах? Но ведь это и не требуется. Оценка в SP проще, чем оценка в часах, при этом она объективнее и позволяет достоверно планировать.
Мне кажется, в этом основная ошибка всех, кто доблестно сражается со сторипойнтами — непонимание, что оценивать в SP проще, чем в часах.
Потому что с оценкой в часах люди чаще ошибаются.
Давайте я попробую продать Вам идею сторипойнтов под соусом, которым закончил предыдущий комментарий.
Смотрите, когда Вы пытаетесь оценить задачу в часах, у вас есть огромная шкала от 1 до N часов. В процессе оценки Вам понадобится оценить задачу максимально точно, иначе смысл оценивать её в часах (ведь эту оценку мы потом хотим использовать для понимания, какие задачи брать в итерацию). Для этого Вам нужно будет сравнивать каждую задачу с довольно-таки большим числом других задач — и всё равно это будет неточно, и каждый раз будут возникать сомнения, а три это часа или четыре, семь или девять и так далее, и в итоге вы всё равно ошибетесь — и чем больше задача, тем больше вероятность ошибки.
Каноничная оценка в SP проводится на гораздо меньшей шкале. Самая часто используемая шкала — ряд Фибоначчи из 4-5 чисел. У вас есть 1, 2, 3 и 5 сторипойнтов (ну и, допустим, 8 для особо крупных задач, которые не удалось декомпозировать). Разница между 3 и 5 сторипойнтами, как правило, весьма прозрачна (хотя это тема для отдельного обсуждения).
Мой пойнт в том, что оценка в сторипойнтах проще и объективнее. Она менее точна, но для планирования спринтов это и не требуется.
Скажите, задачу, которую Вы оцениваете в 3 дня, Вы действительно делаете ровно три дня?
Если вы откладываете задачу, которую делали три дня — вы не просто НЕ максимизируете предсказуемость, вы совершаете одно из страшнейших преступлений против эффективности — копите незавершенную работу, но это отдельная тема...
Ладно, как бы то ни было, получается, что вы, во-первых, не стремитесь к точной оценке, во-вторых, пытаетесь учитывать все факторы, влияющие на время выполнения задачи, и, в-третьих, оцениваете задачу, сравнивая её с предыдущими. Поздравляю, Вы уже используете сторипойнты, правда мне решительно непонятно, зачем Вы называете их часами, если это не часы.
Я сравниваю её со всем опытом, а не с какой-то конкретной эталонной задачей или набором задач.
Да, в конечном счете к этому и приходят. Оценка появляется в голове "сама собой".
Достаточно оценивать со стабильной и не сильно большой дисперсией отклонения, а там ЗБЧ вывезет.
Да, так работает емкость спринта.
В общем-то, чуть-чуть добавить осмысленности и коллегиальности — и будут полноценные сторипойнты. Непонятно, почему Вы с ними воюете ¯_(ツ)_/¯
Если вы работаете над потоком задач не командой — то тут уже другой вопрос. Аджайл всё-таки для команд, а не для одиночек.
по-моему, все противники часов в треде забывают про уже давно существующие "сторипоинты" ещё со времён мануфактур и заводов…
Называются они "человекочасы".
И вы не поверите… К хронологическим часам они привязаны весьма и весьма относительно.
// и мне уже полтреда так и хочется попросить рассказать как же сисадминам/инженерам/техподдержке и т.п. оценивать абсолютно разные каждый раз задачи (появляющиеся в процессе спринта, а не заранее) в сторипоинтах?
TL;DR версия описанного ниже: смысл оценки в сторипоинтах, если постоянно всплывают такие задачи, что за планируй-не-планируй, а за спринт, в который пытаются упихнуть — не взлетит.
Плюс, ладно в компаниях где я консультирую существует такой человек как я, который при обсуждении любого вопроса всегда прикидывает максимально возможное количество трудностей, которые помешают реализации (хотя и я, порой, недооцениваю степень их влияния). Но ведь такие "пессимисты" как я есть далеко не везде, и "привет продалбывание спринтов". А ещё есть менеджеры, штрафующие команду за продолбанные спринты.
Так вот...
Ну да, задачи "настроить NginX" на одном на другом сервере, казалось бы, можно друг относительно друга посчитать.
Хотя, ведь, даже тут "заказчики" любят постоянно чего-то недоговаривать в задаче: то у них ОС окажется слишком старая, то окажется, что проект не умеет в современный php/python/whatever, и php/… надо древнючий из глубин ада достать, то вообще nodejs из bleeding edge воткнуть.
То от апстрима неожиданные сюрпризы...
А что делать с потоком задач которые банально невозможно оценить без предварительного погружения в стек технологий?
Например, всю жизнь жили на парке железок, вдруг высокое начальство ставит задачу "переезжаем в амазон", под которую нанимает внешнего специалиста.
Потом начальство задалбывается от срывов сроков (возникших из-за недооценки, произошедшей из-за постоянных недоговорок об особенностях, ну и, может от особенностей компетенции нанятого специалиста в конкретных используемых стеках внутренностей проектов), и когда всё уже готово оно принимает решение вернуться на железки.
А потом вдруг приходит решение "строим всё на докере".
При этом докер все только "слегка щупали", и, за годы работы на голом железе не особо двигались дальше.
И знания о докерной кластеризации есть только теоретические.
Что, строим планирование исходя из теоретических знаний, которые позволят "примерно" прикинуть?
Нуок. Построили.
Посреди работы выясняем:
вот тут вот докер не может работать с glusterfs, так что надо потратить ещё два дня на перенастройку всех кластеров гластера на NFS, а так же прогнать изменения в файрволлах, чтобы кто попало не шарился по нашим вольюмам (потому что гластер, как оказывается, по NFS игнорирует выставленные ограничения доступа).
А вот тут выясняется, что Elasticsearch чтобы работать с больше чем 16 ГБ оперативки надо выставлять параметры ядра, а докер такое умеет только когда вне кластера. А в кластере — not implemeted yet.
А ещё внезапно оказывается что в java завезли баг, из-за которого она ложно предполагает что не может создавать лок-файлы на многослойных ФС, один из слоёв которой — сетевой.
И встреваем ещё на полспринта, пока строим костыли.
Потом ещё какая-нибудь внезапная херня типа бага стабильном релизе Sentry, который делает нормальную работу с ним вообще невозможной.
И так проект "на полгода" просрачивается ещё месяца на три.
А тут ещё начальство вдруг "что-то мы бюджет превышаем, давайте-ка срежем пучок серверов"...
И как в таких условиях стори-поинты помогут в прогнозах хотя бы на йоту?
А, и да, забыл самое главное:
Если сторипоинты, по итогу, "Нарекаем этой задаче 5 сторипоинтов", то почему так же нельзя наречь ей "5 человекочасов"? Зачем было придумывать сторипоинты?
и в итоге вы всё равно ошибетесь — и чем больше задача, тем больше вероятность ошибки.
оценка в сторипойнтах проще и объективнее. Она менее точна, но для планирования спринтов это и не требуется.
То есть в часах больше вероятности ошибиться, а сторипоинты сами по себе не очень точные, поэтому ошибиться сложнее?
Вы говорите о создании продукта или о прикрытии зада перед начальством?
Мой спринт такой:
— если работал и помнишь код, где нужно поменять и знаешь как это поменять, то 0,5 часа
— если не работал с кодом, но понимаешь, что поменять нужно чуть — 1 час
— если понимаешь, что поменять чуть, но с кодом не работал, в архитектуру вникать нет смысла и нужно обсуждать с заказчиком нюансы — 2 часа
— создание новой фичи на знакомом коде без архитектурных изменений — 4 часа
— любые работы, вызывающие изменение бизнес-логики или архитектуры решения — 6 часов на старте, затем по итогам этих 6ти часов
— отсутствие точных требований к задаче — плюс 1 час к расчетному времени
— ввод в работу нового проекта (подготовка рабочего окружения, изучение архитектуры) — 3-4 часа в зависимости от стека
По этой сетке можно разложить любую задачу на подзадачи и вывести расчетное время готовности проекта.
Но это, конечно, если хватает знаний для декомпозиции. А если нет — берешь паузу и в свободное от работы время учишься там, где не хватает.
Продуктивный день разработчика 6 часов. За 20 лет работы не видел ни одного уникума, способного кодить 8 часов с перерывом на обед. Чай/кофе/перекуры легко съедают 2 часа рабочего времени. Да и санитарные нормы 45/15 в час не на пустом месте придуманы были.
Без морали.
То есть в часах больше вероятности ошибиться, а сторипоинты сами по себе не очень точные, поэтому ошибиться сложнее?
Абсолютно так.
Мой спринт
Вы работаете в одиночку?
То есть в часах больше вероятности ошибиться, а сторипоинты сами по себе не очень точные, поэтому ошибиться сложнее?
Абсолютно так.
Это фиаско
Есть красное русское слово для этого случая — «очковтирательство». Кажется, оно как нельзя лучше подходит для иллюстрации смысла планирования в сторипоинтах.
Вы работаете в одиночку?
Отнюдь. «Мой» означает, что я использую эти критерии в работе. Вне зависимости мою или чужую работу планирую.
Критерии «известен-код, известно-что-делать, есть-все-требования» значительно точнее, чем «джун-мидл-сеньор» в вашем способе планирования. Вкупе с более точным инструментом измерения дают вообще фантастическую точность относительно спринтов через сторипоинты.
Смотрите, когда Вы пытаетесь оценить задачу в часах, у вас есть огромная шкала от 1 до N часов. В процессе оценки Вам понадобится оценить задачу максимально точно, иначе смысл оценивать её в часах (ведь эту оценку мы потом хотим использовать для понимания, какие задачи брать в итерацию).
Вы чушь сейчас говорите, на практике оценка в часах идет так же как в СП, потому что по факту в часах никто не меряет, а меряют скорее так: "надо полдня" или "два дня" или "ну это на полспринта/на весь спринт таска, надо побить, вообще говоря". Ну и потом ставят полдня*длина_рабочего_дня часов, например.
То есть в итоге идет оценка путем сравнения как раз с некоторой задачей, которая решается за полдня-день, и человек виртуально представляет, насколько дольше/быстрее он сделает оцениваемую задачу по сравнению с эталонной. Это все то же самое что и с СП, только в данном случае сравнивается конкретный и четкий показатель (ожидаемая продолжительность выполнения) а не абстракцию, которую численно и оценить-то никто не может, на самом деле.
Потому что оценка в часах не учитывает:
Кто будет делать учитывается ровно так же, как и в случае СП — если вы не выбирали среднее. Риски учитываются заведомо, т.к. при оценке вам всегда дают квантиль. Т.е., когда вы спрашиваете у человека "за сколько выполнишь задачу?" то он отвечает на самом деле на какой-то вопрос вроде: "сколько нужно часов, чтобы уложиться в вероятностью 9/10" (это так мозн работает при интуитивных стат. оценках). С-но, чем выше дисперсия для требуемого времени (т.е. риски) тем дальше будет смещен квантиль и выше оценка.
Agile позволяет делать эти прогнозы с большей точностью, чем традиционные подходы.
Оценка в часах будет всегда в среднем точнее. Математический факт.
Просто в силу того, что оценки в СП очень неточны — вы, в отличии от оценки в часах, не можете их проверить.
Ну то есть с часами вам сразу понятно — оценили как 10, делали 15, вот вам ошибка в 5 часов. А в СП наличие ошибки в оценке доказать вообще сложно, можете давать любую оценку, хоть рандомайзером, и по итогу она окажется "точной".
Рекомендую почитать про феномен ошибки планирования.
СП этим ошибкам точно так же подвержены.
Логика вывода SP у всех должна быть общая — для этого достаточно провести 15-минутную лекцию с объяснением, что это и как работает. Проверено личным опытом =)
Пожалуйста, хватит говорить про часы. Оценка в часах не работает. Это тоже статистический факт.
Любой процесс в этой вселенной завязан на время. Ваши сторипойнты лишь производная.
Да, часы можно вывести из СП. Обратная конвертация не работает, и оценить задачу корректно в часах невозможно.
Если такая конвертация невозможна, то сторипойнты вообще ничего не значат — это просто случайные числа, непригодные для планирования.
UPD: Ну вот, справился за плоторы. Один сторипойнт позволил бы мне пинать хер остаток дня.
Чтобы написать этот комментарий мне потребуется две минуты.
Вы серьезно аргументируете этим Вашу способность оценивать задачи, требующие несколько часов а то и дней работы?
Такая конвертация не нужна, и сторипойнты не имеют особого смысла применительно к одной задаче. Они имеют смысл в масштабе нескольких спринтов. В отличие от часов, в которых ошибка планирования имеет тенденцию накапливаться, сторипойнты благодаря механизму их проставления отображают производительность команды гораздо корректнее и точнее. Именно поэтому они позволяют планировать, а часы — нет.
Один сторипойнт позволил бы мне пинать хер остаток дня.
Если Вам действительно хочется нести подобный бред — предупредите сразу, я не буду мешать.
В отличие от часов, в которых ошибка планирования имеет тенденцию накапливаться, сторипойнты благодаря механизму их проставления отображают производительность команды гораздо корректнее и точнее. Именно поэтому они позволяют планировать, а часы — нет.
Не, вы уж говорите как есть — в отличии от часов, для которых ошибка планирования очевидна и измерима, в сторипоинтах можно давать любые оценки, и они всегда будут заведомо "правильными", т.к. для того чтобы они были "правильными" их достаточно таковыми объявить. И обратного (что оценка в сп была плохой) доказать нельзя.
Следовательно, 1 спринт = L часов.
Мы в ретроспективе можем посчитать, сколько часов заняла доставка одного сторипоинта в среднем. Но это будет вычислением корреляции сторипоинтов и часов. На длительных отрезках (множестве спринтов) будет наблюдаться корреляция. На планировании спринта мы не можем достоверно предсказать сколько часов займёт один сторипоинт.
Но это будет вычислением корреляции сторипоинтов и часов.
А вот ответьте на такой вопрос — если бы сторипоинты не коррелировали никак с часами, то в них был бы какой-то смысл и какая-то польза? Если да — раскройте, пожалуйста, какой смысл и какая польза.
Они не могут не коррелировать по определению. Но как комплексная оценка, где время лишь один из параметров, они приносят больше пользы, чем чистые часы.
Они не могут не коррелировать по определению.
Это ответ не на мой вопрос. Предположим, они не коррелируют, что тогда?
Но как комплексная оценка, где время лишь один из параметров, они приносят больше пользы, чем чистые часы.
Вы можете указать для примера, какие именно факторы учитываются в оценке СП, но не влияют при этом на время выполнения задачи? Вот конкретно. А то все, что до этого было перечислено — на время выполнения задачи влияет, с-но, при оценке часов учитывается.
Например, время на восстановление после выполнения задачи определнного типа или определнного стейкхолдера. Куда вы это время отнесёте при оценке в часах? На оцениваемую задачу? Время нужно когда задача уже закрыта. Разнести по другим по минуткам? Сделать задачу "отдых"?
Вот как в оценке в часах учитывать разную скорость разных людей на разных задачах? Оцениваем все вместе, кто будет делать неизвестно.
Разнести по другим по минуткам? Сделать задачу "отдых"?
Ну да :)
Если это отдых, и он вам нужен, то это и должен быть — "отдых", а не часть какой-то задачи. Но:
Куда вы это время отнесёте при оценке в часах?
При желании, если вам так хочется, вы можете относить туда же, куда относите соответствующие СП :)
И, кстати, оценивать отдых в СП несколько затруднительно.
Ну и при качественных оценках время выполнения всегда статистически завышается, так что с отдыхом обычно проблем не будет.
Вот как в оценке в часах учитывать разную скорость разных людей на разных задачах?
Ну вот у вас каждый оценил и вы видите оценку каждого человека, с-но знаете кто готов угадать эту мелодию за 4 ноты, а кто — за три :) С-но команда сразу в процессе эти оценки же тоже видит и сама прекрасно может определиться с тем, кто, что, когда и как :)
А в случае СП как это делать? У вас оценки будут одинаковые, т.к. оценки СП не зависят от производительности исполнителя. С-но, информации никакой нет, если только вы не ведете специально бумажку, типа "Вася лучше Пети на задачах Х", и потом в соответствии с этой бумажкой назначать.
При желании, если вам так хочется, вы можете относить туда же, куда относите соответствующие СП :)
СП относятся к задачам, после которіх необходим "сверхурочный" отдых. Но при оценке в часах так делать нельзя по многим причинам. А оценивается он в СП интуитивно, если не в первый раз. Это комплексная же оценка, включаяющая не только оценку времени, но и оценку стресса, оценку уровня интеллектуального и эмоционального напряжения. Пускай даже не отдых буквально подразумевает, но понимание (необязательно осознанное) того, что следующую задачу будешь делать дольше, чем без такой задачи прямо перед ней.
Ну и при качественных оценках время выполнения всегда статистически завышается,
Что это за качественная оценка, которая завышается? Не учитываются положительные риски?
Ну вот у вас каждый оценил и вы видите оценку каждого человека, с-но знаете кто готов угадать эту мелодию за 4 ноты, а кто — за три :) С-но команда сразу в процессе эти оценки же тоже видит и сама прекрасно может определиться с тем, кто, что, когда и как :)
Ну то есть план на пару недель составляется под конкретных исполнителей? Не считаю это хорошей практикой в общем случае.
У вас оценки будут одинаковые, т.к. оценки СП не зависят от производительности исполнителя.
Бинго! Бывают разные, конечно, как излишне оптимистичные, так и излишне пессимистичные, но сведутся к одной, скорее к более авторитетной.
С-но, информации никакой нет
Информация есть. Даже если фактическое время работы над задачей не логируется вообще, реально только бумажки на доске передвигаются без всяких джир, то за две недели, да ещё с ежедневной "рефлексией" можно легко посмотреть кто сколько СП сделал лично из общего вклада и понять почему так много/мало от ожидаемого уровня. То ли пробелы в знаниях (которые в процессе могли закрыться, а могли нет), то ли архитектура неподходящая была (которая в процессе могла быть изменена, а могли быть костыли забиты), то ли сработали какие-то риски, которые в скоуп задачи заложить нельзя было (оценка типа "подключу такую-то либу и если критичных багов в ней не окажется, то за час закрою задачу, а если окажется, то 2 недели и то не факт, что хватит" как по мне бесполезна для планирования календарных графиков, только для риск-менеджмента.
По ретроспективе неудачных или слишком удачных спринтов можно понять, да, "Вася лучше Пети на задачах Х" (а можно понять "все вместе слишком оптимистично/пессимистично оценили задачу"). Причём хоть в часах их оценивать, хоть в СП, это обычно очевидно и бумажки не требует, для оценок "лучше/хуже" по крайней мере. А вот что с этим делать проще решить с СП. Может Вася вообще лучше Пети в целом и ему надо работать над общим увеличением перфоманса, а пока просто учитывать этот факт при планировании, а может надо закрывать пробелы, а может просто не брать таких задач в будущем если резерва по времени нет.
СП относятся к задачам, после которіх необходим "сверхурочный" отдых. Но при оценке в часах так делать нельзя по многим причинам.
Почему нельзя? Можно. Точно так же интуитивно добавляете в задачу и все. Хоть какие-то причины из этих "многих" сможете назвать?
но понимание (необязательно осознанное) того, что следующую задачу будешь делать дольше, чем без такой задачи прямо перед ней.
Так тогда СП надо добавлять в следующую задачу, не в эту. Причем только в том случае, если эта следующая будет у того же исполнителя. В итоге у вас оценка в СП будет меняться от того, какому исполнителю поставили задачу.
Что это за качественная оценка, которая завышается? Не учитываются положительные риски?
Оценка, соответствующая требованием. Любая оценка — статистическая, по-этому сумма вероятностей оценить задачу выше и оценить задачу ниже — всегда 100%. С-но, в предположении о симметричности распределения (ну оно по факту не симметрично, но максимально к нему близко), если вы даете оценку точно по мат. ожиданию, то вы будете просирать сроки в половине случаев. Это же плохо? Плохо, с-но, вы берете квантиль, чтобы укладываться в сроки, например, в 90% случаев. Но это значит, что в 90% случаев ваша оценка будет завышена.
Если к этому добавить, что вы даете оценку не точную (так, что минимальный интервал сильно меньше по сравнению с дисперсией), то ситуация еще больше сдвигается в сторону переоценки — т.к. если при нужном квантиле вы в интервал не попадаете, то вы почти всегда подвинетесь на следующий вперед.
Информация есть. Даже если фактическое время работы над задачей не логируется вообще,
А что толку его логировать, если не с чем сравнивать?
можно легко посмотреть кто сколько СП сделал лично из общего вклада и понять почему так много/мало от ожидаемого уровня.
И что это даст? Непонятно. СП же не отражают никаких "физических" показателей. С-но, из них нельзя сделать никаких выводов.
Почему нельзя? Можно. Точно так же интуитивно добавляете в задачу и все.
То есть задачу сделал, пора передавать дальше, но ты её не закрываешь, а сидишь отдыхаешь? Неправильно как-то.
В итоге у вас оценка в СП будет меняться от того, какому исполнителю поставили задачу.
Оценка как раз не должна, время будет зависеть, но не оценка. Оценка может оказаться неверной, а может оказаться что конкретный исполнитель медленно "делает СП" на таких задачах.
С-но, в предположении о симметричности распределения (ну оно по факту не симметрично, но максимально к нему близко), если вы даете оценку точно по мат. ожиданию, то вы будете просирать сроки в половине случаев. Это же плохо?
Нет, не плохо объективно. В спринте отклонения в разные стороны с большой вероятностью компенсируют друг друга. А ошибка в одной задаче объективно ничего не решает, без микроменеджмента и успешно закрытом спринте никто и не узнает может быть. Но плохо субъективно, ошибся ведь. Но завышение оценки плохо и объективно, и субъективно. Бизнесу обещают меньше чем могут и даже если делают по факту больше, то как замечено, бизнесу хорошо от этого не становится. А вот ощущение обмана бизнеса вполне может появиться.
А что толку его логировать, если не с чем сравнивать?
Есть с чем. С другими задачами этого исполнителя в этом спринте. С задачами других исполнителей в этом спринте. С прошлыми спринтами по разным разрезам и т. п.
И что это даст? Непонятно. СП же не отражают никаких "физических" показателей. С-но, из них нельзя сделать никаких выводов.
СП отражают вполне конкретный "физический" показатель: какие конкретно задачи мы собирались закрыть в спринте. Если уложились точно, то на ретроспективе основная тема "как можно закрывать больше". Если не успели, то основная тема "случайность или где провтыкали", если успели раньше — "случайность, ошибка оценок принципиальная или выросла скорость и можно брать больше"
То есть задачу сделал, пора передавать дальше, но ты её не закрываешь, а сидишь отдыхаешь? Неправильно как-то.
Ну и с СП то же самое.
Оценка как раз не должна
Не должна, но в вашей схеме зависит. Т.к. у вас сложность задачи определяется не сама по себе, а исходя из того, какие задачи делал до этого исполнитель. Если до этого он делал сложные задачи и устал — то сложность текущей возрастает.
Нет, не плохо объективно.
Нет, это объективно плохо. Просирать половину сроков — это провал. Даже треть. Даже четверть. С-но для многих людей и 10% — это чересчур.
В спринте отклонения в разные стороны с большой вероятностью компенсируют друг друга.
Я вам уже выше сказал — это просто когнитивное искажения, согласно которому, если подбрасывать монетку, то вы будете оставаться около нуля (в плане разницы между количеством орлов и решек). По факту же ошибка в подобных случайных процессах нарастает, т.е. подбрасывая монетку вы будете уходить от нуля все дальше и дальше.
А ошибка в одной задаче объективно ничего не решает, без микроменеджмента и успешно закрытом спринте никто и не узнает может быть.
Так это плохо, что никто не узнает. Если ошибка есть — она должна быть обнаружена. Даже если она и не привела ни к каким последствиям. Потому что это она сейчас не привела.
СП отражают вполне конкретный "физический" показатель: какие конкретно задачи мы собирались закрыть в спринте.
Этот показатель отражает список ваших задач на спринт. При чем тут СП?
Ну и с СП то же самое.
То же, да не совсем. Тратится общее время спринта, а не конкретной задачи и даже не конкретного человека. При оценке в часах конкретного исполнителя надо или закладывать ему после таких задач время отдыха сверх условных 20 часов в спринт, то есть ставить ему не 60 часов, а, например, 58. Или делать фейковые задачи для отдыха, или ещё как-то обходить. В СП такой необходимости просто нет, а даже если есть, то она решается добавлением СП в задачу, но нет никакой проблемы сделать задачу, изменить статус, и отдыхать. С часами нужны какие-то трюки специальные.
Нет, это объективно плохо. Просирать половину сроков — это провал. Даже треть. Даже четверть. С-но для многих людей и 10% — это чересчур.
Чем єто обїективно плохо, если скоуп задач за спринт крайне редко не выполняется? Запланировали на день две задачи по 3 часа, одну сделали за 2, другую за 4 — чем объективно плохо это?
При чем тут СП?
На основании двух чисел в СП (оценок и результатов прошлых спринтов) мы решили, что включать в спринт, а что нет. По сути СП за спринт — это количество задач за спринт с учётом сложности каждой задачи.
Есть нюанс: однотипные задачи, в том числе в разных спринтах, должны оцениваться в одинаковое количество SP, если не было изменений инфраструктуры, архитектуры и т. п., изменяющее их сложность. И за этим хорошо бы следить специально. В том числе для оценки эффекта таких изменений.
Обсудить этот вопрос со всей командой. Например, станет ли лучше (проще, точнее) если будем оценивать эти задачи в 5 SP или 8
Речь про устояшившийся режим.
Почему? Потому что вы привыкли вкладывать при оценке в часах? :) Какое у вас ощущение, когда команда еженедельно успешно выполняет разных неизвестных задач на 30 часов по первоначальной оценке на человека. Причём каждую закрывает в срок, а не так, что одну сделал на 2 часа быстрее чем оценил, а другую на 2 часа больше.
Одно из правил эффективного внедрения оценок в SP — не делать такую "автоматическую" оценку. SP теряют свой смысл с ней, проще сразу в "нормочасах" оценивать, или реальных часах конкретного исполнителя.
SP не про длительность решения задачи, корреляция есть, но не прямая зависимость, чтобы с коэфициентом переводить. Тут математика второго класса неприменима, тут интегральное исчисление и вероятностные функции. Никакой информации о том, сколько времени займёт каждая отдельная задача в утверждении "за 2 недели спринта мы сделаем 30 задач на 100 SP" нет. Точнее есть, но только оценка сверху: каждая задача из этих 30 займёт не больше 2 недели работы всей команды.
Абсолютно все известные мне программисты, понимающие, что такое SP, и зачем они нужны, умеют ими грамотно пользоваться, не занимаясь абсурдным переводом в часы.
Скажите, а зачем-таки нужна оценка в SP, если планирование ведется все равно в часах?
Ну то есть, если SP нельзя перевести в часы — оценка автоматом становится бесполезной, т.к. ее нельзя использовать для планирования.
Если же ее можно перевести в часы — то можно использовать часы. Что на счет этого?
Сторипойнты в скраме нужны для того, чтобы понимать скорость работы команды, и, уж простите, но очевидно, что Вы этого НЕ понимаете.
Так ведь скорость — это, по определению, количество В ЧАС. То есть, чтобы оценить скорость работы команды — надо оценить задачу в часах.
Скорость команды — количество типовых задач за период. Оценка задачи в часах тут лишняя.
Скорость команды — количество типовых задач за период. Оценка задачи в часах тут лишняя.
Ну так типовая задача — это в итоге все равно Х часов. Зачем промежуточный показатель, если можно сразу измерить в часах? 2 недели спринт = 10 дней, каждый день пусть по 6 часов, с-но 60 часов на человека. В итоге производительность команды можно сразу узнать, просто умножив количество человек в команде на 60.
Нет, X часов не константа даже в пределах одного спринта: разработчики разные.
Нет, X часов не константа даже в пределах одного спринта: разработчики разные.
Так в этом случае SP использовать нельзя. Они должны переводиться в часы, это необходимое условие, т.к. часы это единственная измеримая метрика. В противном случае знание SP не дает вам никакой информации, с-но вы при оценке просто зря потратили время. Можно просто рандомом SP устанавливать и все тогда.
У нас есть статистика сколько SP поставила команда за прошлые спринты и результаты ретроспектив непопадания. Естественно, предполагается, что оценки были нерандомные. А часы как раз могут плавать в зависимости от того, кто делал. У нас всё же не строительство, где нормируется на задачи человеко-часы разных специалистов разных разрядов. Можно, наверное оценивать задачи типа "тут требуются 2 часа сеньор фронта, 3 часа миддла бэка, 5 часов джуна фронта" а потом как-то композировать задачи, чтобы на каждого выходило условных 60 часов за 2 недели. Но субъективно непопадания в планы будут гораздо чаще, хотя бы потому что сеньор сеньору рознь.
Можете называть итоговую цифру сторипойнтами, если угодно, но ее природа от этого не изменится.
Здесь уже несколько раз отвечалось на этот вопрос — оценка производится сравнением с уже выполненными и оцененными задачами.
Скажите, вот оценили вы задачу, например, в 16 часов — как часто случается, что она действительно делается ровно за 16 часов?
Нет, вы не поняли. Под "делается" я имею ввиду весь процесс — от начала работы до перевода в статус "готово". И речь не про "укладывается". Можно назвать срок в три дня, сделать за час — и формально это будет "уложился".
Он у вас один?
А программист сидит дома и кодит по ночам
Извините, я не очень в сарказм сейчас, это шутка или действительно так?
Тогда это ужасно. Нет, это его выбор, разумеется, но на мой взгляд это ужасно.
Возвращаясь к делу — скрам в целом и стори-пойнты в частности не особо применимы к, скажем так, одиночным забегам. В Вашем случае это действительно было бы бессмысленным оверхедом.
Итак, то есть вы утверждаете
Нигде, ни разу, ни одним своим словом я даже не пытался намекнуть на такой вывод. Я написал ровно то, что написал — скрам для команд, а не для одиночек.
Скрам слабо применим в ситуации, когда практически невозможно зафиксировать планируемый объём работ на 1-4 недели, когда с вероятностью близкой к 100% кто-прибежит и скажет бросать все задачи и делать новую, очень важную, с одной стороны, а с другой, сложно вообще сказать будет ли что делать через это время.
Ну скрам заточен под ситуации когда подавляющее большинство поступающих задач может ждать минимум эти две недели или сколько там спринт устнаовлен. Максимум во время текущего спринта можно сделать оценку поступивших, чтобы бизнес на следующий спринт планировал что включать или не включать в бэклог спринта.
Скажите, вот оценили вы задачу, например, в 16 часов — как часто случается, что она действительно делается ровно за 16 часов?
Если вы оценили задачу в 5сп, то как часто оказывается, что она действительно 5сп?
И накапливается ошибка из-за изменений условий. Год назад вы сделали эталонную задачу за час, а теперь она потребует полчаса, из-за роста квалификации, новой инфраструктуры и т. п. Или, наоборот, теперь потребует 2 часа, потому что надо писать тесты, проводить кодревью, уговаривать админов дать сервер вне очереди и т. д.
Очень просто считать для начала: вашу оценку времени делите на вашу оценку эталонной задачи в 1 сторипоинт. Важно: оценки должны происходить одновременно, а не так, что год назад засекли за сколько сделали эталонную задачу, а теперт делим на это число.
Очень просто считать для начала: вашу оценку времени делите на вашу оценку эталонной задачи в 1 сторипоинт.
А в чем проблема не делить а так и оставить в часах? Зачем огород городить? :hz:
Я старался, чтобы звучало так, что SP это некая комплексная оценка
Вы не поверите, но оценка в часах — это тоже комплексная оценка, в которую, по определению, входят все факторы, которые могут повлиять на время выполнения задачи.
И что дальше с этим делаем? Увольняем? Игнорируем его мнение при следующих оценках?
А это уже менеджмент решает, что делать. Важно, что информация есть. И когда информация етсь — это всегда лучше, чем ее нет. Или смысл СП как раз в том и состоит, чтобы скрывать от менеджмента важную информацию?
А если только Вася будет делать? Или только Петя? Или Петя час поделает, а потом критикал баг прилетит и он отдаст доделвать Васе?
Не понял, в чем вопрос. Уточните. И сразу скажите, как СП проблему решает.
СП как раз решает, а оценивание в часах — нет.
Как решает, если не решает? Я вам уже укзаал конкретный кейс, в котором с СП те же проблемы. Более того — на самом деле с СП еще все и хуже, ведь легко оказывается, что, решая задачу Х, Вася за спринт делает 10сп, а решая задачу Y — он делает 20сп.
При этом если в часах вы это легко оттрекаете — т.к. увидите, что Вася оценивал Y в часах занижено по сравнению с остальными, то в случае СП вы никак эту информацию извлечь не сможете. Вы просто увидите что у вас производительность Васи по каким-то причинам прыгает туда-сюда. Почему? Да хз, оценок Васи в часах ведь нет, а оценка в СП одинаковая.
С оценкой в СП понятно что делать на проваленном спринте
С оценкой СП как раз непонятно что делать, потому что оценка СП не содержит никакой информации о характере проблемы. Возможно проблемы и нет, а возможно — она есть, и если есть — анализ оценок СП никак не поможет определить, в чем проблема.
В случае часов у вас полно полезной информации, которая позволяет определить, в чем дело. Например — зачем-то дали Васе задачу X вместо задачи Y, зачем? Ну и т.д.
Это информация, которую можно использовать при планировании.
Субъективно, очень скоро понадобится человек, который будет назначать какие задачи кому делать и будет вводить поправочные коэффициенты. Самоорганизованной команды не будет больше.
Какие поправочные коэффициенты? Они как раз для СП нужны, т.к. у вас у каждого своя производительность в СП. Причем она еще и от задач зависит, с-но нужен отдельный человек, который будет все это менеджить — следить за тем, у кого на каком классе задач какой коэффициент производительности и, исходя из этого, по диаграмме Ганта планировать спринт.
В случае часов все и так очевидно, и команда сама без каких-либо проблем (и непонятных зачем-то выдуманных вами поправочных коэффициентов, зачем они нужны, если у вас есть часы — в которые все коэффициенты уже входят сами собой?) быстро и эффективно может распределить на спринт задачи из беклога. При этом все совершенно наглядно и не надо собирать гигантские объемы стат. данных для того, чтобы планирование было точнее, чем рандомом.
А в чем проблема не делить а так и оставить в часах? Зачем огород городить?
Это просто "лайфхак" для тех, кто не может не измерять задачи в часах.
в которую, по определению, входят все факторы, которые могут повлиять на время выполнения задачи.
Не согласен с таким определением. Вернее по моему глубокому убеждению оценка разработчика не может быть такой.
Или смысл СП как раз в том и состоит, чтобы скрывать от менеджмента важную информацию?
Можно и так сказать в какой-то мере. Но с поправкой: в скраме, где обычно и применяются сторипоинты, это особо не относится к важной для менеджмента информации. Важно для менеджмента сколько от запланированного объёма команда делает за спринт.
С оценкой СП как раз непонятно что делать, потому что оценка СП не содержит никакой информации о характере проблемы. Возможно проблемы и нет, а возможно — она есть, и если есть — анализ оценок СП никак не поможет определить, в чем проблема.
В случае часов у вас полно полезной информации, которая позволяет определить, в чем дело. Например — зачем-то дали Васе задачу X вместо задачи Y, зачем? Ну и т.д.
Это информация, которую можно использовать при планировании.
Оценка в часах так же не содержит никакой информации о характере проблемы. Точнее не так же, а ещё меньше содержит информации. Как раз отдельный человек нужен, чтобы следить за оценкой в часах.
А вообще у меня стойкое ощущение, что мы о разных вещах говорим и про оценку в сп, и про в часах. Для меня в сп — это комплексная, а в часах базовая, не учитывающая ничего кроме собственно оценки на задчу, никаких рисков, никаикх ошибок
Отличаются. При оценке в часах я не представляю как измерять производительность. На прошлом спринте мы молодцы работали со скоростью 1,5 часа в час, а в этом что-то пока и на 40 минут в час не вышли.
Отличаются. При оценке в часах я не представляю как измерять производительность.
Производительность меряется по фидбеку стейкхолдеров. Если вы доставили фичи в сроки, которые устраивают бизнес — вы молодцы. При этом если вы доставили фичи вдвое быстрые — вы ничуть не более молодцы, потому что быстрее никому не надо, надо в сроки :)
Но вы можекте стать более молодцами потратив потом время на покрытие тех. долга, например.
Если же не доставили — значит, вы не молодцы. А сколько каких фич вы по факту делаете в СП — это никому не интересно и неважно вообще.
Ну и тем более тот факт что вы сделали в новом спринте вдвое больше СП чем в прошлом — никак не говорит о том, что производительность возросла. Это может быть стат. флуктуация в оценке. Или завышение (как намеренное — так и неосознанное) :)
Партия требует делать больше СП? Окей, будем делать больше СП ;)
С точки зрения стейкхолдеров, оценивание задач хоть в часах, хоть в СП, хоть в строках кода смысла обычно не имеет, если команда обещает дать определённый набор фич за спринт. Это чисто внутреннее дело команды как сформировать этот набор, в смысле где в приоритизированном бэклоге остановиться и сказать "больше мы не сделаем за спринт". Но вот с точки зрения команды мотивированных профессионалов хорошо бы, по-моему, видеть числовые метрики роста производительности как метрику роста профессионализма, а не просто "успели или нет". Оценка в часах тут никак не помогает, как мне кажется. "Мы за 500 часов сделали задач на 500 часов, бизнес сказал "молодцы"" — и что? По крайней мере без глубокой ретроспективы с поиском аналогичных задач из прошлого и сравнении как их оценок, так и факта. Оценки в СП же позволяют отслеживать этот рост. Пускай даже по факту его нет :)
С точки зрения стейкхолдеров, оценивание задач хоть в часах, хоть в СП, хоть в строках кода смысла обычно не имеет, если команда обещает дать определённый набор фич за спринт.
Все верно. Но штук в том, что при измерении в часах вы можете спланировать задачи на спринт и отчитаться по выполнению, а в случае СП — не можете. Потому что СП ничего не значат.
Но вот с точки зрения команды мотивированных профессионалов хорошо бы, по-моему, видеть числовые метрики роста производительности как метрику роста профессионализма, а не просто "успели или нет".
Во-первых — непонятно, зачем? У меня вот есть мой комфортный темп работы. Я могу работать быстрее, могу работать медленнее. Ну поработал я быстрее, и что из этого? Я и так знаю, что работал быстрее, мне не надо для этого ничего измерять, т.к. я изначально решил, что буду работать на этом спринте быстрее, чем мне комфортно (ну надо, допустим, в силу каких-то причин). Зачем тут СП какие-то?
Ну а во-вторых — СП жэе не являются такой метрикой. СП — это вообще не метрика, т.к. метрика, по определению, измерима, а СП — нет.
По сути, вы можете просто в конце спринта договариваться, как оцениваете сделанные задачи, ну и каждый раз увеличивать это число, постфактум. Типа, окей ребята, пусть сделанные в этом спринте задачи — это 150сп! и это на 10 сп больше чем в прошлом! А в следующем — у нас будет 160сп!
И ведь действительно будет — потому что сколько хотите, столько и объявляете. Но зачем это?
Все верно. Но штук в том, что при измерении в часах вы можете спланировать задачи на спринт и отчитаться по выполнению, а в случае СП — не можете. Потому что СП ничего не значат.
Для вас ничего, для других — замаскированные абстрактные человеко-часы или даже человеко-часы конкретного исполнителя, для третьих ещё более комплексная оценка.
Во-первых — непонятно, зачем? У меня вот есть мой комфортный темп работы.
Тут скорее о фиксации изменения этого комфортного темпа.
Ну а во-вторых — СП жэе не являются такой метрикой. СП — это вообще не метрика, т.к. метрика, по определению, измерима, а СП — нет.
Инструментально СП неизмеримы, а так измеримы пускай и оперируют комплексной сложностью.
По сути, вы можете просто в конце спринта договариваться, как оцениваете сделанные задачи, ну и каждый раз увеличивать это число, постфактум.
Все же поймут, что это филькина грамота. Интересно фиксировать рост производительности. А при оценке в часах максимум можно ориентироваться на факто по сравнению с чужими оценками,
Для вас ничего, для других — замаскированные абстрактные человеко-часы или даже человеко-часы конкретного исполнителя, для третьих ещё более комплексная оценка.
В часах как раз ничего абстрактного нет, потому что часы обладают свойством вполне объективной измеримости. Это факт и от него не деться, извините :)
Тут скорее о фиксации изменения этого комфортного темпа.
А зачем эта фиксация нужна?
Инструментально СП неизмеримы, а так измеримы пускай и оперируют комплексной сложностью.
Опишите процесс измерения. Ну вот питона в попугях я как меряю — представляю питона, попугая, и пытаюсь визуально в воображении разложить копии попугаев по питону.
Опишите, пожалуйста, этот процесс, когда вы говорите, что: "это задача на 5 сп!"
Все же поймут, что это филькина грамота.
Точно такая же филькина грамота как и СП в принципе. В обоих случаях вы взяли и договорились, что "у этих задач будет Х СП!".
В чем разница-то?
Интересно фиксировать рост производительности
Так рост СП не говорит о росте производительности. Да и если бы говорил — зачем об этом росте знать вообще? Типа повышение ЗП требовать?
В часах как раз ничего абстрактного нет, потому что часы обладают свойством вполне объективной измеримости. Это факт и от него не деться, извините :)
Вы можете измерить только те часы, которые уже были потрачены. Часы, которые вы указываете при оценке, никак не могут быть измерены в момент планирования.
Вы можете измерить только те часы, которые уже были потрачены.
Именно. А потраченные СП я измерить не могу.
Часы, которые вы указываете при оценке, никак не могут быть измерены в момент планирования.
А их измерять и не надо, на то она и оценка. Измерять надо, насколько оценка оказалась точной
потраченные СП я измерить не могу.
Потраченные СП измерять невозможно, да и не нужно. Это единица измерения сложности, а не времени.
В ходе выполнения работы все так же тратите часы.
Потом корректируете оценку. На входе в алгоритм корректирования дается:
- количество часов конкретного сотрудника на 1 СП сейчас
- количество часов этого же сотрудника на 1 СП раньше
- количество часов других сотрудников на 1 СП
Если количество часов сейчас заметно превышает обычное количество, то делаем один из выводов
- задачу недооценили
- сотрудник работал медленно
Если недооценили задачу, то разбираемся какую сложность не учли. Если работал медленно, то корректируем объем сложности, который команда успевает за спринт.
А зачем во всех этой схеме нужны СП, если и так часы учитываются?
Для оценки относительной сложности задачи
Учитываются не часы на задачу, прежде всего, а все часы на спринт. Вернее обычно часы учитываются позадачно, но в чистом виде не анализируются сразу. В часах тоже можно так делать: мы наоценивали задач на 600 часов на спринт и сделали их за 600 часов — мы молодцы. Но на практике ни разу такого не встречал, анализ сразу на уровне задачи идёт, прямо в момент закрытия, а то и раньше начинаются "ты уже просрочил задачу".
Но на практике ни разу такого не встречал, анализ сразу на уровне задачи идёт, прямо в момент закрытия, а то и раньше начинаются "ты уже просрочил задачу".
Так это же хорошо — позволяет быстро выявлять проблемы и принимать оперативные решения. Это основа эджайла, собственно, если не оценить постоянно ход работы, то это уже и не эджайл.
В часах как раз ничего абстрактного нет, потому что часы обладают свойством вполне объективной измеримости. Это факт и от него не деться, извините :)
В часах нет, в человеко-часах есть. Фраза "за спринт мы сделаем задач на 100 СП" говорит гораздо больше (при нормальных процессах) чем фраза "за спринт мы сделаем задач на 600 человеко-часов". По сути последняя означает "наш план: сколько сделаем столько сделаем"
Так рост СП не говорит о росте производительности.
Должен говорить при устоявшихся процессах.
Да и если бы говорил — зачем об этом росте знать вообще?
Лично мне это важно для себя, понимать что моя производительность растёт. С точки зрения бизнеса важно чтобы команда понимала рост своей производительности, чтобы она больше брала задач на спринт.
В часах нет, в человеко-часах есть. Фраза "за спринт мы сделаем задач на 100 СП" говорит гораздо больше (при нормальных процессах) чем фраза "за спринт мы сделаем задач на 600 человеко-часов".
Ну вообще-то нет. Первая фраза вообще не значит ничего, а вторая фраза хотя бы говорит сколько у вас в команде люди работают :)
Ну и если вы хотите как-то охарактеризовать входящие в спринт задачи — вы просто даете список задач, в чем проблема?
По сути последняя означает "наш план: сколько сделаем столько сделаем"
Так а в СП не так? Точно так.
Лично мне это важно для себя, понимать что моя производительность растёт.
Ну это ваше личное странное желание.
Не согласен с таким определением.
А какое у вас определение, извините? Как вообще можно дать оценку Х, если не оценив влияние определяющих Х факторов?
Вернее по моему глубокому убеждению оценка разработчика не может быть такой.
Никакой другой она быть не может. Естественно, вы можете что-то не учесть и дать неточную оценку (ну, все оценки сколько-то будут неточны), но это верно и для СП, если вы что-то не учитываете, то не учитываете.
Суть, однако, одна — чтобы понять, сколько на что-то уйдет часов (дать оценку) вам надо понять, что влияет на сроки и оценить это влияние. И результирующая оценка получится как равнодействующая оценок факторов. Вы вообще знаете какой-то другой способ оценивать? Я — нет.
Важно для менеджмента сколько от запланированного объёма команда делает за спринт.
Зачем менеджменту это знать? Оценка скорости в спринте сама по себе же бесполезная информация, из нее ничего нельзя извлечь.
а в часах базовая, не учитывающая ничего кроме собственно оценки на задчу
Я, если честно, не понимаю, что вы подразумеваете под "собственно оценки на задачу". В "собственно оценку на задачу" риски и входят, заведомо, как они могут не входить? Если вас спрашивают ожидаемую скорость выполнения, а риски на нее влияют, значит, ваш ответ учитывая риски и не учитывая риски будет разным. И при учете рисков он будет ближе к реальности (статистически и если вы в принципе способны адекватно оценить риски). И ваша задача дать ответ наиболее близкий к реальности. Значит, вы учитываете риски. Как это "базово" — я вообще не понимаю, честно. Что это за "базовая оценка", откуда это число вообще берется, как? Как вы можете дать оценку чего-то, если не оценив влияющие факторы? Если все факторы убрать, то у вас не оценка будет, а просто чистый рандом, случайное число.
Я к тому, что при оценке в часах не дело простого разработчика без менеджерских функций учитывать риски, что что-то пойдёт не так, что замедлит или ускорит задачу. При оценке в СП тоже в принципе, но правильное их применение компенсирует риски как бы автоматически. С одной стороны, положительные и отрицательные риски компенсируют друг друга в течение спринта. С другой, решение по тому сколько задач брать в спринт принимаются на основании результатоа предыдущих спринтов, что устраняеет систематические ошибки в оценке.
Я к тому, что при оценке в часах не дело простого разработчика без менеджерских функций учитывать риски
Он риски оценит автоматически. Как вообще можно оценить время, не оценивая риски? Я не понимаю. Вы же при оценке привязываетесь к своему опыту. А ваш опыт включает риски.
Я вот могу дать оценку времени, которая включает все влияющие на это время факторы, т.к. это просто моя интуитивная оценка с привязкой к опыту по решению задач подобного вида и знанию того, как они решаются. Та оценка, которая у меня в голове сроазу всплывает — это она и есть.
Но я не понимаю, как дать оценку, исключая какой-то из факторов, ведь мой опыт ничего не говорит о влиянии конкретных факторов, он говорит именно о том, как они влияют совокупно.
Ну точнее, можно набрать статистику, проанализировать — но это сложная, очень сложная задача. На подобную оценку (которая что-то не учитывает) уйдет не одна неделя. И уж точно такую оценку нельзя сделать в голове. Т.е., еще раз — оценка с влиянием всех факторов делается просто, на автомате. Оценка, которая что-то не включает — дать сложно, практически невозможно в требуемых условиях.
С одной стороны, положительные и отрицательные риски компенсируют друг друга в течение спринта.
Но это вообще не про СП, а про процесс разработки. А он одинаковый :)
С другой, решение по тому сколько задач брать в спринт принимаются на основании результатоа предыдущих спринтов, что устраняеет систематические ошибки в оценке.
Наоборот — ошибки так только накапливаются из-за привязки новых оценок к оценкам ошибочным (но об ошибочности которых вы не знаете).
В случае же часов на ретроспективе вы постоянно на основании нового опыта подкручиваете механизм оценок и они становятся все более точными. При этом накопления нету by design.
Как вообще можно оценить время, не оценивая риски? Я не понимаю
Идеальное развитие ситуации, оценка снизу. В голове так или иначе составляешь план без любых "если что-то пойдёт не так" и просчитываешь его.
Но это вообще не про СП, а про процесс разработки. А он одинаковый :)
Неа :) С точки зрения психологии команды влияние разное. При оценке в часах и логировании (пускай и в уме) позадачно слишком часто будут всплывать ошибки и неважно недооценки или переоценки, для мозга это ошибки, причём не понятно неправильно оценили задачу или при вполне нормальной оценке то ли затупил, то ли риски сработали. А по сути и не важно, главное, что оценка и факт не совпали. С другой стороны, большой соблазн завышать оценки, пускай и объясняя это, пускай и только себе для очистки совести, учётом рисков, хотя в рамках одной задачи это чаще всего не работает правильно, риски надо учитывать на большем скоупе.
Наоборот — ошибки так только накапливаются из-за привязки новых оценок к оценкам ошибочным (но об ошибочности которых вы не знаете).
Как это привязывая к ошибочным? Привязываются к эталону, можно неправильно оценить отношение задачи и эталона. Но оценки эталона — это единица измерения :) Неправильный метр и килограмм в Палате мер и весов — этот нонсенс, пока они были эталонами.
В случае же часов на ретроспективе вы постоянно на основании нового опыта подкручиваете механизм оценок и они становятся все более точными.
При оценке в СП это не необходимо для удовлетворения стейкхолдеров и руководства — подкручивать можно как оценки задач, так и планируемое количество СП на спринт. Обычно и то, и другое подкручивается, соответственно сходится быстрее.
Идеальное развитие ситуации, оценка снизу.
Не понимаю. Как я могу оценить идеальное развитие событий, если его никогда не наблюдал? В реальности же у меня не выборка из идеального.
В голове так или иначе составляешь план без любых "если что-то пойдёт не так" и просчитываешь его.
Ну вот этот просчет и будет уже содержать риски.
А по сути и не важно, главное, что оценка и факт не совпали.
Они вообще не могут не совпасть, вероятность их совпадения — 0. То есть, событие практически невозможное. Ошибка — это не когда вы "не угадали время" (такой задачи не стоит, да и она невыполнима, вы в любом случае либо завышаете либо занижаете). Ошибка — это когда вы не выполнили задачу в срок.
Как это привязывая к ошибочным?
Ну вот вы оценили задачу в Хсп, и это неправильная оценка. Но потом в привязке вы ее будете учитывать.
Привязываются к эталону, можно неправильно оценить отношение задачи и эталона.
Слушайте, ну прекратите уже эти бредни про "эталон", давайте мби серьезно разговаривать?
Нету никакого одного эталона и быть не может. Эталон — это все задачи которые вы вообще выполняли. При оценке сложности учитываются все они.
Если бы в реальности можно было убрать у программиста этот опыт и заставить реально оценивать по 1 эталону — вы бы получали оценку уровня "просто рандом", не более.
Ну серьезно, как вы собрались оценивать сложность задачи связанной с архитектурным рефакторингом по эталону в виде фикса верстки?
При оценке в СП это не необходимо для удовлетворения стейкхолдеров и руководства
Для удовлетворения стейкхолдеров и руководства надо просто фичи вовремя выкатывать.
Я старался, чтобы звучало так, что SP это некая комплексная оценка, в которую входит классическая оценка времени завершения задачи.
SP это некая комплексная оценка
Именно! Сторипойнт — это произведение:
а) непосредственные временные затраты;
б) индивидуальный коэффициент исполнителя (общий опыт, опыт решения идентичных задач, коммуникативные навыки etc);
в) коэффициент факторов среды (задержки на получение API-ключей, железа etc);
г) коэффициент непредсказуемости (болезни, климат etc).
Список неполный, каждая команда дополняет его самостоятельно.
Наиболее важно тут, что командная оценка задачи не может быть усреднена (а потому бесполезна). В большинстве случаев если двое оценивают в 5, а непосредственный исполнитель — 8, то закладывать придется 8.
б) индивидуальный коэффициент исполнителя (общий опыт, опыт решения идентичных задач, коммуникативные навыки etc);
Ахахах, вобще-то, сп — это оценка объема работы. Она не зависит от исполнителя, она для всех одинакова, просто у вас один исполнитель сделает эти сп быстро, а другой — медленнее. А вот в часовой оценке как раз описанные факторы оказываются учтены, т.к. человек, давая оценку, конечно же, учитывает свои компетенции.
Все остальные описанные факторы, конечно, в оценке часов тоже учитываются — как и абсолютно любые другие факторы, оказывающие влияние на время выполнения задачи.
У нас есть статистика сколько SP поставила команда за прошлые спринты и результаты ретроспектив непопадания.
И что дальше вы с ней сделаете? Еще раз — с часами вы просто смотрите на результат и видите на сколько кто ошибся. В случае с СП как получить ту же самую информацию? У вас вместо одной измеримой величины несколько связанных между собой достаточно сложным образом случайных. Чтобы получить какой-то сколько-нибудь значимый статистический результат в таких условиях, вам надо набирать статистику по команде сотни лет. Да и то не факт, что что-то выгорит.
А часы как раз могут плавать в зависимости от того, кто делал.
Так у нас всегда есть оценка того, кто делал. С-но мы всегда можем оценить оценку конкретного человека с его затратами на конкретную задачу.
Можно, наверное оценивать задачи типа "тут требуются 2 часа сеньор фронта, 3 часа миддла бэка, 5 часов джуна фронта"
А может лучше оценивать "нам надо 5 часов работы Васи и 2 часа работы Пети"?
Вы уже который раз повторяете этот тезис что сп удобнее т.к. сеньор работает быстрее джуна. Но я вам еще раз отвечаю — это не устраняет проблемы, т.к. основной разброс в скорости разработки между членами команды идет не из-за того, что Вася — сеньор, а Петя — джун, а из-за того, что Вася в силу специфичного опыта знает, как работать с задачей Х, а Петя — не знает. При этом они оба могут быть вполне себе мидлами и уже на другой задаче соотношение в скорости будет обратным. И СП эту проблему никак не решает, а вот оценивание в часах — решает прекрасно, т.к. вы видите кто на сколько задачу оценил и за сколько ее в итоге сделал исполнитель. Никакой этой информации в случае СП просто нет.
Еще раз — с часами вы просто смотрите на результат и видите на сколько кто ошибся.
И что дальше с этим делаем? Увольняем? Игнорируем его мнение при следующих оценках?
С-но мы всегда можем оценить оценку конкретного человека с его затратами на конкретную задачу.
Так и что делаем?
А может лучше оценивать "нам надо 5 часов работы Васи и 2 часа работы Пети"?
А если только Вася будет делать? Или только Петя? Или Петя час поделает, а потом критикал баг прилетит и он отдаст доделвать Васе?
И СП эту проблему никак не решает, а вот оценивание в часах — решает прекрасно
СП как раз решает, а оценивание в часах — нет.
вы видите кто на сколько задачу оценил и за сколько ее в итоге сделал исполнитель.
Ну видим, и что? Вводим для него поправочный коэффициент? Просим его вводить такой коэффциент самостоятельно? С оценкой в СП понятно что делать на проваленном спринте: на ретроспективе смотрим мы оптимистично оценили скорость команды в целом или сработал какой-то риск — это простая информация, которую легко учесть в будущих планированиях или просто надо забыть. При оценке в часах всё гораздо сложнее получается. Субъективно, очень скоро понадобится человек, который будет назначать какие задачи кому делать и будет вводить поправочные коэффициенты. Самоорганизованной команды не будет больше.
И что дальше с этим делаем? Увольняем? Игнорируем его мнение при следующих оценках?
Пытаемся выяснить причину — возможно изменились условия труда / состояние здоровья.
Если переоценки постоянные по времени и значению — можно вводить коэффициент.
Если переоценки постоянные по времени и переменные по значению — можно попробовать декомпозировать задачи и оценивать по частям.
А если только Вася будет делать? Или только Петя? Или Петя час поделает, а потом критикал баг прилетит и он отдаст доделвать Васе?
Ну такие вещи (перескок задачи от исполнителя к исполнителю) стоит минимизировать. А время выполнения если трекать — оно будет привязано к исполнителю
Обычная практика при скраме общий "стэк" задач, где люди просто выбирают их по порядку. Кто будет делать предсказать невозможно.
Обычная практика при скраме общий «стэк» задач, где люди просто выбирают их по порядку. Кто будет делать предсказать невозможно.
кто будет делать — предсказать невозможно, да (на этот случай, можно брать среднюю / максимальную оценку участников или указывать явно оценки на каждого участника), но «сначала делал один, потом другой» — это немного не тот сценарий, что вы сейчас озвучили.
С оценкой в СП понятно что делать на проваленном спринте: на ретроспективе смотрим мы оптимистично оценили скорость команды в целом или сработал какой-то риск — это простая информация, которую легко учесть в будущих планированиях или просто надо забыть.
Почему это таким же образом не сработает при оценке в часах?
В чём скорость будем измерять? В часах за час?
А зачем ее измерять? Вам скорость-то не важна, да и никому не важна. Важно, сделали вы задачи в срок или нет. Проваленный спринт — это когда вы не сделали задачи в срок. При чем тут скорость?
Спринт может быть провален по многим причинам.
Мне лично важна. При этом полное понимание, что мерять её ни в штуках задач, ни в часах за час смысла нет.
Мне лично важна.
Ну окей вам лично важна и вам хочется что-то там измерять в СП, Но при чем тут качество планирования? Это просто ваши хотелки :)
Вообще интересно как мы уже перешли от планирования к психологическому климату в команде и "мне лично важна". Кажется, у нас настала стадия торга :)
Давайте мби депрессию пропустим и сразу перейдем к стадии согласия? А то вы мне как собеседник импонируете, не хочется, чтобы вы зазря депрессировали :)
Фича фиче рознь же. Как можно мерять фичу изменить пару строк в UI (нормальную архитектуру предполагаем и реально протсо изменить) и чоздание, например, нового скриена на фронте и ендпоинтов для него на бэке?
Вот мне тоже интересно — как? Ну, если не в часах :)
Задача задаче рознь. А успели или нет — бинарная величина.
Премировать или нет — решение руководства, лично я против премий таких. А скорость нужна для оценки полезности изменений в процессе. Вот начали, например, тест-кейсы писать паралельно с разработкой — ускорило это процесс или нет. Понятно обычно, что тайм-ту-маркет это улучшает, а вот число фич за период с учётом их сложности увеличило или нет?
В чём скорость будем измерять? В часах за час?
В фичах за единицу времени / в проценте готовности фичи за единицу времени.
Кажется это очевидно из определения скорости, не понимаю, где вы тут нашли противоречие.
Вотерфол и ко позволяют достоверно и корректно планировать на годы вперёд. И итеративность в них есть, хотя циклы обычно больше.
Главное их отличие от аджайл подходов — они плохо работают с часто изменяющимися требованиями или когда требования до конца не ясны в принципе.
Главное их отличие...
Верно. А теперь скажите, насколько часто в наше время встречается возможность делать продукт без оперативного изменения требований?
Довольно часто, если подумать. Если вы делаете что-то сложнее интернет магазина, то требования к софту обычно долго прорабатывают аналитики, формируют вполне конкретные требования, которые не меняются кардинально на протяжении месяцев.
обычно долго прорабатывают аналитики
Компания, которая создает продукт, придерживаясь этой стратегии, нежизнеспособна. Не в современном мире.
Вы думаете, agile просто так что ли придумали? Чтобы персонально Вас позлить?
Ну, что я могу сказать на это. Или я работаю в вымирающих компаниях или вы неправы :) Время покажет :)
Я что-то не пойму — Вы то жалуетесь на agile и задалбывающую Вас эффективность, то говорите, что работаете в компаниях, работающих по устаревшим моделям. Мне нужно пояснение.
А мне не нужно :) Я устал тут уже отвечать в комментариях, быть может часов через 40-60 напишу вам ответ, потому что сейчас мне ваще не до этого :)
В соседней статье был перевод: англ. scrum «схватка вокруг мяча». Но я никак не могу понять кто с кем схватывается, что в этой метафоре есть мяч, и зачем эта бурная деятельность в принципе нужна.
Не забываем также, что фасилитатор стоит компании каких-то невменяемых денег, распределив которые между членами команды можно неплохо улучшить коммуникацию; даже на психотерапевта останется.
Сильно зависит от компании, предметной области и самой сути проекта.
Повторюсь, вы можете не верить в это всё, можете всё это ненавидеть, как угодно. Факт останется фактом — научный подход повышает эффективность работы команды в разы, что доказывается опытом буквально десятков тысяч команд в самых разных областях.
Дело в этой самой "эффективности". Я вижу результат этой эффективности. Говнокод, приложения, жрущие ОЗУ гигабайтами и тонны бесполезной для технического специалиста терминологии. Это эффективность измеряется только для бизнеса.
Я могу понять это. Я за деньги бизнеса делаю вещи для бизнеса. Это совершенно не обязывает меня любить это дерьмо, что породил подобный подход к организации труда. Я делаю это потому, что нужны деньги, но как человек я стал несчастнее от деятельности, которая раньше приносила мне удовольствие. Отсюда и мой гнев.
научный подход повышает эффективность работы команды в разы, что доказывается опытом буквально десятков тысяч команд в самых разных областях.
Да вы о чем вообще? О каком научном подходе речь, если подавляющее большинство лидов не знакомы с курсом матстатистики достаточно, чтобы этот подход использовать?
ЗЫ: Мы ведь об одном и том же научном подходе говорим, правда? Построение математической модели рабочего процесса и оценка его параметров, формулирование стат. гипотез и их проверка — вот это вот все, да? Или вы стори поинты с фасилитацией научным подходом называете? :)
Научным я называю подход, построенный на сборе метрик, их анализе и осмыслении. Построение гипотез и их проверка — тоже часть метода, разумеется.
Не очень понятен ваш сарказм, я разве что-то говорил о том, что знают или не знают "подавляющее большинство лидов"? Мы говорим об agile, или о вашем личном опыте наблюдения?
Научным я называю подход, построенный на сборе метрик, их анализе и осмыслении. Построение гипотез и их проверка — тоже часть метода, разумеется.
А конкретно можно, на примере?
Мы говорим об agile, или о вашем личном опыте наблюдения?
Если исходить из контекста — вроде как об agile, но, с другой стороны, общеизвестно, что agile методы традиционно противопоставляют себя научным методам управления.
Так что, о чем конкретно вы говорите — мне ясно не совсем, вам это следует уточнить.
Что конкретно за методы, в каком смысле "научный подход", вот это вот все. Чтобы понимать друг друга.
Ну так скрам так и работает по сути :) Ставится гипотеза, что команда сделает за спринт задач на N сторипоинтов, проверяется, смотрится результат, смотрится что было не так, выдвигает я следующая, проверяется…
Ну так скрам так и работает по сути :) Ставится гипотеза, что команда сделает за спринт задач на N сторипоинтов, проверяется, смотрится результат, смотрится что было не так, выдвигает я следующая, проверяется…
Статистическая гипотеза — это "с вероятностью 90% команда справится". А "или справится или нет" — это блондика и динозавр, а не статистика :)
Но вот то, что именно так скрам и работает — это вы в яблочко попали, действительно :)
Статистической гипотезой может быть и "команда справится с 90% объема".
Все очень зависит от бизнеса, но по моим наблюдениям, далеко не у всех фич есть объективный дедлайн (вроде отчетного периода бухгалтеров). Работу наваливают в духе "мы хотим чтобы еще вот это было" и приоритезируют в духе "фича А нам нужна быстрее фичи Б".
Статистической гипотезой может быть и "команда справится с 90% объема".
С какой вероятностью? :)
Без указания вероятностной оценки это не стат гипотеза, а "или справится с 90% объема или нет". Стат. гипотеза — это гипотеза о свойствах случайной величины (ну если математически). А "справится или нет" — это не св-ва случайной величины.
Смысл вероятностной оценки здесь в том, чтобы потом определить степень достоверности отклонений. Ну, то есть — команда не справилась в силу каких-то причин (и надо делать ревью и разбираться) или то, что она не справилась — это просто стат. флуктуация, с-но ничего предпринимать не следует?
Только первые несколько спринтов это "или справимся или нет". Потом набирается статистика, анализируюся тренды и делаются гипотезы вероятностные
Соответственно, фраза «за 2 недели успеем сделать задач на 50 СП» смысла не имеет тем более.
В целом, да.
«задача в n сторипойнтов делается в n раз дольше, чем задача в 1 сторипойнт»
А вот этого "в n раз дольше" как раз рекомендуется избегать, потому что SP тогда становятся какими-то нормочасами. Комплексная сложность задачи оценивается, а "SP в спринт" — грубая интегральная оценка производительности команды "сколько сложности мы доставили/собираемся доставить за спринт". При планировании превышение суммарных SP прошлых значений лишь сигнал "высокие риски того, что всё мы сделать не сможем"
Как Вы определили, что команда стала работать на 30% менее эффективно?
Нет, погодите, давайте разберемся. Вы стали тратить время на что-то помимо разработки, и на основании этого делаете вывод о том, что команда стала работать менее эффективно? Причем не просто менее эффективно, а аж на треть?
Прежде, чем задавать вопрос, как аджайл помог (или не помог) конкретно в вашем проекте планировать и прогнозировать, неплохо бы понять, возможно ли было планирование и прогнозирование до начала внедрения этого самого аджайла. Возможно, бизнес не имел никакого представления о том, что происходит на вашем рисерч-проекте, и насколько он близок к завершению?
Нет, Вы не привели пример, Вы привели собственное видение ситуации (напомню — без каких-либо объективных метрик Вы утверждаете о снижении эффективности команды на 30%). Я не ставлю под сомнение Ваш личный опыт, но я осмелюсь утверждать, что Ваше видение эффективности сильно разнится с видением владельца продукта.
Я не могу ответить на Ваш вопрос, потому что я не знаю деталей Вашего проекта.
Аджайл в том или ином виде применим к любым проектам и областям, связанным с задачами, или, если хотите, неким дискретным потоком единиц работы. IT, производство, продажи — да, да и снова да.
Если Ваш проект из таких (а он, видимо из таких), то да, аджайл применим и к нему.
Но Вы как-то незаметно трансформировали вопрос "как аджайл помогает планировать" в вопрос "когда проект будет выполнен". А между тем, это два разных вопроса, и на второй аджайл редко пытается дать ответ. В чем он действительно помогает — так это в понимании, когда конкретная задача будет выполнена. Возможно, с этим в Вашем проекте были проблемы?
Если бизнес не понимает скорость работы команды — как он вообще может предполагать о том, "когда что-то новое выкатится на прод"?
Вы что-нибудь слышали об итеративной разработке?
Аджайл позволяет уверенне планировать итерацию, и понимать, какие фичи будут за неё сделаны. Следовательно, дает ответ на вопрос, "когда что-то новое выкатится на прод".
Я нигде не утверждал, что итеративная разработка требует релиза по итогам каждой итерации.
Если мы знаем, какую фичу хотим доставить, и примерно представляем, как её делать, то мы можем достоверно запланировать её разработку. Но понимаю, в чем затруднение.
Приведите пример такой фичи, пожалуйста. Фичи, которая соответствует всем условиям:
а) должна быть поставлена пользователю
б) пользователь заранее должен быть оповещен о сроке
в) неизвестно, каким образом реализовывать эту фичу
Пока идёт чистый рисерч, если есть что продемонстрировать (прототип, обработки, бенчмарки и т. п.) — оно демонстрирует ся без выкатывания на прод и выдачи даже примерный сроков. Когда рисерч закончен, бэклог для мвп заполнен, тогда и начинаются сроки
AST и результаты бенчмарков с оптимизатором и без него.
Раз бизнес решил, что одна рисерч задача важнее другой и поэтому её делать надо первой или даже просто смог выделить что-то в задачу с конкретными ожидаемыми результатами, то результаты и надо демонстрировать, даже если результат "после двух недель сравнения разных доступных библиотек мы решили написать свою". Хотя бы вот так дословно, а лучше отчёт о сравнении.
Я не знаю вашей специфики, потому привожу примеры исходя из своего опыта. Но в общем случае я стараюсь не то чтобы избегать задач "за месяц найти способ сделать что-то", а дробить их на задачи типа "попробовать такой способ, другой, третий" с конкретным критериями завершения и результатами которые можно показать типа "вот графики, так получилось добиться 50 мс в 90% случаев, продолжение работ по этой теме считаю перспективным только в увеличении процента"
Но в общем случае я стараюсь не то чтобы избегать задач "за месяц найти способ сделать что-то", а дробить их на задачи типа "попробовать такой способ, другой, третий" с конкретным критериями завершения и результатами которые можно показать типа "вот графики, так получилось добиться 50 мс в 90%
Вы в данном случае, получаете, будете тратить время на формирование четкого плана на три месяца вперед (agile такой agile, кек)? Или же каждую неделю будете пробовать по способу и отчитываться "попробовал Х, не получилось, пробую Y" без какого-то уточнения, сколько займет этот процесс (ожидаемо) в общем?
Как раз там где весь бжкоог известен с первого дня аджайл особо не нужен.
Аджайл помогает в условиях постоянного изменения требований. Когда на начало работ ещё точного понимания а что нужно — нет.
я там выше по треду привёл пример админской работы (всего лишь одного проекта из десятков). И там, о да, "постонное изменение требований" во все поля. И попросил рассказать как в таких условиях применять сторипоинты.
Ну это спорно, на самом деле. Аджайл — это же не только оценка задач (она вообще не во всех аджайл-подходах нужна) и не только планирование, это вообще набор способов сделать процесс гибким и эффективным. Это включает в себя, в частности, методы анализа, ретроспективы, контроля и так далее. Если есть возможность всё это применять — почему бы нет?
в банальном проектном управлении есть такая штука как оценка рисков
и оценка отклонения проекта и его составляющих
при отклонении/возникновении риска управляющий просто пересчитывет ход работ и распределение ресурсов.
да, при этом надо работать с людьми, слушать, объяснять, договариваться.
никто не «позволит» вам прогнозировать, это всегда ваш риск
будущего никто не знает, оценить вероятности успеха/успеха возможно только при изучении, достаточном знании и наблюдении всех состоявляющих проекта, в частности работы тех самых людей
и все равно управление проектами-кейсами в большей части исскуство, постигаемое человеком на практике
> «традиционные» методы разработки, типа того же waterfall, не справляются от слова никак.
когнитивное искажение.
не справляются люди, которые не имеют достаточных компетенций в управлении проектами, в частности не
— имеют достаточного знания предмета
— окружения проекта и его стейкхолдеров
— людей, создающих продукт
— поставок и компонентов
— критичности
— договороспособности по целям проекта/кейса
Ну, если кому-то попсовые методы помогают просто таки собраться и довориться, то флаг в кулак.
Но лучше помогает хороший человечный профайлинг и простое деловое обсуждение, с часами жизни и целями, с четким пониманием выгоды и росков каждого. И лидерство как результат работы, компетентности и адекватного социального ранга.
для IT проектов waterfall не хорош примерно никогда. Главное преимущество итеративной и инкрементальной разработки не в точности оценок или плана, а в управлении рисками. Частые релизы снижают интеграционные и продуктовые риски. В классических waterfall проектах, все риски скопом ловишь в фазе интеграционного тестирования.
Классический как раз тоже с итерациями, просто они заметно реже.
Толковые и бестолковые сотрудники есть как среди менеджеров так и разработчиков. Но если бросаться в крайности, то ни какого диалога не получиться, а проблемы сами собой не решаться. Ищите точки соприкосновения.
Поэтому им пришлось все свою работу скинуть на плечи разработчикам, а самим делать митапы и фасилитировать встречи. Иначе поймут, что они не нужны и их уволят.
Я правильно понял, что на текущий момент автор не руководит тимой, так как вся команда QA разошлась отдельными QA специалистами по Dev командам?
Возможно Вы скажите, что сами виноваты и т.д., но для реализации или изменения потребовалось очень много согласований и разрешений. По этому важно обсуждать вместе, вся команда должна знать, понимать все изменения вносимые.
Скрам с первых же страниц возводит входной барьер, подменяя и запрещаяя использовать устоявшиеся понятные термины: вместо сроков спринты и сторипойнты. Уж не пытается ли когорта эффективных менеджеров защитить воображаемую вотчину от посягательств здравого смысла?
На практике скрам обмазывает людей процедурами, чтобы снизить их эффективность до прогнозируемого уровня. Меньше стресса из-за сорванных сроков, премии за стабильную поставку, а также чудовищные (если хотите, транзакционные) издержки и ощутимая демотивированность людей на местах.
На практике
Судя по вашему комментарию, Вы понятия не имеете о том, что происходит на практике. На практике эффективность команд, начинающих работать по какой-либо из agile-методологий, возрастает в разы.
Судя по вашему комментарию, Вы понятия не имеете о том, что происходит на практике
Это единственный аргумент тех, кто в секте?
эффективность команд возрастает в разы
В чем вы измеряете эффективность? (Уж не количеством ли одобрительных голосов, выраженных на ретроспективе?) Приведите, пожалуйста, пример такого расчета. Я честно гуглил, но нахожу только списки возможных метрик (улучшение одной, как всегда бывает, приведет к снижению других) и абстрактные рассуждения.
Если Вы не знаете, как оценить эффективность работы команды, то как Вы можете утверждать, что agile не способствует её росту?
Давайте без "давайте"? Я Вам, вроде как, ничем не обязан. Если Вы не знаете, что такое эффективность и при этом беретесь о ней судить — то какой смысл мне Вам что-то объяснять? Разберитесь со своей агрессией для начала, а после вернемся к обсуждению.
Если Вашей целью было "слить" кого-то — ради бога.
Понимаете, когда я отказываюсь продолжать дискуссию с человеком, настроенным агрессивно, настроенным на конфликт, — это не обида, это попытка сохранить себе нервы.
В моём представлении, дискуссия — это некий процесс обмена мнениями, попытками донести свою точку зрения, и обязательным условием этого процесса является взаимоуважение. Если его нет — то зачем мне эта дискуссия?
И да, я знаю, что это интернет, и тут всегда нужно быть готовым к тому, что тебя пошлют на три буквы. Но идти или нет, и продолжать ли слушать посылающего — этот выбор я оставляю за собой.
В моём представлении, дискуссия — это некий процесс обмена мнениями, попытками донести свою точку зрения
Ну вот у вас человек попросил раскрыть свою точку зрения, а вы в ответ: "Давайте без "давайте"".
Ну вам же конкретный вопрос был задан — какие вы имели ввиду метрики эффективности и как они использовались?
Потому что вы же понимаете, что таких метрик дохрена? И ваш визави может спокойно выбрать любую и сказать: "вот по этой метрике agile обосрался". И что дальше, вы скажете "это плохая метрика", но при этом не уточните, какая вам нужна? И, видимо, плохими будут все, в которых agile не блещет?
https://ru.wikipedia.org/wiki/%D0%9D%D0%B8_%D0%BE%D0%B4%D0%B8%D0%BD_%D0%B8%D1%81%D1%82%D0%B8%D0%BD%D0%BD%D1%8B%D0%B9_%D1%88%D0%BE%D1%82%D0%BB%D0%B0%D0%BD%D0%B4%D0%B5%D1%86
Никак не могу взять в толк, почему у Вас вызывает такие затруднения понимание этого комментария.
Как по мне, то скрам призван повышать мотивированность работы путём изоляции, что ли, команды от микроменеджмента бизнеса.
Только на фазах формулировке задачи и её приёмки. Грубо — два дня из 10 :)
Не так давно шесть дней вылетело. В первые три обо всем договорились и начали декомпозицию. Во второй понедельник руководство огласило некий аспект, который свел на нет 75% проведенного планирования. Сами, конечно, дебилы, что не предположили, не уточнили — но руководство на то и руководство, что не доступно с одного клика.
Если под группой людей понимается команда, то почему нет? Другое дело, если группа — это ребята из разных команд со своими проектами и целями внутри них. Возможно кто-то иначе ответит на ваш вопрос.
Команда — не голосовая — это группа разнообразных объектов, способная решать какую-либо задачу или выполнять работу с измеряемым параметром эффективности.
Группа определяется путём обобществления, команда подбирается путём детализации. Т.е. в группе важно делать упор на то, что людей объединяет. В команде же важно, чем один человек отличается от другого и как это укладывается в общее дело.
Для группы замена одного члена другим не принципиальна — всё равно в группе у всех одинаковый признак группы и группа при этом не перестает быть группой. В команде же замена одного члена другим практически невозможна. Выбытие участника команды останавливает всю команду. Подбор замены не всегда возможен.
Если разложить на столе детали редуктора — это будет группа запчастей. Общий признак — они предназначены для редуктора. На столе могут лежать несколько разобранных редукторов и это всё будет одна группа запчастей редуктора.
Но если собрать часть запчастей в редуктор — это уже будет команда, применительно к технике — узел, агрегат — в котором каждый член выполняет свою индивидуальную функцию, а вместе они передают крутящий момент от источника к получателю.
Рабочая или проектная группа в моём понимании: люди, собранные вместе для решения конкретных задач. Они могут быть командой, а могут не быть. Командой их делают раздкляемые всеми или почти всеми общие цели и консенсус о способах их достижения. Задача лида или другого менеджера с точки зрения бизнеса — создать из группы команду, достижения целей которой будет достиженим целей бизнеса. Команда может не получится в принципе или команда получится, но цели у неё будут другими.
1) В туалет ходят с туалетной бумагой, а в душ с полотенцем; и не наоборот. Агил используют в поддержке продукта, ватерфол в разработке.
2) Если для планирования нужна консультация кодера/разработчика, то лид/менеджер — никто. У каждого своя работа, писать код и строить планы — это разные вселенные. Менеджеру сдать проект нужно как можно быстрее, а разработчик хочет сделать как можно надежнее. Каким хреном они могут вообще сами договориться? Цели разные.
3) Команда — это не группа. В группе может быть сколько угодно каких угодно человек. Но в команде каждый человек берет на себя часть от 5ти ролей. И ранжировать людей джун-мидл-сеньор в команде невозможно, т.к. у всех разные роли и за счет этого команда действует как единый механизм.
А в целом всем нам знакомо, что происходит, когда молодого необразованного амбициозного человека назначают начальником над соплеменниками. Коллеги, не расслабляйтесь, изучите матчасть по скрамам, агилам, ватерфолам и командам. И посылайте недоменеджеров и недолидов сразу, как услышите их «фирменный» сленг («фасилитация», например).
Человеку свойственно за англицизмами и подменой понятий скрывать недостаток знаний и навыков.
На месте работодателя я бы попросил удалить эту статью, чтобы не позорить компанию.
В Dodo Pizza я пришла сразу на должность лида команды тестировщиков. Для меня тогда не было важно насколько увеличится мой доход при переходе с должности автоматизатора другой компании на должность лида в Додо. Сейчас нет команды тестировщиков как отдельной сущности, нет и необходимости ими отдельно управлять. Скорее теперь моя роль преимущественно в наблюдении за ними, консультации при необходимости, помощи в прокачке навыков по автоматизации и подобное.
А должен был вырасти?
Почему "доп"? Заменить одни на другие. Вместо того, чтобы весь день писать тесты или код, заниматься этим только полдня, а вторые полдня руководить :) Если руководить нравится больше, то можно и на меньшую зарплату согласиться :)
Если руководить нравится больше, то можно и на меньшую зарплату согласиться :)Точно! Где-то это уже было… что-то типа «чем меньше зарплата, тем богаче человек» или «чтобы перестать работать за деньги, нужно работать бесплатно»… Какая-то очень популярная книга лет 10 назад про папу.
"За деньги" или "ради денег" немного разные вещи. Работа ради денег предполагает основной целью работы максимизацию получаемых за работу сумм (обычно в рамках каких-то общественных и личных ограничений — кто-то киллером не пойдёт из-за рисков преследования, кто-то по личным моральным соображениям) при минимизации затрачиваемых ресурсов с перекосом в максимизацию доходов. Работа за деньги предполагает же нахождение оптимума между ресурсами и доходом. А работа, которая нравится требует меньше ресурсов при тех же результатах или даёт лучшие результаты при тех же ресурсах.
Когда у нас была отдельная QA команда мы использовали обычный Kaiten с нашей отдельной доской и бота, который помогал ребятам взаимодействовать с разными системами эффективнее. Сейчас у нас есть гильдийная доска (исследовательские задачи) и доска для бота (разработки и поддержки) без какой либо автоматизации по распределению задач между ребятами. С удовольствием бы узнала, а какой же инструмент используете вы, и как в нем автоматизирован процесс распределения задач.
Очень советую книгу, читал когда готовился к аналогичной должности.
Есть мнение, что тимлид вообще должен быть отстранён от непосредственно кодинга, чтобы эффективно управлять. Или грамотно делегировать полномочия по управлению сеньорам, подчинив им миддлов и джунов.
Лидер команды обычно говорит от лица команды перед вышестоящими руководителями и координирует работу внутри команды. Требований по кодированию или некодированию к нему нет, но, поскольку образно «Лидер» — это «лучший из» (to lead — вести), кодировать он должен уметь не хуже других членов команды (в некоторых местах тимлиду в должность добавляют слово «ведущий» — ведущий инженер, например).
Управлять от него также по большому счету не требуется, управлением занимаются менеджеры (manage — управлять). У лида задача — знать потребности команды и получать под них нужные ресурсы, чтобы команда работала в полную силу максимальное количество времени.
Это личное мнение. К сожалению, не все компании смотрят так на позицию тимлида. Но у таких компаний, как правило и возникают споры в чем мерить спринты — в сторипоинтах или часах.
Некоторые компании считают тимлидов менеджерами низшего звена прежде всего. При этом могут иметь позиции техлидов или ведущих инженеров. В принципе второй вариант мне больше нравится.
Он мало что понимал в разработке, но при этом он всегда это подчеркивал, просил объяснять ему как ребенку и никогда поперёк мнения разработчика не вставал.
Он начинал митинги с отвлеченных тем, в первую очередь выводил каждого члена команды на положительный настрой и только потом начинал обсуждать рабочие вопросы, зачастую в терминах «меня тут возлюбили по такому вопросу, ребята, что мне делать?» Т.е. он больше просил советов, чем ставил задачи.
Он сильно следил за тем, чтобы разработчик в течение дня был в отличной форме — и физической и моральной. Как мамочка вился вокруг команды, не давая раскиснуть и уработаться.
Он не занимался делегированием переговоров. Любой вопрос к его отделу со стороны компании решался только с ним, «вызвать ответственного», как это любят делать менеджеры, когда некомпетентны в предмете — никогда не практиковал.
Любой вопрос члена команды к компании (пропуск, абонемент в бассейн, отпуска, болезни, расчет ЗП) всегда решался только им самим. Вплоть до того, что пуговицу пришить? — Давай, я девочек попрошу, ты пока кофе выпей.
Разумеется, на волне кризиса, его посчитали самым безопасным звеном для сокращения. И, само собой, компания вскоре перестала существовать.
Для меня это был лучший пример менеджера-управленца за всю жизнь. К сожалению, больше мне таких не попадалось, хотя вру, знал еще одного, но поработать под его началом не предоставился шанс.
После того, что я видел, заявление компаний «мы очень внимательно относимся к нашим сотрудникам, создаём им лучшие условия работы» и факт присутствия во главе отдела некомпетентного управленца, который ставит задачи и теребит сроки — лицемерие или некомпетентность чистой воды.
5 ошибок начинающего лида