agile

Waterfall과 Agile? 현실은?

이미 Waterfall 방식은 너무 느리고 비용이 많이 들어서 대부분의 소프트웨어 프로제트에서는 사용하지 않습니다 via Waterfall과 Agile :: All of Software 정말일까? 현실적으로 대부분 Waterfall 방식을 사용할 듯한데. 왜냐하면? 대부분의 기업에서(인터넷이나 벤처는 잘 모르겠다) Project 를 관리하는 역할이나 그 관리자를 관리하는 사람이 저것밖에 모를텐데. Agile? Scrum? XP? 정말 들어본 적이나 있을까? 최소한 내 주변에 있는 백명이 넘는 개발자 중에 저 세가지 단어를 들어본 사람의 수는 손가락으로 꼽을 수 있다고 장담한다.

Scrum

Agile 방법론에서 가장 유명한 것은 XP이지만 그 외에는 Scrum도 있다. Scrum은 MS에서 사용해서 유명한 듯하다. MS에서 나온 몇 권의 책도 있고, 이번에 Scrum 책 한권이 번역되어 나왔다. 아직 읽어보지는 못했지만 정진호 님의 글을 읽다가 손뼉을 치고 싶을 만큼 “맞아 맞아"를 외치게 한 문장 하나. 프로젝트의 일정이 점점 꼬이고 제어할 수 없는 상태에 빠지는 것은 숨어 있던 문제가 나중에 드러나기 때문입니다. Scrum은 숨어있는 문제를 빨리 드러나게 해 준다고 하는데 도대체 어떻게 하길래 그럴 수 있을까?

[Agile] Assessing Test Driven Development at IBM

원문 : 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.

소통의 문제는 여기에도

요즘 “소통의 부재"가 유행이다. 그런데 그 “소통의 부재"가 청와대와 국민 사이에만 있는 것은 아닐 것이다. 회사 내의 “소통의 부재"는 참 많은 생각을 하게 한다. Agile에서 적극 추천하고 있는 “Stand-up meeting"을 시행하고 있다. 시작한 지 1년이 훨씬 넘은 듯하다. 하지만 한 번도 Agile에서 기대하고 있는 것처럼 적극적인 의사교환이나 정보 교환을 본 적이 없다. 늘 대장 노릇을 하는 사람이 주절주절 이야기를 하고, 나머지 사람들은 땅을 보거나 모니터를 보거나 가끔은 대장을 보거나. 피드백? 그런 거 별로 없다.

Positive Retrospective

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

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

예전에도 한번 “잔업없는 회사"라는 내용으로 접한 적이 있었는데 우연히 어떤 글을 보고 다시금 찬찬히 그 회사의 글들을 보게 되었다. (주)사이냅소프트 많은 IT업체가 그렇듯이 회사의 생활등을 블로그를 통해 접할 수 있다(우리도 IT업체인듯 한데 그러기엔 우린 엄살이 너무 심하지. 뭐 그리 숨길 게 많다고) 그 중에는 사이냅소프트의 전경헌 사장님과의 인터뷰 글도 볼 수 있는데 사장님의 생각을 통해 회사의 생활이 어떨 지 짐작할 수 있다(반론의 여지가 있는 말이긴 하다. 윗사람의 생각대로 회사가 움직인다고 단정지을 수 없기 때문이다.

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

코드와 로그는 나만을 위한 것이 아니다. - 나의 코드를 받아서 책임 지게될 후임자의 것이다. - 나와 관계된 블럭 담당자의 것이다. - 내 블럭이 제공하는 기능을 시험하는 시험자의 것이다. 자기만 사용할 거라고, 자기만 볼 거라고, 이전 담당자가 코드를 엉망으로 작성해서 그런 거라는 핑계는 대지 말자. 현재 그 코드를 담당하는 사람이 자신이면, 자신이 모든 걸 책임져야 하는 것이다. 자신의 외모에 신경쓰는 것의 일부만이라도 코드에 신경을 써주자. 제발 부탁이다.

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

Agile 관련 책에서도 유사한 내용이 나오지만 코멘트는없으면 없을 수록 좋다. 코드만으로도 이해할수 있는 코드가 가장 좋기 때문이다. 그렇지 못하다면 위에서 처럼 코드와 똑같은 내용을 문장으로 적는 것이 아니라 알고르즘이나 코드의 존재 이유에 대해 적어야 한다. 불필요한 코멘트는 코드의 가독성만 떨어뜨린다. 출처 : birdkr’s home by (버드) comments 야옹^^ at 2008-02-01 17:02:16 오.. 이런 명쾌한 규칙이~!! 감사합니다. ^^ 어떨땐 주석이 더 읽기 어려운경우도 있어요. -0-;; cychong at 2008-02-01 23:38:44 무척 찔립니다~ ㅋㅋ.

우리에게 필요한 것은

대화 공유 배려 그리고 희망 comments 떠나는 강책임 at 2007-12-21 01:37:23 그걸 찾으러 저는 떠납니다. 저도 여기서 정말 많이 아쉬웠습니다. p.s. 뭔일 있습니까? cychong at 2007-12-21 07:04:05 저도 떠나고 싶습니다. 1년간 아니 근 몇 년간 쌓인 거죠. 그러다 어제 회식 자리에서 결정타를 맞았구요. 뭔 부서가 그냥 회식도 아니고 송년회 회식을 그렇게 하나 몰라요. 그동안은 바빠서(?) 인식을 못하다 현실을 깨달은 거구요. 그리고 연말이잖아요. 좋은 소식은 커녕 나쁜 소식만 들리니. !@#!@#$ 야옹^^ at 2007-12-21 17:18:43 정말 필요한것들입니다… 어디에 요청해야할까요?

AgileOST 모임 후기라는데

요즘 한창 관심을 두고 있는 Agile. XP하면 국내에서 제일 유명한 김창준씨가 Agile에 대한 경험담을 서로 나누는 자리를 마련했단다. 그 모임 후기 내용이 정리되고 있는 위키가 있다. 경험이 있거도 혹은 없어도 다른 사람들과 이야기를 나누는 것은 좋은 일이다. 내가 일하는 곳에서 제일 아쉬운 점이 바로 대화부족이듯이. 지금은 너무 늦었으니 아침에 다시 한번 읽어봐야겠다.