Как я могу отслеживать качественные атрибуты в канбан моей команды?

Моя команда использует систему Kanban для отслеживания повседневного прогресса, и она отлично проработана для понимания прогресса в функциях (записанных в виде пользовательских историй). Мы в значительной степени позволили нашему дизайну системы появиться, поскольку мы развиваем особенности, которые работали хорошо до недавнего времени. За последние две недели у нас было несколько дискуссий об архитектурных компромиссах, особенно связанных с характеристиками производительности и качества модифицируемости.

Я думаю, что происходит, когда мы реализуем функции и проектируем систему, мы неявно принимаем решения об архитектуре, но не рассматриваем эти решения с точки зрения наших известных требований к качеству. Было бы здорово, если бы я мог отслеживать / фиксировать / визуально представить, как принимаются эти важные решения по проектированию, чтобы у членов команды был больше шансов не создавать дополнительную напряженность в архитектуре системы во время ее реализации. И, конечно, чтобы усложнить ситуацию, функции на нашей плате не являются исключительно функциональными и иногда скрывают архитектурную сложность!

Как я могу визуально отслеживать прогресс в качественных атрибутах (или других архитектурно значимых решениях) в канбан моей команды?

мы неявно принимаем решения об архитектуре, но не рассматриваем эти решения с точки зрения наших известных требований к качеству.

Я думаю, что вы можете визуализировать это, создав шаг «архитектурного обзора» в вашем рабочем процессе. Этот шаг будет представлен колонкой канбадской доски с собственным пределом WIP. Предел WIP будет зависеть от того, сколько архитекторов / дизайнеров вы должны принять участие в этих обзорах.

Команда разработчиков отвечает за горизонтальный поток пользовательских историй слева направо. Архитектор (ы), в большинстве случаев, трогают истории только тогда, когда они находятся в колонке архитектурного / технического обзора. Пересечение колонны с горизонтальной дорожкой позволяет увидеть встречу разработчика (-ей) и архитектора (-ов).

У одной из команд, в которой я работаю, аналогичный шаг, когда они проводят обзор схемы базы данных с главным архитектором данных. Они не используют Канбан, но если бы они это сделали, у них, скорее всего, была бы эта колонка на их доске.

Известные качественные атрибуты могут тогда быть представлены как:

• определение сделано для этапа архитектурного обзора.
• приемочные испытания вокруг уже готовых пользовательских историй, представляющих нефункциональные требования. Тогда определение готовой новой пользовательской истории будет включать в себя не нарушение этих тестов.

ДОБАВЛЕНО : шаг рабочего процесса «архитектурный анализ» может вызывать проблему, называемую трагедией общего достояния . Вот отличный пост в блоге о том, как визуализация Kanban может помочь справиться с этим и возможные решения.

В этом вопросе действительно две части. Одна часть: как мы узнаем, когда архитектура изменится. Вторая часть: откуда мы знаем, что архитектура все еще хороша.

Для этой первой части: Как вы узнаете, когда архитектура будет изменена?

Цель здесь - взять что-то, что делается неявно, и сделать это явным

• Предложение Алексея - один из вариантов. Создайте колонку на доске для обзора архитектуры. Затем переместите туда карту, если это потребует архитектурных решений
• Другим вариантом является создание явной политики о том, как справиться с этим: «Если нам нужно изменить архитектуру, то мы должны соединиться с кем-то другим», это пример одной такой политики. В одном проекте у нас была политика, согласно которой изменения кода для определенных специализированных модулей должны выполняться путем объединения с конкретными людьми. Когда кто-то хотел изменить там код, он вызывал пару и объединялся. Остальная часть работы была сделана в одиночку. Вы можете сделать что-то подобное с архитектурой.

Вы, вероятно, согласитесь с первым, если многие карты требуют проверки, или если архитектор не является частью команды и требуется передача обслуживания, или обзор будет достаточно подробным, чтобы занять некоторое время, которое вы хотите отслеживать доска. Последний вариант, если только несколько карт касаются архитектуры, и найти пару по запросу легко.

Теперь перейдем ко второму вопросу: откуда мы знаем, что архитектура все еще хороша?

Я большой поклонник визуализации. Вы можете иметь диаграмму на доске с примечаниями, описывающими компоненты и архитектуру.

Существуют также статические анализаторы, которые будут анализировать кодовую базу и генерировать изображение с графиком зависимостей различных компонентов. Вы можете запустить его, взять отпечаток и повесить его на стену раз в неделю или около того. Возможно, две последние распечатки могут быть на стене, так что вы можете увидеть, изменилось ли что-нибудь за последнюю неделю.

Это позволяет сделать вашу архитектуру и дизайн видимыми. Члены команды будут время от времени смотреть на это и комментировать, если что-то может быть изменено или подвергнуто рефакторингу или сделано лучше.

Я тоже видел эту проблему. Неявное принятие решений! Если проблема заключается в неявности, то решит ли это как можно более явную проблему? Я предлагаю немного подправить процесс архитектуры, чтобы «начать эксплицировать» неявные мысли, которые постепенно превращаются в решения. Цель дополнительного шага в этом процессе состоит в том, чтобы заставить членов команды понять, что каждый склонен к принятию неявных архитектурных решений. Этот шаг просто не даст принять неявное решение.

Может помочь «Выяснение неявных решений» как часть канбана для каждого из сценариев.

То, что я собираюсь предложить, может быть громоздким. Но если процесс сопоставлен с набором элементов канбана и если он присутствует на доске для каждого сценария арки, он не поможет вам отследить его. Я полагаю, что вы также можете сопоставить их с шаблоном сценария из шести частей и импровизировать канбан-доску, чтобы учесть полученные результаты, можно отслеживать QAs.

Викрам.

Это один из рисков задержки архитектурных решений в Agile командах. Очевидно, что самая ответственная вещь за гибкость - откладывать архитектурные решения до последнего ответственного момента . Но шансы, что последний ответственный момент может (или должен) произойти рано.

Одна вещь, которая помогает, состоит в том, чтобы четко определить ваши основные требования к вождению; вещи, которые вы точно знаете, что должны иметь (но не обязательно должны реализовывать прямо сейчас). Ваша развивающаяся архитектура (которая стремится быть минималистичной и гибкой) должна учитывать существующую или будущую поддержку таких требований.

Более важно, однако, что ваша развивающаяся архитектура НЕ ДОЛЖНА реализовывать артефакты, которые получают (или могут получить) способ поддержки таких ключевых требований к вождению, даже если эти артефакты предназначены для разрешения текущих требований. Мы можем ссылаться на такие артефакты как мешающие артефакты , артефакты, которые приносят реальную ценность (поскольку они реализуют решение существующих требований), но чье присутствие затрудняет / удорожает реализацию будущего ключевого движущего требования.

В тех случаях, когда вы должны внедрить мешающий артефакт, ваша задача будет заключаться в том, чтобы спланировать его удаление в какой-то момент (чтобы вы могли реализовать требование к вождению ключа, которому мешают).

Очевидно, что все это эзотерично без реального, осязаемого контекста (например, реального проекта). Но более или менее ваша модель процесса разработки и ваша развивающаяся архитектура должны принимать во внимание эти соображения.

Неявные требования - это мертвая архитектура. Все должно быть четко указано, как ключевые требования к движению, так и те, которые являются вспомогательными. Вам не нужно выполнять требование на ранней стадии. Вам нужно только быть в состоянии объяснить это.

PS. Под требованием я подразумеваю архитектурные требования системного уровня и не обязательно эфемерные требования прикладного уровня, которые могут быть приняты без существенных изменений в архитектуре. Надеюсь, это поможет.