Pull to refresh

Comments 49

Потому что, очевидно, story point берутся от балды и метрикой являться не могут.
ну почему же от балды, sp это сложность задачи как ее видит вся команда и есть очень четкие правила как считать их(нужен эталон в 1 sp и уже с ним сравнивать).
От балды берется только там где scrum для галочки
Я пропустил какую-то революцию и мы теперь можем измерять сложность задачи не от балды? Вот это новость. Это напоминает ситуацию со спортсимами, где игроки часто спорят по поводу рейтингов персонажей, мол «вот у этого футболиста должен быть рейтинг 94, а не 92, разработчики накосячили!» И вроде как у разработчиков тоже как бы есть свой эталон «1 очка умений» для игрока, вот только все ли с такой оценкой согласны? Да и правильно ли разработчики оценили степень умений игрока? А черт его знает. Так же и в разработке. Простейший фикс на 3 строчки может откопать такой пласт технического долга, что вы еще 3 недели будете перебирать всю систему по кусочкам и выскребать оттуда все лишнее, а при планировании эта задача у вас пойдет с оценкой 1 sp и вы отстанете от графика аж на 3 недели. Даже постфактум мы не можем с достаточной точностью оценить сложность задачи, просто потому что не особо ясно что считать «сложностью». Поэтому и не могут sp считаться серьезной метрикой ну вот вообще никак, как и затраченные на работу часы.
Конечно никто вам не скажет что есть четкие критерии которых вы должны придерживаться для оценки сложности задач, НО каждая команда выбирает для себя эталон который берет за 1SP и уже этой задачей меряют все остальные.
И данный процесс итеративный и со временем эталонная задача изменится.

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

Всякое бывает и каждый случай надо разбирать, именно разбирать, а не искать крайнего. Если технический долг большой, то наверное надо в бизнесовые задачи, как минимум вводить написание тестов, автотестов и тп.
Не понятно, как эталон сложности прикладывать к другим задачам.
Не происходит ли подмена понятия?
Что, на самом деле, мы вспоминаем трудоемкость аналогичных задач (потраченное время) и на основании этого называем количество story points?
Скорость будет изменяться от спринта к спринту.

Хм. Так и скорость, выраженная в часах — тоже будет изменяться? Ведь люди не роботы — устали, начали работать медленнее. То что раньше делалось за пол часа — будут делать за час-полтора. Получается хрен редьки не слаще.
Все верно, не важно в каких единицах — скорость разная в каждом спринте.
И Cohn говорит о том, что при планировании спринта не нужно обсуждать скорость.
Story Points и скорость он использует только для долгосрочного планирования, для оценки бэклога продукта. Но скорость там усредненная.

Один раз работал в конторке где были эти сторипоиты, да и вообще нужно было наперёд сказать сколько у меня времени займет та или иная задача.
Имхо бред, я что лопатой копаю? Даже с лопатой можно неверно оценить может под землёй будет куча камней или какая нибудь коммуникация и все оценки сбились.
Это такая тупейшая чушь, цель которой только одна заставить разработчика пахать, раздал оценки тогда давай укладывайся в них, дал слишком много — а почему так много можно же быстрее...)
Ну или очередной тупой манагер который не занимался разработкой никогда, возомнил себя гуру планирования и без понимания сути вещей заставляет всех вокруг страдать точными оценками и отчетами по ним.
Поэтому сейчас когда я слышу о стори поинтах или аналогичной херни, сразу же ставлю крест на предложении.

Зря вы так, в этом деле надо без фанатизма — и тогда у всех всё будет хорошо. Насколько я помню, сторипоинты нужны в том числе для оценки фокус-фактора команды, да и никто же не требует от вас точной оценки — покер планнинг вроде бы должен повышать её точность, отчасти поэтому оценка в сторипоинтах, а не в часах.

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

А как он висит, если ничего не говорят. Вообще, насколько я помню, сначала в XP предлагали использовать «идеальные часы» и velocity оценивалась как отношение идеальных часов к календарным. Потом решили что это подбивает начальников давить на девелоперов, чтобы они работали согласно идельным часам, потом ввели сторипоинты, чтобы сделать единицу измерения абтрактной и отвязанной от времени.

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

В любом случае главное, что надо помнить, чтоб не чувствовать лишний груз ответственности: оценка — это не обязательство. Когда вы уже работаете над задачей ваше обязанность сделать задачу как можно быстрее, а не уложиться в оценку.

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


P.s. лично мне нравится система футболок: разделение задач на s, m, l, по договоренности можно добавлять xs, xl, xxl, но обычно это лишнее.

Логичная альтернатива это не использование оценок по времени. Точнее той формы что описана в статье и относится к этим бредовым методологиям.
По сути оценки времени даются всегда, на глазок, от коллеги к коллеге или начальнику. И корректируются в процессе работы. Смысла в чем то другом не вижу.
Когда вы управляете конвеером где налаженный тех процесс, такие оценки вполне возможны, но даже тут нет страховки от случайных событий — кто-то заболел или отключили электричество.
В IT уже начиная с самого среднего проекта эти оценки бред.
Может когда вся работа это постоянно клепание CRUD или типового УГ на Joomla и аналогах, оценки ещё возможны, при условии что команда слажена. В более менее сложном проекте это уже бред.

Странно. Редко приходится слышать такое аргументирование против стори поинтов.

> По сути оценки времени даются всегда, на глазок, от коллеги к коллеге или начальник

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

Оценки времени получаются с таким суровым разбросом, что на всех уровнях их все потом добивают многократными временными буферами и все равно сроки срываются (ну либо опять же закладываются такие суровые буферы, что некоторые компании можно сразу закрывать). Потому и используюся строи поинты. Их можно откалибровать с помощью исторических наблюдений. Правильно отработаный процесс оценки бэклога в стори поинтах дает не оценку, а вилку которая нужна для того, чтобы другие подразделения компании могли координировать свою работу с програмистами (маркетинг, продажи, hr,… да кто угодно).

В рамках спринта использование часов для задач — более-менее оправдано. Хотя бы потому, что строи поинты привязываются к комманде, а задачи к отдельным людям, а значит для отдельного разработчика становятся не преминимыми. Ну и при достаточном уровне декомпозиции временнЫе оценки по задачам так сильно не плывут.
> Имхо бред, я что лопатой копаю?

Не, если задача декомпозирована на элементарные операции, то конечно да. Только я не разу не видел такой декомпозиции. Да и ответственность просто переносится на сторону аналитиков — а они смогут заренее сказать, сколько времени у них займёт декомпозиция задачи?

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

Почему бред? В целом это как работа аналитиков искать закономерности типа «оценки этого программиста в половине случае в два раза больше факта, а в половине в три раза меньше», а задача менеджера составить план работ так, чтобы был запас процентов в 80 и при этом иметь в виду риски что может потребоваться 200
фичу придумывают аналитики, историю или юзкейс придумывает product owner в соавторстве с коммандой, а вот таски придумывают сами разработчики.

фича — это зачем мы хотим что-то сделать, история/юзкейс — что мы хотим сделать, а таски — это как мы это будем делать.
Это такая тупейшая чушь, цель которой только одна заставить разработчика пахать, раздал оценки тогда давай укладывайся в них


Ох, мы тут все стали забывать, что разработчиков берут потому, что они самые умные в команде и всем важно их мнение, а не потому что они должны пахать.

Никто вам манагерам ничего не должен.)
Вы забываете что разработчик это, в основном, квалифицированный специалист. Который обменивает свои знания на деньги компании. А типичный манагер, какой нибудь бывший тестировщик или БА, который 0 в разработке, и трясется за своё место потому что в другой компании он никому не нужен, а в этой получил место просто потому что работает там уже много времени и глубо знаком с проектом, но ни как не потому что он какой то одаренный и с глубоким понимание специалист.
Вот и получается что манагер судит по себе, он жутко зависим от компании и часто ограниченный, в его понимании все такие же как он, а разработчик ресурс. Только вот все не так. Уже не эра заводов и значение квалифицированного специалиста на проекте который может его поддерживать в живом состоянии, решая все проблемы это огромная ценность для бизнеса но не для этого специалиста. С учетом текущей высококонкурентной среды, когда неплохую работу можно найти за неделю.
Разработчик не пахарь, а ценность.
Кол-во манагеров я бы везде тотально сократил, потому что они обычно только мешают. Сколько я проектов уже перевидал, почти все если уже быть честным, где все держится на одном двух, главных разработчиках, и они решают все реальные проблемы, а манагер который только мешает, думает что это результат его 'гениальной' работы и избавится от этого ненужного баласта, постоянно отвлекающего, напрягающего и генерирующего поток бессмысленных идей и предложений по проекту, трудно. Почему то в головах многих людей старой формации, которые сейчас в силу своих возрастных преимуществ владеют большинством бизнесов, прочно заселе восприятие о необходимости манагера.
Но это не беда, сейчас уже много компаний которые стремятся к плоской структуре и они постепенно выигрывают позиции, за счет своей эффективности.

Как это противоречит тому, что разработчик должен уметь оценивать задачу и должен придерживаться названных собой оценок?
Разработчик должен уметь оценивать задачу, но он не должен придерживаться своих оценок. Как вы вообще это представляете? Вот оценил я задачу в 4 часа, прошло 2 часа, понимаю что и половины не сделано. Как я должен придерживаться? Забивать на, например, обработку ошибок? Имитировать ожидаемое поведение? Стучать по клавиатуре в 2 раза быстрее или что?
Должен обновить оценку и работать дальше. Конечно оценка зачастую зависит от качества проработки технического задания, знакомства с проектом и тысячи других факторов. Но, как показывает практика одни разработчики справляются с этим хорошо и практически никогда не ошибаются, а другие систематически ошибаются. Хорошая новость в том, что навык оценивания затрат это тоже скилл и его можно прокачивать и при адекватном подходе за пол года из условных «двоечников» можно сделать вполне уверенных «хорошистов».
Обновить оценку и придерживаться старой, даже понимая её нереалистичность — это очень разные вещи. Конторы, где менеджмент и работники придерживаются мнения, что оценка — это обязательство, мне напоминают СССР с его добровольно-принудительными «социалистическими обязательствами» за невыполнение которых в некоторые времени и по расстрельной статье пойти можно было.
А я вижу регулярно разработчиков, которые протестуют против оценок только потому, что их своевременно не научили это делать. Но через пару месяцев у всех все получается и никого ничего не беспокоит. Но да, оценка это обязательство разработчика в рамках некоторых методологий управления бизнес-процессами. Сейчас ИТ работы очень много и отлично, что у всех есть возможность выбирать другую работу, если из-за оценки вдруг приходится переступать через себя.
Я видел протестующих только среди тех, для кого данная оценка превращается в обязательство. И особо не важно, внутреннее или внешнее. Мне, например, не нужно переступать через себя чтобы дать оценку. Но бесполезно взывать «ну поторопись, ты в свою оценку явно не укладываешься». Да, я допустил ошибку, оценив задачу в, например, 4 часа, а по факту сделав её за 16. Да, возможно у компании в целом и лично моего руководства какие-то непредвиденные проблемы возникли, не заложили в планы риски моей неточной оценки. Но моя ошибка в неточной оценке, а не в медленной работе. Я несу ответственность за неточную оценку, а не за то, что не уложился в неё.
Могу подписаться под каждым словом. Задача менеджера/руководства оценивать риски заранее и компенсировать их, а разработчик любой квалификации может ошибиться с оценкой. Это часть рабочего процесса, а не трагедия и трагедию из-за неправильной первоначальной оценки делают только недальновидные люди.
Оценка не должна быть обязательством, это инструмент управления проектом, а не перестраховка риска за счет разработчика.
К сожалению, многие менеджеры, да и работники (даже если их никто не просит) воспринимают оценку как обязательство, и стремление её не нарушать или свести нарушение и ли его последствия к минимуму всякие нежелательные эффекты типа уменьшения качества и выгорания из-за работы по ночам\выходным. :(

Мне кажется что вы манагер и витаете в облаках.
Почему я должен чему то придерживаться? Если от меня требуют какие то оценки я говорю всегда что могу предположить, но ничего не обещаю и это оценка от балды. Если вам она нужна — пожалуйста. Только ко мне потом не приходите спрашивать почему она не соответствовала действительности.
Не нравиться, ну что ж поищите себе другого сотрудника, у меня благодаря моим навыкам разрабатывать работающий продукт, предложений предостаточно. Где мне не будут всякие не понимающие ничего в разработке личности указывать на то как я должен работать.
Я делаю продукт и сколько на него времени нужно столько и трачу, и это разумное время не больше не меньше нужного, другое меня не интересует.
Вообще стараюсь компаний где манагеры а не техлиды чем-то рулят, избегать.
Потому что постоянно объяснять человеку о процессе которым он не владеет бесмыссленно и себе же дороже.

Почему я должен чему то придерживаться?

Почему? В моем случае это неотъемлемая процедура в рамках процесса управления разработкой.

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

Мне кажется вы банально не понимаете зачем нужна менеджеру оценка. Оценка инструмент управления проектом, который позволяет управлять ожиданиями стейкхолдеров с одной стороны, а с другой стороны сделать загрузку всех участников равномерной (без трудовых подвигов и без спадов в рабочей нагрузке).
Есть ли у разработчика право на ошибку? Конечно есть, в этой ситуации главное, чтобы он обновил оценку на новую, а не ждал дедлайна задачи и только потом сообщал, что ничего не готово. Задача менеджера при изменениях оценки оценить импакт на общий ход проекта и если риски изначально это не покрывали уладить вопрос со стейкхолдерами.
Как часто разработчик может ошибаться? Столько, сколько будет нужно чтобы он обучался нормально оценивать задачи. Главное видеть улучшения качества оценок с его стороны и заинтересованность выдавать правильные оценки.
Если его нет, то действительно всем будет проще пожелать друг другу удачи.
Вот какое-то противоречие чувствуется в вашей позиции. Вот как вы представляете «разработчик должен придерживаться своей оценки»? Что он должен делать конкретно? Работать? Так он и так должен. Опускать какие-то куски решения, которые он закладывал в оценку, но не успевает реализовать? Другими словами отдавать решение по его мнению неготовое, сырое, не отвечающее архитектурным и прочим принципам и стандартам компании?
Это значит только то, что нужно быть сфокусированным и стараться выполнить работу в рамках оценки. Работать можно тоже с разным уровнем отдачи: например параллельно отвлекаясь на флуд с коллегами, перекуры, посещение необязательных митингов. Оценка позволяет смотреть на некоторые вещи по другому, а стоит ли например прямо сейчас поучаствовать в политической дискуссии или поспорить с кем-то на хабре или все таки уделить время задаче?
В одной из компаний, где работал, было требование менеджеров ставить задачи на паузу, если прямо сейчас ею не занимаешься и снимать, когда занимаешься. Про дискуссии на рабочем месте не скажу, но вот за перекурами, обедами и организованными митингами следили. Не жёстко, типа все мы люди и понимаем, что мог забыть переключить статус, когда получил сообщение в мессенджер «ты что забыл про митинг, 10 минут только тебя ждём!», но вот систематическое и злостное нарушение, скажем так, не поощрялось.

Но тут ещё много зависит от детализации оценки. Если оценивается в днях, то такой трекинг не нужен. А если в часах, то палка от двух концах: редко даже при желании можно чётко установить даже оперативно заняла задача, оцененная в 5 часов, 4 часа или 6 реально.
Я за разумные буфера в рамках задач. Есть набор задач, которые объединены в один пакет и общая оценка пакета в районе 50-60 часов. Добавляем к задаче буфер в районе 10-15% от общего скоупа всех задач и тогда по каждой задаче не нужно отслеживать получилось 6 часов или 8. Точка мониторинга это не превышение общего буфера по пакету задач.
sp про сложность и не разу про скорость. с задачей в 1 sp можно 3 дня делать монтонную просту работу, и с задачей в 5 sp -3 дня разбиратся и за полчаса доделать ее.

И оценить мы примерно можем сколько мы sp делаем, считаем среднее кол-во sp за 6 месяцев, вот он и средний показатель.

Ну а если не уложились и сильно всохатились, есть ретро на котором можно обсудить как улучшить ситауцию.

scrum — это процесс в котором надо научится жить. и менеджеры которые привыкли все возводить в абсолют(скорость разработки) для них трудно переключится на sp.
scrum — это процесс в котором надо научится жить

Его надо закопать и никогда не откапывать. Надеюсь когда-нибудь люди придут к этому.

Любой адекватный разработчик это понимает. Манагерам удобно так выжимать соки.
Когда я слышу это слово scrum или понимаю что эта бездарная идея где то рядом. Сразу делаю выводы кто передо мной и что нужно валить.

> sp про сложность и не разу про скорость.

Когда вы их используете для планирования (имеется ввиду planning собрание в scrum) — так думать можно и так проще. Но вообще, после того, как она прокорректирована несколькими спринтами — это комплексная оценка. В ней закладываются накладные рассходы на отпуска, собрания, автоматизированное тестирование, коммункации внутри комманды и с заказчиком.

> считаем среднее кол-во sp за 6 месяцев, вот он и средний показатель.

Зачем вы считаете средний показатель? Средний показатель — это способ подвести комманду под over-commitment.
> Зачем вы считаете средний показатель? Средний показатель — это способ подвести комманду под 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. "

Спасибо за ссылку!
Мне, как человеку страдающему от скрамма, безумно интересно узнать смысл оценок в сторипоинтах. Что дает количество сторипоинтов менеджменту я не могу понять. Слова не пусные. Я вижу пару моментов определяющих бестолковость сторипоинтов:
По моему опыту бэклог бэклог глубже одного спринта редкость. Не знаю кто готов оценивать бэклог на три спринта вперед, если к следующему спринту он может и должен быть реорганизован.
Оценка задачи базруется на опыте оценивающих. Равномерность команды недостижимый миф, поэтому отпуск любого члена команды меняет вес сторипоинта довольно значительно. Ценность метрики такой точности весьма сомнителен.
Планирование на срок дальше одного релиза сомнительно, поскольку релиз способен поменять ситуацию довольно радикально. Индустрия тоже может и будет меняться. При этому перенос релиза на один-два спринт, как правило, допустимо. Какой тогда смысл?
Все это я говорю после перехода команды с оценок в часах на сторипоинты. У нас довольно странный менеджмент. Он относится к Сазерлэнду как к иконе и не пытается ничего адаптировать, потому и перестраиваем едущую машину без оглядок. Спустя четыре месяца использования сторипоинтов могу лишь констатировать несходящиеся спринты.
Вот статья самого Сазерленда www.scruminc.com/story-points-why-are-they-better-than
Я так понимаю, что это нужно для того, чтобы примерно представлять сколько фич можно сделать за данное время и как-то приблизительно планировать вперед учитывая все эти отпуски и болезни усредненно.

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

Вопрос. А что такое «несходящиеся спринты» и какой реальный негативный эффект от этого?
Дисклаймеры: Я не фанат Сазерленда ни отца ни сына ни духа, который у них, вероятно, есть. Я не был ни на одном скрам тренинге. Я ненавижу скрам и любые концепции обесценивания девелопера.
Несмотря на мою необученность я в курсе идей скрама. В реальности все может быть не так, как у них. В нашей команде никто не пробует восполнить отсутствие человека и доделать его работу, кроме случаев крайней необходимости. Это нормальная экономия времени — тому, кто делал сделать это быстрее, а очередность задач не имеет значения при скраме.
Люди команды очень-очень разные. Это не однородное месево, воспеваемое сазерлендом. Он требует увольнения любых людей выше или ниже среднего уровня команды. Это тупик. Команда не будет развиваться, потмоу как добиться равномерного развития невозможно. В общем утопия.
По моему опыту развитие продуктом никак не связано с маркетингом. Все маркетинговые мероприятия сеюминутны и концептуальны и с перспективой не связаны. Это мой личный опыт наблюдения за несколькими продуктами одной конторы. Но очень долгий. Маркетинг абстрактен.
Сходимость спринта для нас это приближение burn down chart к идеальной форме или ходя бы падение до 0 в конце спринта. Для нашего менеджмента это единственная ментрика, потому краеугольная.
Он требует увольнения любых людей выше или ниже среднего уровня команды.

Можно цитату?


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

Тогда надо увеличить оценки раза в четыре — по большей части итерации начнут сходиться. Оценка это вероятностный процесс, если хотите 100% уверенность в том, что выйдете в ноль до конца спринта, надо планировать бесконечное время

Я не знаю кто такой Майкл Кох и какой продукт он написал. Изначально оценка в sp выглядит очень слабой попыткой характеризовать динамику. На этот "Гербалайф" купилась целая куча деланных менеджеров, которые мало того что в софте не понимают, так и в принципе в управлении.
Пусть возьмём модель scrum, sp и так далее. Может изучал не так детально, но никто не приводил граничных условий когда эта модель работает, а когда нет. В энтерпрайзе, когда пара строчек в минуту может обернуться тем, что тебе надо поговорить 3 другими командами, у тех свои зависимости, в итоге строчка становится очень дорогой, и часто это выясняется только в процессе работы. Оценка в sp уже уехала. Второе легаси говнокод, в нем очень сложно давать оценки, т.к. не всегда понятно, какое изменение что за собой тянет. Более того перед изменением часто надо сделать рефакторинг, чтобы не усугублять ситуацию. А там бывает и дизайн надо обсудить и какие-то варианты попробовать, оценка мало предсказуема.
Разный уровень знания кода и технологий, кто то уже работал, кому то немного изучить. Оценки разные.


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


Всегда поражало что как можно оценивать сложный процесс разработки по одному графику попугаев? Куча факторов, в том числе противодействующих аккумулируются в одном графике. Вот график пошел не туда куда надо, какие факторы на это повлияли, хрен знает.
Очень напоминает форекс разводил, вот тут будет фигура "голова-плечи", курс идёт по волнам Эллиота, создаваемыми давлением Бойля Мариотта, значит тут продаем и тут покупаем, с вас 100$ за торговлю на истории))
Прежде чем вообще что-то изучать, всегда оцениваю результат этих людей: что они уже сделали, а всякие продаваемых "Гербалайфа" с канбаном, скрамом, скейлд аджайл фреймворком идут лесом — слишком много продаванов. Посмотрите как организован процесс написания ядра линукс, вот процесс Торвальдса стоит изучить, потому что результат как говорится "на лицо", а что эти продаваны сделали я не знаю.

Не ответил на главный вопрос автора. Все что можно оценить, оцениваем, все что нет, не оцениваем.

Only those users with full accounts are able to leave comments. Log in, please.