Comments 108
А какой точки зрения придерживаетесь вы, документируете ли свой код непосредственно в исходниках?
Оба подхода имеют право на жизнь. И похоже золотая середина такая — пиши максимально понятный код без комментариев, но если нужная «чёрная магия», которая неочевидна с полтычка — сделай отдельный комментарий «что тут происходит»
Без комментов в сожных кусках кода все равно обойтись сложно.
Я больше про какие-то штуки, которые были, например, оптимизированы. И, если, например, изначально код делал какую-то банальную штуку — например, брал квадратный корень наивным способом, то потом превратился в кашу из ассемблера с магическими константами, который пофиксить правильным именованием переменных уже не получится ) Или подобные кейсы.
К сожалению за почти все 14+ лет разработки я не видел хороших вариантов именно в коде это описать и отобразить, в комментариях тоже. Не помогает и история коммитов, потому что или много изменений кода или же задача в таск трекере имеет только название и никакого анализа и описания.
Будучи архитектором, я не могу часто читать код со всеми деталями, я просто не смогу физически порой найти комментарий «почему» и буду страдать, плакать, идти к автору, если он еще работает и спрашивать почему так. И то не факт, что автор будет понимать и помнить почему так всё вышло.
Нужно описание архитектуры и бизнес истории, причем не в формате как это предлагает эджайл (или кто там это предложил) в формате: «я, как… хочу… чтобы ...» — это вот тоже не дает ответа на вопрос: «а почему ты так хочешь?». Нужны ADR и прочие архитектурные артефакты.
За сим закончу, а то начнет гореть сильно =)
Полностью согласен. Где-то должны быть отражены РЕШЕНИЯ — почему сделали так, а не иначе. Причём на всех уровнях, начиная с глобальной архитектуры. Именно это позволяет не ходить по граблям (я самый умный и я знаю как, все до меня — дураки, а начинаешь копать и выясняется, что предшественники не просто так сделали именно так и пытались таким образом обойти какую-то проблему).
Но при этом возникает другая проблема. Проектирование — оно однонаправлено. В результате имплементация получается как попало, потому что то, что нарисовано не вписывается в реальный мир. Ну, или разрабы скроили время и сделали как попало. И цикла обратной связи — синхронизации того, что реально сделано с проектной документацией… я не видел. Можно на это потратить кучу энергии и пытаться контролировать это на ручном приводе… но вряд ли это правильно.
Некоторое время назад мне пришлось разбираться с одной проблемой в нынешнем проекте. Под подозрение попала загадочная перетасовка битов перед вычислением результата. Коммит, которым эта строчка была добавлена, добавлял только эту одну строчку. Описание коммита — "исправить расположение битов". У меня ушла пара дней сопоставления документации на ECC и на наш контроллер, чтобы убедиться, что эти перестановки (плюс еще последующие 3 строки) действительно нужны.
После этого я сделал коммит, который добавляет к этой строке комментарий с описанием того, почему именно эти биты должны быть переставлены именно так (как пришло из контроллена и как нужно передать в следующую функцию), а комментарий к коммиту содержал вообще около 40 строк с полной табличкой соответствия бит.
Комментарии нужны не столько "что тут происходит", а "зачем это тут вообще делать".
Через каких-то 5 лет приходят в проект новые люди, которые, несмотря на то, что в индустрии недавно, уже сеньоры. Но при этом они начали с более новой версии, и кое-что им будет совершенно неочевидно.
Все так. Фундамент был заложен 30-50 лет назад и мы до сих пор ездим на принципах и технологиях созданных туда (unix, tcp/ip, KISS, SRP) и пр. И действительно к сожалению у ребят сегодня опыт только в кодировании и конкретных фреймворках. И соответствующий узкий кругозор. С другой стороны — и пофиг. Кто-то будет головой работать (и двигать индустрию вперед) и получаать over дофига, а кто-то будет работать руками и будет заменяемым
- Там (в твоем переложении на текущие реалии) есть тимлид/архитектор и старший, но нет места обычным программистам (не говоря уж о том, что титулы вообще — это не самое хорошее)
- Инструментальщика ты назвал DevOps'ом. Но все же, на мой взгляд, девопс лучше воспринимать как процесс, а не как отдельный человек. И по-хорошему, его должны делать все, а не кто-то один.
- Секретарь. На мой взгляд, очень расточительно иметь под это отдельного человека. Во-первых команда должны стремиться быть самоорганизующейся и самодостаточной. И многие вопросы связанные с техническими вещами или уточнениями требований от заказчика брать сама (что бы не было лишней передачи знаний и «сломанного телефона»). А не технические вопросы по проекту (и не только это) должен брать на себя владелец продукта (PO / PM)
На счёт того, что любая система тяготеет к разрушению, это тоже корпоративное наблюдение из 70-х. Сегодня есть фантастические программные продукты существующие 30 и более лет, такие как linux и emacs. Мне кажется, дело в том, что инженерия ПО сделала огромный шаг вперёд: мы намного лучше понимаем, как разрабатывать, чтобы продукты жили очень долго
По комментариям, Мартин прав: чем меньше комментариев, тем лучше.
По поводу второй части вашего комментария позволю себе не согласиться. Возрастание энтропии — это один из основных законов, которые встречаются в разных сферах, а не что-то специфичное для индустрии разработки ПО.
Сегодня есть фантастические программные продукты существующие 30 и более лет, такие как linux и emacs
и что? Это как загадка про корабль Персея. Хотя, конечно, феномен возможности существования преемственности программных средств вроде linux и emacs имеет место быть, но это именно то, что я называю моделью "коробочного софта" (в отличие от современных веб-продуктов, когда нет какого-то явного релизного цикла и в каждый момент времени есть конкретная текущая единая версия ПО, она же — последняя, ПО будто течет, как жидкость, от разработчика к заказчику или потребителю, непрерывно — концепция liquid software by Барух Садогурский)
и что?
И то, простите за автоцитату, что, инженерия улучшилась настолько, что любая система больше не тяготеет к разрушению. Выражаясь более простыми словами, если делать ревью, автотесты и своевременно рефачить, то продукт может развиваться сколь угодно долго. Пока на него есть спрос, естественно.
Это утверждение очень сложно доказать или опровергнуть,
Доказательством является тот неоспоримый факт, что сегодня существует много программных продуктов, существующих и активно развивающихся более 10-и лет. При этом, объём их кодовой базы просто пипец какой огромный. И эти продукты живут и развиваются. В 70-е ничего подобного не было и не могло быть
Сейчас в моде большая дробность, но суть не меняется — всё равно накапливается технический долг, и приходится тратить время на реорганизацию и переписывание
В 70-е не было самого понятия технического долга. И никто не знал что с ним делать. Ни один менеджер не выделил бы время на его устранение. Это и была одна из причин проблем описанных Бруксом.
В 70-е не было самого понятия технического долга.
Было, только не называлось так.
Те инженеры, что физическим миром работают — они как бы вполне в курсе были, что некие артефакты могут существовать много десятков лет и надо уметь с этим работать. И что если что-то не так сделаешь на проектировании какого-то узла, его изготовят десятками тысяч штук — то так ты с этим и будешь страдать неопределенное количество времени.
Эта наша отрасль ухитряется делать вид, что такого не бывает.
У них нет тех долга, так как им не надо выпускать следующую версию на следующей неделе.
Зато у них есть расходы на эксплуатацию на ближайшие много лет, которые из за неудачного проектирования или дурной конструкции узла взялись.
Точно так же как у нас есть расходы на поддержку продукта из за того же неудачного проектирования и дурной конструкции приложения
Точно так же как у нас есть расходы на поддержку продукта из за того же неудачного проектирования и дурной конструкции приложения
и что хуже — расходы на вывод из эксплуатации продукта и та же миграция пользователей/данных на следующую итерацию этого продукта или другого продукта.
Условно — когда у тебя появились пользователи — все, ты прибился гвоздями к тому, какое они поведение ожидают от системы. И его нельзя просто взять и поменять. Или тем более убить систему. Это будет или дорого в плане ресурсов (поддержка). Либо может нести репутационные риски.
Когда вторая версия выпускается через 5 лет, можно весь проект выкинуть
Нельзя. Потому что эта железка, в каком-нибудь тепловозе со сроком эксплуатации 50 лет стоит. Или внутри моста, который вообще в обозримом будущем никто заменять не будет.
Те инженеры, что с физическим миром работают должны делать правильно с первого раза.
это не так. Те же машины — сначала проектировали пилотный образец, тестировали, вносили коррективы, потом опять промежуточный вариант, а потом уже строили производственную линию по тиражированию.
В чем разница с айти — в айти стоимость проверок различных гипотех существенно ниже, т.к. все виртуальное. Но когда ты выходишь в реальный мир — тот же IoT, то приплыли. Стоимость экспериментов опять становится высокой и становится желательно делать максимально хорошо с первого раза, как Вы говорите
Те же машины — сначала проектировали пилотный образец, тестировали, вносили коррективы, потом опять промежуточный вариант, а потом уже строили производственную линию по тиражированию.
Да, вы правы. Но когда вышли на массовое производство, лучше чтоб всё было правильно. Выкатывать обновления очень дорого.
Но когда ты выходишь в реальный мир — тот же IoT, то приплыли
Почти так. Всё-таки там тоже можно обновления выкатывать. Только обновлялка должна очень хорошо работать
Те инженеры, что с физическим миром работают должны делать правильно с первого раза. У них нет тех долга, так как им не надо выпускать следующую версию на следующей неделе.
Полагаю что Вы, пардон, мало работали в этой области. Мне вот вполне довелось работать среди тех, кто "с 75-ых" и ранее, и которые с железом до которого после выпуска дебаггером не дотянешься. Кто лучше, кто хуже — такие же, по факту, люди, как и работающие сейчас. Другие модные термины, другого уровня абстракции проблемы — вот и вся разница. Не было у них некогда VCS, кодосравнивалок, а менеджер виртуальной памяти приходилось писать самому в кодах чтоб не тормозил — так теперь вполне учатся, применяеют и удалённо работают.
Ээ. Я когда про инженеров, работающих с физическим миром, говорил — так это я про тех, у которых никакого кода и электроники нет. А есть чертежи железной детали хитрой формы.
А, это другое, да. Значит, не так понял. Про них не скажу.
А вот вся та стоимость, что следует из повышенной стоимости эксплуатации слегка кривой детали. И стоимость замены всех ее экземпляров на нормальные.
Те самые "производитель XYZ отозвал автомашины с дефектами" Это часть выплата технического долга так выглядит.
Да ну? Я вот книгу с типографским браком в магазин умудрился вернуть ) проблема только доказать, что это реально существенный недостаток
ну, тут вопрос масштаба. Но по факту это брак процесса. Когда он становится массовым — приходится вкладываться производителю в возврат (отзыв) или ремонт за свой счет (и оказывается, что выгодно держать сеть сервис-центров, например). Это все про деньги, ничего личного. Не про прогресс, не про "сделать потребителю хорошо".
Излишне тяжёлая деталь, как вариант. Или излишне хрупкая шестерня, разрушение опорных катков под нагрузкой, топливный бак в боевом отделении, плохая вентиляция боевого отделения.
Это если вспоминать история разработки и внедрения А-32/Т-34
не очень понятно, что в мире чертежей железных деталей соответствует техническому долгу.
А вот та самая ширина задницы лошади и вытекающие из неё параметры ракеты.
Был техпроцесс X, для работы в связке с ним разработан техпроцесс Y, инструменты, стандарты, практики, инфраструктура. Затем X отмер, а Y нет и даже развился.
Положим, про лошадиные зады — это миф, но дюймовая резьба на водопроводных трубы в метрических Европе и бывш СССР — реальный технический долг.
Кто лучше, кто хуже — такие же, по факту, люди, как и работающие сейчас
В принципе, да. Только владеют несколькими тайными техниками: вылизать продукт ДО того как его увидит заказчик, написать менеджер памяти, если это надо сделать. Сейчас, мало кто может сделать как первое, так и второе
Ещё навык "Создать для Лексикона шрифт для печати "как рукописный", если диссертацию принимают только рукописной"
И эти продукты живут и развиваются. В 70-е ничего подобного не было и не могло быть
Ну здрасьте, а UNIX, а существующие до сих пор пресловутые системе на КОБОЛе?
Брукс же не говорит, что это «невозможно», там вся книга про то, что надо понимать суть сложностей и методы борьбы с ними. Собственно, непонятно, что принципиально изменилось в этом вопросе.
Про «технический долг» — это да, как в анекдоте «жопа есть, а слова нет». Собственно, «философия UNIX» (которая сейчас, мне кажется сильно размылась) — это как раз один из видов ответа на данный вопрос, родом как раз из семидесятых — как уменьшать технический долг и упрощать рефакторинг. Делаем гибкий универсальный API (текстовый ввод-вывод), разбиваем систему на минимальные части, далее занимаемся ими по отдельности. Микросервисная архитектура, если угодно.
Принципиально изменилось, что мы теперь знаем про техдолг и как с ним бороться. Мы знаем что надо автоматизировать тесты и знаем как это делать. У нас есть сотня примеров успешных проектов и тысячи примеров провалившихся проектов в которых каждый может покопаться и лучше понять как проектировать хороший API.
Штука не в том, что «мы знаем про...», а в том, что вы почему-то полагаете, что они про это не знали. Я так не думаю; но тут надо копать глубже в историю, конечно. На сегодняшний день книга Брукса выглядит несколько капитанской, но это ровно потому, что его идеи (как и других единомышленников, конечно) теперь считаются «здравым смыслом», ну и замечательно.
вы почему-то полагаете, что они про это не знали
Были у меня старшие товарищи из тех времён. Все, как один, смотрели на современные процессы разработки с некоторым принебрежением: мол, напридумывала молодёжь всякого, вместо того чтобы просто без багов писать. Да и, трудно поверить, что люди знали про автотесты, код-ревью и техдолг с рефакторингом, но нигде про это не написали ни статей, ни книг.
RVS вышел в 82-м, CVS — в 86-м.
Верно, то есть UNIX уже десять лет как писали к тому моменту, и ничего, справлялись.
напридумывала молодёжь всякого, вместо того чтобы просто без багов писать.
Да я, в общем, не вижу в этом взгляде особых проблем: ведь тот же репозиторий нужен для того, чтобы совместно редактировать код. Но если система построена как UNIX — как коллекция небольших утилит — то ничего совместно редактировать и не надо. Конечно, хорошо бы ещё следить за версиями в своём собственном коде, но при известной дисциплине и этого можно добиться.
Я не говорю, что этот метод хорош, но при некоторых договорённостях управленческого порядка вполне работоспособен.
а и, трудно поверить, что люди знали про автотесты, код-ревью и техдолг с рефакторингом, но нигде про это не написали ни статей, ни книг.
Ну, вы утверждаете отсутствие чего-либо. Это довольно смелый подход. Если мы не будем заниматься стрельбой по движущимся мишеням, я предложу просто два контрпримера на поверхности:
Статья 1976 года про code reviews, на Google Scholar можете найти полный текст.
Известная книга ван Тассела 1978 года. В пятой главе вполне себе про автотесты, в т.ч. про автогенерацию тестовых данных.
Статья 1976 года про code reviews, на Google Scholar можете найти полный текст.
О, спасибо, интересно прочитать будет.
Статья 1976 года про code reviews, на Google Scholar можете найти полный текст.
вот она, кстати. Только там описан ревью, проводимый после написания кода. А не так как сейчас, когда, во-первый, ревью делают на каждое изменение, а во-вторых, его делают наши же коллеги.
Известная книга ван Тассела 1978 года. В пятой главе вполне себе про автотесты, в т.ч. про автогенерацию тестовых данных
Извините, но там про автотесты нет вообще, а про автогенерацию тестовых данных один абзац. Это и понятно: какие автотесты, если программа на перфокартах. Зато, есть шикарный перл: «Если вы верите, что можете писать программы правильно, так оно и будет. Если же вы убеждены, что написанная вами программа непременно содержит ошибки, — они неизбежны» (начало главы 4.32)
Конечно, отдельные элементы современных процессов появились давно: мы, таки, стоим на плечах гигантов. Но, всё-таки, целостный процесс, позволяющий создавать и развивать циклопические программные системы, сложился в последние лет 20
Про ван Тассела тоже мимо — читайте разделы 5.17-5.18 и около них. Более того, снова движущаяся мишень. Мне лично книга ван Тассела не слишком нравится — там много общих рассуждений и мало конкретики. Однако она ни разу не претендует на новизну и глубину — автор на некотором (довольно поверхностном) уровне обсуждает сложившиеся практики. Моя цель — показать, что такие практики были, а если требуется более глубокое и вдумчивое описание существовавших процессов — это уже другая задача.
Про code review — я и говорю, вы мне предлагаете стрельбу по движущейся цели
Естественно, с самого начала имелся ввиду процесс, более или менее, современного вида, когда каждое изменение просматривается одним-двумя коллегами. Понятно, что перепроверять проект не Кент Бек придумал.
Так-то, ревью ещё фараон Джосер Имхотепу, наверное, делал. Я бы делал, на его месте.
читайте разделы 5.17-5.18 и около них
Да, действительно. Разделы 5.17.5 и 5.18 описывают систему, вполне современного вида
Естественно, с самого начала имелся ввиду процесс, более или менее, современного вида, когда каждое изменение просматривается одним-двумя коллегами
Ну так дайте ссылку на современное определение. В википедии такого нет (и определение из википедии ссылается на печатные источники), а наши личные представления о прекрасном чего обсуждать.
Спасибо за комментарий. Но Вы правы и нет одновременно. Действительно, указанные подходы создают плечо при помощи которых радикально увеличивается качество кода и, как следствие — становятся возможны существенно более сложные системы. Это примерно как сравнивать ассемблер и джаву. На первом мы гораздо быстрее утыкались в возможности человеческой головы и в принципе сейчас сложность систем качественно другая. Но при этом все равно даже сейчас мы можем получить систему, которая упрется опять в предел возможности расширения. И в этом смысле ситуация ровно такая же как и была. Ну, и сложность в определенной степени перекочевала с уровня кода на уровень взаимосвязей между теми же компонентами (реверанс в сторону микросервисов). Победим эту проблему — история сделает очередной виток и упремся в что-то ещё.
Но при этом все равно даже сейчас мы можем получить систему, которая упрется опять в предел возможности расширения
Как раз принципиальная разница в том, что во времена Брукса мы гарантированно упирались в возможности расширения. А сейчас, можем не упереться. Причём, это происходит не случайно или по наитию, а в следствие применения известных методов.
Это как загадка про корабль Персея
И всё таки это был корабль Тесея :)
Заяц стоял у книжного шкафа и ленивого перелистывал страницы какой-то книги. Со вздохом сказал:
— Реквием по надежде, — и начал ставить книгу на полку.
— Что там у тебя? — живо поинтересовался Оруженосец.
Заяц подошел к столу и положил книгу в центр.
— «Peapleware». Знаю, читал, — сказал Оруженосец. – А почему реквием и почему по надежде?
— Потому что тридцать лет назад эта книга была надеждой, а сейчас это реквием.
(с)
И вместе с вами обсудить некоторые цитаты, которые актуальны до сих пор.
Я не знаю, какой у Вас опыт в разработке, но могу точно сказать, что подходы кардинально поменялись за последние 25 лет, а уж по сравнению с 1975-м так это вообще другой мир.
Ради примера берем цитату:
Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше.
В современных реалиях хорошо отлаженный onboarding — это просто мастхэв любого мало-мальски уважающего себя Team Lead/Project Manager. В нынешнее время разработка довольно хорошо параллелится и есть масса средств для контроля за ней при любом количестве участников. Я напомню, что в 1975-м еще не было так нам привычного интернета и тех инструментов, что мы используем для разработки сегодня — bug tracking, VCS, wiki…
Тем не менее мысли Брукса весьма понятны и довольно хорошо изложены, но прямо переносить их на текущую реальность не стоит, а уж тем более применять в практике.
VCS, bug tracking, wiki — это именно те инструменты, которые дал нам технический прогресс и они облегчают нашу жизнь. Назначение их при этом не меняется. В начале документацию распечатывали на бумаге и подшивали в архивы, затем Брукс предлагал как более современное решение использовать «микрофиши» (уменьшенные в 90 раз фотокопии документов на плёнке). Сейчас мы фиксируем документацию в wiki. Но назначение инструмента от этого не меняется — распространение знаний о системе.
Первая VCS появилась, кстати, для OS/360, но разработку SCCS начали только 72-м, так что можно только представить, как тогдашние разработчики синхронизировали кодовую базу.
Речь именно о цитате:
Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше.
В те времена управление разработкой было не таким гибким, а сама разработка — не такой параллельной и модульной, как сейчас. В современном мире добавление рабочей силы как раз позволяет уложиться в сроки, сам видел такое не раз.
На самом деле очень много «но». С тем же успехом сегодня добавление новой рабочей силы может похоронить проект. Тем более — когда речь идёт не о +1-2 разработчика, а когда нужно расширение на 50-100% от текущей команды
у нас agile и требования меняются очень часто — это риски. Которые могут привести к необходимости пересмотреть capacity.
В случае "водопада" — вы же сами понимаете, что там на старте очень сложно оценить реальный скоуп. Потому что каждый продукт уникален. Это не шаблонная работа печь пирожки. Погрешность оценок в начале просто космическая. И учитывая количество взаимосвязей — действительно может оказаться на трети проекта, что захочется докинуть еще 50% людей.
И такой проект думаю был мертв изначально, только вот обнаружилось это как раз к моменту дедлайна)
может быть )))) учитывая еще оптимистичность оценок )
Смотря от размера команды. К двоим докинуть ещё одного-двоих — ещё в пределах вообразимого и даже есть шансы на успех. Но это изначально очень камерный проект выходит, да.
«Предположим, что трудоемкость задачи оценивается в 12 человеко-месяцев, и три человека должны выполнить ее за 4 месяца, причем в конце каждого месяца имеются четыре контрольные точки A, B, C и D, в которых можно произвести измерения. [имеется в виду, что всего 4 точки — одна точка в конце календарного месяца]. Предположим теперь, что первая контрольная точка была достигнута лишь по истечении двух месяцев. Какие альтернативы имеются у менеджера?»
То есть какой тут онбординг — половина срока прошла, и вся наша скромная команда из трёх человек по уши в работе. Вот ещё новичков им не хватало. Сейчас, так понимаю, в этом отношении ничего не меняется.
Я, конечно, извиняюсь, но зачем менеджер ждал второй месяц? То, что первый этап не закрывается вовремя, становится известно не в первый день второго месяца, согласитесь? Обычно это становится ясно заранее, полагаю, что за неделю точно до конца первого месяца было ясно, что не успевают. То есть просрал сроки конкретно менеджер и есть повод задуматься о его профпригодности.
В рамках конкретной задачи я бы сказал, что надо иметь не четыре, а, скажем, восемь контрольных точек, но это тоже некий бюрократический оверхед, так что хороших бесплатных решений нет.
Суть в том, что даже хорошо отлаженный onboarding требует чьего-то внимания/ресурсов. Новичок не может сам по себе, «в вакууме», въезжать в проект. Ему всё равно потребуется помощь коллег.
Предположительно, это может делать тот самый человек, что проект документирует. Заодно и проверит, насколько хорошо эта документация написана.
И да, похоже, это должен быть именно отдельный человек. Разработкой полноценно не занимающийся. Т.к. сами разработчики по факту доки писать не любят, не умеют(этому просто не учат на самом деле), и у них глаз замылен 'тут и так все понятно'.
Без отдельного человека, как мы видим, получается плохо. Именно потому что существует конфликт интересов. В этой dreamteam по Бруксу как раз не хватает 'хранителя знания', главное умение которого вытягивать неявное знание из остальных и фиксировать его.
Его роль размазана по людям, из которых это знание как раз вытягивать надо, и которого они не замечают.
Кроме онбординга любой новичок в проекте неизбежно добавит, например, нагрузку на кодревью(оно ведь проводится?). И на синхронизацию(она ведь проводится?). И на тестирование — до интеграции его веток(оно ведь проводится?) и результата после интеграции(- // — // -).
И если первая часть скорее добавилась за эти годы, а третья расширилась, то вторая никуда не девалась.
2. Unit-тесты кода тоже появились позже вроде как.
3. Синхронизация кода была вручную, в этом и есть проблема масштабирования команды в те годы
- Сейчас проводится. И требует время. И требует внимание других разработчиков — то есть, снижает их производительность.
- Не юниттестами едиными. И есть вещи которые и не поюниттестишь. Хороший инструмент, но он не про тему разговора.
- Оно и сейчас вручную в случае плохо состыкованных частей разных отделов/групп, заливаемых непрерывнымпотоком в предрелизную ветку(и, нет, это не НИИ, а "стильно-модно-молодёжно-геймдев" такое учудить может, причём на каждый релиз). Автоматизация сравнивалок и VCS хорошо помогает, но далеко не со всем.
Плюс синхронизация не только кода, но и планов/статусов/людей. Вплоть до "собрать всех участников на собрание и последовательно обсуждать по частям" — увы, тоже реальная современная практика, и тоже в стильно-модно-молодёжно случается.
Замечательно. То есть, усилить конкретную группу людьми в таком случае нельзя, если "5 Developers" фиксированно. Речь то, напомню, про "докинуть ещё людей в неуспевающий проект".
Значит, нужно наращивать количество команд. Или депаратаментов. Или проектов.
Если численность девелоперов не фиксирована — то можно и их нарастить.
В любом случае добавляя новые синхронизационные связи и потери на них.
«5 Developers» фиксированно
С чего Вы взяли, что это фиксированно? Это число выбрано мной как примерное оптимальное число членов команды для эффективной работы, есть немало статей про это, пример — knowledge.wharton.upenn.edu/article/is-your-team-too-big-too-small-whats-the-right-number-2.
Есть компании, которые практикуют плоскую иерархию, когда тимлид подчиняется непосредственно CTO, многое зависит от проекта. Синхронизационные связи и потери на них, конечно же есть, но они не столь велики.
но они не столь велики
Проблема то в том, что они растут в геометрической прогрессии с каждым добавленным элементом. При этом добавленные элементы не привносят производительность в том же объёме.
Если к двум разработчикам добавить третьего — да, хорошие шансы успеть раньше. Если к 20 докинуть 10(на те же 50%) — нет.
Со всеми — нет. Со всеми с кем работа пересекается — нужно, точнее, неизбежно.
Если новички вообще по работе не пересекаются ни с кем — отлично, они возможно не сильно замедлят общую работу. Если ими заткнули неохваченное ещё направление(то есть над "вот этой обязательной к релизу задачей" ещё никто вообще не работал, и она ни одну другую команду не затрагивает совсем), например, то это может помочь. И то, возможно добавление в очередь общей интеграции; и точно затронет синхронизацию уровней выше себя.
Но если все направления имеющимся составом уже охвачены — то новички неизбежно будут пересекаться с уже идущими работами. И их задевать, а это значит — пересекаться, общаться, синхронизироваться, требовать тестирования и интеграции, да и после интеграции добавлять веселья всем остальным.
«Гениально», т.е. мы не успеваем — вместо «докинуть ещё разрабов в команду» — давайте «сделаем ещё одну команду». А в терминальном случае ещё и уровней иерархии добавим.
Вам не кажется, что это шило на мыло и в общем случае не спасёт? Тем более, когда работа не может быть распараллелена? А это именно так. 2 команды не сделают один модуль быстрее в два раза быстрее, более вероятно, что они за тот же срок смогут сделать два модуль по отдельности с исходным качеством.
Я говорю про сложные проекты, я говорю про кровавый.
По большому счету ничего кардинально не поменялось…
Я вот прорывных методов в аналитике не вижу…
Мифический человеко-месяц 45 лет спустя