Як я можу відстежувати атрибути якості на Kanban моєї команди?

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

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

Як я можу відстежувати прогрес щодо атрибутів якості (чи інших архітектурно важливих рішень) на канбані моєї команди?

ми неявно приймаємо рішення щодо архітектури, але не розглядаємо ці рішення з точки зору наших відомих вимог до атрибутів якості.

Я думаю, ви можете уявити це, створивши крок "архітектурного огляду" у своєму робочому процесі. Крок буде представлений стовпчиком дошки Kanbad із власним обмеженням WIP. Ліміт WIP залежатиме від того, скільки архітекторів / дизайнерів ви повинні взяти для участі в цих оглядах.

Команда розробників відповідає за горизонтальний потік історій користувачів зліва направо. У більшості випадків архітектор торкається історій лише тоді, коли вони знаходяться в стовпці архітектурно-технічного огляду. Перетин колони з горизонтальним плавуном візуалізує зустріч забудовника та архітектора.

Одна з команд, де я працюю, має подібний крок, коли вони проводять огляд схеми бази даних з головним архітектором даних. Вони не використовують Kanban, але якби це було, вони, мабуть, мали б цю колонку на своїй дошці.

Відомі атрибути якості можуть бути представлені у вигляді:

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

ДОДАТО : На етапі робочого процесу "архітектурного огляду" може бути підозрювана проблема, що називається трагедією загального користування . Ось чудовий пост у блозі про те, як візуалізація Kanban може допомогти впоратися з цим та можливими рішеннями.

Є справді дві частини цього питання. Одна частина: Як нам знати, коли змінюється архітектура. Друга частина: Як нам знати, що архітектура все ще гарна.

Для цієї першої частини: Як дізнатися, коли архітектура змінюється?

Мета тут - взяти щось, що робиться неявно, і зробити це явним

• Пропозиція Олексія - це один варіант. Створіть стовпчик на дошці для огляду архітектури. Потім перемістіть туди карту, якщо вона потребуватиме архітектурних рішень
• Інший варіант - створити чітку політику щодо того, як це впоратися: "Якщо нам потрібно змінити архітектуру, тоді ми повинні з'єднатися з кимось іншим" - приклад однієї такої політики. В одному з проектів у нас була політика, згідно з якою зміни коду до певних спеціалізованих модулів повинні здійснюватися шляхом з'єднання з певними людьми. Коли хтось захотів змінити код там, він закликав би пару і об'єднатися. Решту роботи виконали сольно. З архітектурою можна зробити щось подібне.

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

Тепер переходимо до другого питання: як ми можемо знати, що архітектура все ще гарна?

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

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

Це дозволяє вам зробити так, щоб ваша архітектура та дизайн були видимими. Члени команди оглядатимуть це раз у раз та коментуватимуть, чи можна щось змінити чи відреставрувати чи зробити краще.

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

Збереження "експлікації невідкладних рішень" як частини канбана для кожного із сценаріїв може допомогти.

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

Вікрам.

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

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

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

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

Очевидно, це все езотеричне без реального, відчутного контексту (як реальний проект). Але більш-менш ваша модель процесу розвитку та ваша архітектура, що розвивається, повинні враховувати ці міркування.

Неявні вимоги є мертвими для архітектур. Все повинно бути чітко визначено як ключовими вимогами до руху, так і тими, що є допоміжними. Вам не потрібно застосовувати вимогу на початку. Потрібно лише вміти рахувати це.

PS. Під вимогою я маю на увазі архітектурні вимоги на системному рівні, а не обов'язково вимоги рівня ефемерного рівня, які можна задовольнити без істотних змін у архітектурі. Сподіваюся, це допомагає.