애자일 프로젝트 관리에 대한 궁극적인 소개

브리핑

당신은 "Widgets International"의 얼굴을 영원히 바꿀 회사의 가장 최신의 가장 위대한 이니셔티브를 전달하는 책임자입니다. 고객의 참여를 유도하고 마음을 사로잡고 동료의 삶을 더 쉽게 만들고 회사의 수익을 수백만 달러로 만드는 소프트웨어 프로젝트입니다. 많은 기대와 열정, 설렘, 기대가 있습니다. 비즈니스가 혜택을 누릴 수 있도록 최대한 빨리 완료해야 합니다. 회사의 미래 성공은 당신에게 달려 있습니다. 모든 시선은 당신에게 있습니다. 당신은 실패할 수 없습니다.

처음에는 “대단하다, 도전할 준비가 됐다. 이 일을 끝내자!” 잠시 멈추고 뒤로 물러나 "좋아, 우리가 이것을 어떻게 할까?"라고 생각합니다. 동료 및 동료들과 이야기하기 시작합니다. 모범 사례 소프트웨어 개발 및 프로젝트 관리 기술을 찾는 데 시간을 할애하지만 옵션과 접근 방식은 셀 수 없이 많습니다. 약어와 방법론이 많이 있습니다. 눈에 띄는 사람은 정상에 올라갑니다. 의심이 들어옵니다. 어느 것을 사용해야 할까요? 성공을 어떻게 보장할 수 있습니까? 잘못된 결정을 내리면 어떻게 됩니까?

소프트웨어 프로젝트 관리와 관련하여 수많은 의견이 뒷받침하는 다양한 옵션이 있습니다. 방 모퉁이에서 속삭이는 목소리, "이렇게 해보세요." 다른 사람들은 "이것이 유일한 방법입니다"라고 외칩니다. 나머지 사람들은 "전혀 관리하지 말고 계속 진행하십시오."라고 속삭입니다. 실제로 그 모든 목소리는 어느 정도 진실을 말하고 있습니다. 그러나 중요한 것은 귀하의 요구 사항, 팀, 비즈니스 및 고객에게 적합한 것이 무엇인지 알아내는 것입니다.

장면 설정

소프트웨어 프로젝트 관리가 세 가지 진영 중 하나에 정확히 자리 잡았던 때가 있었습니다. 통제와 거버넌스를 유지하기 위한 구조를 제공하면서 실행 및 제공 방법에 대한 결정을 내릴 수 있는 무거운 프레임워크가 있었습니다. 긴 프로젝트를 계획하고, 모든 요구 사항을 이해 및 이행하고, 복잡한 시스템을 설계 및 승인하고, 많은 코드를 작성한 다음 테스트해야 하는 폭포수와 같은 규범적인 순차적 방법론이 있었습니다. 시각). 마지막으로, 보다 덜 규범적이지만 반복적인 소프트웨어 개발 수명 주기(SDLC)를 통해 신속한 프로토타이핑 또는 대규모 시스템을 점진적으로 설계, 구축 및 제공할 수 있습니다.

애자일 소프트웨어 개발 및 애자일 프로젝트 관리는 폭포수의 부적절함과 소프트웨어 제공에 대한 반복적인 접근 방식의 이점에서 탄생했습니다. 1950년대의 뿌리, 70년대의 사고 리더십, 90년대의 성숙, 00년대의 채택으로 그 뿌리를 추적할 수 있습니다. 2001년, 실무자와 전문가 그룹은 Agile 소프트웨어 개발 정신을 구현하고 발전을 장려하기 위해 4가지 가치와 12가지 기본 원칙을 정의하는 것을 목표로 Agile 선언문을 만들었습니다. 그리고 확실히 발전했습니다.

이제 단순히 Agile이라고 부르는 것은 특별히 도움이 되지 않습니다. 소프트웨어 컨텍스트에서도 이 단어는 사람이나 조직에 따라 다른 의미를 갖습니다. 많은 측면, 정의, 구현 및 해석이 있습니다. Agile을 수용하는 각 기관은 자체 정의를 부여하려고 합니다.

애자일 소프트웨어 개발 및 프로젝트 관리는 기본적으로 올바른 작동 소프트웨어를 가능한 한 빨리 그리고 자주 제공하는 것을 선호하는 관련 동작, 프레임워크, 기술 및 개념의 그룹이라고 말하는 것으로 충분합니다.

앞서 소프트웨어 개발이나 프로젝트 관리에 적용되는 Agile은 다를 수 있다고 언급했습니다. 간단히 말해서, 애자일 소프트웨어 개발은 ​​BAU(Business as normal) 또는 프로젝트 컨텍스트에서 훌륭한 소프트웨어 개발을 처리합니다. 반면 애자일 프로젝트 관리는 소프트웨어를 포함하되 이에 국한되지 않는 복잡한 프로젝트를 제공하는 데 필요한 거버넌스와 제어를 처리합니다.

Scrum, Kanban, XP 및 Lean Software Development와 같은 많은 애자일 소프트웨어 개발 방법을 사용할 수 있습니다. 그러나 럭비 게임이 스크럼 이상인 것처럼 애자일도 마찬가지입니다. 따로따로 이러한 애자일 패러다임은 거버넌스, 자원 조달, 재무, 명시적 위험 관리 및 기타 여러 중요한 프로젝트 관리 개념과 같은 복잡한 프로젝트에 필요한 프로젝트 관리의 전체 수명 주기를 다루지 않습니다. 이를 위해 PMI Agile 또는 PRINCE2 Agile을 고려할 수 있습니다. "거버넌스된 민첩성"이라고 생각하십시오.

애자일해야 하는 이유는 무엇입니까?

오래 전에 우리는 생존을 위해 식량과 피난처를 모으기 위해 땅을 배회했습니다. 그것들은 단순한 요구 사항이었지만 꽤 민첩했습니다. 얼마 후, 산업혁명을 배경으로 국가와 경제가 성장하고 번영했습니다. 이것은 관리와 통제의 탄생이자 민첩성의 상실이었습니다. 이제 우리는 기업이 지식 근로자를 고용하는 정보화 시대 또는 혁명에 있습니다. 지식 근로자는 고객, 비즈니스, 사회, 경제 및 세계 문제에 대한 훌륭한 솔루션을 만들기 위해 노력하는 귀하, 파트너, 동료 및 동료입니다. 지식 근로자는 종종 느슨하게 정의되고 변화하는 요구 사항에 분석, 지식, 추론, 이해, 전문 지식 및 기술을 적용합니다. 이러한 기업과 근로자는 구산업 시대의 프로세스와 절차로는 충족할 수 없는 방법과 기술이 필요합니다. 애자일은 상호 작용을 지원합니다.

사실상 어떤 소프트웨어 프로젝트도 처음에 자신 ​​있게 착수하고 가치 있는 작업 소프트웨어를 변경 없이 제공하기 위해 필요한 모든 것을 알 수 없습니다. 변화는 프로젝트의 성공에 기회와 위험을 동시에 제시합니다. 관리되지 않는 기회는 훌륭한 회사와 멋진 회사의 차이를 의미할 수 있습니다. 관리되지 않는 위험은 재앙과 파멸을 초래합니다. 애자일은 변화를 관리합니다.

Agile을 채택하면 변화하거나 새로운 요구 사항에 대응할 수 있습니다. 이를 통해 개발 팀이 전문가가 되어 참여하고 신뢰할 수 있으며 정보에 입각한 비즈니스의 지원을 받는 결정을 내릴 수 있습니다. 고객이 진정으로 원하는 것을 전달할 수 있습니다. 궁극적으로, 귀하와 귀하의 조직은 가능한 한 빨리 투자 수익을 끌어내는 동시에 고객의 요구와 기대에 부응하는 고품질의 가치 있는 소프트웨어를 제어할 수 있습니다. 애자일은 가치를 창출합니다.

Agile을 도입하는 데는 비용이 듭니다. 공짜로 오지 않습니다. 소프트웨어 제공을 위해 애자일 접근 방식으로 전환하는 것은 따라가기 힘든 경로일 수 있습니다. 그러나 애자일 철학을 내면화하고, 신중하게 밟고, 올바른 태도로 올바른 팀을 참여시키고, 일을 세분화하고, 달성 가능하고 현실적으로 만들고, 피드백에 응답하면 보상을 거둘 것입니다. Agile은 협업을 강조합니다.

다음은 기대할 수 있는 몇 가지 이점을 나열한 것입니다.

• 시장 출시 속도
• 초기 수익 창출
• 실제 가치의 정기 배송
• 투자 보호
• 데이터, 데이터, 데이터
• 더 나은 제품 품질
• 관리 가능한 기대치
• 고객 만족도 향상
• 더 높은 성과를 내는 팀
• 진행 상황에 대한 가시성 향상
• 예측 가능성, 투명성 및 자신감
• 관리 가능한 위험

성공은 최종적이지 않고 실패는 치명적이지 않습니다. 중요한 것은 계속할 수 있는 용기입니다.

Winston Churchill은 실제로 이것을 말한 적이 없지만 애자일의 꽤 좋은 요약이라고 생각합니다. 우리는 Agile이 대부분의 프로젝트에서 최선의 발판이라는 것을 알고 있습니다. 그것은 당신이 성공을 위해 노력하도록 격려하지만 우리는 항상 반복하고 계속 구축합니다. 애자일은 당신이 실패하도록 부추길 것이지만 일찍 실패하고 계속 나아가십시오. 고객이 제공한 통찰력을 바탕으로 올바른 솔루션을 구축하고 계속할 수 있는 용기가 보상을 가져옵니다.

명심해야 할 점은 Agile을 필요에 맞게 조정할 수 있다는 것입니다. 귀하의 비즈니스에 적합한 방법과 거버넌스를 사용하십시오. 어디에서 시작하든, 사용하는 방법의 내용, 맥락 및 정신에 충실하십시오. 바닐라로 유지하십시오. 이제 막 시작하는 경우 배우십시오 . 당신이 잠시 동안 그것을 해왔다면, 이해 하십시오. 당신이 멋있어지고 있다면, 신청 하십시오. 마지막으로, 비즈니스와 프로젝트가 복잡하고 상호 의존적 이라면 . 시간이 지남에 따라 귀하와 귀하의 팀은 귀하의 비즈니스에 가장 적합한 것이 무엇인지 알아낼 것입니다.

실행할 수 있음

그래서 지금 당신은 생각하고 있습니다. "알겠습니다. 알겠습니다. 어떻게 시작합니까? 어디서부터 시작해야 할까요?” 글쎄, 모든 좋은 것들과 함께, 우리는 처음부터 시작합니다. 그리고 Agile을 사용하면 "내가 전달하고자 하는 비즈니스 가치는 무엇인가?"라고 자문해 보는 것입니다. 결국 우리가 프로젝트를 수행하는 이유는 비즈니스 가치를 창출하기 위한 것입니다. 프로젝트가 비즈니스 가치를 도출하기 위해 착수할 가치가 있는지 확인하려면 실현 가능한지 이해해야 합니다.

비전

귀하의 프로젝트가 수익 증대, 새로운 시장 진입, 더 많은 고객 확보, 고객 인식 개선 또는 식별한 주어진 문제에 대한 삶을 더 쉽게 만들 것으로 예상됩니까? 이를 염두에 두고 "비전"을 진술할 수 있습니다.

• 당신의 비전은 일반적인 문제를 해결하기 위한 대담한 스타트업, 비즈니스 관리 전략, CEO의 애완동물 프로젝트, 특정 제품 팀 또는 고객의 요구 등 다양한 출처에서 나올 수 있습니다.
• 자신의 입장에서 한 발짝 물러서서 고객의 손에 있는 새로운 제품이나 서비스의 미래가 어떤 모습일지 "확인"하십시오.
• CEO, 제품 담당자 및 고객과 같은 이해 관계자를 참여시키십시오. 워크샵을 하고, 이것을 따로따로 시도하지 마십시오. 가정에 도전하고 주장을 검증하십시오.
• 적어 두십시오. 짧게 유지하십시오. 비즈니스 가치에 중점을 둡니다.
• 비전이 모든 사람의 공감을 불러일으키고 여러분이 향하고 있는 방향을 나타내는 일반적인 해석을 충족한다는 데 모두 동의할 때까지 수정하십시오.
• 당신의 비전은 유효하다면 거의 바뀌지 않습니다. 당신이 거기에 도달하는 방법이 가장 확실할 것입니다.

사람들은 당신이 하는 일이나 당신이 하는 방법을 사지 않습니다. 그들은 당신이 그것을 하는 "왜"를 구매합니다. 이것이 귀하의 비즈니스와 고객 사이에 감정적 연결을 만드는 것입니다. 비전은 이것을 설명하는 데 도움이 될 것입니다.

실현 가능합니까?

실현 가능성은 적어도 몇 가지 음영으로 나타납니다. 일반적으로 비즈니스와 고객을 위한 더 밝은 미래에 대한 비전이 기술적으로 실현 가능하고 비즈니스에서 실현 가능한지 이해하고 싶을 것입니다.

• 만약 당신의 비전이 1시간 안에 전 세계 어디든 여행을 하는 것이라면, 당신은 기술적 타당성에 문제가 있을 수 있습니다. 과학, 물리학 및 기술이 아직 그 꿈을 완전히 따라잡지 못했기 때문에 기술 솔루션은 이론 외에는 실행 가능하지 않을 수 있습니다. 또한 솔루션이 새로운 것이라면 MVP(Minimum Viable Product)라는 개념을 훨씬 뛰어넘을 것입니다.

• 제품의 기술적 타당성을 테스트하려면 디스커버리 프로토타입 프로젝트에서 추가로 탐색하거나 프로젝트 초기 단계에서 스파이크를 실행하는 것이 좋습니다. 염두에 두고 있는 솔루션의 규모나 복잡성을 생각하면 어떤 방법을 사용해야 하는지 알 수 있습니다.

  “우리 팀이 기술적 타당성을 이해하는 데 있어 얻은 최고의 지식 중 일부는 스파이크를 수행하는 데서 비롯되었습니다. 그리고 종종 가장 간단한 솔루션이 승리합니다!”

• 두 번째로 고려해야 할 타당성 측면은 귀하, 귀하의 팀 또는 귀하의 비즈니스가 업무를 수행할 수 있는 기술과 동기를 가지고 있는지 여부입니다. 예를 들어, 집에서 아이들의 생일을 위해 케이크를 굽는 데 능숙하다면 정말 좋습니다. 그러나 이것을 세계에 가장 좋은 케이크를 판매하는 비즈니스로 전환하려면 규모를 확장할 수 있는지, 비즈니스와 생산을 모두 처리하고, 유통 및 이행을 관리하고, 고객 서비스를 돌볼 수 있는지 이해해야 합니다.
• 이러한 유형의 비전은 장기적으로 달성할 수 있습니다. 그러나 현재로서는 그렇지 않을 수도 있습니다. 따라서 규모를 축소하고, 작게 생각하고, 현실적으로 보이는 작은 덩어리를 선택하고 가능한 한 최고의 작은 열망을 제공하는 데 집중하십시오. 그렇게 해서 고객의 참여를 유도하고 기쁘게 할 수 있다면 고객이 다시 방문하여 친구에게 더 많은 정보를 제공하도록 한 다음 고객 피드백을 가이드와 나침반으로 사용하여 확장하십시오.
• 또한 프로젝트가 예산과 기간 측면에서 실현 가능한지 알아야 합니다. 귀하의 비즈니스는 이 프로젝트를 수행할 여유가 있습니까? 기간은 달성 가능한가요? 시간과 돈은 고정된 Agile 프로젝트의 세 가지 제약 조건 중 두 가지입니다. 우리는 주어진 고정된 시간과 주어진 고정된 예산 내에서 제공하는 것을 목표로 합니다.
• 제품의 품질은 고객이 사용하는 최종 제품과 팀이 훌륭하고 강력하며 안정적인 소프트웨어를 제공하기 위해 사용하는 엔지니어링 방식을 나타냅니다. 품질은 또한 우리가 짧게 바꾸지 않는 것입니다. 반면에 품질 기준은 변경될 수 있습니다. 페라리를 만들 계획이 아니라면 제품에 대한 높은 품질 인식이 없을 수 있습니다. 우주 로켓을 제작하지 않는 경우 생산 조건에서 달성한 허용 오차가 훨씬 더 높을 수 있습니다. 초기에 적절한 어조와 기대치를 설정하십시오.

이제 당신은 당신의 꿈이 초콜릿 이상이라는 것을 확인했고, 당신의 가정을 테스트하고 이 노력이 투자할 가치가 있다는 것을 사람들에게 증명하기 시작했습니다.

정당화

이제 여러분의 상황에 따라 칭의가 다양한 형태로 나타날 것입니다. 그러나 본질적으로 이 프로젝트가 고객의 성공 기준을 충족하고 성공 가능성이 있으며 가치를 제공하고 저렴하다는 것을 증명하려고 합니다.

• 고객 요구 사항을 기반으로 가정을 설명한 다음 검증하십시오. 린 스타트업은 귀사의 제품이 고객에게 필요하고 가치를 창출할 것임을 식별하고 입증하는 데 유용한 지침을 제공합니다.

• 사업 계획을 작성, 테스트 및 검증하십시오. 이제 이것은 귀하의 은행이나 비즈니스 및 금융 전공에서 생산하도록 지시한 것과는 전혀 다릅니다. 사용하지 마십시오. 잉크가 마르기 전에 만료됩니다. 대신 비즈니스 모델 캔버스를 확인하십시오. 이것은 본질적으로 가치 제안, 고객, 수익 및 비용에 초점을 맞추는 짧은 형식의 사업 계획입니다. 성공할 비즈니스가 있는지 확인하는 데 사용하십시오.

  “한 번 이 조언을 무시하고 50페이지 분량의 길고 긴 사업 계획서를 작성하는 데 오랜 시간을 보냈습니다. 그것은 나를 아무데도 얻지 못했다. 내가 한 모든 가정은 근거가 없었고 내가 한 모든 예측은 검증될 수 없었습니다. 다시는 그런 일을 하지 말라고 가르쳐준 고통스럽고 값비싼 경험이었습니다.”

• 복잡한 환경에서 제공되는 프로젝트 포트폴리오가 있는 성숙한 비즈니스에 있는 경우 재무 모델링이 필요할 수 있습니다. 필요한 경우 위의 사항을 입증한 후에만 이 작업을 수행하십시오.
• MVP를 구축한 후에는 보다 전통적인 사업 계획을 수립해야 하는 경우가 있을 수 있습니다. 예를 들어 회사의 경쟁 프로젝트 및 리소스 포트폴리오 내에서 자금 조달 또는 선택을 위해 이동해야 하는 경우입니다. 그러나 이것은 위에서 사용된 도구에 기반한 사업 계획이 될 것입니다. 가벼워지기도 합니다.
• 어쨌든 이 도구를 살아 숨쉬는 인공물로 사용하십시오. 당신의 가이드와 벨웨더로 사용하십시오. 그것들은 결코 정적이지 않습니다. 이를 참조하고 프로젝트 또는 비즈니스가 발전함에 따라 수정하십시오.

정당성을 확보하고 모든 이해 관계자가 참여하면 화를 낼 것입니다.

타당성 단계는 일반적으로 프로젝트 수명 동안 한 번 수행됩니다. 특히 데이터, 고객, 시장 또는 비즈니스가 그렇게 표시하는 경우 프로젝트의 비전과 실행 가능성을 다시 찾을 수 있습니다. 최소한, 그들은 당신을 안내하는 등불이 될 것입니다.

개시

엄청난. 결정이 내려졌고 프로젝트가 승인되었으며 구축할 준비가 되었습니다. 글쎄, 거의. 나는 당신이 생각하고 있다는 것을 압니다. “벌써, 정말? 우리가 지금 이것을 하지 않는다면 우리는 결코 하지 않을 것입니다. 이 쇼를 도로에서 합시다!” 그러나 이것을 고려하십시오. Agile은 초기에 자주 가치를 제공하는 동시에 고객을 기쁘게 하는 것이 아니라면 아무 것도 아닙니다. 시간을 내어 프로젝트를 전달하는 가장 좋은 방법을 찾는 것이 성공을 위한 가장 좋은 기반입니다.

팀

스포츠에서 좋아하는 팀 게임에 대해 생각함으로써 팀이 원하는 대로 수행할 수 있도록 하는 핵심 역할을 인식할 수 있습니다. 전통적으로, 당신은 매니저, 주장, 그리고 나머지 스쿼드를 찾을 수 있을 것입니다. 그 외에도 코치, 물리 치료사, 영양사 및 다양한 지원 직원을 찾을 수 있습니다. 하지만 럭비 경기를 보면 팀 안에 팀이 있습니다. 바로 스크럼을 구성하는 선수입니다. 이 팩은 공을 되찾고 계속 플레이하는 것이 임무인 지정된 플레이어로 구성됩니다. 스크럼이 진행 중일 때 각 측면의 플레이어는 리더 없이 단일 유닛으로 최대한 협력하고 의사 소통하며 효율적으로 공을 다시 소유하도록 합니다. Jeff Sutherland가 자신의 소프트웨어 개발 방법론을 "스크럼"으로 명명하도록 영감을 준 것은 럭비 게임입니다.

• 스크럼은 애자일 플레이북의 유일한 소프트웨어 개발 방법이 아닙니다. 그러나 팀으로 일하고, 개인에게 동기를 부여하고, 신뢰 관계를 구축하고, 자기 조직화, 섬기는 리더십, 의사 소통, 투명성 및 협업의 애자일 개념과 행동을 가장 잘 설명하는 것입니다.
• 귀하의 팀은 주로 귀하가 처한 상황에 따라 구성됩니다. 사용할 수 있는 개발자가 있을 수 있습니다. 그들 중 일부, 전혀 또는 모두는 다양한 정도로 Agile에 익숙할 수 있습니다. 새로운 팀을 고용하거나 제3자와 파트너를 맺을 수 있습니다.
• 다른 역할도 필요하지만 이에 대해서는 나중에 논의하겠습니다.
• 개발 팀을 구성하는 경우 기술을 선택했다고 합니다. 팀을 모으는 위치에 따라 특정 기술이 제공됩니다. 따라서 개발 팀을 구성하는 방법과 여정의 이 지점에 도달하기 전에 기술 평가를 수행해야 하는지 여부를 신중하게 생각하십시오.
• 이것은 우리를 교차 기능 팀으로 안내합니다. 팀은 함께 일할 때, 개인이 직책에 관계없이 일을 완수하기 위해 참여할 때 가장 잘 작동합니다. 자급자족하는 팀과 둘 이상의 역할을 맡은 개인을 구성하십시오.
• 환경, 문화, 관계 센터를 구축하세요. 팀이 제약이나 제약 없이 전달할 수 있는 곳입니다. 팀이 효과적이고 성과를 낼 수 있도록 도구, 인력, 자원 및 공간을 제공하십시오.
• 팀 규모를 7~8명 이하로 유지하십시오. 더 많은 개발자가 필요한 경우 팀을 여러 개의 새 팀으로 나눕니다. 각 팀은 주어진 기능 영역을 담당할 수 있습니다. 여러 위치에 여러 팀이 있는 경우 Scrum of Scrum을 개최하는 것이 좋습니다. 복잡한 환경에 이러한 항목이 많은 경우 Agile 프로젝트 관리를 사용하십시오.
• 팀, 비즈니스, 이해 관계자 및 고객이 서로 액세스할 수 있도록 합니다. 그들이 의사 소통하고 협력하는지 확인하고 진행을 방해하는 모든 것을 제거하십시오. 매일의 의사 소통은 프로젝트 질병에 대한 최고의 치료법입니다. 사람들은 말을 하면 일을 처리합니다.

소프트웨어를 제공하기 위해 팀을 구성할 수 있는 방법에는 여러 가지가 있습니다.

프로젝트 개요

타당성 단계에서 프로젝트의 "이유"를 파악하고 스타트업을 추진할 자신감을 얻었거나 진행을 위해 지원을 받았습니다. 프로젝트 개요는 "왜"와 "무엇을", "언제", "누가"를 결합한 살아있는 문서입니다. 진행함에 따라 지식, 이해 및 경로가 변경될 수 있기 때문에 "살아있는" 것입니다. 이 문서를 한 번 작성한 상태로 두고 다시는 돌아가지 않는 것은 당신의 생각을 특정 시점으로 보내는 것입니다. 애자일 세계에서 시점 기준은 초기에 매주 또는 매일 변경될 수 있으므로 이를 최신 상태로 유지하는 것이 중요합니다.

• 프로젝트 요약을 요약하고 유지하기 위한 훌륭한 도구는 Jonathan Rasmusson이 그의 책 The Agile Samurai 에서 "초기화 데크"라고 부르는 것입니다. 여기에서 프로젝트에 관심이 있거나 영향을 받거나 관련된 모든 사람이 같은 페이지에 있는지 확인하는 데 유용한 조언을 찾을 수 있습니다.
• 프로젝트를 제공하는 데 있어 가장 큰 적은 프로젝트가 무엇이며 어떤 "요구 사항"이 충족되어야 하는지에 대해 명확하지 않거나 일관성이 없거나 완전히 다른 이해를 하는 데 있습니다. 중요한 이해 관계자 중 한 명이 당신이 하는 일에 대해 다른 이해나 관점을 가지고 있다면 그 결과는 상당할 수 있습니다.
• 좋은 프로젝트 개요는 다음을 전달합니다.
  1. 이해 관계자와 팀 구성원 간의 공통적이고 합의된 기대.
  2. 모든 당사자에 걸쳐 동일한 이해와 함께 프로젝트에 대한 이해.
  3. 목표, 비전, 목적, 범위 및 프로젝트 컨텍스트.
• 타당성에서 수집한 브리핑에 대한 좋은 정보가 많이 있을 것입니다. 프로젝트 개요는 검색 질문에 대한 답을 정의하고 찾는 데 도움이 됩니다. 이해 관계자, 귀하의 존재 이유 , 높은 수준의 범위, 위험, 대상 솔루션, 예산, 일정, 기대치 및 우선 순위를 한데 모을 것입니다.

한 동료가 복도에서 나를 멈추고 프로젝트에 대한 프로젝트 개요를 어디에서 얻을 수 있는지 물었습니다. 나는 '우리는 브리핑이 필요 없다, 우리는 민첩하다'고 말했다. 그는 내 정신이나 권위를 의심하는 것처럼 혼란스러워 보였다. 그가 그렇게 하는 것이 옳았습니다.

계속하기 전에 모든 사람이 같은 페이지에 있는지 확인하고, 워크숍을 진행하고, 어려운 질문을 하고, 사람들이 멈추고, 읽고, 댓글을 달고, 수정을 도울 수 있는 위치에 고정시키십시오.

문화와 일하는 방식

당신은 당신의 비즈니스가 작동하는 방식과 문화, 일을 끝내는 방식을 알고 있습니다. 애자일은 본질적으로 기업이 수년 동안 쌓아온 이러한 작업 방식 중 일부에 도전할 수 있습니다. Agile이 구현되고 모든 사람이 애자일을 처음부터 사랑스럽게 채택할 것이라고 기대하지 마십시오. 어떤 사람들은 그것을 혼란스럽게 여기고 두려움과 두려움으로 만 볼 수 있습니다. 어떤 사람들은 공개적으로 참여를 거부할 수 있습니다. 이것들은 당신이 극복해야 할 도전과 인식입니다. 그러나 초기에는 애자일 스틱을 휘두르며 듣지 않으려는 사람을 때리려고 하지 마십시오. 그것은 신뢰, 채택 또는 참여를 구축하지 않습니다.

나는 한때 속담에 큰 막대기를 흔드는 것을 좋아했고, 그것은 나에게 많은 부정적인 언론을 얻었습니다. 나는 그것을 돌렸지만 먼저 상당한 고통을 겪었습니다.

입양의 길을 시작할 때, 신중하고 정중하며 공감하는 마음으로 걸으십시오. 삐걱거리는 오래된 전통적 비즈니스에 종사하고 있다면 전체 비즈니스를 조정하는 가장 좋은 방법이 아닐 것입니다. 작게 시작하여 점차적으로 존경과 인정을 받으십시오. 팀으로만 시작하십시오. 이전보다 더 나은 품질로 더 빠른 소프트웨어를 제공하기 시작하면 사람들은 알아차리기 시작하고 게임을 하고 싶어할 것입니다. 그들이 그렇게 할 때, 그들에게 공을 제공하고 커피를 마시기 위해 그들을 데리고 나가 당신의 새로운 세계로 그들을 편안하게 하십시오. 그들을 도와주세요.

팀과 함께 프로젝트가 무엇인지 알고 Agile 채택 계획에 동의했으므로 팀이 팀으로서 어떻게 행동하고 운영할지 결정하게 하십시오.

• 팀이 집단적 요구에 적합하다고 생각하는 Agile 개념, 기술, 동작 및 프레임워크를 식별하도록 안내합니다.
• 팀 구성원의 요청을 받아 가능한 한 최선을 다해 수행하는 데 도움이 되는 요구 사항이 무엇인지 확인하십시오. 이러한 요청 중 일부는 즉시 해결할 수 있습니다. 다른 사람들은 예산이나 외부 도움을 받아야 할 수도 있습니다. 그것을 가능하게 하기 위해 당신이 할 수 있는 일을 하십시오.
• 이것이 진정한 서번트 리더가 되기 위한 첫 번째 단계입니다.
• 팀이 채택하기로 선택한 개념과 기술에 대한 적절한 교육을 조직하는 것을 고려하십시오. 이것은 이해 관계자를 포함한 모든 팀 구성원이 동일한 페이지에 있고 동일한 메시지를 수신하도록 하는 가장 좋은 방법입니다. 귀하의 요구 사항에 맞게 제품을 조정할 수 있는 공급업체 조직과 협력하십시오.
• 신중하세요. 애자일이 되는 방법을 배우는 워크숍에서 며칠 후에 애자일 닌자가 되는 사람은 아무도 없습니다. 당신의 길은 길 것입니다. "되다"라는 단어는 매우 정의적입니다. 애자일을 진정으로 수용할 때만 그 가치를 알게 될 것입니다. 그것은 당신을 흥분해야합니다. 그것이 당신을 흥분시키면 다른 사람들도 흥분시키십시오.
• 이제 팀이 개념과 기술에 동의하고 희망 사항이 충족되었으며 Agile 교육을 받고 있으므로 팀의 관심을 자신과 팀이 귀하, 비즈니스 및 서로에게 기대하는 바에 맞추십시오.
• 팀 내 및 팀에 의한 몇 가지 작업 방식(WoW)을 정의하면 신뢰, 관계 및 기대치를 구축하는 데 도움이 됩니다. WoW는 전쟁과 평화 가 아닙니다. 7~10개의 글머리 기호 문장 사이의 짧고 요점이어야 합니다. 이 문장은 사람들이 함께 행동하고, 의사 소통하고, 협력하고, 지원하고, 전달하고, 수행하는 방법을 명확하게 나타냅니다. 또한 팀이 비즈니스에서 기대하는 바를 명시해야 합니다.

• Agile은 원칙과 개념을 안내하는 것만큼이나 사고 방식입니다. 그것은 당신이 행동하고, 생각하고, 협상하고, 상호 작용하고, 의사 소통하고, 수행하고, 개선하는 방식으로 발전하는 데 도움이 됩니다. 동기 부여된 개인이 하나가 되어 공통의 목표를 달성하기 위해 서로를 지원합니다. 아프리카 속담에 이런 말이 있습니다.

지금쯤이면 여러분의 팀은 매우 흥분되고 활력이 넘치고 동기가 부여될 것입니다. 이제 사용자 스토리의 백로그를 통해 더 많은 참여를 유도하십시오.

백로그

당신의 프로젝트에 불확실성이 있다는 것을 마음속에 의심하지 마십시오. 초기에 고객에게 적합한 제품을 구축하는 데 무엇이 필요한지 정확히 알 수는 없습니다. 수정 구슬을 애타게 바라보고 미래를 예측할 수는 없습니다.

"백로그" 또는 "제품 백로그"는 요구 사항이 있는 곳입니다. 애자일은 "요구사항"의 본질을 포착하는 짧고 간결한 문장을 작성하는 것을 선호합니다. 백로그는 단순히 긴 항목 목록이며, 각 항목은 사용자 스토리로 하나의 개별 "요구 사항"을 정의합니다. 그리고 이제부터는 '요구사항'이 아닌 사용자 스토리라는 단어를 사용하겠습니다. 아마도 "왜?"라고 묻고 있을 것입니다. 그건 좋은 질문이야. 영원히 보일 것 같지만 고객이 소프트웨어 프로젝트에 필요한 기능이나 측면을 언급하는 것은 항상 요구 사항으로 언급되었습니다. 그 단어는 Agile에서 가치가 없는 해석을 가지고 있습니다. 옥스포드 사전에서는 이를 다음과 같이 정의합니다.

필요하거나 원하는 것. 또는, 의무적인 것 필요조건.

그리고 불행하게도 우리의 솔루션이 무엇인지 정의하고 모든 것이 "강제"라고 말하면 문제가 발생합니다. 이 모든 사용자 스토리가 필수라고 말하기는 너무 쉽습니다. 이러한 관점을 취하면 주어진 범위를 모두 제공하기 위해 일정과 예산을 초과할 위험이 있습니다. 이 제품의 경우 솔루션이 실행 가능하기 위해 이러한 이야기가 필요하다고 말하는 것은 문제가 아닙니다. 우리는 특정 단어의 해석을 피하고 싶을 뿐입니다.

• 항상 페르소나의 관점에서 이야기를 작성하십시오. 페르소나는 솔루션의 사용자 또는 이해 관계자를 나타냅니다. 백로그를 시작하기 전에 이러한 페르소나를 개발하는 것이 좋습니다.
• 이 단계에서는 기본적으로 적절한 시간에 사용자 스토리에 대해 더 깊은 대화를 나누도록 상기시키는 짧고 간단한 문장만 작성합니다.
• 실제 사람들은 목표를 달성하기 위해 수행해야 하는 작업의 관점에서 생각합니다. 페르소나 관점에서 그리고 그들이 해야 할 일의 관점에서 당신의 이야기를 쓰십시오.
• 전체 백로그를 작성할 필요는 없습니다. 고객이 귀하의 제품을 실행하는 데 필요하다고 상상할 수 있는 만큼만 작성하십시오.
• 나중에 사용자 스토리가 변경되거나 중요해지거나 완전히 삭제될 수 있다는 것을 제품 수명 동안 알게 될 것입니다. 자주 릴리스하고, 피드백을 받고, 우선 순위를 평가하면 이 동작을 알 수 있습니다.
• 따로 이야기를 쓰지 마세요. 팀, 이해 관계자, 고객을 참여시키십시오. 스토리는 프로젝트가 진행되는 동안 언제든지 업데이트할 수 있지만 개발 작업이 시작된 후에는 변경되지 않아야 합니다.
• 귀하의 이야기 중 일부는 "에픽"으로 간주될 수 있습니다. 이것들은 많은 것을 다루는 큰 이야기이며 배달 시간이 가까워지면 더 작은 이야기로 나뉩니다.
• 좋은 사용자 스토리의 품질을 검증하기 위한 체크리스트인 INVEST 모델 사용을 고려하십시오.
• 누구나 백로그에 스토리를 추가할 수 있습니다. 바닥이나 특별히 만들어진 "주차장"에 놓아야 합니다. 이 추가된 이야기는 팀 및 비즈니스와 논의할 수 있는 프롬프트 역할을 합니다. 비즈니스와 팀이 지원하는 경우 이를 추정하고 우선순위를 지정할 수 있습니다.
• 가장 위험한 시스템 부분을 고려할 수도 있습니다. 복잡하거나 새롭거나 기술적으로 알려지지 않은 사용자 스토리나 기능이 있는 경우 백로그의 맨 위에 우선 순위를 지정하십시오. 이렇게 하면 첫 번째 릴리스가 있기 몇 주 전에 제품의 어렵고 중요한 부분을 전달하려고 하지 않을 것입니다.

요구 사항을 충족하는 백로그가 있으면 그 안의 스토리를 추정하고 우선 순위에 따라 순위를 매기고 출시 계획을 세울 수 있습니다.

높은 수준의 추정 및 우선 순위 지정

개략적인 추정은 백로그의 크기를 조정하는 프로세스입니다. 프로젝트가 얼마나 "크고" 어떤 가치를 제공합니까? 우선순위는 어떤 이야기가 당신에게 가장 중요한지, 제품의 생존 가능성, 고객의 이익을 결정하는 과정입니다. 우리는 비즈니스에 가장 큰 가치를 전달하고, 고객으로부터 피드백을 받고, 작은 일에 질리지 않기 위해 가장 높은 가치의 아이템을 가장 빨리 전달하고자 합니다. 출력은 우선 순위가 지정되고 적절한 크기로 정렬된 백로그가 됩니다.

• 맨 위에 있는 이야기가 가장 가치 있는 것으로 간주됩니다. 우리는 가장 가치 있는 물건을 가능한 한 빨리 전달하고자 합니다.
• 크기 조정 및 추정을 위한 많은 기술이 있지만 이 시점에서는 스토리의 크기를 잘 나타내는 느낌을 얻고자 합니다.
  • 티셔츠 크기, 상대적 크기, 이상적인 날 또는 스토리 포인트를 사용하십시오.
• 이 시점에서 사용 가능한 모든 정보를 얻지는 못하지만 괜찮습니다. 그것으로 실행하십시오.
• 비즈니스 이해 관계자 또는 제품 관리자(있는 경우)와 해당 작업을 수행할 팀을 참여시키십시오.
• 우리는 작업을 설계, 개발 및 테스트할 사람들이 크기를 조정하기를 원합니다. 왜냐하면 가장 잘 평가할 수 있는 사람은 전문가이기 때문입니다.
• 팀은 이야기를 더 작은 부분으로 나누기 시작할 수 있습니다. 이런 일이 발생하면 더 세분화되지만 개별적인 이야기를 작성하십시오.
• 팀은 또한 기술이나 주어진 사용자 여정을 지원하기 위해 다른 것보다 먼저 전달되어야 하는 몇 가지 이야기의 순위를 매기기 시작할 수도 있습니다.
• 당신과 팀 사이에서 채워야 할 백로그의 구멍을 찾기 시작할 수도 있습니다. 그 구멍을 새로운 이야기로 채우고 적절하게 평가하고 우선 순위를 지정하십시오.
• 우선 순위 지정은 MoSCoW 분석을 사용하여 가장 쉽게 수행됩니다. MoSCoW는 제품이 성공하기 위해 "필수적인" 스토리를 결정하는 데 도움이 되는 간단한 기술입니다.
• 평가가 시작되기 전에 우선순위 지정을 수행할 수 있습니다. 그러나 특정 요소의 크기는 우선 순위와 실제 비즈니스 가치에 대한 결정을 결정할 수도 있습니다. 따라서 서로 평가하고 우선 순위를 정하는 방법을 사용하되 논쟁하지 마십시오!
• 어떤 두 이야기도 다른 것만큼 중요할 수 없습니다. 1순위의 이야기는 2순위의 이야기보다 더 중요하거나 가치가 있습니다.
• 이야기의 중요성이나 가치를 보여주는 가장 좋은 방법은 이야기에 금전적 가치를 더하는 것입니다. 예를 들어 스토리 A가 $5000의 추가 수익을 가져올 것으로 생각되고 스토리 B가 $100를 유치할 수 있다면 스토리 A가 더 가치가 있습니다. 마찬가지로 스토리 C가 스토리 D보다 비즈니스를 더 많이 구한다면 스토리 C가 더 가치가 있습니다.
• 백로그의 크기를 조정하면 숫자가 남게 됩니다. 출시 계획을 세울 때 이 수치는 주어진 시간 내에 우리 팀이 얼마나 많은 것을 제공할 수 있는지 이해하는 데 도움이 될 것입니다.

모든 사용자 스토리를 미리 알 필요는 없습니다. Also, remember that it's not necessary to deliver all of your stories before a customer sees your product. You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

출시 계획

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

적응 계획

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

Story Creation

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

전력 질주

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• 작은 증분으로 작업하면 큰 이점이 있습니다. 이는 곧 제공되는 미래에만 초점을 맞추고 있으며 새로운 입력, 피드백 및 학습을 통해 짧은 반복 주기 내에서 변화에 대응할 수 있음을 의미합니다.
• 릴리스가 시작될 때 스프린트 0을 수행합니다. 이를 통해 팀, 비즈니스 및 프로젝트 릴리스가 준비되고 성공적인 제공을 위한 사고 방식이 설정됩니다. 릴리스의 기반을 지원할 기본 기술 프레임워크 및 아키텍처를 그립니다. 환경, 계정 및 도구를 설정합니다. 어렵거나 알려지지 않은 문제를 이해하기 위해 스파이크를 수행합니다. 스프린트 1에 대한 준비 상태에서 사용자 스토리를 자세히 설명합니다. 스프린트 0은 준비하는 것입니다.
• 릴리스하는 동안 백로그를 계속 수정하십시오. 더 많이 이해하거나 새로운 것을 배우면 우선 순위가 변경될 수 있고 새로운 요구 사항이 전개될 수 있으며 이전에 훌륭한 기능이라고 생각했던 것이 완전히 제거될 수 있습니다.
• 스프린트 내에 완료할 가능성이 없는 작업은 시작하지 마십시오. 할 수 없으면 더 작은 덩어리로 쪼개십시오. 그리고 이전에 시작한 작업이 완료되지 않은 상태에서 새 작업을 시작하지 마십시오. 완전한 것으로 간주할 수 없는 많은 일을 시작함으로써 가치를 창출하지 못합니다. 또한 컨텍스트 전환을 피하십시오. 이것은 하나의 작업을 시작하고, 방해를 받고, 다른 작업을 시작하고, 가장 문제가 되는 작업을 완료하지 않는 활동입니다.
• 한 번에 팀에서 진행 중인 작업의 양을 제한합니다. 예를 들어 세 명의 개발자와 한 명의 테스터가 있는 경우 개발자와 테스터에 대해 WIP 제한을 둘 수 있습니다.
• 스프린트가 계획된 후에는 더 이상 작업을 추가하지 마십시오. 도중에 스프린트를 멈추지 마십시오. 이에 대한 예외는 다음과 같습니다.
  • 예상보다 빠르게 수행한 경우 적절하게 준비된 한 백로그의 맨 위에서 다음 스토리를 가져오는 것을 고려하십시오.
  • 스프린트가 완료되지 않을 정도로 성능이 좋지 않은 경우. 이것은 일반적으로 일부 설명에 대한 재앙이 발생한 경우에만 발생합니다.
  • 비즈니스의 즉각적인 변화 요구로 인해 스프린트 목표를 더 이상 지원할 수 없는 경우.
• 스프린트를 취소했다면 우아하게 하고 다시 집중할 시간을 갖고 다른 스프린트와 마찬가지로 새로운 스프린트를 시작하십시오.
• 릴리스가 끝날 무렵, 최종 릴리스 스프린트를 고려하십시오. 새로운 기능이 작성되지 않고 일부 버그를 정리할 수 있으며 고객에게 제품의 새 버전을 실제로 출시하기 위한 준비를 할 수 있습니다. 그 동안 점진적인 고객 릴리스를 만들 수 없다는 것은 아닙니다. 이는 통제되고 측정되며 지속 가능한 릴리스 메커니즘일 뿐입니다.
• 릴리스가 끝나면 1주일의 스프린트를 고려할 수 있습니다. 이 스프린트에서는 팀과 함께 새로운 아이디어를 분석하거나 새로운 기술을 알아낼 수 있습니다. 이는 비즈니스에 도움이 되는 훌륭한 도구이며 팀이 생각하고 창의적으로 생각할 수 있는 브리핑 공간을 제공합니다. 장난이 아니며 여전히 가치를 창출할 것입니다. 마찬가지로 누구에게나 휴식이 필요합니다. 이 시간에 휴가를 가면 릴리스 중간에 케이던스와 속도를 좋은 상태로 유지하는 데 도움이 됩니다.

완료 정의

"완료"가 실제로 의미하는 바를 정의하는 것은 매우 중요합니다. 프로젝트의 수명에는 여러 버전의 "완료"가 있습니다. 즉, 스토리, 릴리스 또는 전체 프로젝트를 "완료"한다는 의미입니다. 그것은 모두 귀하, 귀하의 팀 및 비즈니스가 배송 준비를 만족시키기 위해 적절한 품질 수준으로 완전하다고 간주하는 것으로 귀결됩니다.

팀의 경우 "완료" 스토리의 정의는 모든 코드가 완성되고, 동료가 검토하고, 정의된 허용 기준을 충족하고, 단위 테스트를 거쳤고, UAT하고, 코드 저장소로 푸시되는 것과 같습니다. 디자이너에서 개발자, 테스터로 스토리를 전달할 수 있도록 하려면 체인의 다음 사람이 "완료"에 대한 정의를 수락해야 합니다. 제품 소유자는 제품 증분을 고객에게 제공하기 위해 이것이 자신에게 무엇을 의미하는지에 대한 기대치를 가질 것입니다. 어쨌든 모든 사람은 "완료"가 무엇을 의미하는지 알고 있어야 하며 그 의미가 충족되도록 하는 책임 있는 당사자가 되어야 합니다. "완료"에 대한 정의를 정의하고, 전달하고, 동의하고, 발전시키십시오. 완료되었습니다.

연속 측정

측정할 수 없으면 관리할 수 없습니다. 개선도 마찬가지입니다. 애자일 프로젝트에서 경험적 데이터를 수집해야 하는 필요성은 혈관에 혈액이 흐르는 것만큼이나 중요합니다! 데이터가 없는 경우 관리, 수정 또는 개선이 필요한 사항을 어떻게 알 수 있습니까? 간단히 말해서, 당신은 직감과 근거 없는 추측에 의존하게 될 것입니다. 그리고 누가 정밀 조사를 하느냐에 따라 다소 불편한 장소가 될 수 있습니다. 따라서 프로젝트를 시작할 때부터 진행 상황을 어떻게 보여줄 것인지, 다른 사람들이 여러분의 성공을 어떤 척도로 볼 것인지 알고 있어야 합니다.

다행히 Agile에는 유용한 도구와 기술이 포함되어 있습니다. 가장 먼저 할 일은 Agile Manifesto로 돌아가서 좋아하는 워드 프로세서에 다음 단어를 입력하고 최대 96pt까지 날려서 인쇄하고 모두가 볼 수 있도록 벽에 붙이십시오.

소프트웨어를 제공하는 데 있어 가장 입증할 수 있는 힘은 작업하는 사람들에게 소프트웨어가 해야 할 일을 하는 것을 보여주는 것입니다. 이는 고객을 행복하게 할 뿐만 아니라 팀에서 큰 존경을 받고 비즈니스를 통해 더 많은 채택을 위해 바퀴에 기름칠을 할 것입니다.

다음은 몇 가지 다른 도구입니다.

• 일일 스탠드업: 이 의식에는 몇 가지 변형이 있지만 핵심은 모든 팀 구성원이 서로 얼굴을 맞대고 이야기하는 것입니다. 짧게 유지하고, 집중하고, 가볍게 유지합니다. 긴 시간 동안 토론이 필요한 것이 있으면 스탠드업 후에 필요한 사람들 간의 더 긴 대화를 위해 주차하세요. 장애가 발생하면 스토리처럼 작성하여 백로그에 추가하고 최대한 빨리 해결하십시오. 팀을 방해하는 모든 것은 진행 속도를 늦추고 기대에 미치지 못하는 감소된 속도와 소프트웨어로 입증할 수 있습니다.
• 속도: 역사적인 도구입니다. 과거 실적이 미래 실적을 보장하지 않는다는 재무 경고와 비슷합니다. 그러나 Agile의 경우에는 대체로 부드러운 팀 속도를 달성하기를 희망합니다. 우리가 계획에 대한 미래의 성과와 확신을 예측할 수 있게 해주는 것은 속도입니다. 주어진 스프린트에 대한 스토리 포인트 출력의 수를 낮출 수 있는 제어 외부의 영향이 있을 수 있습니다. 이런 일이 발생하면 아마도 회복할 수 있을 것입니다. 팀을 이기기 위해 속도를 막대기로 사용하지 마십시오. 그것은 당신에게 호의를 얻지 못할 것입니다. 한 가지 확실한 것은 처음 2~4개의 스프린트에서는 속도가 불규칙하다는 것입니다. 하지만 그 기간 중 어딘가에 일관성과 안정성이 보이기 시작해야 합니다. 속도가 한 극단에서 다른 극단으로 흔들리는 경우 팀과 함께 해결해야 하는 문제가 있는 것입니다.
• 번다운 차트: 이제 이 진행 척도는 가시적인 것입니다. 그런 이유로 더 많은 정보를 찾을 수 있는 링크를 제공하지 않았습니다. 귀하가 직접 조사를 하고 귀하에게 적합한 팀 및 비즈니스로 동의해야 합니다. 가시가 많은 이유는? 글쎄요, 같은 이야기를 하는 자료는 없습니다! 합의된 한 가지는 스프린트 또는 릴리스 내에서 타임박스에 대해 어떻게 수행하고 있는지 보여줍니다. 매일 유지 관리하면 궤도에 있는지 또는 이탈하는지 표시됩니다. 일부 팀은 이를 사용하여 생성할 가치가 얼마나 남았는지 표시하고, 다른 팀에서는 완료해야 할 작업이 얼마나 남았는지 표시하는 데 사용합니다. 전자는 성공과 가치 창출을 축하하는 것이고, 후자는 덜 영감을 주고 동기를 부여하는 것입니다.
• 번업 차트: 작업 완료율을 표시해야 하는 경우 번다운 차트를 사용합니다. 그러나 번업 차트를 사용하면 얼마나 많은 가치가 창출되었으며 스프린트가 끝날 때까지 얼마나 더 많은 가치를 창출할 계획인지 보여줄 수 있습니다. 팀이 수행한 작업(또는 일이 잘 진행되지 않는 경우 거의...)과 아직 목표를 설정한 작업을 모두 비즈니스에 보여줄 수 있는 훨씬 더 동기를 부여하는 도구입니다. 어떤 경우든 차트를 사용하여 진행 상황이 예상대로 추적되지 않는 부분을 찾아내고 패턴이나 편차를 찾은 다음 이를 바탕으로 가능한 한 빨리 근본적인 문제를 수정하십시오. 스프린트의 경우 매일 업데이트하고 릴리스 버전 차트의 경우 스프린트가 끝날 때 한 번 업데이트합니다.
• 작업 보드: 생성되는 가치를 보여주는 훌륭한 시각적 방열판입니다. 매일 또는 하루 중 언제든지 업데이트되면 진행 상황이 즉시 표시됩니다. Kanban과 함께 사용하면 시스템의 흐름 및 막힘을 시각화하는 데도 훌륭한 도구입니다. 많은 개발이 완료된 것을 볼 수 있지만 테스트가 생산적이지 않은 경우 문제가 발생하고 적절하고 신속하게 대응할 수 있습니다.

고려해야 할 다른 도구는 Agile 획득 가치, 주기 시간 및 CFD(누적 흐름 다이어그램)입니다.

이러한 측정값, 차트 및 기타 도구를 볼 수 있도록 유지하고 모든 사람이 볼 수 있도록 벽에 크고 자랑스럽게 두는 것이 좋습니다. 팀, 이해 관계자 및 기타 이해 관계자는 프로젝트 상태를 즉시 볼 수 있습니다. 투명하고 귀중한 커뮤니케이션 도구 역할을 합니다. 이러한 아티팩트를 벽에 둘 수 없다면 공유 가능하고 협업 가능한 도구를 사용하고 액세스를 원하는 사람들이 사용할 수 있도록 하십시오.

지속적인 개선

애자일 생활 전반에 걸쳐 개선할 수 있는 부분을 식별하고 배우십시오. 수업은 프로젝트가 끝날 때 캡처 및 학습되지 않습니다. 운전 시험에 합격하고 강사 없이 잠정적으로 첫 운전을 하는 것과 같습니다. 무엇이 효과가 있고 무엇을 해야 하는지 알게 될 것이지만 시간이 지나면서 새로운 기술을 배우고 운전 기술과 능력을 조정하게 될 것입니다. 나쁜 습관도 들게 됩니다. 그것들을 찾고, 이해하고, 개선할 방법을 찾으십시오.

작동하지 않는 것을 식별하고 해결 방법을 적용할 수 있는 많은 기회가 있습니다. Agile에서 이에 대한 기본 제공 접근 방식은 회고입니다. 이것은 반성과 조정을 위한 기본 도구입니다. 모든 스프린트가 끝나면 팀과 함께 시간을 내어 작업 완료 방법, 품질 전달 방법, 효율성 극대화 방법, 낭비 최소화 방법 및 용량 증가 방법을 개선하십시오. 개선 방안을 찾았을 때 모든 문제를 즉시 해결하려고 하지 마십시오. 가장 큰 영향을 미치고 다음 스프린트에서 구현할 수 있는 항목을 식별합니다. 측정하고 관찰합니다. 그것이 원하는 영향을 미쳤다면 잠그고 작업 방식과 완료의 정의에 기록하십시오. 작동하지 않으면 다시 생각하십시오. 다가오는 스프린트에 포함되지 않는다는 교훈은 주차하고 다음 스프린트에서 주의를 끌 수 있도록 우선 순위를 지정할 수 있습니다.

프로세스를 조정합니다. 작동하지 않는 모든 것을 제거하십시오. 장애물을 제거하십시오. 애자일 팀으로서의 성숙도는 허용하면 끝이 없습니다.

애자일 프로젝트 관리를 넘어서

프로젝트가 전달된 후 어떤 일이 발생하는지 아는 것이 중요합니다. 지원 및 유지 관리는 프로젝트가 고객의 손에 들어오면 성능을 유지하는 데 중요합니다. 고객 피드백은 향후 릴리스에 반영될 수 있습니다. 그리고 고객의 문제는 적절하게 처리됩니다. 프로젝트는 독특하고 시간이 제한된 노력입니다. 그것이 제공하는 제품은 프로젝트 팀이 해산된 후에도 수명이 있습니다. 제품이 활성화되면 지원할 수 있는지 확인하십시오.

애자일 프로젝트는 보다 전통적인 접근 방식과 공존합니다. 예산 통제 및 이해 관계자 가시성에 대한 요구 사항과 유연성 및 응답성의 Agile 목표 간의 균형을 유지합니다.

거버넌스 프레임워크 또는 Agile 거버넌스 모델은 Scrum과 같은 표준 Agile 프로세스와 함께 사용됩니다. 두 가지 특정 방식으로 작동합니다.

• 개발 반복(스프린트) 외부에서 발생하는 프로세스를 명확히 하여 Agile 프로젝트에 대한 래퍼를 제공합니다. 여기에는 프로젝트 시작의 성공적인 완료와 결정 및 계획의 적절한 검증을 위한 명확한 기준을 제공하는 것이 포함됩니다.
• 표준 애자일 프로세스의 특정 부분에 대한 강조점을 바꾸고 거버넌스가 필요하거나 거버넌스를 지원하는 특정 원칙과 기술을 강조합니다.

오늘날과 같이 끊임없이 변화하는 세상에서 조직과 기업은 프로젝트를 제공하는 데 보다 유연한 접근 방식을 채택하고 보다 민첩하게 되기를 원합니다. 그러나 프로젝트 및 프로그램을 제공하고 기존의 공식 프로젝트 관리 프로세스가 이미 존재하는 조직의 경우 많은 애자일 접근 방식의 비공식성이 위협적이며 때로는 너무 위험한 것으로 인식됩니다. 이러한 프로젝트 중심 조직에는 성숙한 애자일 접근 방식(프로젝트 제공 개념 내 민첩성)이 필요합니다. 애자일 프로젝트 관리 .

Agile 도입으로 배우고 성장하십시오. 당신의 팀이 편안하게 여기는 일만 하고, 그들의 목소리가 들리는지 확인하고, 그들의 요청에 따라 행동하십시오. 적절한 시기에 팀이 새롭고 더 가치 있는 기술을 채택하도록 격려하십시오. 비즈니스와 협상하고 애자일 조직이 된다는 것이 무엇을 의미하는지 이해하도록 격려하십시오.

여행을 즐기세요.