소프트웨어 아키텍처를 담당하는 민첩한 환경에서

민첩한 팀에서 누가 현재 스프린트에서 수행되는 작업뿐만 아니라 전체 시스템에 영향을 미치는 높은 수준의 아키텍처 및 디자인 결정을 담당합니까?

제품 소유자, 스크럼 마스터, 스크럼 팀 또는 다른 사람이 있습니까?

"소프트웨어 아키텍처는 전체 팀이 수행합니다.이 연습은 소프트웨어 설계자의 필요성을 제거하지 않으며, 단지 건축가가 더 넓고 경험이 풍부한 관점으로 토론에 기여한다는 것을 의미합니다. 소프트웨어의 아키텍처. "

• 출처 : http://www.executivebrief.com/blogs/software-architecture-agile-environment-sashimi-approach/

물론 건축가이지만 전통적인 종류의 건축가는 아닙니다.

나는 모든 사고를하고 나서 원숭이들이 모든 타이핑을하도록 내버려 두는 외과 의사와 같은 종류의 건축가를 의미하지는 않는다. 나는 역전하기 어려운 결정의 비용 / 이점 타협점을 이해하고 팀에게 무엇을해야하는지 조언하는 숙련 된 리드 프로그래머를 의미합니다.

효과적인 아키텍트는 찾기가 어렵지만 환상적인 위치가 될 수 있으므로 경험이 풍부하고 사려 깊은 프로그래머가있을 것입니다. 그런 사람은

• 물론 좋은 아키텍처 결정을 내리십시오.
• 다른 사람들이 편안하게 조언을 할 수 있도록 효과적으로 조언을하는 방법을 알고
• 아키텍처 결정을 팀에 천천히 위임

이 마지막 요점은 많은 사람들을 여행합니다. 선의의 애질런트가 "팀이 아키텍처를 소유하고 있습니다"와 같은 말을 할 때, 그들은 "올바른"것을 가지고 있지만, 그 적용에서 조언은 거의 의미가 없습니다. 팀이 자신의 아키텍처에 대한 책임을 져야한다고 믿었다면 우선 질문을하지 않을 것입니다. 그러므로 나는 당신이 질문을하는 것으로 가정합니다.

• 아무도 책임을지지 않으며 건축이 열악하거나
• 잘못된 사람은 책임을지고 건축이 나쁘거나
• 책임을지는 사람은 희생양이되고 피하기를 바라고 있습니다

책임을 져야 할 누군가 가 필요하다면 , 그것을 받아들이고 자하는 사람에게 맡겨주십시오. 진심으로. 그 사람은 적어도 걱정합니다. 그 사람에게 업무 수행에 필요한 자원을 제공하고 필요할 때 도와주십시오. 관심이 있다면 배우는 데 필요한 것을 배우려고 노력하기 때문에 아마도 그 사람이 얼마나 유능한 지 중요하지 않을 것입니다. 당연히 그러한 사람은 읽을 수있는 좋은 책과 도움과 조언을 요청할 수있는 동료 및 멘토 커뮤니티의 지원이 필요합니다.

잘못된 사람이 맡은 책임에 대해 걱정한다면, "올바른 사람"이 누구인지 알고, 건축가로 설치하기 위해 싸울 것입니다. The New Strategic Selling 과 같은 책 은 판매 기술을 익히는 데 도움이 될 것입니다.

희생양이 필요하다면, 다른 사람에게 조용히 조금씩 밀어내어 가장 파괴하거나 훼손하고자하는 사람의 경력에 ​​책임을 부여하십시오. 적어도 솔직 해져야합니다.

효과적인 건축가의 작업으로 돌아와서, 의사 결정 직책이 아니라 자신의 직무를 관리 직책으로 생각할 수 있습니다. 최소한 가장 일상적인 결정을 팀에 위임하지 않으면 병목 현상이 발생 하여 전체 조직의 속도가 느려집니다 . 맨 위에 건축가를 더 추가해도 더 빠르지는 않습니다. 처음부터 더 나은 아키텍처 결정을 내릴 수 있습니다. 위임 보드 기술은 설계자가 그 팀의 능력을 보여줌으로써 신뢰를 얻을로 팀에 점점 더 많은 의사 결정을 위임 시간이 지남에 따라 더 편안하게 도움이 될 것입니다.

저는 훌륭한 설계자를 내 시스템을 더 잘 설계하는 방법을 이해하도록 도와주고, 요청하면 참을성있게 조언하고, 때로는 매우 나쁜 결정을 내리지 못하게하는 사람으로 생각합니다. 그러한 건축가는 가장 진실한 의미에서 다른 사람들이 자발적으로 따르는 사람 이라는 지도자의 역할을합니다 .

나는 그것이 많은 것을 알고 있습니다.

참고 문헌

밀러, 새로운 전략적 판매 . 이 책에는 특정 판매를 완료하지 못한 이유를 이해하기위한 모델이 포함되어 있습니다. 동료가 내가 제안한 명백한 훌륭한 일을하지 않는 이유를 이해하는 데이 점이 귀중합니다.

Weinberg, 기술 리더가되었습니다 . 이 책은 효과적인 건축가의 일에서 비 건축가 부분을 수행하는 방법을 배우는 데 도움이되었습니다.

아펠로, 델리 게이션 보드 및 델리 게이션 포커 . 위임이 얼마나 어려운지, 얼마나 많이 위임하는지 과소 평가하지 마십시오. 보다 효과적이고 편안하게 배우십시오.

최고의 아키텍처 , 요구 사항 및 디자인은 자체 구성 팀에서 나옵니다.

- 애자일 선언문

따라서 팀은 적절한 방식으로 건축 결정을 내릴 수 있도록 자체 구성됩니다. 엄격하고 빠른 규칙은 없으며 합의에서 최고 임원의 "협의회"까지, 특정 구성원을 건축 당국으로 지정하고, 해당 직책을 가진 구성원이있는 경우 건축가가 선택할 수 있도록 할 수 있습니다. .

""높은 수준의 아키텍처 및 디자인 결정을 담당하는 사람은 누구입니까? "에 대한 대답은 팀의 규모와 수에 따라 달라집니다.

각 팀에 3-7 개의 팀이있는 1 ~ 2 개의 팀의 경우 자체 구성 팀이 선임 구성원의 리드와 함께 할 수 있습니다.

3 개 이상의 팀의 경우 복잡성이 증가하면 다양한 하위 팀이 다른 팀과 인터페이스 할 작업을 수행하고 있는지 확인할 수있는 아키텍처 팀이 필요합니다. 내 경험상, 약 8 개의 팀이 있거나 약 50 명이있을 때 그 지점에 도달합니다.

SAFe ( Scaled Agile Framework ) 팀의 사이트 에는 훌륭한 리소스가 있습니다.

본질적으로 조직 전체에서 민첩성을 확장하여 단일 릴리스 이상으로 포트폴리오 및 프로그램 계획을 세우는 데 도움이됩니다. 이들의 문서는 릴리스 트레인에 아키텍처 서사를 도입하는 과정에서 엔터프라이즈 및 시스템 설계자를 참여시키는 방법에 대한 제안을 보여줍니다.

명확하게 편집하여 질문을보다 직접적으로 해결하십시오.

확장 된 민첩한 환경에는 아키텍처에 대한 여러 소유권 계층이 있습니다. 민첩한 구현 팀은 필요에 따라 백 로그 구현을 계속 리팩토링하여 저급 신흥 아키텍처를 소유합니다. 높은 수준의 아키텍처 결정 (지원되는 운영 체제, 브라우저, 플랫폼, 라이브러리)은 시스템 및 엔터프라이즈 아키텍트의 책임입니다. 이러한 변경이 필요할 때 비즈니스 사례를 만들고 구현 팀의 릴리스 트레인에 이러한 아키텍처 변경을 추가 할 것을 권장합니다.

따라서 스프린트를 뛰어 넘는 높은 수준의 아키텍처 결정과 관련하여 일반적으로 팀보다 높은 수준에서 결정을 내립니다. 이 전문가들은 전통적으로 기업 내에서 이미 '건축가'역할을하고 있습니다.

다른 답변의 대부분은 프로젝트 내부에 있다는 관점에서 이것에 대해 생각하고 있다고 생각합니다.

이것이 조직의 유일한 수준의 아키텍처라면 결과는 혼란 스러울 것입니다. 나는이 혼란을 직접 목격했습니다. 슬프게도 그렇게됩니다.

TOGAF에 따르면, 엔터프라이즈 아키텍쳐 부서는 IT 환경을 만들고 교체하기 위해 비즈니스에 대한 높은 수준의 계획을 수립합니다. 엔터프라이즈 아키텍트는 아키텍처 원칙을 정의하고 최고 수준의 조직에서이를 승인하고 각 프로젝트에 대한 높은 수준의 아키텍처 및 요구 사항을 생성하는 데 도움을 줄 것입니다. 각 프로젝트는 해당 높은 수준의 아키텍처에서 아키텍처 빌딩 블록을 제공하기 위해 시작됩니다.

따라서 프로젝트 레벨에서 솔루션 아키텍트는 프로젝트 아키텍처를 작성하고 (아마도 반복적으로) 엔터프라이즈 아키텍트로부터 사인을받습니다.

이제 민첩한 프로젝트에 집중하십시오. 민첩한 프로젝트에는 요구 사항이 있습니다. 그것들은 방대한 "요구 사항 문서"의 형태가 아니라 서사시와 이야기입니다. 이 Epics는 여전히 계획이 필요합니다. 몇 개의 스프린트로 개발자 팀을 미지의 상태로 보내지 마십시오. 시스템이 수행해야하는 작업, 시스템과 상호 작용해야하는 다른 시스템 및 조직이 가지고있는 하드웨어 / 운영 체제 / 언어 제약 조건을 높은 수준에서 알고 있으며 솔루션 아키텍트에게 개방 된 아키텍처 선택을 안내하고 제한합니다. 예를 들어, .NET 및 SQL 서버에 최선을 다하고 있다면 매우를두 개의 DB, 두 개의 언어, 두 개의 웹 서버 등을 지원하는 데 드는 비용으로 인해 PHP와 MySQL을 사용하여 Magento 기반의 전자 상거래 사이트를 구현하는 강력한 사례 느낌과 이것은 다른 모든 기내 프로젝트에 영향을 줄 수 있습니다. 이런 종류의 "건축 부채"가 발생하지 않도록 엔터프라이즈 아키텍트의 감독이 필수적입니다.

조직의 조직 설계 및 제품이 포트폴리오에 있는지 여부에 따라 다릅니다. 역할 중심의 대규모 조직에서는 이러한 유형의 활동을 이끌 수석 건축가를 임명 할 수 있습니다.

일반적으로 선임 아키텍트는 제품 백 로그에 영향을주는 것이 아니라 제품 포트폴리오의 여러 제품에 영향을 줄 수 있으므로 설계 결정을 촉진하고 안내합니다.

소규모의 민첩한 회사는 시스템 전문가 인 개발자에게 의존하여 개발 팀을 건축 설계에 맞출 수 있습니다.

궁극적으로 제품에 대해 작업하는 배송 팀이 아키텍처 결정을 합의해야합니다. 경험이 풍부한 건축가와 기술 책임자는 디자인을 지시하는 것이 아니라 디자인이 어떻게 보이는지에 대한 토론을 촉진하는 데 더 집중할 것입니다.

나는 대부분의 답변이 이미 한 사람이 아닌 팀 이 이러한 결정을 내려야한다는 것을 강조한다고 생각 합니다.

그들이 만지지 않는 것은 또 다른 애자일 원칙입니다.

완료되지 않은 작업량을 최대화하는 기술인 단순성은 필수적입니다.

높은 수준의 아키텍처 및 디자인 결정에 대한 생각은 단순성을 염두에 두지 않고 많은 노력을 낭비하고 불필요한 복잡성을 추가하여 확장하기가 더 어려울 수 있습니다.

'건축물'보다 '정원'을 생각하라 — 생존하고 성장하는 디자인의 문화를 만들어라

현재 반복하는 동안 현재 요구에 맞는 아키텍처 및 디자인 결정을 내려야합니다. 결코 될 수없는 미래를 미리 보지 말고 지금 필요한 것에 집중하십시오. 아마 야니 는 잘 생각 된 아키텍처 일 것입니다.

다른 읽기 :

• https://less.works/less/technical-excellence/architecture-design.html