[БЕЗ_ЗВУКА] Добрый день, коллеги! В данном видео мы рассмотрим с вами 12 принципов Agile-манифеста, которые проистекают из четырех ценностей, которые мы рассмотрели в предыдущем видео. Начнем. Принцип № 1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения. Да, вы можете видеть, что эти принципы айтишные и направлены они как раз на разработку программного обеспечения. Но с этим мы ничего не можем поделать, потому что весь Agile вышел из IT. О чем же говорит нам этот принцип? Этот принцип говорит нам о том, что при разработке инновационных каких-то продуктов мы должны ориентироваться на своего потребителя. А как можно на него ориентироваться? В принципе, достаточно просто. Если вы можете показывать ему законченный, но не до конца, продукт, но этот продукт будет нести ему определенную ценность, то есть часть каких-то функций будет работать, ваш заказчик может дать вам обратную связь. И эта обратная связь, она может быть очень ценна, потому что вы лучше начнете понимать, что же конкретно нужно заказчику. А если вы понимаете, что конкретно нужно заказчику, значит вас ждет коммерческий успех по окончанию разработки этого продукта. Смысл простой. Принцип № 2 звучит так: изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. Но здесь пример может быть простой. Это конкурентное преимущество, когда мы работаем в принципе на коммерческом рынке, а представьте, что мы работаем на рынке с госзаказами? Представьте, что у меня есть госзаказ на год на разработку какого-то продукта. Все согласовано, написаны требования, но в какой-то момент меняется одно из законодательств и теперь отчетность какую-то надо делать совсем по-другому. Что делать? Если я сделаю продукт таким же образом, как написано было в изначальных документах, в изначальных требованиях, то этот продукт будет не нужен заказчику, потому что он не сможет под новое законодательство адаптировать его. Адаптировать его сразу — это будет хорошо, и это будет как раз по принципу № 2. Но тогда мы немножечко нарушим наш контракт. И это, кстати, один из вызовов, которые мы будем рассматривать в дальнейших видео. Но принцип 2 говорит нам о том, что требования, они всегда приветствуются, новые требования, изменения требований. Почему? Да потому что мир меняется. И с момента первого заказа, когда пришел к нам заказчик и попросил нас сделать продукт, уже что-то могло поменяться. Могло поменяться понимание заказчика об этом продукте, мог поменяться рынок, внешние факторы какие-то. И много всего. Перейдем к следующему принципу. Принцип № 3. Работающий продукт следует выпускать как можно чаще с периодичностью от пары недель до пары месяцев. Как часто мы могли бы наблюдать такую вещь, что делается продукт. Каждый человек делает какую-то свою часть. Пытаемся собрать все вместе — не работает. И мы тратим очень много времени на то, чтобы этот продукт заработал совместно. Это описывается термином, который называется «синергия». Отдельные модули, отдельные части какого-то продукта не соединяются вместе, не дают того эффекта, на дают вот этого усиливающего эффекта, когда продукт начинает нести какую-то отдельную новую ценность. Принцип 4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Для чего это надо? Мы же с вами манифестировали, что если у нас есть у разработчиков непосредственный доступ к заказчику, к представителю бизнесу, то тот может давать прямую обратную связь о том, мы движемся в правильную сторону или нет. Для этого как раз и считается, что надо, чтобы на одной площадке, где сидят разработчики были и представители бизнеса, и они работали плотно и достаточно много времени проводили вместе. Принцип № 5 звучит так: над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Этот вопрос связывает нас с многочисленными теориями мотивации. Мы немножко погрузимся в эту тему, когда будем разбирать кросс-функциональные самоорганизующиеся команды. Но здесь я вам скажу только одну вещь: если вы людям даете формулу собственного счастья, зависимую на деньги, люди будут эксплуатировать эту формулу. Если вы даете людям возможность на работе реализовать свой потенциал и не думать о каких-то деньгах, то тогда реализуют свой потенциал. Мы берем людей, мотивированных, заряженных, и наша задача с вами — это сделать так, чтобы их мотивация не растерялась. Мы обеспечиваем им условия работы, мы обеспечиваем поддержку с точки зрения руководства, с точки зрения заказчика, мы выпрямляем все коммуникации и полностью доверяем им то, как стоит делать продукт. И они будут делать продукт, лучший продукт. Принцип № 6 звучит так: непосредственное общение является наиболее практичным и эффективным способом обмена информации как с самой командой, так и внутри команды. Если мы с вами вспомним различные способы общения, такие как электронная почта, телефон, вербальное общение, то мы сможем их выстроить по скорости. Помните, что самая быстрая коммуникация у нас — она все-таки вербальная, с глазу на глаз. А еще лучше, если два человека, или три человека, или команда, которая общается вербально, они имели у себя фломастеры и какую-то доску, на которой могли бы визуализировать свои идеи. Это позволяет им обмениваться информацией быстро, а если мы хотим разрабатывать инновационные продукты, мы обязаны обмениваться информацией быстро. Об этом шестой принцип. Принцип № 7. Работающий продукт — основной показатель прогресса. Но это мы с вами еще видели в ценностях Agile. Как же так? В принципе, все просто: нет продукта — нет прогресса, есть продукт — есть прогресс. Иногда бывает сложно понять такую вот вещь: продукт можно разрабатывать долго, можно разрабатывать его полгода, год. Как же показать прогресс, что мы движемся куда-то? Для этого есть принципы итеративной икрементальной разработки. Мы их рассмотрим в следующих видео. А пока принцип № 7: мы меряем все работающим продуктом. Принцип № 8: разработчики, инвесторы и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки. Это очень сложный в переводе на русский язык принцип. Я бы здесь хотел использовать термин, который по-английски звучит так: sustainable pace. Это постоянный ритм, устойчивый ритм. Смысл его в чем? В том, что если мы в своих коммуникациях, в своем процессе работы входим в какой-то ритм, то, работая в этом ритме и поддерживая его, мы можем постоянно создавать новый продукт, искать на рынке тот самый продукт, который попадет в ожидание заказчика, взорвет рынок и обеспечит нам безбедную старость. Принцип № 9: постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. О чем это? О том, что в принципе команда, которая готовит новый продукт, которая делает новый продукт, она должна постоянно развиваться, постоянно повышать свою инженерную культуру. Повышение инженерной культуры говорит о том, что у нас будут развиваться и средства разработки, и повышаться качество продукта. Принцип 10: простота, искусство минимизации лишней работы — она крайне необходима. Здесь есть хорошая такая фраза, на английском она звучит так, есть аббревиатура, называется KISS: Keep It Simple Stupid («Делай это просто, глупышка»). В чем ее смысл? Ее смысл в том, что чем проще сделан ваш продукт, тем проще его поддерживать и изменять. Нам не надо делать универсалию, в универсалии она слишком сложна. Универсалия тяжело проектируется, универсалия тяжело делается, а потом вся наша универсальность разбивается очень легко любым требованием от клиента, которое не входит в изначальную идею, которая входила в продукт. Принцип 11: самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. О чем это? О том, что мы собираем людей, даем им возможность самим определить, каким образом они будут достигать целей, каким образом они будут делать тот или иной продукт. И они нам сделают самый лучшие технические решения. Просто в тот момент, когда мы даем им на откуп то, как они будут это все реализовывать, у них убирается Дамоклов меч любых контролей, которые связаны с применяемыми технологиями. И убирается давление, которое касалось сроков — люди начинают меньше вставлять в продукт так называемых костылей, каких-то подпорок, недоработанных элементов и тому подобного. Они делают то, как инженер хочет сделать сам — не так, как в прошлый раз, когда его очень сильно просили сделать все за в два раза меньшее время. Они начинают это делать правильно, так, как это было задумано людьми, которые придумали средства разработки, например. И принцип 12: команда должна систематически анализировать возможные способы улучшения эффективности и, соответственно, корректировать стиль своей работы. О чем это? О том, что если у нас есть время, чтобы оглянуться назад, посмотреть, как мы работали и придумать что-то, что может улучшить нашу работу в будущем, давайте это будем использовать. Давайте выделим под это конкретное время и будем постоянно развиваться, совершенствовать принципы своей работы, совершенствовать свои инструменты и так далее. Это были 12 принципов. Где можно прочитать про ценности Agile и принципе Agile? Это можно самостоятельно почитать на сайте agilemanifesto.org. Там детально описан процесс появления этого Agile-манифеста, сам Agile-манифест, его переводы на разные языки и те 12 принципов, которые мы рассмотрели в этом видео. А куда же можем двигать дальше? Здесь есть очень интересная штука. После появления Agile-манифеста, как только начали развиваться Agile-подходы, разные люди и разные компании стали адаптировать их для себя. Например. компания IBM выпустила свой IBM Agile Manifesto. Они пересмотрели эти ценности в рамках своей корпоративной культуры. Есть определенные сообщества людей, которые выпустили Agile Manifesto новый версии: 2.0, 2.1 Можете почитать, я привел здесь ссылки в этой презентации. Маркетологи придумали свой Agile-манифест и подобное. Именно это, с одной стороны, вроде бы гибко, а с другой стороны, это порождает определенные неясности. Нету какой-то организации, которая развивает Agile-манифест, поддерживает его или дает нам четкое определение, что же такое Agile. Здесь каждый — кто во что горазд и придумывает свое. Именно это порождает иногда очень неприятные ситуации, когда людям под брендом Agile непонятно какие вещи объясняют. Но мы с вами будем пользоваться классическим манифестом и будем отталкиваться именно от него в нашем курсе. А теперь давайте сделаем небольшой интерактив. У меня к вам вопрос, а вы задумайтесь. Коллеги, какой принцип Agile-манифеста нарушается, когда архитектору крупного проекта потребуется несколько недель, для того чтобы продумать все возможные схемы работы приложения, разработать универсальную архитектуру, покрывающую все возможные потребности под будущий продукт. Следующий вопрос. Какой принцип Agile-манифеста нарушается, когда команды разработки демонстрируют заказчику спроектированные таблицы базы данных или какие-то сделанные запчасти продукта, показывая свой прогресс по разработке? И следующий вопрос. Какой принцип Agile-манифеста был нарушен, когда в результате длительной разработки продукт очень долго не могли собрать вместе? Было большое количество несостыковок разных компонентов или запасных частей. На этом все. До свидания. Встретимся в новом видео. [ЗВУК]