Comments 26
у каждой вертикальной полосочки сверху убираем обьем выполненной работы (в любых единицах, о которых изначально договорились), а новые таски в тех же единицах добавляем к низу столбика.
habrastorage.org/storage2/815/e46/209/815e46209de04571e75fa2fd0a49cf77.png
Когда график сходится — это и есть дата завершения проекта:
habrastorage.org/storage2/fab/0b1/a4c/fab0b1a4cb75baac879111e8a353525f.png
Подробнее тут: www.slideshare.net/Cartmendum/hitting-moving-target
… Только программист, который будет реализовывать конкретную функциональность, может знать, какие шаги нужно будет сделать, чтобы достичь цели.Так то оно так, но в большинстве случаев программист, каким бы он ни был хорошим может навешать лапши начальству о том, сколько времени займет разработка чего-либо. Так что я думаю хоть какой то временной контроль со стороны начальства необходим, ибо незнающему человеку можно сказать что «метод доступа к полю» реализовать крайне сложно и займет это несколько дней. А в целом очень полезная статья.
p.s. все картинки сделаны вручную? или есть ссылка на какой нибудь веб проект, дающий такие возможности?
У меня у знакомых мастер ремонтирует дом, и вот уже второй год дом для жизни непригоден (хотя сперва он брался все закончить за 6 месяцев). Намедни вот заставили его в комнатах повесить хотя бы двери, преодолев его «я лучше знаю когда и в каком порядке все делать!».
Так что в случае приведенной статьи Спольски конечно стоит на позиции программиста, но не следует забывать, что это не единственная позиция, и в конце концов последнее и решающее слово за тем, кто платит деньги (этому же программисту).
Если же в вашу команду приходит новый оценщик, у которого еще нет накопленных данных, предполагайте худшее — приписывайте ему ложную историю с большим разбросом скоростей до тех пор, пока он не справится с полдюжиной реальных задач.
И то от Junior'а.
В большинстве своем технические специалисты, работая в одной команде, наоборот, стремятся давать более точные оценки как показатель их профессионального уровня.
какой-нибудь веб проект, дающий такие возможности
Казалось бы, декомпозиция задачи на мелкие части должна давать более менее хорошую оценку. Но реально бывает так, что подзадача с оценкой 10 часов оказывается не нужна (в ходе реализации придумал другой способ). А бывает наоборот, вылазит другая подзадача, часов на 20 о которой даже не догадывался, пока не начал писать код (отсутствие какой-то очевидной возможности в используемой библиотеке, на которую рассчитывал).
А есть и ещё более суровые случаи. Когда решение «как это сделать» отнимает основную часть времени. То есть, планирование может занимать ещё больше, чем реализация. И это выглядит странно: планировать (а по сути, проектировать) три дня, сделать вывод, что этот код пишется за день и дальше оценивать необходимость функциональности исходя из того, что суммарно на неё нужно четыре дня. Не откажешься ведь уже, когда три четверти сделано
:о)
а предсказать такие сроки заранее было невозможно.Мои научные изыскания пока что привели к этому. Ваше мнение? )
But you can never get 4n from n, ever, and if you think you can, please email me the stock symbol for your company so I can short it.
Я бы перевёл это как "… пришлите мне тикер чтобы я мог его зашортить"
Зашортить (открыть короткую позицию) это значит взять в долг акции, продать их, а когда они упадут в цене купить акции и вернуть долг.
Другими словами Джоел готов поставить деньги на то, что если компания может сократить срок разработки с 4n до n, то она обязательно скоро упадёт на бирже.
Кстати, у него есть русскоязычный раздел: russian.joelonsoftware.com/
И не понимаю о чем говорят те, кто утверждает что Джоель Спольски перестал писать?
Последняя статья на его сайте датирована 30 апреля 2013 года. А это совсем недавно.
ссылка более недоступна :(
Именно для таких случаев и придумали архив интернета:
http://web.archive.org/web/2018*/russian.joelonsoftware.com
Спасибо за перевод. Очень крутая статья. Однако, в первом предложении выводов фраза:
еще несколько секунд каждый день, чтобы сделать запись, когда вы начали работать над конкретной задачей.
на мой взгляд переведена не совсем верно. На мой взгляд, это очень важная фраза и должна быть интерпретирована так:
< ... еще несколько секунд каждый день, для учета рабочего времени (трудозатрат), которое было потрачено на выполнение конкретной задачи>.
В Вашем варианте перевода создается впечатление, что надо фиксировать время начала работы над задачей. А по факту, от сотрудника требуется ежедневная обратная связь о трудозатратах по конкретным задачам над которыми он работал. Добавлю от себя, что еще, в случае необходимости (если разработчик видит, что не укладывается в план), требуется переоценка времени необходимого для завершения конкретной задачи. На основании этой переоценки, РП может заблаговременно скорректировать сроки (без оказания давления на исполнителей).
Доказательное планирование