이 기사는 원래 Medium에 게시되었습니다. 여기에서 Karim의 Medium 페이지를 방문하세요..
Qumulo에서는 확장성이 뛰어난 분산 파일 시스템을 구축합니다. 그 시스템은 주로 C로 작성 소프트웨어 개발 팀이 작성한 수백만 줄의 코드로 구성됩니다. 이것은 매우 복잡하고 미션 크리티컬한 시스템입니다. 네트워킹 인프라와 유사한 엔터프라이즈 스토리지 시스템은 항상 사용 가능해야 하며 오작동할 수 없습니다. 우리 고객은 일반적으로 매우 높은 가용성과 성능 요구 사항을 가진 회사입니다.
우리는 몇 가지 원칙을 준수하여 이 시스템을 구축하기로 결정했습니다. 우리는 XNUMX주마다 소프트웨어를 출시합니다. 우리는 애자일 소프트웨어 개발 방법론을 따릅니다. 우리는 TDD, 단위 테스트 및 품질에 대해 열광적입니다. 우리는 자기 주도적이고 자율적인 팀에서 일합니다.
혼돈의 질서에 관심이 있으십니까? Qumulo의 공석을 살펴보십시오.
조금 더 자세히 설명하는 데 시간을 할애하고 싶은 마지막 요점입니다.
팀원들이 스스로 애자일 팀으로 조직화 4~6명 규모. 각 팀에는 Agile Coach와 함께 PO(제품 소유자)가 할당됩니다. 이 팀 내에는 지정된 리더가 없습니다. 개발 관리자가 없습니다. 기술 리더가 없습니다. 혼돈을 위한 조리법처럼 들리지만 실제로는 그렇지 않습니다.
팀 생성
새로운 비즈니스 요구 사항(새 기능 구축) 또는 보다 일반적으로 엔지니어링 팀 규모의 증가에 따라 새 팀이 생성됩니다. 새로운 소프트웨어 개발 팀이 구성될 때마다 헌장이나 사명을 중심으로 활기를 띠게 됩니다. 그 임무는 팀이 구축해야 하는 기능에 의해 주도됩니다. 기능 우선 순위 지정, 범위 지정 및 전달 목표는 주로 PM 팀에서 설정합니다.
팀이 임무를 선택하는 것이지 그 반대가 아니라 선택한다는 점에 유의하는 것이 중요합니다. 우리는 선택의지, 자율성 및 목적을 장려하기 위해 이를 수행합니다. 어떤 연구가 몇 번이고, 의욕이 넘치고 참여도가 높은 직원을 육성하여 생산성을 높일 수 있습니다.
새로운 소프트웨어 개발 팀이 생성되면 구현하기 위해 선택한 기능을 제공하기 위한 계획을 수립하기 시작합니다. 여기에는 일반적으로 기능의 복잡성에 따라 기능의 적절한 범위와 설계 프로세스를 보장하기 위해 PO(및 잠재적 고객)와 작업하는 것이 포함됩니다. 팀은 일반적으로 기능의 복잡성에 따라 이 단계에서 며칠에서 몇 주를 보냅니다. 이 단계의 주요 아티팩트 중 하나는 팀에서 기능을 제공할 것으로 예상되는 HLE(고수준 추정)입니다.
팀은 설계, 구현 및 테스트에서 기능의 전체 개발을 담당합니다. 증분 전달은 매우 권장되지만 증분 품질은 매우 권장되지 않습니다. 우리는 코드 기반의 끝부분을 항상 출하 가능한 수준의 품질로 유지하기 위해 노력합니다.
팀 스프린트
Qumulo의 소프트웨어 개발 팀은 2주 스프린트로 작업합니다. 앞서 언급했듯이 우리는 2주마다 소프트웨어의 새 버전을 출시합니다. 이것이 어떻게 작동하는지 그 자체로 좋은 기사가 될 수 있습니다. 모든 팀(최대 10명)은 예외 없이 이 릴리스 주기를 따릅니다.
모든 스프린트가 시작될 때 팀은 계획 단계를 거쳐 스프린트 내에서 달성할 것으로 기대하는 것을 개략적으로 설명합니다. 마찬가지로 팀은 모든 스프린트가 끝날 때마다 검토(누구나 참석할 수 있음)를 개최하여 팀이 달성한 것을 발표하고 달성하고자 한 것과 비교하여 평가합니다. 이러한 계획/검토의 흐름을 통해 팀은 HLE에 대한 자신감을 얻고 전달 목표를 향해 좋은 진전을 이루고 있는지 확인할 수 있습니다.
팀 이동
말하자면 두 축을 따라 팀 이동을 권장합니다. 첫째, 팀 구성원이 변경될 수 있습니다. 둘째, 팀 헌장은 일반적으로 팀이 현재 헌장을 완료했을 때 변경됩니다. 팀이 헌장을 포기하고 비즈니스 요구에 따라 새로운 헌장을 작성해야 하는 예외가 거의 없었습니다.
팀 구성원의 변화는 개인에 의해 주도되며 선택의지와 선택을 촉진하는 또 다른 방법입니다. 또한 개인이 제품의 다른 부분에서 작업하여 새로운 기술을 개발하도록 돕습니다. 놀랍게도 팀 움직임은 생각만큼 높지 않습니다. 분기당 소수.
팀 구조
앞서 언급했듯이 소프트웨어 개발 팀은 소프트웨어/하드웨어 엔지니어뿐만 아니라 Agile Coach와 Product Owner로 구성됩니다. 팀 리더가 없습니다. 개발 관리자 및 팀당 할당된 리드가 없습니다. 사실 엔지니어링 조직에는 계층 구조가 없습니다.
고정 차터 팀(Special Teams)
우리 팀 중 일부는 고정 헌장을 가지고 있습니다. 이는 일반적으로 항상 필요할 것으로 예상되는 팀을 위한 것입니다. 다음과 같은 몇 가지가 있습니다.
- 성능: 소프트웨어 줌 확대
- 지원: 우리는 "당신이 그것을 깨뜨립니다. 당신이 고친다”는 사고방식과 우리는 소프트웨어 엔지니어로 구성된 지원 팀을 가지고 있습니다.
- 엔지니어링 인프라: 시스템, CI 및 제품을 만들기 위해 의존하는 기타 여러 도구를 구축합니다.
- 플랫폼: 소프트웨어를 실행할 수 있는 새로운 물리적 및 가상 플랫폼과 수많은 새로운 하드웨어를 평가합니다.
- 인증: 이것은 우리의 소프트웨어가 고객에게 안전하게 출시될 수 있도록 끊임없이 노력하는 3명의 QA 엔지니어로 구성된 팀입니다.
인증팀을 제외하고 위 팀의 구성원은 자발적입니다. 예, 지원 팀도 해당 팀에 합류하기로 선택한 개인을 기준으로 100% 결정됩니다. 지원 팀에는 최소 3개월의 체류 요건이 있습니다. 그리고 우리 팀도 대기자 명단이 있습니다.
우리는 창립 이래(약 5년 전) 소프트웨어 개발 팀 구조에 이 모델을 채택해 왔으며 우리에게 매우 효과적이었습니다. 우리는 Qumulo의 성공에 기여하고자 하는 똑똑하고 창의적인 개인을 고용했습니다. 개인이 어떤 그룹의 사람들과 함께 일하고 해당 팀이 비즈니스 요구 사항의 제약 내에서 어떤 프로젝트를 수행하는지 선택하게 함으로써 개인의 참여를 유지하고 최상의 작업을 수행할 수 있습니다. 작업 그룹 및 할당을 결정하는 선택을 포함하는 프로세스를 선호함으로써 우리는 결과에 대한 자율성과 소유권을 촉진합니다.
