이미 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를 적용한 사례 정리
FVT(Functional Verification Test) 기준 기존 대비 50%의 defect rate를 보임.
TDD(w/ Unit testing)은 개발 초기에 도입해야 함
요즘 “소통의 부재”가 유행이다.
그런데 그 “소통의 부재”가 청와대와 국민 사이에만 있는 것은 아닐 것이다.
회사 내의 “소통의 부재”는 참 많은 생각을 하게 한다.
Agile에서 적극 추천하고 있는 “Stand-up meeting”을 시행하고 있다. 시작한 지 1년이 훨씬 넘은 듯하다.
하지만 한 번도 Agile에서 기대하고 있는 것처럼 적극적인 의사교환이나 정보 교환을 본 적이 없다.
늘 대장 노릇을 하는 사람이 주절주절 이야기를 하고, 나머지 사람들은 땅을 보거나 모니터를 보거나 가끔은 대장을 보거나.
피드백? 그런 거 별로 없다.
게다가 대장이 해주는 이야기는 대부분 진행 중인 과제의 “문제점”인 경우가 많아 듣기에 썩 좋은 이야기는 아니다. 타산지석으로 삼으면 좋겠지만 아쉽게도 전달하는 사람은 항상 “저런 저런 문제가 있었다. 우리는 이게 문제다”가 논지이기 때문에 과히 듣기 좋지는 않다. 맞는 이야기겠지만 비슷한 톤으로 비슷한 논지의 이야기를 주 5일 듣는다고 생각해 보자. 끔찍하지 않은가? 이건 마치 예전 5공때 9시 뉴스에 앵커나 늘 “오늘 대통령 각하는”으로 시작하는 기사를 매일 보도하는 거랑 다를 바가 없다.
아쉽다.
같은 이야기를 하더라도 조금만 다른 투로 친근하게, 때로는 능글맞게, 그리고 피드백을 쉽게 할 수 있는 분위기를 만들면서 한다면 좋겠는지.
그런 분위기를 만드는 게 쉽지는 않겠지만 노력을 안하는 듯 하니.
여기도 “소통”의 문제가 심각하다.
“소통”이 없으니 “팀 웍”을 꿈도 꾸지 못하고, 남이 뭐 하는 지 알 수도 없다.
우리는 왜 긍정적인 회고를 하지 못하는가?
우리는 안 하는 걸까? 못하는 걸까? 둘 다 겠지.
어떻게 하면 바꿔갈 수 있을까?
코드와 로그는 나만을 위한 것이 아니다.
자기만 사용할 거라고, 자기만 볼 거라고, 이전 담당자가 코드를 엉망으로 작성해서 그런 거라는 핑계는 대지 말자.
현재 그 코드를 담당하는 사람이 자신이면, 자신이 모든 걸 책임져야 하는 것이다.
자신의 외모에 신경쓰는 것의 일부만이라도 코드에 신경을 써주자.
제발 부탁이다.
1
Feb 08
(펌) 코멘트 작성하는 방법
Agile 관련 책에서도 유사한 내용이 나오지만 코멘트는없으면 없을 수록 좋다. 코드만으로도 이해할수 있는 코드가 가장 좋기 때문이다.
그렇지 못하다면 위에서 처럼 코드와 똑같은 내용을 문장으로 적는 것이 아니라 알고르즘이나 코드의 존재 이유에 대해 적어야 한다. 불필요한 코멘트는 코드의 가독성만 떨어뜨린다.
출처 : birdkr’s home by (버드)