날짜 기반 개발 모델에 대한 조언

Question

누구든지 날짜 기반 개발 환경에서 작업하는 것에 대한 조언이 있습니까? 본질적으로, 우리는 8 주마다 RIA를 갱신하고 있습니다. 저는 5 명 미만의 개발자로 구성된 작은 팀에서 일하므로 작은주기에 맞지 않는 장기적인 기능을 관리하는 방법에 대해 우려하고 있습니다. 또한, 나는 끊임없는 위기 상황에 처하게되는 것에 대해 우려하고 있습니다.

Answer 1

규칙 1. 지연 기능.

(1) 다음 릴리스로 연기 한 다음 (2) 이유를 파악합니다.

"밀어 내기", "연장 작업"및 "더 똑똑하지 않게 작업하는"작업은 실제로 많이하지 않습니다. 요점은 당신의 계획에 대해 현실적입니다.

1. 계획은 미래를 예측하기위한 시도입니다.

2. 미래를 예측할 수 없습니다.

3. 따라서 계획이 잘못되었습니다. 항상.

"계획", "약속"및 "고객 기대"에 대해 놀래키다가 생각해보십시오.

귀하의 목표는 사용자가 사용할 수있는 것보다 빠른 속도로 기능을 제공하는 것입니다.

2 주 단위로 노력하십시오. 테스트를 거친 통합형, 즉시 사용 가능한 생산.

처음 4 번의 스프린트가 끝나면 8 주 후에 출시 준비가 완료됩니다. 당신은 일을 지었고, 연기 된 것을 만들 것이고, 마지막에 연기 된 목록으로 끝낼 것입니다.

많은 새로운 기능이 추가되어 사용자가 일반적으로 변화의 속도에 괴롭습니다. 사용자는 2 주 스프린트를 공개하지 않을 것입니다. 너무 자주 릴리스하면 사용자가 볼 수있는 변경 속도가 느려지도록 기능을 함께 더 큰 릴리스로 묶어야한다는 사실을 알게됩니다.

여전히 많은 작은 사이클을 수행해야합니다. 더 큰 잔고의 작은 부분 집합을 짓는 2 주간 스프린트를 목표로하십시오.

각 작은주기를 해제하지 마십시오.

Answer 2

8 주 .... 1 주 또는 2 주 릴리스가있는 일부 상점과 비교하면 ... 운이 좋다. 몇 가지 권장 사항 :

• 각 릴리스 후에 클라이언트/비즈니스 소유자의 도움을 받아 maint/bug 수정 프로그램의 우선 순위를 지정하고 목록 맨 아래에서 작업하십시오 ...(마지막 순간에 거기에 있어야 할 때까지 간단하게 들립니다.)
• 주기 'D'에 대한 개발은 계획과 관련하여 실제로주기 'C'에서 시작해야하며 적절한 품질 관리를 보장하기 위해 전달하기 1-2 주 전에 종료해야합니다 발견 된 문제를 해결하는 것
• 배달 날짜를 밀어 넣는 질문에 항상 '무언가'가있을 것입니다. - 범위를 줄이거 나 날짜를 지키십시오.
• 큰 배달을 작은 것으로 분해하고 홍보하십시오. 이 증분 작업으로 인해 추가 작업이 추가 될 수 있지만 품질 보증/버그와 관련된 문제와 위험은 줄어 듭니다.
• 중요한 계측 계획 및 계획 수립 진창을 보여주는 s