요약: 애자일 워크플로는 애자일 팀이 아이디어 구상부터 완료까지 애플리케이션을 개발하기 위해 사용하는 일련의 단계입니다.
모든 소프트웨어 팀은 작업을 완료하는 데 사용하는 프로세스를 보유합니다. 이 프로세스를 정규화(즉, 워크플로로 확립)하면 명확하게 구조화되고 반복 가능하므로 결과적으로 확장 가능합니다. Atlassian은 워크플로 관리에 대한 반복적인 접근 방식을 취합니다. 목표를 더 빠르게 달성하도록 지원하고 팀 문화를 잘 보여주기 때문입니다. 우리는 애자일 워크플로 관리 전문가이며 여러분도 전문가가 되도록 돕고 싶습니다.
애자일 워크플로 시작하기
팀을 위한 워크플로를 구현할 때는 항상 단순하게 시작하세요. 지나친 엔지니어링에 몇 주나 소비하려는 유혹에 맞서 싸우세요. 지나치게 복잡한 워크플로는 조정은 말할 것도 없고 이해하거나 도입하기도 어렵습니다. 소프트웨어 팀의 경우 다음과 같은 기본 워크플로 상태를 추천합니다.
아직 시작되지 않은 작업
팀에서 적극적으로 살펴보고 있는 작업
완료되어 검토 대기 중인 작업
완전히 완료되고 팀의 완료 정의에 부합하는 작업
이슈 추적기에서 이 상태는 워크플로를 구성하는 전환을 사용하여 한 상태에서 다음 상태로 흐릅니다.
일부 소프트웨어 팀은 작업 상태를 더 정확하게 추적하는 추가 상태를 워크플로에 포함합니다.
구현되었지만 아직 테스터 검토를 기다리고 있는 작업(자세한 내용은 애자일 테스트에 대한 문서 참조).
검토가 완료되었으며 기본 또는 릴리스 브랜치로 병합할 준비가 된 코드입니다.
워크플로의 각 상태를 다른 관계자가 처리할 필요는 없습니다. 애자일 팀이 성장하면서 개발자는 디자인부터 배포에 이르기까지 점점 더 많은 작업을 처리합니다. 여러 종류의 작업을 처리할 수 있는 자율적인 팀은 결국 민첩성의 특징입니다.
팀의 회고에서 각 문제점에 대해 논의하고 각 팀은 프로젝트, 기술 스택 및 작업하려는 방법에 따라 약간 다른 가치를 가진다는 것을 명심하세요. 따라서 유연한 워크플로 구성을 가진 이슈 추적기를 선택하는 것이 중요합니다. 많은 팀이 특정 도구 집합에 맞게 작업 스타일을 타협하는데 이것은 모두에게 실망을 안겨줍니다. 이것은 팀원들이 해당 도구를 아예 사용하지 않고 팀 전체의 좌절감만 가중시켜 일반적으로 혼란을 야기하는 결과로 이어질 수 있습니다. 사기가 떨어지면 생산성도 떨어집니다. 우리 모두가 피하고 싶은 이중고입니다.
애자일이 처음이거나 교차 기능 스킬이 없는 팀은 워크플로에 "작은 워터폴"이 생기는 경우가 많습니다. 예를 들어 디자인은 모형을 사용하여 작업 항목을 시작합니다. 개발은 구현을 수행합니다. 테스트를 통해 품질을 확인합니다. 각 상태는 이전 상태가 완료될 때까지 차단됩니다. 친숙하게 들립니까? 이것이 바로 워터폴입니다. 하지만 애자일 워크플로를 사용하면 팀의 차단을 해제하고 개발을 더 쉽게 할 수 있습니다.
애자일 프로세스 워크플로 최적화
기본 워크플로에 익숙하고 이것을 애자일 프로세스 워크플로로 전환할 준비가 되었으면 팀 프로세스에서 각 작업 유형에 대한 상태를 만듭니다. 구상, 디자인, 개발, 코드 검토 및 테스트는 기능적으로 다르며 개별 상태가 될 수 있습니다. 작업이 어떤 단계에 있는지 명확하게 전달하는 효율적인 상태 집합을 목표로 합니다.
프로젝트 상태를 나머지 조직과 공유할 수도 있습니다. 애자일 프로세스 워크플로를 구축할 때 보고해야 할 중요한 메트릭과 팀원이 아닌 관계자가 학습에 관심을 가질 만한 내용을 생각해 보세요. 예를 들어 잘 설계된 워크플로는 다음 질문에 대한 답을 제공합니다.
- 팀이 완료한 작업은 무엇입니까?
- 작업 백로그는 증가하고 있습니까, 아니면 팀과 보조를 맞추고 있습니까?
- 각 상태에는 항목이 몇 개 있습니까?
- 팀 속도를 늦추는 병목 현상이 있습니까?
- 평균 작업을 완료하는 데 얼마나 걸립니까?
- 1차 품질 표준을 통과하지 못한 작업 항목은 몇 개입니까?
워크플로 최적화의 다음 단계는 워크플로를 통해 일정한 작업 흐름을 보장하는 것입니다. WIP(진행 중인 작업) 제한은 워크플로의 특정 상태에서 최소 및 최대 이슈 수를 결정하여 각 상태가 팀을 완전히 활용할 수 있을 만큼 충분한 작업을 가지지만 우선 순위를 저글링하는 과정에서 집중력을 잃을 정도로 작업이 많지는 않도록 보장합니다. WIP 제한을 적용하면 파이프라인을 통해 전반적인 작업 속도를 느려지게 하는 프로세스를 빠르게 확인할 수 있습니다. 팀이 WIP 제한을 중심으로 최적화하는 방법을 배우면 처리량이 증가합니다. (자세한 내용은 WIP 제한에 대한 문서를 참조하세요.)
애자일 프로세스 워크플로 확장의 과제
몇 개의 애자일 팀을 보유한 조직은 워크플로와 관련한 특별한 과제에 직면해 있습니다 팀은 고유한 프로세스와 문화를 반영하기 위해 자체 워크플로를 최적화하려는 경우가 많습니다. 완벽하게 이해할 수 있습니다. 그러나 서로 다른 팀이 동일한 프로젝트에서 작업하는 동안 서로 다른 프로세스를 사용하면 골칫거리가 생길 수 있습니다.
함께 작업하는 애자일 팀은 동일한 워크플로 공유하여 장점을 얻을 수 있습니다. 동일한 워크플로를 사용하면 동일한 규칙을 사용하여 작업을 정의하고 전달하므로 애자일 팀 간에 작업을 더 쉽게 전환할 수 있습니다. 공통 프로세스를 만들려면 일반적으로 두 팀 모두로부터 주고받는 것이 포함됩니다. 훌륭합니다. 서로 배우면서 결국 더 나은 워크플로를 만들어냅니다.
Atlassian의 이슈 추적기인 Jira를 사용하면 팀은 워크플로를 공유할 수 있지만 애자일 보드에서 프로세스를 다르게 표현할 수 있습니다. 이 기능은 워크플로의 공유 자산을 희생하지 않으면서도 유연한 시각화 옵션을 제공합니다.
워크플로가 어떤 형태든 상관없이 개발 프로세스도 민첩해야 합니다. 때때로 회고에서 토론하고 팀의 문화와 구성이 변하는 것에 따라 조정하세요.
