Software Engineering2007.04.25 22:56

Learn from all experiences

모든 경험으로부터 배운다.


"결정적인 국면에 처했을때 임무를 수행하는 능력은 당신이 그것을 할 수 있다는 자신감에서 나온다. 그 자신감은 어디서 나올까? 과거에 그것을 해보았기 때문이다. 물론, 일단은 처음 그것을 시도해 보아야 하겠지만 그 다음부터는 항상 되돌아 볼 수 있는 귀감이 생기는 것이다. 전에 해보았던 것을 할 때는 마음이 편안해진다.

자신감과 자부심이 관건이다. 자신감은 전에 해보았던 일이라는 생각에서 우러나온다. 연습도, 훈련도, 그 무엇도 하고 싶지 않았던 때가 있었지만 내가 다시 마음을 잡은 것은 누군가가 나를 따라잡는 것을 원치 않았기 때문이다. 바로 그런 이유로, 마지막 2분을 남겨놓고 경기가 초긴장의 상황으로 접어들 때는 내가 어떤 다른 선수들보다 유리하다고 느낀다."

마이클 조던이 ESPN에 기고한 글의 일부이다. 출처는 여기


위의 글에서도 알 수 있듯이 전에 무언가를 성공했다는 경험은 아주 큰 자산이다. 그 경험을 통해서 자신감을 얻을 수도 있고, 또한 그와 비슷한 것을 할 때에 아주 유용하게 그 지식을 써먹을 수가 있다. 이런 자신감과 지식들은 프로젝트 성공에 큰 도움을 줄 수가 있다.

프로젝트 레벨이나 기업 레벨에서는 많은 구성원들이 있기 때문에, 한 사람의 성공적인 경험이 다른 구성원들에게 전달될 수 있게 하는 것이 중요하다. 그러므로 지식 관리 시스템, 위키, 버그 관리 시스템 등의 구축을 통해서 많은 지식과 경험을 축적시킬 수 있는 시스템을 만드는 것은 프로젝트의 성공에 아주 도움이 될 것이다.


다른 원칙 보기

Foster open Communications (열린 커뮤니케이션을 장려한다)

Work toward a shared vision (비전을 공유하고, 그 비전을 목표로 작업한다)
Empower Team Members (팀 멤버들에게 많은 권한을 위임한다)
Establish clear accountability and shared responsibility (팀,개인의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다)
Focus on delivering business value(비즈니스 가치에 초점을 맞춰야 한다)
Stay agile, expect change (언제나 유연하게 변화에 대응할수 있도록 한다)
Invest in Quality (품질에 투자한다)
Learn From all Experiences(모든 경험으로부터 배운다)

Posted by kkongchi
Software Engineering2007.04.25 22:44
Invest in quality

품질에 투자한다.


Whitepaper에도 언급하고 있지만, 절대적으로 완벽한 품질이란 있을 수가 없다. 품질이란 계속해서 쌓아가는 것, 발전해 나가는 것이다. 그러므로, 품질은 프로젝트의 모든 과정에서 고려되어야 한다. 즉, 일단 돌아가게 만든 다음에, 품질을 높인다..라는 어프로치는 안 된다.


MSF에서는 퀄리티 추구를 위해서 두 가지 - 테스팅 팀을 중시하는 팀 모델, 개발자들의 Readiness 관리를 위한 교육 모델 - 를 제안한다. 말은 쉽지만 이 두가지가 모두 잘 되는 프로젝트는 현실적으로 찾기 힘들다. 여러 가지 이유 - 예산의 문제, 일정의 문제 등등 - 로 인해서 소홀해지기 쉬운 부분이기 때문이다. 하지만 결국 이런 부분을 소홀히 했을 때, 결과적으로 퀄리티는 당연히 떨어지기 마련이다.



다른 원칙 보기

Foster open Communications (열린 커뮤니케이션을 장려한다)

Work toward a shared vision (비전을 공유하고, 그 비전을 목표로 작업한다)
Empower Team Members (팀 멤버들에게 많은 권한을 위임한다)
Establish clear accountability and shared responsibility (팀,개인의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다)
Focus on delivering business value(비즈니스 가치에 초점을 맞춰야 한다)
Stay agile, expect change (언제나 유연하게 변화에 대응할수 있도록 한다)
Invest in Quality (품질에 투자한다)
Learn From all Experiences(모든 경험으로부터 배운다)
Posted by kkongchi
Software Engineering2007.04.01 19:14

Stay agile, expect change

언제나 유연하게 변화에 대응할있도록 한다.



UML의 창시자 중 한명인 Grady Booch는 그의 저서 "The Unified Software Development Process"에서 이렇게 말하기도 했다.
"It is one of the constants of software development that the requirements change."
"요구사항의 변화는 소프트웨어 개발에서 상수(Constants)중의 하나이다"

그래서 Grady Booch 등이 만든 Rational Unified Process 방법론에서는 Iterative(반복적)이고 Cumulative(점진적)인 개발 방법론을 제시하고 있다. 나도 여러 프로젝트에서 몇 단계의 Iteration으로 프로젝트를 나누는 형태로 진행해본 적이 있었다. 그리고 최근의 XP, Agile 방법론 등에서 매우 중요시하는 것도 이 "Agile"이기도 하다.

내가 몸담고 있는 우리 나라 SI에서는 이런 유연성이 상당히 부족하다. 변화를 아예 받아들이지 못하는 것은 아니지만, 그 변화를 주기 위해서 많은 사람들이 고생을 하게 된다..-_-;; 즉, 변화를 잘 받아들이지 못하는 구조로 일정이나 예산 등이 처음에 책정되기 때문인데, 이런 현상 자체가 이미 이 원칙에 대한 의식이 많이 결여되었다는 것을 보여준다. 문제는 이 때문에 퀄리티가 떨어진다는 것이다.

언제나 변화에 빠르게 대응할 수 있는 환경(시간, 예산 상의 버퍼)을 만들어 놓는 것은 그래서 너무나 중요하다. 그것이 먼저이고, 그 후에는 변화에 대응할 수 있는 팀 구조, 방법론(Iteration이나 XP 등)의 적용을 하자.




다른 원칙 보기

Foster open Communications (열린 커뮤니케이션을 장려한다)

Work toward a shared vision (비전을 공유하고, 그 비전을 목표로 작업한다)
Empower Team Members (팀 멤버들에게 많은 권한을 위임한다)
Establish clear accountability and shared responsibility (팀,개인의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다)
Focus on delivering business value(비즈니스 가치에 초점을 맞춰야 한다)
Stay agile, expect change (언제나 유연하게 변화에 대응할수 있도록 한다)
Invest in Quality (품질에 투자한다)
Learn From all Experiences(모든 경험으로부터 배운다)

Posted by kkongchi
Software Engineering2007.04.01 11:59

Focus on delivering business value

비즈니스 가치에 초점을 맞춰야 한다.


사실 내가 그동안 해왔던 Enterprise SI에서는 이 부분이 부족하다고 말할 수 있다. 고객이 원하는 소프트웨어를 거기에서 만들어주는 일이 대부분이기 때문에, 당연히 일을 하는 만큼 어느 정도 돈은 나올테니까.


하지만, 솔루션을 만들어서 시장에 내놓는 일을 하는 업체, 혹은 최근에 많은 웹기반의 일반 사용자용 소프트웨어(웹 2.0이라고 해야 하나?)를 만드는 업체라면 이 부분은 아주 중요하다. 즉, 시장에서 팔릴 수 있는 것, 고객이 돈을 내고 살만한 것을 만들어야 할 것이다. 이런 비즈니스적인 결과가 따라오지 못한다면 개발자나 기획자 등의 동기부여도 잘 안 될 것이고, 틀림없이 결과도 좋지 못할 것이다.


다른 원칙 보기

Foster open Communications (열린 커뮤니케이션을 장려한다)

Work toward a shared vision (비전을 공유하고, 그 비전을 목표로 작업한다)
Empower Team Members (팀 멤버들에게 많은 권한을 위임한다)
Establish clear accountability and shared responsibility (팀,개인의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다)
Focus on delivering business value(비즈니스 가치에 초점을 맞춰야 한다)
Stay agile, expect change (언제나 유연하게 변화에 대응할수 있도록 한다)
Invest in Quality (품질에 투자한다)
Learn From all Experiences(모든 경험으로부터 배운다)
Posted by kkongchi
Software Engineering2007.03.04 22:08

Establish clear accountability and shared responsibility

팀(개인)의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다.



이 원칙을 지키지 못했을 경우에 가장 문제가 될 수 있는 것은 MSF White Paper에서도 지적하고 있듯이, 작업의 중복으로 인한 과잉 작업 혹은 작업의 실종(?)으로 인해서 발생되는 누락등이다. 이건 결과적으로 프로젝트에 매우 큰 해를 끼칠 수 있고, 프로젝트의 실패로 이어지기도 한다.

팀 혹은 개인의 의무를 분명히 하는 것은 사실 어렵지 않다. 처음에 세심하게 준비하고 문서화함으로써 각 팀 혹은 개인이 그 프로젝트에서 갖는 의무를 분명하게 만들 수 있다.


문제는 2번째이다. 전체적인 책임은 모든 팀/개인이 공유해야 한다는 것. 만약에 어떤 팀 혹은 개인이 자신의 의무를 다 하지 못하고. 실패를 한다면 그 것을 누군가는 메꿔야 한다. 그랬을때, 사실 팀 또는 개인이 자신의 일이 아니라는 이유로 방관할 수도 있고 혹은 자신의 일 이외 부분에 대한 이해가 부족해서 그런 작업을 잘 하지 못할 수도 있는 것이다. 즉 프로젝트에 속한 모든 팀/개인이 전체적인 그림에 대해서 이해하고 전체적인 책임을 공유할 수 있어야 이런 작업에 대해서 실패하지 않을 수 있다. 책임을 모두 공유해야 한다는 것은 바로 그런 의미이다.


다른 원칙 보기

Foster open Communications (열린 커뮤니케이션을 장려한다)

Work toward a shared vision (비전을 공유하고, 그 비전을 목표로 작업한다)
Empower Team Members (팀 멤버들에게 많은 권한을 위임한다)
Establish clear accountability and shared responsibility (팀,개인의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다)
Focus on delivering business value(비즈니스 가치에 초점을 맞춰야 한다)
Stay agile, expect change (언제나 유연하게 변화에 대응할수 있도록 한다)
Invest in Quality (품질에 투자한다)
Learn From all Experiences(모든 경험으로부터 배운다)
Posted by kkongchi
Software Engineering2007.02.09 15:18
현재 일하고 있는 회사에서는 버그 관리 시스템으로 Bugzilla를 사용하고 있다. 개발팀에서 빌드가 이루어진 제품을 QA팀이 가져가서 테스트를 하게 되고, 테스트 중에 발견된 버그들이 이 Bugzilla에 등록되게 된다. 그리고 개발자들은 등록된 버그를 해결하고 다시 그것을 QA팀에 통보를 한다. 이런 과정들을 반복하면서 버그가 줄어들고 또 제품의 Quality가 높아지게 되는 것이다.

나는 지금까지 3개의 버그 관리 시스템을 사용했다. 처음 써 본것은 Microsoft의 RAID이다. 이 제품은 상용 제품은 아니고, Microsoft에서 내부적으로 사용하는 것인데, Microsoft 컨설턴트 분들과 프로젝트를 진행할 때에 이것을 2번 정도 사용을 했었다. 그리고 얼마전까지 속했던 프로젝트에서는 Microsoft Visual Studio 2005 Team System에 포함되어 있는 버그 관리 시스템을 사용을 했다. 그리고 지금은 Bugzilla까지..

이 3개의 시스템은 사실 아주 비슷한 구조를 가지고 있다. 버그를 등록하고 상태를 변경하고(상태에는 Open, Resolved, Fixed, Re-open 등등이 있고) 그리고 메일 등으로 alert을 제공하고 등등.. 그래서 사실 어떤 버그 관리 시스템을 쓰더라도 특별한 차이가 있는 것은 아니다.

중요한 것은 어떻게 쓰느냐이다. 버그 관리 시스템을 그냥 버그 리스트로만 봐서는 안 된다고 생각한다. 버그 관리 시스템은 버그의 관리 뿐 아니라. 버그와 그에 연관된 많은 정보들이 모두 모아져야 한다. 그러기 위해서 내가 생각하는 몇 가지 원칙을 좀 제안해 보고자 한다.

1. 자신의 코드에서 버그를 찾아서 수정했을 때에도, 버그로 기록하자.

버그의 갯수는 물론 개발자를 평가하는 기준이 될 수도 있다. 그래서 대부분 테스트 팀에 넘어가기 전에 자기가 발견하고 수정해 버린 버그에 대해서 버그 관리 시스템에 등록을 하지 않는 경우가 대부분이다. 하지만 나는 그것들도 기록해두는 것이 좋다고 생각한다. 어떤 버그 혹은 이슈는 두고두고 개발자를 괴롭히는 경우가 많다. 그럴 때에 대부분 "그게 뭐였지.." 하면서 기억을 뒤지게 되는데, 버그 관리 시스템에 등록되어 있다면 더 쉽게 찾을 수가 있다.

그리고 하나의 버그를 찾아서 그것을 기록하고 정리하는 과정에서, 그 버그에 대해서 완전하게 이해할 수가 있다. 그러면 자신의 코딩 습관에서 버그를 유발시키는 코드에 대해서 더 잘 이해할 수 있을 것이고 그럼으로써 더 좋은 코드를 작성할 수 있게 될 것이다. 그리고 처음에 말했던, 자신의 버그 숫자가 늘어나는 문제 때문에 등록을 망설인다면, 더 좋은 코드를 작성할 수 있기 때문에 가면 갈수록 버그 숫자는 줄어들게 될 것이다.

2. 버그를 기록할 때는, 재현에 필요한 모든 정보를 남겨야 한다.

이것은 사실 개발자보다는 테스트, 매니저 등에게 사실 하고 싶은 말이다. 우리는 버그 관리 시스템에서 자주 이런 아주 간단한 버그의 내용을 보게 된다. "OOO 기능 작동하지 않음", ""XXX 기능 에러 남" 등등.. 그런데 개발자들에겐 이런 정도의 말은 사실 이해하기에 너무나 부족한 말이다. 틀림없이 테스트해서 내보낸 것인데, 어떤 상황에서 에러가 나는 것인지, 무슨 짓을 하다가 발생한 에러인지 확실히 알 수가 있어야 한다. 이런 식으로 커뮤니케이션하다가 서로간에 사이가 안 좋아지기도 한다..^^;;

버그를 해결하는 과정의 첫 걸음은 바로 "재현(Reproduction)"이다. 즉 다른 사람이 발견한 버그를 개발자가 재현해보고, 그것을 해결할 실마리를 얻을 수가 있는 것이다. 그런데 이 재현을 하기 위해서는 상세한 정보가 필요하다. 버그가 발견된 머신의 소프트웨어 상황이라던지(어떤 브라우저, 어떤 OS 등등) 어떤 오퍼레이션을 어떻게했는지 등의 상세한 정보가 있어야 바로 그 버그를 재현할 수가 있다. 이런 정보가 없이는 버그를 재현하기가 힘들다. (아예 잘 되지 않는 경우도 있다. 실제로 소프트웨어 사용 습관이 사람마다 매우 다른데, 그래서 개발자는 자신의 사용습관만을 테스트해서 버그를 찾지 못했지만, 테스터는 사용 습관에 따라서 버그를 찾을 수도 있기 때문이다. 이 경우, 개발자는 이런 사용습관에 대한 정보가 없이는 버그를 재현해내기가 매우 힘들다)

재현에 필요한 모든 정보를 남겨야, 개발자가 재현하는 데 드는 시간도 줄어들 수 있고, 개발자와 테스터 간의 커뮤니케이션(혹은 말다툼) 시간도 줄일 수가 있고 결과적으로 많은 시간을 절약할 수가 있다. 그 시간에 버그를 더 수정할 수도 있을 것이고, 전체적인 퀄리티를 더 높일 수도 있으며 혹은 뭔가 다른 일을 하면서 개인적인 성취를 이루거나, 사회에 공헌을 할 수도 있을 것이다. ^^;;

3. 개발자는 버그에 대해서 되도록 자세한 정보를 Comment로 남기는 것이 좋다.

개발자들도 버그를 수정한 다음에 Comment를 자세하게 남겨야 한다. "버그 맞습니다. 고치겠습니다", "버그 수정되었습니다", "버그 아닙니다" 이 정도의 커멘트로는 역시 대화가 되지도 않고, 이후에도 아무런 도움이 되지 않는다.

재현이 안 되었다면 자신이 재현을 한 과정과 환경을 써야 하고, 재현이 되었고 실마리를 찾았다면 그 실마리를 적어야 한다. 수정을 했다면 어떤 모듈을 어떤 식으로 고쳤는지 기록해야 한다. 물론 이것이 개발자만 보는 시스템이 아니기 때문에, 자세한 기술적 내용을 쓸 필요가 없기도 하고 그렇게 쓰지 말라는 말을 들을 지도 모르겠다. 하지만 그런 부분은 그 사람들이 가려서 읽으면 된다.

기술적인 내용 등을 자세하게 쓴다면, 개발자는 이 버그 관리 시스템을 일종의 KnowledgeBase로 활용할 수가 있다. 그리고 개인적으로뿐만 아니라, 전체적으로도 이런 자세한 내용은 분명히 도움이 될 것이다. 비슷한 증상이나 버그 혹은 기술적인 문제 때문에 다른 개발자가 지금 고생하고 있을 수도 있다. 그런 사람들에게 장황하게 설명하기보다는 Bug No XXX를 참조하세요라고 말할 수가 있다.. 훨씬 편리한 것이다.

4. 버그로 인해서 소스 코드가 수정되었다면, 그 수정된 부분에 등록된 버그ID등을 주석으로 남겨서 연결고리가 될 수 있도록 해야 한다.

버그를 해결하기 위해서 소스 코드를 수정하게 될 것이다. 아마 대부분 수정하면서 그 내용을 주석으로 남길 것인데, 거기에 버그 번호를 붙이는 것이 좋다. 나중에 "이 버그는 어떻게 해결하셨어요?" 라고 누군가 물어볼 때, "아..기억이 안나..ㅜ.ㅜ" 보다는, 에디터를 열고 버그 번호로 찾으면 쉽게 찾아서 잘난 체 할 수가 있다.

Visual Studio Team System처럼 소스 제어와 버그를 링크할 수 있다면, 더 쉽게 찾을 수가 있다. 이런 기능은 적극적으로 활용해야 한다. 물론 귀찮다. 나도 VS2005 Team System 사용했을 때 이 기능은 전혀 사용하지 않았다. 하지만 나중에는 좀 후회를 했다. 나중에 버그나 Work Item과 관련된 소스 혹은 코드 일부를 찾는 일은 정말 힘들다. 코딩한지 3달 이상된 코드에 대해서는 거의 못 찾는다고 해도 과언이 아니다. 미리미리 준비를 해두는 것이 좋다.

이상, 버그 관리 시스템을 잘 쓰기 위한 생각들을 좀 정리를 해 보았다. 처음에는 귀찮고 개발할 시간을 뺐는 것처럼 보여도 결국에는 도움이 되는 것이 바로 버그 관리 시스템이라는 생각이 든다. 기왕 쓰는 것이라면 최선의 활용방법을 찾는 것이 더 좋을 것이다.

* 더 좋은 아이디어나 노하우가 있다면 댓글이나 트랙백으로 한 마디씩 해주셨으면 합니다..
Posted by kkongchi
Software Engineering2007.01.28 21:29

Empower team members

멤버들에게 많은 권한을 위임한다.


이 항목에 대해서 MSF White Paper는 다음과 같은 구절을 인용한다.


“On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader, because that person would then cease to be a peer and the team interaction would begin to break down. The structure of a team is a network, not a hierarchy."

"최고의 팀에서는 각각 다른 개인이 각자의 전문 분야에 대해서 리더십을 그때마다 제공한다. 누구도 계속해서 리더가 될 수없는데, 항구적인 리더는 동등한 관계의 팀 상호작용을 파괴시키기 때문이다. 팀의 구조는 계층 구조가 아니라 네트워크이다."


Tom DeMarco and Timothy Lister "피플 웨어"



다분히 이상적인 말이지만, 지향해야 할 길이라는 건 분명하다. 소프트웨어 개발 프로젝트가 아닌 모든 분야에 적용할 수 있는 말이기도 하다. 어떤 분야에서건 모든 것을 다 알고 있는 사람이란 있을 수가 없기에, 동등한 자격의 팀 구조에서 어떤 이슈에 대한 최고의 전문가가 각 이슈에 대해서 팀을 이끈다면, 당연히 최고의 성능을 낼 수가 있을 것이다.

현재는 많은 곳에서 이런 시도가 있다. 사회의 전반적인 분위기도 많이 바뀌었을 뿐 아니라 이런 변화가 없는 기존 구조로는 많은 문제점이 나타나기 때문이다. 물론 가야 할 길이 많은 것이 아직도 우리 나라의 전체적인 분위기는 조금은 경직된 상명하복 식이기 때문일 것이다.

SI 프로젝트에 적용해서 말해보자면, 역시 PM 혹은 팀 리더의 노력이 요구가 된다. 결국 커뮤니케이션이 잘 되고, 팀 멤버들에 대해서 많은 것을 파악하고 있어야 이런 일들이 가능하기 때문이다. 손쉽게 편한 방법으로 가고자 한다면 이런 것들이 왜 필요하겠는가? 아무리 자그마한 이슈라고 하더라도, 최선의 방법을 찾으려는 노력이 있어야, 그리고 그러기 위해서 모든 팀 멤버들의 의견을 청취하는 노력이 있어야 할 것이다.


다른 원칙 보기

Foster open Communications (열린 커뮤니케이션을 장려한다)

Work toward a shared vision (비전을 공유하고, 그 비전을 목표로 작업한다)
Empower Team Members (팀 멤버들에게 많은 권한을 위임한다)
Establish clear accountability and shared responsibility (팀,개인의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다)
Focus on delivering business value(비즈니스 가치에 초점을 맞춰야 한다)
Stay agile, expect change (언제나 유연하게 변화에 대응할수 있도록 한다)
Invest in Quality (품질에 투자한다)
Learn From all Experiences(모든 경험으로부터 배운다)
Posted by kkongchi
Software Engineering2006.05.23 22:23

Work toward a shared vision
비전을 공유하고, 그 비전을 목표로 작업한다.

프로젝트에는 명확한 비전 혹은 목표가 있어야 한다. 그 비전은 복잡해서도 안 되고, 애매해서도 안 된다. 이를테면, "이번 프로젝트를 통해서 3달안에 우리의 전자결재 솔루션 제품에 오피스 지원 기능을 추가함으로써 경쟁 제품에 대한 우위를 점하고 업계 No.3로 올라선다" 정도의 간단하면서도 프로젝트를 통해서 달성할 비즈니스 가치, 그 비즈니스 가치를 달성하기 위한 제품의 목표 등을 완전히 기술하는 형태가 되어야 한다. 그리고 그 달성해야 할 비즈니스 가치는 엄격한 조사와 많은 토론을 통해서 제련된 아주 현실성 있는 목표여야 한다.

목표가 명확해야 길을 잃지 않는다. 목표가 명확해야 다른 길로 잘못 들어서지 않는다. 목표가 명확해야 팀원들이 힘을 잃지 않는다. 현재 No.4인데 무조건 No.1로 올라서자 등의 현실성 없는 목표나 최고의 전자결재 솔루션을 만든다 등의 애매한 목표를 가지고 일을 하게 되면, 끝도 보이질 않고 중간에 헤매게 되고 그러다 보면 팀원들의 힘은 빠지는 최악의 상황으로 흘러 갈 수 있다. 명확하고 현실성 있는 목표를 설정해야, 그 목표를 이룰 수 있다. 그리고 결국 프로젝트의 성패를 가루는 기준은 프로젝트가 목표한 바를 이루었느냐이다.



다른 원칙 보기

Foster open Communications (열린 커뮤니케이션을 장려한다)

Work toward a shared vision (비전을 공유하고, 그 비전을 목표로 작업한다)
Empower Team Members (팀 멤버들에게 많은 권한을 위임한다)
Establish clear accountability and shared responsibility (팀,개인의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다)
Focus on delivering business value(비즈니스 가치에 초점을 맞춰야 한다)
Stay agile, expect change (언제나 유연하게 변화에 대응할수 있도록 한다)
Invest in Quality (품질에 투자한다)
Learn From all Experiences(모든 경험으로부터 배운다)

Posted by kkongchi
Software Engineering2006.04.08 23:21

Foster open communications

열린커뮤니케이션을장려한다.


당연한 말일지도 모른다. 하지만 커뮤니케이션이 잘못되어서, 프로젝트가 위기에 빠지는 경우를 우리는 너무나 흔하게 본다. 실제로 많은 소규모 프로젝트들이 담당자들간의 간단한 대화에만 커뮤니케이션을 의존한다. 그런 경우, 마치 가족오락관의 어떤 게임처럼 한군데서 커뮤니케이션의 미스가 생기면 그게 눈덩이처럼 불어나면서, 돌이킬 수 없는 큰 문제로 발전하게 된다. 그리고 서로 책임 떠넘기기에 바빠진다.


위에서 언급한 사례들이 바로 닫힌 커뮤니케이션이다. 즉, 커뮤니케이션 자체는 이뤄졌지만 그 커뮤니케이션의 결과물들은 아무데도 없다. 단지 참여한 사람들의 기억 속에만 있다. 폐쇄적이고 닫혀 있어서 다른 사람들은 아무도 알 수가 없다. 열린 커뮤니케이션은 이런 것을 지양한다. 모든 커뮤니케이션은 기록되고 공개되어 있어서, 적절한 권한이 있다면 누구나 볼 수 있다. 그래서 현재 프로젝트의 상황을 투명하게 볼 수가 있다. 적어도 오른손이 하는 일을 왼손이 몰라서 문제가 생기지는 않는 것이다.



다른 원칙 보기

Foster open Communications (열린 커뮤니케이션을 장려한다)

Work toward a shared vision (비전을 공유하고, 그 비전을 목표로 작업한다)
Empower Team Members (팀 멤버들에게 많은 권한을 위임한다)
Establish clear accountability and shared responsibility (팀,개인의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다)
Focus on delivering business value(비즈니스 가치에 초점을 맞춰야 한다)
Stay agile, expect change (언제나 유연하게 변화에 대응할수 있도록 한다)
Invest in Quality (품질에 투자한다)
Learn From all Experiences(모든 경험으로부터 배운다)

Posted by kkongchi
Software Engineering2006.04.08 23:19
 

MSF(Microsoft Solutions Framework) Microsoft에서 제안하는 Software 개발방법론이다. 실제로 Microsoft에서 동안 많은 소프트웨어를 개발하면서 겪어왔던 여러 교훈들이 녹아있는 훌륭한 방법론이다. (물론 제대로 적용되었을 얘기이다.) MSF다음 8가지를 기본 원칙으로 삼는다.


(* 이름을 클릭하면 각 원칙에 대해서 내가 코멘트한 포스트로 링크된다)

Foster open communications

열린 커뮤니케이션을 장려한다.


Work toward a shared vision

비전을 공유하고, 비전을 목표로 작업한다.


Empower team members

멤버들에게 많은 권한을 부여한다.


Establish clear accountability and shared responsibility

(개인)의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다.


Focus on delivering business value

비즈니스 가치에 초점을 맞춰야 한다.


Stay agile, expect change

언제나 유연하게 변화에 대응할있도록 한다.


Invest in quality

품질에 투자한다.


Learn from all experiences

모든 경험으로부터 배운다.

Posted by kkongchi

티스토리 툴바