우리는 공식적인 프로젝트 관리 시스템이 필요한 4 인 개발팀을 보유하고 있습니다. 스크럼 (Scrum)과 칸반 (Kanban)에 대해 전반적으로 이해하고 있지만, 시도가 끝날 때까지는 진정으로 이해하기 어렵습니다. 우리는 몇 주 동안 하나를 시도해 본 다음 다른 곳으로 전환하는 사치를 가지지 않아서 비슷한 상황에있는 누군가가 자신에게 더 잘 맞는 이유와 이유를 생각할 수 있기를 바랬습니다. 또한 제대로 작동하는 개발 관리 시스템은 유용 할 것입니다.스크럼, 칸반 또는 기타 4 명 개발자 팀
또 다른 참고 사항 : 물론 팀이 성장할 가능성이 있으므로 잘 확장 된 시스템이 필요합니다.
또 다른 참고 : 우리는 또한 쓴 중앙 도서관을 기반으로 모두 Windows의 세 가지 별도의 소프트웨어 응용 프로그램에서 작동
이스크럼과 칸반은 모두 프로세스 "해골"입니다. 어느 쪽도 소프트웨어 개발과 관련이 없습니다. 스크럼은 소프트웨어 개발 조직에 의해 대중화되었지만 소프트웨어 프로젝트 관리 기법보다는 일반적인 관리 기법으로 자리 매김되었습니다. 칸반 (Kanban)은 제조 과정에서 출현했으며 처음에는 유지 보수 팀이 소프트웨어 개발에 적응했습니다. Scrum과 Kanban은 작업을 수행하는 팀을 통해 작업 단위의 흐름을 관리하고 예상 작업이 더욱 정확해질 수 있도록 작업 흐름의 속도를 측정하며 병목 현상을 눈에 잘 띄게하여 해결할 수 있도록합니다.
소프트웨어 개발과 관련이 없기 때문에 Scrum과 Kanban을 사용하는 팀은 점진적으로 반복적으로 소프트웨어를 릴리스하고 개선하는 데 도움이되는 프로세스에 소프트웨어 개발 방법을 추가합니다. Scrum이나 Kanban 프로세스에서 작업하든간에 대부분의 팀은 XP의 기술 관행과 Crystal의 반사 관행을 채택합니다.
XP는 기본적으로 단일 팀에 적용되는 스크럼과 "높은 품질"의 코드와 프로그래머가이를 달성 할 수있는 방법에 대한 지침을 제공합니다. Crystal Clear는 작은 공동 배치 팀에도 적용되지만 프로그래밍 관행에 대해 더 융통성이 있지만 XP 관행을 권장합니다 (과정을 설명하는 책은 우수하고 소중한 조언으로 가득 차 있습니다. 스크럼 팀은 또한 대개 Crystal의 반사적 인 관행을 채택합니다. 즉, 모든 중요한 이정표를 마친 후에 정기적 인 "심장 박동"회고전과 큰 회고전을 채택합니다. Kanban은 지속적인 반영과 개선이 필요하지만 일부 팀은 회고를 사용합니다.
소규모 프로그래밍 팀에서 점진적/반복적 프로세스를 적용하려면 XP는 기술적 기능을 위해 막대를 상당히 높게 설정하고 문서화가 잘되어 있기 때문에 시작하는 것이 좋습니다. kanban-dev 메일 링리스트와 다른 곳에서 소프트웨어 개발 업계의 다른 분야에 지속적 흐름과 Kanban이 가장 잘 적용되는 방식은 여전히 논쟁 중입니다.
프로세스를 개선하고 특정 상황에 맞게 정기적 인 회고를 수행하는 것이 좋습니다.
가장 중요한 부분이다 (그래서 난 당신이 네 개의 프로젝트를 말할 수있을 것 같아요) 지속적인 개선을 촉진하는 반성/회고 적 메커니즘을 갖추고 있습니다. 몇 가지 프로세스 모델로 시작하여 시간이 지남에 따라 이 필요합니다. 그만한 가치가없는 일을 그만 두십시오. 높은 가치를 가져 오는 일을 계속하십시오. 가치가 있거나 특정 문제를 해결할 수 있다고 생각되는 새로운 것을 시도하십시오.
무엇이 당신입니까? 어떤 방법론이 가장 적합할까요?
예. 내가 언급 한 것에 국한하지 않고 – Karim
나는 린이나 XP를 들여다 보았다. 한 번에 여러 프로젝트를 작업하고 있기 때문에 스크럼을 사용하는 것은 불행한 일입니다. 나는 당신이 당신의 필요에 맞게 스크럼을 적용 할 수 있다고 생각하지만, 스크럼은 한 번에 하나의 프로젝트에 가장 잘 작동한다고 생각합니다. 스크럼을 자신의 필요에 맞출 수 있다면 스크럼을 사용하는 것이 좋을 것입니다. 왜냐하면 팀이 성장하고 있다고 지적하기 때문입니다. 정확히 어떤 방법론이 팀에 가장 적합한 지 정확히 말하기는 어렵습니다. 그러나 고려해야 할 문제는 다음과 같습니다. – jAST
- 팀 크기 (및 성장 확률) - 팀이 분할되면 어떻게됩니까? - 팀은이 프로젝트를 얼마나 오래 할 것입니까? - 프로젝트에서 생명과 돈을 잃는 "위험한"방법은 무엇입니까? - 얼마나 자주 전달할 것으로 예상됩니까? - 어떻게 관리하고 있으며 관리자가 새로운 접근 방식을 받아 들일 의향이 있습니까? 답변해야 할 질문은 많습니다. 그러나 가장 중요한 것은 : 방법론을 사용하고 싶습니까? 그것은 당신의 일을 향상시킬 것입니까? – jAST
정형화 된 시스템이 해당 팀 규모로 부과하는 모든 오버 헤드에서 많은 이익을 얻지 못합니다. 대신 모두가 서로 청취하고 블록이 제거되도록 a good management technique을 시도하십시오.
잘 모르겠습니다. 공식화 된 시스템은 현재 어디에 있는지, 누가 무엇을하고 있는지를 모든 사람에게 알리는 이점이 있습니다. 나는 "좋은 관리 기술"과 "형식화 된 시스템"사이에 훌륭한 라인이 있다고 생각합니다. – Karim
중소 팀을 위해 Scrum 작품을 생각합니다. XP와 비교하면 약간의 세부 사항이 남기 때문에 XP에서 빌리거나 의미있는 것을 할 수 있습니다. 선택하는 방법론, 닭 (고객/관리자/이해 관계자/도메인 전문가) 역할의 역할을 고려해야합니다. 때로는 스스로 역할을 수행해야하지만, 도메인에 대한 지식이있는 외부의 페이스 카가 있기 때문에 많은 민첩한 방법론이 효과적입니다.
기타 주요 측면은 팀 간의 커뮤니케이션 수준과 품질 보증 메커니즘의 일부 형태입니다. 같은 건물에 있지 않으면 쌍 프로그래밍을하기가 어렵습니다. Scrum은 스프린트주기 내에서 기능을 수용하려고 시도하며 XP는 단위 테스트, 코드 검토 및 지속적인 통합을 사용하여 하루 내에 통합 된 기능을 얻으려고합니다.
"XP는 그 날 안에 통합 된 기능을 얻으려고합니다." XP를 보완하기 위해 XP는 시스템을 항상 통합하도록 노력합니다.단일 기능 (XP 용어로 "이야기"라고도 함)을 개발하는 데는 보통 하루 이상 걸릴 수 있습니다. 쌍은 기능을 개발하는 동안 자주 체크인 할 것이고 XP 관행은 체크인 기능으로 기존 기능이 손상되지 않고 시스템이 항상 통합 된 배치 가능한 상태에 있음을 확인합니다. – Nat
스크럼을 사용하는 회사가 점점 더 많아지는 것처럼 보입니다. 그 이유는 짧은주기가 더 빠른 피드백을 제공하기 때문인 것으로 보인다. – Halvard
@Halvard, 나는 14 일간의 달리기에 대해 매우 회의적이다. 스크럼은 크런치 한 폭포입니다. 필자는 14 일간의 스프린트를 수행하는 사람들이 XP가 테스트 우선, 리팩토링 및 페어 프로그래밍과 같은 모든 보호 장치없이 XP 반복 개발을하고 싶어한다는 의혹을 갖고있다. 팀이 요구 사항 수집, 설계, 코딩, 테스트를 수행하고 14 일 만에 "완료 됨"상태가되는 방법은 무엇입니까? 내 추측으로는 스프린트 백 로그 및 테스트가 생략된다는 것입니다. –
나는 공통된 라이브러리를 공유하는 두 팀에서 그 주사위를 굴려 더 큰 팀과 함께 일했습니다. 스크럼은 우리에게 유리했습니다. 이제 저는 6 명의 회원으로 구성된 팀과 함께 일하고 XP를 사용하며 잘 작동한다고 생각합니다. 첫 번째 팀은 제품을 개발했으며 '우주 공간'의 영향은 그다지 크지 않았습니다. 그래서 더 긴 반복이 잘 작동했습니다. 아니 우리는 고객 프로젝트를 개발하므로 짧은 출시주기가 더 좋습니다.
그러나 SCRUM과 XP는 그 이상입니다. 이제 우리는 TDD와 Pair-Programming (둘 다 XP 세계에서 더 많이 사용)을 사용합니다. 우리는 또한 더 많은 SCRUM처럼 매일 일어 서서 회의를했습니다. 그래서 우리는 프로젝트와 상황을 위해 XP와 SCRUM을 채택했습니다.
짧은주기 (1 주)와이주기에 대한 리뷰로 시작하겠다. 팀에서 새로운 방법론을 채택하는 데는 다소 시간이 걸리지 만, 회원들이 기꺼이 배우고 변경할 수 있다면 효과가 있습니다.
코딩과 관련된 소프트웨어 또는 코딩과 관련이 없으므로이 질문을 주제와 관련이없는 것으로 보겠습니다. – sevenseacat