웹 앱을 구축하는 민첩한 팀을 확장하고 분할하는 가장 좋은 방법은 무엇입니까?

최근에 웹 앱을 빌드하는 민첩한 개발 프로젝트에서 스크럼 마스터로 일하는 회사에 합류했습니다.

이 팀은 민첩한 팀의 최대 규모가 될 것입니다 (다음 주 9 일 예상). 우리는 잠재적으로 팀을 두 팀으로 나누는 가능성에 대해 이야기했습니다. (현재 과도하지 않은) 스탠드 업을 줄이려는 것이 아니라 스프린트 계획 세션에서 사람들이 완전히 지루해지지 않도록하는 것입니다.

프로젝트에는 두 가지 매우 뚜렷한 계층, 즉 매우 복잡한 기술 백엔드 개발과 UI 디자인 / 빌드 / 통합이 있습니다. 백엔드 사람들이 기술적으로 이야기 할 때 UI 사람들이 영역을 벗어나고 그 반대도 마찬가지입니다. 시간 효율성을 높이기 위해 팀을 분할하는 논리적 인 방법처럼 보이지만 실제로 할 수있는 일은 협업과 지식 공유를 줄이는 것입니다. 두 팀은 나머지 팀이 무엇을 만들고 있는지에 대해 실제로 좋은 아이디어를 얻지 못합니다.

누구든지 이와 같은 일을 한 경험이 있습니까?

불행히도 UI 사용자는 복잡한 백엔드 작업의 세부 사항에 신경 쓰지 않습니다. 이것은 회고에 대한 토론 주제처럼 들립니다. 팀을 규율에 따라 나누면 위험한 선례가 될 것입니다. 요구 사항 사람들이 영역을 시작하고 UI 담당자가 수행하는 작업에 신경 쓰지 않고 자신의 팀을 요구하기 전에 얼마나 빨리 전례가 될 것입니다.

나는 항상 팀을 위해 수직 슬라이스를 선호했습니다. UI는 기술적 인 사람들이해야 할 일에 귀를 기울여야합니다. 기술적 인 사람들은 업무를보다 쉽게 ​​수행 할 수 있도록 도와 줄 수있는 사람들이기 때문입니다.

개인적으로 나는 UI 팀이 먼저 구역을 설정하는 문제에 초점을 맞추고 그 기능 장애가 해결되면 팀을 가장 잘 나누는 방법에 대해 논의합니다. 나는 UI 사람들을 비방하려고하지 않을 것입니다. 아마도 기술적 인 사람들은 UI 사람들에게 더 관련성이 높은 토론을하기 위해 더 많은 일을 할 수도 있습니다.

다른 사람들이 말했듯이, 팀은 새로운 구조를 결정하기 위해 스스로 조직 할 수 있어야합니다. 과거의 경험에 따르면 자기 조직은 모든 ​​사람이 자신의 훈련이나 관심사보다는 팀에 관심이있을 때만 실제로 작동 할 수 있다고 배웠습니다.

건배!

실제로 팀의 독립적 인 부분을 새로운 팀으로 나누는 것이 좋습니다. 더 큰 프로젝트에서는 개발자가 전체 프로젝트에 친숙해지기가 거의 불가능하므로 분할은 여전히 ​​공식적이거나 비공식적입니다.

각 새로운 팀에는 팀 리더 / 기술 관리자가 있어야합니다. 팀 리더 / 기술 관리자는 팀의 범위에 대해 잘 알고 있고 다른 팀의 작업에도 익숙합니다.

그 후 각 팀은 별도의 스크럼 회의를 가질 수 있으며 다른 팀의 리더가 참석할 수 있습니다. 이렇게하면 "지루한"사람들의 수를 줄일 수 있지만 팀은 다른 사람들이 무엇을하고 있는지 알고 성공적으로 협업 할 수있게됩니다.

팀의 범위가 교차하거나 한 팀이 다른 팀에 의존하는 경우 협업이 더 중요해집니다. 그러나 팀 리더가 공동 작업을 조정할 수있는 전체 팀을 다시 제시 할 필요는 없습니다.

스크럼의 주요 측면은 자체 구성 입니다.

질문을 팀과 논의하여 해결하도록 제안합니다.

귀하의 우려는 모두 잘 정립되어 있지만 스크럼 마스터로서 귀하의 임무는 코치하고 촉진하는 것임을 기억하십시오. 그들에게이 문제를 어떻게 해결할지 물어보십시오. 그들은 솔루션을 소유 것이다 있도록 그것을 작동합니다.

일반적으로 교차 기능 팀이 갈 길입니다.

팀을 분할 할 때는 항상 팀이 고객에게 가치를 제공 할 수 있어야한다는 사실을 명심하려고합니다. 귀하의 경우 팀에 백엔드 및 프론트 엔드 개발자가 모두 있습니다.

1. 프론트 엔드가 백엔드로부터 얼마나 멀리 있습니까? 예상대로 거리가 너무 멀 경우에만 분할하는 것이 좋습니다.

   • 백엔드가 데이터베이스 스키마에 대해 말하면 너무 멀지 않습니다 . 프론트 엔드와 백엔드 모두 데이터베이스 스키마에 대한 논의를 청취해야합니다.

   • 백엔드가 샤딩, 메모리 캐시, 디스크 대기 시간 등에 대해 이야기하는 경우, 이는 백엔드가 기계적인 동정과 최적화에 초점을 맞추고 프런트 엔드는 인간의 미학에 중점을 두는 것입니다.

2. 프론트 엔드와 백엔드 사이에 안정적이고 명확한 프로그래밍 인터페이스가 있습니까?

   • 안정적이고 모호하지 않기 때문에 프로그래밍 인터페이스 사용자 (프런트 엔드 개발자)는 변경 사항에 신경 쓸 필요가 없으며 올바르게 사용하는 방법을 배우기 위해 텍스트를 읽을 필요가 없습니다.

   • 백엔드 팀은 초기에 좋은 API와 모의 구현을 제공해야하며 그 후에야 실제 개발이 시작됩니다.

   • 이것은 API가 석재로 설정되어야한다는 것은 아닙니다. 이것은 팀을 둘로 나눈 결과의 완화 일뿐입니다.

3. 왜 이렇게 많은 애자일 기사가 세로 슬라이스를 권장합니까? 배경 정보는 다음과 같습니다.

   • 대부분의 민첩한 기사는 실제로 비용 관점에서 백엔드 작업을 피하는 것이 좋습니다.

   • 또한 민첩한 기사의 일부가 신생 기업에 대한 암시 적 편견을 가지고 있다는 것을 잊지 마십시오.

   • 마케팅의 가혹한 현실을 잊지 마십시오. 대부분의 고객은 프론트 엔드에 대해서만 비용을 지불합니다.

   • 백엔드 작업은 비용이 많이 들고 보수가 느린 경향이 있습니다. 회사가 이미 장기적으로 설립되어 있고 적절한 이익을 창출하지 않는 한, 기성품 기술과 오픈 소스 라이브러리를 고수함으로써 백엔드를 "아웃소싱"하는 것이 좋습니다.

   • 대부분의 민첩한 기사는 백엔드 스위치에서 살아남을 수 있도록 프런트 엔드를 구현하는 것이 좋습니다. 이 조언은 이전 기술과 함께 진행됩니다. 상용 기술이 모든 요구 사항을 충족하지 못하면 다른 기술을 시도하십시오.

4. 팀 분할로 인한 나쁜 결과를 완화 할 수있는 방법

   • 안정적인 백엔드
   • 안정적인 API
   • 낮은 결함률 백엔드
     • 이유 : 좌절을 피하기 위해
     • 방법 : 단위 테스트
     • 성능 또는 최적화; 기능적으로 정확해야합니다.
   • 지속적인 통합
   • 의사 소통, 진행 및 의사 결정의 투명성
   • 두 팀에서 비공식 토론을 장려
   • 팀원 (영역을 벗어난 사람)이 다른 팀의 회의에 참석하도록 격려하십시오.
   • 때때로 공동 회의 및 공동 회고 설정
   • 다른 팀 구성 활동

다른 사람들과 마찬가지로, 나는 수직 슬라이스를 사용하는 것이 좋습니다. 이를 "특징 팀"이라고도합니다. Scaled Agile Framework 사이트 ( http://scaledagileframework.com/scaled-agile-framework/team/features-components/) 에서 장단점을 읽는 것이 좋습니다 .

처음에는 분할 할 때 제품 소유자와 SDF Master가 두 팀의 릴리스 백 로그와 각 기능 팀의 개별 백 로그를 처리 할 수 ​​있습니다. 그러나 규모가 커짐에 따라 제품 기능 백 로그를 구현 한 다음 여러 애자일 팀 릴리스 백 로그에 공급할 수 있습니다. 해당 수준으로 확장되면 기능 백 로그를 관리 한 다음 구현을 위해 기능을 개별 팀으로 가져 오는 별도의 팀이 필요할 수 있습니다. 이 구조에서 다음과 같은 것을 가질 수 있습니다.

1. 애자일 팀 1 : SM, PO, 교차 기능 팀. 그들의 이야기에 대한 자신의 팀 백 로그가 있습니다.
2. 애자일 팀 2 : SM, PO, 부서 간 팀. 그들의 이야기에 대한 자신의 팀 백 로그가 있습니다.
3. 프로그램 관리 팀 : 제품 관리자, 릴리스 관리자, 엔터프라이즈 아키텍트. 상위 레벨의 서사시 및 기능에 대한 자체 프로그램 백 로그가 구성되어 분석되고 팀으로 전달됩니다.

안전 웹 사이트는 더 큰 팀을 구성하는 멋진 물건을 많이 가지고, 당신은 팀 --팀의 대규모 이동으로 일부는 당신을 위해 도움이 될 수 있습니다.