Добрый день коллеги, я хочу представить вам запись полной версии моего доклада ROOP или Agile или выбор подхода в IT-проекте. О чем же хотелось бы с вами поговорить? Мы с вами являемся членами всемирного сообщества аналитиков, бизнес или системных в данном случае не важно. Это то, что нас с вами объединяет. Но на самом деле мы с вами очень разные.
Мы отличаемся по возрасту, отличаемся по гео... Мы с вами живем в разных странах и зачастую являемся представителями разных культур. Мы с вами живем на разных континентах, нас могут разделять моря и даже океаны.
На самом деле, ничто нас так сильно не разделяет, как приверженность к двум большим лагерям. К лагерю сторонников того, что называется традиционным подходом, и того, что называется общим названием agile, или подходы под общим названием agile, гибкие подходы. Кто же из них прав?
По чьи знамена стать так, чтобы не ошибиться с жизненным выбором? Это особо актуально для начинающих аналитиков. А нужно ли вообще выбирать пенсию? или делать этот выбор один раз и навсегда.
В данном докладе я берусь утверждать, что этого непримиримого противоречия не существует. Какой подход выбрать, это не вопрос вашего жизненного выбора. Аналитик должен одинаково хорошо владеть как гибкими, так и традиционными подходами.
Вопрос выбора подхода к конкретному проекту это вопрос, который должен решаться именно на уровне конкретного проекта. Как же выбрать подход для конкретного проекта? С этим мы и попробуем сейчас разобраться. Давайте определимся с тем, что же такое подход или методология. Подход это то, что описывает этапы жизненного цикла процесса разработки программного обеспечения.
Это то, что описывает этапы жизненного цикла разработки программного обеспечения. Это то, что описывает роли и их действия или активности на этапах жизненного цикла. Это то, что описывает артефакты или документы, которые разработаны.
разрабатывается как результат работы ролей на этапах жизненного цикла разработки программного обеспечения. Сейчас существует достаточно большой набор как домашней разработки подходов, так и всемирно признанных подходов, оформленных в виде целых сводов знаний, в виде целых методологий. Это такие как Макроскоп, это Rational Unified Process, это MSF и это семейство подходов под общим названием Agile подходы.
Миром IT была предпринята попытка выполнить некую общую классификацию всех подходов. Эта классификация была проведена на основе критерия возможности выполнения следующих моментов. Первое это возможность указать конечную дату окончания проекта. Второе это возможность проведения долгосрочного планирования. И третье это отношение к изменениям уже существующих требований.
На основе вот этой классификации... были созданы две большие условные группы, в которой были разнесены все эти подходы. Первая группа это подходы, основанные на долгосрочном планировании. План-дривен-подходы.
И вторая группа это группа подходов, которая основывается на изменениях. Для того, чтобы выбрать один из возможных подходов, необходимо знать их основные свойства. Давайте быстро вспомним их основные особенности. Первая условная группа это план-дривен-методологии.
То есть методология. основаны на долгосрочном планировании. План-дривен-подход или методология это подход, при котором у нас есть возможность постепенно, шаг за шагом, от итерации к итерации, вычислить следующие вещи.
От самой начальной идеи, которая витает еще в голове заказчика, до конечных результатов мы прорабатываем следующие моменты. Первое. Мы имеем возможность проработать полный набор детальных требований к будущему настройкам.
нашему решению. И эти требования согласовать с заказчиком. На основе детально проработанных требований у нас есть возможность понять и оценить, какого количества и какого качества сотрудников мы должны включить в нашу команду. Третье.
На основе этой информации мы имеем возможность достаточно точно определить, какое количество времени нам потребуется на реализацию этого проекта. И на основе этой информации рассчитать достаточно точно бюджет проекта. Мониторя любое отклонение из этих показателей на протяжении всего у проекта, мы имеем возможность достаточно грамотно работать с рисками проекта. План-древний подход основывается на том, чтобы В трех таких несколько идеализированных постулатах.
Первое. Все требования должны быть в полном объеме, разработаны до начала имплементации и согласованы с заказчиком. Второе.
Поскольку на основе разработанных требований проводятся все необходимые оценки, любые изменения к этим требованиям должны быть в полном объеме. требованиям нежелательны, потому что если требования будут меняться, наши оценки поплывут. И третье. Если мы разработали наш программный продукт в полном соответствии с согласованными требованиями заказчика, в этом случае заказчик будет доволен тем, что мы разработали. Данные подходы также используются в тех случаях, когда общение с заказчиком затруднено.
В каких случаях может возникать это затруднение в общении? Первое. Это разница во времени.
Второе. Слишком формальные процессы коммуникации на стороне заказчика. Третье. Заказчик недосягаем.
Ну, очень большой начальник. И четвертое. Это языковой барьер. Чуть позже мы более подробно рассмотрим все эти моменты.
Далее, если требования проработаны детально, и это не оставляет какой-то двусмысленности или неоднозначности, если они согласованы с заказчиком, то ситуация, когда после всего этого мы выдадим что-то глючно и несоответствующее требованиям, совершенно недопустимо. Один-два раза заказчик простит нам это, на третий раз он просто найдет другого исполнителя. Каковы же основные особенности Change-Driven подходов? В первую очередь, это отношение к изменениям в требованиях.
Если для план-дривен-подхода любые изменения уже готовых и оцененных требований это просто беда, то для ченч-дривен-подхода это основной движок проекта. Именно поэтому подход так и называется Change Driven. Мы помним, что суть данного подхода заключается в быстром предоставлении значимого с точки зрения бизнеса результата путем очень коротких итераций. Но на самом деле за быстрое получение первого результата и возможность получать через каждые 2-3 недели потенциально работающий продукт необходимо платить.
Чем же заказчик должен платить за это удовольствие? Первое. Главное, с чем приходится мириться при таком подходе, это то, что на первых этапах проекта, на первых итерациях или спринтах проекта, заказчик будет получать нечто очень далекое от желаемого окончательного результата. Но это не вина проектной команды, это нормально для agile проектов, поэтому заказчик должен быть готов к этим рискам и быть готов с ними мириться. Отлично.
Давайте разберемся с теми свойствами или атрибутами проектов. которые нам необходимо проанализировать для того, чтобы понять, какой подход будет наиболее приемлем для данного конкретного проекта. Под понятием приемлемости подхода я понимаю возможность минимизировать риски с помощью данного подхода. То есть, чем больше рисков закрывает данный подход, тем более приемлемым данный подход является для данного конкретного проекта. Первый атрибут это время проведения этапа анализа.
В данном случае под словом «анализ» подразумевается как бизнес, так и системный анализ, то есть те работы, результатом которых является полный набор детально проработанных требований и согласованных с заказчиком требований. На данном этапе мы должны понять, какое время для бизнеса или системного анализа является наилучшим. для данного конкретного проекта?
Или, точнее, какое время для проведения анализа наиболее приемлемо с точки зрения нашего заказчика? Представим себе следующую ситуацию в проекте. Заказчик выделяет со своей стороны людей, которые будут отвечать за формулирование всех пожеланий и ожиданий заказчика в отношении разрабатываемого решения.
Эти люди выделены на промежуток времени, который гораздо меньше, чем время проведения проекта, чем продолжительность проекта. При этом заказчик желает, чтобы за это время мы успели детально проработать требования, чтобы мы успели пройти процедуру согласования их с заказчиком. И мы успели получить от заказчика формальное подтверждение, что это именно то, что они хотят от нас получить.
Впоследствии мы, безусловно, будем иметь возможность общаться с заказчиком, получать уточнения или даже изменения к требованиям, но больше отрывать своих специалистов для постоянной интенсивной работы с нами заказчик не готов. Таким образом, если мы понимаем, что заказчик хочет, чтобы анализ был проведен до начала разработки, и все требования были собраны, уточнены, проведены, согласованы, Прежде чем они будут реализованы, это является хорошим органом для реализации. за то, чтобы предложить некий план-дривен-подход. Некой противоположностью являются change-driven-подходы.
Данные подходы предполагают, что изначально собираются требования к будущей системе, но на самом общем уровне детализации, без указания каких-либо деталей. Просто в виде стандартной фразы я как такой-то такой-то хочу иметь возможность делать то-то, то-то для того, чтобы достичь ту или иную бизнес-цель или выполнить ту или иную бизнес-процессу. с функцией. Более детальная проработка требований проводится только тогда, когда какой-то поднабор требований отобран для реализации в ближайшей итерации или спринте.
В требования добавляются детали, возможно макапы и так далее. Таким образом, команда вступает в проект с очень высокой степенью неопределенности. Это приводит к тому, что практически невозможно заранее точно определить необходимый состав команды, абсолютно невозможно явно определить дату окончания проекта, то есть время, которое потребует И по причине этих неопределенностей никто не может сказать, сколько денег потребуется на реализацию данного проекта. Мы вступаем в проект с достаточно высокой степенью неопределенности. Мы вследствие этой неопределенности не можем рассчитать эти атрибуты проекта.
Следующий момент. При таком подходе не только мы, а требования не только будут дорабатываться, изменяться в процессе разработки, но на протяжении всего проекта новые требования будут добавляться в наш бэклог. Это означает, что бэклог содержит далеко не все требования изначально, в начале проекта, которые в конце концов потребуется разработать.
Это означает, что это не позволяет на начальной стадии проекта предугадать конечный облик нашего решения. Бывает так, что на начальных этапах проекта заказчик достаточно смутно представляет, что именно он хочет получить в результате. Это понимание приходит в процесс имплементации требований итерационно, то есть изначально требование разрабатывается с минимальным объемом деталей, в таком виде оно отправляется в имплементацию, по окончании для заказчика проводится демонстрация того, что разработано, заказчик добавляет новые детали или убирает последствия каких-то неверных предположений. Обновленный требуем вновь возвращается в бэклог, приоритизируется, оценивается и включается в один из последующих спринтов.
Этот цикл для каждого отдельного требования продолжается до тех пор, пока заказчик не скажет «стоп, вот это то, что я хотел от вас получить». Естественно, при таком подходе к работе с требованием, заказчик должен быть как можно ближе к команде разработки и быть максимально доступен на притяжение всего проекта. Поэтому, если заказчик готов стартовать разработку с минимальнейшим пониманием того, а что же необходимо разработать, и готов изменять существующие требования и добавлять новые на притяжение всего проекта, это хороший аргумент за то, чтобы предложить Change-Driven подход. Опять же, при выполнении всех прочих условий, которые мы рассмотрим с вами далее.
Следующее свойство это уровень формальности и детализации разрабатанных документов требований. Если проект соответствует перечисленным ниже высказаниям, то это означает, что у нас нет необходимости в разработке объемной, очень детальной, формальной документации. Почему?
Давайте разберемся. Заказчики интенсивно вовлечены в процесс работы проекта. У нас нет необходимости разрабатывать большие формальные документы для того, чтобы показать наше понимание пожеланий заказчика, наше понимание бизнеса заказчика и получить какое-то формальное утверждение.
Подтверждение того, что наше понимание верно. Общение с заказчиком происходит оперативно и неформально. У нас разработчики обладают значительным знанием в предметной области. В этом случае у нас нет необходимости разрабатывать достаточно большие детальные требования. Что это за ситуация?
Очень часто в проектах складывается ситуация, когда разработчики достаточно давно работают в рамках какого-то бизнес-домена. уже несколько лет работает в одном и том же проекте, разрабатывает первую, вторую, третью версию этого продукта. И они уже достаточно хорошо знают специфику данного бизнеса.
В этом случае у нас нет необходимости в написании больших объемных документов для того, чтобы передать разработчикам информацию о бизнесе. Нам вполне достаточно написать небольшой документ, в котором описывается только та бизнес-функция, та бизнес-фича, которую они хотят получить, заказчик хочет получить на данном конкретном этапе. Зачастую, исходя из каких-то своих бизнес-приоритетов, заказчик хочет получить первый результат от команды разработки как можно быстрее, даже при условии, что данный результат будет весьма далек от конечного требуемого состояния. Когда такая ситуация может возникнуть?
Допустим, заказчик выходит на совет акционеров. Ему необходимо показать результаты работы, показать, что уже существует понимание, какой будет конечный облик нашего решения, что у нас уже есть выбранное решение, и дальше мы будем только наращивать функциональность. В этом случае мы не тратим время на разработку детальной документации. Команда разработки быстро выполняет имплементацию какого-то основного функционала, создает некую упрощенную модель будущего решения. И вот с этой моделью заказчик...
Заказчик решает свои бизнес-задачи. Впоследствии это решение будет дорабатываться, оно будет наполняться новыми бизнес-функциями, новым функционалом. Но сейчас на данном этапе это некая такая упрощенная модель.
Следующее. Реализация проекта возможна небольшой, централизованной командой равноценных высококлассных специалистов. Проектная команда небольшая, централизованная, то есть не распределенная.
Уровень квалификации примерно одинаковый. В этом случае необходимости в объемной, формальной, задокументированной передаче знаний отсутствует. Необходимости в отложенной передаче знаний посредством документов также отсутствуют, ввиду того, что команда компактно располагается в одной локации, ну, по сути дела, в одном офисе. Команда однородная по своим полномочиям, поэтому отсутствует формализм в общении.
Необходимость в формальных документах, формальных запросах, ответах, разрешительных запросах. запретительных резолюциях и так далее. Следующее.
Заказчик готов мириться со следующими рисками. Первое. Приблизительные оценки времени и трудозатрат. Достаточно часто возникает ситуация, когда на начальной стадии проекта не только мы, но и заказчик имеет самое общее понимание, а что же он хочет получить в результате. Таким образом, мы не можем нести в результате.
обладаем информацией о том как долго продлится данный проект какое количество итераций потребуется для того чтобы все разработанные бизнес-функции удовлетворили заказчика именно поэтому оценки по времени даются самые приблизительные и жестко определенная дата окончания проекта в данном случае не имеет никакого смысла и именно поэтому такого типа проекты имеет еще одно классификационное название таймсент материал эти проекты продолжаются и оплачивается заказчиком пока заказчик сам не примет решение, что проект завершен, и он получил все, что он хотел, и именно в том виде, в каком он действительно хотел от нас получить. Следующее. Получение продукта, не точно соответствующего ожидания, содержащего достаточно большое количество ошибок.
Это на самом деле неизбежная плата за ту неопределенность, с которой команда вступает в этап имплементации в высокоуровнях, то есть не детальных требований. Этот риск очень высок в начале проекта и в идеале сводится к нулю. к окончанию проекта таким образом если проект отвечает всем вышеперечисленным критериям при выполнении всех прочих условий лучшим выбором будет все таки некий change driven подход наоборот если условия в проекте складываются следующим образом условия в проекте можно описать высказывания приведенными ниже в этом случае у нас есть необходимость в разработке больших детальных и формальных документов что же это за свойства или ситуации в проекте давайте посмотрим первая разработка может быть отдана в аутсорс в этом случае есть необходимость передавать информацию исполнителям работающим в другой команде и чаще всего в других локациях достаточно часто такая ситуация осложняется Разница во времени с аутсорс-командой.
Иногда к этому добавляется еще одна дополнительная сложность. Эта сложность заключается в том, что между командами, основной командой и аутсорс-командой, внешней командой, может существовать так называемый языковой барьер. В этом случае, когда у нас очень большое расстояние между основной командой и внешней командой, в этом случае временной промежуточек, в течение которого мы можем собрать всю команду, и в онлайне пообщаться вживую, задать вопросы, оперативно получить ответы, в реальном масштабе времени передать какую-то информацию, вот этот отрезочек он очень маленький. Поэтому чем дальше разнесены части команды или основная команда и аутсорс команда, тем больше вес в общении переносится на документы.
Это приводит к следующим рискам или к следующей неизбежной формализации. Чем больше вес переносится... Упор на передачу информации через документы, тем больше информации нам необходимо передавать через документы.
Почему? Потому что таким образом мы, описывая документы, стараясь сделать документы сразу как можно более полными, тем самым мы пытаемся минимизировать риск того, что... что у нас процесс передачи знаний через документы будет затягиваться. То есть мы отправляем документ потребителям нашего документа, они присылают нам через какое-то время свои вопросы, что-то они не поняли, чего-то не нашли. Мы дорабатываем наш документ, дополняем новые информации, опять отправляем, опять получаем какие-то вопросы и так далее.
Вот для того, чтобы количество итераций сократить, мы стараемся сразу документ делать максимально полным. Чем более полный документ, тем больше объем информации он будет содержать. То есть документ...
становится достаточно большим. В этом случае возрастает требование к формальной структуре документа. То есть мы начинаем вводить некую формализацию в структуру документа. Это делается для того, чтобы потребители наших документов могли достаточно быстро, в большом объеме информации, найти ту информацию, которая им необходима, не прочитывая документ от начала до конца.
С другой стороны, если мы вынуждены... Передавать информацию через документы, передавать аутсорсные команды через документы. В этом случае у нас достаточно часто возникают риски, связанные с тем, что внешняя команда начинает затягивать со сроками ответов, со сроками, в течение которых они отрабатывают наш документ и присылают какие-то вопросы или замечания.
Для того, чтобы закрыть этот риск, мы вынуждены вводить некую дополнительную формализацию в процессы передачи информации через документы. Что это означает? Мы говорим, что ребята, давайте для того, чтобы нам не затягивать с согласованием или доведением информации через документы, давайте мы сделаем так. Мы в течение какого-то времени разрабатываем документ, отправляем этот документ вам.
Вы в течение трех дней этот документ смотрите, читаете, пишите какие-то вопросы, замечания и не позже, чем через три дня присылайте нам документ назад с вашими вопросами и замечаниями. Мы в течение, допустим, двух дней отрабатываем замечания, отправляем вам. И опять вы в течение трех дней, не более, присылаете новый набор требований, замечаний, вопросов и так далее.
То есть мы вынуждены вводить некий элемент формализации. Вот это вот дополнительная формализация в процессах доведения информации через документы. Дополнительная формализация структуры документа.
Она документа, объем информации, которую мы передаем через документы. А время, которое нам необходимо... затратить большое дополнительное время, которое нам необходимо затратить на разработку достаточно больших документов, все это не очень хорошо вписывается в неформальные стремительные agile подходы.
Поэтому, как мы увидим с вами чуть позже, в подобных ситуациях имеет смысл все-таки рекомендовать некий план driven подходы. Давайте посмотрим следующее свойство. Проектная команда графически распределена.
Несмотря на то, что проект может выполняться без привлечения субподрядчиков, каких-то аутсорсных команд, сама команда, тем не менее, может быть географически распределена. Сейчас практически невозможно найти большой, серьезный, продолжительный проект, который выполняется единой, нераспределенной командой. География, с которой мне приходилось сталкиваться, работая в проектах, была самая разнообразная. Это Сиэтл, Киев, Минск, Москва, Дубна.
Нижний Новгород, Омск и даже Хошимин. Максимальная разница между двумя составляющими одной команды достигала до 15 часов. 15 часов это разница между Сиэтлом и Омском.
В этом случае тот временной отрезок, в течение которого мы могли собрать всю команду и пообщаться в онлайне, оперативно получить ответы, задать вопросы, вот этот отрезочек был очень маленький. И поэтому, опять же... Вес или акцент в общении, в передаче информации переносился все больше и больше на документы. И дальше у нас опять выстраивается та же самая логическая цепочка.
Чем больше вес общения переносится на документы, тем более полными должны быть эти документы. Тем больше времени мы должны затратить на разработку этих документов. Тем выше требования к формализации структуры этих документов. Тем больше формализма, вынужденного формализма, мы вынуждены привносить...
в наши процессы взаимодействия распределенной команды. Опять же, при всех прочих условиях, вот эти условия проекта, они не располагают к тому, чтобы предлагать некие легкие, неформальные agile подходы. В таких ситуациях все-таки большинство рисков будут закрыты, если мы предложим некий вариант, план, driven подхода.
Следующее свойство проекта. Тестирование основано на требованиях. Если в проекте складывается следующая ситуация.
Заказчик говорит, ребята, делайте проект как угодно, но для меня ситуация, когда по результатам вашего разработки я получаю что-то несоответствующее. моим ожиданиям и содержащая достаточно большое количество ошибок, для меня эта ситуация неприемлема. Это означает, что в проекте должно быть уделено очень большое и серьезное внимание тестированию. Это означает, что сами тестовые документы должны быть очень серьезно и детально проработаны. Я надеюсь, что я не сильно ошибусь, если скажу, что в 90% проектов тестовые документы или тестовые сценарии основывается на документах требований то есть тестовый сценарий как основу берут требования описанные в виде вариантов использования то есть как минимум бизнес вариант бизнес кейс тестировщик должен проверить как пользователь будет от начала до конца проходить свой бизнес код кейс с используем нашего приложения конечно к этим К этим сценариям, написанным на основе вариантов использования, будут добавляться дополнительные шаги.
Шаг влево, шаг вправо, для того, чтобы проверить всевозможные защиты от дурака, введение неправильных значений, нажатие не тех кнопок. Но, опять же, тем не менее, в качестве основы используются документы требования. Поэтому, чем выше требования к детализации и серьезности проработки тестовых сценариев, тем выше требования к серьезности проработки, детализации и объему. Документов требований, поскольку они являются основой для тестовых сценариев.
И дальше у нас опять выстраивается наша знакомая логическая цепочка. У нас увеличивается объем документов требований, у нас увеличивается требование к формальной структуре требований. Мы вынуждены затрачивать на разработку таких документов больше времени. У нас добавляется негаформализация процессов, если команда распределена, либо работает аутсорсная команда и так далее. То есть опять же у нас возникает...
достаточно длительное время на разработку документов, большие объемы документов и формализации, которая не вписывается в agile подходы. Дальше, следующее свойство. Требуются точные оценки.
Если по условиям проекта заказчик настаивает на том, чтобы мы предоставили следующие точные оценки, какое количество специалистов и какой квалификации нам потребуется включить в команду. Сколько времени эти специалисты будут работать для того, чтобы рассчитать, какую зарплату они должны получить? Ну и, соответственно, плюс к этому, какие дополнительные программные средства, консультации нам потребуется привлечь? И, соответственно, на основе этой информации заказчик требует от нас точной оценки того бюджета, который мы затребуем. Либо он желает сверить наш бюджет и понять, насколько наш бюджет вписывается в тот бюджет, которым располагает заказчик.
Для того, чтобы выполнить вот эти оценки, нам необходимо ясно понимать, а что же мы должны разрабатывать. Вот это ясное понимание мы можем получить только на основе детально проработанных требований. Поэтому, чем более точными должны быть те оценки, которые хочет получить от нас заказчик, тем более точными должны быть проработанные требования для того, чтобы эти оценки были получены.
Таким образом, чем детальнее и формальнее документы требуются по условиям проекта, тем проще их разрабатывать в рамках план-дривен-подхода. На детальные документы просто не хватит времени в условиях скрам-пульса, если проект ведется по скраму. На получение необходимой информации для написания подробных требований не хватит времени, и для проверки объемных документов заказчикам тоже не хватит времени. Чем меньше объем...
и формальность документов требуется по условиям проекта, тем больше чаша весов склоняется к Change-Driven подходам. Опять же, при выполнении всех прочих условий. Следующее свойство проекта это подход к управлению изменениями. Нам необходимо проанализировать и оценить отношения заказчика к изменению требований в текущем проекте. Как заказчик относится к тому, что требования в проекте будут меняться.
Если с точки зрения заказчика необходимо достаточно детально проработать требования для того, чтобы получить все необходимые оценки в проекте, в этом случае любые изменения будут рассматриваться как нечто нежелательное, потому что оценки проекта поплывут. В этом случае каждый запрос на изменения обрабатывается как отдельный параллельный проект. Отдельный проект, который состоит из двух основных этапов.
Первый этап. Это так называемый анализ последствий или impact analysis. В чем суть этого анализа? Напомню вкратце. На основе детально проработанных требований и на основе информации о том, о какие связи между требованиями, как эти требования между собой связаны, то есть я имею в виду трассировку между требованиями, мы получаем информацию о как много требований будет затронуто в случае, если мы вынуждены изменить то или иное требование.
Это как анализ того, как далеко разойдутся круги на воде, если мы бросим камушек. Когда мы получили информацию о том, как много требований нам придется изменить, в грамотных проектах грамотные аналитики должны выполнить еще один анализ. Анализ решения.
То есть мы не начинаем сразу реализовывать это изменение, мы анализируем возможные варианты реализации данного изменения к требованию. И грамотный аналитик должен представить заказчику минимум 3-4 возможных сценария реализации данного запроса на изменение. Эти сценарии должны быть оптимизированы с точки зрения различных ключевых критериев. Допустим, например, будет один сценарий, который будет минимизирован с точки зрения временных затрат или затратов. затрат человеческих ресурсов, либо сценарий, который будет минимизирован с точки зрения критерия минимизации рисков выведения системы из стабильного состояния.
Что это означает? Это означает, что помимо того, что наше изменение к какому-то одному требованию может затронуть другие требования, и нам потребуется изменить другие требования, под некоторыми из этих других требований могут быть уже реализованные программные модули. То есть у нас уже эти требования были имплементированы.
И сейчас система находится в неком стабильном состоянии. И внесение любых изменений в существующую функциональность это выведение системы из стабильного состояния. Это потребует, естественно, анализа последствий.
Это потребует повторного детального тестирования приложения. Но это потребует, собственно, переработки существующего функционала. Поэтому это достаточно рискованная операция.
Поэтому аналитик должен проанализировать и предоставить несколько вариантов. реализации данного запроса на изменения. После этого эти варианты предоставляются заказчику, и только заказчик, выделенные специально люди на стороне заказчика, принимает окончательное решение, будет ли реализовано данный запрос на изменения, и какой из сценариев будет наиболее предпочтительным при реализации данного запроса на изменения. Либо, по результатам этого анализа, заказчик примет решение вообще не реализовывать данный запрос на изменения, поскольку последствия будут гораздо более плачевны, если мы данный запрос на изменения реализовывать не будем если мы говорим о том кто имеет право на стороне заказчика принимать такие решения последующем мы еще раз затронем этот момент сейчас мы сразу можем сказать что это в первую очередь спонсор проекта если проекте есть явно выделена роль такая на стороне заказчик спонсор проекта под это человек который имеет достаточно знаний о будущей системе достаточно знания о бизнесе которые позволяет ему принимать осмысленные решения по изменению будущего функционала.
И это человек, который головой отвечает за бюджет проекта. Он спонсор проекта, он отвечает за бюджет проекта. Почему именно спонсор, почему бюджет проекта?
Потому что любое изменение к существующим требованиям, при наличии уже оценок бюджета и так далее, любое изменение это дополнение к бюджету, это не запланированные расходы. Это отклонение от существующего бюджета. и поэтому человек должен обладать достаточно полномочий для того чтобы принимать решение об изменении бюджета о дополнительных затратах окей поехали дальше таким образом чем детальнее и формальнее документы требования Таким образом, если наш проект соответствует вышеописанным свойствам, в этом случае мы должны рекомендовать некий план-дривен-подход. Напротив, если заказчик желает получить результат как можно раньше и готов стартовать проект в условиях высокой неопределенности без детальной проработки требований, в этом случае изменения и дополнения требований не только неизбежны, но и жизненно важны для проекта.
В этом случае процесс обработки запросов на изменения абсолютно неотделим от процесса сбора требований. Измененные требования обрабатываются, приоритизируются и планируются к реализации точно так же, как и новые. или уже существующие требования. Таким образом, если заказчик готов начать имплементацию в условиях достаточно большой неопределенности, когда для заказчика получать быстрый и достаточно частый результат гораздо важнее, чем следование формальным процессам, и самое главное, заказчик готов мириться со всеми рисками, связанными с подобным подходом, очевидно, что ChangeDriven подход это будет наиболее разумное решение. следующее свойство проекта это очень важный момент очень важный аспект очень важно очень болезненно потому что с моей точки зрения именно вот этот аспект несет гораздо несет очень много рисков для атишных проектов это взаимодействие с заказчиком если проект соответствует описание которое будет приведено ниже в этом случае нам необходимо желательно рекомендовать план driven подход какие же это свойство давайте посмотрим Заказчик в силу собственной внутренней корпоративной культуры требует соблюдения формальных процессов общения, принятых в их компании.
Или заказчик в силу своего положения не очень легко может быть привлечен к работе в нашем проекте. Это может быть в ситуации, когда заказчик является спонсор проекта, либо когда заказчик работает в других проектах, поэтому не может постоянно быть доступен в нашем проекте. Либо заказчик является достаточно высокопоставленной фигурой на стороне заказчика. В этом случае нам прийти к заказчику, хлопнуть его по плечу и сказать, пойдем пообщаемся на митинге, в этом случае нам будет крайне сложно.
Если в проекте заказчик требует следовать достаточно сложным формальным процессам подачи запросов на получение какой-либо необходимой нам информации, документов, на проведение демонстрации и так далее, то это будет крайне сложно поддерживать в условиях неформального agile подхода. Нам, к сожалению, приходилось, или к счастью, приходилось сталкиваться с подобной ситуацией, когда проводился стартовый митинг, начинался новый проект, проводился стартовый митинг, и заказчик показывал нам презентацию, на которой... были приведены макапы и ну там краткое описание то есть системы которую мы должны были заменить новым приложением данная презентация давала нам общее понимание функционала назначение вот этой системы которая шла под замену естественно после окончания этого митинга мы попросили заказчика предоставить нам это презентация поскольку она была хорошим стартом для того чтобы начать понимать что от нас требуется заказчик сказал да конечно предоставим вам эту презентацию но Нам нужно получить разрешение на то, чтобы предоставить вам эту информацию.
Нам нужно пройти некий разрешительный процесс на своей стороне. И в результате мы эту презентацию получили где-то через месяц. Уже после того, как мы получили гораздо более серьезные, более детальные документы по функционалу этой системы.
И мы уже успели разработать некий первый набор требований. То есть, когда мы получили эту презентацию, эта презентация нам была совершенно бесполезна. Это достаточно серьезный риск.
Достаточно серьезный риск, который мы всегда стараемся отследить, как можно раньше заметить, увидеть, зарегистрировать, а начать с этим риском бороться. Потому что если каждый раз, когда мы нуждаемся в какой-то информации от заказчика, либо в каком-то документе, физическом документе, и мы вынуждены ждать месяц-два, и никто не может точно сказать, когда мы этот документ получим, в этом случае нам крайне сложно что-то планировать, крайне сложно что-то предугадать. Вот эти вещи необходимо отслеживать и очень серьезно с ними работать.
Следующий момент. Заказчик настаивает на формальных методах общения. Это могут быть записываемые очные или виртуальные встречи, по результатам которых обязательно оформляется некий формальный документ с описанием всех обсуждавшихся вопросов, принятых решений, назначенных поручениях и намеченных в следующих шагах, и кто отвечает за эти следующие шаги. Данный документ принято называть Meeting Minutes, Meeting Notes и так далее.
Наверняка многие из вас с этим документом знакомы. Это некий дополнительный элемент формализации для того, чтобы зафиксировать те вопросы, которые обсуждались, и достаточно формально утвердить или как бы получить подтверждение, что все, кто был задействован на этом митинге, согласны с этим положением, которое описано в Meeting Minutes, с теми поручениями, которые они получили, с теми вопросами, которые были заданы. с теми назначениями и ответственными, которые будут выполнять.
Это некая такая дополнительная формализация, которая, опять же, служит для цели закрытия риска в том случае, если заказчик не очень ответственно на своей стороне относится к выполнению своих обязательств. Общение с заказчиком может быть сопряжено с рисками для проекта. Например, если есть риск непонимания. Риск того, что заказчик будет затягивать с ответами.
Либо риск того, что заказчик может откровенно отказаться от им же выставленных требований. К сожалению, нам приходилось сталкиваться с ситуацией, когда был выставлен на стороне заказчика представитель заказчика. Он поставлял нам информацию о том, что мы должны разрабатывать, какие требования мы должны разрабатывать, какой функционал должен быть в будущем приложения.
Мы это добросовестно фиксировали. Потом через... Спустя какое-то время, через неделю, мы начинали с ним обсуждать уже детали, и человек в присутствии своих коллег на стороне заказчика сообщал нам, что он таких требований не выставлял.
Мы говорили, ну как же так, мы же с вами неделю назад обсуждали этот вопрос. Его аргумент был, вы меня неправильно поняли. Человек общался на английском языке, и он имел некий такой формальный повод для того, чтобы отказаться от своих слов. После этого... И мы постарались ввести некую формализацию в наше общение, понимая, что неформальное общение несет достаточно серьезные риски реворков, переработок, слайдов по срокам для нашего проекта.
Мы постарались ввести некие формальные формы, которые мы заполняли и давали на подпись с рассылкой на его менеджера, на его руководителя, этого человека и так далее. То есть мы начали вводить некую формализацию для того, чтобы подстраховать себя. и ликвидировать вот эти риски. К сожалению, вот эта дополнительная формальность не очень хорошо вписывается в agile подходы, поскольку agile подходы не предполагают какой-либо формализации в общениях.
Следующий нюанс. Заказчик может находиться достаточно далеко от исполнителя. Общение заказчика в таком случае осложнено тем, что заказчик и команда разработки разделены географически, находятся в разных часовых поясах.
Они могут быть разделены языковым барьером. При этом в общении, в вес общения, точно так же, как и в ситуациях, когда мы говорили о распределенной команде, когда мы говорили о команде суподрельных. у а вот сосны команде в этом случае вес общения больше переносится на переписку и на документы и как в те же самые в тех тех же случаях у нас возникает та же самая логическая цепочка то есть у нас увеличивается объем документов у нас увеличивается требования к формальной структуре документов мы стараемся внести некую формальность в процедуры общения тем более в этой ситуации когда мы общаемся с заказчиком потому что Мы хотим закрыть риски того, что заказчик начнет отказываться от своих слов, заказчик начнет затягивать с ответами и так далее.
То есть мы увеличиваем формальность и в переписке, и в процессах, в оформлении документов. Объем документов начинает, сами документы становятся более объемными. Ну и, соответственно, время, затрачиваемое на разработку столь больших объемных и детальных документов, оно, естественно, тоже увеличивается.
Окей, следующее свойство. По требованиям заказчика может вестись подробное документирование следующих артефактов. Это требования, подробное документирование разработки и подробное документирование тестирования. Для каких целей разрабатываются эти подробные документы? Они используются для целей планирования, они используются для целей управления процессами проекта.
Они используются для документирования проведенных работ, они используются естественно для разрешения конфликтной ситуации и они используются для хранения истории проекта. Таким образом, чем больше рисков несет неформальное общение с заказчиком, тем формальные процессы нам придется выстраивать. Чем формальнее процессы общения, складывающиеся в проекте по вине заказчика, либо по требованиям заказчика, тем сложнее поддерживать эти процессы в рамках неформальных agile подходов. Поэтому мы вынуждены предлагать некие гораздо более формальные, тяжеловесные, plan-driven подходы.
Наоборот, если в проекте заказчик доступен для частого и неформального общения, и это является его осознанным выбором, если документирование по-прежнему проводится, но большая часть необходимой информации передается именно в неформальном общении, и это не несет рисков проекта, заказчик от этого не отказывается, если решения и договоренности могут приниматься в неформальной обстановке, и это, опять же, приемлемо с точки зрения заказчика и не несет серьезных рисков для проекта, В этом случае мы говорим о низкой формализации общения с заказчиком. Если по условиям проекта допустима следующая ситуация. Разработка проводится с минимальным объемом документирования.
Оперативно производится разработка. После имплементации результат показывается заказчику. Заказчик высказывает замечание, замечание реализуется и так далее, пока заказчик не придет к пониманию, что бизнес-функция реализована именно так, как это должно быть.
И только после этого... Как эта функция реализована полностью, то есть стабилизирована, проводится так называемое пост-документирование, то есть полноценное описание того, что и как было реализовано. Есть ли общение с заказчиком, обсуждение важной информации, принятие решения может проходить в неформальной обстановке, это приемлемо с точки зрения заказчика и, главное, не несет рисков. то можно смело предлагать Change-Driven подход и не грузить заказчика излишними формальностями, которые он и так сам не требует.
Следующее свойство проекта это сложность проекта. Почему мы должны оценить сложность? Чем сложнее проект, тем детальнее, объемнее и формальнее должны быть документы требования, тем сложнее и формальнее будут процессы в проекте. Что значит сложнее? По каким критериям мы оцениваем сложность проекта?
Далее перечисленные факторы, которые увеличивают сложность проекта при увеличении их… численного значения. Первый фактор это количество заинтересованных лиц на стороне заказчика в проекте. Чем больше заинтересованных лиц, тем больше увеличивается количество ожиданий, мнений относительно того, как должна быть реализована та или иная бизнес-функция. И возникает необходимость в дополнительном времени для обсуждения различных мнений, для разрешения конфликтов интересов и для выработки некого консолидированного решения на стороне заказчика.
Если в проекте на стороне заказчика участвуют несколько больших групп, выражающих пожелания к будущей функциональности, очень может возникнуть ситуация, когда эти пожелания могут вступать в противоречие. Более того, может сложиться ситуация, когда команда, в силу ограниченных проектных ресурсов, я имею в виду люди, время, в принципе не в состоянии реализовать весь объем требований. В этом случае между этими группами возникает конкурентная борьба за ресурсы нашего проекта, за нашу проектную команду.
Различные бизнес-департаменты пытаются оказать давление на команду с целью поднять приоритет своих требований по отношению к приоритету или по отношению к требованию конкурирующих департаментов. Выходом из этой ситуации может быть только очень тщательная приоритизация требований и тщательное планирование. Для разрешения конфликтов необходимо прибегать к таким регулирующим или арбитражным органам, как спонсор проекта или Change Control Board. Мы уже упоминали эти две роли. Решать все эти проблемы в рамках неформального общения крайне затруднительно, а зачастую невозможно.
Таким образом, чем больше количество заинтересованных лиц на стороне заказчика, чем больше объем работ, связанных со сбором, формализацией, валидацией информации, чем выше сложность и формальность процессов, тем меньше для такого рода проектов подходит Change-Driven подход. Для закрытия рисков необходимо выбирать более тяжеловесный или более формальный план-древен-подход. Следующее свойство это количество бизнес-областей, которые затрагиваются проектом.
Чем больше количество разнообразных бизнес-областей затрагивает проект, тем больше объем и разнообразие бизнес-требований мы будем вынуждены обрабатывать. Безусловно, это увеличивает сложность процессов, в рамках которых мы сможем корректно обработать эту информацию, как это описано выше. Кроме этого, добавляется новый класс информации, описывающий требования к взаимодействию различных областей бизнеса. Следующий момент это количество систем, которые затрагиваются проектом. Многие компании уже пережили не одну волну разработки внутренних систем автоматизации их бизнес-процессов.
Поэтому сейчас открывается достаточно большое количество проектов, целью которых является либо замещение уже существующих систем, либо встраивание новой системы в окружение уже существующих систем. При этом новая разрабатываемая система может разрабатываться на замену целому набору существующих старых систем. В первом случае, когда проводится разработка новой системы, замещающей несколько устаревших систем, сложности проекту добавляет тот факт, что в рамках одной новой системы необходимо объединить разные, зачастую плохо уживающиеся друг с другом или полностью противоречивые требования, исходящие от заменяемых систем. В другом случае, когда новая разрабатывающая система встраивается в окружение существующих систем, сложности проекта добавляют необходимость разработки нового кластера требований.
Это интеграционные требования. То есть требования, описывающие взаимодействие новой системы с уже существующими. Сложности проекта в данном случае добавляют еще тот факт, что мы будем вынуждены подключать к проекту людей, которые в нашем проекте не работают. Они ничего не обязаны нашему проекту.
Это те люди. которые являются представителями внешних систем, внешних систем, с которыми мы будем интегрироваться. В этом случае нам потребуется не только привлекать этих людей для общения, допустим, на каких-то встречах, на телефонных звонках, на митингах, но, возможно, нам потребуется привлекать этих людей для того, чтобы они передавали нам информацию о сервисах, которые будут нам доступны. публичные сервисы.
Они должны нам передавать информацию об API этих сервисов, для того, чтобы мы могли вызывать из нашего приложения эти сервисы и использовать их в интересах нашего проекта. И самое главное, вполне может сложиться ситуация, когда мы будем... вынуждены каким-то образом воздействовать на представителей внешних систем, для того, чтобы заставить их изменить сервисы или API своих сервисов, для того, чтобы мы могли их использовать в интересах нашего проекта. Все вот эти моменты практически невозможно выполнить в условии неформального небольшого agile проекта.
Я могу сказать больше, даже в условиях больших серьезных формальных проектов, использующих формальные подходы, зачастую бывает крайне сложно выполнить вот эти задачи. То есть связаться, привлечь людей, которые не входят в наш проект, привлекать их к митингам, привлекать их к тому, чтобы... заставлять их, чтобы они рассказывали о своих сервисах, и тем более заставлять их вносить изменения в собственную систему, только потому что какая-то внешняя система, потребитель, наша будущая система, нуждается в сервисе, который предоставляет немножко другой API.
Это крайне сложно, поэтому только через формальные процессы, только через выход на вышестоящие какие-то органы, на спонсоры проекта, на Change Control Board, может быть, на топ-менеджмент компании, мы можем решать вот эти проблемы. В условиях неформальных подходов решать такие задачи практически невозможно. Таким образом, в обоих случаях увеличение замечаемых систем или систем, с которыми необходимо интегрироваться, вполне может приводить ко всем тем рискам, которые мы уже успели рассмотреть в предыдущих двух пунктах.
В этих случаях, в этих ситуациях, план Древин Подход позволяет закрыть максимальное количество рисков. Окей, мы с вами вспомнили основные особенности подходов и рассмотрели атрибуты или свойства проектов. Мы увидели, что в одних случаях лучше использовать один подход, в других случаях другой.
Но как быть, если один и тот же проект по одним параметрам? может быть проведен с использованием план-древен подхода, по другим параметрам с помощью ChangeDriven подхода. Мы с вами рассмотрели, условно говоря, чистые методологии.
Но, зная все те параметры проекта, которые мы с вами обсудили, и зная, какими способами мы можем заканчивать... закрыть риски, создаваемые этими параметрами, мы можем создать некий собственный подход, симбиоз, взяв необходимый из план-древен и из чент-древен подходов. Таким образом, не существует никакой конкуренции между чистыми методологиями. Не существует единственного лучшего подхода, единственного верного подхода, который будет применим во всех случаях жизни и во всех проектах.
Подход подбирается индивидуально, как конструктор для каждого проекта, и может быть взят как полный подход. полностью из известных методологий, так и создан в виде уникальной комбинации этих методологий. Коллеги, огромное спасибо вам за терпение, за внимание.
Если у вас остались вопросы, я с огромным удовольствием отвечу на эти вопросы по электронному адресу, который вы сейчас видите на ваших экранах. Еще раз спасибо. До свидания.