Agile is a state of mind
18 мая 2007Материалы встречи:
- Видеозапись: первая часть, вторая часть
- Презентация докладчика
18 мая Асхат Уразбаев выступил с докладом о разработке Интернет-проектов с использованием гибких методологий.
Презентация г-на Уразбаева была посвящена вопросу, что такое Agile и как Agile меняет подходы к разработке. Асхат Уразбаев показал на конкретном примере, какие преимущества имеет Agile по сравнению с традиционной каскадным жизненным циклом разработки.
Наиболее важным в методике, по словам Асхата является то, что благодаря работе краткими итерациями возможна корректировка стратегии для получения максимальной выгоды как для заказчика, так и для разработчиков, тогда как каскадный процесс не позволяет приспособляться к изменениям в ходе разработки. Показывается как простой инкрементальный дизайн позволяет в течение нескольких двух-трёхнедельных итераций прийти к действительно прибыльному продукту, вместо полугодовой работы в направлении, наличие денег в конечной точке которого не гарантировано.
Он отметил, что Agile позволяет экономить достаточное количество денег, а также сократить количество ненужной документации. Вместе с тем не утверждается, что документация должна быть исключена полностью из процесса и подчеркивается то что её объём лишь минимизируется, с тем чтобы исключить именно те бесчисленные бумаги, которые никто никогда не читает. Докладчик подробно объяснил все шаги разработки проекта в стиле Agile, пояснив, что документооборот заменяется вербальным общением, и многие члены команды общаются непосредственно с заказчиком.
Асхат привёл данные Алистера Кокбёрна об эффективности различных способов коммуникации, которые показывают, что максимальный поток данных проходит между двумя людьми, общающимися возле флипчарта или доски, на которой они рисуют поясняющие схемы, чуть медленнее общение происходит по телефону и совсем медленно знания передаются по электронной почте. В случае же односторонней передачи данных ряд выстраивается от видеозаписи (лучше один раз увидеть, чем сто раз услышать) и аудиозаписи до бумажного документа в самом низу кривой, показывающей эффективность усвоения информации адресатом сообщения. Асхат заметил, что гибкие методики стимулируют увеличение объёма коммуникации между членами команды, снижая количество бумажного балласта и увеличивая величину информации, передаваемой вербально не только как долю от всей коммуникации между людьми, но и увеличивая объём всей коммуникации вообще. (Это предложение как раз является примером неэффективной текстовой коммуникации — достаточно увидеть одну иллюстрацию, показанную Асхатом, чтобы понять о чем идёт речь.)
Было замечено, что вербальное общение располагает людей к большему доверию друг к другу, а также повышает заинтересованность и ответственность в работе. Подчёркивается, что зачастую большой объём письменной документации является как раз-таки следствием внутреннего недоверия одних членов команды к другим — явления, которое следует всеми силами преодолевать. Задача создания атмосферы взаимного расположения и уважения в команде стоит в первую очередь перед человеком, взявшим на себя роль скрам-мастера или agile coach, agile-тренера — человека, помогающего команде стать действительно гибкой.
Докладчик обратил наше внимание на то, что при использовании методики Agile наиболее важная задача – это построение самоуправляемой, самоорганизующейся команды, в которой потоки информации циркулируют свободно, а не замыкаются на конкретного менеджера проекта. При традиционном подходе в какой-то момент менеджер проекта просто становится узким местом в коммуникации, начинает тормозить процесс разработки, пытаясь удержать всё в голове или на бумаге, и в итоге члены команды так или иначе начинают стараться общаться напрямую, что естественно ведёт к утрате контроля со стороны менеджера. Чтобы этого не происходило, рекомендуется с самого начала выстраивать коммуникацию в команде таким образом, чтобы все постоянно были в курсе о ходе дел друг у друга. Для этого используется несколько практик — ежедневные десяти-пятнадцати минутные летучки, называемые в экстремальном программировании stand-up meetings (стоячие собрания), а в методологии Scrum — daily scrums по аналогии с действиями команды игроков в регби. Также по итогам каждой итерации рекомендуется проводить ретроспективное обсуждение её итогов — что удалось, что пошло не так, кто придумал что-то хорошее, у кого что-то не получилось, какие проблемы возникли. По итогам ретроспективы не следует расходиться в плохом настроении с осознанием проблем, а следует разобраться в причинах их возникновения и придумать их решение. В этом процессе большая роль также отводится скрам-мастеру, который должен быть способен посмотреть на команду со стороны и увидеть, как сделать её работу лучше. Также в ходе ретроспективы можно проговорить итоги всего проекта на данный временной этап и понять куда он двигался и куда двигаться дальше.
Другая важная практика, способствующая улучшению взаимодействия не только в команде, но и между командой и заказчиком — это игра в планирование, подразумевающая формирование общего бэк-лога проекта (примерного списка всех необходимых к реализации пожеланий заказчика, или «фич», от английского feature) и плана на текущий релиз и текущую итерацию. Важным аспектом гибких методологий, связанным с практикой планирования является наличие в прямом доступе команды явно определённого product owner’a — человека, который определяет важность тех или иных фич для бизнеса, и таким образом определяющего их приоритетность к реализации. Такой человек должен быть один, с тем чтобы команда не получала противоречивых указаний, и задачей скрам-мастера является формирование у заказчика понимания необходимости создания и контроля общего видения проекта, осознания своих нужд, реализацией которых и занимается команда разработчиков. Если же от заказчика в качестве авторов пожеланий выступают несколько человек, то необходимо свести их вместе и сформировать единый канал входной информации о пожеланиях для команды.
Приоритетность задач можно определить как отношение выгодности для бизнеса от их реализации к сложности для исполнения со стороны команды. В первую очередь должны реализовываться самые простые и выгодные решения. Сложность задачи можно определять в различных единицах: в очках сложности, говоря что какая-то задача имеет определённое количество очков, а другие относительно неё сложнее или проще; также можно применять идеальные рабочие часы, говоря что если разработчика ничто не отвлекает и он полностью отдаёт себя этой задаче, то она занимает какое-то количество времени для воплощения. В случае с идеальными или инженерными часами, необходимо введение дополнительного показателя — velocity, коэффициента, на который домножается значение идеальных часов разработки, чтобы получить реальное время. Для каждого разработчика этот коэффициент индивидуален, но нельзя утверждать, что по нему можно сравнивать квалификацию, поскольку сам он зависит от многих факторов. Значения сложности каждой задачи необходимо получать от самих разработчиков в ходе игры в планирование. Ни в коем случае это значение не может утверждаться кем-то, кто в реализации задачи участия принимать не будет (например, чрезмерно оптимистичным project-менеджером) — это как правило ведёт к искажению оценок.
После кофе-брейка в докладе описывались технологические практики гибких методологий, которые относятся непосредственно к процессу разработки. Жизненно важно использование модульных тестов и принципов TDD — test-driven development, когда сначала пишутся unit-тесты, и лишь затем пишется функциональный код, который позволяет этим тестам успешно выполниться и дать на выходе «green bar» — зелёную полоску индикатора, означающую отсутствие ошибок. Асхат заметил, что писать тесты уже после написания функционального кода зачастую бывает настолько лень, что разработчики действительно отказываются от этого, и что именно поэтому тесты следует разрабатывать прежде чем основной код. Также докладчик отметил, что именно TDD позволяет держать архитектуру системы предельно простой, поскольку в процессе разработки тестов разработчик достаточно устаёт и пропадает запал воплотить в коде особый взлёт свободной мысли — в итоге в функциональной части пишется только тот код, который позволит тестам исполниться. Как правило большего для правильной работы программы и не требуется.
Рефакторинг (улучшение структуры кода без модификации функциональности), парное программирование и постоянная интеграция рассматривались в ходе беседы как нечто само собой разумеющееся. Следует, впрочем, заметить, что рефакторинг без использования unit-тестов представляет собой достаточно рискованную задачу, поскольку только модульные тесты могут показать, что функциональность кода при его изменении не была нарушена. Парное же программирование позволяет сократить количество ошибок в коде и таким образом увеличить производительность за счёт снижения необходимого для их исправления времени. Помимо этого, чем раньше ошибка оказывается не замеченной, тем дороже её исправление на более поздних этапах, и раннее обнаружение ошибок позволяет значительно сокращать издержки времени и денег. Помимо этого, парное программирование стимулирует обмен опытом между разработчиками, и создаёт дополнительный уровень взаимного контроля, не позволяя отвлекаться на постороннюю деятельность. Постоянная интеграция позволяет держать систему в наиболее актуальном состоянии и в экстремальном случае, быть готовыми к её поставке в любой отдельный момент времени. Как только дописывается какой-то блок функциональности — он вносится в систему. Если же после последнего внесения, система перестала работать, то, по словам Асхата, «кто уронил билд, тот его и поднимает», и соблюдение этого правила должно контролироваться скрам-мастером.
По словам докладчика на начальном этапе использования методики возможен спад производительности, пока команда переходит из состояния псевдокоманды к состоянию гибкой команды, однако, если все сделать правильно, то производительность начнет расти, поскольку разработчики зачастую более компетентны, чем менеджеры.
Асхат рассказал, для каких видов деятельности наиболее выгодно использование гибких методологий, подчеркнув, что для start-up бизнесов это часто единственно возможная методика. В свою очередь тяжело применять гибкие методики в случае большого количества унаследованного кода, который сложно покрывать тестами, а также двоичного кода доступного только в виде интерфейсов, ошибки которого исправить уже нельзя. Также после семинара обсуждались вопросы использования гибких методологий в разработке компьютерных игр и то, как должна выглядеть структура команды разработчиков в этом случае.
Все вопросы, задаваемые в течение семинара, записывались, и Асхат подробно обсудил их со слушателями в конце семинара. Г-н Уразбаев предложил продолжить обсуждение этой темы в Интернете, указав адрес российского Agile сообщества: http://agilerussia.ru.
Комментарии
Комментировать
You must be logged in to post a comment.
http://agilerussia.ru/ - че за фигня?
заходишь и сразу в глаза бросается
“ЗарегЕстрируйтесь на сайте чтобы получать информацию о встречах по почте.”
поправили
[…] гибких методологий (о которых, кстати, не так давно проводился семинар), преимущественно SCRUM. Дмитрий подробно описал […]