'프로젝트관리론/프로젝트지침'에 해당되는 글 9건

  1. 2008/01/04 평생 학습을 통해 배워라.
  2. 2007/07/23 다양한 프로그래밍 언어를 익혀라... (5)
  3. 2007/07/19 요구사항을 수집하지 말고 채굴하라
  4. 2007/07/10 상습적인 야근을 자제하자~ (2)
  5. 2007/06/12 소스를 모두 다 만들려고 하지 마라.
  6. 2007/06/01 소스코드 버전관리를 활용하라. (2)
  7. 2007/05/21 프로토타입을 통해 학습하라.
  8. 2007/05/19 실패를 축하하라
  9. 2007/05/17 깨진 창문을 내버려 두지 말라

평생 학습을 통해 배워라.

|


언제부터인지 모르지만 평생 학습이란 말이 보편화되었습니다.
그만큼 이제 공부라는 것은 학창시절로 끝이 아니라, 사회생활을 하면서도 지속되어야 하는 것이 되어 버린 것이죠..
오죽하면 일과 공부를 병행하는 셀러던트라는 신조어가 나오기도 했습니다.

지난번 포스팅인 변화해야 산다. 에서 이야기 했듯이 프로그래밍 분야에서도 끊임없는 자기개발이 중요한 요소인 것이 사실입니다.

그렇다면, 프로그래머들은 어떻게 평생 학습을 해 나가야 할까요?

1. 꾸준히 해야 한다.
일반 수험생들에게 항상 하는 이야기이지만, 벼락치기는 전혀 도움이 안됩니다.
프로그래밍과 같은 분야에서도 마찬가지입니다.
지금 하는 공부는 당장 필요할 수도 있지만, 향후 몇년 후에 더 가치가 있을 수도 있는 겁니다.
꾸준히 그리고 천천히 계획을 가지고 학습하는 것이 중요하다고 생각합니다.

2. 편식하지 말자.
프로그래머라고 해서 프로그래밍 공부만 하면 안됩니다.
또, 난 Java 개발자니까... 하면서 java라는 특정 언어만 하면 안된다고 생각합니다.
다양한 프로그래밍 언어를 익혀라에서 설명한 것처럼 개발자로서 다양한 언어를 다룰 수 있어야 한다고 봅니다.

더 나아가서.. 프로그래밍뿐만이 아니라 거시적으로 여러가지 정치, 경제, 사회등으로 관심을 넓혀가면서 본인의 프로그래밍을 어떻게 다른 분야와 연동해 우리의 삶을 보다 윤택하게 할 수 있을까 하는 고민까지 하면 좋겠죠..

3. 책을 많이 읽자.
인터넷이 보편화되면서 개발자들 사이에서도 책을 읽지 않는 분들이 조금씩 나타나고 있습니다.
조금만 검색해보면 결과가 나오는데, 뭐하러 책을 처음부터 읽고 있느냐 하는 것이죠..

하지만, 단편적인 검색 결과로 현재의 문제 하나만 해결하기보다는 전체적인 줄거리가 있는 책을 읽음으로서 본인의 시야를 넓히는 것이 중요하다고 봅니다.

다행히 IT 관련 서적들은 그림도 있구... 소스도 있어서... 책은 두꺼워도 실제 읽는데는 그리 많은 시간이 들지는 않을 겁니다.

4. 동기를 부여해야 한다.
솔직히 말이 평생학습이지.. 동기 부여가 되지 않으면 학습 자체가 어려운 것이 사실입니다.

동기를 부여하는 방법은 여러가지가 있을 겁니다.
야간 대학원이나 사이버대학을 통해 학위를 따면서 동기 부여를 할 수도 있구요..
자격증을 목표로 학습할 수도 있을 겁니다.

항상 노력해서 끊임없이 발전하는 개발자 여러분이 되시기 바랍니다.


크리에이티브 커먼즈 라이선스
Creative Commons License




Trackback 0 And Comment 0

다양한 프로그래밍 언어를 익혀라...

|


개인적으로 올 초에 Ruby on Rails를 좀 살펴봤었습니다.

10년 전에 만들어진 Ruby라는 언어와.. 일종의 프레임워크를 적용하여 웹 어플리케이션을 개발할 수 있는 환경을 제공하는 Rails라는 것이었는데요...
물론 실전에서는 한번도 써보지 못하고.. 걍 예제 프로그램 정도만 만들어 봤었죠~

요즘은 Groovy라는 언어와 Grails라는 것을 보고 있습니다.
자바와 같은 바이트 코드를 만들어 주는 스크립트 언어인 Groovy에.. rails와 비슷한 MVC 환경을 만들어 주는 Grails가 있다고 하더군요..

아무래도 자바 환경에서 동작하므로 ruby on rails 보다는 쓰임새가 많을 것 같아.. 살펴보고 있습니다.

오늘 이런 이야기로 시작하는 이유는.. 제 개인적인 욕심 때문입니다. -.-
개인적으로 프로그래머는 언어에 구애를 받으면 안된다고 생각합니다.
또한, 최소한 1년에 하나씩 새로운 언어를 익히려고 노력해야 한다고 생각합니다.

제가 처음 대학에서 컴퓨터공학을 전공할 때만 해도..
언어는 Fortran, Basic, C 가 있었습니다.
이때는 C만 잘하면, 어디서든지 큰소리를 칠 수 있는 환경이었었죠..

하지만, 지금은 환경이 다릅니다.
매일 매일 새로운 언어가 나오고 있고.. 기존의 언어들도 끊임없이 업그레이드 하고 있습니다.

특정언어에 대해 아무리 잘 알고 있다고 하더라도..
다른 언어를 활용하면 더욱 쉽고 빠르게 구현할 수도 있는 것입니다.

그래서 구현에 얽매이지 말고.. 아키텍트나 알고리즘에 좀 더 신경을 쓰는 것이
바람직하지 않을까 하는게.. 제 생각입니다.
그러기 위해서 새로운 언어를 받아들이는데 거부감이 없어야 한다고 생각하구요..

그러나 현실적으로 쉽지는 않습니다.~~
또한 다른 프로그래머들에게 물어보면..
저에게 전형적인 프로젝트 관리자 적인 마인드라고 합니다.

개발자 입장에서는 새로운 언어를 익히는 것이 새로운 외국어를 익히는 것 만큼 낯설게 느껴지기 때문이기도 하는가 봅니다.

정리하면 제 생각은 이렇습니다.
"먼저 기본이 되는 프로그래밍 언어를 하나정도 아주 깊게 이해해야 합니다.
개인적으로는 C언어를 추천하지만, Java나 C++도 괜찮습니다.
그리고 난 후, 다른 언어들을 1년에 하나씩만 추가해 나가면.. 최고의 프로그래머가 되지 않을까요?"

과연 제 생각이 맞다고 보시나요?
또 최고의 프로그래머가 되면 그 다음은.....??


크리에이티브 커먼즈 라이선스
Creative Commons License




Trackback 0 And Comment 5

요구사항을 수집하지 말고 채굴하라

|


실용주의 프로그래머 책에 다음과 같은 이야기가 나옵니다.

요구사항이 지면에 놓여져 있는 경우는 퍽 드물다.
보통은 가정과 오해, 정치의 지층들 속 깊이 묻혀 있다.

프로젝트를 진행하면서 가장 어려운 부분이 요구분석단계라고 생각합니다.

열심히 분석하고 반영해도..
프로젝트 진행 중에 결국 수정이 발생하는 부분이기도 하구요..
발생한 수정에 대해 누구의 탓도 할 수 없게되는~~

그래서 실제로 그 프로그램을 사용할 사람들과 함께 일하면서
사용자 처럼 생각해 보는 것이 도움이 된다고 이야기를 하기도 합니다.

고객과의 의사소통이 중요한 것은 다음 그림에서도 잘 표현되어 있는 것 같습니다.

사용자 삽입 이미지

예전에 데브피아에서 가져온 것인데.. 정확한 출처는 모르겠네요.. -.-

그리고 미친병아리님이 올린 다음 글도 참고해보세요~~
사용자 스토리 : 고객 중심의 요구사항 기법..

요구사항의 중요성에 대해서 잘 설명해 놓은 것 같습니다.

크리에이티브 커먼즈 라이선스
Creative Commons License




Trackback 0 And Comment 0

상습적인 야근을 자제하자~

|


얼마전 IT 개발자의 야근에 대한 글이 블로고스피어에 많이 나온 적이 있었습니다.
저도 IT 개발자들의 야근~~  이라는 제목으로 포스트를 하나 올렸었는데요..

오늘은 프로젝트 관리에 있어서 야근, 즉 초과근무를 어떻게 바라봐야 할 것인지에 대해서 간단히 이야기하려고 합니다.

먼저 야근을 왜 하게 될까? 하고 생각해 봤습니다~~

첫째는 본인 스스로 눈치를 보면서 하지 않을까 합니다.
모두 야근하는데.. 나만 먼저 가면 찍히니까..

둘째는 관리자의 압력에 의해서..
즉, "이것 오늘까지 끝내~~" 하는 무리한 작업요청이 있을 수 있죠..

셋째는 정말로 할일이 많아서...
딱히 할 말이 없는 경우죠. 하지만, 이런 경우는 프로젝트에서 한 두번 마감 직전에 있지 않을까 합니다.
그렇지 않다면 프로젝트의 일정관리에 문제가 있었겠죠~

그럼.. 첫번째와 두번째에 대해 살펴보죠..

Dead Line이라는 책을 보면 다음과 같은 이야기가 있습니다.


압력과 초과근무 시간을 사용하는 실제 이유는 ...

프로젝트가 실패하더라도 모든 사람들이 최선을 다한 것처럼 보이기 위해서일 것이다.

모든 사람들이 최선을 다한 것처럼 보이기 위해서..


즉, 프로젝트의 성공이 아니라~ 실패했을 때를 위한 면죄부라는 이야기인데....



이런 프로젝트는 100% 실패할 거라는 생각이 들었습니다.


일단, 압력이든 뭐든.. 스트레스를 받으면 업무의 효율성이 극도로 떨어진다고 합니다.


또한 단기간이 아닌 장기간에 걸친 야근도 생산성의 감소로 이어진다고 합니다.



프로젝트 관리 측면에서 볼 때, 어떤 방법이 과연 합리적일까요?

첫번째를 고려한다면, 먼저 개발자는 퇴근 후 시간을 자기개발을 위해서,


취미생활을 위해서, 프로젝트의 남은 업무를 처리하기 위해서.. 자유롭게 분배해서 활용할 수 있어야 합니다.


굳이 PM등 타인의 눈치를 보면서 할 필요는 없다는 것이죠..

(대부분의 프로젝트가 일정이 촉박하다구요? 아마도 그럴 것입니다.


하지만, 야근을 염두에 두고 무의미하게 보내는 낮시간을 생각해보면.. 답이 보일것 같다는 생각도 듭니다.)



두번째를 보면, 관리자 입장에서는 개인별로 1주 분량의 적절한 업무 할당을 해주면 될 것 같습니다.


전체 프로젝트 일정을 보면서 스스로 해당 주 내에 업무를 분산 처리할 수 있도록 융통성을 주는 것이죠..

물론 할당된 업무는 일과시간내에 열심히 하면 마무리 할 수 있을 정도로만 주는 것이 좋구요~~


할당한 업무를 완료했는지 여부로 개개인의 개발능력을 판단하시는 것이 바람직하다고 봅니다.


단순한 업무시간이 아니라~~

쩝.. 다 쓰고 나니.. 두서없이 혼자 중얼거린듯한 느낌이 드네요 -.- 에궁~~


크리에이티브 커먼즈 라이선스
Creative Commons License




Trackback 0 And Comment 2

소스를 모두 다 만들려고 하지 마라.

|


요즘~ 필요하다고 생각하는 소스는 공개되어 있는 것도 많고
또.. 컴포넌트 단위로 저렴하게 구입할 수 있는 것도 많습니다.

그러므로 모든 소스를 직접 구현하겠다는 생각은 굉장히 위험한 것이라고 생각합니다.
비록 프로그래밍 코딩에 자신도 있고, 알고리즘 구현도 잘 한다고 할지라도
이미 만들어진 것을 구현하는데 들어갈 노력을...
더 나은 사용자 환경 구축이나 최적화 등에 힘쓰는 것이 바람직 하다고 생각합니다.

더 나아가 본인 스스로나 팀 내부에서 작성한 소스들도 재사용이 가능하도록 정리하려는 노력이 필요합니다.
경우에 따라, 같은 프로젝트에 동일한 일을 하는 소스가 여러군데 존재하기도 하더라구요~
그러한 경우를 막기 위해서 재사용하기 쉽게 만들어야 합니다.
팀 프로젝트에서 소스 코드의 중복이야말로 추후 문제 해결을 어렵게 만드는 원인이 되기도 하니까요~

참고로 스마트플레이스에 올라온 소프트웨어 개발자를 위한 컴포넌트 판매 사이트 글을 보니,
예전에 많이 보던 컴포넌트 판매 사이트들이 나오더군요..

component source.. 오랜만에 들어보는 이름이네요. ^^
공개된 소스로는 코드그루코드프로젝트 등이 유명했었죠..

크리에이티브 커먼즈 라이선스
Creative Commons License




Trackback 0 And Comment 0

소스코드 버전관리를 활용하라.

|


프로젝트의 규모가 점점 커지면서, 소스코드의 버전관리가 중요한 요소로 자리잡아 가고 있습니다.

혼자서 단독으로 프로그래밍을 하던 시기에는 백업 파일만 잘 보관하면 됐지.. 버전관리가 왜 필요할까? 하고 생각했던 것이 사실입니다.
하지만, 협업을 하게 되면서.. 단순히 백업만 가지고서는 발생할 수 있는 문제점들을 해결하는데 어려움이 있게 됩니다.

소스코드를 누가 변경한 것인가?
현재 소스와 이전 소스의 차이점은 무엇인가?
현재 소스를 릴리스(release)에 어떻게 반영할 것인가?
동시에 동일 파일에 대한 변경이 발생할 경우, 충돌을 어떻게 해결할 것인가?

단순한 백업에서는 해결하지 못했던 것을 소스코드 버전관리를 통해서 처리할 수 있게 되는 것입니다.

그래서 어떤 프로젝트를 막론하고.. 심지어 프로토타입이라 할지라도 소스코드 관리를 활용하는 것이 바람직하다고 생각합니다.

이런 소스코드 버전관리 프로그램으로는 CVS, Subversion, SourceSafe 등이 있습니다.
제 경우에는 CVS를 주로 사용하고 있는데요.. VC++ 프로젝트의 경우에는 SourceSafe를 사용하기도 합니다.

기본적인 소스코드 버전관리 프로그램의 특성들은 비슷하니..
한가지를 기본적으로 잘 익혀 두시면 다른 것들도 파악하는데 어려움은 없지 않을까 생각합니다.
(CVS와 Subversion의 차이 설명 : http://www.word.pe.kr/bbs/view.php?id=term&no=5)

추가적으로 CVS와 함께 ANT와 같은 툴도 병행해서 사용하기도 합니다.
기본적으로 주어진 툴을 잘 활용해서.. 노가다하는 시간을 줄이는 것도 훌륭한 프로젝트 관리의 하나가 아닐까 합니다.

CVS에 대한 설명은 다음 사이트를 참고하시기 바랍니다.

CVS를 이용한 프로젝트관리 : http://joinc.co.kr/modules.php?name=News&file=article&sid=60
CVS 이야기 : http://kldp.org/KoreanDoc/html/CVS-KLDP/index.html
CVS 사용 : http://kldp.org/KoreanDoc/html/CVS_Tutorial-KLDP/


크리에이티브 커먼즈 라이선스
Creative Commons License




Trackback 0 And Comment 2

프로토타입을 통해 학습하라.

|


실제로 프로젝트를 진행할 때, 프로토타입을 만든다는 이야기를 많이 합니다.
이런 프로토타입(prototype)의 사전적인 의미를 살펴보도록 하죠.

prototype  [출처 : 네이버영어사전]
━ n.
1 원형(原型)(archetype);견본, 전형;(후대 사물의) 선조, 원조(元祖)
   the prototype of a character (소설에서) 인물의 원형
2【생물】 원형(原形)
━ vt. …의 원형[견본]을 만들다

원형이나 견본이라는 의미로 주로 사용되고 있는데요..
프로그래밍에서는 언제 프로토타입(원형, 견본)을 만들어야 할까요?
당연히 이미 해봤던 것이나, 전체적인 로직과 흐름을 잘 알고 있으며, 구현이 가능한 것에 대해서는 프로토타입이 필요 없을 것입니다.
처음 시도해 보는, 이 기능이 구현될지 안될지.. 의심스러운 부분에 대해서 프로토타이핑을 해야 하지 않을까 합니다.

실용주의프로그래머란 책에서 다음과 같이 이야기 하고 있습니다.

프로토타이핑은 배움의 경험이다. 프로토타이핑의 가치는 만들어낸 코드에 있지 않고,
여러분이 배운 교훈에 있다.

몇몇 고객들이 잘못 이해하고 있는 것 중의 하나가
프로토타입이 완성되면 기능 구현이 완료되었다고 생각하는 경향이 있습니다.
물론 프로토타입이 제대로 만들어졌다면, 실제 구현에 있어서 개발속도나 기술구현에 큰 어려움은 없을 것입니다.

하지만, 위에서 이야기 했듯이 프로토타입의 가치는 학습에 있으므로…
프로토타입의 완료가 해당 기능의 완성이라고 보기에는 무리가 있다는 것이죠.
고객들에게 프로토타입에서 만들어진 코드는 폐기할 것이고, 불완전하며 완성할 수 없다는 사실을 분명히 주지시켜야 합니다.

또한 프로토타입에서 가장 중요한 요소는 바로 스피드라고 생각합니다.
물론 프로젝트 규모에 따라 다르겠지만 너무 오래 걸리는 프로토타입은 좀 생각해 봐야겠죠~~
최대한 빠르게 구현하고, 실제 필요한 기능들을 습득하는 것이 프로토타입이라고 생각합니다.

어쨌든 개발자에게 있어 프로토타입이라는 것은 매우 중요합니다.
실제 구현할 기능을 테스트해 보기도 하고~
새로운 기술을 배울 수 있으며..
향후 보다 안정된 프로젝트 진행을 할 수 있기 때문입니다.

다음은 프로토타입을 만들 때 무시해도 좋은 세부사항이라고 합니다.

Correctness : 적절한 Dummy Data의 사용
Completeness : 제한된 기능만을 사용
Robustness : 불완전할 수 있음
Style : 코드에 주석등이 필요하지 않음 (그러나 학습한 내용을 따로 문서화 하는 것은 의미가 있다고 봅니다.)

윗 부분에서는 개발과 관련된 부분의 프로토타입에 대해 이야기 했습니다만,
좀 더 내공을 키워 아키텍처 프로토타입까지 나아간다면
어떤 프로젝트의 진행에 있어서도 자신감을 가질 수 있지 않을까 생각합니다.

 

크리에이티브 커먼즈 라이선스
Creative Commons License




Trackback 0 And Comment 0

실패를 축하하라

|


상품디자이너인 데이비드 켈리는

“성공과 실패는 동등하게 보상받을 가치가 있다. 하지만 아무 것도 하지 않는 다면 벌을 줘야 한다”

고 이야기 했습니다.

실제 프로젝트를 진행할 때 일입니다.
모 프로그램에 플러그인을 개발해야 할 필요가 있었는데..
처음에 AJAX (DWR) 을 이용해서 처리했습니다.  
하지만, 원격에서 호출이 안되자. dwr 문제일까? 하고 prototype으로 바꾸어서 테스트 해 보았지만,
역시 문제가 발생했습니다.

Javascript는 보안상의 이유로 cross-domain을 지원하지 않기 때문이었습니다.

그래서 이런 경우에 사용할 수 있는 이기종간의 통신을 위한 웹서비스를 사용하자고 제안했습니다.
웹서비스를 이용하여 프로그램을 구성하고 테스트를 마치고 보니..
이런 웹서비스 내에서 우리 프로그램을 호출해야 하는 부분이 또 걸렸습니다.
외부에서 웹서비스를 호출하는데는 전혀 문제가 없었는데요..

이에 옆에 있던 고수 한분이 걍.. URLConnection이나 fopen등을 이용해서 처리하는게 어떠냐는 의견을 제시하고
그걸 통해 드디어 플러그인을 완성하게 되었습니다.

앞에서 Ajax나 웹서비스를 통한 실패가 없었다면, 마지막의 완성도 없지 않았을까 합니다.
또한 이 부분을 담당한 개발자도 다양한 프로그래밍을 통해 한 발 더 나아가는 계기가 되지 않았을까 합니다.

WOW 프로젝트로 유명한 톰 피터스는 다음과 같이 이야기 했습니다.

만약에 신속한 프로토타입이 중요하다는 것을 알고 있다면…
신속한 실패 또한 당연히 (필요하고) 중요하다.
물론 신속한 승리가 가장 좋지만, 신속한 실패는… 신속한 승리를 위한 필요한 노력이다.
신속한 수행은 신속한 실패를 낳는다. 이것은 당연히 신속한 조정을 낳는다. 그리고 이것은 당연히 신속한 성공을 낳는다.
이것이 바로 핵심이다!
그리고 대부분(98%?)의 대기업에는 없는 요소이기도 하다.

음.. 다행히 우리에게는 실패를 두려워하지 않음으로써 빠른 실패, 빠른 성공을 할 수 있는 요소를 가진 것이 아닐까 하네요~

 

크리에이티브 커먼즈 라이선스
Creative Commons License




Trackback 0 And Comment 0

깨진 창문을 내버려 두지 말라

|


 깨진 창문 이론(Broken Window Theory)이라는 말이 있습니다.
'티핑 포인트'라는 책과 '실용주의 프로그래머'라는 책에서 인용되고 있는데요..

요약하면,

오랜기간 수리하지 않고 방치된 창문 하나가 거주자들에게 버려진 느낌을 준다는 겁니다.
그래서 다른 창문이 하나 더 깨지고.. 낙서가 등장하고.. 심각한 구조적 손상이 시작되는 것이죠..
결국 건물 소유주가 고치려는 의지를 넘어설 정도로 건물이 손상되고, 버려진 느낌은 현실이 되어 버린다는 겁니다.

보다 자세한 내용은 다음 블로그들을 참고하시기 바랍니다.

http://www.nanael.net/48
http://blog.naver.com/chowyf?Redirect=Log&logNo=80034681435

'실용주의 프로그래머' 책에서는 실생활 뿐만 아니라 IT 프로젝트에서도 깨진 창문을 조심하라고 말하고 있습니다.
나쁜 설계, 잘못된 결정, 좋지 않은 코드를 눈에 뜨일 때마다 고치라는 것이죠~

흔히 프로젝트 초반에는 DB도 조금 변경하고, 로직도 변경하고.. 개발을 진행합니다.
하지만 어느정도 프로젝트가 진행이 되고 나면.. 고객의 요구사항이나 프로그램 구성상 변경이 발생할 때..
전체를 고치기 보다는 그 부분만 땜빵하듯이 고쳐나가는 경우가 있습니다.
DB를 수정하게 되면 너무 많은 부분을 손대야 하니 어쩔 수 없다고 말하면서~~
하지만, 점점 더 많은 변경을 적용하면서... 소스 코드는 더욱 지저분해지고.. DB도 누더기다 되어버리게 됩니다.

솔직히 지금까지는 이런 경우, 변명을 많이 했었습니다.
"고객이 생각지도 못한 요구사항을 추가한 것이다."
"초기에는 논의 되지 않았던 부분이다."
"데이터베이스를 변경할 수는 없으니 이런식의 꼼수 코딩은 정당하다."
하지만 최종적으로 유지보수도 어려운... 쉬레기 코드가 만들어지는 것이죠~

그렇다면, 실제 프로젝트에서 깨진 창문을 내버려 두지 않으려면 어떻게 해야 할까요?
일단, 프로젝트 팀원들의 마음가짐이 중요할 것 같습니다.
내가 먼저 창문을 깨어서는 안된다~ 는 각오가 필요할 것 같네요~

그리고 가장 중요한 것은 PM 혹은 PL의 역할이 아닐까 합니다.
외부의 변수에 의해 수정이 필요할 때, 전체적인 관점에서 고칠 것을 빠르게 결정하고 진행하는 것이 필요하지 않을까 합니다.
누군가 끊임없이 프로젝트를 관찰하고 있다면, 창문 하나가 깨지더라도 바로 복구할 수 있을 테니까요..
그러기 위해서는 소스코드에 대한 관리, 테스트에 대한 관리, 설계나 기획안에 대한 관리가 PM/PL에게 일정관리 이상으로 중요한 부분이 아닐까 합니다.
깨어진 소스.. 깨어진 설계를 찾아내야 하니까요~~

크리에이티브 커먼즈 라이선스
Creative Commons License




Trackback 0 And Comment 0
prev | 1 | next