SP_>А вот строчек от 500 — ет уже спагетти в которые смотреть страшно
Спагетти возникают в двух случаях:
— грязное кодирование с самого начала, тут только гильотина поможет, ну или HR политика вообще
— очень большое давление поступающих непредсказуемых требований с жесткими срока, которые реализуются быстрым ляпаньем.
Вот спагетти второго типа покрывает только небольшие куски кода, хотя и противно.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[7]: Разработка при ограниченном человекоресурсе.
Здравствуйте, Maxim S. Shatskih, Вы писали:
AJD>>Только коллектив это не значит что вся компания обсуждает. MSS>Дурацкие растраты времени.
Зачем же переносить свой негативный опыт на других?
MSS>По-другому. Каждым куском кода владеет персонально один девелопер. Это владение переменно со временем с периодом порядка 1-2 лет, как я слышал.
И что происходит если человек заболел/в отпуске/уволился?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[9]: Разработка при ограниченном человекоресурсе.
Здравствуйте, Maxim S. Shatskih, Вы писали:
AJD>>Большинство опечаток находится компилятором. Опечатки типа испозование ++i вместо i++ в большинстве случаев абсолютно не принципиальные и не ломают логику софта.
MSS>Совершенно неверно. Запросто может возникнуть ошибка, да еще трудновоспроизводимая и тяжелая в поиске.
Такая ошибка достаточно просто и стабильно воспроизводится и с большой степенью вероятности будет обнаружена еще на этапе юнит тестирования. А вот прокол в бизнес логике, когда не был учтен какой-то специфический usecase и который воспроизводится только на продакшен системе во время полнолуния — вот это, ИМО, тяжелая ошибка.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[8]: Разработка при ограниченном человекоресурсе.
AJD>>>Только коллектив это не значит что вся компания обсуждает. MSS>>Дурацкие растраты времени. AJD>Зачем же переносить свой негативный опыт на других?
Это не свой негативный опыт, а объективная реальность и законы физики. Посчитайте в человеко-часах, сколько времени займут эти дурацкие митинги. Длительность митинга минимум полчаса. Умножьте на числе участников. За это время можно было исправить несколько багов и написать ощутимый объем кода.
Тимбилдинг есть идиотизм. Причина его возникновения — комплексы и заморочки "верхнего" руководства, которое желает ощутить себя то ли крутым павианообразным доминантом, то ли мега-новатором, то ли что-нить в таком духе. Т.е. он нужен не для достижения целей бизнеса, а для чесания личных приятных мест в психике руководителя.
Если речь идет об _эффективности решения поставленной жизнью задачи_ — тимбилдинг не нужен.
Ну вот, например, такой факт бытия: текучесть кадров есть объективная реальность. Ну и смысл "тимбилдовать" человека, если он уже изначально точно знает, что данное место работы ему как одна из ступенек?
MSS>>По-другому. Каждым куском кода владеет персонально один девелопер. Это владение переменно со временем с периодом порядка 1-2 лет, как я слышал. AJD>И что происходит если человек заболел/в отпуске/уволился?
Если уволился или заболел надолго — овнера можно сменить. В отпуске — можно подождать, крайне мало критичных багов, которые надо править немедленно, а в этой ситуации можно и соседу дать разобраться с багой. Все остальные вещи, кроме критичных багов, точно ждут.
Потеря времени? на тимбилдинг и полусектантские митинги теряется больше.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[9]: Разработка при ограниченном человекоресурсе.
Если ПМ не технический, а больше административный, то тиммитинг как раз и позволяет
быстро собрать список открытых вопросов по проекту, чтобы составить общее жизненное состояние проекта.
Также можно сразу решить общие задачи по проекту и ответить на общие вопросы.
ИМХО нельзя так однозначно говорить о том, что митинги нужны или не нужны.
Re[9]: Разработка при ограниченном человекоресурсе.
Здравствуйте, Maxim S. Shatskih, Вы писали:
AJD>>Зачем же переносить свой негативный опыт на других? MSS>Это не свой негативный опыт,
Наблюдаемый мною реал говорит вот о чем: сам факт перехода разработки с единоличного уровня на командный сразу создает огромный оверхед. Оверхед на общение внутри команды. Девелоперы начинают вместо продумывания, кодирования и отладки делать упор на общение между собой.
MSS>а объективная реальность и законы физики. Посчитайте в человеко-часах, сколько времени займут эти дурацкие митинги. Длительность митинга минимум полчаса. Умножьте на числе участников. За это время можно было исправить несколько багов и написать ощутимый объем кода.
Если митинг делать ради митинга на котором все спят — то это да, безусловно, трата времени. А если это брэйншторм то и результат другой.
MSS>Ну вот, например, такой факт бытия: текучесть кадров есть объективная реальность. Ну и смысл "тимбилдовать" человека, если он уже изначально точно знает, что данное место работы ему как одна из ступенек?
Значит именно в этой компании тимбилдинг не имеет смысла
MSS>крайне мало критичных багов, которые надо править немедленно, а в этой ситуации можно и соседу дать разобраться с багой.
Чем дать "соседу" разбираться отличается от совместного владения кодом несколькими людьми?
MSS>Потеря времени? на тимбилдинг и полусектантские митинги теряется больше.
Нет, опрделенно у тебя был только негативный опыт.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[10]: Разработка при ограниченном человекоресурсе.
AJD>Если митинг делать ради митинга на котором все спят — то это да, безусловно, трата времени. А если это брэйншторм то и результат другой.
Мало задач, заслуживающих брейншторма. Очень мало. Применение же брейншторма для простой задачи — это тот же дурацкий митинг, на котором половине народу все очевидно с самого начала (причем более толковой половине), и они там зевают и спят, а их время потрачено.
Простая задача — это задача, решение которой очевидно одному отдельно взятому специалисту, пусть и толковому.
Да, кстати, напомню такую вещь: интеллект коллектива не есть сумма интеллектов отдельных его участников, и не есть даже их среднее. Он всегда НИЖЕ среднего интеллекта участников. См. Густава ле Бона и его классический труд о психологии толпы.
Еще напомню такую вещь: творчество всегда индивидуально. Удачное соавторство, вроде Олдей или Стругацких — редкость. См. классические работы Айн Ранд.
AJD>Значит именно в этой компании тимбилдинг не имеет смысла
А где он вообще имеет смысл? в командах из десятка слабых специалистов, каждый из которых в одиночку теряется, столкнувшись с обычной рутинной задачей?
AJD>Чем дать "соседу" разбираться отличается от совместного владения кодом несколькими людьми?
Тем, что вне форсмажорных ситуаций "соседа" не отвлекают на чужой код, у него свой есть.
AJD>Нет, опрделенно у тебя был только негативный опыт.
А в чем здесь может быть позитивный опыт? действительно не понимаю.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[11]: Разработка при ограниченном человекоресурсе.
Здравствуйте, Maxim S. Shatskih, Вы писали:
AJD>>Если митинг делать ради митинга на котором все спят — то это да, безусловно, трата времени. А если это брэйншторм то и результат другой.
MSS>Мало задач, заслуживающих брейншторма. Очень мало.
Очень согласен, более того большая их часть лежит не в области разработки ПО.
Брейншторминг имеет смысл в творческих, креативных областях, где многое зависит не столько от опыта, сколько от вдохновения и случайности я бы даже сказал. Когда даже начинающий может родить идею достойную обсуждения.
В программинге все горахдо прозаичнее. Если затык у сильного специалиста, то собирать толпу новичков для обсуждения смысла нет — они тем более не помогут в решении проблемы. Если затык у новичка — то собирать кучу более опятных специалистов негуманно, лучше решить проблемы один на один со специалистом в данной области. Да и вообще, в разрабоке ПО, где специализация сильно развита с проблемными моментами лучше обращаться непосредственно к спецам в нужной области, а не собирать весь отдел и не ждать, пока те кто вообще не в курсе въедут в проблему.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[10]: Разработка при ограниченном человекоресурсе.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Если ПМ не технический, а больше административный, то тиммитинг как раз и позволяет N_C>быстро собрать список открытых вопросов по проекту, чтобы составить общее жизненное состояние проекта.
Административный ПМ может обойти всех сотрудников и выяснить статус интересующих его работ. Если ему не позволяет гордость — можно поодному вызвать их для этого к себе в кабинет. Для него это займет ровно столько же времени, а для остальных сотрудников в N раз меньше (где N — кол-во сотрудников).
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[11]: Разработка при ограниченном человекоресурсе.
DAS> Административный ПМ может обойти всех сотрудников и выяснить статус интересующих его работ. Если ему не позволяет гордость — можно поодному вызвать их для этого к себе в кабинет. Для него это займет ровно столько же времени, а для остальных сотрудников в N раз меньше (где N — кол-во сотрудников).
Ну, иногда, чтобы команда не чувствовала, что она работает просто над списком несвязанных задачек это просто необходимо...
Оговорюсь сразу, я имею ввиду малые команды (3-5 человек). При большем количестве такие собрания конечно неэффективны.
Re[11]: Разработка при ограниченном человекоресурсе.
N_C>Ну, иногда, чтобы команда не чувствовала, что она работает просто над списком несвязанных задачек это просто необходимо...
Какая разница, кто что чувствует. Главное, чтоб не ненависть к работе и начальству, остальное — пофиг.
Ни один из моих работодателей с 93 года не страдал такой фигней, как детальная разжевка одному исполнителю нюансов компонента, над которым работают другие. Причина проста: дурацкая потеря времени, в первую очередь исполнителем (у начальника времени больше).
Надо будет стыковать компоненты? тогда по одному человеку от каждой группы встречаются и обсуждают интерфейс, главный критерий обсуждения — как проще, чтобы не переделывать всерьез то и другое.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[12]: Разработка при ограниченном человекоресурсе.
MSS>>Мало задач, заслуживающих брейншторма. Очень мало.
DAS> Очень согласен, более того большая их часть лежит не в области разработки ПО. DAS> Брейншторминг имеет смысл в творческих, креативных областях
...где одному человеку не очевидно решение сразу.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[12]: Разработка при ограниченном человекоресурсе.
Здравствуйте, Maxim S. Shatskih, Вы писали:
DAS>> Административный ПМ может обойти всех сотрудников и выяснить статус интересующих его работ. MSS>Обходить зачем? есть мейл и мессенжеры.
Не обязательно. Но если времени мало, мне бытрее устно объяснить статус задач, нежели писать письмо, особенно если руководитель в условиях прямой видимости. Если времени достаточно или процесс требует документов для истории — можно писать письма — не имею ничего против.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[13]: Разработка при ограниченном человекоресурсе.
