개발 문서 관련해서 고민이 있습니다..

문서화는 한국에서 오해가 가장 많은 부분 중의 하나가 아닐까 생각합니다. 첫째는 이전에 많은 SI회사들에게 개발과 관련이 없는 많은 문서를 만들었기 때문에, 개발자들 사이에서 문서는 쓸데없다는 식의 광범위한 잘못된 생각들이 자리를 잡은 것입니다. 두번째는 XP에서 잘짠 프로그램에는 주석이 필요없고, 문서화보다는 프로그램을 잘짜면 된다는 tech pratice 위주의 개발 방법론을 개발자들이 좋아하기 때문에 문서보다는 프로그램을 작성하는 것을 선호하는 것이었습니다. 하지만 실제 외국분들과 일해보면 한국 vs 외국 개발자들의 큰 차이는 문서화 입니다. 많은 때 한국 개발자들이 손이 빠르지만 충분하지 못한 문서로 인하여 많은 경우 회의에서 정보를 얻어야 하며, 만약 담당자가 바뀌는 경우 코드 베이스 차체가 달라지는 경우가 많았습니다. 반면에 외국 개발자들은 충분한 문서화로 개발 시작은 좀 느리지만 큰 규모의 개발이 많은 회의 없이 가능하고, 지속적으로 프로그램을 발전시키는 것에도 큰 장점이 있었습니다. 문서화는 필요없는 작업이 아니며 꼭 필요한 작업입니다. 문서에는 많은 종류가 있습니다. 아키텍쳐를 결정하는 ADR, 그리고 프로덕트의 중요한 내용들을 결정하는 PDR, 또한 기능에 대한 설명, 메뉴얼, 그리고 테스트의 결과 테스트 시나리오도 중요한 내용이라고 볼 수 있습니다. 위의 내용 중에 꼭 필요한 내용들을 선정하고 간단한 내용 부터 팀이 같이 작성할 수 있도록 DoD(Definition of Done)을 이용하는 것을 권해드립니다. 처음에는 작으나 스프린트를 거듭할 수로 방대한 문서가 생성될 것입니다. 그리고 개발의 끝은 기능이 정상적으로 동작하는 것 뿐만 아니라 관련 있는 테스트와 문서화 모두 종료 되었을 때 DoD를 준수했을 때 완료된 것입니다. 이것 까지 포함해서 estimation 하세요..

문서화도 다양한 종류가 있어서 콕 집어서 말씀드리기는 어려울 것 같네요, 가령 프론트엔드 개발 컨벤션에 관한 문서화일 수도 있고 특정 작업 기획과 설계에 관한 문서화 일수도 있어요. 제 생각에는 범위를 정해두지않고 블로그에 기입하듯이 필요한 부분을 문서화 하면 어떨까요? 그런식으로 연습한 뒤 타사의 기술 블로그에서 인사이트를 얻거나 업무에 필요한 부분이 생길때 확장하는 방식으로 나아가면 좋을 것 같아요!