타임박스

Timeboxing
다음에 대한 시리즈 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
연습
도구들
지식의 표준 및 본문
용어집
윤곽선

애자일 원칙에서 타임박스는 계획된 활동이 이루어지는 시간 박스라고 불리는 활동에 고정적이고 최대 시간의 단위를 할당한다.애자일 원칙 기반 프로젝트 관리 접근법과 개인 시간 관리에 사용된다.

프로젝트 관리 중

타임박스는 프로젝트 계획 기법으로 사용된다.일정은 여러 개의 별도 기간(시간 박스)으로 나뉘며, 각 파트에는 자체 산출물, 마감일, 예산이 있다.[citation needed]때로는 스케줄로 독립 변수(SAIV)라고도 한다.[1]"타임복싱은 시간이 거의 걸리지 않고 동일한 시간대에 맞출 수 있는 다단계 프로젝트나 작업에서 가장 잘 작동한다.예측 가능한 완료 시간적 틀이 있는 직무의 경우에도 이행할 가치가 있다고 말했다.[2]

스코프 고정의 대안으로

프로젝트 관리에서 일반적으로 시간(때로는 일정), 비용(때로는 예산) 및 범위의 세 가지 제약조건이 있다고 간주된다.[3][4][5][6][7] 품질은 종종 네 번째 제약조건(삼각형의 중간으로 표시됨)[8][9][10]으로 추가되며, 한 제약조건의 변경이 다른 제약조건에 영향을 미칠 것이라는 가정이다.[6]

타임박스가 없으면 프로젝트는 대개 고정된 범위까지 작용하는데, [11]이 경우 일부 산출물은 계획된 기간 내에 완성할 수 없다는 것이 명확해지면 기한을 연장해야 한다(고정 범위를 완성하는 데 더 많은 시간을 허용하기 위해), 또는 더 많은 사람이 참여해야 한다(고정 범위를 동시에 완성하기 위해).종종 두 가지 모두 발생하여 배송이 지연되고 비용이 증가하며 종종 품질이 저하된다(신화적 인월 원칙에 따름).

타임박스로 마감일이 정해져 있어 범위를 줄여야 한다는 의미다.이는 조직이 가장 중요한 산출물을 먼저 완성하는 데 집중해야 함을 의미하기 때문에, 타임박스는 종종 산출물의 우선순위를 정하는 계획(예: MoSCoW 방법)과 연계된다.[12]

리스크 관리

타임박스는 불확실한 업무/시간 관계, 즉 마감일을 쉽게 넘길 수 있는 작업을 명시적으로 식별하기 위해 리스크 관리의 한 형태로 사용된다.시간 제약은 종종 계획의 주요 동력이므로 프로젝트 또는 하위 프로젝트의 중요 경로를 고려하지 않고 변경해서는 안 된다.즉, 마감일을 맞추는 것이 보통 중요하다.마감 기한을 놓친 위험 요소에는 프로젝트의 업스트림, 프로젝트 내의 계획 오류, 팀 관련 문제 또는 계획의 잘못된 실행이 포함될 수 있다.업스트림 이슈에는 프로젝트 임무의 변경이나 경영진의 지원/지원 등이 포함될 수 있다.일반적인 계획 오류는 부적절한 작업 분류로, 작업 수행에 필요한 시간을 과소평가할 수 있다.팀 관련 문제에는 팀 간 의사소통 문제, 경험 부족 또는 필수 교차 기능 부족, 헌신/구동력 부족(즉, 팀 구성 및 관리 부족)이 포함될 수 있다.

마감일을 유지하기 위해 3중 제약조건에 대한 다음과 같은 조치를 공통적으로 평가한다.

  • 범위 축소: 낮은 영향의 감소 요구 사항(사용자가 직접 놓칠 수 없는 요구 사항)
  • 여기서 시간은 고정된 제약이다.
  • 비용 증가: 예: 초과 근무 또는 리소스 추가

소프트웨어 개발의 채택

많은 성공적인 소프트웨어 개발 프로젝트들은 타임박스, 특히 작은 프로젝트들을 사용한다.[13]80년대 듀폰에서 타임박스 도입으로 개발자 생산성이 3배 이상 증가했다.[14]어떤 경우에는 규격만 완성할 것으로 추정되는 시간 내에 신청서가 완전히 전달되었다.[14]그러나 스티브 맥코넬은 모든 제품이 적합한[14] 것은 아니며 타임박스는 고객이 품질을 따지지 않고 특징 절단에 동의한 후에만 사용해야 한다고 주장한다.[14]가장 큰 규모의 프로젝트들 중 강력한 채택을 위한 증거는 거의 없다.[13]

타임박스는 몇 가지 주목할 만한 소프트웨어 개발 방법론에 의해 채택되었다.

신속한 변화를 위한 소프트웨어 개발 옹호자 - 계획 중심에서 가치 주도형 개발로 전환품질과 시간은 정해져 있지만 범위 내에서 유연성이 허용된다.가장 중요한 기능을 제공하면 먼저 폭포 모델보다 투자 수익률이 더 빨라진다.[7]

세부 명세서의 부족은 일반적으로 시간 부족 또는 원하는 최종 결과(솔루션)에 대한 지식 부족의 결과물이다.많은 유형의 프로젝트, 특히 소프트웨어 엔지니어링에서는 실현 단계 시작 전에 모든 요건과 사양을 분석하고 정의하는 것이 불가능하다.타임박스는 마감일이 가장 중요하고 모든 요건이 사전에 완전히 명시되지 않은 프로젝트에 유리한 계약 유형이 될 수 있다.이를 통해 프로젝트 중에 발견된 새로운 피드백이나 통찰력을 최종 결과에 반영할 수 있다.[12]

개인 시간 관리에서

주요 기사:시간차단

타임박스는 개인 작업에 사용할 수 있으며, 이 경우 시간(예: 30분)의 축소와 결과물(예: 프로젝트 결과물 대신 집안일)을 사용하며, 종종 시간차단이라고 불린다.

개인 타임박스는 또한 창의성과 집중력을 높일 수 있는 (긴급감이나 압박감을 조성하여) 완벽주의 경향을 억제하는 데 도움을 주는 생명 해킹의 역할을 한다고 한다.[21]

다른 방법과의 관계

타임박스는 다른 개인 시간 관리 방법에서 구성 요소 역할을 한다.

참조

  1. ^ Boehm, Barry W.; Boehm, Barry; Turner, Richard (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley Professional. ISBN 9780321186126.
  2. ^ "Timeboxing – why you should use it?". Firmbee. 2022-01-17. Retrieved 2022-01-25.
  3. ^ 2006-08-20년 프로젝트 관리에 대한 Rod Hutchings의 기사, Wayback Machine(2008년 10월 22일)에 보관된 2009-02-16년 프로젝트 관리에 대한 3가지 제약 사항
  4. ^ Chatfield, Carl. "A short course in project management". Microsoft.
  5. ^ Dobson, Michael (2004). The triple constraints in project management. Vienna, Va: Management Concepts. ISBN 1-56726-152-3.
  6. ^ a b Kanabar, Vijay (2008). MBA Fundamentals: Project Management. New York: Kaplan Pub. p. 51. ISBN 978-1-4277-9744-5.
  7. ^ a b Leffingwell, Dean (2011). Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley. pp. 17–19. ISBN 978-0-321-63584-6.
  8. ^ Snedaker, Susan; Nels Hoenig (2005). How to Cheat at IT Project Management. Syngress. ISBN 1-59749-037-7.
  9. ^ Beck, Kent (2000). Extreme programming eXplained: embrace change. Reading, MA: Addison-Wesley. pp. 15–19. ISBN 0-201-61641-6.
  10. ^ Dangelo, Mark (2005). Innovative relevance: realigning the organization for profit: it is not a battle for the "shore lines" - it's a struggle for purpose. New York: iUniverse. p. 53. ISBN 978-0-595-67081-9.
  11. ^ Godin, Seth. Getting Real: The smarter, faster, easier way to build a successful web application. 37signals.
  12. ^ a b c Jennifer., Stapleton (1997). DSDM, dynamic systems development method: the method in practice. Harlow, England: Addison-Wesley. ISBN 0201178893. OCLC 36755892.
  13. ^ a b 모든 프로젝트 유형에 대해 권투는 23위를 차지했으며 "매우 우수 관리 기준"으로 평가되었으며, 소규모(1000 기능 포인트) 프로젝트의 경우 7위를 차지했으며, 설문조사에 의해 "우수 관리 기준"으로 평가되었다.
  14. ^ a b c d e McConnell, Steve (1996). Rapid Development: taming wild software schedules. Redmond, Wash: Microsoft Press. pp. 575–583. ISBN 1-55615-900-5.
  15. ^ Poppendieck, Mary (2010). Leading Lean Software Development: Results are not the Point. Upper Saddle River, NJ: Addison-Wesley. pp. 137–140. ISBN 978-0-321-62070-5.
  16. ^ Coplien, James (2010). Lean Architecture for Agile Software Development. Chichester Hoboken, N.J: Wiley. p. 25. ISBN 978-0-470-68420-7.
  17. ^ Cohn, Mike (2010). Succeeding with Agile: Software Development using Scrum. Upper Saddle River, NJ: Addison-Wesley. pp. 257–284. ISBN 978-0-321-57936-2.
  18. ^ a b Schwaber, Ken (2009). Agile Project Management with Scrum. New York: O'Reilly Media, Inc. ISBN 978-0-7356-3790-0.
  19. ^ Leffingwell, Dean (2011). Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley. p. 15. ISBN 978-0-321-63584-6.
  20. ^ Beck, Kent (2000). Extreme programming eXplained: embrace change. Reading, MA: Addison-Wesley. pp. 85–96. ISBN 0-201-61641-6.
  21. ^ Pash, Adam (2011). Lifehacker the guide to working smarter, faster, and better. Indianapolis, Ind: Wiley. Hack 29. ISBN 978-1-118-13345-3.
  22. ^ Nöteberg, Staffan (2009). Pomodoro Technique Illustrated. Raleigh, N.C: Pragmatic Bookshelf. ISBN 978-1-934356-50-0.
  23. ^ Hunt, Andrew (2008). Pragmatic thinking and learning: refactor your wetware. Raleigh: Pragmatic. ISBN 978-1-934356-05-0.