Роль бизнес-аналитика (БА, англ. — BA) в проектах Agile в некотором смысле сходна с ролью проектного менеджера (ПМ, англ. — PM). При этом некоторые люди считают эти роли совсем ненужными! Например, руководство по практическому применению Agile-методов Scrum Guide, где излагается суть подхода Scrum («скрам»), описывает только три роли: скрам-мастер, владелец продукта и команда разработчиков. Даже в случае, когда вы изучаете в описании Scram Guide роль команды разработчиков, не говоря уже об аналитиках или аналитической работе. Однако, большинство организаций согласны с тем, что хорошие бизнес-аналитики являются ценным активом для любой команды, будь он запланированный, маневренный или гибридный.
В этой статье подразумевается, что БА, действительно, проверяет то, что остается неизменным в Agile-проекте и то, что меняется. Говоря вкратце — По какой причине и Какие именно основы остаются теми же, и какие детали кардинально меняются (Каким образом, Когда, Где, С Кем).
Давайте начнем с того, Что должны делать бизнес-аналитики. (Я имею в виду — должны делать, а не действительно делают, так как они могут смотреть видео-приколы с кошками большую часть рабочего времени. Это – не занятие во время работы!) В любом случае, бизнес-аналитики выявляют, анализируют, взаимодействуют, управляют и проверяют необходимые условия. Также они помогают понять бизнес и обеспечивают решения, подходящие этому бизнесу. Кроме того, они помогают переводить технические вопросы в бизнес и поддерживать связи с заинтересованными сторонами.
Причина, по которой они делают эти вещи, должна быть достаточно очевидной: чтобы помочь обеспечить создание проектом нужного продукта, а также не пропустить информацию и понять требования заказчика. Также они являются ценными помощниками в продвижении и преодолении барьеров в коммуникациях между клиентом, заказчиком и технической группой.
Важным аспектом является тот факт, что все эти функции, роли, потребности или то, что вы хотите назвать, по-прежнему существуют на Agile-проектах. Кроме того — в некоторой степени – из-за того, что гибкие сроки нередко сжимаются, эти функции становятся более важными для команды, чтобы оставаться продуктивной и профессиональной, так что хорошие бизнес-аналитики бесценны.
Теперь о характере изменений. Давайте начнем с вопроса «Как?». Команды Agile, как правило, не создают большие, детализированные требования к документам, которые были рассмотрены и утверждены до начала серьезной разработки.
Наоборот, требования могут быть зафиксированы в качестве истории пользователя, или на учетных карточках, которые выступают, как напоминание пойти и поговорить со специалистом по соответствующей теме до развития. Они, как правило, меньше по объему в отношении охватываемого ими масштаба и глубины описания. Больше похожи на микро-требования к невнимательным читателям, которые хотят видеть только небольшие, размером с бит, компоненты информации.
Такая зернистая структура фактически обеспечивает большее количество возможностей для перемещения и изменения приоритетов в накопленной базе знаний. Люди также имеют тенденцию давать более точную оценку и более детально проверять результат.
Однако это увеличивает количество элементов управления, а бизнес-аналитики могут помочь в управлении и визуализации главной картины проблемы, являющейся особенно ценной. Переход к более «визуальным и вербальным» форматам часто возникает на Agile-проектах. Больше нет огромного количества письменной информации. Напротив, доски задач и совместные знания, полученные в процессе взаимодействия команд и работы в совмещенных пространствах, являются нормой.
Когда потребности выявлены, проанализированы, доведены, управляемы, и также подтверждена перемена, больше не существует фазы проекта, посвященной в основном выявлению и пониманию большинства требований. Теперь гораздо меньше подтверждений требований со знаком офф до начала работы. Вместо этого, они точно в срок собраны из всего проекта, для работы с ними программистов, и в том виде, в котором они появляются, начиная от демонстрации клиентам и планирования сессий. БА должны сохранять внимательность, получая потенциальный материал из вопросов клиентов. Важным аспектом является роль владельца продукта, помогающего фильтровать существенную информацию от ненужной, а затем назначать приоритеты для развития.
Вопрос «Где работать?», как правило, также претерпевает изменения в гибких Agile-проектах. У БА появляется меньшее количество выделенного рабочего пространства, а больше открытой командной работы. Процесс может быть долгим, кропотливым и сфокусированным на больших, более сложных документах, но такие условия хороши для уточнения деталей и охвата всего материала. Команды Agile в большей степени опираются на очное общение, которое более быстрое, дает возможность анкетирования и выявления проблем более эффективно, а также более легко передает язык тела и эмоции.
Многие Agile-команды состоят из одного или нескольких распределенных членов команд. Таким образом, каждый должен получить соответствующую ему область работы с онлайн-инструментами взаимодействия. Условия, как правило, содержатся в онлайн-хранилищах, доступных заинтересованным сторонам отовсюду. Адаптивность и готовность для БА попробовать, а затем освоить эти инструменты, очень важна для них, чтобы оставаться компетентными и добавить ценности команде.
Наконец, вопрос «С кем?». БА по-прежнему играет важную роль связиста или транслятора между клиентами, переводчиками и техническими ресурсами, но опять же, роль меняется. Команды разработки Agile способны быть обобщающими специалистами с более широким набором навыков, включая бизнес-переговоры и сбор требований. Это играет напрямую на традиционную территорию бизнес-аналитика, но БА по-прежнему ценны, если они выступают в качестве посредников в этой работе. Возможно, фокусирование своего времени на более важном взаимодействии с заинтересованными сторонами (бизнес- или техническими) и уверенность в том, что ни один голос не остался незамеченным, а также обеспечение выполнения задачи с подтверждением всех заинтересованных сторон, приводит к взаимным договоренностям.
Преднамеренный переход от посредника к координатору заслуживает отдельного внимания. Мы хотим избежать сделок между опрашиваемым и БА. Бизнес-аналитик передает полученную информацию разработчикам. Такие телефонные передачи размывают сообщение и являются кросс-функциональными, чтобы избежать афер. Для этого были созданы совмещенные команды.
Отличные БА – не посредники, а замещают матч-мейкеров и диспетчеров. Иногда произношение (явно) глупых вопросов с целью получения тем, обсуждаемых между заинтересованными сторонами, и обратное воспроизведение отрывков диалога, помогает работе, когда возникает разница мнений.
БА, как правило, имеет хорошие коммуникативные навыки и умеет находить пробелы в знаниях или несоответствия. Когда они используют эти навыки, чтобы облегчить общение между бизнес- и техническими ресурсами, то добавляют массу ценности любому проекту.
В итоге, ценность бизнес-аналитиков приносит команде проекта не изменение при переходе к гибкости, а обеспечение готовности и способности менять свои инструменты и подход, чтобы соответствовать новым условиям. В то время как роль параметров может меняться, умные, отзывчивые и покладистые БА всегда будут востребованы, чтобы делать проекты успешными. Опытные бизнес-аналитики, которые готовы адаптироваться и быть там, где требуется помощь, всегда будут желанными и ценными членами команды.
Источник: 8d9.ru
Бизнес-аналитики в Agile — зачем, почему, как
Большинство людей считают, что для разработки какой-то программы нужны только программисты, ведь именно они пишут код и воплощают мечту заказчика в реальность. Но между тем, что говорит заказчик и тем, что в итоге сделает программист, — целая пропасть. Не потому что они — плохие люди или не хотят общаться и понимать друг друга, а потому что заказчик мыслит в масштабе цели, думает, что должна делать программа, для чего он хочет ее использовать. А программист обязан думать, как программа должна работать, откуда брать данные, как назвать новую колонку в таблице данных и т. д., проще говоря, думать о деталях реализации.
Поскольку и программисты, и заказчики — люди занятые, выяснение деталей проходит в форме раундов «вопрос — ответ», при этом нигде не фиксируется, когда и почему было принято такое решение или как оно изменялось со временем. Но главный минус такой коммуникации — разработчик спрашивает «как?», а заказчик может ответить только на «зачем?», а остальное его уже мало интересует. Более того, обычно, отвечая на «как?», заказчик заводит себя в тупик, потому что не может и не обязан знать, сколько вариантов существует для выполнения его потребности и какой оптимален. Программист же всего лишь делает, что ему сказали. В итоге складывается ситуация, когда недоуменный клиент спрашивает, почему приложение не вписывается в его картину мира, а недоуменный программист отвечает, что так и просили сделать.
Даже из названия профессии аналитика видно, что в его обязанности входит не только сбор требований, но и их анализ, а именно — выбор оптимального пути выполнения поставленной цели. Т. е. аналитик должен знать, и зачем клиенту та или иная функциональность, и как она сделана у конкурентов, чтобы проанализировать возможные пути реализации, выбрать оптимальный и описать программистам в деталях.
Аналитик в Agile
Сегодня в России и странах СНГ набирают популярность гибкие методологии разработки ПО. При рассмотрении возможности перехода на них (и даже в процессе перехода или начального использования), почти неизбежно встает целый ряд вопросов. Один из них состоит в необходимости участия бизнес аналитика в процессе разработки.
Привычный всем набор функций аналитика — сбор требований и написание подробной спецификации, как должна работать система. Еще перед запуском проекта требования должны быть собраны, спецификация написана, дизайны нарисованы, и только потом программисты начинают писать код. Эта красивая история написания программы редко соответствует действительности даже в проектах по методологии waterfall, не говоря уже о Scrum.
Проектная документация имеет тенденцию очень быстро устревать— в особенности в сочетании с Agile, где изменения — норма, а не форс-мажор.
- Избегать write-only-документации, т. е. той, которую заведомо никто не прочитает.
- Писать лаконично, выделяя главное и опуская излишние детали, ибо детали меняются чаще.
- Использовать больше визуальных образов, схем, графических нотаций.
Но это вовсе не значит, что минимизировать надо все и до нуля. При полном отсутствии документации, скорее всего, возникнут следующие проблемы:
- Тяжело вводить новых людей в курс проекта.
- Велика вероятность утери общей концепции и видения (проекта в целом и его частей).
- Сложно контролировать качество: непонятно, с чем сверять (в особенности это касается полнофункционального регрессионного тестирования, которое полностью автоматизировать очень тяжело).
- Сложно сопровождать и развивать старую функциональность: все уже забыли, почему и зачем именно так сделали.
Возможные функции аналитика в Agile
Связующее звено между разработчиками и заказчиками
В отличие от классической интерпретации функций аналитика, в Agile именно обеспечение эффективной связи между заказчиками (пользователями) и командой разработчиков играет, по сути, ключевую роль.
- Если возникают проблемы формулирования или интерпретации требований, необходимо, чтобы кто-то организовал общее совещание, на котором бы оказались все вовлеченные стороны (и от разработки, и от бизнеса), при этом нужно управлять ходом дискуссии, помочь сформировать общее решение и сформулировать так, чтобы оно было понятно всем заинтересованным.
- Если пользователи страстно хотят одного, а разработчики упрямо настаивают на другом, кто-то должен помочь найти компромисс или убедить разработчиков сделать, как просят заказчики и пользователи.
- Если для решения задачи требуется прояснить ряд существенных деталей, а представители заказчика ссылаются друг на друга или противоречат друг другу, нужен кто-то, кто сможет эффективно выйти из этой ситуации.
- Если заказчики активно используют внутренний жаргон (бизнес), а разработчики — свой (технический), нужен кто-то, кто сможет переводить.
В большинстве случаев этот «кто-то» — аналитик, которому помогают менеджеры, когда требуется административный ресурс, и ключевые эксперты проекта или даже компании, когда требуется генерация или верификация нестандартных решений.
Контроль качества
Традиционно считается, что качество контролируют специальные люди, которые выполняют приемочные испытания по описанным методикам и программам. Однако кто проверит, что сделали то, что нужно с точки зрения бизнеса, и что пользоваться удобно?
Пользователи и заказчики на демонстрации — конечно, вариант, но, во-первых, не факт, что среди них окажутся заинтересованные именно в этой функциональности люди; во-вторых, так можно потерять лицо (демонстрация превратится в сессию тестирования и отладки); в-третьих, уже будет потрачено определенное количество ресурсов и времени на отладку возможно неверного бизнес решения.
Достаточно очевидно, что вместо (или совместно с) владельцем продукта эта почетная обязанность может быть возложена на аналитика
Схемы взаимодействия аналитик – команда
В Agile большое внимание уделяется командной работе, самоорганизации. Как организовать взаимодействие аналитика с командой с учетом возлагаемых на него функций? Есть разные варианты, причем в зависимости от обстоятельств, эффективными оказываются те или иные.
Владелец продукта — аналитик
Это самый простой и очевидный случай. Владелец продукта отвечает за продукт, за сбор и приоритизацию требований, является своеобразным представителем заказчика, но на стороне исполнителя, отвечает или помогает ответить на уточняющие вопросы. Всё это тесно переплетается с функциями аналитика, обсуждаемыми выше.
Т. ч. можно решить: функции аналитика исполняет владелец продукта. Или, если угодно, наоборот — аналитик исполняет роль владельца продукта.
Среди плюсов такой схемы: простота, минималистичность, относительное удобство и для заказчика, и для разработчиков — и те, и другие всегда знают, к кому именно нужно обратиться со своими вопросами.
- Слишком многое зависит от одного человека — большая нагрузка и связанные с этим риски «бутылочного горлышка».
- Экстремальная незаменимость — а если в отпуске, а если заболел.
- Вряд ли получится плотно привлечь такого владельца продукта к сопровождению системы или активному участию в пилотных внедрениях.
- Есть вероятность, что владелец продукта будет откладывать решение каких-то задач не потому что у них низкий приоритет, а потому что он пока еще не успел как следует проработать постановку. Т. е. убивается вся идея приоритизации работ на основании потребностей бизнеса, а не исходя из внутренних или технических обстоятельств.
Аналитик — помощник владельца продукта
Большинство недостатков предыдущей схемы можно преодолеть, если поделить обязанности владельца продукта и аналитика между двумя людьми — достаточно распространенная практика. Как правило, при этом «главный» решает, что в какую очередь делать, и дополнительно выполняет менеджерские функции. А помощник больше концентрируется на содержании и деталях работ, т. е. играет роль аналитика.
- Деятельность аналитика недостаточно прозрачна для команды, поскольку аналитик в нее не входит.
- Велика вероятность, что команда будет воспринимать аналитика как владельца продукта (или даже руководителя), т. е. видеть в нем не помощника и эксперта, а начальника, что почти наверняка убьет критичность восприятия предложений и моделей, предлагаемых аналитиком — их будут воспринимать не как начальное приближение и дополнительную информацию, а как инструкции к действию.
- Опять же, не так-то просто привлечь такого аналитика к сопровождению.
Аналитик внутри команды
- Аналитик сидит вместе со всеми, т. е. в одной комнате с разработчиками.
- Аналитик участвует в Scrum-митингах с остальными (рассказывает, что делал вчера и что собирается делать сегодня).
- Работа аналитика учитывается при планировании итерации.
- Аналитик может привлекаться к нехарактерным для себя работам, чтобы помочь остальной команде в непростую минуту — например, подготовить тестовые данные, прогнать часть ручных тестов.
- Одной предметной областью (или сильно похожими) занимается несколько команд разработчиков, т. ч. держать по аналитику в каждой команде нет смысла.
- В проекте так много технических и технологических тонкостей и сложностей, что команда в основном сконцентрирована на них, а аналитик в такой команде оказывается инородным телом.
- Нехватка квалифицированных аналитиков.
Так есть разница между аналитиком в Agile и не-Agile (например, в водопаде или другой тяжеловесной методологии)? Однозначный ответ — есть!
В тяжеловесных методологиях аналитик похож на слабопроницаемую стену между командой разработчиков и представителями заказчика/бизнеса. Чтобы сделать хороший продукт, приходится тратить кучу сил на «ковыряние дырок» в этой стене. Кроме того, ужасно высоки риски, связанные с ошибками аналитика. Команде разработчиков при этом отводится роль второго плана.
В Agile же аналитик играет роль связующего звена между разработчиками и заказчиками — своего рода магнит, который не дает им разбежаться по разным углам и тихо там что-то делать без ведома друг друга. При этом команде разработчиков отводится весьма значимая роль. Благодаря этому снижаются риски, связанные с ошибками аналитика: если что, команда уточнит/поправит (а если не поправит, на демонстрации заказчики поправят).
- Блог компании DataArt
- Управление проектами
- Agile
Источник: habr.com
Бизнес-аналитик в ИТ: SLDC, Agile, модели и методологии разработки ПО
Сегодня в рамках обучения начинающих аналитиков разберем типовые этапы и стандарты жизненного цикла программного обеспечения. Читайте далее про SDLC и модели разработки ПО, реализующие движение по его этапам, чем они отличаются от методологий и при чем здесь Agile, а также где место системного и бизнес-аналитиков в Software Development Life Cycle.
Что такое SDLC и где в нем место аналитику
Как следует из названия, Software Development Life Cycle (SDLC) – это жизненный цикл программного обеспечения из набора типовых этапов, переход между которыми определяется моделью процессов разработки ПО. Подробно цель, выходы, действия и задачи каждого из этих процессов описан в международном стандарте ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes».
Российским аналогом этого документа является ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», принятый Федеральным агентством по техническому регулированию и метрологии РФ в 2012 году взамен ГОСТ Р ИСО/МЭК 12207-99.
Эти стандарты подробно описывают более 40 процессов ЖЦ ПО, от организационного обеспечения проекта до повторного применения программных средств, сгруппированные в 7 категорий. Эти регламенты очень детальны и универсальны, т.е. подходят для любого прикладного кейса. Обратной стороной этих достоинств является большой объем документов. Поэтому начинающим аналитикам легче понять основные процессы ЖЦ ПО на примере этапов SDLC:
- Планирование – где владелец продукта отвечает на вопрос «Что нужно сделать?», а руководитель проекта – на вопрос «Как это сделать». Здесь также может принимать участие и бизнес-аналитик, чтобы понять потребности и перевести их в бизнес-требования.
- Анализ– определение и документирование требований в виде ТЗ на разработку ПО и/или спецификации, что является основной рабочей обязанностью бизнес-аналитика;
- Проектирование– определение дизайна и архитектуры ПО, а также другие особенности реализации, например, UI/UX-дизайн. Помимо ИТ-архитектора и дизайнеров, здесь работает системный аналитик, уточняя и дополняя требования от бизнес-аналитика. На практике обязанности системного и бизнес-аналитика может выполнять один человек.
- Разработка– непосредственная реализация всех запланированных требований, что делают программисты/разработчики ПО.
- Тестирование и развертывание– после того, как тестировщики проверят представленный разработчиками результат на соответствие требованиям и отсутствие ошибок, к делу приступают DevOps-инженеры и администраторы, которые разворачивают продукт в реальной среде эксплуатации (production).
- Поддержка и сопровождение– работающий продукт сопровождают администраторы и специалисты технической поддержки. Также здесь и на предыдущем этапе технические писатели создают руководства пользователя и администратора, а также прочую программную документацию, предусмотренную контрактом на этапе планирования.
При том, что набор перечисленных этапов SDLC отражает жизненный цикл ПО, переход между этапами не всегда выполняется строго последовательно. За особенности движения по этапам SDLC отвечают модели разработки ПО, которые мы рассмотрим далее.
Источник: babok-school.ru
