팀의 Kanban에서 품질 속성을 어떻게 추적 할 수 있습니까?

우리 팀은 Kanban 시스템을 사용하여 일상적인 진행 상황을 추적하고 기능에 대한 진행 상황 (사용자 스토리로 캡처 됨)을 이해하는 데 정말 효과적입니다. 우리는 최근까지 잘 작동했던 기능을 개발함에 따라 시스템 설계가 등장하도록 크게 허용했습니다. 지난 2 주 동안 특히 성능 및 수정 가능성 품질 속성과 관련된 아키텍처 균형에 대해 몇 가지 논의를했습니다.

우리는 기능을 구현하고 시스템을 설계 할 때 아키텍처에 대해 암묵적으로 결정을 내릴 수 있지만 알려진 품질 특성 요구 사항에 대해서는 이러한 결정을 고려하지 않습니다. 이러한 중요한 설계 결정이 어떻게 이루어지고 있는지 추적 / 캡처 / 시각적으로 묘사 할 수 있다면 팀 구성원이 시스템 아키텍처가 구현 될 때 추가적인 긴장을 만들지 않을 가능성이 더 높아집니다. 물론 더 복잡하게 만들기 위해 보드의 기능 은 독점적으로 기능 하지 않으며 때로는 건축상의 복잡성을 숨 깁니다!

팀의 칸반에서 품질 속성 (또는 다른 아키텍처 관련 결정)에 대한 진행 상황을 시각적으로 추적하려면 어떻게해야합니까?

우리는 아키텍처에 대해 내재적으로 결정을 내리고 있지만 알려진 품질 속성 요구 사항 측면에서 이러한 결정을 고려하지 않습니다.

워크 플로에서 "아키텍처 검토"단계를 만들어이를 시각화 할 수 있다고 생각합니다. 이 단계는 자체 WIP 제한이있는 Kanbad 보드 열로 표시됩니다. WIP 한도는이 리뷰에 참여해야하는 건축가 / 디자이너 수에 따라 다릅니다.

개발 팀은 사용자 스토리의 수평, 왼쪽에서 오른쪽 흐름을 담당합니다. 대부분의 경우 건축가는 건축 / 기술 검토 열에있는 경우에만 스토리를 만질 것입니다. 수평 스 swim 레인과 기둥의 교차점은 개발자와 건축가의 회의를 시각화합니다.

내가 일하는 팀 중 하나는 수석 데이터 아키텍트와 데이터베이스 스키마 검토를 수행하는 비슷한 단계를 수행합니다. 그들은 Kanban을 사용하지 않지만, 사용한다면 보드에이 열이있을 가능성이 높습니다.

알려진 품질 속성은 다음과 같이 표현 될 수 있습니다.

• 건축 검토 단계에 대한 정의.
• 비 기능적 요구 사항을 나타내는 이미 완료된 사용자 스토리에 대한 승인 테스트. 그런 다음 새로운 사용자 스토리에 대한 완료 정의에는 해당 테스트를 위반하지 않는 것이 포함됩니다.

추가 : "건축 검토"워크 플로우 단계는 공통의 비극 이라는 문제로 의심 될 수 있습니다 . 다음은 Kanban 시각화가이를 통해 가능한 솔루션을 처리하는 방법에 대한 훌륭한 블로그 게시물 입니다.

이 질문에는 실제로 두 부분이 있습니다. 한 부분은 : 아키텍처가 언제 변경되는지 어떻게 알 수 있습니까? 두 번째 부분은 : 아키텍처가 여전히 우수하다는 것을 어떻게 알 수 있습니까?

첫 번째 부분 : 아키텍처가 언제 변경되는지 어떻게 알 수 있습니까?

여기서 목표는 내재적으로 수행되는 것을 취해 그것을 명시 적으로 만드는 것입니다.

• Alexei의 제안은 하나의 옵션입니다. 아키텍처 검토를 위해 보드에 열을 만듭니다. 그런 다음 아키텍처 결정이 필요한 경우 카드를 이동하십시오.
• 또 다른 옵션은이를 처리하는 방법에 대한 명시 적 정책을 만드는 것입니다. "아키텍처를 변경해야하는 경우 다른 사람과 쌍을 이루어야합니다"는 그러한 정책 중 하나의 예입니다. 한 프로젝트에서는 특정 사람들과 쌍을 이루어 특정 특수 모듈에 대한 코드 변경을 수행해야한다는 정책이있었습니다. 누군가 코드를 변경하고 싶을 때는 짝을 불러 팀을 구성했습니다. 나머지 작업은 단독으로 수행되었습니다. 아키텍처와 비슷한 것을 할 수 있습니다.

많은 카드가 검토가 필요하거나 건축가가 팀의 일원이 아니고 핸드 오프가 필요하거나 검토가 추적하려는 시간이 걸릴 정도로 상세하게 설명 될 경우 전자와 함께 갈 것입니다. 보드. 후자는 아키텍처에 닿는 카드가 거의없고 필요할 때 쌍을 쉽게 찾을 수있는 옵션입니다.

이제 두 번째 질문으로 넘어가겠습니다. 아키텍처가 여전히 좋은지 어떻게 알 수 있습니까?

나는 시각화의 열렬한 팬입니다. 화이트 보드에 구성 요소 및 아키텍처를 설명하는 포스트잇 메모가있는 차트를 만들 수 있습니다.

코드 기반을 분석하고 다양한 구성 요소의 종속성 그래프로 이미지를 생성하는 정적 분석기도 있습니다. 일주일에 한 번 정도 인쇄물을 꺼내 벽에 붙일 수 있습니다. 최근 두 개의 출력물이 벽에있을 수 있으므로 지난 주에 변경된 내용이 있는지 확인할 수 있습니다.

이것으로 할 수있는 것은 아키텍처와 디자인이 보이도록하는 것입니다. 팀원들은 가끔 한 번 살펴보고 무언가를 변경하거나 리팩토링하거나 더 나은 방식으로 수행 할 수 있으면 의견을 제시합니다.

나는이 문제도 보았다. 암묵적인 의사 결정! 암시성이 문제인 경우 가능한 한 명시 적으로 작성하면 문제가 해결됩니까? 내가 제안하는 것은 의사 결정이되기 위해 진행되는 암묵적 사고를 '표현하기'위해 아키텍처 프로세스를 약간 조정하는 것입니다. 프로세스의 추가 단계의 목적은 모든 직원이 암시적인 아키텍처 결정을 내리는 경향이 있음을 팀 구성원이 이해하도록하는 것입니다. 이 단계는 암시 적 결정을 추적하지 못하게합니다.

각 시나리오에 대한 kanban의 일부로 "암시 적 결정 명시하기"를 유지하는 것이 도움이 될 수 있습니다.

내가 제안하려고하는 것은 번거로울 수 있습니다. 그러나 프로세스가 일련의 칸반 항목에 매핑되고 각 아치 시나리오에 대해 보드에 제공되는 경우이를 추적하는 데 도움이되지 않습니다. 또한 6 개의 파트 시나리오 템플릿에 매핑하고 결과를 수용하기 위해 칸반 보드를 즉흥적으로 만들 수 있으며 QA를 추적 할 수 있습니다.

비 크람.

애자일 팀의 아키텍처 결정이 지연 될 수있는 위험 중 하나입니다. 민첩하게 행동하는 데있어 가장 책임있는 일은 마지막 결정적인 순간 까지 아키텍처 결정을 지연시키는 것입니다 . 그러나 기회는 조기에 일어날 수 있는 마지막 책임있는 순간 입니다.

도움이되는 한 가지 사항은 주요 운전 요건을 조기에 명확하게 설명하는 것입니다. 반드시 알고 있어야하는 것들 (지금 당장 구현할 필요는 없음) 진화하는 아키텍처 (최소하고 유연하게 시도)는 이러한 요구 사항에 대한 기존 또는 향후 지원을 수용해야합니다.

그러나 더 중요한 것은 진화하는 아키텍처가 이러한 주요 구동 요구 사항을 지원하는 방식으로 가져 오는 (또는 얻을 수있는) 아티팩트를 구현해서는 안됩니다 (아티팩트가 현재 요구 사항을 해결하기위한 것이더라도). 기존의 요구 사항에 대한 솔루션을 구현할 때 실제 가치를 제공하지만 미래의 핵심 추진 요구 사항을 구현하기가 어렵거나 비용이 많이 드는 인공물을 방해 인공물 이라고합니다.

간섭 아티팩트를 구현해야하는 경우 어느 시점에서 제거 계획을 세우는 것이 좋습니다 (따라서 방해되는 주요 구동 요구 사항을 구현할 수 있습니다).

분명히 이것은 실제 프로젝트와 같은 실제적이고 실질적인 맥락이없는 난해한 것입니다. 그러나 개발 프로세스 모델과 진화하는 아키텍처는 이러한 고려 사항을 고려해야합니다.

암시 적 요구 사항은 아키텍처가 죽었으므로 모든 주요 요구 사항과 부수적 인 요구 사항을 모두 명시해야합니다. 초기에 요구 사항을 구현할 필요는 없습니다. 당신은 그것을 설명 할 수 있어야합니다.

추신. 요구 사항에 따라 시스템 수준 아키텍처 요구 사항을 의미하며 아키텍처에 대한 실질적인 변경없이 수용 할 수있는 임시 응용 프로그램 수준 요구 사항은 아닙니다. 도움이 되길 바랍니다.