애자일 문서: 속도와 지식 보유 간의 균형

생성과 관련된 다양한 문서, 아티팩트 및 프로세스는 폭포수 모델의 주요 상징 중 일부입니다. Lean에서 차용하여 Agile은 개발 수명 주기를 간소화하기 위해 근절해야 하는 "낭비"로 많은 문서를 고려합니다.

많은 프로젝트 관리자에게 Waterfall 단계가 어떻게 스프린트로 바뀌는지 이해하는 것은 그리 어렵지 않습니다. 동일한 작업이 수행됩니다. 다른 방식으로 구성되어 있을 뿐입니다. 그러나 대부분의 문서를 제거하는 것은 완전히 다른 작업 방식을 강조하므로 삼키기가 더 어렵습니다. 통제의 고삐를 느슨하게 하고, 미지의 것을 포용하며, 배달 팀이 그 자리에서 결정을 내릴 수 있도록 권한을 부여해야 합니다.

문서화에 대한 전통적인 접근 방식에 대한 도전

Waterfall 방법론에서는 프로젝트 요구 사항을 문서화하고 솔루션을 자세히 설명하는 데 많은 시간을 할애합니다. 이 프로세스는 요구 사항이 완전히 명확하고 캡처 및 기준선에서 변경되는 사항이 없다고 확신할 때 작동합니다. 그러나 지난 수십 년 동안 대부분의 회사에서 경험한 바에 따르면 이는 거의 사실이 아닙니다. 오늘날의 세계에서는 변화의 속도가 너무 빨라 문서화 단계를 완료할 때까지 클라이언트의 요구 사항이 상당히 변경됩니다.

Agile의 초점은 작업을 완료하고 이해 관계자에게 가치를 추가하는 것입니다. 모델이 주변기기 및 클라이언트에게 직접적이고 즉시 가치를 추가하지 않는 활동에 대한 작업을 권장하지 않는 방식으로 구축되었습니다.

폭포수 대 애자일 문서

회사마다 문서 수준이 다르며 프로젝트 수준에서도 다를 수 있습니다. 그러나 Waterfall 및 Agile 프로젝트에서 일반적인 문서화 절차는 다음과 같습니다.

문서화 사례

Waterfall은 문서화에 대한 훨씬 더 엄격한 접근 방식을 권장하며 이는 과도해 보일 수 있습니다. 그러나 이것을 "낭비"라고 무시하기 전에 강력한 문서화 절차를 통해 얻을 수 있는 몇 가지 이점이 있습니다.

전략적 사고의 기회

계획하지 않는 사람은 실패를 계획합니다. 문서화는 프로젝트 관리자가 앉아서 일을 생각하고 최상의 솔루션을 찾도록 강요합니다. 사람들은 때때로 포괄적인 문서보다 작업 소프트웨어의 애자일 가치를 문서가 필요하지 않다는 의미로 잘못 해석합니다. 그런 다음 Intercom의 제품 담당 부사장인 Paul Adams는 시장으로 달려가는데, 이는 벽에 물건을 던지고 무엇이 달라붙는지 보는 것이라고 설명합니다. 솔루션 설계, 계획 수립, 행동 심의 등 이러한 활동은 떠오르는 모든 기능 아이디어를 개발하지 않는 시간을 절약함으로써 가치를 창출합니다.

UX 및 기능적 일관성

회사가 소수의 창립자에서 수백 또는 수천 명의 직원으로 성장함에 따라 많은 다른 팀이 동일하거나 관련 제품에 대해 작업하기 시작합니다. A 팀은 자신이 하는 일이 B 팀이 하는 일과 관련이 없다고 생각할 수도 있지만 최종 사용자에게는 모두 같은 제품입니다. 부서 간 팀이 각자의 일을 하는 대신 사용자 경험과 기능 수준에 대한 명확한 문서화는 분리된 사용자 흐름을 방지합니다.

문서를 사용 설명서로 변환할 수 있음

Waterfall에서는 솔루션과 사용 방법을 자세히 설명하는 데 많은 시간을 할애합니다. 프론트 엔드 개발자를 위해 고화질 디자인의 사진이 만들어집니다. 이러한 모든 자산은 처음부터 만드는 것보다 내부 또는 외부 사용자 가이드로 변환하는 데 더 적은 작업이 필요합니다.

Agile이 문서화 요구를 줄이는 방법

문서를 의무화하기 위한 핑계로 반복해서 등장하는 요소는 직원 이직률입니다. 관리자는 사람들이 떠나고 새로운 사람들이 그들을 대체하기 위해 합류할 때 제도적 지식을 잃는 것을 두려워합니다. 구현된 내용과 작동 방식을 어떻게 알 수 있습니까? 따라잡는 데 얼마나 걸립니까? 현재 팀이 새로운 팀원을 수용할 수 있는 대역폭을 가질 수 있습니까?

좋은 문서를 작성하면 대부분 독립적으로 작업하는 신입 직원이 신속하게 업무를 처리할 수 있기를 바랍니다. 그러나 Agile은 본질적으로 온보딩 시간을 줄이는 동시에 협업 기술을 통해 문서화의 필요성을 줄입니다. 다음은 Agile이 문서화의 필요성을 줄이는 몇 가지 방법입니다.

제품 팀과 애자일 팀 구성원 간의 정기적인 상호 작용

Agile Manifesto는 "프로세스와 도구보다 개인과 상호 작용"을 촉진합니다. 요구 사항은 프로젝트 중에 변경되는 경향이 있고 새로운 아이디어가 발생하기 때문에 Agile은 지속적인 업데이트가 필요한 작성된 아티팩트에 의존하는 대신 소스에서 직접 요구 사항을 명확하게 합니다.

정리 및 계획은 작업을 구분합니다.

백로그 정리 및 스프린트 계획은 기능을 쉽게 이해하고 독립적으로 작업할 수 있는 구현 가능한 특정 부분으로 나눕니다. 이는 신입 사원이 초기에 생산성을 높일 수 있는 기회를 제공하지만 아직 전체 프로젝트의 큰 그림을 완전히 이해하지 못하고 있습니다.

효율적인 문서화를 제공하는 사용자 스토리

사용자 스토리의 간단한 형식을 통해 프로젝트 관리자는 모든 팀 구성원 간에 공유된 이해를 만드는 최소한의 요구 사항을 캡처할 수 있습니다. 사용자 스토리가 스프린트로 이어지지 않더라도 이 문서 아티팩트를 만드는 데 드는 낭비는 매우 적습니다. 사용자 스토리가 스프린트로 이동함에 따라 와이어프레임, 디자인, 승인 기준 등과 같은 기타 필수 정보로 구체화되고 보완될 수 있습니다. 이 프로세스는 일회용이며 가장 적절한 개발 단계에서 생성되는 매우 효율적인 문서 전달을 제공합니다.

코드 문서화 필요성 감소

페어 프로그래밍 및 코드 검토와 같은 기술은 팀 전체, 특히 새로운 팀 구성원에게 기술 지식을 전파할 수 있는 지속적인 기회를 제공합니다. 지속적인 피드백은 문서 어딘가에서 빠르게 구식이 되는 대신 새로운 상황에 적응할 수 있는 유연성을 가진 공유된 이해로 이어집니다.

애자일 행사

일일 스탠드업, 스프린트 리뷰 및 회고는 이메일과 문서에 의존하는 대신 문제를 해결하고 직접 대면하여 결정을 내릴 수 있는 충분한 기회를 제공합니다. 모든 의식의 제한된 시간 프레임은 사용되지 않을 가능성이 높더라도 모든 것을 문서화하는 데 시간을 소비하는 대신 가장 중요한 정보만 우선 순위를 지정하도록 합니다.

위의 모든 사항은 문서를 직접 또는 간접적으로 줄이고 프로젝트 목표 전달의 우선 순위를 지정하는 동시에 문서 부족으로 인해 실제로 손실되는 것이 없도록 합니다.

문서화에 대한 하이브리드 접근 방식

일부 회사는 애자일 환경에서도 여전히 일부 문서를 보유하는 것을 선호합니다. 애자일은 각 프로젝트가 다르고 해결해야 하는 고유한 상황이 있기 때문에 규범적이지 않습니다.

다음은 애자일을 시간 집약적인 문서화 방법과 결합하는 방법의 몇 가지 예입니다.

UML과 애자일 결합

UML(Unified Modeling Language)과 같은 표준 모델링 언어를 사용하는 것을 고려하십시오. 이 언어는 시스템을 시각화하기 위해 정의된 엔터티가 있고 매우 구조화되어 있습니다. 이렇게 하면 콘텐츠를 매우 단순하게 유지하고 필요한 것에 집중하는 데 도움이 되며 서면 언어의 사용을 최소화할 수 있습니다. StarUML 및 Draw.io와 같은 도구는 무엇보다도 편리한 옵션입니다.

코드 문서 생성기

또 다른 접근 방식은 클래스 세부 정보, 메서드 세부 정보, 매개 변수 사용, 종속성 등의 일부로 보다 구조적이고 상세한 주석을 도입하여 코드를 훨씬 더 읽기 쉽게 만드는 것입니다. 소스 코드에서 유용한 문서를 생성하는 프로세스를 자동화하는 많은 도구가 있으며 이를 문서 생성기라고 합니다. 일반적인 것부터 프로그래밍 언어별 것까지 다양합니다.

상세 디자인 및 UX 문서

와이어프레임, 모형, 사용자 흐름 다이어그램, 시퀀스 다이어그램 등을 사용하여 요구 사항을 정의하면 프로젝트 흐름을 단순화하고 기술 팀에 개발해야 할 사항을 명시적으로 명확하게 설명하는 데 도움이 됩니다. 설계 문서는 다양한 수준의 보다 엄격한 문서를 만드는 좋은 방법입니다. 이러한 작업을 위해 선택할 수 있는 다양한 와이어프레이밍 및 UX 도구가 있습니다.

프로젝트 관리 도구 문서 자동화

JIRA, Confluence, Asana 및 Basecamp와 같은 보다 강력한 프로젝트 관리 및 관련 도구는 모든 프로젝트 관련 정보를 한 곳에 보관할 수 있는 방법을 제공합니다. 작업을 연결하고, 태그를 지정하고, 중첩하고, 다른 팀원에게 할당할 수 있습니다. 그러면 팀원이 의견을 남기고 문제를 보고할 수 있습니다. 이러한 모든 작업은 이러한 도구를 조정할 수 있는 유연성과 함께 거의 또는 전혀 노력 없이 상당한 양의 문서를 생성할 수 있습니다.

또한 역사적으로 문서화 요구 사항의 일부는 보고 요구 사항에서 비롯되었습니다. 이해 관계자는 팀 성과 또는 기타 관련 메트릭에 액세스하기를 원합니다. 프로젝트 관리 도구를 사용하면 프로젝트 진행 상황을 반영하고 도구 내의 관련 문서에 다시 링크하는 사용자 지정 대시보드 및 보기를 쉽게 자동화할 수 있습니다.

문서 관리는 균형을 유지하는 작업입니다.

Agile Manifesto의 작성자는 "포괄적인 문서보다 작동하는 소프트웨어"를 중요하게 생각합니다. 그러나 그들은 또한 "오른쪽에 있는 항목에 가치가 있지만 [그들은] 왼쪽에 있는 항목을 더 소중히 여긴다"는 면책 조항을 추가합니다. 일부 문서는 분명히 가치를 제공하기 때문에 Agile은 모든 문서를 제거하는 것을 제안하지 않습니다. 단순히 개발 진행을 크게 방해하지 않고 프로젝트 상황에 따라 필요한 만큼만 소프트웨어를 작동하고 문서를 추가하는 데 우선 순위가 있어야 한다고 제안합니다.

프로젝트 관리자는 문서화에 더 적은 시간을 소비하는 것과 작동하는 소프트웨어를 제공하는 데 더 많은 시간을 소비하는 것과 장기적인 성공을 위해 어떤 형식의 문서가 필요한지 실제로 파악하는 것 사이에서 균형을 이루는 조치를 취해야 합니다.