Agile 문화권 채택

지난 10년간의 "Agile 변환"에서 배워야 할 교훈이 있다면 Agile 접근 방식을 채택하거나 구현하는 데 가장 적합한 솔루션은 없다는 것입니다. 모든 조직에는 서로 다른 제약 조건 및 요구 사항이 있습니다. 맹목적으로 처방전을 따르는 것은 성공으로 이어지지 않습니다.

Agile 이동은 소프트웨어 빌드 관행을 개선하는 방법을 지속적으로 찾는 것입니다. 그것은 완벽한 매일 스탠드 업 또는 회고에 관한 것이 아닙니다. 대신, 옳은 일이 일어나지 않는 것보다 더 자주 일어나는 문화를 만드는 것입니다. 스탠드업 및 회고와 같은 활동에는 자리가 있지만 조직의 문화는 변경되지 않습니다.

이 문서에서는 모든 조직이 Agile 사고방식과 문화를 만드는 데 필요한 기본 요소에 대해 자세히 설명합니다. 권장 사항을 맹목적으로 따라서는 안 됩니다. 각 조직은 지정된 환경에서 적합한 것을 적용해야 합니다.

일정 및 리듬

완벽한 스프린트 길이는 없습니다. 팀은 1주에서 4주까지의 스프린트 길이로 성공을 거두었습니다. 가장 중요한 것은 일관성입니다.

조직의 문화권, 제품 및 업데이트 제공에 적합한 스프린트 길이를 선택합니다. 예를 들어 Microsoft의 개발자 도구 부서(약 6,000명)는 3주 스프린트에서 작동합니다. 리더십 팀은 이 스프린트 길이를 선택하지 않았습니다. 엔지니어링 팀의 직접 피드백에서 나온 것입니다. 전체 부문은 이 3주 스프린트 일정에 따라 운영됩니다. 이후 스프린트는 조직의 심장 박동이 되었습니다. 이제 모든 팀이 같은 드럼의 비트로 행진합니다.

스프린트 길이를 선택하고 고수하는 것이 중요합니다. Agile 팀이 여러 팀인 경우 모두 동일한 스프린트 길이를 사용해야 합니다. 피드백이 변경을 유도하는 경우 수용해야 합니다. 올바른 용어가 마련되면 분명해질 것입니다.

배송 문화

Microsoft의 수석 그룹 프로그램 관리자인 Peter Provost는 "배송을 속일 수 없다"고 말했습니다. 그 말씀의 단순함과 진리는 Agile 문화의 초석입니다. Peter의 의미는 소프트웨어를 배송하면 실제로 소프트웨어를 배송하지 않는 한 이해할 수 없는 것들을 가르쳐 줍니다.

인간의 본성은 절대적으로 필요할 때까지 일을 지연하거나 피하는 것입니다. 소프트웨어 개발과 관련하여 더 이상 사실이 아닐 수 있습니다. 주기가 끝날 때까지 Teams의 버그를 처리하고, 강제 적용될 때까지 설정 또는 업그레이드에 대해 생각하지 않으며, 일반적으로 가능한 경우 지역화 및 접근성과 같은 항목을 피합니다. 이 패턴이 나타나면 팀은 나중에 지불해야 하는 기술적 부채를 쌓습니다. 배송은 모든 부채를 지불해야 합니다. 당신은 배송을 속일 수 없습니다. Agile 문화를 설정하려면 먼저 모든 스프린트가 끝날 때 제품을 배송하려고 합니다. 처음에는 쉽지 않을 것이지만, 팀이 시도하면 발생해야 할 모든 것을 신속하게 발견하지만 그렇지는 않습니다.

건강한 팀

완벽한 Agile 팀을 위한 레시피는 없습니다. 그러나 몇 가지 주요 특성을 통해 성공을 훨씬 쉽게 달성할 수 있습니다.

가능하면 팀 공동 배치

팀이 여러 지역에 분산된 사람들과 함께 성공을 찾을 수 있나요? 예, 하지만 더 어렵다. 사람들이 공동 배치되어 같은 방에 앉아 있을 때 올바른 대화가 일어나는 경향이 있습니다. 전 세계와 다른 표준 시간대에 위치한 팀과 함께 성공할 수 있습니다. 하지만 이러한 모든 장애물이 없다면 같은 팀이 이점을 누릴 수 없을까요?

적절한 시간 동안 팀을 그대로 유지

팀이 함께 소프트웨어를 빌드하는 기술을 습득할 수 있도록 합니다. 팀이 출격하면 개발한 화학이 중단됩니다. 때로는 재구성하는 것이 적절하지만, 팀이 함께 작업하는 방법을 배울 시간이 주어지면 일반적으로 생산성이 향상됩니다. 지침에 따라 적어도 12개월 동안 팀을 그대로 유지합니다.

사람이 아닌 부하 분산 작업

때로는 팀이 뒤처지고 도움이 필요합니다. 이 문제를 해결하기 위한 일반적인 전술은 한 팀에서 다른 팀으로 사람을 빌려주는 것입니다. 그러나 비생산적일 수 있습니다. 더 나은 해결책은 부하를 분산하는 대신 다른 팀에 작업을 부하 분산하는 것입니다. 한 팀에서 한 사람을 끌어당겨 다른 팀을 도와 두 팀을 방해하고, 일시적인 경우에도 이동하는 사람을 좌절시킬 수 있습니다. 이 모든 것은 팀 생산성에 영향을 미치며, 그렇지 않을 가능성이 높으며 일정에 따라 돌아갈 수 있는 능력에 부정적인 영향을 미칩니다.

부하 분산 작업을 통해 이미 설정된 팀이 개입하여 도움을 받을 수 있습니다. 그것은 우선 순위에 대한 대화가되고, 사람에 대한 대화가 아닙니다.

팀이 아키텍처 계층이 아닌 기능 영역을 소유하도록 허용

기능 영역을 소유한 수직 팀을 만들기 위해 노력합니다. 이러한 팀은 데이터베이스에서 사용자 인터페이스 변경에 이르기까지 해당 영역에 기능을 추가하는 데 필요한 모든 작업을 담당합니다. 팀은 엔드 투 엔드 환경을 제공하고 소유할 수 있습니다.

수평 팀이 아키텍처 계층을 소유하는 경우 단일 팀이 엔드 투 엔드 환경을 담당하지 않습니다. 기능을 추가하려면 여러 팀이 조정해야 하며 더 높은 수준의 종속성 관리가 필요합니다. 버그를 해결하려면 여러 팀이 버그를 수정하는 데 필요한 코드를 소유하고 있는지 여부를 조사해야 합니다. 팀이 버그가 아니라고 판단 하고 다른 팀에 할당하면 버그 가 주변에 표시됩니다.

기능 팀에는 이러한 문제가 없습니다. 소유권과 책임은 분명합니다. 일부 아키텍처 기반 팀을 위한 장소가 있을 수 있습니다. 그러나 수직적으로 초점을 맞춘 팀이 더 효과적입니다.

다음 단계

팀이 자체 Agile 변환에 착수할 때 이러한 기본 원칙을 염두에 두어야 합니다. 모든 조직에서 작동하는 단일 레시피는 없습니다. Agile 변환은 여정입니다. 변경하고 학습합니다. 시간이 지남에 따라 조직은 필요한 Agile 문화를 개발할 것입니다.

Microsoft는 세계에서 가장 큰 Agile 회사 중 하나입니다. Microsoft가 DevOps 계획을 위해 Agile 문화를 채택한 방법에 대해 자세히 알아봅니다.

Azure DevOps를 통해 팀이 Agile 문화를 채택하고 크기를 조정할 수 있는 방법에 대해 알아봅니다.