웹 사이트 샵에 어떤 민첩한 방법론을 권하고 싶습니까?민첩한 방법론은 무엇입니까?
우리는 다양한 작은 프로젝트와 큰 프로젝트를 가지고 있으며, 팀은 프로젝트 간 프로젝트이며 멀티 태스크입니다. 우리는 실제로 스크럼에 관심이 있지만 현재 많은 시간을 차지하는 소규모 프로젝트 (2 주 미만)에는 적용되지 않는 것으로 보입니다.
우리 상황에서 민첩한 원칙을 구현하기 위해 어떤 대안이 있습니까?
정식 구조 (평가, 사용자 스토리 계획, 작업 계획, 일상 회의, 회고)가 우리가 이전 방법에서 더 민첩해질 수있게 도와주기 때문에 스크럼으로 시작했습니다. 이제 우리는 3 회의 계획 및 회의가 아침 회의에서 작업/사용자 스토리 기반으로 수행 될 수 있음을 확인했습니다.
각 사용자 스토리에 대한 색인 카드에는 핀 보드와 핀이 있습니다. 게시판은 시작되지 않았으며 진행 중이며 완료되었습니다. 우리가 해체 할 때까지 하루도 더 걸리는 일이 없도록하고, 매일 아침 모임에서 각 사용자 스토리를 세분화합니다. 이것은 우리를 민첩하게 유지하여 사용자 스토리로서의 "기능"목록을 우리가 시간을 작업으로 분해하지 않고 변경할 수있게합니다. 이를 통해 2 주짜리 프로젝트는 큰 프로젝트와 동일한 방식으로 쉽게 처리 할 수 있습니다.
속도를 측정하기 위해 우리는 주말에 얼마나 많은 작업을했는지보기 위해 카드를 계산합니다. 단점은 릴리스 계획과 속도 추정이 스크럼만큼 정확한 것은 아니지만이 하이브리드 XP 방법론은 개발자가 준비가되었을 때 작업에 집중하고 미팅에서 너무 많은 시간을 낭비하지 않도록 도와줍니다.
더 작은 작업을 사용하면 소스 제어에 대한 더 많은 일반 커밋을 촉진하고 빌드 서버 및 배포 스크립트와 결합하여 응용 프로그램에서 하루에 한 번씩 진행할 수 있으므로 클라이언트에서 피드백을 얻으 려 할 때 유용합니다. 우리는 또한 매주 회고를 가지고 있으며 애매한 컨설턴트에게 매주 3 개월 정도 고용되어 올바른 길을 계속 지키고 있습니다.
프로젝트 당 하나의 방법론을 시도하고 잘 작동하는지 확인하십시오.
스크럼은 확실히 2 주 프로젝트에 적용될 수 있습니다. 스프린트 기간을 줄이거 나 스프린트 당 여러 프로젝트를 수행 할 수 있습니다.
또한 프로젝트에서 사용할 다양한 방법론의 부분을 선택하거나 선택할 수 없다는 것은 없습니다.
그런 작은 프로젝트에서는 스크럼이 작동하지 않습니다. 그것의 정의에서 scrum 스프린트는 2 주 오래 있기 때문에. XP의 변형 또는 Extreme Programming이 훨씬 더 적합 할 것입니다. 그러나 복잡한 프로젝트 인 경우 2 주 만에 프로젝트를 완료하는 것은 개발자가 집중해야 할 필요가 있습니다.
또한 선택한 방법에 관계없이 팀을 잘 맞게 프로세스를 수정하는 것을 두려워하지 마십시오.
나는 당신이 현재의 팀이 어떻게 작동하는지보기 위해 몇 가지 방법론을 말하려고 노력해야한다고 생각합니다. 어떤 사람은 XP 또는 다른 새로운 방법론을 시도하기가 쉽지 않습니다. 또한 작고 큰 프로젝트에 대해 다른 방법론을 시도해야합니다. 2 주 프로젝트의 방법론은 변경 될 수 있습니다. 2 주 프로젝트에서 1 반복을 할 수 있으며 시작시 2 주 전체를 계획 할 수 있습니다. 이는 2 년 프로젝트에서는 불가능합니다.
일반적인 프로젝트가 작더라도 스크럼을 사용하면 두 번째 시간이 걸립니다. 당신의 스프린트를 2, 3, 4 일 동안 봐라. 스크럼의 "많은 피드백"을 프로젝트에 통합 할 수 있습니다.
고객은 2 주 동안 무언가를 작업하고 싶지 않습니다. 결국 고객이 "오, 그게 우리가 한 일이 아니야!"라고 말하게하려고합니다.
Ken Schwaber의 짧은 talk about Scrum을 IT Conversations에 들으며 멋진 Podcast가 가득합니다.
그런 다음 나는 Tim McKinnon의 talk on Agile을 InfoQ에서 보았으며 훌륭한 협상과 인터뷰로 가득합니다.
HTH.
환호,
롭
나는 TDD (테스트 주도 개발)를 사용하는 것이이 프로젝트의 혜택을 많이 제공 할 수 있다고 생각합니다. 그것은 개발과 디자인을 도울 것입니다. 단위 테스트는 구현 세부 사항 및 설계 결정을위한 "마이크로 문서"가 될 수도 있습니다.
스크럼을 권하고 싶습니다.
스크럼의 몇 가지 아이디어는 일상 회의에서 얼굴을 마주 보며 일할 수도 있지만, XP에서 쌍으로 프로그래밍하는 것과 같은 개념은 소규모 프로젝트에 더 유용 할 것이라고 생각합니다. 그리고 진정한 "scrummists"는 2 주 간격의 시간을 변경하는 것을 좋아하지 않습니다. – stephenbayer
사실 Ken Schwaber (스크럼의 창시자 중 한 명)는 자신의 책에서 팀의 요구에 맞게 스크럼 프로세스 (스프린트 지속 시간 포함)를 조정해야한다고 구체적으로 말합니다. –
나는 현재까지 나의 가장 짧은 공식 프로젝트가 5 주 동안 있었음을 인정해야하며, 상당히 엄격한 XP 방법을 사용했다. 보통 엄격한 스크럼으로 3 ~ 6 개월 프로젝트를 진행합니다. 나는 마이크로 (2 주) 프로젝트를 수행하지 않았다. 나는 그들을 혼합하는 것보다는 엄격하게 방법론을 따르려고 노력한다. – stephenbayer