Комментарии 18
Спасибо за статью. У меня будет несколько вопросов не столько по личным инструментам, сколько о коллективных и немного о процессах. Ответье если будет возможность. Спасибо.
Скажите, где и каким образом вы аккумулируете полученные требония, классифицируете и связываете (dependency)
Я справшиваю вот с какой стороны — чаще всего приложение состоит из нескольких модулей/компонентов. В простом случае можно представить как минимум front-end и back-end. Бизнес требования часто запрашивают «фичу» которая сотвественно должна получить реализацию в нескольких компонентах, опять таки по-простому front-end и back-end. Далее, если задача сложная, у нее появляются подзадачи, у какой-то подзадачи может оказаться dependency на реализацию некоторого функционала в другом компоненте. Надеюсь понятно объяснил ход мысли. Что у вас используется для решения описаной проблемы?
Дополнительный вопрос — как такого рода растёкшиеся фичи специфицируете? У каждого компонента своя спека и разработчику нужно прочитать инфу в нескольких местах чтоб всецело понять что требуется? Или используете некоторое view которое аггрегирует информацию о конкретной фиче из нескольких спецификаций?
Скажите, где и каким образом вы аккумулируете полученные требония, классифицируете и связываете (dependency)
Я справшиваю вот с какой стороны — чаще всего приложение состоит из нескольких модулей/компонентов. В простом случае можно представить как минимум front-end и back-end. Бизнес требования часто запрашивают «фичу» которая сотвественно должна получить реализацию в нескольких компонентах, опять таки по-простому front-end и back-end. Далее, если задача сложная, у нее появляются подзадачи, у какой-то подзадачи может оказаться dependency на реализацию некоторого функционала в другом компоненте. Надеюсь понятно объяснил ход мысли. Что у вас используется для решения описаной проблемы?
Дополнительный вопрос — как такого рода растёкшиеся фичи специфицируете? У каждого компонента своя спека и разработчику нужно прочитать инфу в нескольких местах чтоб всецело понять что требуется? Или используете некоторое view которое аггрегирует информацию о конкретной фиче из нескольких спецификаций?
Добрый день.
Да, действительно вопрос связан скорее с процессом и в планах появление статьи на эту тему.
Попробую кратко ответить на вопрос.
Как описано в статье — все задачи по проекту ведутся в JIRA, требования в Confluence.
Основным источником, которые все агрегирует — эпическая история в JIRA. Она агрегирует подзадачи и ссылки на требования в Conflunce. Получается dependency ))
Собственно сложно назвать такие фичи растекшимися. В своей работе я стараюсь агрегировать требования в одном источнике (Confluence), снабдить зависимые требования перекрестными ссылками. А уже в JIRA сфокусировать разработчика на конкретные требования.
Надеюсь сумел ответить на вопрос. Повторюсь, вопрос обширный и требует отдельной статьи. Думаю она появится в скором времени.
Да, действительно вопрос связан скорее с процессом и в планах появление статьи на эту тему.
Попробую кратко ответить на вопрос.
Как описано в статье — все задачи по проекту ведутся в JIRA, требования в Confluence.
Основным источником, которые все агрегирует — эпическая история в JIRA. Она агрегирует подзадачи и ссылки на требования в Conflunce. Получается dependency ))
Собственно сложно назвать такие фичи растекшимися. В своей работе я стараюсь агрегировать требования в одном источнике (Confluence), снабдить зависимые требования перекрестными ссылками. А уже в JIRA сфокусировать разработчика на конкретные требования.
Надеюсь сумел ответить на вопрос. Повторюсь, вопрос обширный и требует отдельной статьи. Думаю она появится в скором времени.
Не очень понял, что именно у вас попадает в спринт — готовые требования, или же требования, которые еще требуют разработки, ревью и т.п.?
Спринты, — насколько я понимаю из картинки, — длиной в 1 месяц?
Спринты, — насколько я понимаю из картинки, — длиной в 1 месяц?
Павел, спасибо за вопрос.
Поясню.
Мы разделяем работу аналитика на уровни: бизнес уровень и системный уровень.
Изначально аналитик проводит бизнес анализ и описывает бизнес уровень, формирует требования в виде User Stories.
User Stories попадают на оценку проектной командой (не буду углубляться в процесс оценки).
Когда решение о включении определенного набор US в спринт принято, начинается этап системного анализа и проектирования. Требования детализируются и формулируются в формате ЧТЗ, Use Cases. Вот уже данные требования проходят ревью проектной командой.
Да, спринты длятся по месяцу.
Хочу заметить, что тема процесса актуальна и будет описана в отдельной статье. Здесь я постарался описать мой личный Toolset, которые помогает в работе.
Поясню.
Мы разделяем работу аналитика на уровни: бизнес уровень и системный уровень.
Изначально аналитик проводит бизнес анализ и описывает бизнес уровень, формирует требования в виде User Stories.
User Stories попадают на оценку проектной командой (не буду углубляться в процесс оценки).
Когда решение о включении определенного набор US в спринт принято, начинается этап системного анализа и проектирования. Требования детализируются и формулируются в формате ЧТЗ, Use Cases. Вот уже данные требования проходят ревью проектной командой.
Да, спринты длятся по месяцу.
Хочу заметить, что тема процесса актуальна и будет описана в отдельной статье. Здесь я постарался описать мой личный Toolset, которые помогает в работе.
Спасибо за ответ!
Получается, вы проводите оценку не по детальным требованиям, а по концептуальным? Не выстреливают ли в связи с этим риски? Как с этим боретесь?
Тема процесса очень актуальна и интересна, с нетерпением ждем. Особенно интересно было бы услышать в статье какого типа у вас контракты (преобладают) — Time & Material, Fixed Price?
Получается, вы проводите оценку не по детальным требованиям, а по концептуальным? Не выстреливают ли в связи с этим риски? Как с этим боретесь?
Тема процесса очень актуальна и интересна, с нетерпением ждем. Особенно интересно было бы услышать в статье какого типа у вас контракты (преобладают) — Time & Material, Fixed Price?
Получается, вы проводите оценку не по детальным требованиям, а по концептуальным? Не выстреливают ли в связи с этим риски? Как с этим боретесь?
Для оценки данного набор требований достаточно. Это набор атомарных (детальных и независимых) User Stories, а так же специальные требования зафиксированные в виде примечания к story + прототипы экранов от дизайнеров.
Такой подход позволяет сократить реворк на этапе системного анализа, а так же является стимулом для обсуждения и не ограничивает дизайнера.
Приведу пример:
Если я запишу требование в формате «Приложение должно...», то мы получим четко сформулированную постановку. Отклонение от неё недопустимо.
Если записать требование в формате «Я как пользователь хочу иметь возможность...», то данная формулировка подразумевает множество вариантов решения данной задачи. А уже какой это будет вариант я фиксирую на этапе системного анализа.
Тема процесса очень актуальна и интересна, с нетерпением ждем. Особенно интересно было бы услышать в статье какого типа у вас контракты (преобладают) — Time & Material, Fixed Price?
Постараюсь подготовить данный материал как можно раньше. Он требует более детальной проработки.
Спасибо за статью!
Расскажите, если не сложно, про инструментарий более высокого уровня — техники и методологии, применяемые на практике — мозговой штурм, DFD-диаграммы, анализ бизнес правил итд. И да — применяете ли UML?
Расскажите, если не сложно, про инструментарий более высокого уровня — техники и методологии, применяемые на практике — мозговой штурм, DFD-диаграммы, анализ бизнес правил итд. И да — применяете ли UML?
Не за что, надеюсь она действительно полезна.
Я отвечу на вопросы и воздержусь от детального описания процесса. Оставлю эту тему как лакомый кусок на другой раз.
Мозговой штурм используем, но по необходимости. Повторять подобное каждый спринт не эффективно с точки зрения временных затрат (личное мнение). Применяем для построения концепций по конкретной фиче.
DFD да, но опять же по необходимости. Данные диаграммы нужны, на мой взгляд, на начальном этапе для устранения неопределнностей. Если же идёт фаза развития, то они могут занимать много времени. Практика хорошая, но не панацея. Можете меня ругать за это ). Чаще обходимся UML.
Бизнес правила, само собой. Без их учёта говорить о полноте требований нельзя.
Ну собственно да, UML используем, правда как схематичное изображение описанных текстовым способом требований. Я стараюсь распространять правило среди аналитиков, что полагаться на одни лишь схемы нельзя. Возможно это двойная работа, но в действительности необходимое правило.
Я отвечу на вопросы и воздержусь от детального описания процесса. Оставлю эту тему как лакомый кусок на другой раз.
Мозговой штурм используем, но по необходимости. Повторять подобное каждый спринт не эффективно с точки зрения временных затрат (личное мнение). Применяем для построения концепций по конкретной фиче.
DFD да, но опять же по необходимости. Данные диаграммы нужны, на мой взгляд, на начальном этапе для устранения неопределнностей. Если же идёт фаза развития, то они могут занимать много времени. Практика хорошая, но не панацея. Можете меня ругать за это ). Чаще обходимся UML.
Бизнес правила, само собой. Без их учёта говорить о полноте требований нельзя.
Ну собственно да, UML используем, правда как схематичное изображение описанных текстовым способом требований. Я стараюсь распространять правило среди аналитиков, что полагаться на одни лишь схемы нельзя. Возможно это двойная работа, но в действительности необходимое правило.
Если не секрет, какие UML диаграммы вы используете и для иллюстрации каких аспектов — в большей степени для того чтобы зафиксировать онтологию домена или структуру процессов? Диаграммы рисуете в каком-либо специализированном под UML CASE-средстве или же «стандарт де факто» для многих аналитиков — Microsoft Visio?
Отдельный очень актуальный вопрос — пробовали ли использовать UML для моделирования уровня UI? Если да, насколько эффективным это вам показалось?
Отдельный очень актуальный вопрос — пробовали ли использовать UML для моделирования уровня UI? Если да, насколько эффективным это вам показалось?
Если не секрет, какие UML диаграммы вы используете и для иллюстрации каких аспектов — в большей степени для того чтобы зафиксировать онтологию домена или структуру процессов? Диаграммы рисуете в каком-либо специализированном под UML CASE-средстве или же «стандарт де факто» для многих аналитиков — Microsoft Visio?
Павел, используем в основном UseCase и Activity Diagram. Не брезгаем swimline'ми и стараемся описывать полную картину взаимодействия пользователь и приложения.
Так же применяем диаграмму классов, чаще в статистическом виде.
Нет, не Visio. Используем продукт компании Sparx — Enterprise Architect.
Отдельный очень актуальный вопрос — пробовали ли использовать UML для моделирования уровня UI? Если да, насколько эффективным это вам показалось?
Скажу честно, нет не пробовали и я лично не вижу особого смысла. Во-первых, есть специализированные средства. Во-вторых, дизайнер может сделать прототип в разы быстрее и эффективнее.
В Роботе мы стараемся разграничивать область ответственности дизайнеров и аналитиков. Конечно, от явного пересечения на этапе бизнес анализа не уйти, работаем в паре.
UML можно использовать для проектирования. Например, Activity Diagram повторяют набор шагов на карте экранов.
Спасибо за статью огромное!
У меня два вопроса:
1. Как оценить сроки работ бизнес-аналитика? То есть. как оценивать загрузку, на основе каких критериев? Я увидел, что это очевидно для Вас. Может поделитесь опытом?
2. Цитата:
>>Международный Институт Бизнес-Анализа (IIBA) определяет бизнес-анализ как
практику создания условий для осуществления организационных изменений путем определения потребностей и предложения решений, которые предполагают выгоду для акционеров. >>
ИМХО неверное определение. Анализ — это просто описание. Оно может приносить пользу стейкхолдерам, или не приносить — не имеет значения. Использовать результаты анализа можно как в пользу так и во вред. Это все равно, что от математики требовать полезности. Вы так не думаете?
У меня два вопроса:
1. Как оценить сроки работ бизнес-аналитика? То есть. как оценивать загрузку, на основе каких критериев? Я увидел, что это очевидно для Вас. Может поделитесь опытом?
2. Цитата:
>>Международный Институт Бизнес-Анализа (IIBA) определяет бизнес-анализ как
практику создания условий для осуществления организационных изменений путем определения потребностей и предложения решений, которые предполагают выгоду для акционеров. >>
ИМХО неверное определение. Анализ — это просто описание. Оно может приносить пользу стейкхолдерам, или не приносить — не имеет значения. Использовать результаты анализа можно как в пользу так и во вред. Это все равно, что от математики требовать полезности. Вы так не думаете?
1. Как оценить сроки работ бизнес-аналитика? То есть. как оценивать загрузку, на основе каких критериев? Я увидел, что это очевидно для Вас. Может поделитесь опытом?
Оценка работ для аналитика процесс весьма сложный. Скажу честно угадать точно до сих пор не удается.
Показатель точности зависит от многих факторов: знание предметной области, особенности взаимодействия с заказчиком, опыт коллег и тд.
Для начала нужно лично для себя определить, что для нас является мерилом. Я использую Use Case. Сложность конкретной задачи можно примерно оценить по количество сценариев, которые требуется написать для её покрытия.
Так же в данном случае очень помогает помодоро таймер. Во-первых, он задает ритм рабочего дня и помогает концентрироваться. Во-вторых, по количество помидоров можно определить сколько времени потребовалось на анализ той или иной задачи.
Подобные задачи можно оценивать по трудоемкости относительно друг друга.
Важно сделать оговорку, что если мы говорим о проекте «с чистого листа», то точность оценки может существенно пострадать в виду большого количества неопределенностей.
На самом деле я использую несколько техник для оценки. Думаю стоит описать это в отдельной статье. Вы навели меня на мысль )
ИМХО неверное определение. Анализ — это просто описание. Оно может приносить пользу стейкхолдерам, или не приносить — не имеет значения. Использовать результаты анализа можно как в пользу так и во вред. Это все равно, что от математики требовать полезности. Вы так не думаете?
Не могу согласиться. Автоматизация ради автоматизации — распилка проектного бюджета и сейчас уже не интересна. Бизнес процесс должен зарабатывать (предполагать выгоду для заказчика)
Задача аналитика — найти грань между удовлетворением интересов бизнеса и конечных пользователей, правильно её сформулировать (бизнес анализ) и перевести на язык разработчика (системный анализ).
Анализ — это просто описание.
В случае документирования требований да, но стоит не забывать, что это только одна из частей.
Если Вы сможете написать статью про анализ трудоемкости работ аналитика с цифрами, я думаю, многие скажут Вам спасибо. А заодно и то, как планировать работу над трудными задачами, не укладывающимися в стандартную временную сетку. Это очень полезный опыт.
Про бизнес-анализ:
В моей концепции есть целеполагание, исследование, анализ результатов исследования. Это описание научного подхода. Итак, что есть целеполагание и результаты этого процесса? что есть исследования и результаты этого процесса? и что есть анализ результатов и результаты этого процесса?
Мог бы предложить следующий способ деления: Все вместе — это проект. В рамках проекта необходимо поставить задачу. Результатом постановки задач являются перечень стейкхолдеров и их интересов.
Далее происходит бизнес-анализ. На этом этапе собираются, анализируются и документируются сведения об изучаемой системе.
Затем происходит анализ полученных результатов и формулировка предложений по изменению системы.
На мой взгляд проект не равен бизнес-анализу, потому что сам анализ лишь часть проекта.
Про бизнес-анализ:
В моей концепции есть целеполагание, исследование, анализ результатов исследования. Это описание научного подхода. Итак, что есть целеполагание и результаты этого процесса? что есть исследования и результаты этого процесса? и что есть анализ результатов и результаты этого процесса?
Мог бы предложить следующий способ деления: Все вместе — это проект. В рамках проекта необходимо поставить задачу. Результатом постановки задач являются перечень стейкхолдеров и их интересов.
Далее происходит бизнес-анализ. На этом этапе собираются, анализируются и документируются сведения об изучаемой системе.
Затем происходит анализ полученных результатов и формулировка предложений по изменению системы.
На мой взгляд проект не равен бизнес-анализу, потому что сам анализ лишь часть проекта.
Если Вы сможете написать статью про анализ трудоемкости работ аналитика с цифрами, я думаю, многие скажут Вам спасибо. А заодно и то, как планировать работу над трудными задачами, не укладывающимися в стандартную временную сетку. Это очень полезный опыт.
Да, думаю это действительно интересно и дополнительная возможность систематизировать данные знания для себя лично.
Мог бы предложить следующий способ деления: Все вместе — это проект. В рамках проекта необходимо поставить задачу. Результатом постановки задач являются перечень стейкхолдеров и их интересов.
Далее происходит бизнес-анализ. На этом этапе собираются, анализируются и документируются сведения об изучаемой системе.
Затем происходит анализ полученных результатов и формулировка предложений по изменению системы.
На мой взгляд проект не равен бизнес-анализу, потому что сам анализ лишь часть проекта.
Достаточно философский подход. Что первично? Курица или яйцо…
Переведу в более понятную для меня форму. Я предпочитаю рассматривать аналитику как независимый процесс, который само по себе целостный. Его результат — это набор проектных артефактов и конкретных решений.
Может ли кто-то другой использовать этот результат, не связанный с нашим проектом? Может и зачастую так и происходит.
Мне нравится ваша точка зрения. Она не тривиальна.
Здесь нет вопроса первичности, но смысл я похоже передал. Если результатами могут воспользоваться и враги, например, то анализ отделен от цели.
Здесь нет вопроса первичности, но смысл я похоже передал. Если результатами могут воспользоваться и враги, например, то анализ отделен от цели.
ИМХО.
Если результатом могут воспользоваться другие люди, в том числе и враги, то вы сделали свою работу правильно.
Это значит требования качественные: полные, понятные, непротиворечивые и так далее по списку.
Вот это уже похоже на определение анализа. — сбор достаточных с точки зрения поставленных целей знаний о системе, их оформление в виде специально оговоренных заранее артефактов. Прошедшие проверки на полноту, непротиворечивость и логичность. ИМХО — это ближе к определению бизнес-анализа, чем то. что нам предложено. Далее идет работа по созданию бизнес-архитектуры, когда на основе собранных данных, мы предлагаем решение. И к бизнес-анализу архитектурная деятельность уже не имеет отношения. Она просто использует готовые данные и пытается удовлетворить нужным требованиям
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Инструментарий бизнес-аналитика: личный опыт