Waterfall과 Agile? 현실은?

> 이미 Waterfall 방식은 너무 느리고 비용이 많이 들어서 대부분의 소프트웨어 프로제트에서는 사용하지 않습니다

via [Waterfall과 Agile :: All of Software](http://allofsoftware.net/entry/Waterfall)

정말일까? 현실적으로 대부분 Waterfall 방식을 사용할 듯한데.
왜냐하면? 대부분의 기업에서(인터넷이나 벤처는 잘 모르겠다) Project 를 관리하는 역할이나 그 관리자를 관리하는 사람이 저것밖에 모를텐데. Agile? Scrum? XP? 정말 들어본 적이나 있을까?

최소한 내 주변에 있는 백명이 넘는 개발자 중에 저 세가지 단어를 들어본 사람의 수는 손가락으로 꼽을 수 있다고 장담한다.

내가 우물한 개구리이거나(상당부분 그렇긴 하지만) 혹은 현실은 인터넷에서 떠드는 소프트웨어 공학과는 아직 거리가 있거나.

Scrum

Agile 방법론에서 가장 유명한 것은 XP이지만 그 외에는 Scrum도 있다.
Scrum은 MS에서 사용해서 유명한 듯하다. MS에서 나온 몇 권의 책도 있고,

이번에 Scrum 책 한권이 번역되어 나왔다. 아직 읽어보지는 못했지만 정진호 님의 글을 읽다가 손뼉을 치고 싶을 만큼 “맞아 맞아”를 외치게 한 문장 하나.

> 프로젝트의 일정이 점점 꼬이고 제어할 수 없는 상태에 빠지는 것은 숨어 있던 문제가 나중에 드러나기 때문입니다.

Scrum은 숨어있는 문제를 빨리 드러나게 해 준다고 하는데 도대체 어떻게 하길래 그럴 수 있을까? 궁금하다.

[Agile software with Scrum development](http://image.yes24.com/momo/TopCate66/MidCate07/6567075.jpg)

관련 포스트.
[(프로젝트 초기의) 때 이른 고통](http://younghoe.info/980)

[Agile] Assessing Test Driven Development at IBM

원문 : [Assessing Test Driven Development at IBM](collaboration.csc.ncsu.edu/laurie/Papers/MAXIMILIEN_WILLIAMS.PDF)

IBM에서 JavaPOS 과제에 대해 TDD를 적용한 사례 정리

#### 기존 과제에서의 Unit Testing
* 대부분의 경우 Unit testing은 개발이 이루어진 후에 일어남.
* 일정이 빠듯한 경우 생략됨

#### JavaPOS 과제에서는

* 생소한 방법론이나 생산성에 대한 우려를 해소하기 위해 일정 수립에 심여를 기울임.
* 개발자와 매니저의 반발
* 기존 과제를 분석하여 400 LOC/MM 를 목표로 설정함
* 생산성 factor
* Defect rate – defect rate in short term and long term
* roductivity – LOC/MM
* Test Frequency – ration of interactive vs. automated test? how often?
* Design – more robust design?
* integration – smoother code integration?
* XP에서는 전체 디자인을 하지 않고 코딩을 하지만, JavaPOS의 경우 요구사항이 비교적 유동적이지 않아 UML을 이용하여

####Big Design Up Front를 수행함.

* 중요 클래스에 대해 unit test를 강제화함.
* 중요 클래스에 대해 80%의 자동화된 unit test를 목표로 함.
* Build & Unit testing in Daily
* Unit test는 정상 경우, 예외처리(특히 boundary value)를 포함

###결과
* FVT(Functional Verification Test) 기준 기존 대비 50%의 defect rate를 보임.

* **TDD(w/ Unit testing)은 개발 초기에 도입해야 함**
* **핵심 항목에 대해서는 Unit Test 강제화도 고려할 필요가 있음**

소통의 문제는 여기에도

요즘 “소통의 부재”가 유행이다.

그런데 그 “소통의 부재”가 청와대와 국민 사이에만 있는 것은 아닐 것이다.

회사 내의 “소통의 부재”는 참 많은 생각을 하게 한다.

Agile에서 적극 추천하고 있는 “Stand-up meeting”을 시행하고 있다. 시작한 지 1년이 훨씬 넘은 듯하다.

하지만 한 번도 Agile에서 기대하고 있는 것처럼 적극적인 의사교환이나 정보 교환을 본 적이 없다.

늘 대장 노릇을 하는 사람이 주절주절 이야기를 하고, 나머지 사람들은 땅을 보거나 모니터를 보거나 가끔은 대장을 보거나.

피드백? 그런 거 별로 없다.

게다가 대장이 해주는 이야기는 대부분 진행 중인 과제의 “문제점”인 경우가 많아 듣기에 썩 좋은 이야기는 아니다. 타산지석으로 삼으면 좋겠지만 아쉽게도 전달하는 사람은 항상 “저런 저런 문제가 있었다. 우리는 이게 문제다”가 논지이기 때문에 과히 듣기 좋지는 않다. 맞는 이야기겠지만 비슷한 톤으로 비슷한 논지의 이야기를 주 5일 듣는다고 생각해 보자. 끔찍하지 않은가? 이건 마치 예전 5공때 9시 뉴스에 앵커나 늘 “오늘 대통령 각하는”으로 시작하는 기사를 매일 보도하는 거랑 다를 바가 없다.

아쉽다.

같은 이야기를 하더라도 조금만 다른 투로 친근하게, 때로는 능글맞게, 그리고 피드백을 쉽게 할 수 있는 분위기를 만들면서 한다면 좋겠는지.

그런 분위기를 만드는 게 쉽지는 않겠지만 노력을 안하는 듯 하니.

여기도 “소통”의 문제가 심각하다.

“소통”이 없으니 “팀 웍”을 꿈도 꾸지 못하고, 남이 뭐 하는 지 알 수도 없다.

Positive Retrospective

우리는 왜 긍정적인 회고를 하지 못하는가?

  • 짜증스런 목소리로 “왜 잘못했냐고?” 소리치는 매니저가 만들어 놓은 아픈 상처때문에?
  • 짜증스런 표정으로 의자에 엉덩이를  걸치고 앉아 핸드폰 게임만 하고 있는 개발자들때문에?
  • 해봐야 소용없다는 회의적인 생각때문에?
  • 얄팍한 자존심때문에? 이미 패치내서 지난 간 일을 들쳐내기 싫어서?
  • 왜 회고를 맨날 골방에서 큰 소리를 내가면서 해야 할까? 왜 밝은 장소에서 할 수 있는 분위기가 안 되는 걸까?

우리는 안 하는 걸까? 못하는 걸까? 둘 다 겠지.

어떻게 하면 바꿔갈 수 있을까?

내가 희망하는 개발팀 문화를 가진 회사

예전에도 한번 “잔업없는 회사”라는 내용으로 접한 적이 있었는데 우연히 어떤 글을 보고 다시금 찬찬히 그 회사의 글들을 보게 되었다.

(주)사이냅소프트

많은 IT업체가 그렇듯이 회사의 생활등을 블로그를 통해 접할 수 있다(우리도 IT업체인듯 한데 그러기엔 우린 엄살이 너무 심하지. 뭐 그리 숨길 게 많다고)

그 중에는 사이냅소프트의 전경헌 사장님과의 인터뷰 글도 볼 수 있는데 사장님의 생각을 통해 회사의 생활이 어떨 지 짐작할 수 있다(반론의 여지가 있는 말이긴 하다. 윗사람의 생각대로 회사가 움직인다고 단정지을 수 없기 때문이다. 구름 위에 있는 사람이 갖는 생각과 현실은 다를 수 있으니. 그래도 일단 들어보자)

그 중 일부다.

유용빈: 정치적 스트레스는 어떻게 해결하시나요.
회 사 내에 그런 스트레스가 얼마나 있는지 제가 잘 알지는 못합니다만 다른 회사에 비해서는 상대적으로 적으리라 생각합니다. 개발자들이 지원하는 역할에 머무르는 회사가 많은데 사이냅소프트는 저부터 시작해 영업 직원들도 개발자 출신이라 서로 이해하는 부분이 많아 갈등이 크지는 않습니다. 또 지난해 애자일 컨설팅의 컨설팅을 받으면서 회고하는 문화가 자리잡고 있습니다. 회고란 체계적으로 즐겁게 반성하고 개선점을 찾는 활동인데 그 이후로는 회사에 있던 문제들에 대해 서로 동등한 수준에서 의사 소통을 하면서 그와 같은 스트레스가 더 줄고 있다고 봅니다.

이국진: ‘가정을 지키기 위해 일찍 퇴근한다’는 글을 쓰셨는데 정시 퇴근은 잘 지켜지나요.
그 글은 2005년에 쓴 글입니다. 전에는 일을 굉장히 많이 했습니다. 결혼하고 나서도 아침에 일찍 출근하고 막차 시간이 거의 다 됐을 때나 새벽에 집에 들어갔습니다. 집에서는 잠만 자고 휴일에도 회사에 나와 일하기도 했습니다. 거의 일만 하는 사람이었죠. 일로서 성공하고 싶은 생각도 많았고요. 2005년은 큰 아들이 유치원에 다니던 해였는데 밥 먹으면서 유치원 생활에 대해 아들에게 물었는데 아이가 대답을 하지 않았습니다. 아내가 대신 이야기를 해줬지만 아들에게 직접 듣고 싶다고 말을 거니 아이가 “아빠는 알지도 못하면서 아는 체 해”라고 말했습니다. 그러고 보니 아이가 보기에는 자기가 일어나기 전에 회사에 나가고 자고 있을 때 집에 들어오니 자신에 대해 아무것도 모른다고 생각하는 게 당연하겠더군요. 물론 아내를 통해 아이가 어떻게 지내는지 늘 듣고 있었지만요. 굉장히 충격을 받았고 이게 제가 원하던 삶은 아니라는 걸 깨달았습니다. 아이가 태어날 때만 해도 크는 동안 많이 안아주고 좋은 이야기를 들려주고 싶었는데 열심히 일하다 보니 어느새 아이는 자라 학교 갈 나이가 되어 있더군요. 세상은 장기전이고 그러려면 가정도 지켜야 하고 저뿐만 아니라 직원들도 마찬가지라는 생각이 들었습니다. 그 때부터 열심히(?) 저녁에 일찍 퇴근하고 있습니다. 아이들이 굉장히 좋아하고요. 요즘은 간혹 집에서 저녁 먹고 들어오라는 전화가 옵니다.(웃음)

오랜 기간 몸에 밴 야근이란 습관을 되돌리는 데 반발은 없었나요.
야 근을 하느냐 하지 않느냐가 좋은 개발자를 판단하는 기준은 아닐 겁니다. 책임감이 굉장히 강한 개발자들은 맡은 일이 진전되는 것을 확인하려고 야근을 하기도 합니다. 야근 금지를 반대하는 개발자들도 있었습니다. 회사에서 뭐라 하든 ‘내 일이기 때문에’ 야근을 해도 상관 없다는 이유 때문이었죠. 소프트웨어 개발은 장기전이고 몇 달 바짝 해서 성공하는 게 아니기 때문에 자신의 건강과 가정을 지키며 일하자고 계속 설득해 지금은 야근 금지가 많이 정착되어 특별한 일이 있지 않는 한 다들 일찍 퇴근합니다.

지금도 개발을 하시나요.
예. 수시로 하고 있습니다. 직원들이 개발을 하다 문제에 부딪히면 같이 살펴보기도 하구요. 프로그래밍 공부도 꾸준히 하고 있습니다. 제품 코딩보다는 직원 교육을 위한 코딩 위주로 하고 있습니다. 최근에는 파이썬을 많이 쓰는데 아이디어가 떠오르면 파이썬으로 빠른 시간 안에 구현할 수 있어 직원들이 어떤 문제에 막혔을 때 그것을 푸는 데 도움이 될 만한 코드를 파이썬으로 짜서 보여주기도 합니다. 개발이 여전히 좋아 은퇴 후에도 코드를 짜는 걸 즐기지 않을까 합니다.

앞으로 구상이 있으시다면 소개해 주세요.
지 금까지 한국 소프트웨어 개발사들을 보면 유명 개발자 한두 명에게 크게 의존하는 경우가 많았는데 그런 방식에는 한계가 있다고 봅니다. 문화를 잘 가꾸며 체계적으로 개발을 하는 회사가 성공하는 사례가 나와야 할 것 같습니다. 좋은 소프트웨어를 만드는 데 필요한 것이 있다면 기꺼이 받아들여 배우고 적용할 계획입니다.

또 다른 글,

다양한 기능은 어떻습니까? 마이크로소프트 오피스에는 수없이 많은 기능이 있습니다. 그러나 우리가 사용하는 기능은 매우 단순한 몇가지에 지나지 않습니다. 그 많은 다양한 기능은 어디다 쓰는 것이죠? 그 기능들을 개발하느라고 수없이 많은 개발자들이 시간을 쏟아 부었을텐데… 우리한테 어떤 의미가 있습니까? 사실상 거의 의미가 없죠. 일반인들이 워드에서 XML로 저장하는 기능을 사용할 일이 있겠습니까? 엑셀에서 포아송분포를 계산할 필요가 얼마나 있겠습니까? 그러한 다양한 기능들은 영업을 위한 자료에 사용될 문장 몇개 만드는 것 이상의 용도가 없습니다. 핵심기능이 잘되는 것이 훨씬 중요합니다. 일정과 기능도 무시 못할 요소이기는 하지만, 결코 품질보다 중요하지는 않습니다.

먼저, 정치적 환경입니다. 이건 언제나 발생하고 가장 골치아프고, 해결하기 어려운 것 중에 하나 입니다. 팀장이상 급에서는 어느 정도 신경을 쓸 수 밖에 없죠. 정치적 환경에서 발생하는 문제는 임원들에게 알려주세요. 임원들이 해결하도록 하겠습니다. 정치적 환경 때문에 골치아파 하지 마십시오. 임원들이 해야하는 역할 중에 하나가 정치적 문제를 없애는 것입니다.

두번째로는 기술적 환경이 있습니다. AIX에서 돌아가는 프로그램을 짜야하는데 AIX가 없으면 안되겠죠. PC가 2대 있으면 금방 해결할 수 있는 문제라면 한대 더 사야겠구요. 지금 쓰고 있는 컴퓨터가 느려서 컴파일시간이 오래걸리면 바꿔야죠. 메모리가 부족하면 늘려야겠구요. 기술적인 환경은 약간의 비용을 들이면 쉽게 해결이 가능합니다.

우리 인트라원 자유게시판에 보면 “빌게이츠 찾아가는 법”이라는 제목으로 지도 3장이 올려져 있을 것입니다. 아마 관심있게 본 사람들은 알 수 있었겠지만 마이크로소프트 메인 캠퍼스의 대부분 건물들은 십자(+)형이나 에이취자(H)형으로 되어있습니다. 우리나라 건물들이 대부분 박스(ㅁ)형인 걸 생각하면 매우 특이한 것입니다. 마이크로소프트 메인 캠퍼스에도 박스형 건물들이 몇개 있지만 강당 등 공통 공간인 경우입니다. 직원들이 일하는 공간은 대부분 십자형과 에이취자형 건물입니다. 박스형건물이 건축비가 싸게 먹힌다는데… 왜? 십자형과 에이취자형으로 건물을 지었을까요? 십자형과 에이취자형 건물의 특징은 좁은 복도와 복도 양쪽으로 창이 딸린 방을 배치할 수 있다는 것입니다. 즉, 마이크로소프트는 메인 캠퍼스에 근무하는 모든 사람에게 창이 딸린 작은 방(1인실 또는 2인실)을 주고 있습니다. 너무 돈이 많아서, 돈질을 하는 걸로 보이나요? 빌게이츠씨가 헛 돈 쓰는 거 봤습니까? 차라리 기부를 하면 했지, 과시를 위해서 돈쓰는 건 아닐 겁니다. 또, 빌아저씨쯤되면 과시하지 않아도 누구나 인정하는 세계에서 제일 돈이 많은 사람이잖아요. 빌아저씨가 소프트웨어 회사에서 생산성과 품질을 높이는 가장 좋은 업무 환경을 연구해서(연구비줘서 시켰겠죠) 실현한 것이라 생각합니다.

자, 어떤가?

흔한 말로 생각이 바로 박혀있는 것처럼 보이지 않는가? 어떤 회사의 사장이란 사람이 저런 위험한(?) 말을 할 수 있을까? MS의 건물 배치에 대해서는 피플웨어에서도 언급했던 내용인데 우리 회사 매니저중에 얼마나 많은 사람들이 그 책을 봤을까? 내 근처 사람중에 단 한 사람이라도 본 적이 있을까?(이런 S/W 생산성에 관한 책을 정리해서 공유 해볼까?)

구글 리더에 등록했는데 최근 10개만 보여서 열심히 블로그 페이지에서 직접 글들을 읽고 있다. 볼만한 내용이 너무 많다.

다만 블로그에 댓글이 그리 많은 편이 아닌 것이 아쉽다.

과연 우리 회사는? 우리 회사 역시 세상이 좋다고 하는 것 중 몇 개는 따라 하려고 한다. 다만 항상

  • Top-down
  • 수치를 통관 관리
  • 안하면 갈금

의 형식을 갖는다. 왜 해야 하는 지에 대해 충분히 설명하고(당연한 것도 있겠지만) 자발적으로 하는 문화를 만들기 보다는 늘 명령하달식으로 진행한다. 위키를 설치해서 사용하는 것을 몇 번 보여줬는데 맘에 들었나 보다. 위키를 많이 사용하라고 권고하기 시작했다. 조만간 주간별 포스팅 수등을 관리하면서 1인당 포스팅 갯수를 할당하지 않을까 걱정이다 -_-

코드와 로그는 나만을 위한 것이 아니다.

코드와 로그는 나만을 위한 것이 아니다.

  • 나의 코드를 받아서 책임 지게될 후임자의 것이다.
  • 나와 관계된 블럭 담당자의 것이다.
  • 내  블럭이 제공하는 기능을 시험하는 시험자의 것이다.

자기만 사용할 거라고, 자기만 볼 거라고, 이전 담당자가 코드를 엉망으로 작성해서 그런 거라는 핑계는 대지 말자.

현재 그 코드를 담당하는 사람이 자신이면, 자신이 모든 걸 책임져야 하는 것이다.

자신의 외모에 신경쓰는 것의 일부만이라도 코드에 신경을 써주자.

제발 부탁이다.

(펌) 코멘트 작성하는 방법

Agile 관련 책에서도 유사한 내용이 나오지만 코멘트는없으면 없을 수록 좋다. 코드만으로도 이해할수 있는 코드가 가장 좋기 때문이다.

그렇지 못하다면 위에서 처럼 코드와 똑같은 내용을 문장으로 적는 것이 아니라 알고르즘이나 코드의 존재 이유에 대해 적어야 한다. 불필요한 코멘트는 코드의 가독성만 떨어뜨린다.

출처 : birdkr’s home by (버드)

AgileOST 모임 후기라는데

요즘 한창 관심을 두고 있는 Agile.

XP하면 국내에서 제일 유명한 김창준씨가 Agile에 대한 경험담을 서로 나누는 자리를 마련했단다.

그 모임 후기 내용이 정리되고 있는 위키가 있다. 경험이 있거도 혹은 없어도 다른 사람들과 이야기를 나누는 것은 좋은 일이다. 내가 일하는 곳에서 제일 아쉬운 점이 바로 대화부족이듯이.

지금은 너무 늦었으니 아침에 다시 한번 읽어봐야겠다.