Наш экономичный путь выхода на рынок: практика разработчиков

Продолжение статьи Наш путь бережливого производства к рынку: ритуалы и правила

Одним из ключей к созданию и развитию отличного продукта является внедрение передовых методов работы с программным обеспечением с самого начала. Если все сделано правильно, это будет способствовать развитию экосистемы процветающих, счастливых, высококвалифицированных и разносторонних разработчиков.

В хорошей продуктовой команде разработчики не изолированы друг от друга, а являются частью основной команды и несут такую ​​же ответственность за успех продукта, как и владелец продукта, дизайнер и т. д.

Следуя методам бережливого производства и имея в своей команде высокодисциплинированных разработчиков, вы очень быстро увидите огромные преимущества продукта в виде:

  • постоянно доставляемый код — новые функции в производство как можно быстрее
  • меньше ошибок — высокая достоверность
  • Чрезвычайно быстрое развитие продукта — поворот к совершенству

Чтобы сделать это, разработчики должны быть дисциплинированы в инструментах, практиках и мышлении, в которых они работают, чтобы создать хорошо отлаженный конвейер доставки. Иногда для этого требуется эволюция в быстро меняющемся ландшафте, но важно установить исходные данные с первого дня.

Полный стек › XP › DevOps

Full-stack разработчики

Написание инфраструктуры в виде кода, то есть шаблонов AWS CloudFormation, настройка оповещения из журналов/инструмента мониторинга, когда ваше приложение находится под принуждением, создание RESTful API, внедрение нового инструмента поиска для веб-сайта, встраивание авторизации в приложение Android.

Что общего у этих вещей? В хорошо обученной команде с полным стеком это всего лишь код.

Каждый разработчик должен уметь делать любую из этих вещей. Означает ли это, что каждый должен быть звездным разработчиком и уметь делать их с первого дня? На самом деле, совсем наоборот. Это требует чуткого подхода к вашему продукту, к потребностям ваших клиентов, к тому, чтобы все неизбежно менялось и быстро адаптировалось.

У людей всегда будут свои интересы в определенных частях разработки программного обеспечения, и это хорошая вещь, которую следует использовать для принятия решающих решений. Например, Джейн любит создавать API и делать их максимально быстрыми и легкими, в то время как Джон любит пользовательский интерфейс, побеждая в каждой битве за идеальный пиксел и обеспечивая идеальный опыт. Хорошо иметь экспертов в предметной области, они увлеченно делятся знаниями.

Экстремальное программирование (XP)

Наличие разработчиков с полным стеком значительно упрощает внедрение и выполнение методологии XP.

Я не буду описывать здесь всю методологию, поэтому, пожалуйста, прочитайте XP, если вы заинтересованы, но не знакомы. Короче говоря, XP последовательно и методично практикует ряд конкретных дисциплин разработчиков, включая, помимо прочего:

  • парное программирование
  • развитие, обусловленное поведением
  • высокое тестовое покрытие
  • непрерывная поставка

Парное программирование

Парное программирование — это то место, где полноценный разработчик действительно начинает иметь смысл. Совместное знание не является общим пониманием. Мы предпочитаем сотрудничество документации.

Благодаря ежедневной ротации вы можете работать над другой частью кодовой базы на любом заданном уровне стека. Это позволяет распространять знания всей кодовой базы, устраняя узкие места и зависимости.

Находиться в состоянии постоянного просмотра кода намного эффективнее, чем открывать запрос на включение потенциально утомленным глазам без базовых знаний о реализуемой функции, исправлении или обновлении.

Как правило, решать проблему с двумя умами лучше, чем с одним. Технические обсуждения имеют первостепенное значение для хороших решений. Все мы люди, даже самые опытные разработчики могут ошибаться или принимать неправильные решения.

Одним из ключевых качеств лучших программистов является эмпатия, и фактически самый важный фактор, который мы учитываем при наборе новых членов команды.

Но мы платим двум разработчикам за одну и ту же работу?

Этот старый каштан. Парное программирование говорит о масштабном мышлении. Самый простой способ подойти к этому вопросу — предоставить одно из проведенных исследований по анализу затрат и выгод, но, честно говоря, это гораздо больше. Программное обеспечение — это продукт, а качественное программное обеспечение означает качественный продукт.

Разработка на основе поведения

В частности, разработка, основанная на поведении, представляет собой среду тестирования естественного языка, возникшую из традиционной разработки, основанной на тестировании. По сути, тесты, которые вы пишете, написаны на естественном языке и описывают, как функция продукта должна функционировать, чтобы соответствовать сценариям рассказов о владельцах продукта.

Красный › Зеленый › Рефакторинг

Написание модульных и интеграционных тестов для вашего кода сначала позволяет вам по-настоящему обдумать проблему, подробно обсудить ее и реализовать тестируемый код. Это настоящий сдвиг парадигмы, происходящий от обычного программирования, и к нему нужно привыкнуть, но в конечном итоге он сделает вас лучшим, если не более осторожным и вдумчивым разработчиком.

Еще одним преимуществом BDD является лучшее ретроспективное понимание кодовой базы. Тесты действуют как документация!

Высокое тестовое покрытие

Принцип XP для тестирования заключается в том, что оно выполняется с большим охватом кода. Наша кодовая база не соответствует 100% охвату.

Откуда вы знаете, что что-то работает?

Высокое покрытие тестами дает вам большую уверенность в том, что ваш код с высокой вероятностью будет работать в различных средах и при различных обстоятельствах. Это означает, что после внесения изменений и запуска набора тестов где-то еще в кодовой базе могут возникнуть проблемы, и они будут восстановлены.

Это приводит к гораздо меньшему количеству ошибок и большему шансу быстрее запустить код в производство.

Непрерывная доставка

Внедрение кода в производство как можно быстрее является ключом к продукту; мы хотим протестировать новые функции с нашими клиентами. Это снижает финансовый риск, позволяя нам раньше узнать, верны ли наши предположения о требованиях клиентов. Если это не так, мы не будем тратить больше времени на разработку этой конкретной функции.

Конвейер непрерывной интеграции + непрерывной доставки является необходимостью в разработке современных продуктов. Они дешевы, довольно просты в настройке и позволяют вам запустить код вскоре после внесения изменений.

DevOps

Каждый разработчик несет ответственность за каждую строку кода в производстве. Благодаря тому, как построено программное обеспечение, все разработчики могут уверенно чередовать поддержку и быть достаточно уверенными, чтобы определить, где может быть какая-либо проблема.

Наши разработчики хорошо разбираются в каждом слое; интерфейс, службы, инфраструктура и любые операционные системы, участвующие в обеспечении надежности приложений. Это делает обнаружение и исправление проблем с продуктом намного проще, чем если бы они только что работали над одним слоем.

Еще один ключевой компонент DevOps позволяет автоматизировать все, что мы можем. Это позволяет нам сосредоточиться на постоянном улучшении нашего продукта, а не на повторении ручных задач.

Некоторые аспекты, которые нам нравятся в подходе DevOps:

  • непрерывная интеграция — код, который сам тестирует, создает и развертывает
  • гибкая инфраструктура как код — декларативный подход к созданию серверов, а также их резервирование за счет балансировки нагрузки, автоматического восстановления и автоматического масштабирования и т. д.

Учебный лагерь

Наш буткемп длится 3 месяца и может быть довольно интенсивным для тех, кто никогда не занимался парой или практикой BDD. Новый разработчик будет работать над производственным кодом с первого дня с одним из существующих разработчиков. Нет руководств, нет документации; только погружение.

Учебный лагерь готовит разработчиков к тому, чтобы довольно быстро перерасти свой младший, зависимый статус в неотъемлемых членов команды, на которых можно смотреть как на экспертов по продукту и кодовой базе.

10% времени

Раз в две недели мы выделяем день, чтобы сосредоточиться на чем-то, что является чем-то второстепенным по отношению к нашему основному продукту, но важно по многим причинам:

  • расширяем возможности нашей команды
  • забота о личном развитии
  • двунаправленное обучение с нашим собственным продуктом
  • выгорание настоящее; Отход от того, чему мы посвящаем так много часов, полезен для ума.

Будь то небольшое приложение для оценки TypeScript / Node / MongoDB Ping Pong, работа с постоянным экспертом по безопасности в течение дня для изучения текущих известных уязвимостей с известным сервисом или работа в паре с дизайнером для изучения загрузки счетчиков, все это важно и важно. все это в конечном итоге возвращается к продукту и целостному подходу.

Все имеет значение

Иногда трудно увидеть пользу от простого чтения нескольких сообщений в блоге. Наш подход всеобъемлющ; у каждого из наших методов разработки есть цель по отношению к продукту, и это было бы не то же самое, если бы мы подходили к нему по частям.

Самое главное, все это ведет к чрезвычайно свободной от стресса и веселой обстановке. Мы всегда заняты, всегда есть чем заняться, но в 17:30 мы выключаем часы, идем домой и расслабляемся.

Более счастливые команды — это более продуктивные команды, что в конечном итоге приводит к более качественному продукту, и это то, что нужно нашим клиентам.

MotoMe.com.au только что выпустил редизайн, направленный на повышение качества обслуживания клиентов, идите и проверьте его.