'프로젝트'에 해당되는 글 25건

  1. 2012.01.03 기획자에게 힘을 실어주자~ (2)
  2. 2008.09.29 프로젝트 팀원 역할 어떻게 설정해야 할까요?
  3. 2008.09.15 프로젝트의 성공 요인 분석 #2
  4. 2008.09.15 프로젝트의 성공 요인 분석 #1
  5. 2008.09.08 위험관리(Risk Management) 프로세스 #2
  6. 2008.08.28 프로젝트에 이름을 지어주자~
  7. 2008.04.02 Visibility에 대하여
  8. 2007.12.11 변화해야 산다.
  9. 2007.10.18 자주 리펙토링을 하라.(3)
  10. 2007.10.13 자주 리펙토링을 하라.(1)

기획자에게 힘을 실어주자~

|



새해가 밝았습니다. 
올 한해는 모두 소망하는 것들이 이루어지기를 바라겠습니다.

작년의 프로젝트를 정리하고 올 한해의 계획을 세우면서 다시 한번 느낀점이 바로 기획의 부재였습니다.
단순히 이런 아이디어가 좋다라는 것으로 시작해서 개발을 하다 보면
예상하지 못한 이슈들에 부딪히고 결국 흐지부지 되어 버리고 말죠.

누구의 말처럼 새로운 사업을 하는데 있어서 가장 흔한 것이 바로 아이디어가 아닌가 합니다. 
사람들은 자신의 아이디어가 아주 훌륭한 것처럼 이야기 하지만 결국 누구나 다 생각하고 있는 것이 바로 이 아이디어가 아닐런지요?
이런 아이디어를 구체화 하고 실현 가능하도록 만드는 것이 더욱 중요한 부분이라고 봅니다.

그런 측면에서 작년에는 기획이라는 부분의 필요성을 확실히 느꼈습니다. 
현재 기획자들이 경험이 없어서.. 외부의 훌륭한 기획자가 오면 프로젝트가 훨씬 나아지지 않을까 하고 생각도 했습니다.


그런데..
다음 글을 읽으면서 제가 뭔가 근본적인 것부터 잘못 생각하고 있다는 것을 깨달았습니다. 

기획자가 인정하는 기획자 무용론 (http://fredism.com/?p=1129) 

대규모 기업에서는 기획자에게 모든 프로젝트를 총괄하는 Priority가 있다는 겁니다.
그러나 스타트업이나 소규모 기업에서는 기획자에게 이런 권한을 주지 못한다는 것이죠.

생각해 보니 기획자가 첫째로 막히는 부분은 개발자와의 의사소통에 있다고 봅니다. 
저희와 같은 작은 규모의 기업은 개발자가 나이나 경험 등의 측면에서 기획자보다는 상위에 있습니다.
그리고 개발자는 전통적으로 수동적인 입장을 취하는 경우가 많지요.

그러다 보니 기획자가 자신이 생각한 바를 설명하기보다는 개발자의 의견을 듣고 개발이 어렵다고 하면 기획을 수정하게 됩니다.

둘째로 위 글에서처럼 모두 같이 회의하기 때문에 기획자가 만드는 기획안이나 화면구성안이 없어도 프로젝트를 진행하는데 문제가 없고 
또 대표님이나 이사님과 같은 윗분들과의 대화로 이슈를 해결하면서 기획자는 그저 문서나 만드는 작업으로 전략해 버리지 않았나 싶습니다. 

이런 환경이라면 뛰어난 기획자가 온다해도 제 역할을 수행하지 못하고
내부에서는 뛰어난 기획자라면서 별로인데.. 라는 이야기만 듣게 될 확률이 높을 것 같습니다.

올해 성공적인 프로젝트를 위해 기획자의 위상부터 재정립 해봐야겠습니다.
기획, 디자인, 개발, 테스트, 운영, 마케팅에 이르는 전 부분이 어느 하나 중요하지 않은 부분이 없겠지만, 
맨 앞에 있는 기획 부분 부터 차근차근 만들어보려고 합니다.

 





Trackback 1 And Comment 2

프로젝트 팀원 역할 어떻게 설정해야 할까요?

|




프로젝트 관리자가 관리해야 할 항목은 보편적으로 다음의 9가지를 이야기 합니다.
- 품질관리          - 범위관리         - 위기관리          - 통합관리
- 일정관리          - 원가관리         - 인력관리          - 의사결정          - 구매관리

모두 중요합니다만, 프로젝트를 진행하면서 느끼는 점은 결국 사람이 만든 문제는 사람이 해결해야 한다는 점입니다. 즉 인력관리가 가장 복잡하면서도 어렵지 않나 생각합니다.

프로젝트 관리자가 되면, 프로젝트 수행을 위한 팀원을 적든 많든 배정받게 됩니다.
물론 슈퍼맨을 배정받으면 좋겠지만, 대부분은 일반적인 개발자를 만나게 될 겁니다.

이런 경우, 진정한 리더는 팀원들 자체에 신경쓰기 보다는 그 팀원들의 가능성을 식별해야 한다고 합니다.

가능성....

Project Management - A systems approach to Planning, Scheduling, and Controlling이란 책에 보면 프로젝트 관리자가 마주치게 되는 팀원들의 역할을 설명하고 있습니다.

즉, 협력적인 역할을 하는 사람도 있고 반면에 부정적인 역할을 하는 사람도 있다는 것이죠..

부정적인 팀원들의 역할을 방해하고 협력적인 팀원들의 역할을 극대화 시키는 것이 바로 프로젝트 관리자의 중요한 역할이라는 겁니다.

먼저 부정적인 가능성을 가진 팀원들의 성향을 살펴보죠..

 침략자  팀원들을 비판하고 아이디어에 이의를 제기하며 자존심을 꺽는다.
 지배자  조정하고 (업무를) 인수받으려고 시도한다.
 악의 옹호자  모든 사물에서 결점을 찾아내고 모든 아이디어에 이의를 제기한다.
 문제에 대해 갈팡질팡 하는 팀원  아이디어 사이를 왔다 갔다 하며 초점을 맞출 수 없도록 불균형을 조장한다.
 인정을 받아내려는 팀원  항상 지위에 대해 논쟁하고 성공의 공로를 차지하려고 시도한다.
 탈퇴자  참여하지 않고 정보를 공개하지 않는다.
 방해자  계획이 진행되지 않는 것에 대해 여러 가지 이유를 댄다.

이어서 협력적인 가능성을 가진 팀원들을 살펴보면 다음과 같습니다.

 선창자  새로운 아이디어를 찾고 "한번 해보자"란 말을 사용한다.
 정보 탐색자  보다 정보로 무장하려고 노력하고 자원과 지원 데이터를 찾는다. 팀의 이익을 위한 연구를 한다.
 정보 제공자  자신이 알고 있는 것을 공유하여 팀의 지식을 증대시킨다.
 촉진자  다른 사람들의 아이디어에 대해 눈에 보이는 지원을 보여준다.
 분류자  모든 사람이 이슈나 의사결정 사항을 확실히 이해하도록 도와준다.
 조화자  팀 사이의 단결된 감정을 형성한다.
 문지기  모든 정보가 적절하고 팀이 당면하고 있는 이슈에 대해 집중하도록 보증한다.

정리하면서 보니 역시 사람에게는 양면성이라는 것이 존재하는 듯 합니다.
저 역시 문제에 대해 갈팡질팡 하면서 동시에 정보 제공자로서의 역할을 하는 듯 합니다.

결국은 팀원들의 협력적인 가능성을 극대화시키고 부정적인 가능성을 최소화 시킬 수 있는 능력이 필요하다는 것이겠죠..

여러분은 어디에 속하는 팀원이라고 생각하나요?




Trackback 0 And Comment 0

프로젝트의 성공 요인 분석 #2

|



지난 글에서 프로젝트 성공 요인 중 변경관리, 희의관리, 이해관계자, 변화관리에 대해서 살펴봤습니다.
이번에는 이슈화, 리스크관리, 인적자원, 현실과 지표의 괴리에 대해서 알아보겠습니다.

다시 한번 출처를 언급하면 2004년 월간 시사컴퓨터에 기고된 천장락 교수님의 글을 정리해서 옮겨놓은 것입니다.

5. 사소해 보이는 문제도 '이슈화' 하자

프로젝트를 진행하다가 여러 가지 사정으로 계획과는 다르게 진행되거나, 계획대로 진행하기가 곤란한 문제가 발생했을 때 이슈가 발생했다고 합니다. 또 어떤 것이라도 일정에 차질을 주게 되면 이슈로 인식해야 한다고 합니다.

이러한 이슈를 관리하는 절차는 다음 6단계로 되어 있다고 합니다.

이슈 발생 인지 -> 이슈 분류 -> 대응 방안 수립 -> 대응 방안 실행 -> 실행 모니터링 -> 이슈 종결 내용 공지

이슈가 문제가 되면 리스크(위험)이 됩니다.
그럼에도 불구하고 이슈가 발생할 것 같으면 쉬쉬하고 내부적으로 해결해 보려는 노력을 많이 합니다.
프로젝트에서는 이슈가 언제든지 발생할 수 있습니다. 이런 문제를 내부에서만 조용히 해결하려다 더 큰 문제가 많이 발생할 수 있습니다.
사소한 이슈라도 제대로 파악하고 챙기는 프로젝트 관리자가 되어 보시기 바랍니다.

이슈화 전체보기..

6. 프로젝트의 조기 경보기 "리스크 관리"

리스크를 프로젝트나 프로젝트 내의 일부분이 정해진 기간 내에 주어진 예산으로 완료되지 못할 위기에 빠질 수 있는 정도나 기대한 성과가 달성되지 못할 가능성이라고 정의하고 있습니다.

프로젝트 특성상 발생할 수 있는 리스크에 대해서 비슷한 프로젝트를 진행한 경험에서 축적된 지식으로 예측할 수 있으며, 이렇게 예측된 리스크를 관리 우선 순위별로 분류해 리스크 관리 체크 항목을 가지고 리스크를 관리해 나갈 수 있다고 합니다.

그래서 미리 막을 수 있는 대응책과 실제 발생했을 때 처리 방법이 있어야 한다고 이야기 합니다.
또한, 지표를 통해 리스크를 지속적으로 모니터링 할 수 있어야 함은 기본사항이구요..

앞에서 리스크/위험 관리에 대해서는 #1, #2로 정리한 내용이 있습니다.
리스크 완화, 회피, 모니터링, 관리에 대해서 이야기 했었습니다.
이런 위험 관리는 모든 프로젝트에서 중요한 요소라고 다시 한번 강조하고 싶네요..

리스크관리 전체보기..


7. 인적 자원의 파악, 가볍게 여기면 큰 코 다친다.

의욕이 앞서 보유한 자원의 총량을 초과해 프로젝트를 수행하다 보면 프로젝트가 제대로 진행되기 어렵습니다.
특히 인적자원은 사람의 수 뿐만 아니라 그 사람이 보유한 역량의 수준까지도 파악해야 한다고 합니다.

또한 아웃소싱에 의존하는 비율도 미리 정한 것을 초과하지 않도록 해야 하는데, 이유는 추후 유지보수나 관리에 문제가 발생할 소지가 있기 때문입니다. 프로젝트의 핵심 업무는 내부 인력으로 처리하는게 바람직하다고 하네요..

프로젝트 뿐만 아니라 모든 일은 결국 사람이 해결할 수 밖에 없다고 봅니다. 프로젝트에 있어서 갑자기 인력이 교체되거나 역량이 부족한 인력으로 수행하게 되면 댱연히 문제가 발생할 수밖에 없을 겁니다.
아웃소싱에 의존하는 업체도 아웃소싱 인력의 능력에 따라 프로젝트의 성패를 맡겨야 하니 불안할 수밖에 없을 거구요..

인적자원 전체보기..

8. 현실과 지표 사이의 괴리를 메우자

프로젝트를 진행하면서 나오는 몇 % 진행되었다는 숫자에 대한 문제점을 지적하고 있습니다.
산출물 기준으로 진척도를 계산하게 되면 외형은 확인할 수 있지만, 품질은 확인이 곤란하다는 겁니다.
그리고 개발자의 감으로 진척도를 이야기 하면 테스트에 대한 부분이 포함되어 있지 않으며 객관적이지 않은 진행 상황일 수밖에 없다고 합니다.

그래서 전체 진척도와 단계별 진척도를 별도로 관리하고 테스트와 검토 단계의 비중을 높여서 계산해야 한다고 합니다.

어디서 보니까 어른들은 숫자를 참 좋아한다고 합니다. 모든 데이터를 정량화 하는 것은 프로젝트 관리에서도 중요한 작업임에 틀림없습니다.
그러나 그 정량화에는 반드시 현실이 제대로 반영되어 있어야 합니다. 그러기 위해서는 기준이 중요하고, 프로젝트에서도 개발 속도 뿐만 아니라 품질까지도 포함해야 한다는 것이죠..

현실과지표 전체보기..


이상으로 프로젝트의 성공 요인에 대해 정리해봤습니다. 일반적으로 생각하는 부분과 큰 차이가 없어서 정리해봤습니다.

여러분은 어떻게 생각하는지요? 이 외에도 중요한 요소가 있다면 댓글 부탁드립니다.




Trackback 0 And Comment 0

프로젝트의 성공 요인 분석 #1

|



2004년 5월 ~ 12월까지 월간 시사 컴퓨터에 연재된 천정락 교수님의 프로젝트 성공 요인 분석이란 자료가 있습니다.
4년여의 시간이 지났지만, 아직도 현재 진행하고 있는 IT 프로젝트에도 도움이 되는 이야기 인 듯 하여 정리해서 옮겨 봅니다.

1. 업무 변경 관리로 프로젝트 성공률을 높이자.

첫번째로 이야기 한 것은 변경 관리입니다. 프로젝트의 범위나 현업의 업무가 변경된 경우, 의사결정자들과 프로젝트 수행자들이 모여 업무 변경 관리 위원회를 만들고 체크해 나가야 한다는 이야기 입니다.

방법으로는 업무가 변경될 때마다, 단계별로, 프로젝트 막바지에 변경하는 방식이 있는데요
변경될 때마다 하는 것은 번거롭고 프로젝트 진행을 더디게 할 수 있구요.
단계별로 수행하는 것은 프로젝트가 잠시 멈추게 되므로 미리 일정을 반영해서 변경관리를 해야 한다고 합니다.
마지막에 일시에 수행하는 것은 프로젝트가 긴 경우, 업무 변경의 양도 많고 시간도 오래 걸리므로 주의해야 한다고 하네요..

어쨌든 추가 비용이 들더라도 업무 변경 관리는 어떤 형식으로든지 해야 합니다.
보통 프로젝트 수행시에 보면, 마지막에 설계 문서를 한꺼번에 다시 고치는 경우가 가장 많은 것 같습니다.
즉, 프로젝트가 끝난 후에 개발 결과물에 맞추어서 설계문서를 다시 만드는 것인데요..
실질적인 변경관리라고 볼 수는 없다고 봅니다.

정말 성공하는 프로젝트를 만들고 싶다면, 설계를 변경하는 것에 대한 위험성을 고객이나 프로젝트 수행자 모두 인식하고 초기 설계부터 신중을 기해야 할 것입니다.

업무변경관리 전체보기...

2. 회의도 관리가 필요한 시대다.

회의로 인해 낭비되는 시간의 가치에 대해서 이야기 하고 있습니다.
회의를 줄이기 위해 단순한 정보 공유는 이메일이나 인트라넷 게시판을 활용하고, 화상회의 같은 것을 충분히 활용하자는 겁니다.

만약 회의를 진행한다면, 미리 회의 목적과 내용을 회의 참석자에게 알리고, 회의의 시작과 끝나는 시간을 정해서 준수하고, 회의 끝 부분에 안건과 결론을 정리하고, 결론이 난 부분을 해당 부서나 팀에 효과적으로 전달해야 한다고 하네요..

회의가 많은 기업은 그리 성공하지 못한다는 이야기를 들은 적이 있습니다.
물론 회의라는 것이 매우 중요한 것이지만 그만큼 잘못 사용하면 탁상공론에 실행이 뒷받침되지 않는 조직이 될 가능성도 높겠죠..

회의관리 전체보기..

3. 이해관계자를 '내 편'으로 만들어라

이해관계자라 하면 고객과 같은 '프로젝트 스폰서', 프로젝트를 수행하는 '프로젝트 실행자', 프로젝트에는 직접 관여하지는 않지만 영향을 주거나 받을 수 있는 '외부 이해관계자'를 이야기 합니다.

이런 이해관계자를 명확하게 파악하고, 각자의 입장에서 프로젝트 수행에 대한 득실과 주장의 정보를 파악하고, 프로젝트에 대한 영향을 분석하고, 대응전략과 구체적인 실행방안을 세우고, 모니터링 및 피드백을 해야 한다는 겁니다.

여기에서는 주로 외부 이해관계자에 대한 이야기를 하고 있는데요..
저는 일반적으로 IT 프로젝트에 있어서 고객에 초점을 맞추고 싶습니다. 고객이라 하면 외부고객과 내부고객으로 나눠 볼 수 있을 겁니다.
내부에 같이 프로젝트를 진행하는 사람들도 하나의 고객이라고 생각하고 내편으로 만들어 업무를 진행한다면 프로젝트 진행이 좀 더 수월해지지 않을 까 합니다.

이해관계자 전체보기..

4. 프로젝트 연착륙 뒤엔 변화관리가 있다.

여기에서 변화관리는 위의 변경관리와 다른 이야기 입니다. 변경관리가 프로젝트 진행 중에 발생하는 변경 요소를 관리하는 것이라면, 변화관리는 프로젝트 완료 후 새롭게 적용되는 변화에 대한 관리를 말합니다.

프로젝트를 완료하더라도 적용해야 하는 직원들의 새로운 환경이나 제도에 대한 저항을 받을 수 있다고 합니다. 그래서 실행 과정에서 직,간접적으로 영향을 받게 되는 조직원과 고객으로부터 불편을 사게 되면 기대한 만큼의 성과를 내기도 어렵고, 조직원과 이해관계자들한테 성공했다는 평가를 받기 힘들다고 합니다.

변화를 적극 수용하고 변화에 대한 저항을 극복하며, 변화 계획을 세우고 그 계획을 차질 없이 성취해 나가기 위한 변화 관리가 필요하다고 이야기 하고 있습니다.

실제로 어렵게 프로젝트를 통해 결과물을 만들어도 제대로 활용하지 않으면 무용지물일 겁니다.
결국 만드는 것만이 최종 마무리가 아니라 제대로 필요한 곳에 적용하는 것이 성공적인 프로젝트의 마무리가 아닐까 합니다.

변화관리 전체보기..

이어서 나머지 이슈화, 리스크관리, 인적자원, 현실과지표에 대해서 정리해 보도록 할께요~
프로젝트 관리 알면 알수록 배울게 많은 것 같습니다.




Trackback 0 And Comment 0

위험관리(Risk Management) 프로세스 #2

|



지난번에 위험(risk)의 원인, 식별, 위험관리 프로세스에 대해서 이야기했습니다.

위험이라고 하는 것은 드러나기 전에 처리하는 것이 가장 좋기 때문에 이런 위험 관리가 필요합니다.
실제로 위험이 발생한 이후 처리한다면 프로젝트에 타격도 그만큼 크겠죠..

4. 위험 관리

그래서 이번에는 위험을 관리하는 방법에 대해서 먼저 살펴보도록 할께요..
위험을 관리한다고 해서 모든 위험요소를 제거할 수는 없을 겁니다.
그러나 위험관리를 통해서 위험을 회피하거나 위험요인을 줄이거나 위험 발생시 비상대책을 수립하는데 도움이 될 수 있습니다.
이러한 위험관리에 대해서 정리해 봅니다.

1) 획득 (Procurement)
프로젝트 수행 중에 기술적인 위험요소가 발생한다면, 그런 기술을 가지고 있는 사람이나 조직을 구해서 해결하는 겁니다.
언뜻 보기에는 가장 쉬운 방법 같지만, 실제 프로그래밍에서는 추가 비용이 들어가는 문제가 나올 수 있습니다.
뿐만아니라 프로젝트 참여자가 늘어나면서 발생하는 Communication overhead도 무시할 수는 없을 겁니다.

2) 비상계획 (Contingency Planning)
실제 위험이 발생되었을 때, 위험을 완화하거나 피해를 최소화 하기 위해서 수립하는 계획을 말합니다.
발생 위험의 원인별로 비상 시나리오를 작성하여 위험 발생시 즉각 조치를 취할 수 있도록 하는 것도 포함합니다.

비상조치계획에는 위험항목, 위험정도, 위험발생부위, 비상대책전략, 예상되는 비용, 대책별 추진 담당자, 비상 대책 수행일정 등의 정보를 포함해야 한다고 합니다.

3) 대체 전략 (Alternative Strategies)
예정된 방법이 아닌 다른 방법으로 위험요소를 예방하거나 피하는 방법입니다.
예를 들면, 초기 단계에 위험요소에 대한 설계 변경을 함으로써 구현단계에서 발생할 수 있는 설계위험을 줄이는 것을 들 수 있습니다.

4) 보험 (Insurance)
외주와 같이 외부와 공동 작업을 해야 하는 경우, 발생할 수 있는 위험 요소로 부터 보호받기 위한 건데요..
실제 보험에 드는 걸 말합니다. 요즘은 보증보험증권인가 하는 것을 받기도 하죠..

5) 위험 관리 계획 (Risk Management Plan)
프로젝트 전 과정에서 발생할 수 있는 위험들을 관리하는 절차를 문서화 한 것을 말합니다.
RMMMP(Risk Mitigation, Monitoring and Management Plan)이라는 위험 완화, 모니터링 관리 계획에 포함할 수도 있습니다. RMMM에 대해서는 밑에서 한번 더 정리하도록 하죠..

6) 계약 협정
불명확성이야말로 프로젝트를 실패로 이끄는 지름길입니다.
그래서 이런 불명확성을 계약시에 협의하거나 조건을 부여하는 것을 말하는데요..

글쎄요.. 중소기업의 경우 실제 프로젝트에서 이렇게 할 경우, 계약을 성사시킬 수 있을지 의문이 듭니다.
일정 규모 이상이 되는 기업에서는 제안 단계에서 이런부분에 대해 심의하는 팀이 별도로 있는 걸로 알고 있습니다.

7) 위험관리 및 모니터링
계획만 세워놓고 실제 위험이 발생한 것을 알아차리지 못한다면 아무 소용이 없겠죠..
위험은 초기에 발견하고 해결을 해야 그 피해를 최소화 할 수 있습니다.
그런 의미에서 위험 관리 계획 못지 않게 중요한 것이 위험 모니터링입니다.

또한, 고객의 정책 변경으로 위험요소가 없어져 버리거나 솔루션 업그레이드로 인해 기술적 위험요소가 사라지는 등 초기에 위험요소라고 판단했던 부분이 제거되기도 하므로 모니터링을 통해서 지속적으로 관찰해야 할 겁니다.

5. 위험 완화, 모니터링 및 관리계획(RMMMP - Risk Mitigation, Monitoring and Management Plan)

앞서 설명한 TL 9000에 보면 프로젝트 기획 활동 중에 위험관리 및 우발사건 계획서(Risk Management and Contingency Plan)의 작성을 요구하고 있습니다.
프로젝트 관리자는 이 요구사항을 만족하기 위해서 RMMMP를 작성할 수 있습니다.

RMMMP는 앞에서 이야기한 개념들을 토대로 프로젝트 성향에 따라 적합하게 작성하고, 작성된 계획에 따라 위험관리를 수행하면 됩니다.
실제 프로젝트에서 보면 계획서와 실제 활동이 따로 수행되는 경우가 많은데요..
RMMMP뿐만 아니라 모든 프로젝트 관리 프로세스에서 초기 계획의 수정과 보완으로 지속적으로 활동과 맞춰주는 작업이 필요합니다. (말은 쉽지만, 실제 행동이 어려운 부분이죠.. -.-)

RMMMP에 대한 템플릿이 있어 옮겨봅니다. 참고하시면 도움이 될 듯 하네요..

1.0 서론
    이 부분은 RMMMP의 전체적인 개요를 설명한다.

    1.1 RMMM 활동의 범위 및 정도
        RMMM의 목표, 조직의 책임, 활동의 범위 및 정도를 기술한다.

    1.2 위험관리 조직 역할
        위험관리를 위한 책임을 가지고 있는 사람이나 조직을 기술한다.

2.0 프로젝트 위험들
    이 섹션은 이미 알려진 프로젝트 위험들을 기술한다.

    2.1 위험 테이블
        모든 위험들의 발생 확률 및 영향들을 테이블 형태로 제시한다.
   
        2.1.1 위험 M에 대한 기술
            위험 M을 관련된 조건에 따라 기술한다.

        2.1.2 위험 M에 대한 발생 확률 및 영향
            위험에 대한 발생 확률과 영향도를 기술하며, 각각의 위험을 M개까지 기술한다.

    2.2 위험 정제
        높은 발생 확률의 위험과 높은 영향을 미치는 위험들만을 구분하여 기술한다.

3.0 위험완화, 모니터링 및 관리
    이 섹션은 각각의 위험에 대한 위험 완화, 모니터링 및 경영 활동에 대해 기술한다.

    3.1 위험 M을 위한 완화
        위험을 어떻게 피할 수 있는지를 기술하며, 각각의 위험에 대해 M개까지 기술한다.

    3.2 위험 M을 위한 모니터링
        어떤 조건에서 M이 증가하거나 줄어드는지를 결정하기 위한 모니터링 방법에 대해 기술한다.

    3.3 위험 M을 위한 관리
        위험 M이 발생할 때 어떤 비상조치 계획에 따라 관리할 것인지를 기술한다.

4.0 기타 특수 조건들
    프로젝트에 치명적인 위험을 야기하는 특수한 기타 조건들에 대해 기술한다.

6. 위험 정량화

RMMMP를 보면 중간에 "위험 M에 대한 발생 확률 및 영향"이란 말이 나옵니다.
즉, 위험(Risk)을 정량화 해서 발생 확률이나 영향을 추출해야 한다는 것인데요.
이것을 정량화 하는 것이 그리 쉬운 작업은 아닐 겁니다.
그러나 대략적인 느낌만으로 위험을 감지하는 것보다는 수치화해서 체계적으로 관리하는 것이 바람직 하겠죠..

정량화라고 하는 것이 복잡한 요소가 많아서 빼려다가 그냥 정리해 봅니다.
나중에라도 도움이 되겠죠.. ^^

위험을 정량화 하기 위한 먼저 해야 할 작업은 위험 표를 만들어보는 겁니다.
어떤 위험들이 존재하고, 첫번째 글에서 설명한 어떤 위험인지 분류하고, 위험이 발생할 확률은 어떻게 되고, 어떤 영향을 미치는지 정리해 보는 겁니다.

먼저 예를 보고나서 정리를 하도록 하죠..

사용자 삽입 이미지


분류는 다음과 같습니다.
PS : 프로젝트 크기 위험
ST : 엔지니어의 위험
DE : 개발환경에 대한 위험
BU : 비즈니스의 위험

위험 표에서 영향 부분의 값을 결정하기 위해서 고려해야 할 사항은 다음 세가지 입니다.
위험의 성질 : 위험이 발생할 경우 일어날 수 있는 사건들
위험의 범위 : 위험이 존재하는 전체 구역을 나타내는 범위
위험의 타이밍 : 위험이 언제 얼마 동안 영향을 미치게 될지 고려

그래서 영향 부분의 값을 결정할 때는 1 - 재앙적인, 2 - 심각한, 3 - 별로 중요하지 않은, 4 - 무시할 수 있는 정도로 구분합니다.

위 표를 토대로 위험의 발생확률과 영향에 대한 그래프를 다음과 같이 그려서 위험 관리 포인트를 결정할 수 있습니다.

사용자 삽입 이미지



위험 영향과 확률은 관리 관점에 서로 다른 영향을 줍니다. 큰 영향을 미치더라도 확률이 매우 낮은 위험 인자에 대해서는 많은 관리시간을 소비하지 말아야 한다고 합니다. 그러나 높은 확률에 중간 정도의 영향을 미치는 위험과 낮은 영향력을 갖지만 발생 확률이 높은 위험은 반드시 중점 관리하여야 합니다.

앞의 표를 보면서 어떤 생각이 들었나요?
정량적이라면서 수치를 결정하는 방식에서 기준이 없다고 느끼지 않으셨는지요?

그래서 위험의 발생확률을 결정하기 위한 방법들이 여러가지가 있습니다.
수학 및 통계적 계산 방법을 사용하는 몬테 카를로 기법(Monte Carlo Method)가 있구요..
의사결정을 위한 의사결정 나무 기법(Decision Tree Method)가 있습니다.
이런 방법에 대해서는 나중에 기회가 되면 다시 한번 정리해 보도록 하죠..

좀 쉽게 계산할 수 있는 방법으로는 다음과 같은 공식을 적용할 수도 있다고 합니다.

R = P(h)*P(a)*l

여기서 R은 위험이고, P(h)는 위험의 발생 확률, P(a)는 사고나 손실을 유발하는 위험의 발생 확률, 그리고 l은 손실을 양을 나타냅니다.

아니면 아예 정량적인 방법이 불가능할 경우, 위험 요소를 정성적으로 판단하는 것이 유용하게 사용될 수도 있습니다.
정성적인 방법은 위험 요소에 따라 수치가 아닌 A, B, C, D로 나누고 관리하는 형태를 취하면 된다고 하네요..

이상으로 위험관리에 대해서 대략적으로 정리 해 봤습니다.
도움이 되었는지 모르겠네요~ 앞으로 블로그가 약간 아카데믹해지더라도 이해해 주세요 ^^




Trackback 0 And Comment 0

프로젝트에 이름을 지어주자~

|



Don't call me names!
언뜻 보면 "내 이름을 부르지 마라" 일 것 같지만,
실제 의미는 "욕하지 마라", "약올리지 마라" 라는 뜻으로 사용되는 문장입니다.

names가 복수가 아닌 단수형인 name으로 사용되었다면 이름이라는 의미 그대로 쓰였겠지만,
복수가 되면서 여러개의 이름 즉, 별명으로 보기 때문에 위와 같은 뜻이 되었을 거라고 합니다.

이름이라는 것은 하나의 고유한 의미를 가져야 합니다.
그리고 이름을 지어준다는 것은 그 객체(물체이건 상황이건)에 생명력을 불어넣는 계기가 됩니다.

빅무(Big Moo)라는 책에 나오는 이야기 인데요..
뉴턴이 중력을 발견해서 유명해진 것으로 알고 있지만,
실제로 뉴턴이 발견한 것은 미적분과 반사 망원경이라고 합니다.

뉴턴은 미적분과 연금술 연구에 많은 시간을 보냈는데
오히려 그가 유명해진 것은 중력이라는 이름을 붙인 것 때문이라고 합니다.

중력이라는 이름을 부여함으로써 많은 사람들이 중력을 이용할 수 있는 기회를 준 것이죠..

한때 포탈들의 이름이 어떻게 만들어졌는지에 대한 포스팅이 유행했었는데요..
네이버는 navigate(향해하다) + 사람 접미사(er)의 합성어이고,
구글(google)은 googol이라는 10의 100제곱이라는 단어에서 유래했다고 하죠..

사이트가 성공해서 이름이 멋있어 보이는 건지,
이름을 멋지게 지어서 사이트가 성공한 건지는 모르겠네요..

여러분도 지금 하는 프로젝트에 이름을 지어주고, 의미를 부여해 보세요..
아마도 프로젝트가 한결 수월하게 진행되지 않을까 합니다. ^^

김춘수님의 꽃으로 마무리합니다.

내가 그의 이름을 불러 주기 전에는
그는 다만
하나의 몸짓에 지나지 않았다.

내가 그의 이름을 불러 주었을 때
그는 나에게로 와서
꽃이 되었다.

내가 그의 이름을 불러 준 것처럼
나의 이 빛깔과 향기에 알맞는
누가 나의 이름을 불러다오.
그에게로 가서 나도
그의 꽃이 되고 싶다.

우리들은 모두
무엇이 되고 싶다.
너는 나에게 나는 너에게
잊혀지지 않는 하나의 (의미가) 눈짓이 되고 싶다.

                                                 - 김춘수, 꽃 -






Trackback 0 And Comment 0

Visibility에 대하여

|



바라바시가 쓴 링크라는 책에서는 웹에서의 visibility에 대해 이야기 하고 있습니다.

웹에서의 visibility(가시성)의 척도는 바로 링크의 개수이다. 당신의 웹페이지로 들어오는 링크가 많으면 많을수록 그것은 가시적이다.
웹에서의 visibility는 매우 중요하죠.. 만약 내 페이지에 대한 링크가 전혀 없다면, 아무도 제 블로그를 찾아오지 않을 테니까요..

다음으로 서점에 가서 책을 살 때 여러분은 어떤 것을 중점적으로 보나요?

물론 상품평이 좋고, 유명한 책을 고르겠죠.. ^^
저의 경우는 글자 크기와 폰트를 봅니다. 책을 읽는데 부담이 없어야 하기 때문이죠..
어떤 분은 그림이나 표가 많은 책을 산다고 합니다. 글로 주절주절 적어놓은 것보다 하나의 그림이 더 많은 이야기를 해주고 있으니까요..

이런 것들이 바로 visibility에 대한 예가 아닐까 합니다.

마지막으로 프로젝트 관리에 있어 visibility에 대해 생각해 봅시다.
프로젝트 관리에 있어 의사소통의 문제를 많이 이야기 합니다.

어떤 문제에 대해 이야기 할 때 서로 다른 것을 상상하고 대화합니다.
고개를 끄떡이며 회의를 끝내고 서로 자신들의 의견이 통과되었다고 확신하죠..
하지만 프로젝트가 마무리 되어 갈때.. 문제제기를 합니다. 이게 아니었다고...

이런 문제에 대해 visibility를 높여서 보여주는 것이 바로 다음 그림입니다.
(예전에 인터넷에서 많이 떠돌던 그림이죠.. )

사용자 삽입 이미지


위 문제를 글로 설명하는 것보다 그림이 훨씬 이해가 빠를 겁니다.
아마도 의사소통의 문제가 발생하는 것도 이런 visibility를 높여서 논의한다면 충분히 해결할 수 있을 거라고 봅니다.

프로젝트 관리에 있어서도 제안 작업을 할 때, 진도를 추적할 때, 산출물을 작성할 때, 이런 visibility를 고려한다면 보다 쉽게 고객에게 설명할 수 있을 거라고 봅니다.




Trackback 0 And Comment 0

변화해야 산다.

|



개발자로서 살아가는 것은 정말 쉬운 일이 아닙니다.
왜냐하면 끊임없이 변해야만 하기 때문이니까요..

보통의 직업은 한번 익힌 기술을 가지고 어느정도는 평생 먹고 살수가 있습니다.
물론 그들도 끊임없이 자기 발전을 위해 노력하는 면은 있을 겁니다.
그러나 우리 개발자만큼은 아닐거라고 생각합니다.

끊임없이 나오는 새로운 용어와 기술들, 발전하는 하드웨어, 진보하는 플랫폼, 여기에 새로운 언어들까지..
새로운 것을 배워서 2~3년 써먹다 보면 어느덧 구석기 시대의 기술이 되어버리는 느낌이라고나 할까요?

변하기 위해서는 끊임없이 배워야 하지만,
의외로 개발자들은 변화에 익숙하지 않은 것 같습니다.
새로운 것을 받아들이는 것을 두려워하기보다는 귀찮아하는 면이 많은 것 같습니다.

지금 기술로도 충분한데.. 왜 그걸 써야 하는데?
하는 이야기를 많이 합니다.
하지만 2~3년이 지나면 어느덧 지금 기술은 옛날 기술이 되어 버리고..
그런 개발자들은 점점 도태되기 마련이라고 생각합니다.

추가적으로 개발자들에게 변화하는 기술만큼 중요한 또 하나의 요소는 바로 경험이라고 생각합니다.
그동안 프로젝트를 하면서 쌓아온 노하우는 다른 어떤 것과도 바꿀 수 없는 소중한 자산이니까요..

이 경험과 기술발전에 따른 변화의 조화가 이 시대의 개발자에게 요구하는 것이 아닐까 합니다.




Trackback 0 And Comment 0

자주 리펙토링을 하라.(3)

|



리펙토링을 실제로 어떻게 수행하는지.. 마틴 파울러(Martin Fowler)의 리펙토링 책에 나온 내용을 요약합니다.

여기에 정리한 내용은 인덱스 정도로 활용하시고.. 실제 리펙토링을 위한 예제나 자세한 설명은 책을 참고하시기 바랍니다.

1. 메소드 정리 (Composing Methods)

Extract Method (136)
그룹으로 함께 묶을 수 있는 코드 조각이 있으면, 코드의 목적이 잘 드러나도록 메소드의 이름을 지어 별도의 메소드로 뽑아낸다.

Inline Method (144)
메소드 몸체가 메소드의 이름 만큼이나 명확할 때는, 호출하는 곳에 메소드의 몸체를 넣고 메소드를 삭제하라

Inline Temp (146)
간단한 수식의 결과값을 가지는 임시변수가 있고, 그 임시변수가 다른 리펙토링을 하는데 방해가 된다면, 이 임시변수를 참조하는 부분을 모두 원래의 수식으로 바꾸라

Replace Temp with Query (147)
어떤 수식의 결과값을 저장하기 위해서 임시변수를 사용하고 있다면, 수식을 뽑아내서 메소드로 만들고 임시변수를 참조하는 곳을 찾아 모두 메소드 호출로 바꾼다. 새로 만든 메소드는 다른 메소드에서도 사용될 수 있다.

Introduce Explaining Variable (151)
복잡한 수식이 있는 경우에는, 수식의 결과나 또는 수식의 일부에 자신의 목적을 잘 설명하는 이름으로 된 임시변수를 사용하라.

Split Temporary Variable (155)
루프 안에 있는 변수나 collecting temporary variable도 아닌 임시변수에 값을 여러 번 대입하는 경우에는, 각각의 대입에 대해서 따로따로 임시변수를 만들어라.

Remove Assignments to Parameters (159)
파라미터에 값을 대입하는 코드가 있으면, 대신 임시변수를 사용하도록 하라.

Replace Method with Method Object (163)
긴 메소드가 있는데 지역변수 때문에 Extract Method를 적용할 수 없는 경우에는, 메소드를 그 자신을 위한 객체로 바꿔서 모든 지역변수가 그 객체의 필드가 되도록 한다. 이렇게 하면 메소드를 같은 객체 안의 여러 메소드로 분해할 수 있다.

Substitute Algorithm (167)
알고리즘을 보다 명확한 것으로 바꾸고 싶을 때는, 메소드의 몸체를 새로운 알고리즘으로 바꾼다.

2. 객체간의 기능 이동

Move Method (170)
메소드가 자신이 정의된 클래스보다 다른 클래스의 기능을 더 많이 사용하고 있다면, 이 메소드를 가장 많이 사용하고 있는 클래스에 비슷한 몸체를 가진 새로운 메소드를 만들어라. 그리고 이전 메소드는 간단한 위임으로 바꾸거나 완전히 제거하라.

Move Field (175)
필드가 자신이 정의된 클래스보다 다른 클래스에 의해서 더 많이 사용되고 있다면, 타켓 클래스에 새로운 필드를 만들고 기존 필드를 사용하고 있는 모든 부분을 변경하라.

Extract Class (179)
두 개의 클래스가 해야 할 일을 하나의 클래스가 하고 있는 경우, 새로운 클래스를 만들어서 관련 있는 필드와 메소드를 예전 클래스에서 새로운 클래스로 옮겨라.

Inline Class (184)
클래스가 하는 일이 많지 않은 경우에는, 그 클래스에 있는 모든 변수와 메소드를 다른 클래스로 옮기고 그 클래스를 제거하라.

Hide Delegate (187)
클래스가 객체의 위임 클래스를 직접 호출하고 있는 경우, 서버에 메소드를 만들어서 대리객체를 숨겨라.

Remove Middle Man (191)
클래스가 간단한 위임을 너무 많이 하고 있는 경우에는, 클라이언트가 대리객체를 직접 호출하도록 하라.

Introduce Foreign Method (194)
사용하고 있는 서버 클래스에 부가적인 메소드가 필요하지만 클래스를 수정할 수 없는 경우에는, 첫 번째 인자로 서버 클래스의 인스턴스를 받는 메소드를 클라이언트에 만들어라.

Introduce Local Extension (196)
사용하고 있는 서버 클래스에 여러 개의 메소드를 추가할 필요가 있지만 서버 클래스를 수정할 수 없는 경우, 필요한 추가 메소드를 포함하는 새로운 클래스를 만들어라. 이 확장 클래스를 원래 클래스의 서브클래스 또는 래퍼 클래스로 만들어라.

3. 데이터 구성 (Organizing Data)

Self Encapsulate Field (205)
필드에 직접 접근하고 있는 필드에 대한 결합이 이상해지면, 그 필드에 대한 get/set 메소드를 만들고 항상 이 메소드를 사용하여 필드에 접근하라.

Replace Data Value with Object (209)
추가적인 데이터나 동작을 필요로 하는 데이터 아이템이 있을 때는, 데이터 아이템을 객체로 바꾸어라.

Change Value to Reference (213)
동일한 인스턴스를 여러 개 가지고 있는 클래스가 있고 여러 개의 동일한 인스턴스를 하나의 객체로 바꾸고 싶으면, 그 객체를 참조 객체로 바꾸어라.

Change Reference to Value (217)
직고, 불변성(immutable)이고 관리하기 어려운 참조 객체가 있는 경우, 그것을 값 객체로 바꾸어라.

Replace Array with Object (220)
배열의 특정 요소가 다른 뜻을 가지고 있다면, 배열을 각각의 요소에 대한 필드를 가지는 객체로 바꿔라.

Duplicate Observed Data (224)
GUI 컨트롤에서만 사용 가능한 도메인 데이터가 있고 도메인 메소드에서 접근이 필요한 경우, 그 데이터를 도메인 객체로 복사하고 옵저버를 두어 두 데이터를 동기화하라.

Change Unidirectional Association to Bidirectional (232)
각각 서로의 기능을 필요로 하는 클래스가 있는데, 링크가 한쪽 방향으로만 되어 있는 경우, 반대 방향으로 포인터를 추가하고 수정자(modifier)가 양쪽 세트를 모두 업데이트 하게 변경하라.

Change Bidirectional Association to Unidirectional (236)
서로 링크를 가지는 두 개의 클래스에서 한 쪽이 다른 한쪽을 더 이상 필요로 하지 않을 때는 불필요한 링크를 제거하라.

Replace Magic Number with Symbolic Constant (240)
특별한 의미를 가지는 숫자 리터럴이 있으면, 상수를 만들고 의미를 잘 나타내도록 이름을 지은 다음 숫자를 상수로 바꾸어라.

Encapsulate Field (242)
public 필드가 있는 경우, 그 필드를 private으로 만들고 접근자를 제공하라.

Encapsulate Collection (244)
컬렉션(collection)을 리턴하는 메소드가 있으면, 그 메소드가 읽기 전용 뷰를 리턴하도록 만들고 add/remove 메소드를 제공하라.

Replace Record with Data Class (254)
전통적인 프로그래밍 환경에서 레코드 구조에 대한 인터페이스가 필요한 경우, 그 레코드를 위한 데이터 객체를 만들어라.

Replace Type Code with Class (255)
클래스의 동작에 영향을 미치지 않는 숫자로 된 타입 코드가 있으면 숫자를 클래스로 바꾸어라.

Replace Type Code with Subclass (261)
클래스의 동작에 영향을 미치는 변경 불가능하는 타입코드가 있다면, 타입 코드를 서브클래스로 바꾸어라.

Replace Type Code with State/Strategy (265)
클래스의 동작에 영향을 미치는 타입 코드가 있지만 서브클래싱을 할 수 없을 때는 타입 코드를 스테이트(state) 객체로 바꾸어라.

Replace Subclass with Fields (270)
상수 데이터를 리턴하는 메소드만 다른 서브클래스가 있으면, 그 메소드를 수퍼클래스의 필드로 바꾸고 서브클래스를 제거하라.

4. 조건문의 단순화

Decompos Conditional (276)
복잡한 조건문 (if-then-else)이 있는 경우, 조건 then 부분 그리고 else 부분에서 메소드를 추출하라.

Consolidate Conditional Expression (278)
같은 결과를 초래하는 일련의 조건 테스트가 있는 경우, 그것을 하나의 조건식으로 결합하여 뽑아라.

Consolidate Duplicate Conditional Fragments (281)
동일한 코드 조각이 조건문의 모든 분기 안에 있는 경우, 동일한 코드를 조건문 밖으로 옮겨라.

Remove Control Flag (283)
일련의 boolean 식에서 컨트롤 플래그 역할을하는 변수가 있는 경우, break 또는 return을 대신 사용하라.

Replace Nested Conditional with Guard Clauses (288)
메소드가 정상적인 실행 경로를 불명확하게 하는 조건 동작을 가지고 있는 경우, 모든 특별한 경우에 대해서 보호절을 사용하라.

Replace Conditional with Polymorphism (293)
객체의 타입에 따라 다른 동작을 선택하는 조건문을 가지고 있는 경우, 조건문의 각 부분을 서브클래스에 있는 오버라이딩 메소드로 옮겨라. 그리고 원래 메소드를 abstract로 만들어라.

Introduce Null Object (298)
null 체크를 반복적으로 하고 있다면, null 값을 null 객체로 대체하라.

Introduce Assertion (306)
코드의 한 부분이 프로그램의 상태에 대하여 어떤 것을 가정하고 있으면, assertion을 써서 가정을 명시되게 만들어라.

5. 메소드 호출의 단순화

Rename Method (313)
메소드의 이름이 그 목적을 드러내지 못하고 있다면, 메소드의 이름을 바꿔라.

Add Parameter (316)
어떤 메소드가 그 메소드를 호출하는 부분에서 더 많은 정보를 필요로 한다면, 이 정보를 넘길 수 있는 객체에 대한 파라미터를 추가하라.

Remove Parameter (318)
파라미터가 메소드 몸체에서 더 이상 사용되지 않는다면, 그 파라미터를 제거하라.

Separate Query from Modifier (320)
값을 리턴할 뿐만 아니라 객체의 상태도 변경하는 메소드를 가지고 있는 경우, 두 개의 메소드를 만들어서 하나는 값을 리턴하는 역할을 하고, 하나는 객체의 상태를 변경하는 역할을 하게 하라.

Parameterize Method (325)
몇몇 메소드가 메소드 몸체에 다른 값을 포함하고 있는 것을 제외하고는 비슷한 일을 하고 있다면, 다른 값을 파라미터로 넘겨 받는 하나의 메소드를 만들어라.

Replace Parameter with Explicit Methods (327)
파라미터의 값에 따라서 다른 코드를 실행하는 메소드가 있다면, 각각의 파라미터 값에 대한 별도의 메소드를 만들어라.

Preserve Whole Object (331)
어떤 객체에서 여러 개의 값을 얻은 다음 메소드를 호출하면서 파라미터로 넘기고 있다면, 대신 그 객체를 파라미터로 넘겨라.

Replace Parameter with Method (335)
객체가 메소드를 호출한 다음, 결과를 다른 메소드에 대한 파라미터로 넘기고 있다. 수신자 또한 이 메소드를 호출할 수 있다면 그 파라미터를 제거하고 수신자가 그 메소드를 호출하도록 하라.

Introduce Parameter Object (339)
자연스럽게 몰려다니는 파라미터 그룹을 가지고 있다면, 그것들을 객체로 바꾸어라.

Remove Setting Method (344)
어떤 필드가 객체 생성시에 값이 정해지고 그 이후에는 변경되지 않아야 한다면, 그 필드 값을 설정하는 모든 메소드를 제거하라.

Hide Method (348)
메소드가 다른 클래스에서 사용되지 않는다면, 그 메소드를 private로 만들어라.

Replace Constructor with Factory Method (350)
객체를 생성할 때 단순히 생성하는 것 이외에 다른 작업도 하고 있다면, 생성자를 팩토리 메소드로 대체하라.

Encapsulate Downcast (355)
메소드가 그 호출부에서 다운캐스트 될 필요가 있는 객체를 리턴하고 있다면 다운캐스트 하는 것을 메소드 안으로 옮겨라.

Replace Error Code with Exception (357)
메소드가 에러를 나타내는 특별한 코드를 가지고 있다면, 대신 예외를 던져라.

Replace Exception with Test (363)
호출부에서 먼저 검사할 수 있는 조건에 대해 예외를 던지고 있다면, 호출부가 먼저 검사하도록 바꿔라.

6. 일반화 다루기

Pull Up Field (368)
두 서브클래스가 동일한 필드를 가지고 있다면, 그 필드를 수퍼클래스로 옮겨라.

Pull Up Method (370)
동일한 일을 하는 메소드를 여러 서브클래스에서 가지고 있다면, 이 메소드를 수퍼클래스로 옮겨라.

Pull Up Constructor Body (373)
서브크래스들이 대부분 동일한 몸체를 가진 생성자를 가지고 있다면, 수퍼클래스에 생성자를 만들고 서브클래스 메소드에서 이것을 호출하라.

Push Down Method (376)
수퍼클래스에 있는 동작이 서브클래스 중 일부에만 관련되어 있다면, 그 동작을 관련된 서브클래스로 옮겨라.

Push Down Field (377)
어떤 필드가 일부 서브클래스에 의해서만 사용되고 있다면, 그 필드를 관련된 서브클래스로 옮겨라.

Extract Subclass (378)
어떤 클래스가 일부 인스턴스에 의해서만 사용되는 기능을 가지고 있다면, 기능의 부분집합을 담당하는 서브클래스를 만들어라.

Extract Superclass (384)
비슷한 메소드와 필드를 가진 두 개의 클래스가 있다면, 수퍼클래스를 만들어서 공통된 메소드와 필드를 수퍼클래스로 옮겨라.

Extract Interface (389)
여러 클라이언트가 한 클래스 인터페이스와 동일한 부분 집합을 사용하고 있거나, 두 클래스가 공통된 인터페이스를 가지는 부분이 있다면, 그 부분 집합을 인터페이스로 뽑아내라.

Collapse Hierarchy (392)
수퍼클래스와 서브클래스가 별로 다르지 않다면, 그것들을 하나로 합쳐라.

Form Template Method (393)
각각의 서브클래스에 동일한 순서로 비슷한 단계를 행하지만 단계가 완전히 같지는 않은 두 메소드가 있다면, 그 단계를 동일한 시그니처를 가진 메소드로 만들어라. 이렇게 하면 원래의 두 메소드는 서로 같아지므로, 수퍼클래스로 올릴 수 있다.

Replace Inheritance with Delegation (401)
서브클래스가 수퍼클래스 인터페이스의 일부분만 사용하거나 또는 데이터를 상속 받고 싶지 않은 경우, 수퍼클래스를 위한 필드를 만들고 메소드들이 수퍼클래스에 위임하도록 변경한 후 상속 관계를 제거한다.

Replace Delegation with Inheritance (404)
위임을 사용하고 있는데 전체 인터페이스에 대해 간단한 위임을 자주 작성하고 있다면, 위임하는 클래스를 대리객체의 서브클래스로 만들어라.




Trackback 0 And Comment 0

자주 리펙토링을 하라.(1)

|



프로그래머들은 한번쯤 리펙토링이라는 것을 들어봤을 겁니다.
리펙토링이 좋다는 것은 익히 들어 알겠는데 실제로 못하는 경우가 대부분입니다.

왜 그럴까요?

우선, 리펙토링이 무엇이고 어떻게 하는 것인지 모르기 때문인 것 같습니다.
솔직히 저도 리펙토링 관련 책을 이번에 읽어보기는 했지만,
아직도 어떤 경우에 리펙토링을 해야 하는지 느낌이 확 오지는 않습니다. -.-

A->B로 변경하는 것이 설명되어 있으면, 바로 B->A로 바꾸는 것도 설명되어 있습니다.
즉, 경우에 따라 적용하는 리펙토링이 다르다는 것인데.. 이건 경험이 필요한 것 같습니다.~
끊임없이 생각해보고 변경하다보면 어떤 것이 올바른 리펙토링인지 알수 있지 않을까 합니다.

다음으로는 리펙토링을 하고 있으면, 윗분들은  아무것도 하지 않고 있다고 생각하는 경우가 많을 것 같습니다.
열심히 뭔가 코드를 고치고는 있는데, 프로그램 결과물이 바뀐게 없으니까요..
리펙토링은 기능개선이나 디버깅과 달리 프로그램을 현재 상태 그대로 두고 소스코드만 이해하기 쉽게 바꾸는 것이니까요..

하지만 이 작업의 중요성을 충분히 설명해 주어야 한다고 생각합니다.
프로젝트가 대규모가 될수록.. 추후 유지보수를 위해서도 리펙토링은 반드시 필요하거든요.

방법론에 따른 산출물이 있지 않느냐? 하고 반문할 수도 있지만..
글쎄요~~ 산출물은 끊임없이 바뀌는 프로그램을 모두 반영할 수 있을지 솔직히 의문이거든요
특히, 산출물에 기반하는 개발이 아닌, 개발후 형식적으로 만드는 산출물은 더욱 문제겠지요..
리펙토링을 통해 소스 자체가 훌륭한 산출물이 된다면 더할 나위 없지 않을까 합니다. ^^

사용자 삽입 이미지



마틴파울러(Martin Fowler)의 다음 이야기가 떠오르네요..
"컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다."
그렇다면, 리펙토링은 언제 해야 할까요?
자주.. 생각날 때마다 하는 것이 따로 일정을 잡아서 하는 것보다는 수월하다고 하네요..

그리고 리펙토링을 하려면 잘못됐을 때 소스를 이전 버전을 바꿀 수 있는 버전관리와..
현재 프로그램 전체를 테스트할 수 있는 테스트코드 또한 중요한 요소라고 합니다.

리펙토링을 통해서 잘 디자인된 소스코드를 만드시기 바랍니다.




Trackback 0 And Comment 0
prev | 1 | 2 | 3 | next