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

via Waterfall과 Agile :: All of Software

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

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

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

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

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

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

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

Agile software with Scrum development

관련 포스트. (프로젝트 초기의) 때 이른 고통

원문 : Assessing Test Driven Development at IBM

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시 뉴스에 앵커나 늘 “오늘 대통령 각하는”으로 시작하는 기사를 매일 보도하는 거랑 다를 바가 없다.

아쉽다.

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

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

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

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

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

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

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

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

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

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

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

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

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

제발 부탁이다.

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

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

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