방법론 문서화 - 목적, 종류, 의견

애자일 방법론은 문서보다는 실행되는 소프트웨어에 집중하는 것을 강조합니다. 

문서의 중요성은 인정하지만, 너무 많은 문서(과도한)를 작성하지 않는 것입니다. 

애자일에서의 문서는 소통을 위해 만드는 경우가 많습니다. 그 문서의 종류는 다양하게 있고, 그 문서는 잘 유지되어야만 합니다. 

아래와 같이 문서화에 대해 조금 더 알아보겠습니다. 

 

[목차]

• 목적
• 대표 문서 종류
• 의견

목적

• 지식 공유 및 전달
  • 문서화는 프로젝트에 대한 지식을 공유하고 전달하는 수단입니다. 
  • 새로 합류하는 팀원들에게 프로젝트에 대한 이해를 돕고, 다양한 경험이나 전문성을 공유함으로써 팀 간 지식의 일관성을 유지합니다.
• 요구사항 명확화
  • 요구사항 및 기능 명세서는 프로젝트의 범위와 목표를 명확히 정의합니다. 이는 프로젝트의 방향성을 제시하고, 개발자들이 동일한 목표를 공유하며 일관된 작업을 수행할 수 있게 합니다. 
• 설계와 구현 지원
  • 설계 문서는 시스템의 아키텍처, 구조 디자인을 기술합니다. 
  • 이를 통해 개발들은 프로젝트의 구조를 이해하고, 기능을 구현하는데 필요한 정보를 얻을 수 있습니다. 
• 테스트 및 검증
  • 테스트 문서는 소프트웨어가 기대한 대로 작동하는지 확인하는 데 도움을 줍니다. 
  • 테스트 케이스, 결과 등을 문서로 남겨 소프트웨어의 품질을 보장하고 결함을 식별하며, 수정과 확인을 위한 기준을 제공합니다. 
• 변경 관리와 유지보수 지원
  • 문서화된 내용은 소프트웨어의 변경에 대응할 수 있도록 도와줍니다. 변경 사항을 문서로 남겨 다른 팀원들이 변경 사항을 이해하고 적용할 수 있게 합니다. 
  • 또한, 유지보수 단계에서 기존 코드나 시스템을 이해하고 수정하는 데 도움을 줍니다. 
• 위부 요구 사항 충족 
  • 외부 요구 사항에 대한 준수를 위해서도 문서화가 중요합니다. 
  • 인증, 규정, 보안, 품질 관리 등 외부 요구 사항을 충족시키기 위해 문서화된 정보가 필요합니다. 

대표 문서 종류

• 요구사항 명세서 
  • 시스템이나 소프트웨어에 대한 요구사항을 기술한 문서입니다. 
• 기능 명세서 
  • 소프트웨어의 기능과 동작을 설명하는 문서입니다. 
• 설계 문서
  • 시스템의 아키텍처, 구조, 디자인을 기술하는 문서입니다. 
• 테스트 문서
  • 시스템이나 소프트웨어의 테스트 계획, 테스트 케이스, 결과를 포함하여 문서입니다. 
• 사용자 매뉴얼 
  • 최종 사용자를 위한 설치, 사용, 유지보수 등을 안내하는 문서입니다. 

의견

개인적으로 문서화는 어느 조직에서나 강조하는 부분입니다. 

개발자에게는 소스 코드를 만들기전에 간단하게라도 "순서도"와 비슷한 문서라도 그려보라고 권합니다. 

- 아무리 손이 빨라도 생각해 놓은 로직을 한 번에 코딩할 수 없습니다. 

- 전체 로직을 점검하는 기회는 문서를 통하지 않으면 불가능합니다.

 

기획자에게는 "요구사항 명세서", "기능 명세서"와 비슷한 문서를 간단하게라도 만들어서 관리하라고 권합니다.

- 어떤 서비스든 프로그램이든 요구사항이 적거나, 변하지 않는 경우는 없습니다. 

- 요구사항이 어디서부터 시작해서 어디까지 발전하는지 확인이 필요합니다. 

이처럼 각 담당 분야에 꼭 필요한 문서도 중요합니다.

 

애자일에서는 특히, 이해관계자가 많은 프로젝트에서는 서로의 이해를 일관되게 유지하는데 문서를 강조하기도 합니다. 

애자일은 소통을 강조하기 때문입니다. 

 

더불어, 개발 전문회사라면 한번쯤 생각했봤을 CMMI 인증을 포함한 모든 개발 관련 인증에서도 각 단계별 문서는 반드시 요구됩니다. 

인증받을 때 모든 문서를 만든다는 것은 불가능합니다. 심사위원들이 그리 호락호락하지 않습니다. 

 

개발자라면 부디 설계 문서를 어렵더라도 조금씩 만들어보는 것을 다시 한번 강조드립니다. 

나름 고급 개발자인데 설계 문서 종류도 모르고 만들어 본 적도 없다면, 큰 일입니다.