Я работаю в этой софтверной компании, и до сих пор у меня было только два менеджера, но оба рассматривают работу программиста как не слишком отличающуюся от кладки кирпичей. Они всегда подчеркивали, что мы должны выполнять работу друг друга в любое время.
В результате наш код имеет «групповую собственность» — никто ничем не владеет, и никто ни за что не отвечает. Или, другими словами, всем принадлежит все, и каждый за все отвечает. Если что-то сломается, любой может быть отправлен тушить пожар, независимо от того, кто создал проблему. Если вы откроете код, он будет довольно хаотичным, потому что разные люди по-разному делают что-то. Более того, исправление чужого кода, не тратя много времени на его понимание, быстро заканчивается появлением патчей за патчами. Это никогда не беспокоит наших начальников, потому что они ориентированы на результат; т. е. они никогда не утруждают себя просмотром чего-либо на уровне кода.
Кто-то может не поверить, но это абсолютная правда, и мы чисто софтверная компания!
У них есть оправдание тому, что когда каждый за все отвечает, когда кто-то берет отпуск, другие могут/должны просто поменяться местами и прикрыть его/ее, чтобы он/она мог наслаждаться отпуском в любое время. Однажды парень больше месяца готовился к новому модулю, потом взял отпуск и прямо перед отъездом сказал нашему начальнику, что все вопросы улажены, и можно приступать к кодированию. Итак, на схватке на следующий день мой босс сказал мне, что мы должны сделать это на следующей неделе, не могли бы вы забрать это, пожалуйста?
Я просто не мог поверить в то, что услышал, этот парень готовил его больше месяца, но никогда не делился своими выводами с кем-либо еще, и теперь мой босс хочет, чтобы я забрал его, ни с того ни с сего, без предварительного уведомления. , и закончить его в течение недели.
Я не могу вспомнить подробности, но мне посчастливилось найти некоторые логические причины/оправдания, чтобы уклониться от смертельной пули. Он не считает, что перенимать чужую работу на полпути — это самое болезненное для программиста.
Это обычное дело для софтверных компаний? Как бы вы предложили мне сообщить плохие новости этим (невежественным) парням, что программирование сильно отличается от кладки кирпичей, не смутившись, а также убедив их, потому что они оба твердо убеждены, что каждый должен нести ответственность за все?
Я бы сказал им, что они правы, так как же мы собираемся достичь этой цели на практике?
В принципе, это похвальная и достижимая цель. Давайте посмотрим на особенности:
Если каждый разработчик работает изолированно на своем собственном маленьком острове со своим собственным стилем и независимо делает свой собственный выбор, это прямой путь к катастрофе. Как их работа будет интегрироваться с работой других? А если они заболели или в отпуске? Что, если, не дай бог, они попадут в аварию и не смогут работать или даже умрут? Если он единственный человек, который знает, как работает его код, и его коллегам требуется значительное время, чтобы понять работу этого человека, это угрожает преемственности компании! (Иногда это называют фактором автобуса ) .
При этом у каждого разработчика есть свой набор навыков и специализаций. Не все будут одинаково хорошо разбираться во всем, и это нормально! Вот почему вы, в конце концов, работаете вместе как команда для достижения общей цели.
Так что же нужно сделать, чтобы добиться работоспособной ситуации?
Во-первых, команда должна собраться вместе и либо выбрать набор руководств по кодированию для принятия, либо составить свой собственный набор. Это устраняет фактор «хаоса» в коде: поскольку все будут делать что-то одинаково, коллегам-программистам должно быть намного легче понять, как все работает.
Во-вторых, необходимо создать систему, обеспечивающую возможность обмена знаниями. Если предполагается, что все ваше время будет потрачено на написание кода, то нет времени делиться знаниями, поэтому проблема остается. У программистов должно быть время либо для документирования своего кода, либо для активного обмена знаниями с другими, а в идеале и того, и другого . Следует также установить руководящие принципы для документирования кода, чтобы предотвратить потенциальные проблемы, которые могут возникнуть из-за неполной или недостаточной документации. В то время как эксперт может понять функцию с помощью нескольких коротких строк, тому, кто не работает с этой функцией регулярно, потребуется немного больше информации, чтобы освоиться. В документации должно быть достаточно информации для второго случая.
В идеале, этот обмен знаниями поддерживается регулярными обзорами работы друг друга. Это дает рецензенту возможность улучшить свои знания кода и в то же время помогает вашей команде повысить общее качество кода, поскольку дополнительная пара глаз поможет выявить возможные ошибки. Это также помогает команде лучше понять общее качество продукта. Если многие вещи должны быть решены «хакерским» способом, то, очевидно, качество продукта будет намного ниже, чем если бы те же проблемы можно было решить с помощью красивого чистого кода.
Чтобы украсть аналогию с парикмахером, в идеале все парикмахеры (программисты) смогут закончить работу друг друга, потому что:
все они используют один и тот же набор причесок
все они режут методами и инструментами, которые либо одинаковы, либо, по крайней мере, эквивалентны
они документируют свой прогресс в стрижке, используя согласованную систему, отмечая, что они сделали, как они это сделали и почему они сделали это именно так
они регулярно уделяют немного времени обзору работы друг друга, что помогает им ознакомиться с ней
Чтобы рассмотреть «отношение» ОП к проблеме, вполне может быть, что на самом деле, со временем, которое есть у программистов (из-за сроков и ожиданий того, как их время тратится) и узкоспециализированного характера работы каждого программиста, это цель недостижима на практике. В любом случае гораздо проще помочь вашим менеджерам самим понять, почему цель недостижима, чем заявить, что это так, а затем защищать ее. Поэтому, если кто-то предлагает что-то, в чем вы видите серьезные проблемы, постарайтесь ответить конструктивно, например : «Конечно, но как мы собираемся решать X, Y и Z?» вместо того, чтобы отвечать отрицательным ответом, т.е. «Это никогда не сработает из-за X, Y и Z!». Это помогает руководству воспринимать вас в более позитивном свете и, в конечном итоге, может создать лучшую и более приятную рабочую среду.
Если достижение цели А означает затрату большого количества времени, усилий или денег на решение проблем X, Y и Z, то это может не стоить усилий, но это решение должно принять руководство, поэтому наша работа как сотрудников состоит в том, чтобы предоставить предоставить им необходимую информацию для принятия обоснованного решения.
Коллективное владение кодом — это вещь в Agile-разработке , и обычно это считается хорошей вещью. Но похоже, что ваши начальники просто взяли из agile-манифеста одну понравившуюся им вещь, которая им подходит, и проигнорировали все остальные.
Чтобы это работало, вам нужна команда, которая тесно работает вместе и часто общается. Большинство задач нужно решать парным программированием, обзоры кода должны быть общими и ранними, должна быть высокая степень тестов, чтобы внушать уверенность в качестве, желательно разрабатывать с помощью разработки через тестирование и т.д. и т.п.
То, что существует общий стандарт кода, — это даже не вопрос гибкости, это просто здравый смысл.
Я думаю, что проблема в вас, а не в ваших менеджерах.
разные люди по-разному делают что-то
Вам нужно прекратить это прямо сейчас, установить стандарты кодирования, начать работать с дизайном и стать взаимозаменяемым.
Когда один из моих коллег уходит в отпуск, мы получаем документ о том, над чем он работает, каков прогресс, какие есть нерешенные вопросы и, самое главное, где находится документация.
Я думаю, что суть проблемы в том, что вы должны начать больше работать в команде.
И если вы не можете попасть туда как коллеги, это должно сделать руководство, им за это платят.
¨I think the heart of the problem is that you should start working more as a team."Понимаете, это проблема управления. Суть этой проблемы в том, что, если все так, как описано, это может быть одна из тех компаний, которые избавляются от менеджеров, потому что эти ребята не выполняют свою работу.Коллективное владение кодом, при котором каждый программист может одинаково хорошо работать над каждой частью программного обеспечения, является идеалом , к которому следует стремиться (потому что преимущества реальны), но для его достижения требуется тяжелая работа.
Команде необходимо внедрить один стиль программирования, чтобы код сразу всем узнавался. Команде необходимо проводить строгие проверки кода, чтобы знание фрагмента кода распространялось сразу же после его написания и чтобы был обеспечен общий стандарт качества. Вам нужно использовать «определение выполненного», которое гарантирует, что ничто не будет называться «готовым», пока оно не будет задокументировано, протестировано и проверено. Новым членам команды необходимо время и обучение, чтобы освоить все используемые технологии.
Если менеджеры требуют результатов такого процесса, не инвестируя сначала в его реализацию, они нереалистичны.
Я думаю, вам следует обсудить со своими коллегами, какие изменения вы хотели бы внести в свой рабочий процесс, чтобы сделать его более возможным, например, начать с проверки кода или парного программирования или согласовать общий стиль кодирования.
Затем подойдите к своим менеджерам и скажите что-то вроде
Я знаю, вы хотели бы, чтобы всех программистов можно было заменять, чтобы мы все могли работать над любой проблемой, которая может возникнуть. Тем не менее, мы еще не достигли этого — все мы на самом деле знаем только часть кодовой базы, и нам трудно адаптироваться к тому, как работают другие люди. Тем не менее, мы считаем, что это хорошая идея, и мы предлагаем реализовать X и Y, чтобы начать работать над достижением этой цели.
Мне кажется, что разработчики и менеджеры заняли крайне противоположные позиции в спектре от индивидуального владения кодом до совместной ответственности.
Разработчики могли бы сделать больше, чтобы приблизиться к идеалу менеджеров:
Возможно, вы не сможете достичь максимальной гибкости, которую хотят менеджеры, но вы должны быть в состоянии выйти далеко за рамки одного человека, который может работать над каждым фрагментом кода. Иногда вам может понадобиться сказать им: «Джо или Нэнси могли бы сделать это быстрее», и пусть они решают, платить ли за это кому-то другому.
httpResponseDataа не data, например, ) и тесты (рабочие и простые), а не документацию. Последнее субъективно и гарантированно будет неполным (иначе это был бы код).Краткий ответ: Укажите, насколько это нелепо.
Я действительно сталкивался с этим раньше, и я просто сказал что-то вроде:
Пошли бы вы к ортопеду, если бы вам потребовалась операция на головном мозге? Они оба врачи, да?!
Или же
Вы идете к портному, чтобы подстричься, потому что портные используют ножницы так же, как парикмахеры?
Затем укажите, что существуют очень разные наборы навыков, связанных с каждой специализацией. Скажите им, что программирование такое же. Некоторые разработчики хорошо разбираются в одной области, но совершенно не разбираются в другой.
Это не говорит о том, что вы не можете освоить другие навыки, но это потребует времени и желания.
Вы написали,
никто ничем не владеет, и никто ни за что не отвечает. Или, другими словами, всем принадлежит все, и каждый за все отвечает.
Это две крайности (возможно, вам следует искать золотую середину между двумя крайностями) и ложная дихотомия.
Это обычное дело для софтверной компании?
В зависимости от количества программистов существуют различные возможности.
Один из них — назначить команду (из нескольких человек) для каждого компонента. Ожидайте, что любой/каждый в команде будет нести ответственность (при необходимости) за (что-либо внутри) всего компонента. Команда может иметь или не иметь одного главного разработчика или руководителя группы, который может быть или не быть официальным контактным лицом команды между внешним миром (руководством и QA).
Минимум, который я рекомендую, — это проверка кода. Каждый человек отвечает за свою собственную разработку, и требуется несколько дней, чтобы закодировать какую-то новую функцию, а затем один или несколько других людей тратят часы на просмотр того, что было завершено, протестировано и проверено. ожидать (руководством) понимания того, что они рассмотрели. Например, обзорный комментарий (до того, как они примут или «подпишут» изменение) может быть таким: «Я этого не понимаю, вам лучше немного переработать и/или объяснить лучше» или «Что это значит? сделать, какую функцию (например, видимую в функциональной спецификации), которую он реализует, где автоматизированный функциональный регрессионный тест, который это проверит»).
После того, как (если) они подпишут изменение, менеджер может подойти и сказать: «Смотрите, Боб в отпуске и/или уволился из компании; мы думаем, что есть проблема с этим модулем, который вы просмотрели, и/или мы хотите добавить к нему новую функцию. Не могли бы вы взглянуть на нее? Вы уже знакомы с ней (не говоря уже о том, что несете за нее ответственность), так как вы проводили обзоры кода, когда она была реализована».
Проверка кода имеет множество целей, в том числе:
Однажды парень больше месяца готовился к новому модулю, потом взял отпуск и прямо перед отъездом сказал нашему шефу, что все вопросы улажены, и можно приступать к кодированию. Итак, на схватке на следующий день мой босс сказал мне, что мы должны сделать это на следующей неделе, не могли бы вы забрать его, пожалуйста?
Вот вам менеджер, который выронил мозг.
Да, у каждого разработчика должен быть по крайней мере еще один человек, с которым он тесно работает (парное программирование и т.п.) над каждой отдельной задачей (включая проработку дизайна нового модуля), который, таким образом, должен быть в состоянии взять на себя ответственность без чрезмерного повторная работа в любой момент.
Но это не то же самое, что сказать, что переключение в процессе выполнения не требует дополнительных затрат:
они должны быть примерно такими же, а в идеале чуть меньше, как если бы первоначальный разработчик бросил эту задачу, не улаживая незаконченные концы, чтобы справиться с какой-то чрезвычайной ситуацией, а затем пришлось снова наращивать нагрузку после недели работы над чем-то другим.
Теперь, если вы не тот, с кем он работал над этой задачей, у вас есть только его заметки, и какими бы хорошими они ни были (что, вероятно, не звездно, или учитывая ваше описание, скорее похожее на очень фрагментарное или несуществующее), они просто не может охватить все детали, которые ваш коллега проработал за этот месяц.
Это все равно, что пойти в больницу и потратить время на то, чтобы один врач тщательно оценил ваше состояние в течение месяца с повторными осмотрами, образцами крови, ЭКГ, рентгенографией и всем, что кажется полезным, а затем пойти к хирургу, чтобы вылечить вас немедленно, никогда позволив им сообщить что-нибудь полезное.
Если вы не тот, с кем он работал, вы должны указать, кто из коллег работал, а также предупредить, что, хотя ему было бы гораздо легче взять на себя управление, чем вам, это все равно сопряжено со значительными затратами, как и он. т тот, кто сам занимается подготовкой .
Если нет никого, кто был бы близко знаком с этой подготовкой, вы должны упомянуть, что она должна была быть и (в зависимости от того, как было задокументировано исследование), что вам может понадобиться где-то от x% (ваше лучшее предположение относительно документации и то, что вы подслушали) к полному времени запуска с нуля.
В конце концов, это похоже на провал руководства:
тимлид должен собраться вместе с другими разработчиками и выработать стандарт кодирования, а также начать заниматься парным программированием, модульным тестированием, проверками кода. и все остальные мероприятия по обеспечению качества и распространению знаний в команде.
Это обычное дело? Не так много. Но его можно настроить на работу.
Идея заключается в том, чтобы избегать людей как единой точки отказа . Конечно, за это приходится платить, и программисты платят за это. Вот почему вашего босса будет трудно убедить, что это плохая идея. У него все достоинства, а у вас все недостатки. Тем не менее, это имеет смысл.
Имеет смысл проводить время с другими программистами для обмена знаниями и практикой. Это можно сделать с помощью обзоров, парного программирования или чего-то еще, что вам подходит. Я был в команде из 22 человек, где один консультант (там уже много лет) проводил большую часть своего времени, бродя по коридорам, вместо того, чтобы программировать. Он был связующим звеном в команде, и по крайней мере 15 человек в команде могли работать над программами, которые я делал. Это может быть все, что угодно, неформальные беседы, обмен знаниями за кофемашиной...
Но это имеет свою цену. Платить ИМХО стоит, но если все работают по одной технологии, то не слишком дорого. Стоимость - большие накладные расходы на связь. Это больше, чем вы должны сообщить своему боссу, так как его идея неплоха сама по себе. Просто он должен понимать, что это инвестиции с немедленным вознаграждением.
У них есть оправдание тому, что, когда каждый за все отвечает, когда кто-то берет отпуск, другие могут/должны просто поменяться местами и прикрыть его/ее, чтобы он/она мог наслаждаться отпуском в любое время.
Я знаю одну компанию ( Menlo Innovations ), которая меняет «всех» вокруг «каждого» проекта по установленному графику. Есть способ заставить это работать.
Руководство поставило перед собой такую цель, но полностью сняло с себя ответственность делать все необходимое для того, чтобы это работало. Необходимо будет нанять больше людей, а также увеличить сроки доставки. Они могут оправдать это демонстрацией долгосрочных результатов и не быть заложниками какого-то гуру, который думает, что он единственный человек на планете, способный кодировать его конкретный проект.
Настоящая проблема заключается в попытке реализовать некоторую практику в изоляции. Они должны были рассмотреть дополнительные методы, такие как: командная разработка, тестирование, более обширная документация, ежедневные встречи, чтобы поделиться и ознакомить всех с тем, что делают другие.
editссылка отключена. Компания Menlo Innovations, а адрес — menloinnovations.com.Я думаю, что следующий вывод является взвешенным, но, к сожалению, кому-то просто не нравится его слышать. Я получил неоднократные просьбы удалить их. В демократическом мире каждый голос заслуживает того, чтобы его услышали. Одно дело тебе не нравится это слышать, а другое дело пытаться заставить меня замолчать, что, по моему мнению, не очень хорошо. Итак, вот он снова, мой вывод, убитый из моего ОП.
Вывод
Я думаю, что нам пора прекратить дискуссию и двигаться дальше. После тщательного изучения я выбрал в качестве ответа один «конструктивный ответ, предлагающий конструктивное решение» . Но на самом деле все ответы очень хороши, хотелось бы выбрать более одного ответа.
Из ответов я понял, что это довольно спорная тема, которая открывает мне глаза, потому что до этого я думал, что мои начальники невежественны. Теперь я понимаю, что раньше был невеждой.
Как выразилась Патрисия Шанахан, «разработчики и менеджеры заняли крайне противоположные позиции в спектре от индивидуального владения кодом до совместной ответственности» , и я могу четко сказать, какие ответы/комментарии исходят от менеджеров:
Перед тем, как сделать такой вывод, еще раз учтите тот факт, что этот парень готовил ее больше месяца, но так и не поделился своей находкой с кем-либо еще, и теперь мой ПМ хочет, чтобы я взял ее без предварительного уведомления и закончил ее. в течение недели . И тем более, что для подачи заявления на отпуск нам нужен как минимум месяц, а чаще мы подаем его за два-три месяца до отпуска. Исходя из этого, я считаю, что все будут знать, где на самом деле проблема. Я полностью согласен с TripeHound,
Вероятно, более важным, чем «Команда должна…», является «Руководство должно разрешить команде…» и признать, что производительность при этом сильно пострадает.
Признавайте это или нет, реальная проблема была указана gazzz0x2z: «Это имеет свою цену, и программисты платят цену. Вот почему вашего босса будет трудно убедить, что это плохая идея. У него есть все преимущества, а вы все недостатки» , и я лично согласен с Ремко Герлихом: «Если менеджеры требуют результатов такого процесса, не инвестируя сначала в его реализацию, они нереалистичны» , потому что, в конце концов, как выразился no comprende, «требуется время, чтобы заново понять даже свой собственный код после того, как не видел его какое-то время, поэтому, безусловно, потребуется время, чтобы понять чужой.И вы можете только так много упаковать в свою голову: изучение чужих вещей не задержится надолго.Существует практический предел разделения ответственности за код» ,«Было бы хорошо, если бы вся управленческая команда также могла поменяться местами» .
Хорошо, я знаю, что зашел слишком далеко, и большинство менеджеров могут со мной не согласиться. Итак, подчеркну, это мои личные взгляды, и давайте закончим дискуссию и двинемся дальше. Это также основная причина, по которой я выбираю один «конструктивный ответ, предлагающий конструктивное решение» в качестве ответа — менеджеры и разработчики должны лучше понимать друг друга, и чаще всего именно менеджеры должны лучше понимать разработчиков. С таким пониманием и конструктивным решением мы будем там, просто это не произойдет в одночасье.
Я работаю в этой софтверной компании, и забавно то, что пока у меня было только два менеджера, но оба эти менеджера рассматривают работу по программированию не сильно иначе, чем кладку кирпичей. Они всегда подчеркивали, что вы, ребята, должны браться за работу друг друга в любое время.
Это совершенно нелепая идея. Программирование — это узкоспециализированная область, и разные аспекты программирования требуют совершенно разных навыков. Лучшее, что вы можете сделать, это указать им на это. Хотя аналогии с другими профессиями могут быть уместными и уместными (портной, стрижка волос и т. д.), ваше начальство может им не поверить, поэтому укажите на некоторые существенные различия в программировании, например, насколько дизайн пользовательского интерфейса отличается от тестирования производительности, например.
Но да, вы определенно должны попытаться развеять это мнение у своих менеджеров, чтобы они не испытали очень резкого пробуждения, когда узнают, насколько они неправы.
Вы можете стандартизировать соглашения о написании кода, инструменты, папки и способ работы. Но вы не можете сделать его равным знаниям о некоторых запутанных функциях и о том, как работают некоторые части кода. Это принадлежит только тем, кто часами думает об этом. Объясните своим начальникам, что это вовсе не кладка кирпичей, мне приходилось иметь дело с такими невежественными начальниками, они из строительной отрасли и пытаются использовать те же стандарты в индустрии программного обеспечения, я не могу вам объяснить, что это приводит к большим бедствиям, провальные проекты и высокая текучка действительно хороших разработчиков. Объясните им это. Каждая часть работает по-своему и соответствует бизнес-требованиям. Например, у вас есть «кирпич», который может выполнять одну операцию «плюс», другую операцию «минус» и операцию деления, когда-нибудь один парень попросит вычисление производной или матричной функции, вы можете сравнить такой «кирпич» с предыдущим? У парня, который запрограммировал новое матричное исчисление, есть время поделиться своими знаниями и в то же время остаться в расписании? Я так не думаю.
край