스크럼은 어떻게 자원 봉사 환경에 적응할 수 있습니까?

나는 최근에 스스로를 설정하는 과정에서 여전히 젊은 해커 공간에 합류했습니다. 이 공간에는 작업이 필요한 몇 가지 내부 프로젝트가 있으며 작업에 자원 봉사자가 부족하지 않기 때문에 운이 좋습니다.

이러한 프로젝트를 구성하는 방법에 대한 토론이있었습니다. 나의 가장 최근의 전문적인 경험은 Scrum과 관련이 있었으므로 우리의 소프트웨어 프로젝트를위한 Scrum 접근 방식을 고려하는 것이 좋습니다.

비록 소규모 풀 타임 팀에서 Scrum이 잘 작동하는 것을 보았지만이 조직의 성격은 다릅니다.

• 회원은 자원 봉사자 입니다. 일부는 풀 타임 학생입니다. 다른 사람들은 풀 타임으로 일을합니다. 우리는 실생활이 우선시되는 사람으로부터 일정한 수준의 기여를 기대할 수 없습니다.
• 거의 모든 사람이 수년간 소프트웨어 작성 경험을 가지고 있지만, 많은 회원이 전문적으로 또는 팀으로 수행 한 것은 아닙니다.
• 제품 소유자 가 없습니다 . 이러한 프로젝트의 요구 사항은위원회가 결정합니다. 이위원회의 구성원들도 이행을 위해 노력할 것입니다. 이것은 우리에게 하나의 전담 된 제품 소유자가 없다는 것을 의미합니다.
• 마감일 이 없습니다 (부드럽거나 어려움). 프로젝트는 완료되면 완료됩니다.

이것들은 상당히 중요한 차이점이지만 스크럼을 적용하는 데 차단제가 될 것이라고 확신하지는 않습니다. 약간의 조정만으로도이 장애물을 극복 할 수 있다고 생각합니다.

• 스프린트를 고정 된 스토리 포인트 크기로 변경하지만 유동적 인 지속 시간 (시간)으로 변경하더라도 자원 봉사자 개발자에게 비현실적인 전달 압력을 가하지 않으면 서 반복 릴리스의 혜택을 누릴 수 있습니다.
• 번 다운 차트 와 속도 계산을 버릴 수 있습니다 . 올바르게 이해하면 이는 개발팀과 경영진 간의 다리 역할을하는 도구 및 지표입니다. 이들은 개발자와 이해 관계자 모두에게 의미있는 형태로 진행 ​​상황을보고하는 역할을합니다. 보고 할 사람이 아무도 없다고 생각하면 (프로젝트 관리자, 제품 소유자 및 외부 이해 관계자가 없음)이 문제를 모두 해결할 수 있다고 생각합니다.

내가 조정할 수 있다고 생각하는 것 : 조정할 필요가 없습니다.

• 요구 사항 수집 회의 (들). 모든 사람이 테이블 주위에 앉아 사용자 사례에 대해 토론하고 UI 모형을 스케치하며 제품 백 로그를 작성합니다.
• 스프린트 회고전 . 이것은 우리가 자원 봉사 팀으로서 우리에게 도움이되는 개발 과정에 수렴하는 흥미로운 방법이 될 것입니다.

내가 확실하지 않은 것 :

• 일일 스탠드 업은 어떻게 치료해야합니까? 나는 그들이 우리 환경에서 전혀 가치가 있는지 궁금합니다. 스탠드 업 의식에 대한 나의 이해는 팀 전체에 정보를 자연스럽게 전파함으로써 의사 소통을 돕는다는 것입니다. 스프린트가 평균 스프린트보다 훨씬 적은 복잡성을 제공 할 것이라는 사실을 고려할 때, 다른 모든 팀원의 진행 / 개발에 대해 알 필요가 없을 수도 있습니다.
• Continuous Integration, Code Review 및 TDD와 같은 XP를 추진해야합니까 ? 나는 이것이 많은 것을 요구 할까 우려된다. 사람들이 스크럼에 더 익숙하고 팀으로 일하면 미래의 프로젝트에 이러한 개념을 도입하고 싶습니다.

내 질문 :

스크럼은 자원 봉사자 기반 환경에 적응할 수 있습니까?
그리고 지금까지 계획된 접근 방식이 올바른 방향으로 가고 있습니까?

칸반을 살펴보십시오. 제약 조건에는 SCRUM보다 적합합니다.

편집 : 스크럼은 '진행중인'작업량이 계속 통제되고 모든 스프린트가 끝날 때 단단한 것을 유지하기 위해 스프린트와식이있는 (대략적으로) 주문 된 백 로그입니다. 의식과 스프린트 종지가 사라지면 Kanban으로 끝납니다. 직접 진행중인 작업을 '진행중인'작업을 직접 제한하고 마지막에 안정성을 부여하는 대신 '완료'로 표시된 모든 항목을 수행하도록하는 것이 중요합니다. 각 스프린트.

민첩한 이점을 얻을 수 있습니다. 언제나 유연성, 예측 가능성 측정-SCRUM은 그 측면에서 약간 더 나아갈 수 있지만 약속없이 느슨한 분산 팀에 적합하지 않은 SCRUM의 의식이나 측면없이 . 캐치? 식을 버리는 데는 더 많은 훈련이 필요하므로 테스트, 코드 품질, 진행중인 작업에주의를 기울여야하며 백 로그의 최상위 (사람이 선택할 준비가 된 항목)를 충분히 정교하게해야합니다.

자원 봉사 환경에서 일부 사람들은 원하는 대로만 일하지만 투표 기반 백 로그를 가질 수 있습니다.

(예, 모든 TDD, CI, 리뷰 및 피어 프로그래밍 아이디어는 좋은 아이디어입니다).

먼저 언급 한 차이점을 해결하려면 다음을 수행하십시오.

• 회원이 자원 봉사자라고해서 약속을 요구할 수는 없습니다. 특히 스크럼에서 비교적 짧은 스프린트 기간으로 인해 각 구성원이 향후 몇 주 동안 프로젝트에 얼마나 많은 시간을 투자 할 수 있는지 알 수 있어야합니다. 얼마나 많은 스토리 포인트가 현실적인지 결정하기는 어렵지만 스크럼을 실행 불가능하게 만들지 않기 때문에 각 스프린트가 다른 시간 동안 팀 구성원을 사용할 수있게하면 계획이 조금 더 어려워집니다.
• 제품 소유자는 이해 관계자가 제품에 대한 비전 (및 요구 사항)을 개발 팀에 통합하고 전달할 책임이 있습니다. 통합 부분은 이미 '조향'위원회에서 다룰 것입니다. 커뮤니케이션 부분의 경우 멤버 중 하나를 기본 대변인으로 위임 할 수 있습니다. 그런 다음 모든 실제적인 목적으로 제품 소유자가됩니다.
• 외부 마감일이없는 것이 실제로 Scrum의 문제가 아닙니다. 제품을 완성하는 데있어 팀의 자부심이 더 커집니다. 스크럼 자체에는 각 스프린트마다 자연스러운 마감일이 있습니다.

제안 된 적응, 특히 자원 봉사자와 함께 일할 때는 고정 된 스프린트 길이를 유지하는 것이 좋습니다. 그렇게함으로써, 자원 봉사자들은 어느 기간 동안 그들의 헌신을 포기하고 있는지 확실히 알 수 있습니다.

또한 번 다운 차트를 즉시 버리지 않습니다. 또한 팀 자체가 자신의 노력에 대한 성과를 파악하는 데 유용 할 수 있습니다. 나는 그것을 유지하거나 버릴 것인지 결정하기 위해 팀에게 맡길 것입니다. 속도 계산도 마찬가지입니다. 특히 각 스프린트마다 가용 한 인력 시간이 크게 변할 경우, 향후 스프린트를 추정하는 데 매우 유용합니다 (특히, 인당 완료된 포인트 수를 계산하는 경우).

매일 스탠드 업에 관해서는 모든 사람이 무엇을하고 있는지 또는 문제가 있는지 (그리고 복잡성과 무관 한) 것을 알리기 만하면 여전히 설정에 유용합니다. 그러나 매일 스탠드 업을 구현하기가 더 어려울 수 있으므로 타협해야 할 수도 있습니다.

언급 한 XP 관행은 Scrum 사용과 독립적으로 도입 될 수도 있고 그렇지 않을 수도 있으며 회고 중에 제안 될 수도 있습니다.

아무도 지적하지 않은 것이 놀랍지 만 프로젝트는 대부분의 오픈 소스 프로젝트처럼 보입니다. 더 인기있는 오픈 소스 프로젝트를 확인하면 약간의 영감을 얻을 수 있습니다. 저는 여러분이 스크럼을 잊어 버리고 일반적인 민첩성의 관점에서 이것을 생각해야한다고 생각합니다.

애자일은 커뮤니케이션과 협업에 관한 모든 것입니다. 애자일 선언문에서 4 점 만점에 2 점이 있다고하는 이유가 있습니다.

프로세스 및 도구에 대한 개인 및 상호 작용

계약 협상을 통한 고객 협업

또한 프로젝트를 설명하는 방식에 따라 프로젝트를 수행하는 모든 사람과 대면 커뮤니케이션을하기가 어려울 수 있습니다 (애자일 및 스크럼 모두 권장). 그래서 제가 중점을 두어야 할 것은 전체 팀 (자원 봉사자 및 제품위원회)을위한 커뮤니케이션 채널을 구축하는 것입니다. 위키, 포럼, 화상 회의 및 적절한 백 로그, 작업 및 버그 추적 시스템과 같은 것은 모든 사람이 현재 진행중인 작업과 수행해야 할 작업을 알 수있는 좋은 방법입니다.

두 번째로 주목해야 할 것은 민첩성의 기술적 부분을 칫솔질하는 것이 아닙니다. 많은 사람들은 자신이 프로세스 측면이 아니라 민첩한 작업을 수행하는 사람이라고 생각합니다. 코드 검토는 프로젝트를 아는 사람이 커밋 / 푸시를 검토하여 충분한 품질을 유지하도록함으로써 중요하고 대부분의 오픈 소스 작업입니다. TDD는 모든 애자일 프로젝트에 실제로 제공됩니다. 다른 사람의 실수와 실수를 고치기 위해 자원 봉사자가 귀찮게 할 수없는 경우에는 코드의 변경 사항이 이전 기능을 손상시키지 않도록합니다. 또한 검토자가 추가 된 기능을 테스트에서 확인할 수 있기 때문에 코드 검토가 더 쉬워지고 기능을 실제로 실행하여 기능이 실제로 의도 한대로 작동하는지 확인할 수 있습니다. 지속적인 통합은 TDD와 동일합니다.

마지막으로, 적어도 몇 명의 직원이 프로젝트에 풀 타임으로 일해야한다고 생각합니다. 그 사람들에게는 특정한 역할이 있어야합니다.

• 제품 소유자 : 전적으로위원회를 운영하는 것이 좋지만이위원회의 말을 사양이나 사용자 사례로 해석하고 올바르게 구현할 책임이있는 사람이 있어야합니다.
• 코디네이터 및 스크럼 마스터 :이 사람은 전체 프로세스를 책임지고 모든 사람이 프로젝트에서 발생하는 중요한 일에 대해 알도록해야합니다. 또한 위키 및 작업 및 버그 추적 도구를 유지 관리합니다. 누군가 프로젝트에 대해 궁금한 점이 있으면 먼저 물어보아야합니다.
• 주요 개발자 및 설계자 : 코드를 가장 잘 아는 사람. 그는 코드 검토를 수행하고 민첩한 개발에 충분한 코드 품질을 보장합니다.

설명하는 방식으로 적용 할 수 없으며 여전히 SCRUM이라고합니다. 하지만 제 생각에는 설명 한 설정에 다음과 같이 Scrum을 사용할 수 있습니다.

1. 반복이 수정되었습니다. 진행 상황을 측정 할 수 있습니다. 이것은 단지 관리를위한 것이 아니라 팀이 그들이 어떻게 수행하고 있는지“알”기위한 것입니다.
2. 반복 시작시 지원자에게 용량을 공유하도록 요청하십시오. 모든 팀은 구성원이 저지른 일에 필요합니다. 그렇지 않으면 특정 구성원이보다 전문적으로 수행 한 작업을 위해 팀을 떠날 수 있습니다.
3. 마감일이없는 것이 좋습니다. 스크럼은 각 반복이 끝날 때 수행하는 작업이 잠재적으로 선적 가능해야한다고 강요하지 않습니다. 그러면 그때까지 수행 한 작업 (작동중인 작업)에 따라 다음에 수행 할 작업을 결정할 수 있습니다.
4. 제품 소유자가없는 것도 효과가 있습니다. 순위 백 로그를 쌓고 작업을 수락 / 거부하는 일종의 투표 시스템을 사용할 수 있습니다.
5. 요구 사항 수집은 스크럼의 일부가 아닙니다. 어쨌든 원하는대로 할 수 있습니다. 그러나 반복 범위의 일부로 포함하지 마십시오. 별도의 용량이 있어야합니다. 따라서 반복의 경우 요구 사항이 분명한 작업 만 계획하십시오 (예 : 팀이 승인 기준을 알고 있음).
6. 회고가 좋습니다. 따라서 스크럼을 시작한 다음 회고를 사용하여 작동하는 것과 작동하지 않는 것을 확인하십시오. 예를 들어 반복 크기를 변경해야 할 수도 있습니다.
7. 일일 상태는 필수입니다. 이는 팀이 서로 동기화 할 수있는 기회를 제공합니다. 즉, 다른 구성원의 결과물을 사용할 수 없어서 불필요하게 차단되는 작업이 없도록 노력을 조정합니다.
8. XP는 좋습니다. XP를 기반으로 완료에 대한 엄격한 정의가 있어야합니다. 예를 들어 검토하지 않으면 코드가 입력되지 않습니다. 더 적은 일을하세요 ..

다른 접근법을 제안 할 수 있습니다. 자원 봉사자를 다루기 때문에 고려해야 할 것이 몇 가지 있습니다. 당신의 팀은 아마도 높은 이직률을 가질 것이며, 삶은 방해가되고 사람들은 산만해질 것입니다. 남은 사람들 중 일부는 지속적으로 기여하지만 크게 기여하지는 않을 것입니다. 마지막으로 프로젝트에 이빨을 가라 앉히는 하드 코어 그룹이 있습니다. 나는 여기서 당신의 노동력에 대해 많은 가정을하고 있습니다. 그리고 만약 당신이 나의 평가가 당신과 함께 일하는 사람들을 반영하지 않는다고 생각한다면, 나머지는 무시해도됩니다.

이제 많은 일을하지 않는 사람들이 상당히 자율적으로 일할 수있게 해주는 전략이 필요합니다. 그들은 이것에 헌신 할 시간이 너무 많아서 그 대부분을 지출하게하고 싶지 않습니다. 의사 소통에서. 더 관여하는 사람들은 복잡한 아이디어를 통합하고 제거해야 할 책임이 있습니다.

이를 통해 와이어 프레임 및 프로토 타입에 중점을 둔 개발 프로세스를 생각하게되었습니다.

사용 가능한 작업 항목 풀을 보유하고 사람들이 해당 와이어 프레임을 작성하도록 권장 할 수 있습니다. 이를 Tracer Bullets (Prammatic 프로그래머가 빌린 용어)로 사용하여 아이디어를 구체화하고 사람들에게 영감을 줄 수 있습니다. 거기에서 성공적인 아이디어를 프로토 타입으로 졸업 할 수 있으며, 사람들이 프로젝트에 대해 더 많이 배울 수 있도록 설계된 매우 작은 프로젝트입니다. 그 후 이제는 더 많은 팀원들에게 손을 내밀어 그 아이디어를 귀하의 시스템에 통합하기 위해 노력할 수있는 다수의 사람들에 의해 구축 된 소규모의 견고한 아이디어 섹션을 갖게되었습니다.

Kanban이이 상황에 더 적합 할 것 같습니다.

스크럼에는 맞지 않는 몇 가지 사항이 있습니다. 타이밍 또는 스코프 측정은 필요하지 않으며 개발중인 회의는 회의와 동일한 제품 비전을 가지고 있습니다. 책임과 일관성있는 짧은 계획을 따르는 것이 비즈니스 목표입니다.

Kanban은 단점없이 Scrum과 동일한 장점을 제공합니다. 빠른 프로토 타이핑이 가능합니다. 회의 전에 프로토 타입을 실행할 수 있습니다. 또한 변경 가능한 코드 및 회귀 테스트를위한 TDD를 제공합니다. 페어 프로그래밍은 지식을 전달함으로써 새로운 이민자와 비정규직을 쉽게 코드베이스에 수용 할 수 있습니다.

칸반은 또한 고유 한 장점이 있습니다. 사용자가하는 일에 대한 비전이 동시에 개발되고 있다면 Kanban이 잘 작동합니다. 그 증거는 소기업 프로그램의 성공입니다. 또한 3 명과 같은 자원 봉사자가 거의없는 날에도 칸반은 여전히 ​​잘 작동 할 것입니다. 스크럼은 가벼우면서도 노란색 테이프가 너무 많습니다.