Как стать автором
Обновить

Комментарии 22

Я могу понять, почему некоторых менеджеров тянет планировать каждый день спринта.

Вопрос же стоит просто: либо Scrum, либо менеджеры. Как только появляется менеджер-прокладка, что-то обещающий заказчику, а потом - вжух! - превращающий эти обещания в обязательства команды, все техники Agile становятся бесполезны и даже вредны.

Это, кстати, относится и к "тимлиду". Как только тимлид начинает торговаться за сроки - Scrum умирает.

Формально, в скраме только три роли и ни менеджеров ни тимлидов срди них нет.

Ожидаемые преимущества оценки задач включают

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

А соотношение "пацанских часов к реальным" - ну можно иногда считать, только смысла в этом нет, всегда в диапазоне от 1:3 до 1:5 где то болтается.

НЛО прилетело и опубликовало эту надпись здесь

До сих пор мы обсуждали, почему я считаю, что оценка в Story Points не оказывает позитивного влияния на продуктивность команды

Чем оценка в часах в этом плане отличается? Кроме того, что создает еще большее давление на команду.

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

В этом и ошибка. По скраму такая задача (user story) должна возвращаться обратно в беклог проекта и проходить снова всю дорогу оценки приоритета и затрат.

Я все чаще чувствую, как распространяется негативное отношение к Scrum.

Потому что под скрамом везде понимают бог весть что. За 17 лет работы скрам видел только однажды, все остальное были какие-то сумеречные фантазии менеджмента названые "скрамом" - ну модно же :).

Оценка задач замедлит вашу работу. Не занимайтесь этим. Мы отказались от оценки еще 10 лет назад.
На сегодняшний день у нас есть достаточно данных от Rally по 60 тыс команд. Самые медленные из них оценивают задачи в часах. 

В посте как раз это и говорится про оценку в часах

Чет не понял, а как они сравнивали производительности команд? 60 тыс команд делали одинаковые задачи?
Или по субьективным оценкам при которых команды с эстимейтами в них регулярно не вписывались, а «значит медленные», а команды без эстимейтов оценки не факапили, а «значит быстрые»? :)

Вот исследование (pdf) на которое, судя по всему, ссылается автор. Ожидаемо, я не увидел там про скорость в разрезе методов планирования.

The Software Development Performance Index The Software Development Performance Index (SDPI)...

- Calculating the Index The SDPI is made up of several dimensions. Each raw metric is percentile scored, and one or more of those are averaged to make up a particular dimension. To calculate the overall SDPI, we take the average of the contributing dimensions’ scores.
- Responsiveness score from Time in Process (TiP) TiP is the amount of time (in fractional days) that a work item spends in a particular state. Weekends, holidays and nonwork hours are not counted. We attribute a work item to the bucket where it left that state. You can think of this as the time bucket where work was completed. We then take the median TiP of all the work items in that time bucket. While other parameters are possible, we only look at the TiP of user stories and we define “in Process” as ScheduleState equals “InProgress” or “Completed.”

- Quality score from defect density Defect density is the count of defects divided by man days, where man days is team size times the number of workdays in that time bucket. This results in a metric that represents the number of defects per team member per workday. We look at both the defects found in production as well as those found in test and other areas as indicated by the “Environment” field in Rally Software. We sense whether or not defects are typically being recorded in Rally for each of these types, for each team over a time period, and only use it if it passes this test. We’ll take either as the Quality score or the average of the two if both are reliably recorded.

- Productivity score from throughput/team size Throughput is simply the count of user stories and defects completed in a given time period. The Productivity score is the percentile scoring of this throughput normalized by the team size. While defects are shown in the drill-down charts, currently only user stories contribute to the Productivity score.

- Predictability score from throughput variability Throughput variability is the standard deviation of throughput for a given team over three monthly periods divided by the average of the throughput for those same three months. This is referred to as the coefficient of variance (CoV) of throughput. Again, we only look at user stories for this Predictability score.

Из pdf-ки. Под "медленные" имеется в виду с меньшим SDPI performance index.

И картинка, на основе которой делался вывод про "самые медленные" тоже есть в pdf-ке:
https://diary-public.s3.ap-southeast-1.amazonaws.com/scrum+estimate.png ( и разбор этой картинки: https://herdingcats.typepad.com/my_weblog/2017/07/the-trouble-with-charts.html )

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

Отрицательная это не обязательно значит, что негативная. Расследование инцедентов и problem management могут быть довольно увлекательными. Грамотно отрефлексированный продолб оставляет в целом позитивный остаток. На ТВ было шоу, посвященное расследованию авиакатастроф (Mayday), где показывали большинство стадий такого процесса. Ну или соответствующие топики в ITIL.

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

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

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

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

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

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

Честно говоря выглядит не убедительно, хотя я и не менеджер

Всегда есть руководство, которое спросит когда будет сделана задача. Нельзя же сказать директору "когда-нибудь"

Надо как-то синхронизироваться с другими командами. Та проблема что разработчики из кожи вон лезут чтобы успеть точно не проблема скрама. Надо или переоценивать задачу или учиться давать оценки точнее. От неверных оценок никто не застрахован.

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

Но не подумайте, я стороненик Agile, но того о котором писал Мартин, SCRUM мне тоже не нравится)

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

  1. Согласен, что в большинстве случаев то, что команды называют скрамом или эждайлом, на деле является бесполезной тратой ресурсов, не приносящей никакой бизнес-ценности. Про HADI циклы мало кто слышал и ещё меньше их увязывают со спринтами.

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

  3. Чем больше даётся времени на решение, тем выше вероятность качественного решения в срок. Но те меньше вероятности, что кто-то захочет в нее инвестировать. Треугольник проектного управления никуда не делся.

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

Демарко и Листер писали о том, что оценка задач снижает производительность команды в Человеческом факторе. Книга вышла в 1987, данные для выводов были получены ещё раньше - задолго до любого аджайла

НЛО прилетело и опубликовало эту надпись здесь

Похоже вы неправильно использовали SP, они как раз и нужны для оценки сложности грубо говоря, чтобы разобрать задачи из беклога и в дальнейшем брать их в спринт, а вы опять привязали их ко времени, хотя придумали их как раз от того, чтобы уйти от оценки в часах)) Наверное, это не инструмент плохой, а от того, что использовали как-то не так?

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

А почему, чем заменить, как бороться не ясно. Больше похоже на жалобу разработчика на то, что "глупые менеджеры, которые ничего не понимают в разработке" задолбали со своими сроками и дедлайнами. Это хороши видно, по:

Тем более, что оценки спринтов, как правило, являются необязательными и добровольно поставленными дедлайнами, нарушение которых не несет никаких последствий

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

Если вы не видите причины, по которая та или иная фича должна быть сделана в тот или иной срок, это не значит, что ее нет. И скажите спасибо, что всю эту информацию о каких-то коммитментах перед заказчиках, проблемах с бюджетом, результатам продаж, фильтрует от вас "прокладка-менеджер".

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

Иногда оценку задач проводили в условных единицах (Story Point), а иногда в относительных (с помощью техники Planning Poker).

Поскольку автор в конце ссылается на Сазерленда, то по Сазерленду Story Points - это оценка, основанная на сравнении, а Planning Poker - это метод Проведения этой самой оценки. Почему автор их противопоставляет? Т.е. налицо расхождения с Сазерлендом уже в базовых понятиях.

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

По моему опыту, именно в решении обозначенных проблем Scrum может быть хорош.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий