Комментарии 49
От балды берется только там где scrum для галочки
И данный процесс итеративный и со временем эталонная задача изменится.
А про ту проблему про которую вы говорите — что фикс на 3 строчки кода, превращается в 3х недельную правку кода — Это должно разбиратся на ретро и понимать почему так вышло(потому что вы начали рефракторить все вокруг — большой технический долг, или задачу не разобрали — потому что задачи оцениваются не в строчках и оценка делается всей командой(тестирование, аналитика, разработка) — если так вышло, то тут либо все под забили на разбор задачи(да там 3 строчки поправить, ерунда).
Всякое бывает и каждый случай надо разбирать, именно разбирать, а не искать крайнего. Если технический долг большой, то наверное надо в бизнесовые задачи, как минимум вводить написание тестов, автотестов и тп.
Не происходит ли подмена понятия?
Что, на самом деле, мы вспоминаем трудоемкость аналогичных задач (потраченное время) и на основании этого называем количество story points?
Скорость будет изменяться от спринта к спринту.
Хм. Так и скорость, выраженная в часах — тоже будет изменяться? Ведь люди не роботы — устали, начали работать медленнее. То что раньше делалось за пол часа — будут делать за час-полтора. Получается хрен редьки не слаще.
Один раз работал в конторке где были эти сторипоиты, да и вообще нужно было наперёд сказать сколько у меня времени займет та или иная задача.
Имхо бред, я что лопатой копаю? Даже с лопатой можно неверно оценить может под землёй будет куча камней или какая нибудь коммуникация и все оценки сбились.
Это такая тупейшая чушь, цель которой только одна заставить разработчика пахать, раздал оценки тогда давай укладывайся в них, дал слишком много — а почему так много можно же быстрее...)
Ну или очередной тупой манагер который не занимался разработкой никогда, возомнил себя гуру планирования и без понимания сути вещей заставляет всех вокруг страдать точными оценками и отчетами по ним.
Поэтому сейчас когда я слышу о стори поинтах или аналогичной херни, сразу же ставлю крест на предложении.
В том и дело что требую где то явно, где то ничего не говорят но на разработчике висит уже груз ответственности в виде поставленой оценки.
Нон как видно ни начальники ни девелоперы не хотят разбираться в этой истории — первые предпочитают давить, вторые — страдать и винить сторипоинты :).
В любом случае главное, что надо помнить, чтоб не чувствовать лишний груз ответственности: оценка — это не обязательство. Когда вы уже работаете над задачей ваше обязанность сделать задачу как можно быстрее, а не уложиться в оценку.
Ага, классно получится если при планировании работы на спринт кто-то за вас скажет часы за которые выполнит работу, а делать её придется вам, вот тогда вы и поймёте почему удобно использовать какие-то-там поинты.
P.s. лично мне нравится система футболок: разделение задач на s, m, l, по договоренности можно добавлять xs, xl, xxl, но обычно это лишнее.
Логичная альтернатива это не использование оценок по времени. Точнее той формы что описана в статье и относится к этим бредовым методологиям.
По сути оценки времени даются всегда, на глазок, от коллеги к коллеге или начальнику. И корректируются в процессе работы. Смысла в чем то другом не вижу.
Когда вы управляете конвеером где налаженный тех процесс, такие оценки вполне возможны, но даже тут нет страховки от случайных событий — кто-то заболел или отключили электричество.
В IT уже начиная с самого среднего проекта эти оценки бред.
Может когда вся работа это постоянно клепание CRUD или типового УГ на Joomla и аналогах, оценки ещё возможны, при условии что команда слажена. В более менее сложном проекте это уже бред.
> По сути оценки времени даются всегда, на глазок, от коллеги к коллеге или начальник
На глазок — не работает. Оценка по времени для фичи, которая требует взаимодействия множества людей длительное время требует слишком большого количества информации, которой один человек практически никогда не обладает. Иногда надеятся на «опыт» оценивающего, но происходит либо суровая переоценка (а значит перерасход), либо просто низкая точность.
Оценки времени получаются с таким суровым разбросом, что на всех уровнях их все потом добивают многократными временными буферами и все равно сроки срываются (ну либо опять же закладываются такие суровые буферы, что некоторые компании можно сразу закрывать). Потому и используюся строи поинты. Их можно откалибровать с помощью исторических наблюдений. Правильно отработаный процесс оценки бэклога в стори поинтах дает не оценку, а вилку которая нужна для того, чтобы другие подразделения компании могли координировать свою работу с програмистами (маркетинг, продажи, hr,… да кто угодно).
В рамках спринта использование часов для задач — более-менее оправдано. Хотя бы потому, что строи поинты привязываются к комманде, а задачи к отдельным людям, а значит для отдельного разработчика становятся не преминимыми. Ну и при достаточном уровне декомпозиции временнЫе оценки по задачам так сильно не плывут.
Не, если задача декомпозирована на элементарные операции, то конечно да. Только я не разу не видел такой декомпозиции. Да и ответственность просто переносится на сторону аналитиков — а они смогут заренее сказать, сколько времени у них займёт декомпозиция задачи?
Сама идея о том что какие то аналитики, дают оценки времени выполнения задач программистам и делают их декомпозицию, вам это уже само по себе не кажется бредом. Вы программистом работаете? Очень интересно узнать.)
фича — это зачем мы хотим что-то сделать, история/юзкейс — что мы хотим сделать, а таски — это как мы это будем делать.
Это такая тупейшая чушь, цель которой только одна заставить разработчика пахать, раздал оценки тогда давай укладывайся в них
Ох, мы тут все стали забывать, что разработчиков берут потому, что они самые умные в команде и всем важно их мнение, а не потому что они должны пахать.
Никто вам манагерам ничего не должен.)
Вы забываете что разработчик это, в основном, квалифицированный специалист. Который обменивает свои знания на деньги компании. А типичный манагер, какой нибудь бывший тестировщик или БА, который 0 в разработке, и трясется за своё место потому что в другой компании он никому не нужен, а в этой получил место просто потому что работает там уже много времени и глубо знаком с проектом, но ни как не потому что он какой то одаренный и с глубоким понимание специалист.
Вот и получается что манагер судит по себе, он жутко зависим от компании и часто ограниченный, в его понимании все такие же как он, а разработчик ресурс. Только вот все не так. Уже не эра заводов и значение квалифицированного специалиста на проекте который может его поддерживать в живом состоянии, решая все проблемы это огромная ценность для бизнеса но не для этого специалиста. С учетом текущей высококонкурентной среды, когда неплохую работу можно найти за неделю.
Разработчик не пахарь, а ценность.
Кол-во манагеров я бы везде тотально сократил, потому что они обычно только мешают. Сколько я проектов уже перевидал, почти все если уже быть честным, где все держится на одном двух, главных разработчиках, и они решают все реальные проблемы, а манагер который только мешает, думает что это результат его 'гениальной' работы и избавится от этого ненужного баласта, постоянно отвлекающего, напрягающего и генерирующего поток бессмысленных идей и предложений по проекту, трудно. Почему то в головах многих людей старой формации, которые сейчас в силу своих возрастных преимуществ владеют большинством бизнесов, прочно заселе восприятие о необходимости манагера.
Но это не беда, сейчас уже много компаний которые стремятся к плоской структуре и они постепенно выигрывают позиции, за счет своей эффективности.
Оценка не должна быть обязательством, это инструмент управления проектом, а не перестраховка риска за счет разработчика.
Мне кажется что вы манагер и витаете в облаках.
Почему я должен чему то придерживаться? Если от меня требуют какие то оценки я говорю всегда что могу предположить, но ничего не обещаю и это оценка от балды. Если вам она нужна — пожалуйста. Только ко мне потом не приходите спрашивать почему она не соответствовала действительности.
Не нравиться, ну что ж поищите себе другого сотрудника, у меня благодаря моим навыкам разрабатывать работающий продукт, предложений предостаточно. Где мне не будут всякие не понимающие ничего в разработке личности указывать на то как я должен работать.
Я делаю продукт и сколько на него времени нужно столько и трачу, и это разумное время не больше не меньше нужного, другое меня не интересует.
Вообще стараюсь компаний где манагеры а не техлиды чем-то рулят, избегать.
Потому что постоянно объяснять человеку о процессе которым он не владеет бесмыссленно и себе же дороже.
Почему я должен чему то придерживаться?
Почему? В моем случае это неотъемлемая процедура в рамках процесса управления разработкой.
Я делаю продукт и сколько на него времени нужно столько и трачу, и это разумное время не больше не меньше нужного, другое меня не интересует.
Мне кажется вы банально не понимаете зачем нужна менеджеру оценка. Оценка инструмент управления проектом, который позволяет управлять ожиданиями стейкхолдеров с одной стороны, а с другой стороны сделать загрузку всех участников равномерной (без трудовых подвигов и без спадов в рабочей нагрузке).
Есть ли у разработчика право на ошибку? Конечно есть, в этой ситуации главное, чтобы он обновил оценку на новую, а не ждал дедлайна задачи и только потом сообщал, что ничего не готово. Задача менеджера при изменениях оценки оценить импакт на общий ход проекта и если риски изначально это не покрывали уладить вопрос со стейкхолдерами.
Как часто разработчик может ошибаться? Столько, сколько будет нужно чтобы он обучался нормально оценивать задачи. Главное видеть улучшения качества оценок с его стороны и заинтересованность выдавать правильные оценки.
Если его нет, то действительно всем будет проще пожелать друг другу удачи.
Но тут ещё много зависит от детализации оценки. Если оценивается в днях, то такой трекинг не нужен. А если в часах, то палка от двух концах: редко даже при желании можно чётко установить даже оперативно заняла задача, оцененная в 5 часов, 4 часа или 6 реально.
И оценить мы примерно можем сколько мы sp делаем, считаем среднее кол-во sp за 6 месяцев, вот он и средний показатель.
Ну а если не уложились и сильно всохатились, есть ретро на котором можно обсудить как улучшить ситауцию.
scrum — это процесс в котором надо научится жить. и менеджеры которые привыкли все возводить в абсолют(скорость разработки) для них трудно переключится на sp.
scrum — это процесс в котором надо научится жить
Его надо закопать и никогда не откапывать. Надеюсь когда-нибудь люди придут к этому.
Когда вы их используете для планирования (имеется ввиду planning собрание в scrum) — так думать можно и так проще. Но вообще, после того, как она прокорректирована несколькими спринтами — это комплексная оценка. В ней закладываются накладные рассходы на отпуска, собрания, автоматизированное тестирование, коммункации внутри комманды и с заказчиком.
> считаем среднее кол-во sp за 6 месяцев, вот он и средний показатель.
Зачем вы считаете средний показатель? Средний показатель — это способ подвести комманду под over-commitment.
На самом деле нет, это средний показатель наоборот позволят лишнего ничего не втянуть, что мы точно не успеем(бизнес старается под завязку спринт нафаршировать), но как правила в спринте нужно место оставить для различных форсмажоров, плюс задачи по улучшению процесса. Бывает даже так что, бизнесу точно нужна небольшая фича которая делаться достаточно просто, она ставится целью спринта, а остальное по возможности.
Вроде да можно сказать — а зачем они нужны пользы от них никакой(со стороны бизнеса), но тут главное донести их необходимость/суметь продать. И если что то идет не так, лучше завалится с задачами которые не влияют на цель спринта.
> точно не успеем(бизнес старается под завязку спринт нафаршировать)
Если вы берете среднее, значит у вас уже были спринты с меньшей производительностью.
> Вроде да можно сказать — а зачем они нужны пользы от них никакой(со стороны бизнеса), но тут
> главное донести их необходимость/суметь продать.
От кого?
"Речь идет только об обязательствах"
https://www.scrum.org/resources/commitment-vs-forecast
"One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of “forecast” in regards to the work selected for a Sprint. We used to say that the Development Team commits to which Product Backlog Items it will deliver by the end of the Sprint. Scrum now encourages the Development Team to forecast which Product Backlog Items it will deliver by the end of the Sprint. It may seem to be a simple wording change, but in fact there are strong reasons behind it, and surely it will have great implications. "
По моему опыту бэклог бэклог глубже одного спринта редкость. Не знаю кто готов оценивать бэклог на три спринта вперед, если к следующему спринту он может и должен быть реорганизован.
Оценка задачи базруется на опыте оценивающих. Равномерность команды недостижимый миф, поэтому отпуск любого члена команды меняет вес сторипоинта довольно значительно. Ценность метрики такой точности весьма сомнителен.
Планирование на срок дальше одного релиза сомнительно, поскольку релиз способен поменять ситуацию довольно радикально. Индустрия тоже может и будет меняться. При этому перенос релиза на один-два спринт, как правило, допустимо. Какой тогда смысл?
Все это я говорю после перехода команды с оценок в часах на сторипоинты. У нас довольно странный менеджмент. Он относится к Сазерлэнду как к иконе и не пытается ничего адаптировать, потому и перестраиваем едущую машину без оглядок. Спустя четыре месяца использования сторипоинтов могу лишь констатировать несходящиеся спринты.
Я так понимаю, что это нужно для того, чтобы примерно представлять сколько фич можно сделать за данное время и как-то приблизительно планировать вперед учитывая все эти отпуски и болезни усредненно.
Есть разный софт и он разрабатывался по разному. Для кого-то нужно планировать вперед, чтобы координироваться с переводчиками, маркетингом и прочим.
Вопрос. А что такое «несходящиеся спринты» и какой реальный негативный эффект от этого?
Несмотря на мою необученность я в курсе идей скрама. В реальности все может быть не так, как у них. В нашей команде никто не пробует восполнить отсутствие человека и доделать его работу, кроме случаев крайней необходимости. Это нормальная экономия времени — тому, кто делал сделать это быстрее, а очередность задач не имеет значения при скраме.
Люди команды очень-очень разные. Это не однородное месево, воспеваемое сазерлендом. Он требует увольнения любых людей выше или ниже среднего уровня команды. Это тупик. Команда не будет развиваться, потмоу как добиться равномерного развития невозможно. В общем утопия.
По моему опыту развитие продуктом никак не связано с маркетингом. Все маркетинговые мероприятия сеюминутны и концептуальны и с перспективой не связаны. Это мой личный опыт наблюдения за несколькими продуктами одной конторы. Но очень долгий. Маркетинг абстрактен.
Сходимость спринта для нас это приближение burn down chart к идеальной форме или ходя бы падение до 0 в конце спринта. Для нашего менеджмента это единственная ментрика, потому краеугольная.
Он требует увольнения любых людей выше или ниже среднего уровня команды.
Можно цитату?
Для нашего менеджмента это единственная ментрика, потому краеугольная.
Тогда надо увеличить оценки раза в четыре — по большей части итерации начнут сходиться. Оценка это вероятностный процесс, если хотите 100% уверенность в том, что выйдете в ноль до конца спринта, надо планировать бесконечное время
Я не знаю кто такой Майкл Кох и какой продукт он написал. Изначально оценка в sp выглядит очень слабой попыткой характеризовать динамику. На этот "Гербалайф" купилась целая куча деланных менеджеров, которые мало того что в софте не понимают, так и в принципе в управлении.
Пусть возьмём модель scrum, sp и так далее. Может изучал не так детально, но никто не приводил граничных условий когда эта модель работает, а когда нет. В энтерпрайзе, когда пара строчек в минуту может обернуться тем, что тебе надо поговорить 3 другими командами, у тех свои зависимости, в итоге строчка становится очень дорогой, и часто это выясняется только в процессе работы. Оценка в sp уже уехала. Второе легаси говнокод, в нем очень сложно давать оценки, т.к. не всегда понятно, какое изменение что за собой тянет. Более того перед изменением часто надо сделать рефакторинг, чтобы не усугублять ситуацию. А там бывает и дизайн надо обсудить и какие-то варианты попробовать, оценка мало предсказуема.
Разный уровень знания кода и технологий, кто то уже работал, кому то немного изучить. Оценки разные.
По опыту для точных краткосрочных оценок нужен хороший и понимаемый код и слаженная работа команды, тогда все можно оценивать в часах, днях. Но чтобы построить слаженную команду и контролируемый процесс, необходимо применять совсем другие методики и инструменты.
Всегда поражало что как можно оценивать сложный процесс разработки по одному графику попугаев? Куча факторов, в том числе противодействующих аккумулируются в одном графике. Вот график пошел не туда куда надо, какие факторы на это повлияли, хрен знает.
Очень напоминает форекс разводил, вот тут будет фигура "голова-плечи", курс идёт по волнам Эллиота, создаваемыми давлением Бойля Мариотта, значит тут продаем и тут покупаем, с вас 100$ за торговлю на истории))
Прежде чем вообще что-то изучать, всегда оцениваю результат этих людей: что они уже сделали, а всякие продаваемых "Гербалайфа" с канбаном, скрамом, скейлд аджайл фреймворком идут лесом — слишком много продаванов. Посмотрите как организован процесс написания ядра линукс, вот процесс Торвальдса стоит изучить, потому что результат как говорится "на лицо", а что эти продаваны сделали я не знаю.
Почему я не использую story points для планирования спринта