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

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

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

у каждой вертикальной полосочки сверху убираем обьем выполненной работы (в любых единицах, о которых изначально договорились), а новые таски в тех же единицах добавляем к низу столбика.
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 о которой даже не догадывался, пока не начал писать код (отсутствие какой-то очевидной возможности в используемой библиотеке, на которую рассчитывал).
А есть и ещё более суровые случаи. Когда решение «как это сделать» отнимает основную часть времени. То есть, планирование может занимать ещё больше, чем реализация. И это выглядит странно: планировать (а по сути, проектировать) три дня, сделать вывод, что этот код пишется за день и дальше оценивать необходимость функциональности исходя из того, что суммарно на неё нужно четыре дня. Не откажешься ведь уже, когда три четверти сделано :о) а предсказать такие сроки заранее было невозможно.
Я тоже столкнулся с рядом трудностей, когда попытался использовать методику. Но и пользу она принесла — пусть все не совсем по плану, зато есть неотфонарная дата завершения) К тому же новые и отсеяные задачи частично компенсируют друг друга — текущий проект еще не закончен, но за три месяца (из теоретических пяти) идем со всего лишь с двухдневным отставанием от первоначального плана, хоть за это время он и изменился процентов на 20…
В данном случае «evidence» переводится не как «доказательство» (мы на собираемся никому ничего доказывать), а как «наблюдение».
Да «доказательство» — слишком сильное слово, но «наблюдение» мне показалось все же слабоватым и теряющим смысл. Суть методики сводится к оценкам («показаниям») разработчиков, адекватность или несостоятельность которых и доказывается статистически.
Я бы перевел «Evidence Based Scheduling» как «доказательное планирование», по аналогии с «доказательной медициной» (evidence based medicine).
Ваш вариант определенно звучит лучше. Исправил. Благодарю!
Боюсь вы не правильно перевели пассаж с тикером.
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, то она обязательно скоро упадёт на бирже.
Возможно — этой области я не особо компетентен. Я добавил Ваш вариант интерпретации к переводу отдельной сноской для полноты картины.
Можете вообще удалить свой вариант. vmarunin прав: имеется в виду продажа без покрытия.
Автор когда то активно писал на эту и околостоящие темы. Толково писал! К сожалению перестал…
Недавно был тут топик про плотников, так вот там показали видео, судя по которому можно уместить в коробку чуть больше деревянных блоков, чем кажется, если их сварить =)
Ну так и тут можно «сварить»:

У вас может временно получиться выжать 10-процентный прирост скорости написания сырого кода ценой полного профессионального выгорания персонала.
Очень интересный автор. Когда-то меня на его сайт привела статья про дырявые абстракции.
Кстати, у него есть русскоязычный раздел: russian.joelonsoftware.com/

И не понимаю о чем говорят те, кто утверждает что Джоель Спольски перестал писать?
Последняя статья на его сайте датирована 30 апреля 2013 года. А это совсем недавно.

ссылка более недоступна :(

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.