연속 계획 살펴보기

완료됨

연속 계획은 8개의 DevOps 기능 중 하나입니다.

연속 계획이 필요한 이유 살펴보기

2000년에서 2005년 사이에 정부 기관에서 개발한 소프트웨어 애플리케이션의 사례 연구를 살펴보겠습니다. 이 프로젝트는 2005년 1월 공식적으로 폐기되어 완전한 실패로 판명되기 전까지 개발이 제대로 이루어지지 않았습니다. 프로젝트 실패로 인해 최소 $1억이 낭비되었을 뿐만 아니라 에이전시와 책임자는 여러 비판을 피할 수 없었습니다.

2006년에 두 번째 프로젝트가 시작됐고 비슷한 실패로 귀결되었습니다. 두 프로젝트는 기존의 계획된 총괄적 접근 방식을 통해 선행 설계 모델과 폭포 개발 방법론을 사용했습니다. 두 프로젝트는 결국 완성되지 못했고 수억 달러가 소모되었습니다.

Diagram shows the government agency project timeline.

해당 프로젝트가 실패한 원인이 무엇일까요?

  • 선행 설계 - 200명으로 구성된 팀이 6개월 동안 요구 사항을 작성했습니다.
  • 우선 순위 변경 - 프로젝트가 진행되는 도중에 재난이 발생하여 프로젝트 범위가 크게 변경되었으며, 300명으로 구성된 다른 팀이 6개월 동안 600페이지에 달하는 요구 사항을 작성하게 되었습니다.
  • 노력의 낭비 및 재작업으로 인해 팀원들이 지쳐 프로젝트 기한을 맞출 수 없었으며 70만 줄의 코드를 반복해서 작성하게 되었습니다.

2010년 12월에 Scrum Studio에서 프로젝트를 담당하게 되었습니다. 프로젝트 담당 직원을 기존의 400명에서 40명으로 축소했습니다. 600페이지의 요구 사항에서 670개의 사용자 스토리로 디자인이 수정되었습니다. 팀은 코드를 제공하고 2주마다 새로운 기능을 선보였습니다. 몇 번의 스프린트 이후 대략적인 일정을 예측하고 점진적인 비즈니스 변경을 계획할 수 있었습니다. 2011년 12월까지 코드 작성이 완료되었습니다.

세부적으로 계획하는 것이 왜 어려울까요?

앨런 튜링은 2차 세계 대전 중에 에니그마 기계라는 암호화 디바이스를 해독하기 위해 머신을 개발했습니다.

튜링은 생명을 구하려는 목적으로 계속 새로운 암호를 해독해야 했습니다. 튜링은 겉으로 보이는 무한한 복잡성에 좌절해 해독을 포기하지 않았으며, 더 큰 결과를 얻기 위해서는 작은 세부 정보만 해독하면 된다는 것을 알았습니다.

“우리는 가까운 미래밖에 내다보지 못하지만, 해야 할 일들이 많다는 것은 알고 있다.”

대형 소프트웨어 프로젝트는 항상 복잡합니다. 하지만 복잡성에 압도되면 안 됩니다. 그보다는 간단한 용어와 같이 명확한 부분부터 실행해야 합니다.

OKR(목표 및 주요 결과)에 따라 명확한 방향, 초점, 민첩성을 갖고 지속적이고 효과적으로 계획

연속 계획을 정의하기 전에 명확한 방향과 초점 및 민첩성을 갖고 지속적이고 효과적으로 계획하는 데 도움이 되는 중요한 개념 및 프레임워크를 살펴봐야 합니다.

OKR(목표 및 주요 결과)은 경영진이 설정한 전략적 목표를 수행 팀의 일상적 업무와 연결하도록 설계된 목표 설정 프레임워크입니다.

Important

OKR은 가능한 최상의 결과를 파악하고 실제 성공이 어떤 것인지 명확하게 하는 데 도움이 됩니다.

OKR은 일반적으로 예리한 초점과 민첩성을 갖출 수 있도록 분기별로 수립됩니다.

목표는 방향을 제시하고 주요 결과는 측정이 가능해야 합니다. 다시 말해 마지막에 결과를 살펴봤을 때 논쟁의 여지없이 목표를 수행했는지 여부를 확인할 수 있어야 합니다. 성공인가? 실패인가? 단순하고 어떤 판단도 개입되지 않습니다.

OKR은 일관성과 명료성을 제시할 수 있도록 조직 내의 모든 팀에 맞게 현지화됩니다.

OKR이란 무엇일까요?

OKR에는 세 가지 중요한 측면이 있습니다.

  • OKR은 명확한 목표를 정의하기 위한 프레임워크를 구성하여 조직의 모든 수준에서 의도 및 방향을 명확하게 제공합니다.

  • OKR은 측정 가능한 주요 결과로 보강됩니다. 주요 결과는 성공을 측정하는 결과입니다.

  • OKR은 결과를 중심으로 하는 문화를 조성하여 단순히 목표를 수행하는 사고방식에서 결과 중심적 사고방식으로 확실히 전환하도록 지원합니다.

OKR 예시

OKR 예시는 다음과 같습니다.

목표: 1970년까지 달에 우주 비행사를 보냅니다.

주요 결과:

  1. 1965년까지 무게가 18,000kg 미만인 우주선을 제작합니다.
  2. 1967년까지 우주 비행사에게 달 착륙을 훈련시킵니다.
  3. 달에 우주선을 성공적으로 착륙시킵니다.
  4. 우주 비행사를 안전하게 지구로 복귀시킵니다.

이 OKR 예제는 1970년까지 우주 비행사를 달로 보내기 위한 목표를 제시합니다.

참고

목표는 이해하기 쉽고, 명확한 방향을 설정하며 동기를 제공해야 합니다.

해당 예에서 주요 결과는 목표의 성공을 측정하는 진행률을 측정한 것입니다.

참고

주요 결과는 측정 가능해야 하며 목표를 달성하는 방법을 제시해야 합니다.

OKR의 주요 혜택

OKR의 5가지 주요 혜택은 다음과 같습니다.

  • 집중: 모든 목표가 한 줄로 표현되어야 합니다. 주요 결과는 목표당 5개 이하여야 합니다.
  • 일관성: 관리자와 기여자 모두 일상적인 업무를 조직의 전사적 비전과 연결합니다. 이러한 연결을 일관성이라고 하며 그 가치는 아무리 강조해도 지나치지 않습니다.
  • 약속: 합의된 모든 약속을 수행할 수 있도록 일정과 리소스가 조정됩니다.
  • 추적: 최고 기업이 목표별 관리를 채택하는 이유는 목표 수행에서 결과까지 OKR을 할 수 있기 때문입니다. 모든 OKR은 작성될 때 설정된 메트릭을 통해 추적이 가능해야 합니다.
  • 스트레칭: OKR은 본질적으로 조직이 가능하다고 여겼던 것보다 조금 더 나아가도록 노력하게 합니다.

연속 계획과 정적 계획 비교

연속 계획은 기획자, 설계자, Agile 팀이 지속적으로 기업 전체에 계획을 통합해야 하는 방법입니다.

연속 계획에서 스크럼 기반 계획 방법 및 새로운 디자인을 통해 팀은 실행 수준에 대한 계획을 구체화할 수 있습니다.

변화에 탄력적으로 대응할 수 있지만 명확한 비전과 목적을 가지는 상위 수준의 계획을 수립하는 것이 중요합니다.

폭포 개발 방법론과 Agile 개발 방법론에 대한 타협의 삼각형을 보면 연속 계획과 정적 계획의 차이를 알 수 있습니다.

정적 방법론에서는 범위에 대한 계획이 고정되어 있습니다. 프로젝트에 소요되는 시간과 비용을 스스로 결정해야 합니다.

연속 계획 원칙을 사용하는 Agile 방법론에서는 업무 목표를 충족하는 데 필요한 시간이 고정됩니다. 유일하게 협상 가능한 부분은 범위입니다.

Diagram shows the iron triangle of tradeoffs for Waterfall vs. Agile development methodologies.

이 삼각형은 일반적으로 시간, 리소스, 기능을 제시합니다. Gartner에서는 기간과 비용이 상관 관계가 있고 품질이 종종 누락되기 때문에 해당 표현에 품질을 추가했습니다.

그러나 두 방식의 성공은 어떨까요?

Diagram shows a comparison between the success rates of Agile and Waterfall projects. 9% of the Agile projects failed, 39% succeeded, and 52% were challenged. 29% of the Waterfall projects failed, 11% were successful, and 60% were challenged.

Agile 프로젝트의 성공률이 높은 이유는 소규모 일괄 처리 릴리스를 통해 정보를 얻을 기회가 증가하기 때문입니다.

네 가지 사항을 기억해야 합니다.

  • 비즈니스 요구 사항은 예고 없이 지속적으로 변합니다.
  • Agile에는 비즈니스 변화를 따라잡을 수 있는 계획 메커니즘이 있습니다.
  • 높은 성과를 내는 팀은 그만큼 잘못된 방향으로 빠르게 진행하기 쉽습니다.
  • 정보를 확보하면 위험을 줄일 수 있습니다.

폭포 및 Agile 두 가지 방법론 모두 완벽하지 않습니다. Agile이 해당 기간에 30% 더 성공적이었을 뿐입니다.

연속 계획의 6가지 원칙 살펴보기

연속 계획에는 6가지 원칙이 있습니다.

  1. 가치 단순성
  2. Agile Software Development에 대한 매니페스트
  3. 디자인 고려
  4. 반복 및 증분 개발
  5. 간결한 관리
  6. 추정 정확도

연속 계획 원칙 1: 가치 단순성

연속 계획의 첫 번째 원칙은 가치를 단순화하는 것입니다.

“쉽게 설명할 수 없다면, 제대로 이해한 것이 아니다.”

-알베르트 아인슈타인

연속 계획 원칙 2: Agile Software Development에 대한 매니페스트

연속 계획의 두 번째 원칙은 Agile Software Development에 대한 매니페스트입니다.

매니페스트는 소프트웨어의 제공에 대한 것입니다. 프로젝트 관리나 디자인이 아닌 소프트웨어 개발에 관한 것입니다. 매니페스트는 연속 계획과 DevOps의 핵심입니다.

Microsoft는 소프트웨어를 개발하고 다른 이들의 소프트웨어 개발을 지원함으로써 더 나은 소프트웨어 개발 방법을 찾고 있습니다. 이러한 작업을 통해 다음과 같은 가치를 얻을 수 있습니다.

  • 프로세스와 도구에 대한 개인 및 상호 작용
  • 포괄적인 문서에 대한 작업 소프트웨어
  • 계약 협상을 통한 고객 협업
  • 계획에 따른 변화에 대응

연속 계획 원칙 3: 디자인 고려

연속 계획의 세 번째 원칙은 디자인을 고려하는 것입니다.

디자인 고려는 혁신에 대한 사용자 중심의 접근 방식을 통해 이루어집니다. 경계를 설정하고 낭비를 줄이기 위해 실행 가능성, 타당성, 원활성의 교집합에 중점을 둡니다.

Diagram explains design thinking. Design thinking establishes the boundaries of the product early (often called the minimal viable product or “MVP”). It focuses on the intersection between business viability, technical and budget feasibility, and desirability. This intersection is where innovation happens.

연속 계획 원칙 4: 반복 및 증분 개발

연속 계획의 네 번째 원칙은 반복 및 증분 개발입니다.

어떤 사람들은 어떤 결과를 얻게 될지 모르는 것을 두려워합니다. 반복 개발은 반복적인 피드백 루프 내에서 요구 사항과 우선 순위를 관련자에게 전달하여 해당 문제를 해결합니다. 각 반복은 완전하고, 사용 가능하며 사용자에게 유용합니다. 반복 개발은 기능을 더 많이 추가하며 가장 중요한 기능을 우선적으로 추가합니다.

연속 계획 원리 5: 간결한 관리

연속 계획의 다섯 번째 원칙은 간결한 관리입니다.

가치는 최종 고객의 관점에서 정의됩니다. 프로세스 내에서 가치 스트림을 파악할 수 있으며 고객에게 가치가 전달되지 않는 단계는 낭비로 판단되어 제거됩니다.

해당 프로세스는 반복되어 지속적인 개선을 통해 완벽한 상태로 나아가게 됩니다.

Diagram shows the stages of the process: identify value, map the value stream, create flow, establish pull, and seek perfection.

연속 계획 원칙 #6: 추정 정확도

연속 계획의 여섯 번째 원칙은 추정 정확도입니다.

추정이란 시간이 얼마나 걸리는지, 비용이 얼마나 드는지, 얼마나 많은 기능을 제공할 수 있는지에 대한 분석적 예측입니다. 추정에는 정확도와 정밀도라는 두 가지 특성이 있으며 두 특성은 서로 전혀 관련이 없습니다. 추정은 엔지니어링 팀의 관할입니다.

목표는 비즈니스 요구 사항에 대한 설명입니다. 얼마나 많은 시간을 투자할지, 얼마나 많은 비용을 투자할지, 얼마나 많은 기능을 제공하고자 하는지를 의미합니다. 목표는 비즈니스의 관할입니다.

약정은 특정 날짜까지 기능 및 품질을 제공하겠다는 약속입니다. 약정은 공동의 관할입니다.

중요

연속 계획의 목표는 추정, 목표 및 약정에 맞춰 일관성을 유지하는 것입니다. 일관성을 유지하지 않으면 조직 내부 및 외부의 기대를 충족하지 못합니다.

OKR과 스크럼 간의 관계 설명

이제 OKR이 무엇인지와 OKR을 사용해야 하는 이유뿐만 아니라 연속 계획에 대한 내용을 이해했으므로 이 둘 사이의 연결에 대해 알아보겠습니다.

OKR과 같은 기술을 사용하여 작업을 구조화하면 최소한 단기적으로는 불확실성이 줄어듭니다. OKR은 연계 방식으로 정의되기 때문에 관리자가 관리 스타일을 표현하는 방법을 바꾸게 됩니다.

OKR과 같은 기술은 권위주의적인 관리 스타일에서 벗어나 경험을 시작하는 빠르고 효율적인 방법입니다.

Objectives and key results lead to epics. Epics help define features, which involve user stories, and result in a development task.