Comments 15
Спасибо, интересный материал. Жду следующих частей!
Опять разработку требований подменили управлением
Я бы сказал, что это самопиар в виде описания опыта работы в конкретной компании (Банк), с её терминологией и жизненным циклом. Ничего общего с общим подходом нет. Да, определённые приемы вполне рабочие, но выделять их, можно только Уже имея соответствующий опыт. Для начинающих Аналитиков, только как кейс, откуда дёргать то что хочется попробовать на практике...
Спасибо за интерес к статье. Вы правы, в статье рассматривается конкретный кейс. Действительно каждый проект индивидуален и используемые на нем инструменты зависят от многих факторов. Это предметная область, размер компании, используемые в компании методологии управления разработкой и даже прошлый опыт участников команды проекта. С универсальными подходами можно ознакомится в теории. Я, конечно, не претендую на лавры Вигерса и не думаю что можно в одной статье описать больше инструментов чем в SEBoK и BABOK. Но у универсальных подходов есть и свои недостатки. Бывает такое что начитавшись теории, приходишь на реальный проект и просто не знаешь с чего начать. Учебные проекты как раз и нужны, для того чтобы приземлить теорию в асфальт практики. Лучше попробовать описать требования хотя бы для одного проекта с использованием конкретного инструмента, чем долго читать теорию и ждать когда найдется компания которая слово в слово следуют описанным в теории методологиям, и очень ищет аналитика педанта.
Гораздо эффективнее начинать инициацию с определения бизнес-потребности.
В таком случае будет решаться конкретная боль бизнеса/заказчика. Иначе цель ради цели может привести к разочарованию заказчика и существенным различиям ожидаемого и фактического результатов.
Бизнес-потребность, как и бизнес-цель/бизнес-требования, могут быть сформулированы умным заказчиком заранее.
Если бизнес-потребность не определена, то сперва собираются первичные требования, которые потом лягут в основу бизнес-потребности, а затем и в основу бизнес-потребности.
Низкоуровневая бизнес-цель по данной бизнес-потребности формулируется только после определения потребности. Верхнеуровневая бизнес-цель может распространяться на десятки бизнес-потребностей. Верхнеуровневая бизнес-цель — это цель, которая была сформулирована заказчиком или рукодством заказчика перед началом работы аналитика и задает рамки проекта, а также направление исследования или анализа.
На основе полученной/сформулированной бизнес-потребности будут разработаны бизнес-требования, а затем функциональные/нефункциональные требования и критерии приемки. Если речь о разработке информационных систем.
Описанный мною подход абсолютно практический. Подход из статьи сильно теоретизированный и не универсальный.
Описанный вами подход никак не противоречит тому что написано в статье. Я также предполагаю что аналитик начинает свою работу с определения бизнес — проблемы и бизнес — цели https://disk.yandex.ru/i/zJ_nRs1sABiJaA . Бизнес требования, как и требования любого другого типа могут быть при необходимости декомпозированы. Но сути дела это не меняет. Заказчик может сформулировать бизнес требования самостоятельно, это тоже правда. А может и не сформулировать и тогда аналитику нужно ему помочь. Мне кажется мы с вами говорим об одном, но только разными словами :)
Это больше обязанности бизнес-аналитика, чем системного.
Скажите, как сочетается утверждение "В DTB разделяют идеологию гибких методологий разработки" и описанная дальше поэтапная работа по "водопаду"?
Это очень интересный вопрос, дискутировать о котором можно часами. Вы буквально открыли ящик Пандоры :)
В начале позволю себе немного придраться к терминам. Обратите внимание, на фазе инициации не была написана ни одна строчка кода :) Мы только выявляли, анализировали и документировали требования. Частично были затронуты некоторые вопросы из сферы управления проектами. Думаю что описанной в статье информации недостаточно для того, чтобы определить используемую модель управления разработкой.
Тем не менее давайте представим что в статье использовалась следующая формулировка "В DTB разделяют идеологию гибких методологий управления проектами". И чтобы не вдаваться в детали будем придерживаться гипотезы, о том что все методологии управления проектами можно разделить на две группы: водопад (каскад) и итерационные (гибкие). На мой взгляд, тот факт что аналитику нужно выполнять свою работу в определенном порядке, еще не говорит о том что он работает по водопаду.
Поясню почему так:
- Несмотря на то что на этапе первичного анализа мы выявили требования по работе с общим счетом из мобильных приложения клиента DBT и в целом понятно как могут использовать общий счет юр. лица. Мы сознательно отложили анализ этих требований на более поздние этапы. По сути это крупные итерации по выявлению требований.
- Каждый созданные аналитиком артефакт обсуждался со стейкхолдерами и корректировался на основании обсуждения. Это оперативное получение обратной связи и работа с изменениями требований.
- На основании первичного анализа были определены границы проекта, но не был составлен детальный план проекта, которого нужно было бы придерживаться при работе по водопаду.
Таким образом, то что аналитик работал последовательно, не значит что он не был гибким. Просто гнулся он в правильном направлении :)
Рада буду прочитать ваши контраргументы. Будет здорово, если вы напишете, почему эта модель относится к водопаду :)
Холивар был бы, если бы мы утверждали "мой подход АА лучше", а я говорю про противоречие формулировок (не утверждая сейчас, что лучше - я могу топить как за ту, так и за эту сторону).
В новой формулировке "гибкие методологии управления проектами" мне тоже видится оксюморон: проекты - это одно, а продуктовый подход (для чего и придумали гибкие методологии) - это другое.
Приятно и не привычно видеть на habr комментарии не нацеленные на холивар :)
Оксюморон, есть и он был добавлен осознанно. На стадии инициации мы очень приблизительно определяем границы проекта. И неважно используется проектный или продуктовый подход. Прежде чем начать какую-либо доработку нужно понимать хватит ли нам времени и бюджета на то чтобы ее реализовать. Да, agile учит нас быть гибкими. Да, нужно быть готовыми к изменениям. Но надо понимать что изменения могут быть разными. Если мы можем выявить какие-либо требования и риски на ранних этапах, нужно это сделать, не зависимо от используемых методологий. И это не мешает нам заложить лаг по времени и бюджету на случай если появятся требования и риски которые мы даже представить себе не могли.
Многие проповедники agile часто забывают что изменения все-таки должны быть обоснованы. Например, не стоит постоянно вносить правки в архитектуру, потому что вышел новый фреймворк или СУБД. Все хорошо в меру. И с гибкостью тоже не стоит перебарщивать.
Если мы занимаемся продуктовой разработкой можно рассчитывать что продукт будет приносить деньги, на которые можно будет пополнять бюджет на разработку нового функционала. Но понять хватит ли нам этих денег мы сможем только оценив стоимость разработки. А для оценки стоимости нам нужно хотя бы верхнеуровнево понимать что входит в этот новый функционал (описать вариант реализации).
Гайд для системного аналитика: как управлять требованиями на разных этапах проекта. Часть 1: Инициация