장기 계획과 민첩성?

우리 팀은 최근 우리의 작업에 대한 거의 1 년 계획을 세우는 과정을 밟았습니다. 계획을 세 단계로 나누었습니다. 각 단계에는 몇 가지 발사가 포함됩니다.

민첩한 점에서 이것이 잘못 되었습니까? 우리는 처음 몇 단계를 제외하고 아무것도 디자인하는 데 너무 많은 시간을 소비하지 않았기 때문에 나쁜 생각이 아니라고 생각합니다. 방향을 바꿀 수 있습니다. 동시에 우리는 가까운 시선만으로 행동하지 않는 것이 좋습니다.

프로젝트가 어디로 가는지에 대한 비전을 갖는 것이 Good Thing ^TM 입니다.

그것이 일어날 것이라고 정확히 믿는 것은 아닙니다.

"전투를 준비하면서 나는 계획이 쓸모 없다는 것을 항상 알았지 만 계획은 필수적입니다."

-드와이트 D. 아이젠 하워

민첩한 방법론에 따라 접근하는 방법은 소화 가능한 조각으로 분해하고 각 조각이 소화 된 후 시력을 다시 조정하는 것입니다.

즉, 지금부터 1 년 후의 종말점은 지금 생각하는 것과 정확히 일치하지 않을 것입니다. 그러나, 당신은 당신의 명부에있는 모든 고가 품목을 다루어야하고 앞으로 나아갈 때 이해 관계자들의 참여와 행복을 유지해야합니다.

좋아, 경영진은 계획에 대한 신화를 제시했다. 나는 당신을 위해 그들이 당신을 붙 잡지 않기를 바랍니다. 보이지 않는 광경 때문에, 당신의 팀이 장기 계획에서 말하는 것과 같은 것을 성취하지 못할 것에 돈을 걸고 싶습니다. 실제로 업계 평균을 달성하면 약 2 배나 빠질 것입니다. 대부분의 조직에서 추정치가 주어지면 원하는만큼 자유롭게 당신을 이길 수있는 클럽이됩니다.

내가 냉소적이라고 생각할 것입니다. 결국 모든 사람들이 알고있는 불특정 기능 세트에 대해 모호한 시간을 전달하면 예상보다 훨씬 느리거나 빠르게 발생할 수 있습니다. 죄송하지만, 그 대부분은 사실 일 수 있지만 사람들이 그 숫자를 듣는 경향이 아닙니다. 그들은 날짜를 들었고, 한 번 말한 날짜는 당신이 말했던 것보다 더 견고한 것으로 들리는 경향이 있습니다. 또한 의사 소통의 사슬이 있으면 더 견실해질 것입니다. 그리고 당신이 말한 것에 기초하여 외부 고객에게 판매에 의해 무언가를 약속하면, 당신은 갑자기 그 수보다 유연성이 훨씬 적다는 것을 알게 될 것입니다. 그리고 시간이 걸리는 시간을 과소 평가했음을 보증합니다.

그 분명한 지적을 벗어나서, 소프트웨어 추정을 실제로 어떻게 수행 해야하는지에 대해 배우 려면 Software Estimation (소프트웨어 추정) 을 읽는 것이 좋습니다 . 당신은 당신이 잘못한 일과 다음에 더 잘하는 방법에 대해 많은 것을 배울 것입니다. (이 과정에서 내가 할 일을 과대 평가 한 이유에 대해 확신 할 수 있습니다.)

즉, 민첩성은 프로세스를 소규모 팀에 적합한 것으로 줄이는 것입니다. 프로세스를 줄이는 좋은 방법은 단기적으로 작은 계획을 세우기 위해 대규모 장기 계획을 줄이는 것입니다. 미래에 어떤 일이 일어날 지 모르기 때문에 더 정직한 경향이 있습니다. 그러나 이는 더 큰 비즈니스 요구에 맞지 않기 때문에 민첩하다고 선언하든 관계없이 때로는 더 긴 계획을 세워야합니다.

그 말로, 나는 당신이 대화 한 날짜에 관한 주요 사실을 발견 할 것을 강력히 권합니다. 불행히도 당신을 물린 마감일로 돌아올 가능성이 높습니다. 그리고 그 사실은 이것입니다. 사람들이 관심있는 날짜, 날짜 또는 기능은 무엇입니까? 이것이 내가 의미하는 바입니다. 종종 조직에는 중요한 날짜가 있습니다. 예를 들어, 회의 나 휴가가 붐비기 전에 무언가를 해보십시오. 이 경우 중요한 것은 무언가를 발표하는 것이며, 무언가가 완전한지 여부는 그다지 중요하지 않습니다. 다른 경우에는 실제로 함께 릴리스해야하는 일련의 기능이 있으며, 완전성이 정확히 발생하는 것보다 완전성이 중요합니다. 당신이 어떤 상황에 처해 있는지 발견 할 수 있다면, 팀은 다가오는 (거의) 불가피한 위기를 처리하는 방법을 계획하는 데 훨씬 더 나은 위치에있을 것입니다.

돌로 작성된 것이 아니라 진행중인 것으로 간주되는 한 계획을 세우는 것이 좋습니다.

여기서 핵심은 정기적으로 (최소 한 달에 한 번) 릴리스하고 , 사용자로부터 실제 피드백 을 수집 하고 해당 피드백을 기반으로 계획을 업데이트 하는 것입니다.

즉, 프로젝트 범위가 변경되면 계획이 변경됩니다. 이것은 사용자가 원하는 것에 대해 더 많이 배웠다는 것을 의미하기 때문에 좋은 것 입니다.

로 가정 project-management하고 agile당신이 스크럼을 의미,이 갈 수있는 정확한 방법이 될 수 없다.

에서 Scrum당신이 1 년 계획을 가지고있는 경우 1 년에 달이 있기 때문에 관점, 적어도 많은 스프린트로해야한다. 따라서 2 개의 스프린트간에 변경 가능하므로 1 년 계획이 더욱 민첩 해집니다.

A Sprint는 한 달을 초과 할 수 없으며 여기서 Team커밋은 Sprint Backlog Items의 상태가 Done됩니다.

Done여기서 중요한 단어이며, 각 Scrum Team필수 항목에는 하나의 완료, 즉 수행 할 작업이없는 정의가 있어야합니다. a Sprint Backlog Item가 완료 되면 이는 분석, 아키텍처 및 기술 문서가 작성되고 기능이 철저히 테스트되었음을 ​​의미합니다 (단위 테스트, 통합 테스트, 기능 테스트 ...).

일단 Product Backlog배치되고 항목이 맨 아래로 덜 중요하고 우선 순위가 가장 높은 항목으로 우선 순위가 결정되면 (개발자) 팀 Product Backlog Item은 각자의 경험에 따라 각각의 개발에 소요 되는 시간을 결정합니다 . 여기서 프로젝트에 1 년의 작업이 필요할 것으로 판단 할 수 있습니다. 단지Product Owner투자 수익을 담당하는 사람으로서 품목의 우선 순위를 정하거나, 최종 사용자에게 가장 중요한 것이 무엇인지 알고 있어야합니다. 또한, 팀은 기능을 완전히 개발하는 데 필요한 시간을 평가해야합니다. 여기에는 재사용이 가능한 코드가있을 수 있지만이 기능의 요구에 맞을 수 있습니다. 즉, 추가 복잡성을 피하고 항목을 가져 가지 않아야합니다. 팀이 요구 한 것보다 오래 제품 백 로그가 완벽 할 필요는 없습니다! 시스템이 개발할 것이라고 생각할 수있는 간단한 사용자 스토리 열거는 프로세스의 해당 단계에서 충분합니다.

그것은 중에있는 Sprint Planning Meeting팀은 다음을 위해 개발 될 것입니다 무엇을 저지해야한다는 Sprint따라서를 생성 Sprint Backlog. 는 Sprint Backlog에 기초 부분 집합으로 구성 Product Backlog Items것을 Team커밋은 스프린트의 끝에서 수행 할 수 있습니다. 예를 들어 50 개 품목의 제품 잔고를 고려하고 50 개 품목 모두 1 년이 소요되어야하는 경우 팀은 제품 백 로그에서 5 개 품목을 선택하고이 5 개 품목으로 스프린트 백 로그를 작성하려고 할 수 있습니다. 이 같은 5 개의 항목은 필요할 때 여러 개의 다른 항목으로 확장 / 분해 될 수 있으므로 팀은 수정 후 마음이 바뀌고 제품 백 로그에서 이전에 선택한 5 개의 항목 중 4 개의 항목 만 수행 할 수 있습니다.

Sprint Planning Meeting이 종료되면 한 달에 8 시간을 초과 할 수없는 스프린트 (Sprint)는 팀이 선택한 항목에 대한 작업을 수행 할뿐 아니라 작업 수행 방법을 계획합니다. 팀의 모든 사람들이 자신이해야 할 일을 정확히 알 수 있도록 Sprint해야합니다. 프로젝트를 위해 팀이 교차 기능하는 것이 중요합니다.

즉, 현재 상황에서 한 달 동안 지속되는 각 스프린트의 끝에서, Team최선을 다하는 모든 품목은 제품 백 로그에서 선택한 품목을 대상으로하는 모든 기능을 갖춘 기능을 제공 할 수 있어야합니다. 배송이 가능해야하지만에 따라 그렇게하는 것이 타당하지 않다면 반드시 배송해야하는 것은 아닙니다 Product Owner.

동안 그것은이다 Sprint Review Meeting가 어디에 Product Owner필요는이 있음을 소환 할 Team스프린트 동안 수행 된 것을 보여줍니다, 그리고이 모든 일이 최선을 다하고 해당하는 경우는,하지 왜 말할 필요가있는. 취소 된 작업은 다음 작업으로 다시 들어와 다음 작업에 Product Backlog사용할 수 있습니다 Sprint. 목적이 변경되었을 경우, 제품 소유자가 달리 지시하지 않는 한,이 실행 취소 된 항목은 다음 스프린트에 포함되어야합니다. 그러나 가장 중요한 것은 스프린트 중에 시스템의 목표가 변경되었지만 꼭 필요한 경우가 아니라면 중단하지 마십시오. 제품 소유자 만 스프린트를 중단 할 권한이 있습니다.

Sprint Review Meeting월간 스프린트에 대해 4 시간을 초과하지 않는 이상이 끝나면 (정확하게 기억한다면)에 가야합니다 Sprint Retrospective Meeting. 이 Sprint Retrospective(가) 필요 Team가 논의 할 수 있도록 발생하는 스크럼 팀이 등 성능 및 그에 따라 조정을 가져올을 향상시킬 수 있습니다 방법 스크럼 마스터와 무엇이 잘못되었는지 제품 소유자 (옵션)의 존재.

의 타임 박스 Sprint Retrospective가 끝나면 새로운 Sprint Planning Meeting것은 다음을 계획 Sprint하고 새로운 것을 생성해야합니다 Sprint Backlog.

의 Team는 Daily Scrum모든 팀원이 세 가지 질문에 답변하는 15 분 스탠드 업 미팅 을 유지해야합니다 (특정 순서가 아님).

1. 지난 일일 스크럼 이후에 무엇을 했습니까?
2. 다음 일일 스크럼까지 무엇을 하시겠습니까?
3. 지난 일일 스크럼 이후 발생한 문제 나 장애는 무엇입니까?

이 팀은 반드시 참석 해야 할 의무Scrum Master 는 없지만 , 팀이 Daily Scrum에서 만나고 회원이 세 가지 질문에 올바르게 대답하도록해야합니다.

Scrum Master는 다른 Scrum 팀 구성원 (Scrum Master, 제품 소유자 및 팀)이 Scrum 규칙을 준수 할 책임이 있습니다.

결국 이러한 간단한 규칙에 따라 개발 팀이 민첩해질 것입니다. 민첩성은 팀이 가능한 한 빨리, 즉 각 스프린트가 끝날 때마다 변경 사항을 따라 잡을 수있는 기능으로, 제품 소유자가 제품 백 로그에 가져온 변경 사항을 알 수 있습니다. 전체 재난과 오리엔테이션의 완전한 변경의 경우, 회사가 흡수해야하는 최대 손실은 한 달의 개발 기간이며 한 달에 약 20 일의 작업 일이 있다는 것을 고려하면 무시할 수 없습니다.

Scrum 및 Agile Software Development에 대한 자세한 정보가 필요한 경우 Scrum.org 및 해당 Scrum 안내서 를 참조하십시오 .

글쎄, 그건 꽤 답이다! 최소한 이것이 프로젝트 관리를 도와 줄 수 있기를 바랍니다.

편집 # 1

3 단계 또는 4 단계를 수행 할 계획이라고하더라도 팀은 주요 목표 관점에서 초점을 잃을 가능성이 높습니다. 1 분기 이후에 팀이 수행 한 작업을 시연하는 경우 소프트웨어 아키텍처를 중요하게 재 설계하고 재고해야하므로 20 일 이상 손실 된 작업을 재개해야하는 중요한 변경 사항이있을 수 있습니다. 민첩성의 원칙은 변경이 발생하자마자 또는 합리적인 시간 내에, 즉 스프린트의 시간 상자 인 스크럼의 경우 가능한 빨리 변경 사항을 따라 잡을 수 있도록하는 것입니다.

1. 최대한 많이 발사해야한다고 생각합니다. 소프트웨어 개발 진행에 대한 유일한 실제 피드백 / 메트릭은 프로덕션 환경에 배포 된 코드입니다. 따라서 어떤 프로세스를 사용하든 실시간 배포가 많을수록 민첩성이 높아집니다. 즉, 실제 사용자로부터 더 일찍 실제 피드백을 받고 더 빨리 적응할 수 있습니다.

2. Big Design Up Front 을해서는 안되지만 백 로그를 조정하고 보충 할 때마다 다음 스프린트의 스크럼과 Kanban / 흐름 모두 (방이있을 때) 큰 그림을 생각하는 것이 좋습니다 WIP 한도에서). 전체 (제품, 서비스 등)를 고려하면 다음에 어떤 가치가있는 작업 항목을 고려하는 것이 더 쉽습니다.

3. 큰 그림이 바뀐다는 점에 유의하십시오. 백 로그를 고려할 때마다 우선 순위를 조정하는 등 큰 그림을 변경하는 것도 고려하십시오. 특정 고객 및 전체 시장의 요구를 포함하여 시간이 지남에 따라 상황이 변경됩니다. 큰 그림에는이를 반영해야합니다. 계획을 세울 때뿐만 아니라 백 로그를 보충 할 때마다 우선 순위가 현실과 일치 할 수 있습니다.

요컨대, 조사하고 적응 할수록 민첩성 이 높아진다고 생각합니다 .

큰 그림 계획은 그리 오래 걸리지 않으며, 스프린트를 정의 할 때 큰 프로젝트가 큰 그림을 염두에 두는 것이 중요합니다. 그렇지 않으면 스프린트에서 찍은 바로 가기가 나중에 문제를 일으킬 수 있습니다.

당신은해야합니다 :

1. 마스터 플랜 (바람직하게 마감일이 첨부되지 않은 계획)을 갖추십시오.

2. 스프린트를 정의 할 때 스프린트가 큰 그림과 일치하는지 확인하십시오. 이것이 항상 스프린트에 필요한 것에 대한 아이디어를 바꾸는 것을 의미하지는 않습니다. 스프린트를 정의 할 때 큰 그림을 조정해야하는 경우가 있습니다. 한 가지 또는 다른 큰 그림 계획과 스프린트는 스프린트로 들어가는 서로 일치해야합니다.

3. 당신이 갈 때 마스터 플랜을 조정해야합니다. 일하면서 배우게됩니다. 새로운 기회가 생길 것이며 계획의 갈등이 생길 것입니다. 이동 중에도 마스터 플랜을 즉시 조정할 수 있습니다. 그러나 거의 항상 스프린트간에 다시 방문해야합니다-마지막 스프린트의 교훈을 통합하고 다음 스프린트가 큰 그림과 조화를 이루도록하십시오.

백 로그와 큰 프로젝트 계획이 별도의 구조 인 것이 가장 좋습니다. 대규모 프로젝트 소유자는 마스터 계획을 컨텍스트를 유지하기 위해 계층 적 개요 형식으로 유지 한 다음 기능에서 작업을 가져와 백 로그를 공급하여 다음 스프린트를 공급할 수 있습니다.

마스터 계획과 달리 백로 그는 다른 팀 구성원이 추가 할 수 있습니다. 백 로그 항목과 큰 그림 계획을 조화롭게 유지하는 것은 주 프로젝트 소유자의 몫입니다. 때로는 백 로그 항목을 조정하고 때로는 큰 그림 계획을 조정하는 경우도 있습니다.

이 방법은 민첩성의 힘을 유지하고 큰 그림 계획을 통해 주어진 시간에 프로젝트의 모든 요소를 ​​최상의 상태로 정렬하는 힘을 유지합니다.

짐

여기에 애자일 안티 란 트의 짧은 형태를 추가하겠습니다.

애자일은 대규모 프로젝트, 특히 미래 개발의 기초가 될 라이브러리와 프레임 워크를 구축 할 때 매우 파괴적 일 수 있습니다. 초기 단계에서 정말로 중요한 관심사는 "내 디자인이 내년에 제공해야하는 기능을 지원할 것인가"입니다. 대부분의 애자일 전략은 이러한 종류의 미래 사고를 허용하지 않으므로 프로젝트 실패 지점이 생성됩니다.

나는 이것에 의해 단지 화상을 입었 기 때문에이 시점에서 약간 아프다. 핵심 라이브러리 중 일부를 다시 작성하고 있습니다. 첫 번째 단계가 완료되었으며 스프린트의 기능 목표를 달성했습니다. 모두 매우 민첩합니다. 그런 다음 동적 로딩 기능을 추가하기 위해 탑승했습니다. 그러나 이전에는 동적 로딩이 없을 것이라고 가정했기 때문에 약 6 주 동안 정체당했습니다. 이미 있던 내용을 다시 작성하고 해결하는 데 많은 시간을 낭비했습니다. 최악의 부분은 동적 로딩이 시작시 사양에 있다는 것입니다. 초기 작업에서 미래의 모든 요구 사항을 염두에두고 민첩한 관행이 나쁜 것으로 간주하는 '큰 디자인 작업'을 수행 한 후 며칠 내에 기능을 구현할 수있었습니다.

교훈은 기꺼이 버릴 작은 물건에 민첩성을 사용하는 것입니다. 때로는 좋을 수도 있습니다. 그러나 이것이 진정한 소프트웨어 개발 방법이 아닙니다. 위험이 높거나 수명이 긴 기초 코드를 작성할 때는 큰 디자인을 수행하십시오.