공학을 공부하고 있거나 엔지니어라면 해당 분야에서 많이 사용되는 "백로그"라는 단어를 들어보셨을 것입니다.
그러나 백로그가 무엇이며 엔지니어링 프로젝트에서 백로그가 왜 그렇게 중요한지 궁금한 적이 있습니까?
백로그는 아직 완료되지 않은 작업이나 주문 목록 그 이상입니다.
프로젝트를 성패시킬 수 있는 강력한 도구이며, 잘 사용할 줄 알면 프로젝트를 성공시킬 수 있습니다.
이 블로그 게시물에서는 다양한 유형, 역할 및 중요성을 포함하여 엔지니어링의 백로그에 대해 이야기합니다.
따라서 엔지니어링 프로젝트를 다음 단계로 끌어올리고 싶다면 계속 읽으십시오.
엔지니어링에서 백로그 정의 및 중요성 이해
공식적인 정의:
1. 미래의 작업과 이익을 약속하는 주문의 누적 2. 처리되지 않은 자재 또는 수행되지 않은 작업의 누적.
엔지니어링 및 프로젝트 관리에서 백로그는 수행해야 하는 작업과 작업의 중요성 목록입니다.
팀이 범위 및 비즈니스 우선 순위를 계획하는 데 너무 많은 시간을 소비하기 전에 세부 사항을 계획하는 데 도움이 됩니다.
할 일 목록:
제품 팀은 다음에 작업할 프로젝트를 결정하고 백로그는 개발 주기의 모든 팀에서 제품 제공을 위해 작업할 때 작업을 추적하고 우선 순위를 지정하는 데 사용됩니다.
가장 중요한 항목은 제품 백로그의 맨 위에 있으므로 팀은 먼저 무엇을 작업해야 하는지 알고 있습니다.
사용자 스토리, 버그 수정 및 제품 업데이트는 모두 제품 백로그에 넣는 일반적인 사항입니다.
개발팀은 백로그를 한꺼번에 처리하지 않습니다.
대신, 그들은 "스프린트"라고 하는 작은 조각들을 한 번에 수행합니다.
각 스프린트의 작업이 명확하고 실행 가능한지 확인하기 위해 백로그 그루밍 또는 개선이 정기적으로 수행됩니다.
백로그의 중요도:
우선순위가 잘 지정된 애자일 백로그는 계획 릴리스 및 반복을 더 쉽게 만들고 이해 관계자 및 다른 팀과의 기대치를 설정하며 엔지니어링 시간을 고정 자산으로 만듭니다.
잘 조직된 제품 백로그는 팀이 프로젝트의 목표와 요구 사항을 명확하게 정의하고 이해하고, 작업의 중요성에 따라 작업의 우선 순위를 지정하고, 다음에 작업해야 할 작업에 대해 정보에 입각한 결정을 내리고, 변화하는 요구 사항과 우선 순위에 지속적으로 적응하는 데 도움이 됩니다. 개발 프로세스를 보다 유연하고 효율적으로 만듭니다.
백로그 관리:
백로그 관리는 사용자가 가장 중요한 기능을 먼저 얻을 수 있도록 팀에서 백로그를 추가, 변경, 정리 및 순위 지정하는 프로세스입니다.
백로그가 가득 차면 제품을 시장에 출시하는 데 시간이 오래 걸리고 품질이 떨어지게 되어 소프트웨어 개발에 피해를 줄 수 있습니다.
백로그를 복원하는 것은 프로젝트를 정상 궤도에 올려 놓고 성공적인 소프트웨어 개발에 매우 중요한 창의성을 육성하는 핵심 부분이 될 수 있습니다.
백로그는 다음을 의미할 수도 있습니다.
회계 및 재무에서 백로그는 채워야 하는 판매 주문이나 처리해야 하는 재무 문서와 같이 수행해야 하는 대량의 작업입니다.
백로그는 상황에 미치는 영향에 따라 좋거나 나쁠 수 있습니다.
한편으로는 판매가 증가하고 있음을 의미할 수 있지만, 다른 한편으로는 회사는 효율성이 떨어지거나 수요를 충족할 수 없음을 의미할 수 있기 때문에 일반적으로 백로그를 피하려고 합니다.
백로그의 힘 잠금 해제: 마감일을 피하고 스트레스를 높이는 방법!
아직도 이해하기 어렵나요? 관점을 조금 바꿔보겠습니다.
시간과 예산에 맞춰 일을 끝내는 데 지쳤습니까? 다가오는 마감일의 흥분과 공황의 달콤한 맛이 그립습니까? 음, 걱정하지 마세요. 저는 무엇을 해야 할지 알고 있습니다: 백로그! 그래 너가 옳아.
그 명령과 작업이 쌓이게 놔두면 곧 당신이 무엇을 해야할지 알고 있는 것보다 더 많은 일을 하게 될 것입니다.
업무 처리에 작별을 고하고 스트레스로 인한 심장마비에 안부를 전하세요.
누가 돈을 벌고 효율적이 되려고 합니까?
좋아, 그건 그냥 TV 광고처럼 보이도록 만든 농담일 뿐이야.
이제 설명으로 돌아가 봅시다.
제품 백로그 대 스프린트 백로그: 주요 차이점
제품 백로그와 스프린트 백로그는 Agile 방법론에서 소프트웨어 개발 프로젝트를 구성하는 두 가지 중요한 도구입니다.
두 백로그는 모든 소프트웨어 개발 프로젝트의 중요한 부분이지만 범위와 목표는 다릅니다.
제품 백로그:
제품 소유자는 프로젝트가 시작되기 전에 프로젝트에 추가할 기능 목록을 만듭니다.
이 목록을 "제품 백로그"라고 합니다.
기본 목표와 원칙 및 변경 가능성이 더 높은 기타 부분을 포함하여 전체 제품에 대한 개요를 제공합니다.
항상 변화하고 있으며 시장의 변화나 고객의 피드백을 반영하기 위해 언제든지 변경될 수 있습니다.
제품 백로그는 개발 팀과 이해 관계자가 무엇을 왜 구축해야 하는지에 대해 이야기하는 가장 중요한 방법 중 하나입니다.
또한 전체 개발 팀이 프로젝트 전체에서 사용할 수 있는 단일 정보 소스를 제공하는 살아있는 문서이기도 합니다.
스프린트 백로그:
반면에 스프린트 백로그는 각 애자일 스프린트 동안 완료될 수 있는 제품 백로그의 항목만 포함하는 제품 백로그의 하위 집합입니다.
특정 시간 동안 제품의 기능을 더욱 돋보이게 합니다.
스프린트 백로그는 제품 백로그의 항목으로 구성되지만 각 애자일 스프린트 동안 완료할 수 있는 항목으로만 구성됩니다.
스프린트 계획 회의 중에 팀은 스프린트 중에 작업할 제품 백로그의 항목을 결정합니다.
여기에서 스프린트 백로그가 만들어집니다.
모두가 동의하면 전체 스프린트에 대한 항목과 완료 단계가 설정됩니다.
스프린트 백로그는 스프린트 계획 회의 중에만 변경할 수 있다는 점에서 제품 백로그와 다릅니다.
차이점:
- 범위: 제품 백로그는 프로젝트에 추가할 모든 기능에 대한 개요를 제공하는 반면 스프린트 백로그는 각 애자일 스프린트에서 수행해야 하는 작업에 중점을 둡니다.
- 목적: 제품 백로그는 개발 팀과 이해 관계자 간의 커뮤니케이션 도구로, 무엇을 구축해야 하고 왜 구축해야 하는지에 대한 공유된 이해를 제공합니다.
개발 팀은 스프린트 백로그를 사용하여 특정 스프린트 동안 작업을 계획하고 수행합니다.
- 유연성: 제품 백로그는 시장이나 고객 피드백의 변화를 반영하기 위해 언제든지 업데이트할 수 있는 살아있는 문서입니다.
스프린트 중에는 스프린트 백로그가 고정되며 스프린트 계획 회의 중에만 변경할 수 있습니다.
백로그 관리 및 유지: 역할 및 책임
백로그를 추적하고 관리하는 것은 애자일 소프트웨어 개발의 핵심 부분입니다.
다음은 백로그를 관리하고 유지하는 데 있어 가장 중요한 역할과 책임입니다.
제품 소유자의 책임:
- 제품 소유자는 항목을 사용자 스토리로 분류하는 것을 포함하여 제품 백로그를 관리하고 유지 관리할 책임이 있습니다.
- 콘텐츠, 가용성 및 주문을 포함하여 제품 백로그를 구성하고 유지 관리할 책임이 있습니다.
- 백로그가 전체 프로젝트 목표와 일치하고 팀이 중요하고 가치 있는 작업을 수행하고 있는지 확인합니다.
개발팀의 책임:
- 개발팀은 제품 백로그를 기능의 점진적인 부분으로 바꾸는 일을 담당합니다.
- 그들은 스프린트 백로그를 소유하고 포함할 항목과 우선 순위 지정 방법을 결정할 책임이 있습니다.
- 스프린트 계획 세션 동안 제품 백로그 항목에 대한 추정치를 제공합니다.
- 그들은 스프린트 목표를 실현하면서 제품 증분을 제공하기 위한 계획과 함께 스프린트를 위해 선택된 일련의 제품 백로그 항목인 스프린트 백로그를 만듭니다.
- 그들은 Sprint Backlog에서 작업을 실행하고 새로운 정보를 사용할 수 있게 되면 이를 수정 및 업데이트합니다.
스크럼 마스터의 업무는 다음과 같습니다.
- 스크럼 마스터는 스크럼 이벤트를 촉진하고 모든 사람이 스크럼 이론, 관행, 규칙 및 가치를 이해하도록 돕습니다.
- 그들은 백로그를 변경하는 과정에 관여할 수 있지만, 스스로 변경할 수 있는 권한은 없습니다.
협업 및 서로 대화:
- 제품 소유자는 제품 백로그를 유지하는 데 전적으로 책임이 있지만, 제품 백로그를 개선하는 것은 스크럼 팀의 나머지 구성원이 지금까지 프로젝트에 대한 지식, 통찰력 및 경험으로 기여하는 공동 작업이어야 합니다.
- 전체 팀이 작업하고 제품 백로그에 기여하지만 이를 작동하는 소프트웨어로 전환하는 것은 궁극적으로 개발 팀의 몫입니다.
즉, 제품 소유자는 제품 백로그를 담당하고 개발팀은 스프린트 백로그를 담당합니다.
스크럼 마스터는 스크럼 회의를 진행하고 모든 사람이 스크럼의 이론, 관행, 규칙 및 가치를 이해하도록 합니다.
팀은 함께 작업하고 대화하여 두 백로그가 모두 정확하고 최신이며 프로젝트의 전체 목표와 일치하는지 확인합니다.
개발 팀은 제품 백로그의 항목을 작동하는 소프트웨어로 전환하는 일을 담당하고 제품 소유자는 백로그가 프로젝트의 전체 목표와 일치하는지 확인합니다.
백로그 개선 및 우선 순위 지정 기술
백로그 관리 및 유지: 역할 및 책임
백로그는 애자일 프로젝트 관리의 중요한 부분이며 관리하고 최신 상태로 유지해야 합니다.
이 기사에서는 제품 및 스프린트 백로그를 관리하고 추적할 때 스크럼 팀의 역할과 책임이 무엇인지에 대해 설명합니다.
제품 소유자 및 제품 백로그
제품 소유자는 비즈니스 요구 사항, 시장 및 기술에 따라 변경되는 살아있는 문서인 제품 백로그를 관리하고 업데이트하는 일을 담당합니다.
로드맵과 해당 요구 사항은 중요도에 따라 순위가 매겨진 개발 팀의 작업 목록인 제품 백로그를 만드는 데 사용됩니다.
가장 중요한 것은 맨 위에 있으므로 먼저 작업할 수 있습니다.
제품 소유자는 제품 백로그를 구성하고 최신 상태로 유지하는 일을 담당합니다.
여기에는 항목을 사용자 스토리로 분류하는 것이 포함됩니다.
그들은 백로그에서 작업을 주문하는 방법을 결정하고 프로젝트의 전체 목표에 부합하는지 확인합니다.
제품 소유자는 고객의 피드백이나 새로운 요구 사항에 따라 언제든지 백로그의 작업을 변경하거나 재정렬할 수 있습니다.
그러나 일단 작업이 진행되면 너무 많은 변화가 없어야 합니다.
제품 백로그를 정리하고 스프린트를 계획하는 세션 중에 스토리 포인트를 사용하여 PBI를 추정합니다.
이것은 크기에 대한 대략적인 생각일 뿐입니다.
제품 책임자는 개발 팀이 절충 사항을 이해하고 선택하도록 도와줌으로써 개발 팀에 영향을 미칠 수 있지만 최종 추정치는 작업을 수행할 사람들이 수행합니다.
개발팀 및 스프린트 백로그
개발팀은 제품 백로그의 항목을 함께 사용할 수 있는 기능으로 변환하는 일을 담당합니다.
제품 소유자가 제품 백로그를 관리하는 유일한 사람이지만 나머지 스크럼 팀은 지금까지 프로젝트에 대한 지식, 통찰력 및 경험을 공유하여 제품 백로그를 개선하는 데 도움을 주어야 합니다.
전체 팀이 작업하고 제품 백로그에 추가하지만 이를 사용할 수 있는 소프트웨어로 전환하는 것은 개발 팀의 일입니다.
개발팀은 제품 백로그의 하위 집합인 스프린트 백로그를 담당합니다.
스프린트 백로그에는 제품 백로그에서 가장 중요한 것뿐만 아니라 사용자 스토리, 작업, 사용 사례 및 테스트와 같이 수행해야 하는 기타 작업이 있습니다.
스프린트 백로그에서 개발자는 현재 스프린트 중에 수행할 간단한 작업을 찾을 수 있습니다.
또한 제품의 높은 수준의 사용자 가치를 설명하는 스토리와 사용자 스토리를 간단하고 실행 가능한 개발 단계로 세분화하는 세부 작업이 있습니다.
개발팀은 스프린트 백로그에 들어갈 내용과 각 항목의 중요성을 선택하는 일을 담당합니다.
사용자 스토리, 작업, 사용 사례, 테스트 및 선택한 제품 백로그 항목을 분류하는 기타 항목을 스프린트 백로그에 추가할 수 있습니다.
각 일일 스크럼 회의(매일 회의) 동안 팀원은 스프린트 백로그에서 계획된 작업에 대한 진행 상황을 검토하여 이 스프린트 목표를 달성하기 위한 궤도에 있는지 확인합니다.
로드맵의 기능에 중요한 버그나 변경 사항이 있는 경우 스프린트 백로그에서 우선 순위를 변경하거나 업데이트할 수 있습니다.
백로그 개선 및 우선 순위 지정 기술
애자일 프로젝트 관리에서 효과적인 백로그 개선 및 우선 순위 지정 기술을 사용하면 프로젝트의 결과와 작동 방식을 개선하는 데 도움이 될 수 있습니다.
백로그 개선은 사용자 기대치, 시장의 피드백 및 프로젝트 제공이 모두 동기화되도록 하는 지속적인 프로세스입니다.
백로그 그루밍 세션은 우선 순위를 재평가하고, 제품 백로그를 정리 및 구성하고, 스프린트 계획을 보다 생산적으로 만드는 데 사용됩니다.
백로그 구체화의 주요 이점은 목록의 맨 위에 있는 항목이 관련성이 있고 충분한 정보가 있으며 추정치가 있는지 확인하는 것입니다.
효과적인 우선 순위 지정은 백로그에 도달하기 훨씬 전에 시작됩니다.
먼저 제품에 대한 계획을 세워야 합니다.
이를 통해 팀은 공유된 목표 및 프로젝트 세트와 관련하여 얼마나 잘 수행하고 있는지 측정할 수 있습니다.
제품 백로그의 항목(예: 사용자 스토리, 버그, 스파이크 등)을 구성하여 올바른 순서로 빌드하고 릴리스할 수 있도록 백로그 우선 순위 지정이 필요합니다.
업종별 수주잔고 유형 및 관리
백로그 유형
제품 개발에는 기능을 중요도에 따라 배치하고 실행에 옮겨야 합니다.
이를 위해 사용되는 세 가지 주요 유형의 백로그가 있습니다.
- 제품 백로그.
제품 백로그는 아직 릴리스 우선 순위가 지정되지 않은 기능을 포함하는 제품의 장기 계획입니다.
새로운 정보와 피드백이 들어올 때마다 변화하는 살아있는 문서입니다.
비전을 수행할 수 있고 제품에 가치를 추가할 수 있는 특정 작업으로 세분화합니다.
- 릴리스 백로그.
릴리스 백로그는 특정 릴리스에서 제공될 기능을 나열하는 제품 백로그의 일부입니다.
제품 백로그에서 항목의 중요도와 수행 가능 여부를 기준으로 항목을 선택하여 작성됩니다.
- 스프린트 백로그.
스프린트 백로그는 특정 스프린트에서 제공될 기능을 나열하는 릴리스 백로그의 일부입니다.
항목의 중요도와 수행 가능 여부에 따라 릴리스 백로그에서 항목을 선택하여 작성됩니다.
다양한 산업의 백로그 관리
산업마다 백로그를 처리하는 방법이 다릅니다.
여기 몇 가지 예가 있어요.
- 소프트웨어 개발.
Scrum 또는 Kanban과 같은 민첩한 방법은 소프트웨어 개발에서 백로그를 처리하는 데 사용됩니다.
스크럼 팀은 "스프린트 백로그"에서 특정 작업을 수행하는 시간 제한 기간인 "스프린트"에서 작업합니다.
매일 팀은 일이 어떻게 진행되고 있고 어떤 문제가 있는지에 대해 이야기하는 "스탠드업" 회의를 가집니다.
Kanban에서 작업 항목은 작업이 진행 중인 위치를 보여주는 열과 함께 보드에 표시됩니다.
작업 항목이 여러 단계를 거치면 팀 구성원이 작업 항목을 한 열에서 다른 열로 이동합니다.
- 프로젝트 관리.
프로젝트 관리에서 Trello 및 Jira와 같은 도구를 사용하여 백로그를 추적할 수 있습니다.
이러한 도구를 사용하여 사용자는 프로젝트의 여러 단계를 보여주는 목록이 있는 보드를 만들 수 있습니다.
작업 항목은 다른 단계를 통해 이동할 때 이러한 목록에 추가하고 목록 간에 이동할 수 있습니다.
스크럼 및 백로그 관리
스크럼 제품 백로그
스크럼 제품 백로그는 중요도에 따라 순위가 매겨진 프로젝트의 항목, 기능 및 작업 목록입니다.
무엇이 필요한지에 대한 자세한 정보가 있어서는 안 됩니다.
대신 최종 요구 사항은 고객과 함께 스프린트 중에 설정됩니다.
제품이나 서비스를 제공하기 위해 수행해야 하는 작업을 보여주는 사용자 스토리를 스크럼 제품 백로그에 추가할 수 있습니다.
스크럼 제품 백로그의 모든 항목에는 고객을 위한 일종의 가치가 있어야 합니다.
스크럼 팀은 다른 사용자 역할 요약, 워크플로 설명, 사용자 인터페이스 지침, 스토리보드 또는 사용자 인터페이스 프로토타입과 같은 다른 아티팩트를 사용할 수도 있지만 스크럼 제품 백로그를 대체하지는 않습니다.
대신, 그들은 그것이 말하는 것을 추가하고 설명합니다.
물류 백로그
논의되는 내용에 따라 "물류 백로그"라는 용어는 다른 의미를 가질 수 있습니다.
공급망 관리에서 백로그는 고객이 주문했지만 아직 발송되지 않은 모든 제품입니다.
여기에는 작업 주문 번호, 제품 번호, 배송 날짜, 금액, 주문 상태 등이 포함됩니다.
백로그는 고객이 아직 채워지지 않은 주문에 대해 지불할 용의가 있음을 보여주기 때문에 비즈니스에 좋습니다.
그러나 기한을 지키지 못하고 주문이 제 시간에 배송되지 않으면 백로그가 이월 주문으로 바뀌어 비즈니스에 좋지 않을 수 있습니다.
항만 컨테이너 물류에서 적체란 코로나19 정책 등으로 인한 공급망 문제와 상품을 원하는 사람들의 증가로 인해 선적 컨테이너가 항구에 쌓이는 것을 말합니다.
이러한 종류의 물류 적체는 운송 시간을 더 오래 걸리게 하고 비즈니스에 더 많은 비용을 초래할 수 있습니다.
유지보수 백로그: 백로그란 무엇이며 백로그를 계산하는 방법은 무엇입니까?
팁: 필요한 경우 캡션 버튼을 켭니다. 구어에 익숙하지 않은 경우 설정 버튼에서 "자동 번역"을 선택하십시오. 좋아하는 언어를 번역할 수 있게 되기 전에 먼저 동영상의 언어를 클릭해야 할 수도 있습니다.
사용 사례
| 사용: | 설명: |
|---|---|
| 소프트웨어 개발: | 백로그는 종종 소프트웨어 개발에서 프로젝트의 진행 상황을 추적하는 데 사용됩니다. 여기에는 최종 제품을 만들기 전에 완료해야 하는 모든 기능, 버그 및 작업 목록이 있습니다. 팀은 백로그의 항목에 대해 작업합니다. 프로젝트에 가장 적합한 순서대로 백로그를 사용하여 수행해야 할 작업, 각 작업의 책임자 및 각 작업의 기한을 추적할 수 있습니다. 백로그는 소프트웨어 개발 팀이 할 수 있는 도구입니다. 그들이 고품질 제품을 제 시간에 배송하고 싶다면 없이는 안 됩니다. |
| 조작: | 제조에서 백로그는 재료와 제품이 생산 프로세스를 통해 이동하는 방식을 추적하는 데 사용할 수 있습니다. 예를 들어 백로그는 주문을 채우기 전에 완료해야 하는 미완성 제품의 수를 추적하기 위해 만들 수 있습니다. 백로그는 다음과 같을 수 있습니다. 생산 공정이 원활하게 진행되고 주문이 제 시간에 채워지는지 확인하는 데 사용됩니다. |
| 건설: | 백로그는 건설에서 프로젝트가 얼마나 진행되었는지 추적하고 모든 작업이 제 시간에 완료되었는지 확인하는 데 사용할 수 있습니다. 각 작업이 올바른 순서로 완료되고 프로젝트가 계획대로 진행되고 있는지 확인하기 위한 백로그. |
| 재원: | 재무에서 백로그는 아직 처리되지 않았으며 처리되어야 하는 지불 또는 송장을 추적하는 방법입니다. 예를 들어, 백로그는 지불되지 않은 기한이 지난 송장 수를 추적하기 위해 만들 수 있습니다. 모든 지불이 제 시간에 처리되고 회사의 현금 흐름이 잘 관리되는지 확인하는 데 사용됩니다. |
결론
엔지니어링에서 백로그는 프로젝트 관리의 중요한 부분이며 백로그의 중요성을 이해하면 프로젝트의 성공에 큰 영향을 미칠 수 있습니다.
제품 백로그 또는 스프린트 백로그를 관리하고 개선 및 우선 순위 지정을 위한 효과적인 기술을 사용하려면 "백로그"의 개념을 완전히 이해하는 것이 중요합니다.
그러나 백로그 관리는 일회성 작업이 아니라는 점을 명심하는 것이 중요합니다.
프로젝트 수명 주기 내내 개선하고 주의를 기울여야 합니다.
엔지니어로서 백로그를 처리하는 방법을 아는 것은 작동하는 프로젝트와 작동하지 않는 프로젝트의 차이를 의미할 수 있습니다.
따라서 백로그의 힘을 최대한 활용하고 최상의 결과를 얻기 위해 백로그를 개선하고 개선하는 것을 멈추지 마십시오.
공유…
