Чему медицина может научить нас в укомплектовании наших веб-команд
Адам Смит открыл Богатство народов, объяснив, как булавочная фабрика была бы более эффективной, если бы каждый рабочий выполнял единственную функцию в производственном процессе. Предоставляя работникам целенаправленные задачи, работники будут быстрее развивать сфокусированный опыт, что приведет к более быстрому и менее подверженному ошибкам производству.
В разработке программного обеспечения специализация лежит в основе таких понятий, как Принцип единой ответственности, инкапсуляция и абстракция. Ценность этих концепций широко признается профессионалами. Они приводят к более быстрой разработке не только за счет повышения гибкости кода, но и за счет сокращения умственных затрат и позволяя разработчику сосредоточиться только на одной части системы за раз. Тем не менее, когда дело доходит до их собственных командных ролей, веб-разработчики в scrum-командах испытывают трудности с пониманием того, как и следует ли применять эту концепцию.
В веб-разработке существуют роли специалистов, распространенными примерами которых являются операции, интерфейс и серверная часть. Однако разработчики полного стека в настоящее время составляют большую часть отрасли. Недавний опрос Stack Overflow показывает, что 63% всех разработчиков считают себя полноправными разработчиками. Между тем, по мере того, как сам стек продолжает усложняться, с такими тенденциями, как CI / CD и PWA, часто требующие изучения собственных мини-стеков, никогда раньше обязанности инженера полного стека не были так многочисленны. Учитывая, что веб-разработка как профессия существует всего 30 лет, а scrum еще моложе, мы должны обратиться к более старой профессии, которая решает сложные проблемы с помощью кросс-функциональных команд, чтобы определить, является ли сильная зависимость от разработчиков полного стека. правильный подход: медицина.
Специализация - относительно недавнее явление в медицине. На протяжении большей части истории врачи работали в одиночку или в небольших клиниках, которые обслуживали одну общину и, следовательно, должны были иметь возможность решать широкий спектр медицинских проблем на регулярной основе. Они были «полным стеком» по необходимости. Но создание более крупных больниц означало, что врачи могли свободно углублять свои медицинские знания в определенной области, а расширение транспортной инфраструктуры позволяло пациентам искать экспертов в их условиях.
Другими словами, специалисты снова и снова сталкиваются с одними и теми же проблемами, что позволяет им определять передовой опыт и продвигать область исследования. Существует также очевидное преимущество, заключающееся в том, что специалист может выполнять специализированную задачу намного быстрее и чище, чем универсал.
Дженералисты существуют как в медицинских, так и в гибких командах, но спектр выполняемой ими работы принципиально различается. Ожидается, что врачи первичного звена будут выполнять рутинную работу, но перекладывать любую другую работу на специалиста. Если вы пойдете к терапевту с онкологическим заболеванием, он не станет вдаваться в подробности, чтобы узнать подробности и способы проведения вашей химиотерапии. Ожидается, что он будет иметь общие сведения о вариантах лечения, а затем направит вас к онкологу. Напротив, ожидается, что типичный разработчик полного стека решит любую поставленную перед ним задачу. Она могла бы выполнять простой CSS - высокоуровневую интерфейсную задачу - одну минуту и оптимизировать размер пакета Webpack - низкоуровневую интерфейсную задачу - следующую. Затем она переключится на создание нового маршрута для API, а затем попытается сократить время выполнения заказа на конвейер CI / CD. Если разработчик не знает, как выполнить одну из этих задач, ему необходимо выучить ее, даже если он не будет применять эти знания снова в течение нескольких месяцев (к этому моменту он уже разучился выполнять задачу).
Чтобы получить представление о некоторых проблемах, которые возникают в больших командах, состоящих только из инженеров полного цикла, я опросил некоторых разработчиков по этой теме и обнаружил, что следующие проблемы являются общими:
- Моральный дух людей, которые не могут работать в тех проблемных областях, которые им нравятся, обычно низок. Вы часто будете видеть, как разработчик, которому нравится работать над внешним интерфейсом, выполняет внутреннюю работу, сидит рядом с разработчиком, ориентированным на серверную часть, пишущим CSS - и все это в попытке сохранить свои навыки.
- Лучшие практики развиваются медленно, ошибки часто повторяются, а решения принимаются с небольшим опытом в целевой области. Поскольку ни один разработчик не работает над одним и тем же проблемным пространством слишком долго, ни один разработчик не может легко размышлять, судить, устанавливать связи и обобщать, что означает, что уроки усваиваются медленно.
- Скорость развития непостоянна и часто случайна. Иногда звезды совпадают, и все разработчики получают задачу, с которой они знакомы, что обеспечивает плавный спринт. Чаще всего это не так.
- Любое техническое решение должно быть доведено до сведения всех разработчиков, а не части разработчиков, независимо от их опыта. Попробуйте объяснить ценность Redux и запросите отзывы у разработчиков, которые использовали только шаблоны erb.
- Привлечение новых разработчиков может быть болезненным. Ожидается, что новые разработчики быстро приобретут глубокие познания в каждой части стека.
Специализация может решить все вышеперечисленные проблемы, поощряя разработчиков работать над тем, чем они увлечены, позволяя им быстрее получать целенаправленный опыт, поддерживая постоянную скорость разработки, сокращая количество людей, которые должны участвовать в принятии решения, и снижая темпы роста. время, сократив стек, который необходимо изучить новым разработчикам.
Так как же укомплектовать кадрами специалистов и универсалов и работать в гибкой команде, чтобы предотвратить перечисленные выше проблемы? В идеале типичная веб-команда должна состоять из одного или двух внешних разработчиков, одного или двух внутренних разработчиков и одного разработчика полного стека. Разработчик полного цикла мог бы расширить любую специальность, выполняя общие задачи, когда одна из них перегружена, а также обеспечивать техническую связь и координацию между специалистами, аналогично роли врача первичной медико-санитарной помощи. Наличие разнообразных ролей в вашей команде разработчиков также дает разработчикам возможность уделять больше времени тому, чем они увлечены, и меньше - темам, которые им не интересны. Мы все видели, что происходит, когда у вас есть разработчик полного стека, который презирает CSS, берется за историю стилизации. Это плохо для морального духа и неэффективного использования времени.
Разработчики полного цикла могут быть правильным выбором, когда проект небольшой, простой и ограниченный бюджет, но по мере роста проекта и повышения планки приемлемого приложения проектам необходимо будет серьезно рассмотреть вопрос о найме или обучении специалистов, или рискуют медленными выпусками и неадекватными продуктами.
