Jak mogę śledzić atrybuty jakości w kanban mojego zespołu?

Mój zespół korzysta z systemu Kanban do śledzenia codziennych postępów i działa bardzo dobrze, jeśli chodzi o zrozumienie postępu w zakresie funkcji (zarejestrowanych jako historie użytkowników). W dużej mierze pozwoliliśmy na pojawienie się naszego projektu systemu, gdy rozwijamy funkcje, które działały dobrze do niedawna. W ciągu ostatnich dwóch tygodni odbyliśmy kilka dyskusji na temat kompromisów architektonicznych związanych w szczególności z parametrami wydajności i jakości modyfikacji.

Myślę, że to, co się dzieje, kiedy wdrażamy funkcje i projektujemy system, domyślnie podejmujemy decyzje dotyczące architektury, ale nie rozważamy tych decyzji pod kątem naszych znanych wymagań dotyczących atrybutów jakości. Byłoby naprawdę wspaniale, gdybym mógł śledzić / uchwycić / wizualnie zobrazować, jak podejmowane są te ważne decyzje projektowe, aby członkowie zespołu mieli większą szansę, aby nie tworzyć dodatkowego napięcia w architekturze systemu podczas jego wdrażania. I oczywiście, aby bardziej skomplikować rzeczy, funkcje na naszej płycie nie są wyłącznie funkcjonalne i czasami ukrywają złożoność architektoniczną!

Jak mogę wizualnie śledzić postęp w zakresie atrybutów jakości (lub innych istotnych decyzji architektonicznych) na kanban mojego zespołu?

domyślnie podejmujemy decyzje dotyczące architektury, ale nie rozważamy tych decyzji pod kątem naszych znanych wymagań dotyczących atrybutów jakości.

Myślę, że możesz to sobie wyobrazić, tworząc krok „przeglądu architektury” w swoim przepływie pracy. Krok byłby reprezentowany przez kolumnę tablicy Kanbad z własnym limitem WIP. Limit WIP będzie zależał od liczby architektów / projektantów, którzy muszą wziąć udział w tych recenzjach.

Zespół programistów odpowiada za poziomy przepływ historii użytkowników od lewej do prawej. Architekci w większości przypadków dotykają opowieści tylko wtedy, gdy znajdują się w kolumnie przeglądu architektoniczno-technicznego. Przecięcie kolumny z poziomą linią pływania wizualizuje spotkanie programistów i architektów.

Jeden z zespołów, w których pracuję, ma podobny krok, w którym dokonuje przeglądu schematu bazy danych z głównym architektem danych. Nie używają Kanbana, ale gdyby tak zrobili, bardzo prawdopodobne byłoby, że mieliby tę kolumnę na swojej planszy.

Znane atrybuty jakości można następnie przedstawić jako:

• definicja wykonana dla etapu przeglądu architektonicznego.
• testy akceptacyjne wokół już wykonanych historii użytkowników reprezentujących wymagania niefunkcjonalne. Wtedy definicja „gotowa” dla nowej historii użytkownika obejmowałaby nieprzełamanie tych testów.

DODANO : Etap przepływu pracy „przeglądu architektury” może być podejrzany o problem zwany tragedią dóbr wspólnych . Oto świetny post na blogu o tym, jak wizualizacja Kanban może pomóc sobie z tym poradzić i możliwymi rozwiązaniami.

To pytanie składa się z dwóch części. Jedna część to: Skąd wiemy, kiedy zmienia się architektura. Druga część to: skąd wiemy, że architektura jest nadal dobra.

Pierwsza część: Skąd wiesz, kiedy zmienia się architektura?

Celem jest wzięcie czegoś, co jest robione w sposób dorozumiany i wyraźne

• Sugestia Aleksieja jest jedną z opcji. Utwórz na tablicy kolumnę do przeglądu architektury. Następnie przenieś tam kartę, jeśli będzie wymagała decyzji architektonicznych
• Inną opcją jest utworzenie wyraźnej polityki dotyczącej tego, jak sobie z tym poradzić: „Jeśli potrzebujemy zmienić architekturę, musimy sparować z kimś innym” jest przykładem takiej polityki. W jednym projekcie mieliśmy politykę, zgodnie z którą zmiany kodu w niektórych wyspecjalizowanych modułach musiały być wykonywane przez parowanie z określonymi osobami. Gdy ktoś chciał tam zmienić kod, dzwonił po parę i łączył siły. Reszta pracy została wykonana solo. Możesz zrobić coś podobnego z architekturą.

Prawdopodobnie wybierzesz tę pierwszą, jeśli wiele kart wymaga przeglądu, lub jeśli architekt nie jest częścią zespołu i wymagane jest przekazanie lub ocena będzie na tyle szczegółowa, że ​​zajmie trochę czasu, który chcesz śledzić tablica. Ta ostatnia jest opcją, jeśli tylko kilka kart dotyka architektury, i łatwo jest znaleźć parę na żądanie.

Teraz dochodzę do drugiego pytania: skąd wiemy, że architektura jest nadal dobra?

Jestem wielkim fanem wizualizacji. Możesz mieć na tablicy wykres z notatkami opisującymi komponenty i architekturę.

Istnieją również analizatory statyczne, które analizują bazę kodu i generują obraz z wykresem zależności różnych komponentów. Możesz go uruchomić, wziąć wydruk i przykleić go na ścianie raz w tygodniu. Być może dwa ostatnie wydruki mogłyby być na ścianie, więc możesz sprawdzić, czy coś się zmieniło w ostatnim tygodniu.

Pozwalają ci to uczynić architekturę i projekt widocznym. Członkowie zespołu będą od czasu do czasu zerkali na to i komentowali, czy coś można zmienić, zreorganizować lub zrobić w lepszy sposób.

Też widziałem ten problem. Implikowane podejmowanie decyzji! Jeśli niejawność jest problemem, czy uczynienie go tak wyraźnym, jak to możliwe, rozwiąże problem? Sugeruję nieco ulepszyć proces architektury, aby „zacząć odkrywać” ukryte myśli, które stają się decyzjami. Dodatkowym krokiem w tym procesie jest uświadomienie członkom zespołu, że każdy ma skłonność do podejmowania dorozumianych decyzji architektonicznych. Ten krok po prostu sprawi, że dorozumiane podejmowanie decyzji będzie niemożliwe.

Pomocne może być zachowanie „Wyjaśniania niejawnych decyzji” jako części kanban dla każdego ze scenariuszy.

To, co zamierzam zasugerować, może być kłopotliwe. Ale jeśli proces zostanie odwzorowany na zestaw elementów Kanban i jeśli zostanie on wprowadzony na planszę dla każdego scenariusza łukowego, czy to nie pomoże ci go śledzić. Sugeruję, abyś mógł również zmapować je do szablonu scenariusza sześcioczęściowego i zaimprowizować tablicę Kanban, aby uwzględnić wyniki, a QA można śledzić.

Vikram.

Jest to jedno z ryzyk związanych z opóźnieniem decyzji architektonicznych zespołów Agile. Oczywiście najbardziej odpowiedzialną rzeczą za zwinność jest opóźnianie decyzji architektonicznych do ostatniej odpowiedzialnej chwili . Ale szanse są ostatnią odpowiedzialną chwilą, która może (lub musi) nastąpić wcześnie.

Jedną z rzeczy, która pomaga, jest jasne określenie wczesnych wymagań dotyczących prowadzenia pojazdu; rzeczy, które wyraźnie wiesz, że musisz mieć (ale niekoniecznie musisz je teraz wdrożyć). Twoja rozwijająca się architektura (która stara się być minimalistyczna i elastyczna) powinna uwzględniać istniejące lub przyszłe wsparcie dla takich wymagań.

Co ważniejsze jednak, twoja rozwijająca się architektura NIE MOŻE implementować artefaktów, które mogą (lub mogą) uzyskać takie wsparcie, aby sprostać tak kluczowym wymaganiom kierowania pojazdem, nawet jeśli artefakty te są przeznaczone do rozwiązywania bieżących wymagań. Możemy odnosić się do takich artefaktów, jak artefakty zakłócające, artefakty , które dostarczają prawdziwą wartość (ponieważ wdrażają rozwiązanie istniejących wymagań), ale których obecność utrudnia / kosztuje wdrożenie przyszłego kluczowego wymogu kierowania pojazdem.

W przypadkach, w których musisz wdrożyć artefakt zakłócający, Twoim zadaniem byłoby zaplanowanie jego usunięcia w pewnym momencie (abyś mógł wdrożyć kluczowy wymóg, który jest przeszkadzany).

Oczywiście wszystko to jest ezoteryczne bez rzeczywistego, namacalnego kontekstu (jak prawdziwy projekt). Ale mniej więcej twój model procesu rozwoju i twoja ewoluująca architektura muszą brać pod uwagę te względy.

Domniemane wymagania są wymarłe dla architektów. Wszystko musi być wyraźnie określone, zarówno kluczowe wymagania, jak i dodatkowe. Nie musisz wcześnie wdrażać wymagań. Musisz tylko móc to uwzględnić.

PS. Przez wymaganie rozumiem wymagania architektoniczne na poziomie systemu, a niekoniecznie efemeryczne wymagania na poziomie aplikacji, które można spełnić bez istotnych zmian w architekturze. Mam nadzieję, że to pomoże.