폭포에 중점을 둔 사람들에게 민첩한 프로젝트를 표현하는 방법 [닫기]

우리 팀은 프로젝트 계획에서 개발 노력을 대표하도록 요청 받았습니다. 우리의 업무에 만족하지 못하거나 제공 능력에 의문을 제기하는 사람은 없으며, 프로젝트 계획에 대한 IT 소의 전화에 참여하고 있습니다. 문제는 우리가 민첩한 팀이며 공식 프로젝트 계획의 관점에서 우리의 작업에 대해 생각하지 않았다는 것입니다.

우리가 다음에 무엇을하고 있는지에 대한 일반적인 아이디어를 가지고 있지만 반복을 계획 할 때까지 100 % 확신 할 수 없습니다. 지금까지 우리 팀은 대부분 진공 상태에서 작업했으며 외부에 방법론이나 지표를 제시 할 필요가 없었습니다. 우리는 Extreme Programming 에서 배우는 대부분의 관행을 따릅니다 .

우리는 분기 별 계획 회의를 개최하여 분기 동안 진행할 이야기에 대한 일반적인 아이디어를 얻습니다. 즉, 우리의 이야기는 3x5 카드에 기록되어 있으며 작업이 시작될 때에 만 추정됩니다. 추정 후 우리는 Team Foundation Sever에 이야기를 기록합니다 . 반복하는 동안 스토리에 코드를 첨부하고 완료되면 스토리를 완료된 것으로 표시합니다. 이 데이터를 통해 번 다운 및 속도 차트를 생성 할 수 있습니다. 가장 중요한 것은 우리가 씹을 수있는 것보다 더 많이 물지 않게하는 반복의 평균 속도를 알고 있다는 것입니다.

개발 방식을 수정하고 싶지는 않지만 워터 폴에 익숙한 사람 만 이해할 수있는 보고서에 개발 활동을 소개하고자합니다. 에서 어떤 애자일 프로젝트 계획 봐처럼 하는가하면 , 켄트 맥도날드는 민첩하고 폭포 프로젝트 계획의 차이점을 세우고 좋은 작업을 수행합니다. 그는 소모품 총알의 차이점을 지정합니다.

• 민첩한 프로젝트 계획은 기능 기반
• 애자일 프로젝트 계획은 반복으로 구성됩니다
• 민첩한 프로젝트 계획은 기간에 따라 세부 수준이 다릅니다.
• 애자일 프로젝트 계획은 팀 소유

차이점을 설명 할 수있는 것이 좋지만 데이터를 제시하는 가장 좋은 방법은 무엇입니까?

반 반신 애자일 선언문을 보여주세요 .

그것은 폭포 방법 과 비교 하여 애자일 시스템이 무엇인지에 대해 확실히 알려줍니다 .

프로세스 및 도구에 대한 개인 및 상호 작용 및
해당 개인 ( '자원'이라는 용어를 선호)이 상호 작용하는 방식을 제어하기위한 필수 프로세스 및 도구가 있습니다.

소프트웨어가 포괄적으로 문서화 되어있는 한 포괄적 인 문서에 대한 작업 소프트웨어

물론 엄격한 계약의 경계 내에서 계약 협상을 통한 고객 협업
및 엄격한 변경 관리 대상

변경에 대응하기 위한 세부 계획이 마련되어 있고 계획
에 따라 계획에 따라 변경에 대응

나는 이것을 한 번해야했다. 팀은 고객이 외부 제 3 자 ( "감사 자"라고 함)가 원하는 Agile을 수행하기를 원했으며 폭포 보고서를보고 싶어했습니다.

우리가 거짓말 을 할 수있는 중요한 이유 는 타사가 실제로 신경 쓰지 않았기 때문에 확인란을 선택하기를 원했기 때문입니다. 고객이 만족하고 팀이 만족했다면 "감사 자"는 최종 상자를 체크 아웃하기 전에 되돌아 가서 우리가 준 보고서를 거의 볼 수 없었습니다.

타사가 중요하고 실제로 폭포를 사용하고있는 경우이 작업을 수행하지 마십시오 . 감사관이 귀하가 민첩하다는 사실을 알고 서류를 업데이트하지 않은 경우 거짓말을 할 수 있습니다.

너 뭐하니? 거짓말 하지만 하얀 거짓말.

• "기능이 있어야 함"요구 사항으로 기능을 다시 표현하십시오.
• 귀하의 작업은 반복에 있으며 반복은 일반적으로 X 주 이상 걸리며 폭포 계획은 일반적으로 주 단위로 일을보고 싶어하므로 큰 문제는 없습니다. 각 반복의 끝에 마일스톤으로 레이블을 지정할 수 있습니다. 이정표는 폭포입니다. 반복에는 테마 (또는 관련 Epic)가있는 경향이 있으므로 중요 시점에 테마 / 에픽 제목을 붙일 수 있습니다 (예 : 21/11 GUI 완료).
• (번 다운 / 업 차트에서) 속도를 계산하고 평균적으로 스토리 포인트가 (적어도 현재 속도에서) 얼마나 많은 시간을 나타내는 지 계산하면 작업 시간이 줄어 듭니다. 거칠고 부정확 한 경우가 많지만 어느 정도 의미가 있습니다.
• 계획은 시간대에 따라 세부 수준이 다릅니다. 기본적으로 폭포와 동일합니다. 폭포 계획은 잠재 고객에 따라 세부 사항이 다를 수 있습니다.

• 애자일 계획은 팀이 소유합니다. 폭포수 계획은 프로젝트 관리자가 소유합니다. 프로젝트 관리자가 이미있을 수 있으며 아마도이 번역을 수행하고있을 것입니다 . 번역 된이 문서의 소유권을 가져 와서 문서 때문에 비가 올 수있는 측면에서 팀을 보호해야합니다. 애자일 프로젝트 또는 워터 폴 프로젝트 관리자가 팀을 방해하지 않도록 팀을 보호하는 역할을합니다.

• 물론 다음 반복 작업을 실제로 알지 못하지만 대략적으로 수행중인 작업을 알고 있습니다. 당신은 그것에 대한 느낌을 가지고 있으며, 여전히 반복 후에 더 거칠습니다. (이것은 반복 레이더라고 들었습니다). 거짓말하고 말하십시오. 반복 레이더에없는 스토리 카드에 대해 치아를 통해 거짓말을하고 어딘가에 넣으면됩니다. 프로젝트 계획에 너무 많은 업데이트를 제출하지 않아도되기를 바랍니다. 그렇지 않으면, 당신이 말한 것을하지 않았다는 것을 알게 될 것입니다.

기본적으로 이것은 고통입니다. 번역은 많은 시간이 소요됩니다. 많이해야한다면 자동화하십시오.

첫 번째 질문은 비즈니스가 실제로 원하는 것입니까? 일부 비즈니스는 민첩한 스프린트가 Gantt 차트로 표현 / 분류되는 것을보고 매우 기뻐합니다. 스프린트를 실제로 이해하고 정기적으로 변경 될 수있는 사람에게는 이치에 맞지 않을 수 있지만, 요구하는 사람들에게는 친숙합니다. 그런 다음 간트 차트와 함께 번 다운 등을 제시하십시오.

우리는 비슷한 것을 겪었고 결국 (Agile이 작동하는 경우) 자체 판매됩니다 (그렇지 않으면 왜하지 않습니까?). 사람들은 "노력"을 이해하기 시작하고 특정 팀이 2 주 스프린트에서 40 노동 포인트를 "버닝"할 수 있으며 실제로 이러한 노력 포인트를 추정하는 데 상당히 능숙합니다. 그들이 혜택을보고 나면 프로세스를 나머지 비즈니스에 판매합니다. 그러나 요점은 당신이 결코 반격 할 것이므로 누군가에게 절대로 그것을 강요 할 수 없다는 것입니다.