[БЕЗ_ЗВУКА] [БЕЗ_ЗВУКА] Итак, мы поняли проблему заказчика, выяснили требования к решению и предложили такое решение. Оно было принято, и мы проработали общее представление о том, как оно может быть реализовано. Теперь нам надо сделать проект, имея который специалисты, обладающие необходимой компетенцией, смогут его реализовать. Как же может быть организована работа над проектом? Практически при любом подходе к организации работы над проектом (если брать, конечно, примитивный code & fix), все этапы работы над проектом, описанные выше, все равно присутствуют, хотя и не всегда в явном виде. А code & fix — это когда мы просто начинаем кодить и исправляем что-то по месту, если что-то было не так. Здесь нет необходимости что-либо планировать, нет необходимости что-то документировать, разве что пост фактум. Поэтому code & fix требует минимальной квалификации разработчиков, соответственно, им можно платить меньше денег. Но у всего есть своя цена. Такой подход очень скоро приводит к тому, что код невозможно поддерживать. Исправление одной ошибки приводит к появлению нескольких новых. Внесение минимальных изменений в одну часть программы приводит к разрушению функций, реализуемых другими частями. Практически невозможно организовать работу над проектом уже даже малой командой. И в определенном смысле можно сказать, что все последующие развития методологии разработки выросли из стремления как-то решить эти проблемы. Так, каскадная модель подразумевает последовательное прохождение всех стадий, причем каждая из них должна быть полностью завершена до начала следующей. Поэтому эту модель иногда называют водопадом. Шаги могут называться по-разному, например, выявление и анализ требований, высокоуровневое проектирование, модульное проектирование, реализация тестирования, внедрение и эксплуатация. Это несколько иное, чем мы говорили, но суть от этого не меняется. Такой формат дает высокую скорость разработки, заранее взвесив стоимость и сроки выполнения работ, однако лишь в том случае, если требования к проекту, а также способы его реализации четко определены. Если же требования неточны, то их корректировки не предполагается, и о существующем недостатке можно узнать, только когда система уже полностью готова. Эту проблему решает так называемая V-модель. Здесь на каждом этапе происходит контроль текущего процесса, чтобы убедиться в возможности перехода к следующему, для чего при тестировании текущего уровня сразу разрабатывают стратегии тестирование следующего. Это подходит для малых и средних проектов, где требования четко определены и фиксированы, но требуется высокая надежность продукта. Инкрементная модель позволяет работать с неполными требованиями, когда основные требования определены и понятны, но и их детали должны быть уточнены. Тогда требования разбиваются на блоки, и для каждого блока запускается некий миниводопад. Это дает возможность быстро выпустить продукт с базовой функциональностью, а потом последовательно добавлять новые функции — инкременты. Спиральные модели проходят несколько витков спирали, на каждом из них производится планирование, анализ рисков, конструирование, оценка результата, и при удовлетворительном результате выполняется переход к новому витку. Эта модель похожа на инкременты, но с акцентом на анализе рисков. Она подходит для объемных и критически важных задач, где каждый следующий шаг поэтому требует трудоемкого анализа для оценки последствий. Например, при разработке банковских приложений, при выпуске новых продуктовых линеек, при необходимости научных исследований, при переходе к очередному этапу и так далее. Прототипная модель основана на реализации последовательной модели системы. Сначала создается исследовательский прототип, простейшая модель, которая представляется заказчику, чтобы убедиться, что его требования правильно поняты. Затем создается экспериментальный прототип, чтобы проверить приемлемость предполагаемых подходов к технологиям. Затем эволюционный прототип — фактически это уже готовый продукт, но в самом простом варианте, который может впоследствии улучшаться. При этом требования к качеству эволюционного прототипа уже такие же, как и у конечного продукта, а дальше наращивается его новый функционал. В последнее время в моду вошли так называемые гибкие (по-английски agile) методологии разработки. Так, Scrum заявляется как фреймворк, как каст при разработке, передаче и поддержке сложных продуктов. Считается, что в основе Scrum лежит теория эмпирического управления. В ней источником знаний является опыт, а источником решений — реальные данные. Методология основана на спринтах. Спринты представляют собой жестко заданные, небольшие по времени итерации разработки продукта. Над проектом работает одна универсальная команда. В ней столько разноплановых специалистов, сколько нужно для решения любой задачи проекта. Каждый день команда оценивает свои задачи и необходимые на них трудозатраты, выясняет проблему, с которыми столкнулась, и планирует, что надо сделать завтра. В основе Kanban та же гибкая методология разработки, предполагающая разбиение задач на мелкие части. Над задачей может работать несколько узкопрофильных команд. К примеру, сначала работают аналитики, потом дизайнеры готовят прототип, а на третьем этапе включаются разработчики. При этом универсальные команды тоже не запрещены. Методологии Scrum и Kanban обе следуют принципам бережливой, длинной и гибкой agile-разработки, используют втягивающиеся системы планирования, то есть задание не выдается исполнителю, а забирается им из перечня, стоящих в очереди. Планирование строится как результат обсуждения внутри команды с использованием досок с учетными карточками и минимизации используемой документации. Из-за особенностей реализации методологии Scrum часто используют в стартапах, а Kanban — для управления проектами и в стадии поддержки развития функциональности. Какова специфика использования гибких методологий? Гибкие методологии сейчас в моде, но при этом очень мало специалистов, которые понимают их идею и принципы применимости. Поэтому у некоторых разработчиков складывается впечатление, что это некая научно обоснованная легализация таких всем известных подходов, как «Что тут думать, трясти надо!», «По ходу дела разберемся» или возврат к любимому code & fix. А началось все с претензии к водопаду. Отличительная черта модели — ступенчатость, и вся работа по проекту жестко разделена на этапы. Они следуют один за другим в предопределенном порядке и никогда не перекрываются. Возвратов на более ранние ступени при разработке не предусмотрено. Но в водопаде два первых этапа являются критически важными, и мы говорили о том, что ошибки и выявления требований или направлений построения архитектуры потребуют переделки всей созданной системы. Но в классическом водопаде мы узнаем о том, что что-то было не так, лишь при испытаниях уже готовой системы. Поэтому цена ошибок, сделанных на начальном этапе может быть в десятки раз выше, чем на последующих. Тем не менее, водопадная модель хорошо работает, когда есть изученный образец системы и известна технология для реализации новой программы. А вот для новых задач такой подход оказывается неэффективным, как по указанным выше причинам, так и потому, что для новой задачи мы не можем точно предсказать трудоемкость работ по каждому этапу, тем более когда над проектом работает параллельно несколько команд. И вот у вас уже одна команда свою часть проекта сделала, ее вполне можно было бы запускать в работу, но по данной методологии надо дождаться, когда свою работу сделают все. И то же происходит на всех этапах. Мы разобрали, как в других методологиях пытаются обойти эту проблему, а agile представляется как некая волшебная пилюля, которая может решить эту проблему кардинально и сделать процесс разработки максимально эффективным. Но есть проблема. Если ты понимаешь, что именно надо сделать, то можно выполнять работу максимально гибко, изменять их очередность, приоритеты, менять места в зависимости от наличия ресурсов и даже по настроению, дожидаясь периодов наибольшей производительности. Но начинать что-то делать, не представляя результата деятельности, это большой риск. Представьте, что вы подрядились построить дом, а заказчик еще не решил, как он будет выглядеть, но при этом не хочет терять времени и говорит: «Ну вы начните пока делать фундамент». Какой фундамент вы будете делать, если не знаете, сколько будет этажей? Будете рассчитывать на меньшее число — может потребоваться все переделать. Сделаете с запасом — будут бессмысленно потрачены ресурсы и время. Считается, что в [НЕРАЗБОРЧИВО] проектах все несложно и в любой момент можно поправить. Но на самом деле последствия неверно выбранной архитектуры могут оказаться более чем существенными. И это то, что не работает в приложениях интернета вещей, которые завязаны на физическое оборудование, комплектующие, инфраструктуру и так далее. Поэтому гибкие методологии могут быть применимы и даже эффективны, если точно понятно, что и как надо сделать, а вопрос лишь в распределении ресурсов. И помните, мы говорили об этом, когда обсуждали архитектуру системы. Только если она существует и выстроена правильно, то любой элемент можно сделать независимо, а потом быть уверенным, что все вместе правильно соберется. А еще некоторые компания заявляют agile как некий формат работы с заказчиком, мол, вы говорите, что надо сделать, а мы вам сделаем. Аналогично, это работает, только если заказчик уже имеет на руках проект и четко понимает, что надо сделать. Либо он готов платить за ваше время и готов взять на себя все риски. Но обычно это не так. А то, что agile на слуху, позволяет недобросовестным или некомпетентным разработчикам получать заказ, не гарантируя заказчику ни результата, ни сроков, ни стоимости работ. Как же применить гибкие методологии в разработке приложений интернета вещей? Об этом мы поговорим в следующем видео.
