Если вы «в теме», такие термины, как Agile и Scrum, для вас не в новинку — техники и методы, с ними связанные, используют Microsoft, Google, Yahoo, Accenture и десятки других лидеров индустрии. Если вы планируете работать в IT-индустрии, вы не можете себе позволить не знать про методики Agile. Это не просто новый модный тренд. С их помощью делаются дела.
Agile — командная игра
Прежде чем р азговаривать, надо определиться с терминами. Agile, Scrum, Extreme Programming и Lean Development часто упоминают, имея в виду одно и то же, или почти одно и то же. Однако разница есть. Agile — это набор принципов и методик для разработки какого-либо продукта; Scrum — это инструментарий для организации проекта по созданию чего-либо; Lean
Development описывает принципы работы всего предприятия, которое исповедует Agile. Ну а Extreme Programming — это одна из техник для создания программного обеспечения в рамках Agile. Fail fast, fix fast, learn quickly Scrum — один из наиболее популярных методов Agile («эджайл») пришёл в США и Европу из Японии, где первой его на практике применила Toyota ещё в 80-х годах прошлого века.
В основе всех методик Agile лежит один простой принцип: мы должны не говорить о деле, а делать дело. Не документация, а готовый продукт. Не картинки, а реально работающие макеты. Не группы из ста человек с десятью начальниками, а команды из 6–8 людей без явного лидера. Не жёсткая иерархическая структура типа «я начальник — ты дурак», а самоорганизовывающаяся и самомотивирующаяся команда, которая несёт полную ответственность за собственную работу.
Звучит как забавная сказка? Главный фокус Agile заключается в том, что эти методики не были придуманы теоретиками и насильно внедрены в реальные компании. Всё, что они описывают, действительно работает на практике. Более того, сначала у кого-то это получилось воплотить на практике, а уже потом это было описано в разных методиках.
Зане Сегрума,
Quality Working Group Lead компании Accenture
Agile в сравнении с Waterfall
В традиционных методиках, например, Waterfall, всё прямолинейно — там написано, что за чем идёт и какую задачу кто, когда и после чего должен выполнять. В Agile всё наоборот: там есть фреймворк (Scrum), который определяет главные принципы работы, но в него заложена идея интерактивности — ты не должен планировать весь проект до конца, так как не знаешь, что произойдёт через полгода или год, что и как повлияет на какие-то процессы. Ты всё время работаешь с итерациями и если видишь какие-то проблемы, то реагируешь немедленно. А не так, что три месяца назад что-то было придумано, сейчас мы воплотили это в коде, а через полгода поняли, что это не работает или работает не так, как рассчитывали изначально.
В Waterfall есть менеджер проекта, который отвечает за принятие решений и планирование. Там также есть аналитики, которые придумали, как оно всё должно работать. Так что если ты просто разработчик, то ты должен двигаться в том направлении и работать над таким решением, которое за тебя выбрал кто-то другой. А в Agile все работают вместе как команда, каждый может приходить со своими идеями и участвовать в общем обсуждении. Для большинства людей отсутствие «начальника», который спускает задания сверху, является дополнительной мотивацией. Их воодушевляет то, что из ста имеющихся заданий они сами могут выбрать то, что им по душе. Такой подход является бонусом для людей, так как они решают и выбирают, они гораздо больше вовлечены в процесс.
В отличие от Waterfall, в Agile команда должна уметь сама организовать свою работу. Даже если это не получается очень хорошо в первый раз, команда учится достаточно быстро. Если в такой команде есть какой-то человек, который часто опаздывает, срывает все сроки, занимается не тем, чем надо, то вся команда через процесс постоянного общения подталкивает его и мотивирует работать. Неудача одного — это неудача всей команды, и команда обычно не допускает таких провалов. По крайней мере, она кровно заинтересована их не допустить. Когда начинается любой проект, клиент должен определить, что он хочет получить на выходе. Но бизнес клиента тоже не статичен — у них постоянно появляются новые сервисы, услуги. И система должна это поддерживать. По Waterfall нередко получается так, что клиент должен предсказать, как он будет работать через год-полтора. И всё то новое, что у него появится за это время, автоматически оказывается вне фокуса проекта. В Agile можно манипулировать User Story и добавлять новшества хоть после каждого спринта, в зависимости от приоритетов клиента.
Плюс в Agile клиент начинает работать с системой уже после первого-второго спринта, а не через год или два после начала проекта. Ошибки быстро исправляются, и на свет выходит готовый продукт. Кому-то может показаться, что Agile — это «метод научного тыка», но на самом деле ничего общего он с ним не имеет. Никакого хаоса нет и в помине. Просто документация создаётся по факту наличия готового продукта, и работающий прототип в данном случае гораздо важнее файла или файлов с сотнями страниц текста.
Это относительно новый подход, и он настолько свеж, что у него отсутствует устоявшаяся «официальная» терминология на русском языке. Потому, увы, без небольшого количества сленга и англицизмов не обойтись.
Белки в колесе
Суть Agile лучше всего познаётся на конкретном примере. Давайте посмотрим, как Scrum, один из самых популярных фреймворков Agile, рекомендует (но не требует!) работать. В основе Scrum лежит Sprint — период концентрированного усилия команды. В команду входит 6–8 разработчиков (программисты, тестеры, аналитики и т. д.), без явной субординации. В команде три глобальные роли — «член команды», Scrum Master и Product Owner. Последний представляет заказчика, пишет User Story и определяет их приоритет. Команда же в рамках этих «историй» определяет «таски» на каждый конкретный Sprint.
User Story заказчик формирует ещё до начала проекта — из них складывается так называемый Product Backlog — большое хранилище того, что надо сделать в течение всего проекта. Перед каждым спринтом команда формирует Sprint Backlog — список задач, которые должны быть сделаны во время конкретного спринта. Особо подчеркнём, что спринт не может быть продлён — это строго фиксированный отрезок времени. Если команда не успевает реализовать все задачи, они просто переносятся из Sprint Backlog обратно в общий пул задач (Product Backlog).
Каждый день в течение спринта скрам-мастер собирает команду на 10–15-минутные планёрки, во время которых каждый участник команды рассказывает о том, что он сделал за прошлый рабочий день, что он собирается делать сегодня и с какими он проблемами столкнулся. По завершении спринта проводится общий ретроспективный митинг, на котором команда (и те, кто пожелают присутствовать, хотя бы заказчик) обсуждает уже весь спринт и говорит на более глобальном уровне. Говорить во время этой встречи могут только и исключительно члены команды.
Итогом спринта _всегда_ является некий билд — работающий продукт или его часть, то, что сразу же начинает приносить пользу заказчику. Это правило является обязательным — закончившийся спринт всегда оставляет после себя что-то уже готовое. Исключением не является и т. н. «нулевой спринт» — неделя или две, в рамках которой настраивается рабочая среда, определяются основные инструменты и общая архитектура, то есть закладывается фундамент проекта. Просто в этом случае «продуктом» является среда разработки.
Важно то, что задания из Sprint Backlog не «спускаются сверху» — каждый может и должен сам выбрать то, чем он хочет заниматься. Более того — на самом деле каждый определяет эти задачи во время планирования всего спринта. Скрам-мастер ни в коем случае не является менеджером проекта — в его задачу не входит что-то кому-то навязать, он лишь координирует деятельность команды и подталкивает её в нужном направлении
Agile development — набор методов и инструментов, которые позволяют разрабатывать проекты в условиях, когда требования заказчика могут часто меняться. Примеры методов включают в себя Scrum и экстремальное программирование.
Scrum — принципы организации проекта в рамках методики Agile. Изначально термин пришёл из игры регби. Там «скрам» — это построение игроков, во время которого команда движется плечом к плечу, защищая мяч, и вместе проносит его на сторону противника. Впервые было использовано в статье в журнале Harvard Business Review, в которой описывались успешные методики работы, применяемые в Японии.
Sprint — одна итерация или цикл работ над проектом. Весь проект состоит из множества спринтов. Термин пришёл из лёгкой атлетики, где он означает быстрый бег на короткие дистанции. Примерно также можно описать работу во время спринта — очень быстро и очень интенсивно, но сравнительно недолго. Спринт длится 2–4 недели.
Sprint planning meeting — в начале каждого спринта команда проекта собирается вместе и выбирает ту функциональность (User Stories), что должна быть имплементирована в течение спринта. Одновременно каждая User Story разбивается на задачи, которые необходимо выполнить в течение спринта.
Stand-up meeting — ежедневная планёрка, в рамках которой скрам-мастер и команда разработчиков обсуждают, что сделано, что надо сделать и какие проблемы возникли. Обычно проводится в начале рабочего дня в течение 10–15 минут. «Stand-up», потому что во время встречи все обязаны стоять. В первую очередь для того, чтобы собрание не затянулось. Да и во вторую очередь тоже для этого же.
Основная задача скрам-мастера — обеспечить инфраструктуру для нормальной работы команды, планирования и ежедневных летучек, направить команду в нужном направлении. Раньше я не верил, что команда может быть самоорганизованной, считал, что есть сильный лидер и более опытные разработчики, которые принимают решения. Но оказалось, что в Scrum это работает и решения принимает вся команда. Скрам-мастер должен так построить диалог, чтобы люди раскрепостились и начали участвовать в дискуссии. Иногда это может быть непростой задачей.
В команде каждый день идёт дискуссия о том, как та или иная задача может быть реализована. Происходит это на так называемых Stand-up meeting — ежедневных коротких встречах, летучках, на которых каждый рассказывает, что он делал вчера, что собирается делать сегодня, какие проблемы возникают. Проводятся они для того, чтобы вся команда знала, кто чем занимается и кто кому чем может помочь. Встречи не должны превышать 15 минут, и на самом деле за эти 10–15 минут можно решить очень многое. В Agile/Scrum важно, чтобы все в команде понимали, что все мы делаем одно дело и все несём за него ответственность.
Что касается разработчиков, то это заблуждение, что Agile требует суперпрофи. Мы не рок-звёзды, мы — реальные люди, чудес не бывает. Хотя в прессе и литературе очень часто пишут, что Agile работает только в том случае, если разработчики исключительно опытны. Из моей реальной практики — это не совсем верно. В принципе, я встречался с некоторыми разработчиками, которые не приемлют идеи Agile. Им нужна чёткая спецификация и указания сверху. Но это исключение.
И когда программист выбирает задание и понимает, что все решения в рамках задания он может выбирать сам, то работник начинает делать всё быстрее и лучше. Эту атмосферу сложно передать, когда работа становится действительно cool, а не повинностью, как это иногда случается в длинных, скучных, затяжных проектах. Абсолютное большинство тех, кто поработал в agile-проектах, не хотят возвращаться к более традиционным методикам. Это отлично видно по реакции людей. И это — повод задуматься всем тем, кто никогда не работал по методикам Agile.
Scrum — практик о практике
Владимир Тихомиров,
старший системный аналитик компании Accenture,
сертифицированный ScrumMaster
Основная задача скрам-мастера — обеспечить инфраструктуру для нормальной работы команды, планирования и ежедневных летучек, направить команду в нужном направлении. Раньше я не верил, что команда может быть самоорганизованной, считал, что есть сильный лидер и более опытные разработчики, которые принимают решения. Но оказалось, что в Scrum это работает и решения принимает вся команда. Скрам-мастер должен так построить диалог, чтобы люди раскрепостились и начали участвовать в дискуссии. Иногда это может быть непростой задачей.
В команде каждый день идёт дискуссия о том, как та или иная задача может быть реализована. Происходит это на так называемых Stand-up meeting — ежедневных коротких встречах, летучках, на которых каждый рассказывает, что он делал вчера, что собирается делать сегодня, какие проблемы возникают. Проводятся они для того, чтобы вся команда знала, кто чем занимается и кто кому чем может помочь. Встречи не должны превышать 15 минут, и на самом деле за эти 10–15 минут можно решить очень многое. В Agile/Scrum важно, чтобы все в команде понимали, что все мы делаем одно дело и все несём за него ответственность.
Что касается разработчиков, то это заблуждение, что Agile требует суперпрофи. Мы не рок-звёзды, мы — реальные люди, чудес не бывает. Хотя в прессе и литературе очень часто пишут, что Agile работает только в том случае, если разработчики исключительно опытны. Из моей реальной практики — это не совсем верно. В принципе, я встречался с некоторыми разработчиками, которые не приемлют идеи Agile. Им нужна чёткая спецификация и указания сверху. Но это исключение. И когда программист выбирает задание и понимает, что все решения в рамках задания он может выбирать сам, то работник начинает делать всё быстрее и лучше. Эту атмосферу сложно передать, когда работа становится действительно cool, а не повинностью, как это иногда случается в длинных, скучных, затяжных проектах.
Абсолютное большинство тех, кто поработал в agile-проектах, не хотят возвращаться к более традиционным методикам. Это отлично видно по реакции людей. И это — повод задуматься всем тем, кто никогда не работал по методикам Agile.
Таким образом команда сама себе создаёт и выбирает задания (из ею же созданного списка) и сама же контролирует их выполнение — если какой-то человек постоянно опаздывает или «не тянет», он, вопервых, сам начнёт это чувствовать.
А во-вторых, команда будет явно или неявно «давить» на него — в скраме нет понятия «я», есть — «мы». «Мы не успеваем», все успехи и неудачи общие, но не индивидуальные.. О бедном заказчике замолвите слово…
Scrum требует от заказчика нести ответственность за проект наравне с разработчиком. Если в более традиционных методиках заказчик что-то там запрашивает и потом может ждать результата много месяцев и не имеет особого влияния на ход проекта, то здесь от него требуется очень высокий уровень интерактивности. Во-первых, он должен регулярно формировать Product Backlog, а во-вторых, быстро говорить «да» или «нет» (и отвечать более развёрнуто на более сложные вопросы), когда разработчики предлагают ему какие-либо решения.
Это требует высокого уровня компетентности от, как правило, одного человека, потому что только заказчик знает, что ему действительно нужно. И чем плотнее он взаимодействуетс разработчиками и чем лучше контакт, тем больше выгоды в итоге получат все участники и тем плодотворнее будет сотрудничество. Бизнес не статичен, и понятно, что у заказчика могут меняться приоритеты.
Например, в начале проекта для заказчика была более актуальна работа с частными клиентами, а через три месяца вдруг стало важным развить корпоративное направление. В случае с традиционными техниками ведения проектов он не может никак повлиять на разработку — разве что через практику change request после окончания проекта, и это будет (по крайней мере
— может) стоить серьёзных денег. В случае с Agile он может не просто менять приоритеты, но и давать принципиально новые задания, такие, о которых в начале проекта и речи не было. В этом случае из общего пула User Story выкидываются менее приоритетные задачи и заменяются новыми, более важными. Ничего подобного в случае с более традиционным подходом к разработке сделать нельзя.
Скрам-мастер — кто он?
Как мы уже сказали выше, скрам-мастера нельзя называть менеджером проекта. Во-первых, потому, что он не несёт глобальной ответственности за выполнение заданий проекта. Во-вторых, скрам-мастер — это просто одна из ролей. Одновременно этот человек является полноценным членом команды, может и должен выполнять другие обязанности и всячески помогать команде. Исключением являются действительно масштабные проекты, в рамках которых создаются т. н. scrum of scrums — скрамы скрам-мастеров, на которых они интегрируют
проделанную их командами работу и обсуждают проект на более глобальном уровне.
В общем и целом скрам-мастер — это наставник и модератор в одном лице. Он обеспечивает наилучшие условия работы для команды, оберегает её от давления извне (со стороны заказчика прежде всего), решает текущие административные или хозяйственные проблемы и направляет дискуссию и работу в нужное русло. Если кто-то на планёрках не раскрывается
и молчит, скрам-мастер должен разговорить этого человека.
В общем и целом в его задачу входит сделать так, чтобы от спринта к
Глоссарий
Sprint Retrospective — ежемесячная планёрка членов команды, на которой обсуждаются итоги каждого спринта. В теории должна отнимать не более трёх или четырёх часов времени.
Sprint Review — ежемесячная встреча между разработчиками, их руководством и представителем заказчика, на котором команда показывает, что было сделано в течение последнего спринта, и демонстрирует работающий продукт.
Product Backlog — список заданий (to do list) для всего продукта. Содержит User Story и прочие задания, связанные с User Story. Размер заданий должен быть таким, чтобы каждое из них можно было сделать не более чем за 8 часов. За наполнение Product Backlog перед началом проекта отвечает Product Owner. Добавлять задания в уже утверждённый Product Backlog можно только ценой удаления оттуда чего-то менее важного.
Sprint Backlog — список заданий (to do list) для каждого конкретного спринта. Как правило, в него включены задания с наивысшим для представителя заказчика приоритетом. Определяется командой разработчиков перед каждым спринтом. После утверждения и начала спринта никакие задачи в нём не могут быть заменены до следующего спринта.
Product Owner — лицо, ответственное за содержимое Product Backlog и Sprint Backlog, принимающее решение с точки зрения бизнес-целесообразности. Обычно это представитель заказчика, но иногда это может быть и сотрудник в самой компании-исполнителе или консультант.
«Сострадание — это не просто добрая воля, но готовность к созданию долговременных отношений, готовность принять и вынашивать точки зрения разработчиков, менеджеров и клиентов, с любым из которых вы можете быть не согласны, чтобы помочь им найти пути к принятию друг друга и созданию сообщества…».(Питер Мерел, «The Tao of Extreme Programming»).
Agile — специфика обучения
Борис Мишнёв,
проректор, профессор Института транспорта и связи
Оформление «гибкой разработки» (Agile, в частности) как технологии, которую можно совершенствовать, которой можно обучать и широко пользоваться, является самостоятельной, отдельной проблемой.
Да, все «тяжёлые» и хорошо документированные технологии потребляют значительные ресурсы, которые выделяет спонсор проекта (заказчик — Прим. ред). Но плюс такого подхода в том, что владельцем этих устойчивых процессов («know how») в значительной степени остаётся само предприятие. Эти процессы не только документируются, но и количественно анализируются. Есть, что изучать и с чем сравнивать текущие успехи новой разработки.
При различных вариантах «гибкой разработки» носителями технологии всё равно являются сами разработчики (они оценивают ситуацию, принимают гибкое решения для каждого отдельного случая и общаются с заказчиком). Если это всё не формализовано и не документировано, то не может быть отделено от разработчиков и самостоятельно использоваться. Здесь работает конкретная команда, состоящая из разработчиков с уже имеющимся успешным опытом такой разработки. А если такой команды нет, то совсем непонятно, как её можно создать за необходимое время (как правило, очень маленькое время до начала активной разработки продукта).
Единственно эффективным способом обучения нового и способного разработчика остаётся его реальное участие в таком, уже успешном проекте. Всё решают люди! Особенно нужно отметить, что принципиальным условием возможности быстро вести разработку на основе совершенствования работающих версий является наличие качественной и супербыстрой обратной связи от заказчика. Кто-то должен всё время «рассказывать истории» и оценивать результаты. Это — обязательное требование всех «гибких технологий». Есть свои проблемы и с «быстрой» разработкой больших проектов, когда задействуются десятки и сотни разработчиков.
Резюмируя, можно сказать, что имея слаженную команду высококвалифицированных разработчиков, обученных одной из «гибких» технологий, можно успешно реализовывать проекты малой и средней сложности при наличии уже частично готовых решений («внутренних стандартов»). Конечно, и все вспомогательные средства проекта должны быть гибкими и легко доступными. Что касается обучения технологиям «гибкой разработки», то основной акцент здесь должен быть сделан на понимании различных форм ведения процессов разработки.
Поэтому производители ПО сегодня уделяют особое внимание специальным средствам коммуникации как между членами команды, так и с заказчиком. Другими словами, гибкость достигается в значительной мере за счёт «коллективного разума», который очень плохо поддаётся формализации и для успешной реализации требует специально созданных условий и усилий.спринту команда показывала постоянно высокую производительность при минимальном количестве возможных проблем.
Только маленькие проекты?
Выше мы уже упомянули про scrum of scrums. И действительно, такие компании, как Microsoft или Google, оперируют проектами, в которых могут быть заняты сотни программистов. Машиностроительные компании, особенно в Японии, также исповедуют Scrum. И в то же время они применяют техники Agile — значит, это возможно?
Да, возможно. Главный принцип Scrum — команда не может превышать восемь человек. Если проект слишком большой и там заняты десятки людей, значит, создаются скрамы более высокого уровня и ещё более высокого уровня — получается этакое разветвлённое дерево. При этом, заметим, от традиционной иерархической пирамиды её отличает то, что каждая команда сама несёт ответственность за свою работу и сама выбирает очерёдность заданий. А также то, что практически все участники проекта знают о том, что делают соседи (общий пул заданий виден всем). При этом каждая команда может выполнять самые разные задачи и работать с разными частями проекта.
Специалисты говорят, что когда люди понимают, что происходит, и видят, как их работа влияет на результат, их мотивация тут же растёт. От частного вновь к общему Теперь, когда у читателя сложилось представление о том, как выглядит agile-проект, мы можем вернуться к более общим вопросам. Например, проблема документации. Может сложиться такое впечатление, что в случае использования Agile сопроводительных бумаг не бывает в принципе. Это не совсем так. В большинстве случаев документация пишется, но только после того, как получен конкретный результат (иногда бывает так, что документ очень важен для заказчика, тогда может быть и наоборот). И её должно быть ровно столько, чтобы хватало для понимания того, как оно всё тут работает или устроено. Перед созданием документа разработчики задают вопросы: «Доживёт ли он до конца проекта?», «Увеличивают ли эти документы ценность проекта для заказчика?». Если ответ отрицательный, такой документ никому не нужен. Ещё один важный момент — тестирование.
В рамках Agile обычно создаётся тестовая среда, через которую «прогоняют» весь созданный код сразу после выполнения конкретных задач. После добавления кода в репозиторий весь проект автоматически «перестраивается» и вновь запускаются тесты — чтобы быть уверенным в том, что новая или изменённая функциональность не создаёт фатальных ошибок в работе проекта. Создание тестов до кода, парное программирование и прочие методики т. н. экстремального программирования являются неотъемлемой частью Agile.
Поскольку во всей статье мы говорим о разработке программного обеспечения, можно подумать, что Agile и Scrum применяются только в этой сфере. Вовсе нет. Применять подобный метод можно где угодно: начиная от выпуска журнала (как раз идеальный с точки зрения всех методик период выпуска в 30 дней) и заканчивая поддержкой уже существующих продуктов и систем, машиностроением и т. д. и т. п. Коротко говоря, везде, где речь идёт о создании чего-либо, можно применять методы Agile. ! «Agile не определяется набором практик и техник. Она определяет стратегическую способность, способность создавать и реагировать на изменения, способность найти баланс между гибкостью и структурой, способность выявлять инновационное мышление в команде разработчиков и способность вести организации в условиях неопределённости». (Джим Хайсмит в книге «Agile Software Development Ecosystems»).
Принципы в основе Agile Manifesto
Наш самый высокий приоритет — удовлетворение клиента через раннее и постоянное создание ценного программного обеспечения. Мы приветствуем изменение требований даже в поздних стадиях разработки. Процессы agile поддерживают изменения для получения заказчиком конкурентных преимуществ.
Надо выпускать рабочие версии программ часто, в период от пары недель до пары месяцев с приоритетом на более короткие сроки. Разработчики и менеджеры должны работать вместе ежедневно на протяжении всего проекта.
Стройте проекты вокруг мотивированных личностей. Дайте им среду, поддерживайте всем необходимым и верьте, что они сами сделают всё, что нужно.
Самый действенный и эффективный метод передачи информации в команде разработчиков — это личное общение.
Работающее программное обеспечение — самое главное определение прогресса.
Процессы agile поощряют постоянную разработку. Спонсоры, разработчики и пользователи должны идти в ногу бесконечно долго.
Постоянное внимание к техническому совершенству и хорошему дизайну повышают выносливость.
Простота — искусство максимизировать количество несделанной работы — абсолютно критична.
Лучшие архитектура, требования и дизайн появляются на свет усилиями самоорганизующихся команд.
Agile — командная игра
Прежде чем р азговаривать, надо определиться с терминами. Agile, Scrum, Extreme Programming и Lean Development часто упоминают, имея в виду одно и то же, или почти одно и то же. Однако разница есть. Agile — это набор принципов и методик для разработки какого-либо продукта; Scrum — это инструментарий для организации проекта по созданию чего-либо; Lean
Development описывает принципы работы всего предприятия, которое исповедует Agile. Ну а Extreme Programming — это одна из техник для создания программного обеспечения в рамках Agile. Fail fast, fix fast, learn quickly Scrum — один из наиболее популярных методов Agile («эджайл») пришёл в США и Европу из Японии, где первой его на практике применила Toyota ещё в 80-х годах прошлого века.
В основе всех методик Agile лежит один простой принцип: мы должны не говорить о деле, а делать дело. Не документация, а готовый продукт. Не картинки, а реально работающие макеты. Не группы из ста человек с десятью начальниками, а команды из 6–8 людей без явного лидера. Не жёсткая иерархическая структура типа «я начальник — ты дурак», а самоорганизовывающаяся и самомотивирующаяся команда, которая несёт полную ответственность за собственную работу.
Звучит как забавная сказка? Главный фокус Agile заключается в том, что эти методики не были придуманы теоретиками и насильно внедрены в реальные компании. Всё, что они описывают, действительно работает на практике. Более того, сначала у кого-то это получилось воплотить на практике, а уже потом это было описано в разных методиках.
Зане Сегрума,
Quality Working Group Lead компании Accenture
Agile в сравнении с Waterfall
В традиционных методиках, например, Waterfall, всё прямолинейно — там написано, что за чем идёт и какую задачу кто, когда и после чего должен выполнять. В Agile всё наоборот: там есть фреймворк (Scrum), который определяет главные принципы работы, но в него заложена идея интерактивности — ты не должен планировать весь проект до конца, так как не знаешь, что произойдёт через полгода или год, что и как повлияет на какие-то процессы. Ты всё время работаешь с итерациями и если видишь какие-то проблемы, то реагируешь немедленно. А не так, что три месяца назад что-то было придумано, сейчас мы воплотили это в коде, а через полгода поняли, что это не работает или работает не так, как рассчитывали изначально.
В Waterfall есть менеджер проекта, который отвечает за принятие решений и планирование. Там также есть аналитики, которые придумали, как оно всё должно работать. Так что если ты просто разработчик, то ты должен двигаться в том направлении и работать над таким решением, которое за тебя выбрал кто-то другой. А в Agile все работают вместе как команда, каждый может приходить со своими идеями и участвовать в общем обсуждении. Для большинства людей отсутствие «начальника», который спускает задания сверху, является дополнительной мотивацией. Их воодушевляет то, что из ста имеющихся заданий они сами могут выбрать то, что им по душе. Такой подход является бонусом для людей, так как они решают и выбирают, они гораздо больше вовлечены в процесс.
В отличие от Waterfall, в Agile команда должна уметь сама организовать свою работу. Даже если это не получается очень хорошо в первый раз, команда учится достаточно быстро. Если в такой команде есть какой-то человек, который часто опаздывает, срывает все сроки, занимается не тем, чем надо, то вся команда через процесс постоянного общения подталкивает его и мотивирует работать. Неудача одного — это неудача всей команды, и команда обычно не допускает таких провалов. По крайней мере, она кровно заинтересована их не допустить. Когда начинается любой проект, клиент должен определить, что он хочет получить на выходе. Но бизнес клиента тоже не статичен — у них постоянно появляются новые сервисы, услуги. И система должна это поддерживать. По Waterfall нередко получается так, что клиент должен предсказать, как он будет работать через год-полтора. И всё то новое, что у него появится за это время, автоматически оказывается вне фокуса проекта. В Agile можно манипулировать User Story и добавлять новшества хоть после каждого спринта, в зависимости от приоритетов клиента.
Плюс в Agile клиент начинает работать с системой уже после первого-второго спринта, а не через год или два после начала проекта. Ошибки быстро исправляются, и на свет выходит готовый продукт. Кому-то может показаться, что Agile — это «метод научного тыка», но на самом деле ничего общего он с ним не имеет. Никакого хаоса нет и в помине. Просто документация создаётся по факту наличия готового продукта, и работающий прототип в данном случае гораздо важнее файла или файлов с сотнями страниц текста.
Это относительно новый подход, и он настолько свеж, что у него отсутствует устоявшаяся «официальная» терминология на русском языке. Потому, увы, без небольшого количества сленга и англицизмов не обойтись.
Белки в колесе
Суть Agile лучше всего познаётся на конкретном примере. Давайте посмотрим, как Scrum, один из самых популярных фреймворков Agile, рекомендует (но не требует!) работать. В основе Scrum лежит Sprint — период концентрированного усилия команды. В команду входит 6–8 разработчиков (программисты, тестеры, аналитики и т. д.), без явной субординации. В команде три глобальные роли — «член команды», Scrum Master и Product Owner. Последний представляет заказчика, пишет User Story и определяет их приоритет. Команда же в рамках этих «историй» определяет «таски» на каждый конкретный Sprint.
User Story заказчик формирует ещё до начала проекта — из них складывается так называемый Product Backlog — большое хранилище того, что надо сделать в течение всего проекта. Перед каждым спринтом команда формирует Sprint Backlog — список задач, которые должны быть сделаны во время конкретного спринта. Особо подчеркнём, что спринт не может быть продлён — это строго фиксированный отрезок времени. Если команда не успевает реализовать все задачи, они просто переносятся из Sprint Backlog обратно в общий пул задач (Product Backlog).
Каждый день в течение спринта скрам-мастер собирает команду на 10–15-минутные планёрки, во время которых каждый участник команды рассказывает о том, что он сделал за прошлый рабочий день, что он собирается делать сегодня и с какими он проблемами столкнулся. По завершении спринта проводится общий ретроспективный митинг, на котором команда (и те, кто пожелают присутствовать, хотя бы заказчик) обсуждает уже весь спринт и говорит на более глобальном уровне. Говорить во время этой встречи могут только и исключительно члены команды.
Итогом спринта _всегда_ является некий билд — работающий продукт или его часть, то, что сразу же начинает приносить пользу заказчику. Это правило является обязательным — закончившийся спринт всегда оставляет после себя что-то уже готовое. Исключением не является и т. н. «нулевой спринт» — неделя или две, в рамках которой настраивается рабочая среда, определяются основные инструменты и общая архитектура, то есть закладывается фундамент проекта. Просто в этом случае «продуктом» является среда разработки.
Важно то, что задания из Sprint Backlog не «спускаются сверху» — каждый может и должен сам выбрать то, чем он хочет заниматься. Более того — на самом деле каждый определяет эти задачи во время планирования всего спринта. Скрам-мастер ни в коем случае не является менеджером проекта — в его задачу не входит что-то кому-то навязать, он лишь координирует деятельность команды и подталкивает её в нужном направлении
Agile development — набор методов и инструментов, которые позволяют разрабатывать проекты в условиях, когда требования заказчика могут часто меняться. Примеры методов включают в себя Scrum и экстремальное программирование.
Scrum — принципы организации проекта в рамках методики Agile. Изначально термин пришёл из игры регби. Там «скрам» — это построение игроков, во время которого команда движется плечом к плечу, защищая мяч, и вместе проносит его на сторону противника. Впервые было использовано в статье в журнале Harvard Business Review, в которой описывались успешные методики работы, применяемые в Японии.
Sprint — одна итерация или цикл работ над проектом. Весь проект состоит из множества спринтов. Термин пришёл из лёгкой атлетики, где он означает быстрый бег на короткие дистанции. Примерно также можно описать работу во время спринта — очень быстро и очень интенсивно, но сравнительно недолго. Спринт длится 2–4 недели.
Sprint planning meeting — в начале каждого спринта команда проекта собирается вместе и выбирает ту функциональность (User Stories), что должна быть имплементирована в течение спринта. Одновременно каждая User Story разбивается на задачи, которые необходимо выполнить в течение спринта.
Stand-up meeting — ежедневная планёрка, в рамках которой скрам-мастер и команда разработчиков обсуждают, что сделано, что надо сделать и какие проблемы возникли. Обычно проводится в начале рабочего дня в течение 10–15 минут. «Stand-up», потому что во время встречи все обязаны стоять. В первую очередь для того, чтобы собрание не затянулось. Да и во вторую очередь тоже для этого же.
Основная задача скрам-мастера — обеспечить инфраструктуру для нормальной работы команды, планирования и ежедневных летучек, направить команду в нужном направлении. Раньше я не верил, что команда может быть самоорганизованной, считал, что есть сильный лидер и более опытные разработчики, которые принимают решения. Но оказалось, что в Scrum это работает и решения принимает вся команда. Скрам-мастер должен так построить диалог, чтобы люди раскрепостились и начали участвовать в дискуссии. Иногда это может быть непростой задачей.
В команде каждый день идёт дискуссия о том, как та или иная задача может быть реализована. Происходит это на так называемых Stand-up meeting — ежедневных коротких встречах, летучках, на которых каждый рассказывает, что он делал вчера, что собирается делать сегодня, какие проблемы возникают. Проводятся они для того, чтобы вся команда знала, кто чем занимается и кто кому чем может помочь. Встречи не должны превышать 15 минут, и на самом деле за эти 10–15 минут можно решить очень многое. В Agile/Scrum важно, чтобы все в команде понимали, что все мы делаем одно дело и все несём за него ответственность.
Что касается разработчиков, то это заблуждение, что Agile требует суперпрофи. Мы не рок-звёзды, мы — реальные люди, чудес не бывает. Хотя в прессе и литературе очень часто пишут, что Agile работает только в том случае, если разработчики исключительно опытны. Из моей реальной практики — это не совсем верно. В принципе, я встречался с некоторыми разработчиками, которые не приемлют идеи Agile. Им нужна чёткая спецификация и указания сверху. Но это исключение.
И когда программист выбирает задание и понимает, что все решения в рамках задания он может выбирать сам, то работник начинает делать всё быстрее и лучше. Эту атмосферу сложно передать, когда работа становится действительно cool, а не повинностью, как это иногда случается в длинных, скучных, затяжных проектах. Абсолютное большинство тех, кто поработал в agile-проектах, не хотят возвращаться к более традиционным методикам. Это отлично видно по реакции людей. И это — повод задуматься всем тем, кто никогда не работал по методикам Agile.
Scrum — практик о практике
Владимир Тихомиров,
старший системный аналитик компании Accenture,
сертифицированный ScrumMaster
Основная задача скрам-мастера — обеспечить инфраструктуру для нормальной работы команды, планирования и ежедневных летучек, направить команду в нужном направлении. Раньше я не верил, что команда может быть самоорганизованной, считал, что есть сильный лидер и более опытные разработчики, которые принимают решения. Но оказалось, что в Scrum это работает и решения принимает вся команда. Скрам-мастер должен так построить диалог, чтобы люди раскрепостились и начали участвовать в дискуссии. Иногда это может быть непростой задачей.
В команде каждый день идёт дискуссия о том, как та или иная задача может быть реализована. Происходит это на так называемых Stand-up meeting — ежедневных коротких встречах, летучках, на которых каждый рассказывает, что он делал вчера, что собирается делать сегодня, какие проблемы возникают. Проводятся они для того, чтобы вся команда знала, кто чем занимается и кто кому чем может помочь. Встречи не должны превышать 15 минут, и на самом деле за эти 10–15 минут можно решить очень многое. В Agile/Scrum важно, чтобы все в команде понимали, что все мы делаем одно дело и все несём за него ответственность.
Что касается разработчиков, то это заблуждение, что Agile требует суперпрофи. Мы не рок-звёзды, мы — реальные люди, чудес не бывает. Хотя в прессе и литературе очень часто пишут, что Agile работает только в том случае, если разработчики исключительно опытны. Из моей реальной практики — это не совсем верно. В принципе, я встречался с некоторыми разработчиками, которые не приемлют идеи Agile. Им нужна чёткая спецификация и указания сверху. Но это исключение. И когда программист выбирает задание и понимает, что все решения в рамках задания он может выбирать сам, то работник начинает делать всё быстрее и лучше. Эту атмосферу сложно передать, когда работа становится действительно cool, а не повинностью, как это иногда случается в длинных, скучных, затяжных проектах.
Абсолютное большинство тех, кто поработал в agile-проектах, не хотят возвращаться к более традиционным методикам. Это отлично видно по реакции людей. И это — повод задуматься всем тем, кто никогда не работал по методикам Agile.
Таким образом команда сама себе создаёт и выбирает задания (из ею же созданного списка) и сама же контролирует их выполнение — если какой-то человек постоянно опаздывает или «не тянет», он, вопервых, сам начнёт это чувствовать.
А во-вторых, команда будет явно или неявно «давить» на него — в скраме нет понятия «я», есть — «мы». «Мы не успеваем», все успехи и неудачи общие, но не индивидуальные.. О бедном заказчике замолвите слово…
Scrum требует от заказчика нести ответственность за проект наравне с разработчиком. Если в более традиционных методиках заказчик что-то там запрашивает и потом может ждать результата много месяцев и не имеет особого влияния на ход проекта, то здесь от него требуется очень высокий уровень интерактивности. Во-первых, он должен регулярно формировать Product Backlog, а во-вторых, быстро говорить «да» или «нет» (и отвечать более развёрнуто на более сложные вопросы), когда разработчики предлагают ему какие-либо решения.
Это требует высокого уровня компетентности от, как правило, одного человека, потому что только заказчик знает, что ему действительно нужно. И чем плотнее он взаимодействуетс разработчиками и чем лучше контакт, тем больше выгоды в итоге получат все участники и тем плодотворнее будет сотрудничество. Бизнес не статичен, и понятно, что у заказчика могут меняться приоритеты.
Например, в начале проекта для заказчика была более актуальна работа с частными клиентами, а через три месяца вдруг стало важным развить корпоративное направление. В случае с традиционными техниками ведения проектов он не может никак повлиять на разработку — разве что через практику change request после окончания проекта, и это будет (по крайней мере
— может) стоить серьёзных денег. В случае с Agile он может не просто менять приоритеты, но и давать принципиально новые задания, такие, о которых в начале проекта и речи не было. В этом случае из общего пула User Story выкидываются менее приоритетные задачи и заменяются новыми, более важными. Ничего подобного в случае с более традиционным подходом к разработке сделать нельзя.
Скрам-мастер — кто он?
Как мы уже сказали выше, скрам-мастера нельзя называть менеджером проекта. Во-первых, потому, что он не несёт глобальной ответственности за выполнение заданий проекта. Во-вторых, скрам-мастер — это просто одна из ролей. Одновременно этот человек является полноценным членом команды, может и должен выполнять другие обязанности и всячески помогать команде. Исключением являются действительно масштабные проекты, в рамках которых создаются т. н. scrum of scrums — скрамы скрам-мастеров, на которых они интегрируют
проделанную их командами работу и обсуждают проект на более глобальном уровне.
В общем и целом скрам-мастер — это наставник и модератор в одном лице. Он обеспечивает наилучшие условия работы для команды, оберегает её от давления извне (со стороны заказчика прежде всего), решает текущие административные или хозяйственные проблемы и направляет дискуссию и работу в нужное русло. Если кто-то на планёрках не раскрывается
и молчит, скрам-мастер должен разговорить этого человека.
В общем и целом в его задачу входит сделать так, чтобы от спринта к
Глоссарий
Sprint Retrospective — ежемесячная планёрка членов команды, на которой обсуждаются итоги каждого спринта. В теории должна отнимать не более трёх или четырёх часов времени.
Sprint Review — ежемесячная встреча между разработчиками, их руководством и представителем заказчика, на котором команда показывает, что было сделано в течение последнего спринта, и демонстрирует работающий продукт.
Product Backlog — список заданий (to do list) для всего продукта. Содержит User Story и прочие задания, связанные с User Story. Размер заданий должен быть таким, чтобы каждое из них можно было сделать не более чем за 8 часов. За наполнение Product Backlog перед началом проекта отвечает Product Owner. Добавлять задания в уже утверждённый Product Backlog можно только ценой удаления оттуда чего-то менее важного.
Sprint Backlog — список заданий (to do list) для каждого конкретного спринта. Как правило, в него включены задания с наивысшим для представителя заказчика приоритетом. Определяется командой разработчиков перед каждым спринтом. После утверждения и начала спринта никакие задачи в нём не могут быть заменены до следующего спринта.
Product Owner — лицо, ответственное за содержимое Product Backlog и Sprint Backlog, принимающее решение с точки зрения бизнес-целесообразности. Обычно это представитель заказчика, но иногда это может быть и сотрудник в самой компании-исполнителе или консультант.
«Сострадание — это не просто добрая воля, но готовность к созданию долговременных отношений, готовность принять и вынашивать точки зрения разработчиков, менеджеров и клиентов, с любым из которых вы можете быть не согласны, чтобы помочь им найти пути к принятию друг друга и созданию сообщества…».(Питер Мерел, «The Tao of Extreme Programming»).
Agile — специфика обучения
Борис Мишнёв,
проректор, профессор Института транспорта и связи
Оформление «гибкой разработки» (Agile, в частности) как технологии, которую можно совершенствовать, которой можно обучать и широко пользоваться, является самостоятельной, отдельной проблемой.
Да, все «тяжёлые» и хорошо документированные технологии потребляют значительные ресурсы, которые выделяет спонсор проекта (заказчик — Прим. ред). Но плюс такого подхода в том, что владельцем этих устойчивых процессов («know how») в значительной степени остаётся само предприятие. Эти процессы не только документируются, но и количественно анализируются. Есть, что изучать и с чем сравнивать текущие успехи новой разработки.
При различных вариантах «гибкой разработки» носителями технологии всё равно являются сами разработчики (они оценивают ситуацию, принимают гибкое решения для каждого отдельного случая и общаются с заказчиком). Если это всё не формализовано и не документировано, то не может быть отделено от разработчиков и самостоятельно использоваться. Здесь работает конкретная команда, состоящая из разработчиков с уже имеющимся успешным опытом такой разработки. А если такой команды нет, то совсем непонятно, как её можно создать за необходимое время (как правило, очень маленькое время до начала активной разработки продукта).
Единственно эффективным способом обучения нового и способного разработчика остаётся его реальное участие в таком, уже успешном проекте. Всё решают люди! Особенно нужно отметить, что принципиальным условием возможности быстро вести разработку на основе совершенствования работающих версий является наличие качественной и супербыстрой обратной связи от заказчика. Кто-то должен всё время «рассказывать истории» и оценивать результаты. Это — обязательное требование всех «гибких технологий». Есть свои проблемы и с «быстрой» разработкой больших проектов, когда задействуются десятки и сотни разработчиков.
Резюмируя, можно сказать, что имея слаженную команду высококвалифицированных разработчиков, обученных одной из «гибких» технологий, можно успешно реализовывать проекты малой и средней сложности при наличии уже частично готовых решений («внутренних стандартов»). Конечно, и все вспомогательные средства проекта должны быть гибкими и легко доступными. Что касается обучения технологиям «гибкой разработки», то основной акцент здесь должен быть сделан на понимании различных форм ведения процессов разработки.
Поэтому производители ПО сегодня уделяют особое внимание специальным средствам коммуникации как между членами команды, так и с заказчиком. Другими словами, гибкость достигается в значительной мере за счёт «коллективного разума», который очень плохо поддаётся формализации и для успешной реализации требует специально созданных условий и усилий.спринту команда показывала постоянно высокую производительность при минимальном количестве возможных проблем.
Только маленькие проекты?
Выше мы уже упомянули про scrum of scrums. И действительно, такие компании, как Microsoft или Google, оперируют проектами, в которых могут быть заняты сотни программистов. Машиностроительные компании, особенно в Японии, также исповедуют Scrum. И в то же время они применяют техники Agile — значит, это возможно?
Да, возможно. Главный принцип Scrum — команда не может превышать восемь человек. Если проект слишком большой и там заняты десятки людей, значит, создаются скрамы более высокого уровня и ещё более высокого уровня — получается этакое разветвлённое дерево. При этом, заметим, от традиционной иерархической пирамиды её отличает то, что каждая команда сама несёт ответственность за свою работу и сама выбирает очерёдность заданий. А также то, что практически все участники проекта знают о том, что делают соседи (общий пул заданий виден всем). При этом каждая команда может выполнять самые разные задачи и работать с разными частями проекта.
Специалисты говорят, что когда люди понимают, что происходит, и видят, как их работа влияет на результат, их мотивация тут же растёт. От частного вновь к общему Теперь, когда у читателя сложилось представление о том, как выглядит agile-проект, мы можем вернуться к более общим вопросам. Например, проблема документации. Может сложиться такое впечатление, что в случае использования Agile сопроводительных бумаг не бывает в принципе. Это не совсем так. В большинстве случаев документация пишется, но только после того, как получен конкретный результат (иногда бывает так, что документ очень важен для заказчика, тогда может быть и наоборот). И её должно быть ровно столько, чтобы хватало для понимания того, как оно всё тут работает или устроено. Перед созданием документа разработчики задают вопросы: «Доживёт ли он до конца проекта?», «Увеличивают ли эти документы ценность проекта для заказчика?». Если ответ отрицательный, такой документ никому не нужен. Ещё один важный момент — тестирование.
В рамках Agile обычно создаётся тестовая среда, через которую «прогоняют» весь созданный код сразу после выполнения конкретных задач. После добавления кода в репозиторий весь проект автоматически «перестраивается» и вновь запускаются тесты — чтобы быть уверенным в том, что новая или изменённая функциональность не создаёт фатальных ошибок в работе проекта. Создание тестов до кода, парное программирование и прочие методики т. н. экстремального программирования являются неотъемлемой частью Agile.
Поскольку во всей статье мы говорим о разработке программного обеспечения, можно подумать, что Agile и Scrum применяются только в этой сфере. Вовсе нет. Применять подобный метод можно где угодно: начиная от выпуска журнала (как раз идеальный с точки зрения всех методик период выпуска в 30 дней) и заканчивая поддержкой уже существующих продуктов и систем, машиностроением и т. д. и т. п. Коротко говоря, везде, где речь идёт о создании чего-либо, можно применять методы Agile. ! «Agile не определяется набором практик и техник. Она определяет стратегическую способность, способность создавать и реагировать на изменения, способность найти баланс между гибкостью и структурой, способность выявлять инновационное мышление в команде разработчиков и способность вести организации в условиях неопределённости». (Джим Хайсмит в книге «Agile Software Development Ecosystems»).
Принципы в основе Agile Manifesto
Наш самый высокий приоритет — удовлетворение клиента через раннее и постоянное создание ценного программного обеспечения. Мы приветствуем изменение требований даже в поздних стадиях разработки. Процессы agile поддерживают изменения для получения заказчиком конкурентных преимуществ.
Надо выпускать рабочие версии программ часто, в период от пары недель до пары месяцев с приоритетом на более короткие сроки. Разработчики и менеджеры должны работать вместе ежедневно на протяжении всего проекта.
Стройте проекты вокруг мотивированных личностей. Дайте им среду, поддерживайте всем необходимым и верьте, что они сами сделают всё, что нужно.
Самый действенный и эффективный метод передачи информации в команде разработчиков — это личное общение.
Работающее программное обеспечение — самое главное определение прогресса.
Процессы agile поощряют постоянную разработку. Спонсоры, разработчики и пользователи должны идти в ногу бесконечно долго.
Постоянное внимание к техническому совершенству и хорошему дизайну повышают выносливость.
Простота — искусство максимизировать количество несделанной работы — абсолютно критична.
Лучшие архитектура, требования и дизайн появляются на свет усилиями самоорганизующихся команд.
