Споры «полный стек против узкой специализации» вечны.
Но одно дело спорить в комментариях, а совсем другое — создать свою компанию и опробовать экстремальный подход на практике.
Антон Кекс Я пошел по этому пути: стал сооснователем компании Codeborne, где разработкой занимаются исключительно «фулстек-крафтеры» и практикуется экстремальное программирование.
И, по его словам, команды из 2-4 человек могут делать то, что от других требуют 50 человек.
Об этом он подробно рассказал на нашей конференции JPoint .
Обычно на наших мероприятиях вы не услышите слово «agile», потому что много пустых разговоров о методологиях, а мы любим конкретику, код и хардкор.
Но поскольку Антон не кабинетный теоретик, а обладатель большого нестандартного опыта, то это всего лишь хардкорная и ценная информация.
Вы можете не согласиться с его позицией, но с ней как минимум полезно ознакомиться.
И хотя отчет был сделан пару лет назад, в 2021 году он продолжает собирать просмотры, поэтому мы решили сделать текстовую версию для Хабра.
Под катом представлена видеозапись и текстовая расшифровка.
Остальная часть истории рассказана с точки зрения Антона.
Оглавление
- Введение: о Таллинне и Codeborne
- Фрагментация сообщества: что разделяет разработчиков — Конфликт 1: администраторы против разработчиков — Конфликт 2: Разработчики баз данных и разработчики приложений — Конфликт 3: Изоляция по интересам — Конфликт 4: Фронтенд против бэкенда — Конфликт 5: iOS против Android против всех остальных — Конфликт 6: изобретая велосипед, Котлин против Swift — К чему приводят конфликты?
- Фуллстек приходит на помощь — Экстремальное программирование — Что важно знать фулстеку? — Побочные эффекты полного стека
- Роли поддержки: игра в сломанный телефон
- Манифесты Agile, Scrum и программного обеспечения
- Мастера, мастера, мастера! — Что должен уметь мастер? — Как решить проблему без кода? Пример из жизни — Стартапы и мастера — недоинжиниринг — Экстремальные практики программирования
- Кодовая рутина
- Парное программирование
- Заключение
Введение: о Таллинне и Codeborne
Доклад на русском языке, а слайды на английском, потому что я не местный.Я родом из славного города Таллинна: это лучше всего сохранившийся средневековый город Европы, а также европейская столица информационных технологий.
Все технологии ЕС взяты из Эстонии.
Так что приходите к нам, здесь здорово! 
Мой отчет основан на опыте Codeborne, который я создал с коллегами в 2010 году.
Мы работаем уже 9 лет именно так, как я вам сейчас расскажу, поэтому все проверено в бою.
На мой взгляд, это лучший формат для работы в IT. Компания у нас небольшая, в ней 33 «крафтера», других должностей нет. Слово «мастер» иногда переводят на русский язык как «мастер», но я предпочитаю «мастер своего дела».
Нашими клиентами являются почти все крупнейшие компании Эстонии, и у нас много клиентов за рубежом.
В 2012 году мы привезли интернет-банкинг в Россию: создали первый такой интернет-банк в России, каким мы раньше привыкли видеть его в Эстонии.
У нас небольшая команда, но эффективность у нас очень высокая: мы делаем очень много, никто не может в это поверить.
И поэтому я сейчас расскажу тебе о наших секретах – никому не рассказывай.
Фрагментация сообщества: что разделяет разработчиков
Начнем с напоминания.ИТ существует только потому, что мы делаем проекты для бизнеса, государства и так далее.
Они платят нам деньги.
Без них мы абсолютно бесполезны: мы можем закодировать себе что-нибудь крутое, но это не то.
И тем не менее мы постоянно делим друг друга на группы и спорим друг с другом.
Если мы заглянем немного в прошлое, то увидим, что в прошлом все программисты были фулстек-крафтерами.
Но тогда таких слов еще не было, и их называли просто «программистами».
Кстати, не все знают, что первыми программистами были в основном женщины, так что это были не мастера, а мастерицы.
В то время программистам приходилось знать еще больше об аппаратном обеспечении.
Теперь быть фулстеком не означает, что нужно сидеть с паяльником.
В то время вам приходилось управлять машиной на очень низком уровне.
А потом все изменилось: появились конфликты, токсичность, разные группы, сообщества, которые не общались друг с другом.
Давайте посмотрим на них.
Эта фотография является хорошим примером.
Вверху можно писать разные слова, не обязательно «разработчик» и «тестер».
Главное — нож за спиной, а это не то, к чему мы стремились.
Не этого ждали от нас все те люди в 50-х, которые бегали с перфокартами.
Конфликт 1: Админы против разработчиков
Давайте рассмотрим первый конфликт, который я однажды наблюдал.Это были администраторы против разработчиков.
Администраторы — это, наверное, одна из первых дополнительных ролей в ИТ, появившаяся, когда начался активный рост ИТ.
Интернет появился, но и до него были серверы, на которых запускались какие-то приложения, и кто-то должен был за ними следить.
Эта роль отличается от программирования.
Проблема в том, что администраторы несут ответственность за стабильность своих систем и поэтому ненавидят перемены.
И мы, разработчики, вся наша работа — создавать эти изменения.
И сразу очевиден первый конфликт: люди не хотят общаться друг с другом.
Фразу «Предоставление админских прав разработчику приведет к хаосу» я услышал в этом году, в 2019. Я был в шоке, что есть люди, которые, несмотря на все девопсы и так далее, до сих пор говорят, что если дать разработчикам какой-либо доступ, то наступит хаос.
начнется.
Конфликт 2: Разработчики баз данных и разработчики приложений
Затем в 2000-е произошел еще один очень популярный конфликт — между разработчиками баз данных и разработчиками приложений.Очень интересный факт: задолго до этого появилась компания Oracle, которую мы все знаем и любим, и она занималась созданием баз данных.
Их консультанты путешествовали по всему миру и продавали свою продукцию всем крупным банкам и другим компаниям.
Чтобы лучше продавать продукты, им нужно было придумать новую специальность (DBA) и новое очень важное словосочетание — «активы данных».
Чтобы высшее руководство компаний понимало, что наша база данных — это сокровище, это наши активы, они так же важны, как наши деньги на банковском счете.
И, к сожалению, это создало отдельную роль для людей, специализирующихся только на базах данных.
У этих людей случился большой конфликт с разработчиками приложений, в основе которого был вопрос: куда девать бизнес-логику? Человек, для которого весь мир — его святая база данных, естественно, хочет запихнуть туда все, даже то, что туда не помещается.
Разработчик приложений — наоборот. Для него база данных — это какая-то помойка, и он хочет вытащить оттуда все самое важное.
Басисты оставались более консервативными.
Я до сих пор вижу людей, использующих, например, CVS для разработки своих хранимых процедур в Oracle. Это вообще ужас, 2019 год. С другой стороны, разработчики приложений пошли другим путём и сказали: «NoSQL, да ладно, реляционные базы данных — это херня, нам нужны новые крутые фичи».
И все начали заново изобретать то, что уже давно существовало в мире баз данных, например, консистентность.
И теперь программисты сами должны писать такие вещи в своих приложениях.
Естественно, они там делают кучу багов.
Конфликт 3: Изоляция по интересам
Появилась и куча других изолированных сообществ в ИТ, связанных с разными вариациями.Например, статические и динамические языки.
Но мы, конечно, на конференции по Java, знаем, что динамические языки — это для детского сада, да? Затем, конечно, есть, например, программное обеспечение с открытым исходным кодом и проприетарное программное обеспечение.
Есть люди, которые живут в мире Microsoft и понятия не имеют, что происходит за пределами этого мира.
Они сидят там и смотрят, что им показал Microsoft, и все.
На самом деле, это ужасно.
Такие примеры, как Ruby и Python, .
NET и Java EE (пусть Бог будет пухом).
Все они созданы людьми, которые пытаются жить в своем собственном мире и постоянно что-то изобретают заново.
Например, разработчики Ruby и Node только сейчас начинают ценить то, что было в Java в 1995 году.
Это многопоточность и обратная совместимость.
Они только сейчас начинают это понимать, а мы все это знали давно.
Еще есть разработчики игр.
Это тоже отдельный мир.
Эти ребята еще меньше общаются со всеми нами, они даже не знают, что такое непрерывная интеграция и юнит-тесты.
Но они работают в студиях, очень модно одеваются, круто тусуются и так далее.
И, конечно, еще есть те, кто все еще программирует на C, на C++, а это тоже совершенно отдельный мир.
Для них тоже появились альтернативы: Go, Rust (кстати, если кто-то из вас еще не смотрел Rust, это офигенный язык, стоит посмотреть).
Конфликт 4: Фронтенд против бэкенда
Потом появилась новая терминология, разделившая нас: фронтенд и бэкенд. До 2010-х годов такие слова вообще никто не употреблял.Это были странные слова.
А началось всё с того, что в какой-то момент всем захотелось делать интерфейсы покруче, посложнее, а вместе с этой сложностью пришла необходимость использовать новые технологии и делать всё по-другому.
То есть они перестали просто добавлять jQuery где-то в середине своего HTML и начали думать, что нужно сделать новые крутые инструменты.
Даже я в то время выступал за более четкое разделение UI и остального кода, ведь они сейчас пишутся на разных технологиях.
Но я никогда не думал, что люди должны специализироваться на том или другом.
Что случилось? Пришло новое поколение разработчиков: какой к черту бэкенд? Пользовательский интерфейс красивый, это круто, давайте возиться с Node, компилировать JavaScript в JavaScript и изобретать фреймворки каждый месяц.
Сейчас вокруг фронтенда ходит много шуток.
Кстати, компиляция JavaScript в JavaScript занимает больше времени, чем компиляция кода Scala, представляете? Я действительно это видел.
А нас теперь разжаловали до разработчиков API. Мы, backend-разработчики Java, сейчас сидим и просто создаём API для крутых чуваков, которые делают «сексуальный UI».
Конфликт 5: iOS против Android против всех остальных
В то же время произошла вторая революция: наши мобильные устройства очень сильно развились.И вы знаете, Стив Джобс очень мудр.
Когда вышел первый iPhone, он сказал, что есть действительно крутой движок Safari, на нем можно писать потрясающие приложения Web 2.0 и Ajax, которые выглядят и ведут себя точно так же, как приложение на iPhone, а Apple не нужны нативные приложения.
Это то, что он сказал в 2007 году, и это было мудро — это не привело к новой фрагментации среди разработчиков.
Что случилось? Через месяц появился Jailbreak. Apple увидела, что там появилось новое сообщество: люди начали взламывать и делать приложения для iPhone. У меня был первый iPhone, и это была классная игрушка: туда можно было установить ssh-сервер и заходить в терминал на телефоне.
И в конце концов у Apple не было другого выбора, кроме как создать App Store. История свершилась: теперь, к сожалению, у нас каждый маленький сайт, каждый маленький магазинчик во дворе хочет иметь свое приложение, и чтобы каждый его зачем-то установил и пользовался.
И что это значит? Это означает, что мы, разработчики, снова имеем разделенное сообщество.
Потом появился Android. Царство небесное — это Windows Phone, к счастью, потому что это опять-таки фрагментация (хотя Windows Universal Apps по-прежнему можно писать под Windows).
Сейчас есть iOS и Android разработчики, они перестали общаться друг с другом, они совсем другие.
Идея Android заключалась в том, чтобы использовать Java для привлечения огромного количества существующих разработчиков к новой платформе.
Идея потрясающая.
Что мы видим сейчас? Новое поколение разработчиков, которые никогда в жизни ничего не писали на бэкенде.
Они просто отстой в Android и говорят: «Я не хочу бэкенд — это не круто, но Android совсем другой».
И естественно, снова начали придумывать: как все это тестировать, какие новые языки нужны, ведь старые уже не подходят. Все усиленно учили Objective-C — теперь никто не хочет видеть Objective-C. Сейчас мы подошли к тому, что компании обязаны как минимум трижды перереализовать весь свой UI: пишут для Android, для iOS, для веба и потом для чего-то еще.
В каждой компании до сих пор есть бэкенд-разработчики.
Они разделены на микросервисы, у каждого микросервиса есть своя команда, и они занимаются только своим микросервисом.
Они знают, что где-то здесь у них есть этот костыль, но они ничего не знают об этом костыле.
Все это ужасное злоупотребление ресурсами нашей матери-земли.
Конфликт 6: изобретая велосипед, Котлин против Swift
Давайте посмотрим на Котлин и Swift. Оба замечательных новых современных языка, они мне очень нравятся.Они очень похожи, удивительно похожи.
Они разрабатывались независимо друг от друга, и результат был практически одинаковым.
Опять же, сколько ресурсов на это было потрачено.
Но в то же время есть некоторые нюансы.
Например, в Kotlin от Java-сообщества узнали, что «проверяемые исключения» — это плохо, а в Swift, наоборот, добавили это как крутое нововведение, после Objective-C.
К чему приводят конфликты?
Доходит до того, что есть разработчик функции X и функции Y, и предполагается, что мы разные и не общаемся.Это даже не совсем шутка: у нас есть бессерверные решения, есть AWS Lambda, и мы действительно собираемся стать разработчиками однофункциональных приложений.
Представляете, если бы такое было с врачом? Одно ухо у тебя есть, ок, а теперь иди к другому чуваку, он проверит другое ухо.
Это ерунда.
У этой ерунды есть название: по-английски это сверхспециализация.
На русский это можно перевести как «слишком узкая специализация».
Именно это мы сейчас, к сожалению, активно наблюдаем в ИТ.
Это ведет к:
- Раздутые команды .
Теперь, чтобы сделать что-то маленькое, нам нужно не 2 разработчика, а 25, потому что каждый из них делает свой маленький кусочек, а потом кто-то другой пытается его подключить, чтобы все работало вместе;
- Низкий коэффициент грузовика (коэффициент автобуса/коэффициент грузового автомобиля).
Это количество людей в вашей команде, которое может переехать грузовик, чтобы ваш проект продолжал существовать.
Если единственного iOS-разработчика в вашей команде собьет грузовик, и ваше iOS-приложение станет бессмысленным, это очень плохо.
Я работаю со многими компаниями-клиентами и вижу это постоянно;
- Медленные и дорогие проекты .
Мы, как отрасль, специально подвели наших клиентов.
Это значит, что люди, имеющие очень узкую специализацию, пытаются создать в своей песочнице огромные замки и сделать ее еще круче.
Из этого получается, что сложность всей системы растёт, все компоненты становятся сложнее, с ними всё сложнее взаимодействовать.
Как разработчики, мы всегда должны стремиться к простоте.
Я сейчас вижу переинжиниринг повсюду.
Фуллстек приходит на помощь
На помощь приходит возвращение к старому доброму фуллстеку-разработчику.
Раньше все разработчики были такими.
Это мастер на все руки:
- У него широкий кругозор;
- У него есть опыт работы в различных областях и стеках;
- Он может выбрать подходящий инструмент для конкретной задачи;
- Ему не нужно ни на кого показывать пальцем.
«Я сделал свою часть, но эти бэкендеры не допилили свой API, это все их вина, что наш проект провалился» — такого не бывает;
- Он может очень быстро освоить новые технологии, потому что много чего пробовал, знает, что важно, а какой просто синтаксис нужно выучить.
Как пример: в нашей маленькой Эстонии узкоспециализированных людей гораздо меньше.
Когда людей мало, это очень сложно себе позволить.
Когда у вас большой город и большой рынок, вы можете позволить себе быть неэффективным.
«Большой» чаще всего означает «неэффективный».
А это значит, что каждое конкретное звено в этой неэффективной организации — еще менее важный человек.
Вы хотите быть неважным в своей организации? Вырубаешь свою маленькую функцию, и ладно, плевать, что там происходит. Это приводит к обвинениям.
Начинаешь обвинять всех вокруг в том, что наш проект опять не укладывается ни в сроки, ни в бюджет. 
Экстремальное программирование
Давайте посмотрим, что для меня можно назвать библией разработчика.Этот экстремальное программирование , одна из оригинальных гибких практик.
«Экстремальное программирование основано на очень важной концепции.
коллективное владение кодом , по-русски – «колхозное программирование».
Это означает, что весь код является общим.
Не бывает вот мой код, а здесь не мой код, Катя поменяла эту функцию, поэтому я ее не трогаю, пусть Катя сама исправляет свои ошибки.
Нет. В экстремальном программировании все по-другому.
Я иду куда угодно и исправляю все, что нужно сделать.
Если я Full Stack разработчик, я либо помог построить всю систему с нуля, либо изучил каждый аспект системы.
Мне это нужно для того, чтобы я мог где угодно что-то настроить и исправить, чтобы я мог понять, где настоящая проблема, и не чинить там, где это не нужно.
Я ничего не оставляю другим: если я делаю новую функцию, я должен убедиться, что она работает полностью, от самого пользовательского интерфейса до базы данных, всего.
Я полностью контролирую ситуацию.
Если всю мою команду собьет грузовик, я все равно справлюсь.
Именно такое ощущение должен испытывать фуллстек-разработчик.
Естественно, с такой крутой силой приходит и ответственность, но это круто, это интересно, это делает нашу жизнь и работу веселее.
Многие говорят, что быть фулстек-разработчиком ужасно сложно: «Я не могу столько знать, это просто не умещается в моей маленькой голове».
Фактически, определение Full stack разработчик может быть таким: вы знаете все стеки своего проекта .
В собственном проекте вы можете работать на всех уровнях.
Это не значит, что вы знаете все технологии в другом проекте, но если вы туда попадете, то вы их все изучите без проблем, потому что у вас уже есть большой опыт. Это значит, что вы как бы полиглот в языках.
Вы знаете, что важно, вы знаете суть программирования и можете применять его где угодно.
Например, многие специалисты по PL/SQL говорят, что не умеют писать модульные тесты.
Если вы умеете это делать, вы можете написать для себя простой фреймворк на любом языке, показать его людям как на C, так и на PL/SQL — смотрите, вот они, юнит-тесты, вот так делается разработка через тестирование, даже на вашем языке, где вы говорите, что это невозможно.
Вы по-прежнему будете углубленно изучать наиболее важные части вашего проекта и приобретать опыт в своем проекте.
Потому что никогда не надеешься, что кто-то решит проблему за тебя.
Что важно знать фулстеку?
Важными для вас являются, например, структурирование кода, как его хорошо спроектировать.Безопасность, как правильно залогиниться, чтобы потом провести хороший аудит своего приложения, как его автоматически протестировать, как решать проблемы просто, а не сложно.
Любой дурак может написать сложный код, но попробуйте написать простой .
Это то, чему вам действительно нужно научиться.
Потом вы берете какой-нибудь новый язык программирования, играете с ним пару дней, а потом можете выполнять его так же круто, как вы это делали на Java, например.
Плюс нужен деплой, девопс: нужно автоматизировать запуск своего приложения, чтобы оно не вылетало.
Потому что если он выйдет из строя, злой админ позвонит вам среди ночи, и вам станет плохо.
А если ты где-то в баре уже пьяный, что тебе делать? У меня такое случилось.
Вы скажете - почему я? Почему я должен быть таким? Потому что технологии и специализация приходят и уходят. .
За свой опыт я уже повидал много разного и интересного, и это не важно.
Вы всегда можете применить свой опыт к новым технологиям.
Потом сейчас много говорят об ИИ — придет автоматизация и начнет писать за нас код. Мы, программисты, считаем, что все остальные профессии будут заменены роботами, и мы продолжим программировать этих роботов.
Это не верно.
На самом деле у нас много работы, которую можно легко автоматизировать.
И ИИ тоже это сделает. Нам напишут функции, они эти функции составят, и нам нужно быть к этому готовыми.
Так что теперь нам нужно быть максимально гибкими и продолжать изучать новые вещи.
В мультидисциплинарных командах, как говорится, лучше химия: они лучше общаются, лучше понимают друг друга, не показывают пальцем и не обвиняют других в своих проблемах.
Кроме того, разработчики полного стека, как правило, более полезны для организации, поэтому им платят больше.
Исследование переполнения стека показало, что в среднем зарплата фулстек-разработчика может быть до 50% выше, чем у узкоспециализированных разработчиков .
Многие из них, поскольку все знают и умеют, идут дальше в стартапы и открывают свой бизнес – это и есть самый сок нашей профессии.
Все это приходит с пониманием общей картины.
Вы видите всю картину вашего проекта: где проблема, где ее исправить, вместо того, чтобы подлатать одну мелочь по вашей специализации и сделать еще один костыль, потому что вам лень ждать, пока другая команда это исправит на своей.
сторона.
Вам проще не переусердствовать, потому что оверинжиниринг часто связан с узкой специализацией .
Вы глубже поймете, как все работает, станете более эффективными, будете совершать меньше бесполезной работы и глупых ошибок.
Кроме того, ваш проект по сути обречен, если в вашей команде нет ни одного члена команды, обладающего полным набором функций.
Вы, конечно, скажете, что полный стек вашей команды — это архитектор.
Он все знает, он опытный, он крутой, он старый и все круто.
Но на самом деле, по моему опыту, такие архитекторы, которые специализируются или переспециализируются на архитектуре и перестают писать код, очень скоро становятся неактуальными.
Они перестают правильно мыслить и становятся совершенно бесполезными людьми в команде.
Побочные эффекты полного стека
Как полноценный разработчик, вы будете более прагматичный .Вы не будете использовать каждый новый интерфейсный фреймворк, который выходит каждый месяц.
Может быть, вы попробуете это в свободное время, но опять же поймете, что эту фигню я уже видел в 90-х, но в несколько другом виде.
Вы будете выберите для себя то, что скорее всего не исчезнет в следующем году .
Например, недавно я попробовал пройти онлайн-регистрацию в нескольких известных авиакомпаниях, и они изменили всю систему.
Там какие-то крутые чуваки в клетчатых рубашках все переписали в одностраничное приложение и толком даже не умеют правильно обрабатывать ошибки.
И поэтому, чтобы пройти онлайн-регистрацию в Lufthansa, вам нужно зайти в инструменты разработчика и посмотреть, где у них есть вещи, которые я ввел неправильно.
Как полный стек, вы узнать цену продажи отдельных вещей в разных частях проекта .
У вас есть понимание, где это вам обойдется дороже.
Вы обеспокоены тем, сможете ли вы или другие ваши коллеги выдержать это в долгосрочной перспективе.
Наконец ты не используйте слишком агрессивные структуры, которые пытаются вас полностью контролировать .
Когда кто-то перестанет поддерживать эту структуру, вам придется нести ответственность за работоспособность вашего приложения.
Даже если вы купите какие-нибудь крутые инструменты: в мире проприетарного ПО раньше было популярно покупать какие-нибудь BEA WebLogic, ESB, крутые системы.
Но потом, когда они разваливаются в производстве, у вас нет времени звонить в их поддержку в Индии и ждать, пока они придумают, как решить эту проблему за вас.
Вам предстоит решить эту проблему самостоятельно, декомпилировать их ужасный код и понять, где он лежит, придумать, как его обойти.
Поэтому вам лучше не использовать такие вещи, которые вас контролируют. Всегда лучше написать код, который управляет всеми остальными компонентами.
Давайте подумаем: многие ли из вас знают, как написать текущий проект полностью с нуля? А что если сюда ещё включить сторителлинг, то есть сбор требований? Сможете ли вы сделать все это сами? Что, если всю команду переедет грузовик? Думаете, если сейчас переписать свой проект с нуля, будет лучше? От того, кто это будет делать, зависит, насколько вы уверены в себе.
В английском языке есть такое понятие, как «может сделать отношение» — это нужно развивать в себе.
Роли поддержки: игра в сломанный телефон
Все знают, что мы как программисты продвинулись немного дальше остальных людей.
Вот почему другие люди говорят, что с нами трудно общаться.
На самом деле, я недавно прочитал классную статью, где говорилось, что проблема в том, что программист ценит точность.
Ему очень важно рассказывать точные факты, ведь работа программиста очень сильно зависит от точности.
Мы должны реализовывать определенные вещи именно, а не «ну, может, так, может, так».
А обычно люди говорят именно это, поэтому возникают недоразумения.
Но в наших командах, помимо разработчиков, есть тестировщики, аналитики, менеджеры проектов, продакт-менеджеры, как их сейчас модно называть.
Например, до создания Codeborne я работал в Swedbank. В 2010 году это был, пожалуй, самый инновационный банк в мире, и даже там из 700 сотрудников ИТ-отдела только 50 были разработчиками .
Возникает вопрос – а что делают другие? И кажется, что все что-то делают. Это так называемые второстепенные роли.
Они существуют именно потому, что программисты не умеют правильно выполнять свою работу.
Мы не умеем общаться, мы не хотим общаться, мы не хотим тестировать свой код, мы все это выбрасываем куда-то и позволяем этим заниматься кому-то другому.
Иногда мы даже не хотим нормально собирать наш код, просто напортачили, и позволяем кому-то другому попытаться его собрать, ладно, да? Вот почему появляются такие люди и превращают нас в кодовых обезьян.
Эти должности позволяют нам, программистам, не развивать свои коммуникативные навыки.
Естественно, это снова снижает эффективность.
Мы тыкаем друг в друга пальцем, обвиняем друг друга и играем в сломанный телефон.
Это детская игра, помните: шептались, шептались, и всё исказилось.
Я часто замечал эту проблему в Codeborne: если мы общаемся с посредником, он всегда будет отстаивать ту точку зрения, которую ему когда-то сказали.
С ним невозможно провести какие-либо переговоры, чтобы что-то изменить.
У разработчика часто есть гораздо лучшее представление о том, как решить проблему, но в итоге вы получаете мессенджера, который никогда не передаст вашу идею реальному заказчику.
И это очень плохо.
Поэтому в проектах мы всегда ищем нужного человека, с которым можно поговорить.
Если вы разговариваете не с тем человеком, ваш проект обречен на провал.
.
Кроме того, вы действительно думаете, что тестировщики по-прежнему несут ответственность за устранение ваших ошибок? Фактически, тестировщики, если они есть в вашей команде, уже должны быть последней линией защиты.
Если что-то найдут, то это плохо, поэтому надо стараться отвечать за свое качество.
Многие из вас наверняка видели эту картинку.
Это чертов пример того, как все роли в ИТ не могут разговаривать друг с другом и понимать друг друга.
Клиент также никогда не знает, чего он хочет .
Как мы видим, вначале он хотел трехскоростную качалку, а на деле хотел подвесное колесо.
А что сделали разработчики, лучше вообще не смотреть.
Это, к сожалению, типичная ситуация в IT. Несмотря на это, мы по-прежнему хорошо зарабатываем, нам по-прежнему платят, хотя мы занимаемся ерундой, это долго, дорого и так далее.
Наши бедные клиенты берут то, что им дают, со всеми багами и некорректной реализацией.
И мне очень жаль смотреть на команды или компании, которые не могут найти время для выхода на рынок хотя бы за пару дней, чтобы запустить свой код в производство.
Код, который действительно имеет ценность для бизнеса: он принесет деньги или даст представление о чем-то.
Нет, они месяцами ждут, пока им что-нибудь соберут, полуразваленное выкатят в производство, а потом снова откатят.
Манифесты Agile, Scrum и S
Теги: #программирование #Управление разработкой #Конференции #agile #управление командой #fullstack development #мастерство разработки #fullstack-
Эмаль
19 Oct, 24 -
Поддержка Hp Окутывает Компьютерный Мир
19 Oct, 24 -
Код Безумия И Успеха Oracle Database
19 Oct, 24 -
Механика Головоломок В Приключенческих Играх
19 Oct, 24 -
Интерактивная Реклама Дроидов В Нью-Йорке
19 Oct, 24
