문서는 얼마나 적어야 할지?
2011/10/27 17:26 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
소프트웨어 개발 프로젝트에서 문서는 적게 적어야 한다.
다시 말하면 "보통의 회사에서는 문서는 필요한만큼만 가장 적게 적어야 한다."
물론 문서를 많이 적으면 여러 각도에서 상세히 적기 때문에 중복은 많이 발생하지만 잘못된 가능성을 충분히 줄여준다.
예를 들어서 스펙문서를 제대로 하나를 효과적으로 적으면 95%를 커버하는데 이를 99.9%까지 커버하도록 적으려면 10배의 비용을 더들여서 수십개의 문서를 만들어야 한다.
절대 문제가 생기면 안되는 원자력 발전소, 우주선, 생명유지장치는 이렇게 할 수도 있다. 실제로는 이런 경우도 다 그렇게 하는 것은 아니다.
문서를 아무리 많이 적어도 완벽을 기해야 하는 경우는 여러 문서를 적어야 하지만 보통의 SW 개발 프로젝트에서 이러한 경우는 거의 없다. 대부분의 SW 개발 프로젝트는 가장 적은 비용으로 가장 빨리 끝내야 한다. 그러기 위해서는 문서를 가장 적게 또한 효과적으로 적어야 한다.
아래에 문서를 만드는 4가지 경우가 있다.
3,4,5번 보다는 차라리 2번이 낫다.
문서를 많이 적는 것은 중복이 많아지고 결국에 서로 Conflict가 나고 업데이트도 안되며 정작 개발시 거의 쓸모없어진다. 하지만 문서를 가장 효과적으로 적게 적는 것은 수십개의 문서를 적는 것보다 훨씬 더 어렵다.
일단 많이 적어보고 줄여나가는 것보다는 문서를 거의 적지 않는 경우라면 꼭 필요한 것부터 조금씩 늘려가는 것이 좋을 것이다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by EvelynGiggles
RSS Feed
소프트웨어 개발 프로젝트에서 문서는 적게 적어야 한다.
다시 말하면 "보통의 회사에서는 문서는 필요한만큼만 가장 적게 적어야 한다."
물론 문서를 많이 적으면 여러 각도에서 상세히 적기 때문에 중복은 많이 발생하지만 잘못된 가능성을 충분히 줄여준다.
예를 들어서 스펙문서를 제대로 하나를 효과적으로 적으면 95%를 커버하는데 이를 99.9%까지 커버하도록 적으려면 10배의 비용을 더들여서 수십개의 문서를 만들어야 한다.
절대 문제가 생기면 안되는 원자력 발전소, 우주선, 생명유지장치는 이렇게 할 수도 있다. 실제로는 이런 경우도 다 그렇게 하는 것은 아니다.
문서를 아무리 많이 적어도 완벽을 기해야 하는 경우는 여러 문서를 적어야 하지만 보통의 SW 개발 프로젝트에서 이러한 경우는 거의 없다. 대부분의 SW 개발 프로젝트는 가장 적은 비용으로 가장 빨리 끝내야 한다. 그러기 위해서는 문서를 가장 적게 또한 효과적으로 적어야 한다.
아래에 문서를 만드는 4가지 경우가 있다.
- 문서 거의 없이 개발하는 경우 (쓸모 없는 문서, 개발중에 안보는 문서, 나중에 문서를 만드는 경우도 여기 해당)
- 스펙문서를 포함해서 한두개의 문서를 효과적으로 적는 경우
- 각 단계에서 수십개의 문서를 철저히 만드는 경우 (거대 방법론)
- 거대 방법론을 흉내 내지만 문서는 거의 안보는 경우. 문서따로 개발따로 (우리 주변에서 흔히 보는 경우)
- 최종 결과물만 거대 방법론 흉내내는 경우. 나중에 제출용으로 문서를 만든다. (이것도 친근하다)
3,4,5번 보다는 차라리 2번이 낫다.
문서를 많이 적는 것은 중복이 많아지고 결국에 서로 Conflict가 나고 업데이트도 안되며 정작 개발시 거의 쓸모없어진다. 하지만 문서를 가장 효과적으로 적게 적는 것은 수십개의 문서를 적는 것보다 훨씬 더 어렵다.
일단 많이 적어보고 줄여나가는 것보다는 문서를 거의 적지 않는 경우라면 꼭 필요한 것부터 조금씩 늘려가는 것이 좋을 것이다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by EvelynGiggles
'개발프로세스' 카테고리의 다른 글
| 문서는 얼마나 적어야 할지? (2) | 2011/10/27 |
|---|---|
| 획일화된 프로세스의 함정 (6) | 2011/04/03 |
| 이번 프로젝트 내일 끝나? (10) | 2011/01/31 |
| 소프트웨어 관료화 (16) | 2009/08/31 |
| 프로세스가 창의성을 저해한다고? (8) | 2009/04/08 |
| 소프트웨어 개발의 극과 극 (0) | 2009/02/18 |
Trackback Address: http://allofsoftware.net/trackback/239
넘침은 부족함만 하지 못하다고 했는데
사람의 욕심과 보여주기 그리고 비교로 인해서
이런 작업을 하지 않으면 일을 하지 않는것 같아 보인다는 생각을 고쳐야 할텐데 그게 가장 어려운것 같아요
안녕하세요. 구차니님
열심히 코딩하고 있으면 일한다고 생각하고, 아키텍처 고민하고 있으면 논다고 생각하는 경향도 있더군요.
소프트웨어엔지니어가 경력이 늘어 갈수록 코딩 등의 일은 줄어들고 생각하는 시간이 늘어야 하는데 말이죠.