01.03.2009 Наконец-то выкладываю свою первую статью

Национальные особенности русского Agile


Введение
О чем эта статья
Agile лозунги и иллюзии вокруг них
Самоорганизованная команда
Хорошо мотивированная команда
Кроссфункциональная команда
Что же такое Agile?
Agile как парадигма
Agile как обобщение гибких методологий
Документация в Agile
Coda

«Добрый день.
Вам сегодня крупно повезло!
Сегодня мы вам предлагаем SCRUM!»

Введение
Активная, но при этом нездоровая миссионерская проповедь вначале RUP- , а теперь Agile -подходов как панацеи от всех IT-болезней приводит к одному и тому же обратному эффекту.
Многие серьезные разработчики естественным путем внедрили у себя одну или несколько из мировых best-practices, но потом с удивлением узнали, что эти практики уже давно интегрированы и продвигаются в рамках RUP.
Так разработчики оказались автоматически причислены к последователям RUP, и получили клеймо «тяжеловесных».
…Теперь они боятся заявлять о том, что применяют эти практики.
Аналогично и с Agile…
Внедряя практику парного программирования, многие остерегаются, как бы их не заклеймили анархистами от ХР и Scrum.


О чем эта статья
Данная статья из серии «Agile: иллюзии и реальность» (1).

Её задача - рассмотреть некоторые из Agile практик и попытаться показать, что при правильном понимании их многие вопросы касательно их применения могут оказаться неактуальными.

Agile – лозунги и иллюзии вокруг них

• Самоорганизованная
• + мотивированная команда
• Кроссфункциональная команда
• Понятие Agile
• Документация в Agile
• Прозрачность процесса

Что осталось за кадром:

• Product owner и анализ требований
• Бизнес и инжиниринг работают как одно целое
• Коммуникации
• При планировании присутствуют все участники
• Оценивается команда, а не каждый ее член
  

В данной статье будут рассматриваться некоторые из них.

Самоорганизованная команда
Один из ключевых элементов Agile это команда.
Agile практики уже заметили, что в Agile «никогда не идет речь о некомандной разработке». (2)
Большая часть принципов Agile Manifesto подчеркивает именно то, что изначально гибкая разработка осуществлялась при командном подходе.
Так, 5-ая и 11-ая строки Манифеста заявляют о самморганизации и мотивированности команды.

«We follow these principles:
• 5) Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done,

• 11) The best architectures, requirements, and designs
emerge from self-organizing teams».
Данные принципы являются одними из ключевых рекомендаций Agile подхода. Его приверженцы уже заметили, что при соблюдении этих принципов, управление жизненным циклом продукта (от концепции и до сопровождения) становится намного эффективней.
И, не смотря на то, что данные принципы не являются критериями гибкой разработки, они уже плотно вошли в традиции Agile-культуры.
Но есть и другая сторона.
Нередко активная миссионерская проповедь именно этих принципов у многих серьезных разработчиков вызывает не только недоверие, но и тотальное скептическое отношение ко всему Agile. Рождается, с большим трудом выражаемое в каких либо отдельных формулировках – но совершенно отчетливое общее отрицательное отношение.
Дело в том, что эффективность всех Agile принципов изначально очень сильно зависит от их правильного понимания. Но, к сожалению, в назначение большинства популярно-ознакомительных тренингов и презентаций, как правило, в первую очередь входит “заинтересовать”, а не “ознакомить”.

Так, что же такое самоорганизованная и хорошо мотивированная команда, и что скрывается за принципами о том, что команда должна быть такой?
Следуя учению Agile - евангелистов, самоорганизованной командой, называется та, члены которой не нуждаются в руководителе в традиционном понимании этого слова.
Т.е. самоорганизованной командой называется та, члены, которой не нуждаются в человеке, который бы раздавал каждому из них отдельные задания и отслеживал процесс их исполнения. «…Если б вы сами могли брать себе задания, сами решить внутри команды, кто - чем будет заниматься, эффективность такой работы, как показала практика и наш уже многолетний опыт, - намного выше …» (1).

Для того чтобы правильно понимать и применять данную практику, в первую очередь важно не забывать об ее предыстории.
В классике первопроходцами agile подхода были не просто разработчики, организованные в самоорганизованную команду, они ”по совместительству” были хозяевами, как процесса, так и продукта разработки. И, следовательно, руководителя у команды не было не потому, что царила полная анархия, а потому что каждый член команды уже был руководителем. Очевидно, руководителям не было больше кем управлять, кроме как самими собой. Ну, а поскольку, такие руководители, зачастую, не были одиночками, а были хозяевами-совладельцами (со - партнерами), то им и приходилось самостоятельно решать между собой, кто из них чем будет заниматься.
Логично, соблюдая теперь принцип самоорганизованной команды, мы должны понимать, что каждому из ее членов ни в коей мере не запрещается иметь своих помощников (наемников) или отдавать свою часть работы на аутсорсинг. (Естественно, при условии, что ответственность с такого team-player-а не снимается, равно, как и число членов команды не считается увеличенным).
Самоорганизованной может также быть команда помощников (наемников). Т.е. несколько помощников одного из представителей команды руководителей могут также принимать от него одно задание (пачку заданий) на всех. При этом в роли владельца продукта (product owner-а) для такой команды помощников будет выступать тот, помощниками кого они являются.
Иерархию можно продолжать …

Несложно заметить, что при таком подходе к описанному принципу множество из прежних, выражающих сомнение к Agile-у вопросов становятся неактуальными.
Вот некоторые из них:
• Как быть с junior-ами в Agile?
• Кому выполнять черновую работу?
• Как быть с теми, кто не хочет придерживаться Agile принципов?
• Зачем на «планировании» все члены команды? (на самом деле, те, кому на совещании делать нечего – попросту не являются ее членами)
• И еще много пунктов на тему «бизнес и инжиниринг работают как одно целое».

Хорошо мотивированная команда
Команда должна быть хорошо мотивированной говорит Agile Manifesto (5 принцип).
Действительно, чем мотивированнее команда, тем она эффективнее и производительнее.
И, если не будет мотивации, то не будет процесса не только самоорганизованного, а и вообще какого-либо другого

Что же такое мотивация в Agile?
В простонародье под мотивацией понимают искусное управление “кнутом и пряником”…
Но в Agile команда самоорганизована.
Т.е. в Agile команду никто не подгоняет, она и так достаточно энергична и заинтересована в конечном результате.
По-видимому, команда в Agile уже мотивирована.
Следовательно, не будет Agile-а, если команда не будет мотивирована.

«Команда это – небольшая группа людей с общими целями, общими навыками, самоорганизующаяся», замечают Agile - миссионеры (1).
Вопрос, где же взять предварительно мотивированную команду?
...
Таким образом, не стоит заблуждаться касательно того, что мотивация автоматически повышается всего лишь из-за повышения ответственности каждого члена команды.
«Вы же понимаете… у нас – Scrum!
Поэтому, если Вы не будете мотивированны, Вы у нас работать не будете», – типичная ситуация, когда кандидату предоставляется компенсационный пакет наемника, при этом требования по заинтересованности к конечному результату и по ответственности за него выставляются наравне с совладельцами.
Отсюда вывод: не стоит забывать, что
самоорганизованная и мотивированная команда
НЕ РАВНО
само-мотивированная команда.
Прежде – мотивация, потом – самоорганизация.
Мотивация – причина, самоорганизация – следствие.

Кроссфункциональная команда
Это еще один Agile-принцип, вокруг которого постоянно “ломаются копия и луки ”.
Одни не видят преимущества от его соблюдения.
Другие не видят возможности его соблюдения.
Третьи, вообще считают его чем-то глупым, лишним и ненужным…
И, нередко, в связи с ним у многих разработчиков всплывают те же вопросы, что и прежде с принципом “самоорганизации”.
Например,
• как быть с junior – ами?
• или, кому же тогда черновую работу выполнять?
Однако в мире Agile мода на кроссфункциональность команды продолжает расти.
Что не на ровном месте.
Как показала история, и как продолжают учить Agile –миссионеры, кроссфункциональность команды – это еще одни из немаловажных Agile - принципов, соблюдение которого принесло пользу уже немалому количеству разработчиков.
Но, как и все остальные принципы гибкой разработки его следует правильно понимать.
Даже этот принцип особенно важно правильно понимать:
что же именно за ним скрывается, и в чем именно он может принести, или не принести пользу.

Итак, что же такое кроссфункциональность, зачем она нужна, и как ее достичь?
О кроссфункциональности команды хорошо написал Алексей Кривицкий, координатор украинского Agile сообщества, в своей статье «QA – in - Scrum» (http//:www.agileukraining.org). В данной статье он замечает, что cross-functional – ой командой называется полнофункциональная команда, т.е. та, которая состоит из всех тех, «кто вносит вклад в разработку результата итерации».
«В очень маленьких проектах это только разработчики, в проектах побольше – это дизайнеры, разработчики и тестировщики, в совсем больших проектах – это аналитики, дизайнеры, инженеры баз данных, … и др.».

Также кроссфункциональной командой считается та, в которой для каждого игрока найдётся другой (игрок), способный при случае его заменить. (Не путать с экстремизмом: все вмешиваются в результаты каждого и за всё одновременно отвечают).

Теперь – относительно пользы от такой кроссфункциональности.
В той же статье А. Кривицкий показал, как правильное следование принципу кроссфункциональности позволяет избежать типичной ситуации, когда кодирование постоянно опережает тестирование.
Автор предлагает программистам экономить время на написание кода и использовать освободившееся время на тестирование своего или чужого кода.

Очевидно, кроссфункциональность в команде должна быть настолько, насколько она действительно необходима. Т.е. нужна не примитивная кроссфункциональность, а адаптивная.

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

Также эксперты отмечают, что плотное, конструктивное общение, прозрачность процесса, парная работа и т.д., – это все практики, направленные на реализацию именно адаптивной кроссфункциональности.

Что же такое Agile?
За последние несколько лет наблюдается удивительная тенденция:
- То, что Agile описывается набором практик – знают даже совсем “безграмотные”.
- Многие даже по набору внедренных практик способны вынести заключение: “Это – Agile!”.
- Мода на Agile и его популярность растут на глазах.
Тем не менее, понимание, что же такое Agile в своей сущности – до сих пор находится в плачевном состоянии...
Самое замечательное, что это печальное явление наблюдается не только среди тех, кто еще на дальних подступах принципиально отверг Agile, но и в равной степени – среди тех, кто его с энтузиазмом принял и с успехом внедрил.

Так, нередко, имея одно и то же поверхностное представление об Agile, одни его чуть ли ни возводят в ранг культа, другие – ненавидят.
– Ты нарушил Agile принципы!
– А что такое Agile принципы?
– О-о-о! Ты не понимаешь?!...
Agile дан нам свыше, думать нам некогда (не смеем), мы должны с трепетом ему следовать…
(дословное цитирование впечатлений одного из посетителей известного agile - сообщества).
Или другой вариант:
«Да, мы с удивлением обнаружили, что у нас действительно уже внедрены и реально работают чуть ли не все практики, заявленные в Agile …
…но только не клеймите нас Agile-ом!»

Итак, что же такое Agile?
Для ответа на этот вопрос в первую очередь следует заметить, что за термином Agile скрывается несколько понятий.
Эти понятия достаточно плотно пересекаются между собой и во многих местах являются взаимодополняющими, но всё же они не являются тождественно равными.
Так,
1. Во-первых, Agile – это некоторый стиль, подход (парадигма, концепция) разработки.
2. Во-вторых, Agile – это обобщение всех гибких методологий, методик.
3. В-третьих, Agile – это, собственно процесс гибкой разработки.
4. И, наконец, в-четвертых, Agile – это просто набор практических рекомендаций, направленных на повышение гибкости разработки (кажется парадоксальным, но это оказывается близким к идеям CMMI (А. Кондаков, русскоязычный гуру CMMI (4))

В четвертом случае Agile чаще всего называют framework-ом, концептуальным каркасом или костяком методологии.
Для именования подобного framework-а часто еще употребляют другой термин: Scrum. Многие идут дальше, утверждая что Scrum – это уже и есть весь Agile.

Agile как парадигма

Если говорить об Agile в ключе первого определения, то в этом случае апологеты часто называют Agile культурой (хорошо ещё, если культурой, а не религиозным культом).
"Agility is not a technology, science, or product but a culture" (Philippe Kruchten). При этом говорят, что Agile – это нечто великое, и что описать его в коротких, емких и однозначных выражениях практически невозможно. В лучшем же случае, некоторые соглашаются сформулировать, чем же эта культура описывается.
Оказывается, Agile культура описывается по трём направлениям:

• принципами,
• практиками,
• и ценностями.

Причем, все ценности делятся на несколько категорий. Замечательно, что самой важной из них заявляется «Дух».
(Как тут не вспомнить про нашумевшую проповедь Духа RUP)
Однозначно истолковать суть этого духа довольно трудно. Каждый может трактовать его в удобном для него направлении.
Евангелисты чаще всего объясняют его через принципы, описанные Кентом Беком в «ХР – 2.0»:
• Общение
• Простота
• Обратная связь
• Смелость, кураж
• Уважение
• Гуманность
• Взаимная выгода
• и т.д.

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

«1. Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software».

Говорит первая строка Манифеста. Все остальные принципы того же манифеста являются ее развитием. Многие удивляются, мол, неужели подыгрывать заказчику и уважать друг друга нужно только в Agile?
На самом деле в Agile это подчеркнуто, только для того, чтобы легче было понять остальные его принципы. И, чтобы подчеркнуть, что без слаженного сотрудничества в Agile (с его командной спецификой) добиться какого-либо успеха будет еще труднее, чем в non-Agile (здесь – подходе, ориентированном на конвейер).
Именно в связи с этим духом, Agile и назвали не просто системой взглядов (парадигмой), а – культурой.

Однако не стоит упускать из внимания, что при недобросовестном отношении, в Agile места для спекуляции не меньше чем в non-agile (т.е. в подходе ориентированном на процессные поставки), а то и больше.
Где больше доверяют, там больше возможности для воровства.

Agile как обобщение гибких методологий

• Что же такое Agile, если смотреть на него как на обобщение гибких методологий?
• Что такое гибкие методологии?
• И почему гибкие методологии стали называть Agile-ом?

Если проследить историю, то гибкая разработка, а, следовательно, и гибкие методологии были еще задолго до того, как термин Agile стал активно употребляться в IT индустрии. «В феврале 2001 года 17 разработчиков методологий, авторов DSDM, XP, Scrum, FDD и др., собрались для того, чтобы попытаться обнаружить что-нибудь общее в своих подходах. Результатом стал Манифест гибкой разработки (3). Тогда же появился термин Agile (то есть гибкий, шустрый), объединяющий все методологии под одной крышей» (А. Уразбаев, (5)).
Т.е. вначале был ряд гибких методологий – потом они все получили одно обобщающее название Agile.
Касательно обобщения гибких методологий, также неплохо написал один из Agile тренеров, Денис Миллер: «Agile - набор методологий, удовлетворяющих определённым правилам. Я могу придумать методологию XYZ, если она реализует правила Agile, я её буду относить к Agile методологиям» (см. комментарии к статье, Денис Миллер(6))
Однако хотелось бы отметить, что, скорее всего, принципы Манифеста – это было далеко не все, что оказалось общим среди рассматриваемых подходов. И, что, скорее всего, назначением Манифеста, по большому счету, была рекламма: привлечение внимания общественности путем декларации подхода призванного снизить общеизвестные риски Заказчика в процессе разработки (в первую очередь - риски, связанные с невозможностью изменений требований на произвольной стадии разработки).
Таким образом, принципы Манифеста – не равно критерии, которым должна удовлетворять гибкая разработка (не смотря на то, что в некоторых местах они пересекаются). Т.е. другими словамм, Agile Manifesto – НЕ РАВНО Agile Criterion. (К сожалению, полного такого набора критериев до сих пор не существует. А, если и существует, то мало кому известен. Есть только отдельные Nokia - test на Scrum и на итеративность разработки).

Так что же такое гибкая методология (методика, разработка)? В чем же критерии гибкого подхода?
К сожалению, как было уже сказано только что, многие заблуждаются, считая, гибкой разработкой ту и только ту, которая неуклонно следует принципам Манифеста.
Не смотря на это, евангелисты замечают, что гибкой разработкой (гибкой методологией) в первую очередь считается та, которая следует принципу: «изменения приветствуются, а неопределенность признается» (5).
С этим критерием также пересекается второй принцип Манифеста:
«1. Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage».
Таким образом, ключевыми и отличительными признаками гибкого подхода являются следующие
• гибкая адаптация к изменениям требований
• гибкая реакция на условия неопределенности

Здесь важно отметить, что одна из ключевых Agile практик, плотно вжившаяся в Agile традицию такая, как «инкрементность и кратковременные итерации» является всего лишь инструментом для соблюдения данного принципа.
Но два вышеперечисленных критерия – не все. Есть еще, как минимум один.
Поскольку термин agile в переводе – не только «гибкий», но и «шустрый», «легкий», «подвижный», то еще одним неотъемлемым критерием гибкой (agile) разработки считается
• легкость, проворность и подвижность.
Так евангелисты называют Agile методологии «облегченно-гибкими», «адаптивно-проворными» и « прозрачно-осмысленными». При этом они же замечают, что понятие Agile трудно сформулировать на русском языке одним словом
«…тяжело найти подходящий термин в русском языке (я не говорю, что невозможно), который бы передал все ценности и значения, вкладываемые в слово «agile» в контексте подходов к разработке ПО…» (А. Кривицкий, (3)).

Документация в Agile
Данный пункт является завершающим в статье, и поэтому возможно в некоторых местах он будет несколько неполным. Однако, поскольку он затрагивает вопросы, на почве которых до сих пор ведутся не только горячие споры, но и нередко созревает вполне категорическое отношение ко всему Agile, упускать совсем его из виду не хотелось бы.
Итак, как уже было сказано выше, одним из отличительных признаков Agile считается легковесность и прозрачность
В том числе , agile разработкой считается та, которая не перегружена излишней документацией, излишними артефактами и ролями.
Однако не стоит забывать, минимум документации – НЕ РАВНО ноль документации.
Вспомним, что в Agile кроме всего прочего также обязательным критерием является прозрачность «…Прозрачность и осознанность – одни из чуть ли не главных особенностей agile-подходов в разработке программного обеспечения…», (А. Кривицкий). Как известно, хорошее документирование – один из инструментов обеспечения прозрачности.
Таким образом, в Agile-e документация – не в нагрузку, а в помощь.
Но не стоит забывать, что документация действительно станет «в помощь», только при условии высокого качества таковой.
В Agile качество документации становится одним из решающих факторов успеха.
Недаром же все апологеты постоянно напоминают, что в agile нельзя жертвовать качеством. В agile всё должно быть качественным (в том числе – и документация).
«9. Continuous attention to technical excellence
and good design enhances agility», (agile manifesto).
Теперь видно, что в Agile документации не просто минимум, в Agile-e она еще и обязательно качественная. Следовательно, если в Agile документации мало, то это не значит, что над ней нужно мало (т.е. недостаточно) трудиться. Наоборот, в Agile над документацией нужно особо тщательно работать – а это часто занимает время.
На нечитаемую документацию в Agile просто не остаётся времени.

Coda
Как уже было сказано выше, данная статья является развитием направления «Agile: иллюзии и реальность».
В таком направлении IT-миру уже известно, как минимум, еще две статьи:

1. первая так и называется «Agile: иллюзии и реальность».
Ее автор А. Якима (1).
2. вторая – это «Аналитик в Agile: анархизм или необходимость». Ее автор – один из участников SEC(R) - 2008, Андрей Бибичев. (7)
Итак, вслед за выводами корифеев подчеркнем следующее.
Гибкая разработка действительно очень эффективна и действительно способна принести большие преимущества компаниям….
Однако, как заметили те же авторы, «…ее эффективность реальна только в случае, если ставятся адекватные цели и за основу берутся реалистичные предпосылки», а главное «осознаются основные идеи Agile» (1).
При отсутствии же такого осознания, «попытки использовать материалы по Agile-методологиям, как исчерпывающие инструкции или догматы, приведут вас к чему угодно, кроме того, что изначально вкладывалось в понятие Agile» (7).

-- Внедряйся  Scrum большой, внедряйся  маленький..

-- Внедряйся  Agile большой и еще больший!..

Ну, и напоследок, соглашусь с А. Бибичевым, который, будучи сам последователем гибкого подхода, обращается ко всем, заинтересовавшимся Agile-ом, с рекомендацией применять его с умом и не делать из него “очередной карго-культ”.
……………………………………….
Часто проповеди Agile вначале вызывают у слушателей повышенный энтузиазм и эйфорию от успеха, которого ещё нет, но который кажется таким близким.
А после неудач или неожиданно малой отдачи от внедрения – глубокое разочарование и депрессию.
Такое явление нередко объясняется агитационными перегибами Agile-проповедников:
- раздутые описания возможностей Agile,
- эмоциональная перенасыщенность рекламных тренингов.
(В последнем случае слушатели часто влюбляются уже не в Agile, а в его проповедь, людям нравится, когда их лечат).
……………………………………
Но замечательней всего, что перегибы проповедей очень часто негативно влияют даже на тех, кто уже давно применяет Agile практики.
Так, случается, когда успешные команды уже давно работавшие в стиле Agile, но не догадывавшиеся об этом, узнав об Agile, ожидают от него еще чего-то, принципиально нового, способного излечить все. Однако, не получив ожидаемого эффекта, такие команды надолго разочаровываются во всем Agile (старый-старый синдром поиска очередной серебряной пули Брукса).
……………………………..
Однако, если все же постараться к Agile отнестись объективно, и дополнительно – хорошо поискать по разноплановым источникам, толкующим Agile проповеди, то иногда с удивлением можно найти, что, оказывается, Agile действительно не является панацеей от всех IT-болезеней.
Мало того – Agile не гарантирует повышение эффективности разработки. Как говорят Agile толкователи: следуя Agile рекомендациям, неправильное развитие проекта может быть всего лишь обнаружено на более ранней стадии.
Аналогично можно найти, что и Scrum, несмотря на всю свою популярность среди всех Agile - подходов, часто не является лучшим решением. Что со Scrum-a всего-навсего, многим легче начать. (Scrum легче продается..., людям нравятся красивые слова, замечают евангелисты).
В дальнейшем же, как отмечают те же евангелисты, от самого Scrum-a может уже ничего и не остаться, каждая его практика может быть заменена на какую-либо другую подходящую альтернативу.
………………………
Логично теперь, учитывая все выше сказанное, сделать небольшой предостерегающий вывод:
прежде чем задуматься о внедрении Agile, наверное, лучше всего было бы посмотреть, а не внедрен ли он и так у нас.


(1) – www.agilerussia.ru А. Якима «Agile: иллюзии и реальность»
(2) – www.TraningLabs.ru (Асхат Уразбаев, Никита Филиппов)
(3) – www.agileukraining.org (Алексей Кривицкий)
(4) – www.inspirex.ru
(5) -- www.compress.ru/Archive/CP\2007\5\23/#begin (Асхат Уразбаев)
(6) -- http://habrahabr.ru/blogs/pm/23747/#habracut (Денис Миллер)
(7) – www.custis.ru (Андрей Бибичев)