Вероятно, первой мыслью при взгляде на заголовок может стать «Да как вы зае… — сколько уже было разборов этой темы.» Всецело поддерживаю — я бы отреагировал аналогично, если бы не одно «но»: с большинством встречавшихся мне разборов я в корне не согласен. А потому приберегите негодование, ибо контент вас может удивить и даже нанести непоправимую ценность. И тем более я рекомендую вчитаться тем аналитикам, рабочий стаж которых <= срокам активного распространения Agile в отечественных масштабах. В общем, погнали.
Каково доминирующее нынче мнение о процессных подходах к разработке ПО?
Есть Waterfall (водопад, каскад), где работа идет строго последовательно, а потому это ужос как неудобно и старо аки говно мамонта, в связи с чем ему пора отойти на покой. А есть Agile, который весь такой светлый и правильный, ибо, как минимум по большей части, итеративен. Соответственно, всевозможные сравнения этих подходов — это дихотомия добра и зла. Ну что ж, давайте разбираться.
Что такое Waterfall? Не будем далеко ходить и заглянем в Википедию:
The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks.
Я не буду вкапываться в детали и разбирать модель — читать мы все умеем, да и сравнительных анализов в Интернете море. Казалось бы, да, для абсолютного большинства проектов это люто неэффективно, и спасительный Agile — это как раз то, что доктор прописал. Но давайте в той же Википедии поднимемся на уровень выше:
Most modern development processes can be vaguely described as agile. Other methodologies include waterfall, prototyping, iterative and incremental development, spiral development, rapid application development, and extreme programming.
Вот и первый сигнал того, что не аджайлом и водопадом мир един. Давайте теперь заглянем в PMBOK Guide (Seventh Edition), который уж точно должен быть продуманнее, чем рандомная статья в Википедии:
A development approach is the means used to create and evolve the product, service, or result during the project life cycle. There are different development approaches, and different industries may use different terms to refer to development approaches. Three commonly used approaches are predictive, hybrid, and adaptive.
1. A predictive approach is useful when the project and product requirements can be defined, collected, and analyzed at the start of the project. This may also be referred to as a waterfall approach.
2. Hybrid approaches often use an iterative or incremental development approach.
3. Adaptive approaches are useful when requirements are subject to a high level of uncertainty and volatility and are likely to change throughout the project. While agility is a wide mindset that is broader than a development framework, agile approaches can be considered adaptive.
Если и этого недостаточно, то давайте любимого Вигерса вспомним — в масштабе всего лишь одной диаграммы.
Под конец давайте полирнем все это дело логикой. До Agile Manifesto 2001 года, и тем более до точки, когда принципы Agile стали проникать в наши широты, люди как-то работали. И если вы полагаете, что это был сплошной Waterfall — т. е. мыши плакали, но не понимая всю нелепость строгой последовательности работ, усердно грызли этот архаичный кактус — пора выбрасывать такую логику в окошко. Итеративные подходы к разработке (да-да, те, что упомянуты во всех источниках, к которым я прибегал выше) давно уже прочно вошли в обиход — ни на одном проекте, на котором я или мой круг контактов работали до Agile, не использовался термин Waterfall и не наблюдалось следование его принципам: вне Agile люди работали и работают по большей части по точно таким же (с позиции концептуального планирования работ) итеративным подходам к разработке ПО, просто ценности и принципы Agile не ставятся в главу угла.
Что из этого всего следует? Сравнивая Waterfall и Agile (с неизменными выводами в пользу Agile), авторы подобных материалов сравнивают коня с самолетом, радостно восклицая, насколько последний более быстр и удобен. Но не допускают при этом, что после коня были еще и автомобили, которые долгое время тотально доминировали и были вполне себе отличным подходом к разработке ПО. И не только были, а еще и никуда не делись — большинство тех, кто отстал от моды и не в Agile нынче, поверьте, работают НЕ по водопаду. Более того, если ваша команда гордо несет знамя Agile, но при этом члены команды и вся она как результирующее целое не шарят майндсет гибкой разработки и ее ценностей (что встречается весьма нередко), то вы работаете ровно так же, как эти самые «мамонты» — от того, что вы стали называть итерации спринтами, а спеки запихивать по кусочку в User Stories, вы не стали Agile, не тешьте себя иллюзиями. И я сейчас не беру узкие кейсы, в которых конь априори лучше подходит для целевой задачи — я опираюсь на статистическое большинство проектов.
Что все это значит для бизнес-аналитика?
Во-первых, я не раз видел сравнение «монолитная спецификация, создающаяся предиктивно на старте» VS «just-in-time User Stories». Agile-апологеты в особенности любят подчеркивать подобным силу и мощь Agile-техник. И снова это конь VS самолет / добро VS зло. За всю свою бытность аналитиком в до-аджайлную эпоху я максимум пару раз прорабатывал полную спецификацию требований до старта разработки. Требования ровно так же итеративно разрабатывались, только техники и подходы не звались историями пользователей, хотя по своей сути не сильно от них отличались. Спецификация, техническое задание и прочие «классические» артефакты либо прекрасно разрабатываются итеративно, либо замечательно режутся на кусочки, аналогичные User Stories. Это все грубое искажение реальности, не дающее аналитику широту инструментария и загоняющее его в искусственные рамки.
Это была первая часть статьи. Далее пойдет часть для относительных новичков, которая ближе к, непосредственно, бизнес-анализу. Мы поговорим о планировании бизнес-анализа в контексте подходов к разработке ПО, взяв за основу то, что постулируется в BABOK, но в моем авторском преломлении.
Есть у нас в BABOK такая замечательная область знаний, как Business Analysis Planning and Monitoring — это об организации бизнес-анализа на проекте и управлении его ходом в контексте мониторинга и внесения корректировок. И первым пунктом в этой области идет задача Plan Business Analysis Approach: определить общими мазками то, каков будет ваш (или командный) бизнес-анализ на проекте, т. к. это во многом определит набор/структуру работ и дальнейший выбор техник и артефактов. BABOK сводит подходы к двум основным вариациям:
- Предиктивный (склоняющийся к раннему планированию).
- Адаптивный (меньше планирования и больше адаптации под обстоятельства по факту).
Похоже, да, на подходы к разработке ПО из PMBOK выше? Не хватает только гибридного, но по факту он, конечно же, есть — просто нужно представить, что упомянутые два подхода в чистом виде — это точки на концах шкалы, между которыми есть много промежуточных и по факту более «рабочих» вариантов.
Предиктивный подход применяется в классических моделях и методологиях разработки ПО, в частности — в Waterfall, плюс в более жестких итеративных моделях (когда проектные стадии явно выделены и артефакты определены заранее). Такой подход подразумевает раннюю (отсюда и «предиктивный») работу над требованиями — либо в масштабе всего проекта, либо его отдельных итераций.
Адаптивный подход — это подход с позиции гибкости, по принципу «действуем по ситуации». Приложив нехитрое умственное усилие можно догадаться, что он прекрасно ложится на Agile-модель и на менее формальные итеративные модели, когда команда может себе позволить работать над требованиями в режиме «чё париться заранее — когда придет время, тогда и проработаем». Это более рискованно с позиции того, что позже всплывет нечто, что потребует существенных переделок, влияющих на сроки и стоимость, а потому применяется в более свободных контрактных моделях, более демократичных взаимоотношениях с клиентом и на проектах, где цена ошибки не столь существенна.
Каковы ключевые особенности этих двух подходов:
1. С точки зрения разработки требований классическому бизнес-анализу свойственно более тщательное документирование. В Agile же (будем для простоты брать это иногда за синоним адаптивного подхода) у аналитика гораздо меньше документирования, т. к. акцент сделан на взаимодействии с командой. Поэтому в ситуациях, когда вместо глубокой проработки требований и фиксации их в документе можно подойти к кому-то и перетереть, Agile-аналитик выберет второе. В плане скорости и ресурсных затрат, думаю, понятно, что в Agile паровоз быстрее и проще тронется с места. Тем не менее, документирование требований как задача не ради любви к графомании появилась, и у подхода с меньшим документированием есть ряд недостатков и рисков. Но это тема отдельной статьи, а пока что я остановлюсь на артефактах чуть подробнее.
Есть такие понятия, как степень формализованности и детализация артефактов БА. В первую очередь под такими артефактами понимаются конечные контейнеры, в которых аналитик будет хранить требования, но сюда также могут входить и прочие артефакты — например, сам документ, описывающий результаты планирования бизнес-анализа, или документ, описывающий заинтересованных лиц проекта и то, как с ними коммуницировать. Под формализованностью артефактов понимается степень свободы (или, для пессимистов, несвободы) в выборе шаблона документов. Детализация — это как детальность проработки требований с точки зрения глубины, так и полнота требований вширь. Максимальная детализация — это требования, покрывающие все, даже мельчайшие аспекты алгоритмов и нефункциональных особенностей системы, причем описывающие систему с разных сторон, то бишь «взглядов» (например, с позиции юзера — Use Cases, плюс с позиции системы — Features и функциональные требования, плюс c позиции данных — Data Model + словарь данных, и т. п.) Формальные и детализированные артефакты — это документы по некому строгому оговоренному заранее шаблону, например ТЗ по ГОСТу, полноценные спецификации требований, Vision and Scope и прочие тяжеловесные документы, которых так боятся веселые и общительные Agile-аналитики. Неформальными (и, как правило, менее детализированными) считаются Agile-артефакты а-ля User Stories с критериями приемки и всякие обрывочные варианты наподобие страниц в Вики-системах с прототипами UI и комментариями к ним — то бишь те самые «черновики», к которым классические аналитики относятся с пренебрежением. Это значительно более либеральные, скажем так, требования, оставляющие простор для креатива со стороны команды разработки.
Сюда же: традиционные Agile-техники (вот уж где оксюморон) документирования требований подразумевают постановку задачи. Техники классического бизнес-анализа — накопление базы знаний. Я не буду на этом подробно останавливаться, но это полезно осознать: Software Requirements Specification — это база знаний о требованиях и в каждый момент времени она отражает актуальный срез требований к решению, который по мере внесения изменений эволюционирует и поддерживается в актуальном состоянии. User Stories — это «сделай вот такую штуку», т. е. постановка задачи, и, соответственно, каждая такая история не отражает актуальный срез требований — она устаревает после релиза версии и может быть выброшена на помойку.
Полагаю, вы уже догадались, что предиктивный подход по самой своей сути подразумевает формальные и детализированные артефакты, а адаптивный — наоборот.
2) Может и, скорее всего, будет различаться набор техник для извлечения и управления требованиями. В классическом бизнес-анализе техники частенько направлены на более глубокую проработку изучаемых вопросов. Use Cases, SWOT, анализ рисков, финансовый анализ и все то прочее, что позволяет проработать AS IS и TO BE в любой степени погружения и с максимальным бдением. И пусть никто нам не мешает любую из техник использовать вне зависимости от выбранного подхода, как правило у аналитика в Agile в арсенале более облегченные техники, позволяющие существенно быстрее, но с меньшим тщанием проработать те же самые вещи — Lean Canvas, Impact Map, Personas и пр.
3) В Agile — более сильное смещение фокуса исследования на пользователя и его потребности. И здесь не то, чтобы Agile что-то новое привносит в этом плане, просто классические подходы исторически старее. А по мере эволюции подходов к разработке люди все больше убеждались, что во главу угла при проектировании программных систем нужно ставить пользователя и опыт, который он получает при использовании системы (естественно, если это в ногу с бизнес-требованиями). Конечно же, ни один традиционный подход к бизнес-анализу не станет утверждать, что пользователь и его потребности при разработке требований — это неважный аспект. Но именно с развитием Agile появились техники, которые максимально акцентируют эмпатию пользователям системы при разработке требований и стоят на стыке с UX (Personas, User Stories, Customer Journey Map и пр.)
4) В плане концентраций усилий в традиционных подходах аналитик, как правило, больше работает на старте — на старте проекта или его итерации. Это вполне логично, т. к. бизнес-анализ — логически начальный этап работы. В дальнейшем аналитик может по большей части самоустраниться и пойти работать над другим проектом, оказывая лишь небольшую периодическую поддержку в виде консультаций или поддержки требований в актуальном состоянии. В Agile работа распределена более равномерно, что это обусловлено тем, что в Agile работают максимально небольшими итерациями и по принципу just in time — делаем работу тогда, когда она действительно нужна. То бишь аналитик в составе команды разработки будет прорабатывать требования каждые, грубо говоря, две недели, не считая Discovery. Да и помимо разработки требований работы у него хватит — постоянно участвовать в коммуникациях с командой и заказчиком, ведь документация у нас, как мы уже говорили, облегченная и подразумевает много разговоров и пояснялок.
Тут стоит добавить, что Agile в принципе поощряет такое понятие, как постепенная, итеративная разработка требований. Если классический бизнес-аналитик стремится сделать требования максимально качественными перед тем, как отдать их в команду разработки, то Agile-аналитик будет сознательно делать их максимально черновыми на старте с постепенной доработкой в параллели с тем, как команда примется их реализовывать.
5) Работа с изменениями. В классических подходах она может варьироваться в зависимости от контрактной модели проекта и принятого подхода работы с заказчиком. Аналитик может либо жестко охранять скоуп («эээ, чувак, мы это не обсуждали — это потребует дополнительных ресурсов»), либо, наоборот, охотно приветствовать любые изменения, т. к. это дополнительные деньги. Agile тут более однозначен: несмотря на то, что есть вариации и привязка Agile к fixed price проектам, чаще работа все же идет по T&M-концепции. Сам подход к планированию релизов заключается в том, что команда фиксируется больше на краткосрочных планах. Конечно, это не означает, что длительное планирование отсутствует, но это уже неизбежные эволюции под разные специфики, а потому, если утрировать, что будет дальше — не так важно: через 2 недели на старте очередного спринта заказчик может все кардинально переиграть, ну а мы как аналитики приветствуем радостной улыбкой.
6) И последнее: в традиционных подходах роли более обособлены, что применимо, в принципе, ко всей команде разработки. Требованиями занимается аналитик — это его епархия. Да, он работает в тесной связке с внешними и внутренними заинтересованными лицами, но именно он отвечает за работу с требованиями и выполняет ее абсолютную часть. В Agile же поощряются кросс-функциональные команды, плюс совместная работа над разными аспектами проектов по необходимости. В комбинации с пунктом про итеративную проработку требований работает это примерно так: аналитик фасилитирует, т. е. организует и управляет начальной проработкой требований вместе с заказчиком, сразу же вовлекая туда экспертов из команды разработки как консультантов. Эти черновые требования затем на разного рода встречах совместно дорабатываются всей командой с аналитиком в качестве центральной точки этого процесса. Как следствие, и ответственность за итоговые требования более размазана по всей команде, нежели в классическом варианте.
Ну и в заключение: какие факторы учесть при проработке BA approach? Вкратце, ибо это отдельная тема, плюс контент ниже будет изобиловать весьма неоднозначными постулатами, требующими детального пояснения (на которые в рамках подобной статьи нет ни времени, ни места):
1) Сама модель и методология разработки ПО. Полагаю, выше прослеживается, какой подход чему свойственен. Зачастую именно этим и ограничивается принятие решение о том, каким будет бизнес-анализ.
2) Чем рискованнее для последующего использования само решение, плюс чем оно сложнее с т. зр. масштабов и усилий для его разработки и внедрения, тем к более формальному подходу имеет смысл склоняться. Медицинское ПО, ПО для военного оборудования, атомных реакторов, сложное с позиции архитектуры или внутренних алгоритмов ПО — все это сигналы для того, чтобы выбрать как минимум ряд аспектов предиктивного подхода.
3) Формальность контракта с заказчиком и его личные предпочтения. Жесткие условия при работе с клиентом (например, fixed price) — сигнал к предиктивному подходу.
4) Распределенные заинтересованные лица, т. е. те, которые находятся не у тела команды, а далеко и географически в разных местах и временных зонах — это еще один сигнал к большей предиктивности подхода (коммуникации становятся ограниченными в плане времени, добавляется ряд помех в виде языкового барьера и временных зон, а собрать их вместе на продуктивный воркшоп становится сложнее).
5) Как опыт команды разработки, так и ее постоянство (или, снова для пессимистов, непостоянство). Опытные разработчики со значительно большей вероятностью заметят неполноту или иную некачественность требований и уточнят у аналитика. Плюс на их совесть можно оставить креатив в ряде вещей («Вася, придумай сам, как тут сделать наиболее юзабельно – главное, чтобы пользователь мог выполнить задачу.»). Чем опытнее и самостоятельнее команда разработки, тем большую адаптивность подхода можно позволить. Если команда разработки склонна к частым ротациям, то такой команде нужны артефакты, в которых они в любой момент смогут узнать необходимые требования к тому, что было разработано до них, чтобы внести туда какие-либо изменения — в такой команде предиктивность важнее.
6) Важно ли для кого бы то ни было хранить требования в долгосрочном варианте, или же требования нужны только для того, чтобы разработать систему? Например, ожидаемые частые изменения, когда решение уже будет разработано, в комбинации с непостоянством команды. Или сложность решения в комбинации с ожидаемой необходимостью выяснять, как же там и что работает. Для таких ситуаций будучи базой знаний лучше подойдут артефакты предиктивного подхода.
Ну и в конце я бы хотел донести следующую мысль:
Долгосрочно оптимальным подходом всегда будет ваше умение собрать собственный конструктор под конкретный проект. Для этого как раз и нужно понимать, какие вариации подходов есть и в чем их специфики. Также далеко не лишним будет постоянно расширять арсенал техник, артефактов и инструментов, чтобы умело собирать из этих кирпичиков личный или командный домик на проекте. Вредным же я считаю подход «Agile — единственная истинная религия», а User Stories — венец техник БА, а потому помимо них ничего уметь не нужно. Если вы аналитик, умеющий функционировать только в рамках гибкого подхода и его техник, то вы не гибкий аналитик — вам сложно будет адаптироваться к разным ситуациям.