Мы ещё не закончили с циклом типовых ошибок 😊 Пришла очередь для типовых проблем со скоупом (#21).
В предыдущих заметках мы затрагивали скоуп (границы, рамки, объем решения) и то, что его чаще всего представляют и поддерживают в виде функциональных возможностей (фич, features), вариантов использования (use cases, UC) и пользовательских историй (user stories, US). Давайте обсудим проблемы, которые чаще всего наблюдаются в скоупах, сформированных с помощью каждой из этих техник. Мы не будем обсуждать, а) чем каждая из проблем чревата, дабы не сильно удлинять опус — каждый сам может поразмыслить над тем, где кроются серьезные риски, а где — удобство восприятия; б) очевидные вещи, применимые к любому логическому набору требований, которые еще дядюшка Вигерс постулировал: полнота и непротиворечивость.
Фичи:
- Пропуски aka ни одна мелочь не должна остаться за кадром. Да, я упомянул, что неполнота — вещь очевидная, но тут я хотел бы акцентировать внимание именно на «мелочных деталях». Скоуп в виде фич — это распил решения на части. Если после такого распила остались опилки, которые не «приклеены» ни к одной доске, то их нет в решении. Часто, например, выделяют фичу Аутентификация, в описании или дальнейшей декомпозиции которой ни слова о выходе из системы (log out). Этот пункт актуален и для US, но не актуален для UC — UC не покрывают весь скоуп решения исходя из самой их сути, что делает их ограниченными в применимости для этой задачи.
- Неоднородность. Какие-то фичи — большие куски, другие — «мелочи», которые ценными кусками решения назвать сложно. Возьмем для примера Telegram. Работа с сообщениями и аудиозвонки — вполне зачетные фичи. Настройка аватарки — так себе, в сравнении. Почему вся работа с сообщениями — это один большой кусок, а из управления профилем как схожего по масштабу куска выделена одна только операция? Получается, что среди, условно, 20 элементов одним будет вся работа с сообщениями, а ещё 10 — это подпункты работы с профилем? Акценты тут точно верно выставлены? Пункт вполне себе применим и к US, когда одни эпики действительно эпичны, а другие порой меньше, чем отдельно взятая история. Для UC, при этом, это не особо актуально, т. к. сама техника диктует, чем должен быть каждый из UC, что и обеспечивает однородность (ниже рассмотрим это).
- Подача одним сплошным списком. Если фич немного — ок. Если их, например, 20+, то задумайтесь: не проще ли для восприятия и дальнейшего управления ими поделить решение вначале на 5 элементов, а затем каждый из них декомпозировать на ряд дочерних? Аналитик структурирует все, что можно структурировать. Если в вашем скоупе идут подряд такие фичи для Telegram, как Отправка сообщения, Редактирование сообщения, Настройка аватарки, Ночной режим и Редактирование параметров группы (или, что еще печальнее, они идут вперемешку), вселенная не шепчет, что их можно сгруппировать по функциональным областям / фичам более высокого уровня абстракции? Для US также есть понятие эпиков, которое можно еще дополнить рядом уровней: темы/стримы/любой_ваш_термин_позволяющий_выстроить_наглядную_структуру. UC, при этом, не могут быть разного уровня абстракции, но их также можно как визуально, так и в тексте сгруппировать по областям.
Варианты использования:
Проблемы с UC, как правило, вытекают из непонимания, что такое UC и каким качественно отдельно взятый UC должен быть. Сразу оговорюсь, что это все не есть заветы, высеченные на скрижалях, — опытный аналитик может осознанно нарушать пункты ниже. Но я бы не рекомендовал это делать из-за незнания или не понимая, серьезная это ошибка или оформительская мелочь.
- Когда UC — не операция. UC — это вариант использования, операция над решением. Если среди ваших UC Отправить сообщение, Создать группу и Совершить звонок затесалось что-то типа Интеграция с Google-аутентификацией, то вы смешиваете «Что полезного юзер может сделать с системой» с «Что в решении нужно реализовать».
В предыдущих заметках мы затрагивали скоуп (границы, рамки, объем решения) и то, что его чаще всего представляют и поддерживают в виде функциональных возможностей (фич, features), вариантов использования (use cases, UC) и пользовательских историй (user stories, US). Давайте обсудим проблемы, которые чаще всего наблюдаются в скоупах, сформированных с помощью каждой из этих техник. Мы не будем обсуждать, а) чем каждая из проблем чревата, дабы не сильно удлинять опус — каждый сам может поразмыслить над тем, где кроются серьезные риски, а где — удобство восприятия; б) очевидные вещи, применимые к любому логическому набору требований, которые еще дядюшка Вигерс постулировал: полнота и непротиворечивость.
Фичи:
- Пропуски aka ни одна мелочь не должна остаться за кадром. Да, я упомянул, что неполнота — вещь очевидная, но тут я хотел бы акцентировать внимание именно на «мелочных деталях». Скоуп в виде фич — это распил решения на части. Если после такого распила остались опилки, которые не «приклеены» ни к одной доске, то их нет в решении. Часто, например, выделяют фичу Аутентификация, в описании или дальнейшей декомпозиции которой ни слова о выходе из системы (log out). Этот пункт актуален и для US, но не актуален для UC — UC не покрывают весь скоуп решения исходя из самой их сути, что делает их ограниченными в применимости для этой задачи.
- Неоднородность. Какие-то фичи — большие куски, другие — «мелочи», которые ценными кусками решения назвать сложно. Возьмем для примера Telegram. Работа с сообщениями и аудиозвонки — вполне зачетные фичи. Настройка аватарки — так себе, в сравнении. Почему вся работа с сообщениями — это один большой кусок, а из управления профилем как схожего по масштабу куска выделена одна только операция? Получается, что среди, условно, 20 элементов одним будет вся работа с сообщениями, а ещё 10 — это подпункты работы с профилем? Акценты тут точно верно выставлены? Пункт вполне себе применим и к US, когда одни эпики действительно эпичны, а другие порой меньше, чем отдельно взятая история. Для UC, при этом, это не особо актуально, т. к. сама техника диктует, чем должен быть каждый из UC, что и обеспечивает однородность (ниже рассмотрим это).
- Подача одним сплошным списком. Если фич немного — ок. Если их, например, 20+, то задумайтесь: не проще ли для восприятия и дальнейшего управления ими поделить решение вначале на 5 элементов, а затем каждый из них декомпозировать на ряд дочерних? Аналитик структурирует все, что можно структурировать. Если в вашем скоупе идут подряд такие фичи для Telegram, как Отправка сообщения, Редактирование сообщения, Настройка аватарки, Ночной режим и Редактирование параметров группы (или, что еще печальнее, они идут вперемешку), вселенная не шепчет, что их можно сгруппировать по функциональным областям / фичам более высокого уровня абстракции? Для US также есть понятие эпиков, которое можно еще дополнить рядом уровней: темы/стримы/любой_ваш_термин_позволяющий_выстроить_наглядную_структуру. UC, при этом, не могут быть разного уровня абстракции, но их также можно как визуально, так и в тексте сгруппировать по областям.
Варианты использования:
Проблемы с UC, как правило, вытекают из непонимания, что такое UC и каким качественно отдельно взятый UC должен быть. Сразу оговорюсь, что это все не есть заветы, высеченные на скрижалях, — опытный аналитик может осознанно нарушать пункты ниже. Но я бы не рекомендовал это делать из-за незнания или не понимая, серьезная это ошибка или оформительская мелочь.
- Когда UC — не операция. UC — это вариант использования, операция над решением. Если среди ваших UC Отправить сообщение, Создать группу и Совершить звонок затесалось что-то типа Интеграция с Google-аутентификацией, то вы смешиваете «Что полезного юзер может сделать с системой» с «Что в решении нужно реализовать».