Итак, что же замедляет разработку программного обеспечения?
Задумайтесь об этом вопросе на секунду. Как так выходит, что чем дольше Вы что-либо разрабатываете, тем сложнее и неприятнее добавлять в Ваше приложение новые фичи, попиливать архитектуру?
И почему раньше задачи решались так просто, а теперь выглядят запутанными и сложнореализуемыми?
Казалось бы, положение должно улучшаться, ведь Вы уже давно в проекте, разве нет? Почему всё происходит наоборот?
Ну же, не стоит винить себя за то что ответы не всплывают у Вас в голове сами по себе, большинство разработчиков страдают тем же. Да и вопросы, согласитесь, не из лёгких.
Если бы мы знали ответы на все вопросы, то и проблем бы никаких не было.
Тем не менее Вы ещё не раз столкнётесь с менеджерами, заказчиками и даже другими разработчиками, которые безуспешно продолжают искать ответы на эти же вопросы.
И в первую очередь все начинают винить процесс. Ведь очевидно, что проблемы с процессом негативно влияют на скорость разработки.
В этом есть смысл. Тем не менее я обнаружил что зачастую не это является корнем Ваших проблем. Если команда не сидит сложа руки, а важные задачи правильно приоритезированы, то вероятнее всего процесс не виновен.
Я хочу чтобы Вы меня здесь правильно поняли. То есть две вещи, которые я упомянул — не единственные, что должны Вас волновать, я лишь пытаюсь сказать, что раз уж большую часть времени команда реально работает над действительно важными для проекта вещами, Вы никак не сможете волшебным образом наладить процессы, хоть как-то заметно увеличивая продуктивность разработки команды (в большинстве случаев).
Рассматриваются и такие варианты:
Конечно, это всё замечательные вопросы, которые следует время от времени себе задавать, однако я постоянно убеждаюсь в том, что есть другая позабытая проблема побольше…
Давайте проведём небольшой эксперимент.
Забудем обо всех процессах, забудем о скраме и бэклогах и стори поинтах и всём-всём остальном.
Вы — Разработчик. Вам надо сделать поставленную Вам задачу, изменить кое-что в коде. Вы сидите один, нет никаких процессов, аналитиков. Только Вы и Ваша работа.
Можете подумать о чём-то, что Вы делали недавно или же разрабатываете прямо сейчас, я всего лишь хочу чтобы Вы абстрагировались от всего что напрямую не относится к дизайну или кодированию данной фичи.
Наверняка у Вас будут примерно такие мысли:
1. Эта фича имплементится быстро и просто, я знаю как и куда её добавить, всё будет тип-топ!
Вот так, замечательно! Выходит, на самом деле у Вас нет никаких проблем.
2. Что-то я не понимаю, что надо сделать. Как и где это будет использовано в системе?
Хм, в таком случае у Вас, скорее всего, присутствуют кое-какие проблемы с процессом. Может быть Вам нужна постановка задачи почётче или следует задать больше вопросов. Такое случается, правда. Идеи-полуфабрикаты попадают в процесс и кому-то определённо придётся побегать и пошевелить мозгами прежде чем разработчики на самом деле смогут заняться ими.
3. Я боюсь что-то менять, это почти невозможно. Прежде чем начать, понадобится копать в других частях приложения и разбираться: что, как и почему так работает (и как оно вообще должно работать).
Как не печально, но это наиболее вероятный исход. Что-то среднее между вторым и третим пунктом, потому что у них одна и та же причина — готовый код и либо усопшая, либо «её-нет» архитектура.
И я продолжаю сталкиваться с тем, что разработка большинства приложений замедляется из-за кода самих приложений или же утери оригинального дизайна.
Но подобные проблемы Вы увидите только в успешных компаниях, потому что…
Было время, я консультировал пару провальных стартапов. И должен заметить, у них была одна общая черта (как в прочем и у большинства других стартапов): ноль проблем с кодом. Да-да, отличная кодовая база, причёсанная, ухоженная, пахнет приятно.
Я видел самую лучшую архитектуру и идеальный код в умерших стартапах.
Может быть это выглядит так, будто я противоречу сам себе. Сейчас поясню.
Проблема заключается в том, что стартапы со сверкающим кодом не поспевают за рынком. Они стоят на старте и завязывают красивые бантики на своих шнурках, оглядываются по сторонам и осторожно рассматривают каждое место куда собираются поставить ногу.
Что происходит? Они создают прекрасный код, клёвую архитектуру. Но слишком поздно. Конкуренты вырываются вперёд и двое обкофеиненных не-совсем-программистов-но-я-чуть-кодил бодро обходят Вас со своим приложением на VB6, написанным прошлой ночью на коленке. Да, может не совсем то, что хотел заказчик, но зато как оперативно!
Но что, я разве теперь утверждаю что надо написать салфеточный говнокод и быстренько сдать его, иначе провал?
Или я говорю, что нельзя выраситить успешную контору на хороших практиках и качественном коде?
Нет. Но я пытаюсь сказать что большинство успешных компаний в первую очередь вовремя сосредоточили свои усилия на заказчике и только затем на ПО.
Другими словами, если Вы взгляните на код десятка успешних компаний за последние лет пять, в 9 из них вы обнаружите дерьмовую архитектуру и систему весьма отдалённую от исходного дизайна и хороших манер.
Окей, к чему я всё это?
Компании-победители бегут и выживают! Однако и после 5 лет они всё ещё продолжают бежать изо всех сил и тут их некрасивые шнурки начинают развязываться.
Возможно, они даже не приметят, что их шнурки развязаны до тех пор пока пару раз не споткнутся о них. Чепуха, они всё ещё продолжают бежать. С одной стороны, это хорошо, ведь именно это делает их преуспевающими, а других, что решили остановиться и, оставшись далеко позади, завязать свои шнурочки, — позорно проигравшими.
Проблема обычно даёт о себе знать примерно после пяти лет непрерывного бега, когда компании решают что пора выходить на новый уровень. До сих пор у них неплохо выходило бежать, виляя из стороны в сторону и стараясь держать ноги достаточно раздвинутыми, чтобы реально не попасть на шнурки.
Это самую малость их тормозит и потому они продолжают бежать, яростно клепая фичи и брызжа слюной.
И вот уже от тряски с них начинают падать штаны! Но у серьёзных компаний нет времени, чтобы без причины сбавлять скорость и начинать подтягивать свои сползающие штаны!
Со стороны это всё выглядит очень позитивно. Они краснеют, выкладываются на полную для того чтобы продолжать бежать с прежней скоростью, но спущенных штанов и развязанных шнурков вполне достаточно для того чтобы бег превратился в неуклюжую быструю ходьбу. Старушка с грузиками на лодыжках даёт им фору, но они всё ещё слишком заняты, чтобы сделать передышку и подтянуть эти штаны! И с прошлого раза ещё не наверстали!
И тут они начинают думать. Что же делать? Как решить проблему, не сбавляя скорости и не подтягивая лишний раз штаны? Начинается импровизация. Они пытаются прыгать. Кому-то в голову даже взбредает идея что нужно больше ног… =)
Я думаю, Вы уловили мысль. На самом деле, нужно всего лишь…
Надеюсь, что аналогия ясна и теперь Вы понимаете что происходит с закостенелой архитектурой и затхлым системным кодом.
Пока Вы несётесь со всей дури, Ваши шнурки развязываются, а с приложения неуклонно начинают спадать штаны, это всё нешуточно заставляет Вас тормозить.
И это будет ухудшаться до тех пор, пока Вы наконец не обнаружите, что на самом деле Вы двигаетесь назад.
К сожалению, у меня нет волшебного ответа. Если Вы можете ускориться, забив на архитектуру и дизайн системы в целом, то рано или поздно Вам придётся расплатиться и зарефакторить всё по-нормальному.
Возможно, Вы начнёте с нуля. Возможно, придётся объединить все свои силы, чтобы привести всё в порядок. В любом случае, Вам придётся остановиться. Хотя может быть кто-то пробовал завязывать шнурки на бегу? =)
Не печальтесь, Вы не сделали ничего плохого. Более того — Вы выжили в то время, когда другие были слишком бережными и провалились. Только не игнорируйте свои штаны, в которых Вы путаетесь на каждом шагу, сделайте что-нибудь страшное!
Прим. перев.: я не переводчик, я такой же как и все, поэтому вышел более-менее вольный перевод. Старался передать ироничность статьи. Об опечатках и недочётах пишите, пожалуйста, в личку. Спасибо за внимание и хорошего дня!
Задумайтесь об этом вопросе на секунду. Как так выходит, что чем дольше Вы что-либо разрабатываете, тем сложнее и неприятнее добавлять в Ваше приложение новые фичи, попиливать архитектуру?
И почему раньше задачи решались так просто, а теперь выглядят запутанными и сложнореализуемыми?
Казалось бы, положение должно улучшаться, ведь Вы уже давно в проекте, разве нет? Почему всё происходит наоборот?
В поисках ответов
Ну же, не стоит винить себя за то что ответы не всплывают у Вас в голове сами по себе, большинство разработчиков страдают тем же. Да и вопросы, согласитесь, не из лёгких.
Если бы мы знали ответы на все вопросы, то и проблем бы никаких не было.
Тем не менее Вы ещё не раз столкнётесь с менеджерами, заказчиками и даже другими разработчиками, которые безуспешно продолжают искать ответы на эти же вопросы.
И в первую очередь все начинают винить процесс. Ведь очевидно, что проблемы с процессом негативно влияют на скорость разработки.
В этом есть смысл. Тем не менее я обнаружил что зачастую не это является корнем Ваших проблем. Если команда не сидит сложа руки, а важные задачи правильно приоритезированы, то вероятнее всего процесс не виновен.
Я хочу чтобы Вы меня здесь правильно поняли. То есть две вещи, которые я упомянул — не единственные, что должны Вас волновать, я лишь пытаюсь сказать, что раз уж большую часть времени команда реально работает над действительно важными для проекта вещами, Вы никак не сможете волшебным образом наладить процессы, хоть как-то заметно увеличивая продуктивность разработки команды (в большинстве случаев).
Рассматриваются и такие варианты:
- Парное программирование?
- Сменим скрам на канбан?
- Разве мы не должны определять бэклог иначе?
- Может нам стоит использовать попугаев для оценки задач? Стори поинты? Или вообще пусть все бэклоги будут одинакового размера?
- Нам нужно больше девелоперов? Или бизнес аналитиков?
- Стоит ли реорганизовать команды?
Конечно, это всё замечательные вопросы, которые следует время от времени себе задавать, однако я постоянно убеждаюсь в том, что есть другая позабытая проблема побольше…
ВАШ КОД!
Давайте проведём небольшой эксперимент.
Забудем обо всех процессах, забудем о скраме и бэклогах и стори поинтах и всём-всём остальном.
Вы — Разработчик. Вам надо сделать поставленную Вам задачу, изменить кое-что в коде. Вы сидите один, нет никаких процессов, аналитиков. Только Вы и Ваша работа.
Можете подумать о чём-то, что Вы делали недавно или же разрабатываете прямо сейчас, я всего лишь хочу чтобы Вы абстрагировались от всего что напрямую не относится к дизайну или кодированию данной фичи.
Наверняка у Вас будут примерно такие мысли:
1. Эта фича имплементится быстро и просто, я знаю как и куда её добавить, всё будет тип-топ!
Вот так, замечательно! Выходит, на самом деле у Вас нет никаких проблем.
2. Что-то я не понимаю, что надо сделать. Как и где это будет использовано в системе?
Хм, в таком случае у Вас, скорее всего, присутствуют кое-какие проблемы с процессом. Может быть Вам нужна постановка задачи почётче или следует задать больше вопросов. Такое случается, правда. Идеи-полуфабрикаты попадают в процесс и кому-то определённо придётся побегать и пошевелить мозгами прежде чем разработчики на самом деле смогут заняться ими.
3. Я боюсь что-то менять, это почти невозможно. Прежде чем начать, понадобится копать в других частях приложения и разбираться: что, как и почему так работает (и как оно вообще должно работать).
Как не печально, но это наиболее вероятный исход. Что-то среднее между вторым и третим пунктом, потому что у них одна и та же причина — готовый код и либо усопшая, либо «её-нет» архитектура.
И я продолжаю сталкиваться с тем, что разработка большинства приложений замедляется из-за кода самих приложений или же утери оригинального дизайна.
Но подобные проблемы Вы увидите только в успешных компаниях, потому что…
Иногда необходимо бежать с развязанными шнурками
Было время, я консультировал пару провальных стартапов. И должен заметить, у них была одна общая черта (как в прочем и у большинства других стартапов): ноль проблем с кодом. Да-да, отличная кодовая база, причёсанная, ухоженная, пахнет приятно.
Я видел самую лучшую архитектуру и идеальный код в умерших стартапах.
Может быть это выглядит так, будто я противоречу сам себе. Сейчас поясню.
Проблема заключается в том, что стартапы со сверкающим кодом не поспевают за рынком. Они стоят на старте и завязывают красивые бантики на своих шнурках, оглядываются по сторонам и осторожно рассматривают каждое место куда собираются поставить ногу.
Что происходит? Они создают прекрасный код, клёвую архитектуру. Но слишком поздно. Конкуренты вырываются вперёд и двое обкофеиненных не-совсем-программистов-но-я-чуть-кодил бодро обходят Вас со своим приложением на VB6, написанным прошлой ночью на коленке. Да, может не совсем то, что хотел заказчик, но зато как оперативно!
Но что, я разве теперь утверждаю что надо написать салфеточный говнокод и быстренько сдать его, иначе провал?
Или я говорю, что нельзя выраситить успешную контору на хороших практиках и качественном коде?
Нет. Но я пытаюсь сказать что большинство успешных компаний в первую очередь вовремя сосредоточили свои усилия на заказчике и только затем на ПО.
Другими словами, если Вы взгляните на код десятка успешних компаний за последние лет пять, в 9 из них вы обнаружите дерьмовую архитектуру и систему весьма отдалённую от исходного дизайна и хороших манер.
Так, а что насчёт штанов?
Окей, к чему я всё это?
Компании-победители бегут и выживают! Однако и после 5 лет они всё ещё продолжают бежать изо всех сил и тут их некрасивые шнурки начинают развязываться.
Возможно, они даже не приметят, что их шнурки развязаны до тех пор пока пару раз не споткнутся о них. Чепуха, они всё ещё продолжают бежать. С одной стороны, это хорошо, ведь именно это делает их преуспевающими, а других, что решили остановиться и, оставшись далеко позади, завязать свои шнурочки, — позорно проигравшими.
Проблема обычно даёт о себе знать примерно после пяти лет непрерывного бега, когда компании решают что пора выходить на новый уровень. До сих пор у них неплохо выходило бежать, виляя из стороны в сторону и стараясь держать ноги достаточно раздвинутыми, чтобы реально не попасть на шнурки.
Это самую малость их тормозит и потому они продолжают бежать, яростно клепая фичи и брызжа слюной.
И вот уже от тряски с них начинают падать штаны! Но у серьёзных компаний нет времени, чтобы без причины сбавлять скорость и начинать подтягивать свои сползающие штаны!
Со стороны это всё выглядит очень позитивно. Они краснеют, выкладываются на полную для того чтобы продолжать бежать с прежней скоростью, но спущенных штанов и развязанных шнурков вполне достаточно для того чтобы бег превратился в неуклюжую быструю ходьбу. Старушка с грузиками на лодыжках даёт им фору, но они всё ещё слишком заняты, чтобы сделать передышку и подтянуть эти штаны! И с прошлого раза ещё не наверстали!
И тут они начинают думать. Что же делать? Как решить проблему, не сбавляя скорости и не подтягивая лишний раз штаны? Начинается импровизация. Они пытаются прыгать. Кому-то в голову даже взбредает идея что нужно больше ног… =)
Я думаю, Вы уловили мысль. На самом деле, нужно всего лишь…
Остановиться, завязать шнурки и подтянуть наконец свои штаны!
Надеюсь, что аналогия ясна и теперь Вы понимаете что происходит с закостенелой архитектурой и затхлым системным кодом.
Пока Вы несётесь со всей дури, Ваши шнурки развязываются, а с приложения неуклонно начинают спадать штаны, это всё нешуточно заставляет Вас тормозить.
И это будет ухудшаться до тех пор, пока Вы наконец не обнаружите, что на самом деле Вы двигаетесь назад.
К сожалению, у меня нет волшебного ответа. Если Вы можете ускориться, забив на архитектуру и дизайн системы в целом, то рано или поздно Вам придётся расплатиться и зарефакторить всё по-нормальному.
Возможно, Вы начнёте с нуля. Возможно, придётся объединить все свои силы, чтобы привести всё в порядок. В любом случае, Вам придётся остановиться. Хотя может быть кто-то пробовал завязывать шнурки на бегу? =)
Не печальтесь, Вы не сделали ничего плохого. Более того — Вы выжили в то время, когда другие были слишком бережными и провалились. Только не игнорируйте свои штаны, в которых Вы путаетесь на каждом шагу, сделайте что-нибудь страшное!
Прим. перев.: я не переводчик, я такой же как и все, поэтому вышел более-менее вольный перевод. Старался передать ироничность статьи. Об опечатках и недочётах пишите, пожалуйста, в личку. Спасибо за внимание и хорошего дня!