일관된 변화를 고려할 때 계획 기간이 얼마나 짧습니까?

변경은 드문 일이 아니며, 요구 사항의 변경, 워크 플로의 사양 변경입니다. 나는 변화가있을 것이라는 점을 인정했지만, 변화가 일어날 것이라는 것을 알면 계획 기간이 얼마나 짧은가? (정의가 권장됩니다)

• 반복 (2-4 주)?
• 일주일?
• 2-3 일의 기간?
• 하루?
• 하루에 1/2?

회사가 현재 계획보다 먼저 '계획'1 [시간 간격 (위에서)]으로 가정하여 계획이 다음과 같이 들린다 고 가정합니다.

"[오늘 아침 / 오늘 / 이번 주 등] 에서이 작업을 하고 [오늘 오후 / 내일 / 다음 주 등]에서 작업 할 것 입니다 .

또한 초점 / 방향의 변화는 매 초마다 세 번째 간격마다 일관되게 발생한다고 가정합니다.

저는 Scrum Practitionner이므로 사용을 제안합니다.

1. 반복 기간을 정의하십시오. 스타트 업에서는 2 주 반복, 대기업 프로젝트에서는 1 개월 반복
2. 반복 시작시 제품 백 로그에서 개발할 기능 중에서 선택하십시오. 제품 관리자는 물론 반복 계획을 변경할 권리가 없습니다.
3. 반복 계획이 아닌 제품 백 로그에서 변경이 발생합니다. 그러므로 당신은 당신의 일에 영향을 미치지 않습니다.

스크럼 에 대한 자세한 내용

더 큰 그림을 모든 디테일에서 잃어 버리는 경향이있는 경우가 많으며, 결국 바퀴를 돌리게됩니다. 그것은 큰 위험입니다.

XP (또는 Scrum)를 사용하는 것이 좋습니다. 즉, 각 반복이 시작될 때 한 번만 계획해야하며 1-2 주 길이 인 경우 가장 효과적입니다.

Kanban 에는 필요에 따라 계획을 세우는 매우 멋진 것들이 있지만 개인적으로 Kanban은 개발을 처음부터 시작할 때보다는 유지 관리 및 지원 상황에 더 적합하다고 생각합니다.

나는 이런 식으로 세분화합니다.

1. 중요한 프로젝트 / 애플리케이션 개발-1 주일
2. 간단한 일회성 향상 기능이 목록에 포함되어 우선 순위가 매겨지며 각 기능은 반나절 또는 하루 종일 처리됩니다.
3. 버그 수정은 일반적으로 우선 순위가 높으며 # 2와 유사한 프로세스를 거치지 만 때로는 훨씬 빨리 수정 될 수 있습니다.

여기서 중요한 요소는 주어진 작업에 대해 실제로 얼마나 많은 계획을 세울 수 있습니까? yadda, yadda, yadda를 수행하는 새로운 웹 사이트를 시작하면 버그 수정보다 더 많은 계획이 있습니다. 누가 미리 버그를 계획합니까? 부서 관리자는 그들이 무언가를 잊어 버렸고 분기보고가 끝날 때 그것을 필요로한다는 것을 알게되었습니다.

매주 반복하는 시간은 10 시간이거나 50 일 수 있습니다. 모든 다른 항목이 즉각적인 양에 따라 다릅니다. 작은 추가 작업을 위해 프로젝트를 따로 보관해야하는 경우 경영진이 요청할 때 시간 제약을 이해하는 것이 훨씬 쉽다고 생각합니다. 그들이 그 작은 변화가 불필요하다고 식별했을 때 나는 기쁘다. 그리고 나는 yadda-yadda-yadda 웹 사이트에서 계속 일해야한다.