개발자간에 작업을 나누는 가장 좋은 방법은 무엇입니까

우리 팀과 저는 약 10 년 전에 개발 한 사이트를 재건하고 있으며 Agile에서 사이트를 만들고 싶습니다.

그래서 많은 시간을 읽은 후 (아마도 충분하지 않음) 개발자간에 작업을 나누는 방법에 대한 질문에 어려움을 겪고 있습니다.

좀 더 구체적으로 말하면 사이트가 서로 통합되지 않은 별도의 모듈로 나뉘어져 있습니다.

개발자간에 작업을 나누는 가장 좋은 방법은 무엇입니까?

• 각 사람에게 다른 모듈을 제공합니다.
• 모든 개발자를 동일한 모듈에 할당하고 모듈의 다른 부분 (UnitTesting, DAL 및 Mapping, Logics, UI)으로 작업을 분할하십시오.
• 모든 개발자를 동일한 모듈에 할당하고 작업을 다른 로직으로 분할하십시오 (예 : 각 개발자는 특정 로직 (BL의 메소드 일 수 있음) 및 단위 테스트, DAL 및 맵핑 및 UI)을 담당합니다.

아니면 완전히 다른 것입니까?

우리 팀은 현재 몇 번의 릴리스에 대해 "민첩한"상태를 유지하려고 노력했지만 대기업의 일원이되어서 쉽지 않았습니다. 나는 대답이있는 것처럼 가장하지는 않지만, 관찰 한 내용을 공유 할 수 있습니다.

• 모듈 당 개발자 나누기 :

  • 사람들이 고립되어 너무 많이 일하면 팀이 기술과 지식을 공유하는 데 도움이되지 않기 때문에주의해야합니다
  • 사람들이 자신의 모듈에 너무 집중하고 더 큰 그림을 보지 않으면 계획 회의 및 일일 스탠드 업은 모두에게 둔감 할 수 있습니다. 사람들이 지루해지면, 그들은 체크 아웃을 시작하고 민첩성이 테이블에 가져다주는 많은 혜택을 잃습니다.
  • 실제로 잘 작성된 일부 구성 요소와 다른 구성 요소로 끝날 수 있습니다. 사람들이 고립 된 상태에서 일하면 선배들은 후배를 훈련시킬 수 없습니다.

• 모두가 같은 모듈에서 동시에 작업

  • 우리는 경영진이 팀 전체에 민첩성을 부여하기로 결정했을 때 한 번의 릴리스를 시도했으며 완전히 길을 갈 것입니다. 절대 열차 사고로. 우리는 일년에 9 명의 개발자로 구성된 팀이 일반적으로 1 명의 개발자가 수행 한 작업을 수행했습니다. (나는 여기서 과장하고 있지만 많지는 않을 것이다).
  • 아무도 호흡 실이 있다고 생각하지 않았습니다. 소프트웨어에 신경 쓰지 않은 사람들은 더 큰 팩의 일부이기 때문에 집에서 바로 느끼고 그룹에 희석되었습니다. 소프트웨어에 대한 열정이있는 사람들은 9 명이 동의 한 범위를 벗어나거나 이동할 수있는 자유가 없기 때문에 절대적으로 어려움에 처했습니다.
  • 모든 회의는 저를 쏘고 싶어하는 시점까지 영원히갔습니다. 같은 방에서 의견을 가진 사람들이 너무 많아서 같은 괴물 DLL을 사용해야했습니다. 공포.
• 마지막 릴리스에서 우리는 다른 것을 시도하기로 결정했습니다
  • 무엇보다도 개발 그룹을 3-4 명의 개발자로 구성된 소규모 팀으로 나눕니다. 각 팀은 서로 상대적으로 격리 된 상태로 일했지만 팀 내에서는 훨씬 더 단호하게 일했습니다.
  • 이 접근 방식을 사용하면 스탠드 업이 빠르며 계획 회의는 견고한 4 시간에 비해 1-2 시간이 걸립니다.
  • 각 팀은 해당 팀의 개발자가 관심을 갖는 것에 대해서만 논의하기 때문에 모든 사람들이 참여하고 있다고 느낍니다.
  • 각 팀의 기술 책임자는 정기적으로 다른 기술 책임자와 대화하여 전체 프로젝트가 제대로 진행되고 있는지 확인합니다.
  • 사람들을 특정 모듈의 "소유자"로 만드는 대신, 우리는 사람들에게 전문 지식 영역을 할당했습니다. 따라서 프로젝트를 처음 시작할 때 사람들이 자신의 모듈을 가지고있는 것처럼 느꼈지만 몇 개월 후에 개발자들은 서로 코드를 살펴보기 시작했습니다. 영역이 겹치기 시작했습니다.
  • 코드 검토는 필수적입니다. 이것은 우리가 엄격한 코드 검토 정책을 가지고 있고 팀의 모든 사람들이 그들을 좋아하는 두 번째 릴리스였습니다. 특정 영역의 전문가는 다른 사람이 해당 코드를 수정할 때 항상 코드를 검토합니다.
  • 코드 검토를 통해 많은 지식 공유가 가능하며 팀의 코드 품질이 전반적으로 향상되었음을 확인할 수 있습니다. 또한 코드가 너무 자주 검토되기 때문에 사람들이 다른 사람의 전문 분야에 들어갈 때 이미 코드를 이미 몇 번 보았을 가능성이 있습니다.
  • 각 팀의 많은 부분이 디자인 검토 회의에 빠지므로 코드를 본 적이 없어도 모든 사람은 팀이 담당하는 모든 모듈의 일반적인 흐름에 익숙합니다.
  • 우리는 이것을 약 10 개월 동안 해왔으며 격리 된 모듈 접근 방식으로 시작하여 모든 사람이 모든 작업을 수행하는 것처럼 느껴졌습니다. 그러나 동시에, 좁아 지거나 제한된 것처럼 느끼는 사람은 없습니다. 그리고 사람들이 여전히 어떤 권위를 가지고 있는지 확인하기 위해, 우리는 그것들을 지금은 형식적인 것이지만 지역 전문가로 남겨 두었습니다.

우리는 그 마지막 일을 해왔고, 개선의 여지가 많이 있지만, 전체 팀은 매우 기뻤으며 우리가 대기업의 일원이 될 때 많은 것을 말합니다.

우리가 "민첩한"처음 3 번 잘못한 한 가지 중요한 점은 사람들이 어떻게 작업해야하는지, 그들이 무엇을해야하는지에 대해 들었던 때입니다. 이것이 팀이 프로젝트에 대한 관심을 완전히 상실하게하는 가장 좋은 방법입니다.

대신, 반대를 시도하십시오. 팀원들에게 그들이 원하는 것은 무엇이든 할 수 있고 관리자 / 리더로서 (당신이 하나라면, 관리자가이 말을 반복하지 않으면) 가능한 한 생산적이고 행복해야한다는 것입니다. 프로세스는 나쁘지 않지만 프로세스가 필요하다는 것을 깨달을 때 팀을 도울 수 있어야합니다.

팀원 중 일부가 고립 된 상태에서 일하는 것을 선호하는 경우에는 어느 정도 팀원에게 맡기십시오. 그들이 쌍으로 일하는 것을 선호한다면 그렇게하도록하십시오. 사람들이 가능한 한 자신의 작품을 고르도록하십시오.

마지막으로, 이것은 매우 중요하며 항상 간과됩니다. 당신은이 권리를 얻지 못할 것입니다 (슈퍼맨이거나 최소한 배트맨이 아닌 한). 정기적 인 회고 회의를 갖는 것이 매우 중요합니다. 우리가 회고를 시작했을 때, 그것들은 그 책에 의해 이루어졌으며 그것은 당신이 앉아야 할 또 다른 과정처럼 느껴졌습니다. 그것은 회고적인 것이 아닙니다. 팀의 의견을 경청하고 가장 고통을주는 영역을 파악하고 수정하여 모든 사람이 업무를 진행할 수 있도록합니다. 일반적으로 소프트웨어 엔지니어는 일반적으로 제품과 기능을 제공하는 것과 같이 회고 회의에서 의사 소통해야하는 가장 중요한 메시지는 오직 이익을위한 것입니다. 가장 큰 장애물 또는 가장 쉬운 장애물부터 시작하여 장애물을 식별하고 해결하려고합니다.

팀과 회의를 갖고 할 일 목록을 보여주고 누가 무엇을하고 싶은지 물어보십시오.

모듈을 생각하지 마십시오. 기능 요소를 생각하십시오. 이러한 기능 요소를 사용자 스토리 (또는 다른 방법)로 설명하고 승인 기준 (현재 응용 프로그램에서 정의하고 비즈니스가 기대하는 변경)을 설명하는 것을 잊지 마십시오. 기능적 요소를 백 로그에 넣습니다. 그런 다음 비즈니스가 먼저 어떤 기능을 제공해야하는지 우선 순위를 정하십시오 (점차적으로 반복적으로 작업하고 우선 순위는 먼저 구현해야 할 사항을 알려줍니다).

최소한 원래 응용 프로그램의 일부에 대해이 기능을 갖추면 개발 준비가 된 것입니다. 다음에 일어날 일은 선택한 민첩한 방법론에 따라 다릅니다. 중요한 부분은 각 기능을 일반적으로 여러 작업으로 나눌 수 있으며 팀 구성원이 원하는 작업 (자체 구성)을 선택한다는 것입니다. 민첩하게 시작할 때, 자기 조직에는 인기없는 작업이 팀에 의해 동등하게 공유되도록 누군가의 도움이 필요할 수 있습니다. 팀이 성숙 해지면 개발자는 현재 자체 조직과 의견을 달리하는 것을 망설이지 않고 팀 내에서 자동으로 처리됩니다.

모듈을 처음부터 생각하는 것이 좋은 방법 일 필요는 없습니다. 어떤 이유로 응용 프로그램을 다시 작성하고 있으며 잘못된 모듈 분리를 기반으로하는 현재 응용 프로그램 아키텍처가 눈에 띄는 문제의 숨겨진 이유 중 하나입니다. 또한 기존 모듈의 일부 기능이 완전히 재정의되고 다른 곳으로 옮겨 질 수 있습니다.

나는 다윗의 대답에 동의하지만, 정교하게 만드는 것에서 이익을 얻을 수 있다고 느꼈습니다.

• 민첩한 의미, 당신은 이러한 결정을하지 않고 팀에 밀어 넣습니다. 그런 프로젝트 관리자 / 리더는 없습니다. 팀만
• 가장 잘 아는 사람들, 일을 나누는 방법은 팀원들입니다.
• 백 로그에 대해 토론하고 다음 반복 / 스프린트에서 실현하고자하는 것을 찾으십시오.
• 계획 포커 나 유사한 방법을 사용하여 어쨌든 얼마나 많은 작업을 나눌 것인지에 대한 아이디어를 얻고 실제 작업 패키지를 함께 나누기 시작하십시오 .

기본적으로 요점은 다음과 같습니다. SE의 어느 누구도 당신에게 그 질문에 답할 수 없으며, 그에 대한 지적도 없습니다. 팀으로서 답변을 얻는 것이 훨씬 낫기 때문입니다.

가장 간단한 방법이 가장 좋습니다.

아주 좋은 이유를 정의 할 수 없다면 작업을 testing / log / UI / etc와 같은 그룹으로 나누지 마십시오. 저의 추론은 프로그래머가 평범한 전문 분야 이외의 분야에서 일할 수있게 해주면 더 흥미롭고 도전적 일 수 있으며 자신의 분야에서 발전하고 성장할 수 있다는 것입니다. 시간 제약으로 인해 전문 지식을 기반으로 작업을 분할해야한다고 생각되면 최소한 각 개발자가 여전히 자체 단위 테스트를 수행하고 코드 검토 및 승인 테스트를 사용하여 문제를 해결해야합니다. 자신 만의 테스트를 작성하는 것은 매우 민첩하며 테스터가 시간을 갖기를 기다리는 것은 매우 낭비입니다.

이 같은 종류의 딜레마에 직면했을 때 나는 다음과 같은 접근법을 사용했다.

• 프로젝트 범위를 정하십시오. 자신이 무엇을하고 있는지에 대한 아이디어를 제공하고 프로젝트를 일련의 작업으로 나누어 기능 목록을 개발하십시오.

• 기능의 우선 순위를 정하십시오. 어떤 기능을 조기에 완료해야하는지 결정하고 고객에게 즉각적인 가치를 제공 할 수 있습니다. 개발자가 동일한 모듈로 작업하더라도 걱정하지 않아도되지만 코드 병합을 관리 할 수있는 좋은 프로세스와 도구가 있어야합니다.

• 팀을 참여시키고 개발자에게 기능을보다 쉽게 ​​관리되는 작업 목록으로 나누도록 도와달라고 요청하십시오. 그룹으로 검토하고 더 쉽게 추정 할 수 있도록 필요에 따라 작업을 조정하십시오.

• 각 개발자에게 개발자가 작업하려는 우선 순위 큐의 맨 위에서 구현할 태스크 또는 반복 실행 방법에 따라 태스크 그룹을 선택하도록 요청하십시오.

• 우선 순위 큐의 맨 위에서 다음 항목을 선택하기 전에 각 개발자가 완료 될 때까지 한 가지 작업 만하도록하십시오. 사람들이 때때로 작업을 변경하도록 유혹 할 수도 있지만, 개발자의 시간 측면에서 낭비로 이어질 수 있습니다. 의존성 병목 현상이 발생하면 작업 우선 순위를 조정하고 낭비를 최소화해야합니다.

• 개발자가 겹치는 반복으로 실행하고 그에 따라 릴리스를 관리하는 것을 두려워하지 마십시오. 이렇게하면 작업 완료를 기다리는 릴리스간에 낭비되는 시간을 최소화 할 수 있습니다.

궁극적으로 애자일이란 팀, 회사 및 고객에게 잘 맞는 솔루션을 찾는 것입니다. 자신에게 가장 적합한 관행의 균형을 찾아서 프로세스를 조정하는 것은 사용자의 책임입니다. 과제를 나누는 방법은 훨씬 더 큰 프로세스에서 매우 중요한 부분이 될 것이지만, 기꺼이 참여를 장려하고 나중에 개발되는 프로세스 관련 문제를 해결하기 위해 최대한 간단하게 유지해야합니다.

프레드 브룩스 박사의 외과 팀 을 언급하지 않고서는 개발자 팀의 조직 토론이 완료되지 않습니다 .

기본 공식은 다음과 같습니다. 작업 단위당 하나의 외과 팀

외과 팀 정의

수술 팀의 개념은 두 가지 기본 아이디어를 기반으로합니다.

1. 누화로 인해 생산성이 저하 되므로 작업 단위당 개발자 수가 적습니다 .
2. 고출력 개발자 는 저출력 개발자보다 성능이 뛰어나며 (브룩스에 따르면 중간 출력 개발자와 같은 것은 없습니다) 따라서 가장 중요한 작업을 수행하고 방해 요소를 제한하는 것이 좋습니다.

수술 팀은 3-10 명의 개발자로 구성됩니다.

1. 최고 프로그래머. 실제 프로그래밍의 대부분을 수행하는 고출력 개발자.
2. 부조종사. 회의 참석 및 요구 사항 수집과 같은 일부 프로그래밍 작업뿐만 아니라 일부 관리 작업을 수행하는 또 다른 고출력 개발자.
3. 1-8 명의 조수. Brooks는이를 문서화, 코드 정리, 리서치, 도구 / 알고리즘 작성, 테스트 등을 담당하는 개발자라고 설명합니다. 60 년대로 Brooks는 정확히 8 개의 역할을 제안했지만 현대적인 도구를 사용하면 1 또는 2 정도만 있으면됩니다. 아마도 프로젝트의 요구에 따라 할당되어야합니다.

작업 단위 정의

이제 팀을 구성 할 수있게되었으므로 무엇을 할당해야합니까?

• 프로젝트가 매우 작 으면 쉽습니다. 하나의 수술 팀을 전체 프로젝트에 할당합니다.
• 그렇지 않으면 전체 프로젝트 아키텍처 를 담당하는 사람이나 팀으로 시작해야합니다 . 소프트웨어를 적절히 모듈화하여 추가 하위 팀으로 작업을 분할하는 것이 그들의 임무입니다. 아키텍처 팀은 개발자를 너무 얇게 퍼 뜨리지 않기 위해 다른 작업을 수행 할 수도 있습니다.

허용 가능한 세 가지 기본 패턴이 나타납니다.

1. 각 계층 (UI, DAL 등)에 대해 정확히 1 개의 하위 팀
2. 각 모듈에 대해 정확히 1 개의 하위 팀 (홈 페이지, 지원 사이트, 상점)
3. 두 가지의 혼합 (낮은 수준의 프레임 워크 팀과 각 모듈에 대한 UI 중심 팀)

개발자와 모듈의 수 (및 시간 척도)에 따라 일반적으로 개발자가 흥미로운 모듈 하나를 선택하고 도전적인 모듈 하나 (바람직하게는 수행하지 않은 것)를 선택한 다음 나머지는 기술 수준과 시간 제약. 나는 이것이 내 개발자들에게 그들이 일하고 싶은 것을주고 그들을 밀어 줄 무언가를 준다는 것을 안다.

물론 이것은 항상 작동하지는 않습니다 ...

여기 내가 할 일이 있습니다 :

모든 모듈이 작 으면 각 모듈에 작업 할 수 있습니다. 그렇지 않으면 다음을 수행하십시오.

1. 각 모듈의 크기, 복잡성, 기술을 정의하십시오.
2. 각 팀원 기술을 정의하십시오.
3. 함께 일하는 사람과 다른 사람과 잘 어울리지 않는 사람을 정의하십시오.
4. 모듈 기술 요구 사항과 팀 기술을 기반으로 잘 협력하는 팀에 큰 모듈을 할당하십시오.
5. 모듈 기술 요구 사항 및 팀 기술을 기반으로 다른 사람들과 잘 어울리지 않는 사람들에게 나머지 모듈을 할당하십시오.

다른 사람들과 일하기를 원하지 않는 사람들이 가장 능숙한 사람들이며 위의 경우는 일반적인 경우이므로 위의 방법은 효과가 없습니다.