다수의 민첩한 스크럼 팀이있는 조직에는 "엔터프라이즈 건축가"로 지정된 소수의 사람들이 있습니다. EA 그룹은 품질 및 의사 결정 준수를위한 제어 및 게이트 키퍼 역할을합니다. 이로 인해 팀 결정과 EA 결정이 겹칩니다.
예를 들어, 팀은 라이브러리 X를 사용하거나 SOAP 대신 REST를 사용하려고하지만 EA는이를 승인하지 않습니다.
이제는 팀 결정이 무효화 될 때 좌절을 초래할 수 있습니다. 충분히 이해한다면, EA 사람들이 모든 힘을 "잡아"서 팀이 결국 동기 부여가되고 민첩하지 않은 상황에이를 수 있습니다.
스크럼 가이드는 그것에 대해 말을이있다 :
자체 구성 : Scrum Master조차도 개발 팀에 제품 백 로그를 출시 가능한 기능의 증분으로 바꾸는 방법을 알려주지 않습니다.
합리적입니까? EA 팀이 해산되어야합니까? 팀이 거부하거나 단순히 준수해야합니까?
답변:
개발 팀은 실제 업무를 수행하는 기능 간 기술을 갖춘 3 ~ 9 명으로 구성됩니다.
Scrum Master는 "Enterprise Architect"를 프로젝트 팀의 일원으로 초대해야합니다. 그러면 건축가와 프로그래머 간의 의사 소통이 우수 할 것입니다.
사용되는 기술 선택은 소프트웨어 요구 사항의 일부이므로 어떤 이유로 든 특정 기술을 사용하지 않아야하는 기능 요청의 일부입니다.
시스템과 코드베이스는 스스로 말할 수 없기 때문에 아키텍트는 시스템과 코드베이스를 말합니다. 건축가를 갖는 것은 일반적으로 회사의 장기적인 최선의 이익입니다. 특히 사내 구축 소프트웨어에 의존하는 회사입니다.
건축가는 개발자에게 백 로그를 증분 (스프린트)으로 바꾸는 방법을 알려주지 않고 어떤 기술을 사용할 수 있고 사용할 수 없는지를 말합니다. 두 가지 다른 문제를 혼란시키고 있습니다.
해결책은 아무것도 바꾸지 않는 것입니다. 아키텍트가 너무 제한적이거나 너무 압도적이므로 팀이 좌절감을 느끼는 경우 이는 SCRUM과 무관 한 직원 문제이며 직원 만족도 문제와 가능한 경우 비즈니스 이해 관계자와 함께 해결해야합니다. ( " 아키텍트가 Turbo Pascal을 사용할 수 없기 때문에 x%기능을 개발하는 데 시간이 더 걸립니다 ."yz
이런 종류의 일은 프로젝트를 완수하기 위해 큰 팀을 필요로하는 것과 민첩한 팀을 작게 유지해야하는 것 사이의 균형을 유지하는 데 필요합니다.
일반적으로 '팀장 스크럼'은 각 소규모 팀에서 선출 된 한 명의 구성원으로 구성됩니다. 그것은 자기 조직적 특성의 일부를 제공 할뿐만 아니라, 높은 수준의 그룹이 내린 결정이 민첩한 그룹에 의해 받아 들여질 수 있도록 어떤 표현 방식을 제공합니다.
특정 시나리오의 경우, 뭔가 아마 반란 또는 단순 승인을 민첩 팀 차라리 배우지 않는게을 중지 할,하지만해야합니다. 팀은 이상적인 소프트웨어가 아니라 좋은 소프트웨어를 만들어야한다는 사실을 알아야합니다. 서로 다른 기술을 사용하여 동일한 프로젝트에서 유사한 작업을 수행하는 여러 팀이 있으면 소프트웨어 품질이 떨어질 수 있습니다. 동일한 프로젝트에서 여러 팀이 서로 다른 코딩 표준을 사용하게하면 소프트웨어 성능이 저하 될 수 있습니다.
따라서 프로젝트가 어떻게 진행 될지에 대한 합의에 도달 할 수 있는 방법 이 필요 합니다. 팀장 스크럼은 다른 장소에서 효과적으로 사용됩니다. 다르게 행동해야하거나 그룹이 효과적으로 수행하지 않는 이유를 조사해야합니다.
질문 :이 아키텍트 팀이 존재하는 이유는 무엇입니까? 내가 생각할 수있는 유일한 이유는 여러 팀간에 상호 운용성을 강화하기 위해서입니다. 또는 팀이 단일 제품의 다양한 부분을 작업하고 있으며이 아키텍트 팀은 모든 부분이 함께 작동하도록 존재합니다.
나는이 계획이 민첩한 환경에서 잘 작동한다고 생각하지 않습니다. 다양한 팀이 독립적이어야하며 입력 및 출력도 같아야합니다. 따라서 출력을 제한하는 것은 입력 요구 사항의 일부일뿐입니다. 그러나 이러한 제약은 합리적이어야합니다. "라이브러리 X를 사용하지 않아야 함"과 같은 것은 좋은 요구 사항은 아니지만 "사용 된 타사 라이브러리 수를 최소로 제한해야합니다"또는 "다른 팀에서 사용하지 않는 새 라이브러리 추가는 제한되어야합니다."라고 말하는 것이 좋습니다. 괜찮을거야.
그런 다음 건축가 팀을 모든 팀에서 해체하고 건축 문제에 전문 지식을 사용합니다. 팀의 일원이됨에 따라 팀의 문제를보다 잘 파악할 수 있으며 아키텍처의 핵심 부분을 변경하는 것에 대한 더 나은 아이디어 나보다 교육적인 의견을 가질 수 있습니다. 또한 팀 전체의 아키텍처가 일관성을 유지하도록 의사 소통을하는 팀 전체의 건축가에게 권장해야합니다.
Scaled Agile Framework 의 그룹 은이 사실을 잘 알고 있습니다. 우리 대부분은 팀 수준에서 거래하지만, 규모를 확대 할 때 프로그램 및 포트폴리오 수준에서도 역할이 있다는 것을 인식해야합니다. 조직 전체에서 아키텍처 결정을 내려야하며 이는 조직의 하위 수준에서 발생하는 상황에 영향을 미칩니다. 건축 결정을 내리는 데 아무런 문제가 없습니다!
이와 관련하여, 민첩한 소프트웨어 요구 사항 에 관한 Dean Leffingwell의 최근 책 은이 주제에 대해 잘 읽었으며 직접 읽었습니다.
또한 여러 개의 민첩한 팀 (일부는 Kanban, 일부는 Scrum)과 건축가가 있습니다. 설계자는 모든 제품 (헬퍼 라이브러리, 인증, 빌드 인프라)에 걸친 인프라를 담당합니다. 이들은 기술적 인 결정을 내리지 만 대부분 인프라 구성 요소를 구현합니다.
이것은 잘 작동하며 일반적으로 충돌이 없습니다. 한 가지 중요한 점은 다음과 같습니다.
건축가는 팀에 대한 공식적인 권한이 없으며 단지 그들을 지배 할 수 없습니다. 일반적으로 건축가는 모든 제품에 적용되는 결정을 내리고 팀은 제품에 대한 결정을 내립니다. 충돌이있는 경우, 설계자 및 팀은 합의에 도달하거나 경영진에게 이관하기 만하면됩니다 (드물게는 발생하지는 않음).
건축가와 개발자를 동료로 만드는 것이 정말 중요하다고 생각합니다. 둘 다 서로 다른 영역에서 공통의 목표를 향해 노력합니다. 아무도 다른 사람을 "지배"할 수 없다면 협력이 더 나을 것입니다.
나는 여기에 어떤 갈등도 보이지 않는다. 내가 이해 한 바에 따르면, 모든 EA (제 생각에 칭찬할만한 제목)는 QA입니다. 모든 사람들은 그것을 알고 있어야합니다.
당신은에 있음을 고려해야 어떤 요구 사항 수집은 반복이나 선행을인지, 중요한 단계 개발 방법론 (즉, 하나를 고려하고받을 가치).
이러한 요구 사항 중 일부는 회사 정책에 의해 설정됩니다. 그리고 이것들은 기본 규칙을 설정합니다.
그러나 어느 쪽이든 요구 사항이 충족되는지 여부입니다. 그 결정을 내리기가 어렵다면, 요구 사항이 부족하고 (더 넓은 의미에서) 진정으로 테스트 할 수 있도록 요구를 반복해야합니다. 이를 요구 사항 반복으로 처리해야합니다.
귀하의 아키텍트는 민첩한 팀의 결정을 무시해서는 안됩니다. 아키텍트는 팀에 전달 된 요구 사항 / 스토리에이를 포함시켜야합니다. 프로젝트 환경 변화와 새로운 상호 운용성 요구 사항이 도입 될 때 팀을 지속적으로 업데이트해야합니다.
명령을 내리고 기술적 결정을 내리는 건축가는 문화적 결함입니다. 그들은 단순히 공유 된 목표 / 비전을 유지하고 동일한 페이지에 별도의 팀을 유지하는 것이 아니라 "보스"로 간주합니다. 민첩한 방법론은 의사 소통 및 연락을 기반으로합니다. 의사 결정이 내려 질 때까지 건축가가 참여하지 않으면 민첩하게 실패합니다.
마틴, 자기 조직화 팀이 환경에서 어떻게 기능하는지에 대해 오해하고 있다고 생각합니다.
당신은 Scrum Guide를 인용했다 : "아무도 (Scrum 마스터조차도) 개발 백 팀에 제품 백 로그를 잠재적으로 출시 가능한 기능의 증분으로 바꾸는 방법을 알려주지 않는다."
이것은 스크럼 팀이 회사 전체의 기술 및 비즈니스 요구 사항과 다른 팀의 요구 사항에 관계없이 원하는대로 (제공하는 한) 수행 할 수있는 라이센스가 아닙니다.
물론 이해 관계자들은 그들의 영향력을 남용 할 수 있습니다. 이는 협업의 과제 중 하나이며 EA에만 국한되지는 않습니다. 그러나 협업은 팀의 경계에서 끝나지 않습니다.
Waterfall 또는 Scrum (이것은 작동하지 않을 두 가지를 혼합하는 것처럼 보입니다)은 처음에는 나에게 무의미한 관리 계층처럼 들립니다. 기술 결정을 담당하는 게이트 키퍼는 리드 개발자, 개발자의 선호도가 앱을 수많은 기술 선택으로 전환하지 못하도록하는 개발 관리자, 개발 관리자 전체가되어야하며 예산이 적지 않은 사람이라면 누구나 잠재적 인 비용을 부담해야합니다.
실제로 의사 결정의 결과를 겪어야하는 실제 사람들과 협의하지 않고 기술 결정을 내리는 데 쓸데없는 비 개발자처럼 나를 어리석은 것은 없습니다.