문서가 없으면
'프로젝트' 카테고리의 다른 글
| 문서가 없으면 (2) | 2011/03/13 |
|---|---|
| 프로젝트 시작부터 개발자가 바글바글 (0) | 2009/01/23 |
| 프로젝트는 연습이 아니다. (2) | 2009/01/19 |
| 소프트웨어 프로젝트는 누가 진행하는가? (0) | 2008/11/12 |


|
|
| 문서가 없으면 (2) | 2011/03/13 |
|---|---|
| 프로젝트 시작부터 개발자가 바글바글 (0) | 2009/01/23 |
| 프로젝트는 연습이 아니다. (2) | 2009/01/19 |
| 소프트웨어 프로젝트는 누가 진행하는가? (0) | 2008/11/12 |
| 매일 불난 호떡집 같은 회사 (중요한 일 vs. 시급한 일) (14) | 2011/01/03 |
|---|---|
| 해외에 소프트웨어를 팔려면 이것이 꼭 필요하다. (12) | 2010/12/14 |
| 문서화 딜레마 (20) | 2010/11/11 |
| 내가 지금 하고 있는 일의 가격 (6) | 2010/11/02 |
| 개발자를 잘못 채용하는 방법 (20) | 2010/04/19 |
| Google을 이끄는 힘 (7) | 2009/10/30 |
문서화 정말 어렵더라구요. 4년차만에 처음으로 개발하기 전에 설계하면서 문서부터 만들고 있는 중인데, 이 정도밖에 안됐나 하는 자괴감이 들더라구요. 갑자기 또 속상해지네. 크크크. 10년차 되서 스펙때문에 또 좌절하면 어쩌죠. 스펙까지 익숙해지려면 보통 몇년 걸리나요? 빌 조이같은 천재들 말고요.
안녕하세요. 김재호님
스펙은 가장 작성하기 어려운 문서입니다.
요구사항 분석 능력이 있어야 하고, Domain도 잘 알아야 하고, 문서도 잘 작성해야 합니다.
제대로 적는데는 기본적으로 3~4년은 걸리고 10년이 지나고 20년이 지나도 꾸준히 실력이 증가하는 소프트웨어를 개발하는데 있어서 가장 어려운 분야입니다.
빌조이 같은 천재라고 해도 결코 처음부터 스펙을 잘 적을 수는 없습니다.
문제는 스펙을 적는 방법을 배우기가 어려운 거죠.
안녕하세요. godway님
우리나라 책중에서는 제가 쓴 "소프트웨어 개발의 모든 것"을 추천합니다. 그리고 외국책 중에서는 Requirement Engineering으로 검색을 해보시는 것이 좋겠습니다.
책을 보는 것은 도움이 되기는 하지만 책만 보고 제대로 작성하는데는 매우 오랜 시간이 걸립니다.
소프트웨어 개발의 모든 것, CodeCraft, 조엘온 소프트웨어 등등을 읽으면서,
"스펙 문서 만드세요."
라는 말을 볼 때마다, 그렇지요 옳은 말씀이지요 하면서 읽었습니다.
실제로 실천하려 하니 참으로 어렵다는 생각을 많이 해 봤습니다.
문서를 여러개를 짧게 만들어야 하는지, 길게 하나로 만들어야 하는지...
여기에는 이것이 들어가도 되지만, 저기에는 이것이 들어가면 안되는지...
이것들 고민하는 것이 일이고 실력이라는 생각 역시 들었습니다.
하지만 전에 한 번 분석 설계 구현의 순서로 만들기를 실험해 봤을 때,
시간이 확실히 줄어들었던 기억이 있어서
이젠 꼭 지키려고 노력합니다.
정말
"건강하게 살려면, 나쁜 것들 드시지 마시고, 운동 열심히 하세요"만큼이나 어려운 일이 문서화인듯 합니다.
안녕하세요. 주의사신님
문서는 쪼개나 합치나 같은 겁니다.
관리가 편하려면 하나의 문서로 만드는 것이 좋지만, 한 섹션이 너무 크면 문서를 나눠도 좋습니다.
단 문서를 나눌 경우에는 문서에 Link를 걸어야 하는데 Link된 문서는 바로 열어 볼 수 있도록 회사의 문서관리시스템이나 소스코드관리시스템에 등록해서 그 Link를 추가해야 합니다.
좋은 경험을 가지고 계시네요.
꾸준히 계속 적어나가면 매번 실력이 늘어가는 것을 느낄 수 있을 겁니다.
안녕하세요, 전규현님 오랜만입니다.
문서를 만들겠다고 달려드는 데서 부터 문서화 작업이 힘들어 지는 것이 아닌가 생각합니다. 요즘 인기있는 지속적 통합이나 지속적 배포같은 부분에서 말하듯이 문서화도 짧게 지속적으로 문서를 만들어 나가야 하지 않을까 생각합니다. 시스템 만들어 놓고 테스트 시작하거나, 통합을 시작하거나 하면 큰 문제가 생기니 짧게 짧게 작은 양에 대한 작업을 하자는 것처럼 문서화도 그 때 그 때 노트 형식으로 적어 놓으면서 발전 시켜 나가는 방법도 나쁘지 않은것 같습니다.
안녕하세요. Jake님
과유불급이라고 생각합니다.
그래도 여전히 문서 만들기를 지극히 싫어 합니다.
그래서 최근에 Agile에서는 문서를 안만들어 되는 것으로 착각하고 혹 하기는 합니다.
문서를 만드는 방법이 다를 뿐이죠.
문서는 만드는것보다도 계속 업데이트하는게 중요한것 같더군요..
실제로 버전이 올라가다 보면 문서와 소스내용이 틀려 낭패보는 경우도 가끔 있구요..
저술하신 "소프트웨어 개발의 모든것"을 봤지만 제가 말씀드린 경우의 해결책은 못 본것 같은데요..(기억을 못하는지도..)
문서의 버전업을 어떤 형식으로 진행할 수 있는지 방안이 있으시면 조언 부탁드립니다.
또 문서없이 wiki만 사용하는 경우 문제점이 있을까요? (요즘 문서의 버전문제때문에 wiki를 검토중이라서요..)
언제나 좋은 글 감사합니다..
안녕하세요. 무혹님
그래서 문서는 최대한 적게 만들어야 합니다.
제 책에서도 문서의 업데이트에 대한 내용이 있습니다.
책의 내용을 보면 이와 관련된 내용이 몇가지 있습니다.
문서는 업데이트가 어렵기 때문에 꼭 필요한 문서만 만들고 SRS는 꼭 업데이트 하라고 하고 있습니다.
또한 설계문서는 완벽하게 업데이트하기 어렵다고 설명하고 있습니다.
설계문서는 구현을 하기 위해 필요한 것이기 때문에 나중에 변경되는 것은 모두 업데이트 하기 어렵습니다.
그래서 Doxygen이나 JavaDoc을 잘 이용할 것을 설명하고 있습니다.
설계에서는 그렇기 때문에 인터페이스를 최대한으로 깔끔하고 간단하게 만드는 것이 좋습니다. 너무 얽히섥히 섞인 인터페이스는 나중에 바뀌더라도 관리가 잘 안됩니다.
약간 다른 이야기 이기는 합니다만..
대체로 글 잘 쓰시는 분들이 코딩 역시 잘 하시더군요
후배들 코딩 스타일을 글 쓰는 유형에 비교하면 다음 3가지로 간추려 지는데..
-시인 타입: 이해하기 힘들다. 잘 돌아간다.
-이면지 제작자: 이해하기 힘들다. 잘 안 돌아간다.
-기자 타입: 이해하기 쉽다. 잘 돌아간다.
요새는 코딩하기 전 과제 계획서 또는 일정표 등 문서 부터 써 보라고 합니다.
글을 쓰는 모습을 보면 이 사람이 코딩을 어떻게 하겠다 대충 알 것 같더군요
더불어 우리가 수학 논문을 많이 쓰기 때문에 증명 숙제 한거나, 쓴 논문을 보면 이 녀석이 위 중 어느 타입이구나 감이 오더군요.
안녕하세요 ~ 좋은 글 잘 봤습니다
저는 컴퓨터와는 전혀 관련이 없지만 말씀하신 내용은 학생부터 나이든 할아버지 할머니까지 도움이 되는 거 같아요
뭐 개인적으로는 연구노트를 꾸준히 제 때에 쓰고, 제 때에 다시 살펴보는 게 얼마나 어려운 지 느끼고 있네욤 ㅡ _ㅡ;;
한번 작성이 아니라 계속 업데이트 해야 하고
그걸 여러 사람과 공유/동기화 하는게 가장 힘든걸 보면
Trac 등에서 위키로 문서화 하는 추세가 바람직 할수 밖에 없는것 같아요.
안녕하세요. 구차니님
Word로 작성을 하던 Wiki를 이용하든지 큰 상관은 없을 것 같습니다. 중요한 것은 문서를 작성하는 것이고 그 내용이 더 중요하다고 생각합니다. 어디에 적느냐는 서로 장단점이 있는 것 같습니다.
내용이 중요하다는 의미는 설계문서를 작성할 때 UML을 이용하느냐 Doc로 작성하느냐 노트에 연필로 작성하느냐보다는 "설계"자체를 잘 하냐가 더 중요하듯이 어차피 내용을 잘 모르면 어떠한 툴을 가져와도 의미 없는 문서가 됩니다.
그래서 선배들이 작성한 문서를 리뷰에 참석해서 꾸준히 배워나가는 것이 문서에 무엇을 적어야 하는지 배우고 또 어떻게 적어야 하는지 어떻게 리뷰를 해야 하는지 익힐 수 있습니다.
또, 무엇은 적을 필요가 없는지도 자연스럽게 배우게 됩니다.
현재 그런 환경이 아니라면 누군가가 먼저 시작을 해야겠죠. 항상 선구자는 힘든 법입니다. ^^
선구자는 힘들다는 말, 무척 공감이 갑니다.
"내가 무엇을 해 보겠다" 할 때 대부분 반응은 "왜 귀찮게 그런 걸 하냐"가 대다수 더군요
가끔은 왜 이걸 해야 하는지 설득하는게 더 힘들 때도 있습니다.
여하튼 최근에 작은 프로젝트 팀장이 되어 이것 저것 해 보려고 하다보니 고민이 많네요.
그런 경우는 무엇을 하고 무엇은 지금은 무리인지를 판단하는게 중요합니다.
사실 이런 판단이 가장 어려운 판단 중에서 하나입니다.
그럴때 주변의 선배나 전문가에게 물어보는 것이 가장 좋습니다.
본인 스스로 판단하는 능력이 생기려면 이러한 경험을 모두 해 본 후 일겁니다.
참 힘들죠~
안녕하세요. 철이님
혹시 문서화를 왜 하려고 하시나요?
문서를 작성하면 프로젝트의 기간이 줄어든다는 것을 믿고 계시나요?
이것을 경험을 통해서 알고 있지 않으면 문서를 만들기 정말 어렵습니다.
대부분은 몇번 문서를 만들다가 프로젝트 시간만 더 걸리고 문서가 사장되기 일쑤입니다.
이런 경우는 필요없는 문서를 만들거나 문서를 잘못 만들기 때문인 경우가 많습니다.
그래서 제 책에서는 설계 문서보다더 스펙(SRS)문서를 만들라고 권하고 있습니다. 또한 뒤늦게 만드는 문서는 필요없고 프로젝트를 더 지연시키므로 만들지 말라고 하고 있습니다.
또 중요한 것은 문서는 가능하면 적게 만드는 것이 가장 좋습니다.
| 프로토타입이란? (8) | 2011/11/03 |
|---|---|
| 스펙에 있어서는 안될 표현들 (8) | 2011/06/20 |
| 개발문서를 만들기는 했는데 업데이트가 안되는 이유 (16) | 2010/03/24 |
| SRS에 대한 인식의 변화 (10) | 2009/11/13 |
| 이건 기능이 아닌데 (4) | 2009/08/03 |
| 고객이 요구사항을 너무 자주 바꿔요. (4) | 2009/07/30 |
저는 문서를 적게 만드는 것 보다는,
doxygen이나 ea 또는 여러 툴들을 병행해서,
문서 작업을 별도로 하지 않아도 항상 up-to-date 하게 만드는 것도 좋은 방법이라고 생각이 듭니다.
셋팅하는게 귀찮지만 말이죠. 한번 하면 인수인계나, 관리할때 편하거든요.. ![]()
안녕하세요. PatternLoad님
Doxygen이나 JavaDoc을 이용하는 것은 Low level design 문서 용도로 아주 좋은 방법이죠. 귀찮더라도 이런 규칙은 프로젝트 초기부터 정하게되면 모두 따르도록 어느정도 강제가 필요합니다. 하지만 Doxygen도 업데이트 안하는 경우도 있더군요. - -;
스펙은 또다른 이슈입니다. 다른 방법이 별로 없습니다. 툴을 이용하는 것도 분석 작업과 업데이트를 대신해주지는 않습니다.
예 그렇죠. 스펙은 아무래도 서로 협의하고 조율해야 되는 부분이니깐요. 정말 게으름과 싸워 이기는 문제는 힘들죠.. 전 SparxSystems의 Enterprise Architect로 이러한 환경을 통합할려고 노력하고 있습니다. 툴이 대신 업데이트 해주지 않아도, 어느정도 연관성을 충분히 잡아주는것 같습니다. 물론 이런일도 꽤 번거로운건 사실이죠.. ![]()
저는 문서에 대한 활용도(접근성 및 검색 용이성)가 높다면 그만큼 최신 내용으로 업데이트 될 가능성이 클거라고 봅니다. 이전 회사에서는 항상 MS워드로 문서를 만들고 게시판에 등록시키도록 강요했습니다. 지식검색시스템을 구축해놓고 윗분들이 보기에 좋은 형상을 만들어 놓은거죠. 하지만 실무에서는 검색도 안되고 접근도 용이하지 않았습니다 (다운로드해서 업데이트 해서 다시 올리고..ㅡㅡ)
전 외부 공개용 문서(메뉴얼등)를 제외하고는 쉽게 활용가능한 툴을 쓰자고 제안했었습니다. 그 방안으로 위키를 제안했었는데 묵살당했죠...ㅋㅋㅋ 로우레벨 문서는 저도 doxygen이 좋은듯..
안녕하세요. 청하님
문서를 작성하기 어려우면 툴은 더욱 쓰기 어려운 측면이 있습니다. 결국은 어디다기 쓰느냐보다도 무엇을 어떻게 쓰느냐가 핵심입니다. 또한 몇십년전부터 이런 시스템이 없었을 때도 문서를 작성하는데 문제가 있는 것은 아니었습니다.
저도 이런 시스템을 도입하는데는 긍정적으로 생각합니다. 다만 문서를 먼저 쓰고 리뷰하는 것을 할 줄 알아야 됩니다.
위키는 위키문법의 장벽이 무시 못하고
그래서 fckeditor + mediawiki 혹은 fckeditor + dokuwiki로 하려고 했는데
아무도 안하시더라구요 ㅠ.ㅠ
언젠가 한번 doxygen을 시도해봐야할꺼 같아요..
안녕하세요. 구차니님
그렇게 쉽게 바뀌면 정말 좋겠습니다. ^^
사람들은 바꾸려고 하지 않는 것이 습성입니다. 일단 익숙하지 않아서 불편해하고, 바꾼다고 나아진다는 확인이 없고, 일이 더 많아지고 귀찮아질까봐 바꾸지 않습니다.
Doxygen도 시도해보고 알아봐 놓는 것은 좋으나 혼자서 열심히 하다가는 혼자만 바쁘고 그 결실은 다 같이 나눠가지다가 금방 포기하고 맙니다. 이런 것은 회사차원에서 강제성을 가지고 추진해야합니다.
저도 작년부터 설치형 게시판, fckeditor + mediawiki 등등등 문서 정리를 위해서 많은 것을 시도해 보고 있는데 강제가 없으면 중간에 잘 안되더군요.
그래서, 전략을 좀 수정했습니다. 우선 제가 강제 할 수있는 프로젝트 팀부터 고과에 반영한다고 엄포를 놓아서 조금씩 해보고 있습니다.^^;
이게 성과가 잘 나오면 전사적 도입도 시도 할 수 있을 것 같아서요....
항상 제가 고민하는 내용을 시의적절하게 포스팅해 주셔서 감사합니다.
안녕하세요. koraper님
전사적인 시행이 어렵다면 시범프로젝트에서 성공사례를 보여주고 설득하는 것도 오래걸리기는 하지만 좋은 방법입니다.
변화되는 것은 사람의 활동이고 좀 처럼 변화되지 않는 것은 문서라고 생각해 봅니다.
으쌰으쌰 해서 잘 된 문서를 만들었다고 해도 이 후에 누가 사용할지 ,또는 어떤 환경요소에 따라서 처음 문서제작의 의미가 살아나거나 또는 죽거나 하는것 같아요.
경험적으론.. 대 다수의 프로젝트가 말씀하신것처럼 '문서을 위한 문서'가 대부분이었던 것 같습니다. 또는 윗선에 보여주기 위한 방편이 많았던 것이 분명했습니다.
이를 개선해 보고자.. DDD에서 말하는 Context Map이라던지, Context Integration과 같이 시간이 지남에 따라 문맥이 흐려지는 것을 막기 위한 전략도 어느정도 타당성이 있어 보이지만..(이게 과연 현실적으로 가능할지..이론적인 것만은 아닌지 더 경험해 봐야만 하는 그런 종류의 것인것 같습니다.)
문서작업을 대부분 싫어해서도 그렇고, 윗선에 보여주기위한 문화라던지, 아니면 문서나 소프트웨어를 인질극으로 삼으려고 하는 사람에겐.. 여간 귀찮은 장애물이 되지 않을까 합니다.
프로젝트 진행이나 의사소통이 하도 되질 않아, 어느정도 강제적인 강압도 필요한 적도 있었습니다. 하지만만 지속적인 강압은 제일 좋지 않은 결과를 낸 것 같은 아쉬운도 많이 남았습니다.
항상 저도 이와 같은 고민을 하고 살아요. 어떻게 하면 개선할 수 있을까? 어떻게 하면 모순을 없앨 수 있을까? 정작 중요한것은 개인의 실력일까 아니면 팀웍 콘트롤일까? 신기술이 중요할까 아니면, 타당성 있는 기술이 중요할까 등등..
규현님 글보면 어찌 제 생각이랑 일치한지~
moova님 안녕하세요.
그래서 항상 개발 문화를 강조합니다.
자연스럽게 무슨 일을 하던지 문서화를 하는 수준까지 되어야 합니다.
꼭 필요한 소수의 문서를 알맞게 만드는 것이지요.
말로 때우는 방식은 더이상 안됩니다.
그렇게 문서를 만드는 것이 가장 빨리 개발하는 방법이라는 것을 깨달아야 합니다.
SRS가 업데이트가 되지 않고 공유도 안되면서 Test Case 문서랑 매치 하려니 여간 답답한 일이 아닐 수 없지요. 뭐 제가 파견 나가 있는 삼X전자 또한 뭐 해당 문제들이 비일비재 합지요.
hoya님 안녕하세요.
그런 케이스는 거의 주먹구구 방식과 다를바 없습니다. 삼X전자에서는 뭔가 체계를 갖추고 근사하게 개발을 하고 있다고 착각할지 모르지만 실리콘밸리의 구멍가게 소프트웨어 회사보다도 못하다는 것을 아직도 깨닫고 있지 못합니다.
그러면서 우리나라의 중소 소프트웨어 회사들의 씨를 말리고 있죠.
기존 문서에 대한 고정 관념을 좀 버렸으면 합니다.
프로젝트를 진행 하다 보면 문서 관리에 대해서 반드시 MS의
word나 ppt 등 특정 파일 포맷으로만 관리 하려고 합니다.
물론 이런 포맷이 쓰이는 문서도 있지만 이틀에서 벗어나면
문서가 아닌 것으로 생각해서 도입을 하지 않습니다.
저런 형식적인 문서보다 차라리 사내에 허접한 게시판 하나
를 만들어서 히스토리 관리 하는게 더 실용적이라고 생각이
듭니다.
안녕하세요.
맞습니다. 어디에 적느냐가 아니고 내용을 작성하는게 중요하죠.
내용을 적을 능력이 없는 사람들은 또 어디에 적더라도 안되기는 마찬가지입니다. 그래서 안된다고 툴만 찾아다기 보다는 무엇을 어떻게 적을지 배워서 꾸준히 해보는 것이 중요합니다.
2011년-사설토토제작 판매
❤직접 눈으로 확인하시고 결정하세요
토토사이트 전용 자바 프로그래머와 전문 디자인너 로 구성되어 빠른 제작과 지속적으로 유지보수 및 서버운영까지 풀 서비스 하고 있습니다 한번 고객은 또 다른 분으로 연결되고 서버 및 유지보수에 안정된 관리로 인정받고 제 구매를 해주시는 믿음과 실력으로 인정받고 있는 작업장 입니다 *사설토토
사용자 패이지
고급스러운 이미지와 다양한 기능으로 유저에게 보다 신뢰 있게 다가 갈수 있도록 전문 디자인너가 충분한 상당 후 제작해 드립니다 또 요즘 무엇이 인기이고 유행인지를 꾸준히 파악하고 한발 앞서 실행과 유행을 창조하고 있다고 자부합니다
(참고로 원하시는 사이트 디자인 100% 똑같이 도 가능합니다)
관리자 패이지
자동방식과, 엑셀방식. 수동방식 모두 겸비한 최신형 버전입니다
저희가 직접 자바언어로 제작해서 판매하고 있습니다
즉 돌고 도는 소스가 아님을 분명히 말씀 드립니다 또 직접 제작한 소스라 수정 및 유지보수가 원활합니다 기능은 너무 많아서 여기서는 생략 하겠습니다 오셔서 상담 받으시고 직접 조작해보시면 됩니다 *사설토토
계약절차
1번 제작사이트의 요구사항을 문서로 만들어서 주세요 ( 기능, 디자인, 로고 )
2번 계약금 100만원 입금
3번 서버계약 ( 일본서버,미국서버,홍콩서버 선택 )
4번 세팅 및 디자인 작업
5번 중도금 100만원
6번 완성확인 후 잔금처리
7번 유지보수 및 서버 관리 ( 선택 )
사이트 제작비용은 총 4백입니다
서버 관리는 원하시는 분에서만 월 소정에 관리비 받고 관리해 드립니다(도메인 등록, 서버세팅, 서버이전, 아이피 변경, 등등 24시간 관리해 드립니다)
총 제작기간은 1주일에서 상항에 따라 2주 정도 입니다
@소스언어는 자바입니다
@상담시 프로그래머인 제가 통화합니다
@직원&투자자 소개 및 동업자 연결시켜 드립니다
msn 메신저 toto8949@hotmail.com
msn 메신저 모르신 분
검색창에 msn메신저 설치 검색하시고 설치하시면 됩니다.
홍콩서버,미국서버,일본서버,사설토토제작
| 개발자는 코딩만 해야 한다. (14) | 2009/07/09 |
|---|---|
| 살아남은 개발자들 (4) | 2009/07/03 |
| 도대체 얼마나 자세히 적어 달라고?! (4) | 2009/06/29 |
| 악순환 vs. 선순환 (2) | 2009/05/22 |
| 이 바닥을 못 벗어난다. (5) | 2009/05/18 |
| 나는 혼자가 아니다. (5) | 2009/05/15 |
문서가 실용적이어야 한다는 의미는 공감합니다만,
> 문서가 거의 바뀌지 않는다면 잘 작성된 것이고, 그렇지 않으면 잘 작성되지 않은 것입니다.
이 부분은 일반적인 이야기가 아니지 않나 생각됩니다. 코드는 문서보다 훨씬 빠르게 바뀌기 때문에 문서는 뒤쳐지게 되어있는데, 아마도 말씀하신 의미상으로는 문서를 이런 변화까지 수용하게 적어야 된다는 것이 아닐까 추측되는데, 그건 잘 작성된 기준으로 생각하기에는 적합한 기준이 아니지 않나 생각됩니다. 문서가 바뀌기 때문에 잘 작성하지 않았다는 것은...
또한, 다음 단계(?)의 개발자가 이를 활용할 수 있는 프로젝트가 있는 반면, 그렇지 않은 프로젝트도 많이 있기도 한 것 같습니다.
charlz님 안녕하세요.
좋은 의견 감사합니다. charlz님의 댓글을 보면 "문서"라는 말을 가지고도 서로 다른 이미지를 그리고 있다는 생각이 듭니다.
예를 들어서 스펙서를 기준으로 보면 설계단계나 구현단계에서 스펙서가 바뀌는 것은 스펙이 바뀐 것이고, 그 변경에 대한 비용을 몇곱절로 치뤄야 합니다. 하지만 개발 기간내에 스펙이 전혀 바뀌지 않는 프로젝트는 찾아보기 힘들죠. 하지만 변경을 최소화는 해야 합니다. 설계가 진행되고 코드가 진행됨에 따라서 스펙서를 바꾸지는 않죠.
그리고 설계서의 경우에도 코드가 진행됨에 따라서 아키텍쳐나 인터페이스의 변경이 있기 전에는 설계서가 변경되지 않습니다. 문서와 코드가 같이 발전해 나가는 경우는 분석, 설계, 구현단계가 적당히 밍글된 형태일 수도 있습니다. 사실 크고 작은 많은 프로젝트가 이렇게 진행되고 성공적으로 잘 끝나기도 합니다. 하지만 이런 방법으로 계속 성장하기는 어려움이 있습니다.
사실 문서가 잘 작성되었는지 판단하기는 대단히 어렵습니다. 그래서 그 한방법을 언급해 봤습니다.
제가 항상 주장하는 것은 개발자들이나 개발사들의 현재 상황에 따른 전투적인 대응방법이 아니고 개발자들이 꾸준히 성장하고 실력도 향상되며 현재 프로젝트를 잘 수행해내기 위한 원론적인 방법들이 주류를 이룹니다. 그런 관점으로 읽어주세요.
charlz님의 의견과 같은 여러 관점은 제가 많은 도움이 되네요. 감사합니다.
문서라 지긋지긋하지요.
정말 돈받고 만드는 프로덕트로서의 문서들은 가끔 종이값과 타이핑값을 받기 위해 만드는거 아닐까 하는 생각이 들곤 합니다. 그래서 도큐멘트도 아니고 산출물이라고 하는게 아닐까 생각하죠. ^^
SI성 프로젝트를 많이 하다보니 몇십종의 산출물들이 과연 필요나 할까 싶을떄가 많기도 하고, 왜 보지도 않고 쓸데도 없는 문서를 주구줄창 만들어야 할까 싶습니다.
경험적으로 생각해보면 산출물은 의사전달을 위한 문서, 생각을 정리하기 위한 문서, 점검을 위한 문서 세종류가 있는 것 갑습니다. (그냥 제 기준입니다.)
무엇을 위해서 작성을 하는지가 중요한 것 같은데.. 문서 프레임에 압도당할때가 만은데요. 잘하지는 못하지만 고객이나 내부 팀원이 쓸 수 있을 만한 표현력이 들어가면 문서의 프레임이야 얼마든지 고칠 수 있지 않나 싶네요. ㅎㅎ
뭐 항상 만들고 나면 이것 저것 한방에 보고 싶다는 욕심에 덕지덕지 붙여넣다가
질려서 흐지부지 되는 경향이 있어서.
될 수 있으면 간략한게 좋지 않나 생각이 드네요.
특히나 고객의 요구사항이 수시로 변할떄는 말이죠.
산더미같이 많은 문서를 만드는 프로젝트들은 아주 잘못된 관행입니다. 소프트웨어 개발에 대해서 잘 모르는 고객이 거대한 방법론에 있는 문서를 무작정 다 요구하곤 합니다. 그 방법론에서도 문서를 다 만들라고 하지 않는데도 잘못 적용하는 것이지요.
하지만 개발사 입장에서 고객이 요구하는데 안만들 수는 없는 노릇이지요. 수많은 문서 중에서 실제 개발에 필요한 문서는 소수에 불과합니다. 그런 문서만 제대로 만들고 나머지 프로세스나 관리를 위한 문서들은 최소한의 노력만 들이는 것이 좋습니다.
| 살아남은 개발자들 (4) | 2009/07/03 |
|---|---|
| 도대체 얼마나 자세히 적어 달라고?! (4) | 2009/06/29 |
| 악순환 vs. 선순환 (2) | 2009/05/22 |
| 이 바닥을 못 벗어난다. (5) | 2009/05/18 |
| 나는 혼자가 아니다. (5) | 2009/05/15 |
| 이거 팔면 돈 되겠는데! (20) | 2009/04/17 |
황상철님 안녕하세요.
열심히 하시는 모습이 보기 좋았습니다. 젊은 개발자들은 만나는 것은 언제나 즐거운 일입니다.
주제가 조금 어려워서 전달이 잘 되었을지 걱정입니다. 만약 다음에 기회가 된다면, 좀더 쥬니어들에게 직접 와닫는 주제를 한번 정해봐야겠습니다. 감사합니다.
| 우리는 다르다. (6) | 2009/10/09 |
|---|---|
| Peer review의 혜택 (2) | 2009/05/13 |
| 개발자 여러분~ 문서 만들기 싫죠? (12) | 2009/05/06 |
| 이 정도도 안되면서 Peer Review를 한다고요? (10) | 2009/04/06 |
| Peer Review의 방해꾼들 (4) | 2009/04/02 |
| Peer Review의 치명적인 유혹 (4) | 2009/04/01 |
항상 실천하는 건 아니지만 제 경우에는 오늘이 회사 다니는 마지막 날이고 내일부터는 다른 사람이 이 문서로 업무를 수행해야 한다라는 생각으로 문서작성을 하려고 노력하고 있습니다.
물론 일정에 쫒기면서 작성한 문서일수록 대충 작성하는 경향이 강해지긴 합니다만... -_-;;
우울한 딱따구리님 안녕하세요.
문서에 대한 생각이 바뀌는 것은 쉬운일이 아닙니다. 이게 문서만의 이슈가 아니고 소프트웨어 개발 전반 모든 것이 바뀌어야 문서의 역할이 달라지니까요.
회사를 옮기시는 건가요?
maddog님 안녕하세요.
학교에서 배울 수 있는 것도 아니고, 필드에서 선배나 스승에게 배워야 하는데, 기회가 많지는 않죠.
맞습니다. 최소한의 꼭 필요한 문서만 만들어야겠죠. 하지만 그 최소한의 꼭 필요한 문서가 무엇인지 잘 모르는 조직이 대부분입니다. 그게 문제죠....
문서화의 중요성은 굳이 제삼제사 설명하지 않아도 누구나 다 아는 것이겠지요. 문제는 '정치적'이라는 것이지요. 발전하는 조직에서는 코드나 문서에 대해 관리자나 경험자가 리뷰하고 잘못된 부분이나 이해가 어려운 부분을 수정하도록 권고합니다. 그러나 그렇지 않은 조직에서는 (개발자의 실수든 뭐든) 잘못된 부분을 '꼬투리'잡고 그것을 향후에 '정치적'으로 이용할 카드로 생각하지요.
규현님 오랜만에 글남깁니다.^^
이제 입사 3년차인저는 누구보다 문서화의 중요성에 공감하는바입니다. 제 목표중하나였구요. 대학교시절엔 무작정 테크니컬 라이팅카페를 개설해보기도했습니다. 물론 노력은 전혀.^^;;;
제가일하는 곳이 외국계 인만큼 문서화는 정말 의무중의 의무라고 할수 있습니다. 심지어 프로젝트 스케줄의 압박도 무시할만큼 중요하게 여기고있죠. 하지만 현재 점점 흐려지고 나약해지는 제 문서화 스킬이 한탄스럽습니다. 외국애들이 만든 문서를 보면 기가 찹니다..심지어 아름답다고 느껴질정도네요. Visio 와World의 조화..환상입니다. 제스스로 물어보면 답이 있겠지만 역시나 큰원인은 테크니컬 Wrtiing기술의 부재네요..더구나 모든 문서가 영어로 작성해야되다보니 개발보다 더 스트레스를 받는게 사실입니다. Visio같은 유용한 툴조차도 제대로 이용못하니까요..
그래서 규현님의 Writing스킬 노하우를 알고싶네요..
잔뜩 두서없이 써놓고 한번 날려먹고 또 두서없이 써봤습니다.
감사합니다.^^
bluepoet님 안녕하세요.
문서의 내용도 중요하지만, 문서를 작성하는 방법, 리뷰하는 방법등 그 과정도 중요하죠. 그런 과정은 배우지 못하고 결과만 보면 정말 배우기 어렵죠.
| 이건 기능이 아닌데 (4) | 2009/08/03 |
|---|---|
| 고객이 요구사항을 너무 자주 바꿔요. (4) | 2009/07/30 |
| Track me, if you can (0) | 2009/05/04 |
| 개발자들이 바글바글한 외딴섬에 떨어진다면 (20) | 2009/04/22 |
| 요구사항 분석의 출발점 (6) | 2009/02/12 |
| UI Mock-up (2) | 2009/01/21 |
| 회의 때문에 일할 시간이 없다. (0) | 2009/08/20 |
|---|---|
| 왜 이리 버그가 많아요? (3) | 2009/05/26 |
| 커뮤니케이션 오류 (0) | 2009/04/19 |
꽤 오래 전에 TV에서 "비교체험 극과 극"이라는 프로그램을 방영한 적이 있습니다. 어떤 아이템을 정해서 가장 비싼 것과 가장 싼 것을 비교하는 프로그램이었는데 꽤 재미있게 본 기억이 납니다. 소프트웨어를 개발하는 현장에서도 극과 극 현상은 드물지 않게 발생합니다. 여러 회사를 분석해보면 완전 주먹구구이거나 또는 너무 무거운 방법론을 도입해서 오히려 부담이 되는 경우가 많습니다. 적당히 중간인 회사를 찾기가 더 어렵습니다. 완전 주먹구구식 가내수공업 형태의 개발방식도 문제가 있지만, 몸집과 역량에 걸맞지 않은 거대한 방법론을 무조건 따라하는 것은 더 문제가 큽니다. 그럴 바에는 차라리 주먹구구가 낫습니다. 그런 주먹구구회사가 문제를 깨닫고 거대 방법론들을 스스로 연구해서 도입을 하면 그 핵심은 모르고 형식만 따라하는 경우가 많습니다. 그러다보면 프로세스가 너무 복잡하고, 문서도 너무 많이 만들어야 되는 경우가 허다합니다. 이런 시도는 거의 실패한다고 보면 됩니다. 애초에 따라 할 수도 없고, 억지로 따라한다면 비용과 시간은 몇 배로 더 들고 회사는 망하기 길 밖에 남지 않습니다. 국내의 대부분의 소프트웨어 회사들은 그러한 거대 방법론은 필요하지도 않습니다. 또 그렇게 많은 문서는 만들 필요도 없습니다. 개발에 필요한 핵심문서 몇 개만 자신들이 만들고 업데이트하고 감당할 수준 정도만 만들어내야 합니다. 극과 극의 양쪽이 아닌 회사에 딱 필요한 수준의 중간점을 찾아서 적용해야 합니다.
| 소프트웨어 관료화 (16) | 2009/08/31 |
|---|---|
| 프로세스가 창의성을 저해한다고? (8) | 2009/04/08 |
| 소프트웨어 개발의 극과 극 (0) | 2009/02/18 |
| Waterfall과 Agile (5) | 2009/02/06 |
| 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은? (6) | 2009/02/04 |
| 인류멸망 그 후(Life after People) (2) | 2009/01/22 |
| 밥그릇을 지키려는 처절한 몸부림(기생충 개발자) (0) | 2009/03/26 |
|---|---|
| 자기 중심적인 사고에 갇힌 개발자 (6) | 2009/03/11 |
| 개발자도 문서를 잘 작성할 수 있어야 한다. (14) | 2009/02/16 |
| 우리는 당장 써먹을 수 있는 경력 개발자 위주로 뽑아요. (6) | 2009/02/10 |
| 타이핑이 느린 프로그래머 (14) | 2009/02/06 |
| 개발자 5적 (10) | 2008/12/22 |
공감합니다.
일전에 "문서 작성 방법"에 대해 정리해서 팀원들에게 나누어 준적이 있는데,
그때 팀원들 반응이 "너도 관리자 다 됐구나" 뭐 이런 냉소적인 반응이었지요.
살짝 상처받았던 기억이 납니다 ^^;
제가 블로그하는 이유 중의 하나가 작문 연습이기도 하죠. 그런데 생각처럼 잘 안 되네요.
그리고 제목에 오타 있습니다.
잘성 -> 작성
문서작성 아무리 강조해도 지나치지 않죠.
특히나 소위 짬밥을 먹으면 먹을수록 더 중요해지는게 전체적인 그림(전체 시스템에 대한 이해라고 보시면 될듯^^)을 파악하는 능력과 함께 문서 작업 + 프리젠테이션 능력이 아닐까 합니다.
역시 문서는? 남에게 보여주기 위한 것입니다.!
돌이아빠님 안녕하세요.
하지만 많은 엔지니어들이 자신이 가지고 있는 정보를 감춤으로써 자신의 가치를 더 높이려하는 경향이 있습니다. 단기적으로는 그런 효과가 있을지 몰라도 결국에는 자신의 미래를 갉아먹는 짓이요.
우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다. 물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다. 개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와..
수많은 소프트웨어 회사들이 첫번째 성공을 거두고 나서 두번째 도약에 실패하고 사라져간다. 물론 첫번째 성공도 어렵지만 이미 성공의 경험이 있고 방법을 알고 있는 회사들이 두번째 또는 세번째에는 많이 실패하는 이유가 무엇일까?..
'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..
우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..
최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..
우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..
우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..
며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..
프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..
"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..
확실히 살아있는 문서를 관리하는게 상당히 힘든걸 또 다시 깨닫고 있게 됩니다.
그런 이유에서 doxygen과 같이 소스코드를 문서화에 포함하는 게 아닐까 싶기도 하구요 ^^
구차니님 안녕하세요.
그래서 문서는 가능하면 적게 꼭 필요한 만큼만 만들어야 합니다.
설계서의 일부를 Doxygen으로 대신 하는 것은 매우 좋은 방법입니다.