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

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

Меньше перегородок и стен между разными проектными командами и функциональными подразделениями

Обожаю слушать обсуждения дизайнеров за час до дедлайна. Это так успокаивает и помогает настроится *сарказм: off*
«кто в опенспейсе сидел тот в цирке не смеется?»
Надеюсь до управленцев таки дойдет, что не всем разработчикам удобно сидеть в окружении пяти десятков таких же разработчиков без какого либо разделения (хотя бы перегородками) и они начнут активнее практиковать работу из дома как опцию.
Объём коммуникаций растёт квадратично от количества коммуницирующих. Довольно быстро эта степенная функция перегружает мозги даже продвинутых в болтологии менеджеров, что уж говорить о нелюдимых программистах. Так что, если вам регулярно приходится общаться более чем с 5-ю людьми — вы вне зоны комфорта, более 8-ю — вы уже не в теме.
Не то чтобы квадратично, но как full mesh… Строго говоря, n * (n — 1) / 2 и числа таки да, получаются большими.
Дело вот в чем: так ли уж обязательно общаться по принципу «все со всеми»? Не обязательно. Зависит от процессов внутри проекта, от того, насколько понятна задача и еще много от чего.
n*(n-1)/2 = (n^2)/2 — n/2 ~O(n^2) Как это не квадратично?!!!
Вы правы
Спасибо очень познавательно, а главное на злобу дня.

Сто раз уже описанные принципы, которых всё равно не все и не всегда придерживаются, даже сам знаешь, где, Александр. Сколько Agile не обмазывайся, всё равно решения будут вытекать из личных качеств ответственного за них. Люди постоянно ошибаются, принимают решения сгоряча (времени нет, релиз, блаблабла) и просто тупят. Сдаётся мне, пока разработка ПО не станет наукой и не обрастёт научными теориями, никакая методология не будет гарантировать успех даже в 50% случаев. Лучшая методология — та, что сведёт человеческий фактор к минимуму. Разумеется, нельзя трактовать это (как нынче модно) как превращение разработчика в легко заменяемый винтик в механизме, и слепую "ориентированность на результат", при которой бычно лепится говнокод, а рефакторинг, тесты и т.п. отметаются, т.к. не дают гарантии результата. Не стоит забывать и про ошибку выжившего: медведи сильнее «Слухи об уме и доброте дельфинов основаны на рассказах уставших пловцов, которых они толкали к берегу, но мы лишены возможности услышать рассказ тех, кого они толкали в другую сторону». О фейлах не любят писать, не правда ли?


Немного о комментариях. Пишу их в исключительных случаях, когда кодом сказать не получается. Я считаю, что разработчик должен как можно больше тренироваться в написании кода, а не комментариев, тогда и навык будет расти соответствующий. К тому же, комментарии всегда вторичны. Если ЯП не позволяет лаконично выражать очевидные идеи, его нужно менять на лучший. В идеале разработчик должен иметь в арсенале достаточно выразительный ЯП, чтобы комментарии не понадобились никогда. Кто пишет под JVM или Android: пишите на чём-то более-менее приличном, благо выбор есть (для Android — пока только Kotlin). Писать на голой Java — всё равно, что рисовать пяткой, только со временем легче не станет.


P.P.S. Слово "коммуницировать" должно умереть.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий