Comments 26
Ну и?
xyli0o а в чем собственно суть поста? А то это не статья, а какой-то клибаейтный заголовок и все.
Большинство средних и мелких ИТ-предприятий занято разработкой довольно стандартного и не слоюжного набора задач. Соответственно они поддаются достаточно точному нормированию.
Хотя не всегда, но это может быть связано с чисто субъективными факторами.
Например, команда разработчиков не имеет достаточной квалификации и тогда любая задача это квест. Или вместо того чтобы использовать для решения обычной задачи обычных средств (например готового фреймворка, cms или то что можно купить как услугу — карты, видеочаты и т.п.) команда начинает велосипедить — но тут уже время будет тратиться на на задачу а на разработку новейшего непревзойденного своего.
Но у этого вопроса есть и его вторая часть Она касается разработчиков/внедренцев ERP. Они почему-то не хотят смириться с тем фактом что выполнение одной и той же операции по времени может иногда в разы отличаться у разных исполнителей и у разных партий деталей. В уж просто посчитать какая трудоемкость выполнения операций по вводу информации в ERP систему и сколько для этого потребуется дополнительного персонала — это вообще за гранью понимания. Т.к. ERP это априори лучше и быстрее.
Автор пиши продолжение, реально читалось хорошо.
Размажь канбан и аджайлы, пошути про израильскую армию и «кабанов», можно добавить заметок и про российское МО.
Выйдет реальная увлекательная книга
По рабочему месту и личному в том числе личному пространству я привожу в пример обучающий ролик по скраму от ИБМ. Менеджер так удачно расположился сам и расположил своих подопечных что ему видны экраны разрабочиков-мужчин и ноги разрабочиков-женщин.
Э-э-э, давайте так — вы можете думать про это что угодно, а я бы просто сразу сказал «Не верю» (с).
Таких оценок просто не бывает в природе. Нет в программировании рутинных задач такого размера, которые можно было бы точно оценить.
Во-первых, два месяца следует разбить на рабочие дни, и никак иначе. И во-вторых, задачи для оценки должны быть размером порядка одного дня. Ну то есть, оценка в три дня — еще туда-сюда, четыре часа — тоже, но два месяца — никуда не годится, потому что ее точность — те же два месяца, то есть реальные сроки будут например от двух до четырех.
>Напланировали задач на тридцать с половиной часов, и команда разрабов из пяти человек всю неделю пилит и пилит и пилит.
Ну и наконец — в неделе обычно 40 часов. Что в таком случае означает ваша фраза? Если у вас в команде пять человек, вы на неделю должны были напланировать на них на 200 часов задач. То есть, задачи у каждого отдельные, а не пять человек сидят над одной и той же.
И если вы будете хотя бы эти простые правила соблюдать — вы будете получать тем более точные оценки, чем более знакома для вас конкретная задача. Иными словами — сначала декомпозиция на мелкие и знакомые задачи, и только потом оценка. Если декомпозиция не получается, значит задачи слишком сложные, или незнакомые, а точность ваших оценок никуда не годится. Но вообще говоря, с этим тоже можно жить.
P.S. Вам бы не пост на эту тему писать, а просто почитать что-то типа Де Марко и Листера, например, для начала. Об управлении проектами и рисками.
запланировали на 200 часов, а разработчики успели сделать на 30.5. Почему?
Вообще-то ответ на этот "почему" должны дать в конце итерации и обсудить командой.
Возможных разных "потому что" может быть несколько, вы приводите только один сценарий.
Как показывает практика, точность оценок со временем повышается, думаю не погрешу против истины если скажу, что при наличии подобных обсуждений точность повысится быстрее.
>тимлид на встречи побежал
А он не знал, что у него будут встречи? Да ладно вам, наверняка же догадывался — они регулярно бывают. Или знал, но не учел, что рабочих часов у него для кодирования меньше, чем 40 в неделю?
Статья начата хорошо, но оборвана на половине мысли.
Эстимейты хорошо работают на типовых задачах, поэтому правильно указывать не только оценку, но и например: доверительный интервал, мин-макс, условия применения, показывать риски (и точки в которых проводить эскалацию на ЛПР, чтобы не специалист принимал решение, а менеджер разделял ответственность за срыв сроков)
2. Хочется что-то попроще (например, sean-parent.stlab.cc/presentations/2016-12-14-management-tips/2016-12-14-management-tips.pdf)
Об эстимейтах