Comments 34
Отдыхает каждый час минут по пять и этот отдых — часть техники безопасности, без него работать невозможно.Скорее 15 минут на каждый час.
Итого 6 часов за 8 часов, и то, только при условии если не мешают работать.
Но так как приходится общаться с коллегами, уточнять документацию и т д, то бывает и 4 часа в день не наработать (не накодить).
Я бы сказал что в хорошую неделю — два или три дня удается поработать по 6 часов чистого времени, а часто ни одного дня в 6 часов в течении недели.
В среднем, наверно 4 — 5 часов чистого времени в день, скорее 4 чем 5.
Не статья, а золотая скрижаль. Большое спасибо!
В любом случае, что бы ни делал бизнес-руководитель во время проекта, необходимо быть с ним и помогать ему. Сколь бы странными не казались его действия и просьбы. Его действия всегда направлены на успех проекта и руководствуется он только этой целью, а успех проекта это и ваша основная цель.
Ой-ой-ой. Лично моя практика многолетняя практика показывает, что руководствуются они, @бизнес-руководители технического проекта@, прежде всего заявленными на очередной презентации перед владельцами или управляющими бизнеса сроками формального внедрения новых фич. Самый малый их грех — выдавать предварительную оптимистичную оценку трудозатрат разработчиками на реализацию какой-то фичи с несформулированными до конца бизнес-требованиями за обещание разработчиков реализовать максимум за "количество часов в оценке, деленное на 8" календарных дней что угодно, похожее, а потом, при практически закономерном фэйле, обвинять разработчиков.
Прекрасная статья, спасибо! Прям до слез :) Жаль, что в реале большинство этих проблем никого (бизнес-руководителя, напрмер) не волнует.
Самым важным из них с точки зрения темы данной заметки является то, что если время по задаче выставлено не разработчиком, а его начальником, то разработчик работает вдвое менее производительно, чем если бы оценка времени не выполнялась вообще. Если время по задаче оценивалось самим разработчиком, то разработчик работает всего лишь на четверть менее эффективно, если бы он делал эту оценку. Это доказано 30 лет назад и стало широко известно тогда же, что не мешает руководителям требовать от разработчика укладываться в навязанные ему сроки.
Не подскажете, где посмотреть это исследование 30-летней давности?
Не подскажете, где посмотреть это исследование 30-летней давности?Подборка из нескольких разных исследований есть в 5 главе Peopleware Демарко и Листера. Я в данном случае писал про www.sciencedirect.com/science/article/pii/0164121285900068
Если время на написание тестов по каждой задаче сразу заложить и никого не спрашивать — то и убеждать никого не надо будет.
Формально очень попахивает превышением полномочий, если не более злостным злоупотреблением доверием. Заказчик (внутренний или внешний — не суть) обычно имеет полное право на информирование о ходе и составе работ над задачей/проектом, если явно не оговорено "под ключ".
Я бы хотел увидеть (но только со стороны!) большой проект, который выиграл от такого отношения к тестам по сравнению к разработке с использованием тестов.
Невозможно, ибо "история не знает сослагательного наклонения", а чистый эксперимент с выявлением явных плюсов или минусов не может, насколько я знаю, ни одно заинтересованное лицо.
Мне кажется, что выпускать качественное ПО без дефектов это все же задача и ответственность разработчиков, разве нет?В теории да. На практике нет. На практике лишь единичные заказчики готовы платить за качественное ПО без дефектов и то в очень ограниченном количестве случаев. Под качественным кодом я подразумеваю 1 дефект на 100 тыс. строк кода.
давайте пример как аксиомуВы теорией занимаетесь или практикой?
Если это дает выигрыш даже на малом масштабе,Не даёт. Первый месяц разработки без тестов даст на 20% больше кода, чем с тестами, если программисты имеют хорошие навыки написания модульных тестов, и на 50% больше кода, если не имеют. Про качество кода я помолчу.
Это просто заложено в самом TDD, как принцип.TDD это не про ускорение мелких проектов. TDD — это про то, как снизить экспоненциальную деградацию скорости разработки на длительных периодах разработки и при этом же снизить стоимость исправления ошибок на тех же длительных периодах.
Самый быстрый способ написать приложение малого объёма — говнокод. Это даже у Брукса есть.
Потому что не надо спрашивать — а не соблаговолите ли вы приостановить работу на месяц, т.к. мы грязно работали и надо наводить порядок? Если время на написание тестов по каждой задаче сразу заложить и никого не спрашивать — то и убеждать никого не надо будет.В теории всё прекрасно. Особенно с обманом других участников команды управления. Но вообще-то это должностное преступление. Не технический руководитель проекта принимает решение о качестве продукта. Не в его это ведении. А вот что находится в обязанностях технического руководителя, так это донести понимание как получить разное качество продукта при разной стратегии управления разработкой и добиться его при принятии решения.
И да, даже если бы это не было должностным преступлением, то всё равно так поступать не следует. Взаимное доверие является критически важным ресурсом при принятии решений. Это трудно объяснить словами, но это невозможно не почувствовать на практике.
Заказчик рулит качеством в плане scope, но он не может физически знать как делать для него работу.
Давайте посмотрим, как это выглядит в действительности. Заказчику продали проект. В договоре что-то написано. Что там написано — это вообще не дело техруководителя. Для этого есть бизнес руководитель проекта. Он получает на входе договор с заказчиком, техническое задание и смету от техруководителя.
Обязанность техруководителя написать грамотное ТЗ и составить к нему смету понятно и достаточно детально. На основе этих входов бизнес руководитель пытается совместить договор, смету и бюджет. При этом техруководитель должен (его обязанность) объяснить бизнес руководителю цену отказа от тех или иных пунктов из сметы, возможные окольные методы снижения стоимости работ и связанные с этим риски.
В случае, если заказчиком выступает бизнес руководитель процедура согласования значительно проще, но понимания обычно меньше — в таких ситуациях бизнес руководитель, зачастую, не знает специфику разработки вообще.
заказчику решать, нужен ли ему дом где кирпичи просто так друг на друге лежат, или раствором склеены
Заказчику просто нужен дом. А чем склеивать кирпичи — решает бизнес-руководитель со своим руководством. Если, например, этот дом на два раза переночевать или репутационными рисками можно пренебречь — можно обойтись и без цемента. И задача технического руководителя — дать две оценки сроков (стоимости) и возможных последствий (надежность, расширяемость и т.д.) для обоих подходов — с цементом и без.
Не должны технические специалисты (руководители и программисты) принимать бизнес-решений (а качество продукта — это именно оно).
Заказчику просто нужен дом. А чем склеивать кирпичи — решает бизнес-руководитель со своим руководством.
Какое-то у меня походу тотальное непонимание вашей роли "бизнес-руководитель". Это ИМХО определённо не задача бизнес-руководителя — решать нюансы склеивания кирпичей. Его задача — определить общие ТЗ дома и обспечить ситуацию, чтобы Архитектор мог спроектировать дом, а команда — построить. Архитектор решил, что команде нужен цемент — бизнес-руководитель должен обеспечить доставку цемента в указанные сроки и решить проблемы доставки.
Не должны технические специалисты (руководители и программисты) принимать бизнес-решений (а качество продукта — это именно оно)
Именно технические специалисты — программисты и тестеры несут ответственность за качество продуктов и если к их мнению не прислушиваются — то это реально фиговый бизнес-специалист. Равно как и когда бизнес-специалист говорит, что "тут мы порешаем за счёт каких-то внутренних тестов" — в 9 случаев из 10 — он некомпетентен. Он не может это оценить адекватно.
Можно (со стороны разработчика) долгие годы обходиться без тестов при одном из двух условий:
- доводишь до бизнеса, что все риски сломавшейся функциональности при очередной доработке он берёт на себя, раз он не нашёл ресурсов хотя бы на регресс-тестирование перед деплоем
- позиционируешь себя как бога, который если что всё исправит (или хотя бы окатится) за минуты
Формально можно, на практике это выстрел самому себе как минимум в ногу. Рефакторить же будет нельзя эффективно. Плюс потом уже тесты будут подгоняться под имеющйися код, а не описывать изначально поставленные задачи, ну и т.п. Последствий будет много и все неприятные. Полгода — это много.Да, полгода — это много. Да — выстрел в ногу. Да — рефакторить будет проблемно. В толковом проекте вся команда управления это понимает, но сделать ничего не может — сроки и объёмы уже проданы.
В такой ситуации необходим тимлид, который хорошо умеет писать модульные тесты и любит это дело. Одной из его задач будет отсматривать код и оценивать его на покрываемость тестами. Он по коду должен понять покрываем ли данный код тестами в принципе, насколько его легко покрыть и не стал ли он после очередной правки непокрываем. Если код трудно покрыть тестами, то задача возвращается разработчику с описанием как следует переписать данный участок кода, а иногда и с прямой ссылкой на наиболее подходящий шаблон проектирования.
Да, это тоже не панацея ни разу. Но именно так можно тянуть 7-9 месяцев без активного рефакторинга не покрывая код модульными тестами. Потом приходится отводить несколько недель на рефакторинг наиболее проблемных участков кода и начинать активно покрывать код тестами. Думаю, результат такого подхода для всех предсказуем.
Так что абсолютная полезность тестов в долгосрочной перспективе — это не всегда верно. Все зависит от того как в компании с багами разбираются.
Работал в компании где тестов для новой функциональности не писали, но использовали feature tags (Позволяет нажатием одной кнопки в runtime «откатить» свежий код) + регрессивные тесты для сложных случаев(и то в достаточно интересной форме) — если какой то баг все таки вылез. Качество продукта было очень достойным, скорость разработки бешеная. И все вполне себе годами работало и дышало.Верится с трудом, хотя в жизни всё бывает.
Во-первых, откат кода не решает проблему затрат времени на исправление багов. А править их надо даже если код откатывали. Во-вторых, непокрытый код трудно рефакторить и дорабатывать. Лишь достаточно плотно покрытый тестами код позволяет это делать без страха что-то сломать или не так сделать. В-третьих, как бы кох ни был хорошо структурирован, через какое-то время начинаются проблемы с появлением ошибок не там, где добавляли новый функционал или дорабатывали существующий. Но можно, конечно, жить как Wordpress или github — выпускать релиз без тестирования и по громкости криков пользователей (количеству постов в Твиттере) определять есть ли ошибки в функционале, насколько они критичны и где их искать. Каждому своё.
Да, есть достаточно большое количество компаний, у которых десятки мегабайт кода не покрыты тестами. И значительная часть этого кода — официально признаваемое легаси. Разговариваешь с ними о найме, узнаёшь о том, что они хотели бы перевести проект на современный фреймворк, но по прежнему не хотят покрывать код тестами, и уходишь.
Такое чувство, что автор живёт в Утопии… Если это реально рабочая модель — выглядит это круто, когда каждый знает своё место и имеет соответствующую компетенцию… Но что если кто-то уходит? Или людей не хватает, ведь по такому "эталону", как требуется в "Разработчиках"… да по нему вообще реально хоть кого-то нанять? Ну реально стоящего? Рост на новые технологии — запрещается, выход за пределы стека — запрещается, сказать проджектманагеру, что он мудак — тоже запрещается (причём априори — вы же такого в принципе не наймёте)…
Вообще какие-то наверное чисто "проджеткменеджерские" закидоны — покоробило.
Такое чувство, что автор живёт в Утопии… Если это реально рабочая модельОна не рабочая. Никому не пожелаю по ней работать. Но по ней временами приходится работать. При всём треше, который должен осознавать любой, кто имел дело с управлением проектами.
Но что если кто-то уходит?И так можно спросить про каждый элемент: а что, если он оказался ненадёжен. Поэтому описанное не методология, не фреймворк, не руководство, а из жанра «так бывает, так поступали, так сработало и есть понимание, что вот так вот и вот так вот не сработало бы».
ведь по такому «эталону», как требуется в «Разработчиках»… да по нему вообще реально хоть кого-то нанять? Ну реально стоящего?Да, последние пять проектов в таком режиме вполне себе прошли успешно. В трёх из них разработчиков нанимал и увольнял лично я.
сказать проджектманагеру, что он мудак — тоже запрещаетсяЛюдям вообще не стоит говорить, что они мудаки. Мудаки достаточно просто отсеиваются на собеседовании, а с оставшимися вполне можно по-человечески общаться даже в сложных ситуациях.
Вообще какие-то наверное чисто «проджеткменеджерские» закидоны — покоробило.Никому и не советую так работать. Только дело в таких проектах не в «манагерах», а именно в острой нехватке времени.
Да, последние пять проектов в таком режиме вполне себе прошли успешно
"Успешно" это заказчик реально доволен и получил всё что хотел (подчеркну фразу) или когда "главное что при нас — работает" и ещё 3 раза по столько же времени "чиним баги"?
Только дело в таких проектах не в «манагерах», а именно в острой нехватке времени.
Я работал уже во многих проектах и "острая нехватка времени" — это всегда косяк именно что "манагеров". Они там чего-то пообещали сделать по типу "пятилетку за три года", а потом — нехватка времени, ушёл ведущий или ключевой программер, которого задолбало, что откинуло реальные сроки ещё на X недель, но естественно — времени нет, а значит "все работают на выходных" и "херак-херак и в продакшен"… Потом уходит ещё кто-то… а потом кто-то не выдерживает и таки делает то, что людям вообще-то говорить не стоит ;).
заказчик реально доволен и получил всё что хотелЭто какая-то фантастика. Реальность иная: заказчик получил продукт, оплатил его и продукт используется в режиме промышленной эксплуатации. Вот это — успех.
Я работал уже во многих проектах и «острая нехватка времени» — это всегда косяк именно что «манагеров».В этом плане совершенно согласен.
Управление разработкой технологически сложных интернет-приложений в условиях острой нехватки времени