Я пишу это для тех, кто отрицательно ответил на перечисленные вопросы.

В Рунете вы можете найти множество статей и обзоров гибкой разработки, в частности XP и Scrum. Это ещё одна. Чем же она отличается?

Отличается она тем, что нацелена на аудиторию разработчиков, которым как мне подсказывает мой опыт объяснить выгоды от применения гибких подходов (или agile software development) намного сложнее, чем менеджерам проектов или представителям стороны заказчиков.

Ещё она отличается тем, что написана по просьбе моих друзей специально для developers.org.ua.

Так, хватит воды. Перехожу к сути.

Кстати, на счёт воды… Подходы ведения проектов, которые ставят в сравнение с гибкими подходами называют водопадными (или каскадными). Их так называют потому, что артефакты таких проектов перетекают от отдела к отделу как вода на каскадах водопада. Очевидно, что пересогласование требований или перерисовка архитектуры в таком проекте тем сложнее, тем больше утекло воды с момента написания такого документа. Признаками такого проекта являются горы документов, функциональная разбивка компании (отдел разработки, отдел тестирования…), заранее принятые решения и далеко идущие (и уже возможно устаревшие) планы.

Всё это не так плохо, если помогает эффективной работе. Часто же ей это вредит. Лучшее враг хорошего?

Давайте теперь разберёмся с аджайлом и в частности Скрамом.

Скрам – это подход управления проектами (при чём не только по разработке ПО), который предлагает каркас, в рамках которого вы можете строить свой agile процесс, адаптирую его части по ваши нужды. Это не конструктор, но цельный набор хороших практик, с которого часто легче начать, нежели с нуля.

Приходилось ли вам учить новый язык программирования или какой-то API, начиная с примера в мануале и переделывая его по ходу под ваши нужды? В итоге в конечном коде возможно не останется ни одной строки, которая была в начальном примере. Тем не менее использовать за основу простой работающий пример было удобно. То же самое и со Скрамом. Примените, отладьте, поломайте, почините, потом смело меняйте на ваш вкус.

Итак, Скрам – это термин из регби, означающий так называемую «свалку», когда все члены команды собираются в кучу.

Гибкая разработка ПО по принципу свалки….

Давайте лучше называть это Скрамом или «командным подходом».

Правила просты для озвучивания (но зачастую не так просты в реализации):

1. У вас должен быть один человек в проекте, который уполномочен принимать решения о том, какую фичу стоит разрабатывать раньше, какую позже.

«Кто платит, тот и музыку заказывает».

Обычно этот человек работает на стороне заказчика. Или является бизнес аналитиком. Или быть может синхронизирует взгляды различных заинтересованных в разрабатываемом продукте заказчиков.

В любом случае разработчикам проще, если такой человек есть, он доступен, и он такой один на проект (во избежание конфликтов).

Его называют «Product Owner» (оставим без перевода)

2. Product Owner поддерживает список требований-пожеланий к продукту. Этот список он сортирует (приоритезирует) по принципу «ценное сверху, менее ценное снизу».

Такой список называется «Product Backlog» (без перевода).

3. Собираясь на планирование короткой фазы проекта (итерации или «спринта» – дословно забега на короткую дистанцию), команда (а это все те, кто влияют на разрабатываемый продукт – архитекторы, дизайнеры, разработчики, тестировщики) выбирают из Product Backlog ту верхнюю часть, которую они считают, что реально начать и закончить (!) за этот короткий выделенный период.

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

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

4. По истечению оговоренного срока команда и заказчик встречаются для просмотра и обсуждения результатов. Это называется демонстрацией («де-монстрация» – изгонение монстров из софта).

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

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

Это называется ретроспектива (дословно «просмотр прошедшего»; или что-то в этом роде – лингвисты поправят).

6. Забыл сказать – во время спринта членам команды скорее всего придётся синхронизировать свои усилия и помогать друг другу для более слаженной работы и достижения общего результата. Говорят, что хорошо это делать раз в день в течение 10-15 минут в присутствии всех членов команды. Это и называется Скрамом.

7. Во время подобного обсуждения члены команды могут пожаловаться на проблемы, которые они не в силах устранить (падает сервер, пропадает интернет, слишком тёплое пиво…) Эти проблемы помогает устранить так называемый ScrumMaster – человек, который понимает принципы и тонкости Скрама, командной работы и «нежного лидерства». Он делает всё, чтобы команда максимально эффективно общалась с заказчиком, между собой и достигла своих обещаний и целей.

Такие вот правила. Или скорее хорошие практики, которые, работая вместе, помогают достичь отличных результатов, построить хорошие и честные отношения с заказчиками и в команде, получить удовольствие и удовлетворение от работы. Они, как мне кажется, дают шанс каждому разработчику подняться на ещё одну ступеньку профессионализма.

Прозрачность и осознанность – одни из чуть ли не главных особенностей agile-подходов в разработке программного обеспечения, поэтому наличие адекватного русского термина сделало бы очевидным их преимущества над другими подходами и методологиями.

Но начнем пока с «начала».

“Начало начал”. Притча.

Сначала программистов было мало, их ценили. Но также ценили компьютерное время, так как компьютеров было ещё меньше, чем программистов. Поэтому так важно было не отпускать программиста далеко от себя, общаясь с ним, выясняя и проясняя требования к программному продукту по ходу его разработки, чтобы таким образом уменьшить количество подходов к компьютеру, сэкономив компьютерного и программистское время. Это были время, когда программисты работали тесно с заказчиками.

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

Появились контракты.

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

Таким образом ситуация пошла против природной нестабильности требований к ПО.

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

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

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

Но было и меньшинство, которое пыталось адаптировать процесс разработки под динамику рынка, сохранив тесные и конструктивные отношения с заказчиками. Эти команды понимали ценность подобного подхода, ибо в условиях развития рынка, повышения конкурентной борьбы, усложнении технологий и требований к ПО, гибкость и динамичность в согласованном принятии решений были единственным выходом.

Прошло 20 лет, технологии усложнились на порядки; толерантность к стабильности требований уменьшилась и стала измеряться неделями; глобализация 21-го века заставила команды стать распеделенными… Эти и прочие факторы повлияли на увеличение популярности подходов, которые в противовес контрактам, спецификациям, долгосрочному планированию, сложным метрикам оценки качества и прогресса ставили во главу угла кооперацию, профессионализм, доверие к людям и конечный результат труда - сам программный продукт.

Необходимость тесного общения стала ещё острее за последнее десятилетие в рамках оффшорной разработки, где эти методы уже успели доказать свою компетентность.

В поисках крепкого словца…

Сегодня на территории русскоговорящих стран работают сотни команд, которые ценят и следуют вышеописанным принципам и подходам, поэтому наличие термина, который бы охарактеризовывал ценности agile-подходов (дабы этот смысл не был утерян) был бы весьма полезен.

Если попробовать охарактеризовать разные стороны этих подходов, то выйдет нечто следующее:

«Облегченность» (или «Легковесность»)

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

«Гибкость»

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

«Адаптивность»

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

«Прозрачность»

Из-за акцентирования внимания участников проекта на ощутимых результатах вместо замыливания внимания различными моделями, расчетами, статистикой, эти подходы делают прогресс проекта видимым и понятным, давая заказчикам полный контроль над курсом проекта ради оптимизации финансовых выходов. Проблемы и риски становятся видимыми, позволяя быть вовремя решёнными совместными усилиями проектных команд и заказчиков.

«Проворность»

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

«Осмысленные»

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

Итого

«Облегченногибкие адаптивнопроворные прозрачныеосмысленные методологии разработки программного обеспечения»…

Похоже тяжело найти подходящий термин в русском языке (я не говорю, что это невозможно), который бы передал все ценности и значения, вкладываемые в слово «agile» в контексте подходов к разработке ПО.

Но если пока не существует адекватного термина, который бы напоминал о многосторонней сути agile-подхода, то, следуя «здравому смыслу, который базируется на реальных данных», стоит использовать существующее множество терминов, варьируя различные аспекты agile для той или иной ситуации.

Вы хотите помочь команде, которая тонет в бюрократии и бумагообороте, не сдвигаясь с места в разработке ПО? Попробуйте объяснить преимущества agile-подхода, базируясь на аспекте «облегченности».

Вам жалуются на то, что команда отклоняет изменения в требованиях, ссылаясь на контракт и указывая на утвержденную процедуру change request management, из-за чего разрабатываемых продукт не будет максимально полезен заказчикам и пользователям? Поговорите с ними об аспекте «гибкости».

Вам говорят, что нужно все предусмотреть сразу и спланировать наперед, иначе наступит хаос? Адаптивность – возможно самый важный аспект, который нужно понять данной команде, чтобы осознать преимущества agile.

У заказчиков проблемы с пониманием прогресса проекта - команда говорит, что разрабатывает какой-то «каркас» и сможет перейти к запрошенной функциональности только к концу квартала? Проворность подхода, пожалуй убедит заказчиков попробовать что-то другое.

Заказчики жалуются на задержки в поставках со стороны команды, которые становятся известны не раньше, чем за день до согласованной даты? Прозрачность agile-подходов поможет предотвратить похожую ситуацию в будущем.

Команда жалуется на отсутствие логики в решениях заказчика – применения agile-подходов придаст осмысленности всем принимаемым решениям, решения станут базироваться на реальных данных, известных всем.

P.S.

Нахождение адекватного термина в русском языке – это дело времени. Но важность сохранения многосмысловой нагрузки agile-подходов останется задачей, которая пожалуй будет актуальной всегда.

———————–

Автор: Кривицкий Алексей, alexey@krivitsky.com
Опубликованно также на http://www.krivitsky.com/2007/02/blog-post.html