Как скрам помогает стать более сильным разработчиком?

Эта статья опубликована на habrahabr: https://habr.com/ru/post/530330/

Если спросить программиста, то как правило, его будут заботить в основном знание какого-либо языка программирования, платформы, фреймворка, алгоритмов и структур данных, паттернов и принципов проектирования. В мире это принято называть Hard Skills.

Что до Soft skills, то, к сожалению, это считается чуть ли не лишним ингредиентом, пустой тратой времени, или же несущественным элементом. Ценность Hard Skills сильно выше, чтобы переставать работать с человеком из-за проблем с Soft Skills.

И об этом можно легко сделать вывод, пройдя несколько собеседований в компаниях, где часто можно встретить человека, активно пытающегося «завалить» интервьюируемого техническими вопросами, дабы показать его слабости. В некоторых компаниях под конец беседы могут спросить о хобби. Ну и упомянуть что используют Agile. Однако по факту, большинство разработчиков участвуют в необходимых церемониях постольку поскольку, лишь бы к ним не приставали “надоедливые менеджеры” или скрам мастера.

С одной стороны, это можно понять, так как в нашем быстро меняющемся мире Hard Skills трудно поддерживать в актуальном состоянии, помнить разные детали на низком и высоком уровнях, чтобы не потерять свою стоимость на рынке труда.

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

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

Итого: строить продукт сложно и дорого. Крайне сложно удержать в одной голове все эти моменты, а потому продукты строят, как правило, команды, а не личности.

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

Однако, здесь не достаёт чуточку цели.

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

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

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

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

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

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

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

Для разработчиков из всего вышеизложенного важно одно: направление развития продукта (и компании) будет меняться, точно!

Работая в стартапах сложно сказать какую проблему придётся решать через 6 месяцев. Никто не знал, что видео-сервис для свиданий станет самым популярным в мире видео-стриминговым сервисом YouTube. Так же, как никто не предполагал, что игра для социализации может превратиться в чат для коллег, как в случае Slack. Бизнесы, которые не смогли повернуть свои продукты в правильном направлении, либо уже исчезли, либо близки к провалу.

Гибкие методологии стали появляться как раз-таки на волне понимания, как важно сохранить возможность гибкости стратегии, возможность в нужный момент резко повернуть в сторону, а не продолжать двигаться по длинным фазам, делая проект, в целях которого уже не уверен. Одним из важнейших отличий гибких методологий от фазовых подходов, вроде Waterfall, являются короткие итерации. Укажу лишь несколько причин по которым организация может видеть итерации полезными:

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

Конечно, когда продукт развивается короткими итерациями, то очень часто нельзя сделать полное решение задачи в одну итерацию. Работа делится на части и само собой появляется требование доставлять продукт инкрементально: всё больше и больше функций с каждой итерацией.

Как неудивительно, это требование должны удовлетворить разработчики, создав соответствующую архитектуру продукта.

Есть одна фундаментальная вещь, которую нужно понять с точки зрения разработки: преждевременное принятие решений (up-front design) — это не всегда хорошо, а чаще плохо.

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

Итеративный подход Scrum ставится в противовес фазовому Waterfall, но так как это не является темой моих рассуждений, я приведу отличную статью на этот счёт.

Самое важное, что нужно понять программисту, это то, что решения бывают двух видов:

1. Решения, которые можно легко откатить назад

2. Решения, которые нельзя просто откатить назад

Последние как раз и являются самыми проблематичными. И когда я говорю про Up-Front design, подразумевается именно ряд решений, которые невозможно или слишком долго повернуть вспять.

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

• Допустим, сегодня вы готовы полностью положиться на какого-либо вендора и писать код, не заботясь об абстракциях, отделяющих ваше решение от специфичных этому вендору сущностей. Будете ли вы считать это правильным выбором через 2 года?
• Выбрав фреймворк для написания программы, подумали ли вы насколько легко будет переключиться на другой фреймворк в случае необходимости?
• Если вы выбрали для разработки новый язык программирования, вы точно сможете найти себе знающих коллег, которые смогут вместе с вами поддерживать и развивать продукт?

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

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

Ещё один сложный вопрос: как вести разработку в условиях изменяющихся требований? Изменяющиеся требования среди разработчиков принято считать чем то очень плохим. Это происходит из-за того, что “необходимость менять требования” заложена в понятие программного (Soft — гибкий) обеспечения, но не указана явно.

Если учесть, что требование “поддержки изменений требований” является одной из составляющих доменной области вашего продукта, то появятся и решения в архитектуре, которые позволят делать эти изменения менее болезненно. Очень часто не нужна возможность менять всё и всюду, а изменения нужны только в определенных частях программы. Там, где свойственно меняться требованиям или ожиданиям клиентов.

Каждый уважающий себя разработчик должен прочитать книгу “Чистая Архитектура” Роберта Мартина, в которой эта тема раскрыта очень широко и приведены примеры решений:

Позвольте добавить один совет, которого в книге нет: разработчики должны создавать настолько мало кода, насколько это вообще возможно, а в идеале вообще обойтись без кода. При этом нужно всё также добавлять функционал. Феноменально, не правда ли?

Нет, я не говорю перестать писать код вообще и перейти на готовые конструкторы. И нет, я не говорю перестать создавать ПО. Я говорю о том, чтобы начать делать ровно то, что приносит ценность, и перестать делать то, что только отнимает усилия. Вот некоторые факты:

• Меньше нового кода, означает меньше поддержки.
• Меньше нового кода также означает меньше всего что может сломаться (работает, не трогай! помните?).
• Меньше нового кода — меньше когнитивной нагрузки.
• Меньше нового кода — больше уверенности в результате работы.

Мы всё ещё должны экспериментировать, создавать “велосипеды”, изучать чужой код, и писать свой. Но не обязательно это делать в системах, рассчитанных на долгую поддержку и развитие большим количеством человек. Примеры:

• Скорее всего, не обязательно писать свой фреймворк с ноля, но достаточно правильно использовать один из существующих, заложив слой абстракции, чтобы можно “спрыгнуть” с фреймворка если это понадобится. Это добавит и тестируемости, и чистоты. Поверьте, это так же потребует большой аккуратности и точности в проектировании. Но, ваши усилия будут направлены на проектирование решения под задачу бизнеса.
• Ровно так же, не стоит писать свой код реализации шифрования. Не стоит писать код там, где вы не являетесь специалистом. Ваши пользователи, как и бизнес, этого не оценят.

Может быть этот совет и покажется кому-то теоретическим. Однако, с практикой и опытом, всё больше начинаешь замечать моменты, в которых лучшее решение лежит совсем не в коде. Как инженеры с развитым системным мышлением, вы можете помочь команде и указать на подобные решения.

Если говорить о коде, то программисты нанимаются для того, чтобы вносить изменения в поведение программного обеспечения так быстро, насколько это возможно. Разработчики могут поддерживать скорость изменений на достаточном уровне только создавая достаточно гибкую архитектуру. Для этого требуется своевременная коммуникация с бизнесом для выяснения что на самом деле ему надо. Также, требуется тщательно продумывать каждое изменение, контролируя архитектуру и технический долг, и постоянно уточняя требования. Если не обратить внимание хотя бы на одну из этих составляющих (перестать коммуницировать с бизнесом или же не обращать внимание на архитектуру), то так или иначе, но скорость внесения изменений очень быстро упадёт, и к вам возникнут вопросы. В последнее время всё чаще встречаются термины Agile Architecture и Lean Architecture. Я предпочитаю объединить эти понятия в одном термине: Гибкая архитектура.

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

Понятие очень размытое и меняет своё значение от компании к компании, от бизнеса к бизнесу, и от команды к команде. Оно часто зависит от мнения начальства, менеджеров, и вообще коллег. Soft skills как раз нужны для того, чтобы это мнение было положительным. Но многим разработчикам эти навыки даются нелегко. Зато, одно остаётся верным всегда: сильный разработчик тот, кто умеет проектировать программное обеспечение, которое соответствует нуждам бизнеса.

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

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

Представьте, насколько сильно изменилась архитектура Android, который изначально был задуман как операционная система для камер, и только. А теперь это одна из двух самых популярных мобильных платформ. Другой пример, PayPal, который создавался как сервис перевода денег между телефонов с операционной системой Palm OS. А теперь сервис обрабатывает миллионы платежей по всему миру.Врядли, развитие кодовой базы этих проектов было монотонным ростом функционала из года в год. Уверен, что такие изменения, словно большой взрыв, порождают массу работ по адаптации, рефакторингу и переписыванию с ноля. Это конечно одни из самых сложных случаев. Но кто может заранее предположить путь вашего проекта?

После того как я провёл параллели между необходимостью бизнеса и техническими навыками разработчиков, а также поверхностно описал трудоёмкость стоящих перед разработчиком задач, думаю настало время суммировать, чем же именно правильно интегрированный скрам поддерживает технический навыки разработчиков. Да, я не оговорился, именно правильно интегрированный скрам. Я видел примеры плохой интеграции методологий, но видел и успешные случаи. С полной ответственностью могу сказать, что одно без другого не получится. Итак:

• Скрам позволяет командам понимать цели бизнеса. Команды, как правило, знают ответы на вопросы “Зачем мы делаем это?”, “Как именно мы должны это сделать?”, “Что будет показателем успеха нашей работы?” и т.д.Эти вопросы могут задаваться не сразу, не с первого дня, но так или иначе, команды приходят к ним. И получают ответы. Имея эти ответы, разработчики могут проектировать системы с большей уверенностью в правильности действий, верно определять интерфейсы взаимодействия компонент, создавать слабосвязанные и мало-зависимые друг от друга компоненты. Такое проектирование повышает качество и стабильность конечного продукта.
• Скрам позволяет командам действовать независимо, самостоятельно принимать решения и не бояться пробовать новые идеи. Представьте, что вы приняли неверное решение в одной из 2-недельных итераций, внесли изменения, а во время презентации работы выяснились неожиданные подробности. Не так уж и плохо отказаться, и откатить решение, на которое было потрачено всего лишь 2 недели. С точки зрения затрат — это цена новых знаний, которая вполне по силам компаниям среднего или большого размера. А ошибка — лучший учитель.
• Скрам позволяет контролировать рост засчёт коротких итераций и небольших инкрементов. Если команда строит что-то очень большое, то рано или поздно встаёт необходимость измерять код всевозможными метриками, чтобы узнать, как растёт технический долг, насколько легко будет поддерживать внесённые изменения и т.д. Когда нет четко отлаженных и повторяемых итераций, легко забыть о какой-то детали или вспомнить о ней только тогда, когда решать проблему будет невозможно или очень дорого.

Некоторые путают понятия Спецификация и Требования. На самом деле, Спецификация может лишь формально описать пожелания заказчика. Но Требования — понятие более широкое. Оно включает и сам процесс разработки, и процесс доставки, и то, как часто и где будет необходимо менять поведение системы. И даже тот факт, кто запрашивает эти изменения. Поначалу, какие-то из этих деталей могут казаться не относящимися к архитектуре совсем, но через некоторое время стать важнейшими и критическими требованиями к системе. Всё должно быть отражено в программной архитектуре.

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

Теги:

• архитектура
• скрам
• lean
• agile
• clean architecture
• чистая архитектура