소규모 팀을 위한 프로젝트 방법론 [닫기]

Question

우리 회사의 각 프로젝트에는 일반적으로 1~4명의 개발자/아트 디렉터/카피라이터가 있습니다. 어떤 방법론을 사용하도록 권장하시겠습니까?기민한?XP?스크럼?다른 것?(나는 그것들이 본질적으로 동일한 개념의 변형이라는 것을 알고 있습니다. 그렇습니다)

Answer 1

나는 그것에 대한 일반적인 대답이 있다고 생각하지 않고, 질문은 너무 넓고, 당신은 그것이 당신이 상자에서 꺼내는 제품인 것처럼 "방법론을 채택 할 수 없다"는 것은 시간이 지남에 따라 진화하는 것입니다. ... 어쨌든이 책의 사본을받는 것이 좋습니다. 첫 번째 소프트웨어 개발

그런 다음 원하는 아이디어를 프로젝트에 적용합니다. 이름과 유행어에 대해 걱정하지 마십시오. 어쨌든 내년에는 모두 "Passé"가 될 것입니다. 간단하게 유지하십시오 처음에는 더 의미가있는 아이디어를 채택하고 벅을 가장 많이주는 아이디어를 제공하고 아직 존재하지 않는 문제를 해결하려고 시도하지 마십시오. 아주 좋은 출발이 될 것입니다.

Answer 2

쌍 프로그래밍의 경우 적어도 짝수의 프로그래머를 갖는 것이 가장 좋습니다 ...; P

소규모 팀의 좋은 점 중 하나는 필요 내부적으로 의사 소통하기위한 많은 지원 시스템 (버그 트랙커는 자신을위한 할 일 목록이되지만 어쨌든 갖는 것이 좋습니다). 전체 팀과 회의를 갖는 데 단지 당신의 숯불을 돌리고 "이봐, 밥과 칼, 이것을 살펴보세요!" 그러나 일반적으로 민첩한 방법은 중소형 팀에 매우 적합하지만 자체 동기 부여 팀원이 필요합니다.

나는 당신이 다른 방법들에서 좋아하는 아이디어를 선택한다고 말할 것입니다. 어쨌든 제안으로 간주 될 수 있습니다.

Answer 3

그런 소규모 팀의 경우 소프트웨어 개발에 대한 민첩한 접근 방식을 분명히 살펴볼 것입니다. 개인적으로, 나는 아마도 내가 가장 잘 알고 있기 때문에 XP, Scrum 및 Lean의 혼합을 사용할 것입니다. 특히 Agile에 익숙하지 않은 경우 XP는 좋은 출발점을 제공하여 프로젝트 별 적응을 찾을 수 있습니다. 나는 "민첩한 개발의 예술"을 강력히 추천합니다.

Answer 4

내 3 개발자 팀은 단순히 Kanban + Continuous Deployments를 사용하여 빠르게 움직일 수 있습니다. 나는 Scrum과 다른 사람들을 보았고 우리 소규모 팀에게는 너무 많은 오버 헤드가 있습니다.

Answer 5

그들은 비즈니스 측면과 매우 가깝습니다. 이는 프로그래머가 회계, 시간 또는 위험 관리 등의 의미를 잘 이해하지 못하는 경우가 많기 때문에 나쁜 것입니다.그들이 그렇다고 생각하더라도.그들은 사업을 정교한 기술 능력을 향상시킬 수 있는 또 다른 매력적인 기회로 여깁니다.회사 규모가 작기 때문에 개발 팀 내에서 복잡한 방법론을 구현하는 것은 과잉일 수 있습니다.그들은 기술적인 질문을 스스로 쉽게 처리할 수 있습니다.그들이 처리할 수 없는 것은 비즈니스 환경에 가깝다고 해서 더 이상 프로그래머가 아니라는 것을 이해하는 것입니다.

나는 일부 프로그래머들이 그토록 좋아하는 기술적 주제에 대해 고객과 이야기하기보다는 규율을 보장하고 기술적 측면에 집중할 수 있는 몇 가지 간단한 정책을 구현하는 것을 제안합니다.

Answer 6

대답은 자극적으로, 그것은 ...

각 팀은 성격과 능력의 조화이며 각 팀원은 다릅니다. "방법론"자체를 찾는 데 초점을 맞추기보다는 각 팀원이 성공하기 위해 각 팀원이 필요로하는 것에 집중하고 프로젝트가 성공하기 위해 필요한 것과 부합하는 것이 좋습니다. 이 두 고려 사항 사이에 올바른 방법론과 프로세스의 혼합을 찾을 수 있습니다.

예를 들어, 저는 지난 7 개월 동안 소규모 팀 (3 명의 정규 개발자와 파트 타임 UI 디자이너)을 이끌고 있습니다. 나는 다음과 같은 관행/절차가 우리에게 적합하다는 것을 알았습니다 ...

• 짧은 (60-90 일), 잘 정의 된 나선을 채택하여 팀이 집중하고 전달 지향을 유지하고 위험을 최소화하는 데 도움이됩니다.
• 반복 수명주기를 채택하여 나선형 과정에서 고객에게 몇 가지 증분 배달을하고 우리가 한 일에 대해 논의합니다. 그렇게하면 우리와 고객은 우리가 그들의 요구를 해결하고 있는지 확인할 수 있습니다.
• 각 팀원의 태도 및 방향을 맞춤화합니다. 예를 들어, 한 팀원은 더 많은 주니어 개발자이고 다른 팀원은 매우 훌륭한 개발자이지만 개방형 작업을 잘 처리하지 못합니다. 그들은 다른 접근법이 필요합니다.

당연히 프로젝트와 팀의 요구에 맞게 CM 프로세스 및 테스트 관행을 조정했습니다.