Sun talks of annotations as being an extension to the existing in Java. I disagree. Let’s define . Metadata is data about data. I consider the reflection API as something that expresses .
It tells you about classes and their methods. It tells you about the
types of arguments in your methods. It tells you about the structure of
your pre-existing Java code.
 | 도와주세요! 팀장이 됐어요 -  신승환 지음/위키북스 |
그러한 점에서 SI 등에의 프로젝트의 경우는 어떨지 궁금합니다. 계약 기간의 연장이나 프로젝트 실패는 곧 리스크이고 손해일것인 데, 좀 더 장기적 안목으로 여러 불확실성이 야기시키는 리스크에 대한 보험으로서 리드타임이 짧은 팀, 혹은 애자일 팀을 끌여들이려는 시도는 없을까요?
----
그리고 조금 질문을 바꿔서, '애자일이 가능하다고 한다면, 구체적으로 무엇이 어떤 모습으로 가능하다는 뜻일까요?' 조금 더 각개
격파(?) 할 수 있지 않을까요? 고객회사와의 빠른 피드백? 실질적인 가치를 매일 전달하는 개발? 유닛테스트 & TDD? 지속적인 디자인 개선? 지속적인 통합?
페어 프로그래밍? 프로세스 개선을 위한 매일매일의 노력? 혹은 이를 가능하게 하는, 변화에 대해 포용하는 사람들의 마인드? 10%의 애자일, 30%의 애자일, 60%의 애자일, 80% 이상의 애자일이 있다면, 각 스펙트럼 대비 모양새들이 어떨지가 궁금합니다. :)
The Goal을 연관시킨 면이 매력적인 발상이었습니다. 또한, 밑줄 친 부분은 매우 실용적인 문제 의식입니다. 그리고 '각개
격파'로 논의하자는 것도 실용적인 발상이죠. 토론프로에서 모호한 논의가 이어질때 사회자들이 끌고 가는 방향이기도 하죠. 그 뒤에 어떤 분이 약간은 모호한 글을 달아뒀길래.. 제가 좀 구체적인 이야기로 쓰레드를 이어갔습니다.
저는 실제 SI 프로젝트에서 애자일 선언에 입각한 접근을 행해서 효과를 거둔 바 있습니다. 정확하게는 현재도 거두고 있죠. 그 중에서 하나를 소개하자면 OPPM(One Page Project Management)를 보고 인용한 것인데 프로젝트 계획 시점에서 전체를 다루는 WBS는 고객사 내규가 허용하는한 구체적인 액티비티는 명기하지 않고 목적 중심으로 작성했죠. 그리고, 실행계획은 스프린트라는 반복주기 단위로 처음에는 2주 단위.. 그리고 프로젝트 중반 이후부터는 4주로 했다가 현재는 6 주 단위로 작성합니다.
필연적으로 변할 수 밖에 없는 부분을 조기에 고정하려고 욕심을 부리다가 소모하는 시간이
following a plan 이나 comprehensive documentation에 해당하고 그 시간을 아끼면
working s/w를 만드는데 쓸 수도 있고, 변화할 부분을 고정하지 않았기에 Responding to change에 유리하죠. 계획의 2단 분리는 일정 변경으로 유발할 수 있는 고객사 결제 등을 피할 수 있어서 시간을 벌어주었죠. 비슷한 사례 중의 하나로 요구사항 범위 확정건이 있는데요.
우리는 12주 안에 결과를 만들어 보여줘야 할 일이 있었는데요.
문제는 고객도 잘 모르는 요구사항에 대해서 정의하고 만들어야 한다는 점이었습니다.
그런 상황에서 지나치게 요구사항을 정의하고, 필요한지 어떤지도 잘 모르는 기능을 위해
UI 프로토타이핑이나 다양한 계층의 현업 인터뷰 소집으로 인한 시간 소비가 위험해보였습니다. 하여.. 2주만에 요구사항에 대한 최소한의 검증 기준만 세워두고 모호한 것은 바로 구현에 들어갔습니다. 모호한 것 우선해서 개발을 했죠. 그래서 모호한 것은 대충 구현된 프로토타입(throw-away가 아닌)을 보여주고 컨셉 불일치부터 확인을 했습니다.
그런 후에는 살을 붙이면 되었고, 결국 빠듯해보이던 일정에 무리없이 구현을 할 수 있었습니다.
가장 큰 성공요인 중에 하나가 고객과 다른 생각을 하지 않는다는 점을 주기적으로 확인하는 과정에 있었고
그 매개체는 working s/w 였습니다. 물론, UI나 API요소가 강한 것은 그 부분부터 구현했고, 저장방식이 중요한 녀석은 DB 스키마나 클래스 자료구조부터 구현해서 보여줬죠.
 | The One Page Project -  클라크 A. 캠벨 지음, 안진환 옮김/을유문화사 |
반면, 그가 서울에 초대받은 이유인 기술적인 교류에 대해서는 다소 부정적인 인상이었나 보다. SOA에 대해 지나치게 구체화 하여 실현 불가능한 (논리적) 프레임워크를 만든다거나 동적 언어에 대해서는 아예 들어본 일이 없다거나... 1난데 없는 애자일 논쟁에 휩쓸렸는데...
SI 프로젝트에서도 애자일 프로세스는 가능한가?라는 글을 보고 애자일에 관심이 많은 사람들의 공통적인 지적은 '애자일이 SI에서 출발했다'는 내용이다. 하지만, 재성씨가 말하는 SI 프로젝트는 국내 열악한 환경을 지적하는 것이었다. 일민형이 '술자리에 씹었다'는 표현을 써서 도발을 했는데, 술자리의 이야기는 이렇다.
선배는 재성씨처럼 개발자에게 영향을 줄 수 있는 사람이 그러한 넋두리를 한다는 것에 대해 실망했다는 내용이다. 나 역시 수도 없이 넋두리를 하며 살아왔다. 하지만, 솔직히 재성씨의 글은 반박을 불러일으키는 그런 글이었다. 댓글을 달아놓은 일민씨도 뭐라고 하려다 말았다 했고, 나 역시 재성씨의 진심을 알기 때문에 달래는 글을 썼다. 하물며 재성씨를 모르는 사람이 저 글을 보면 어떠했을까?
선배는 나름 치열하게 열악한 전장의 일선에서 아주 천천히 개선을 만들어왔다. 그 일을 좋아하고, 앞으로도 그렇게 살 것이다. 나 역시 그렇고, 어제 술자리에 모인 사람은 모두 그런 점을 공유하고 있다. 나는 대부분의 프로젝트에서 부정적인 관행에 의존하는 사람과 치열하게 싸웠다. 글쎄 그게 과연 치열했는지는 자신없지만, 대개는 나보다 훨씬 경험이나 영향력이 있는 이들이더라도, 물러서지 않고 신념을 지켜왔다. 그렇게 했을 때 아주 조금 대가가 주어졌다.
그것은 고작 HR0002222, HR00002223 등으로 작명하자는 원칙을 의미있는 작명으로 만드는 일일 때도 있었고, 프로젝트 관리자가 WBS 작성이나 반복계획서를 밑에 사람들에게 위임해서 입으로만 프로젝트를 하는 행동에 대한 대항이기도 했고, 깊이 고민하지 않고 '내가 오랫동안 그렇게 했다'라고 설계 결정을 내리는 사람과의 투쟁이기도 했다.
이쯤에서 밝히면 나는 애자일이 도무지 뭔지 모르겠다. 그간 수차례 애자일이란 말을 내멋대로 써온 것이 뜨끔하다. 나는 여러 업체에서 모여든 100여명의 팀원이 성공적으로 프로젝트를 이행하기 위해 아침에 수행을 하고 오는 스승을 만난 일이 있다. 그 분이 프로젝트 현장에 있을 때는 갈등이 줄어들고, 사람들이 돌연 협력적으로 바뀐다. 이런 뚱딴지(?)같은 이야기는 접어두자. 나도 그런 것들을 실천할 엄두같은 것은 나지도 않으니까. 내가 애자일이란 말조차 잊어버리고 살 즈음인 요즘에 프로젝트에서 하는 일이 과거에 내가 '애자일'이란 말로 인식했던 것을 실천하고 있다. 그러기 위해서 '자기 일'만 몰두하는 팀원들에게 다른 팀원과 자신의 관계를 설명하는데 많은 시간을 사용하고 있다. 물론, 돈과 시간이 넉넉하다면, 김창준씨를 불러서 컨설팅을 받아도 좋겠지만, 무턱대고 페이 프로그래밍을 하고 TDD를 하자고 해서 팀원들이 그걸 따를 리가 있는가? 새벽에 올린 메시지의 파트너 역시 게임회사에서 '애자일'을 위해 파티션을 제거하고 욕을 먹고 있다 한다. 이러한 활동은 어떤 상황에서 어떤 위치에 있더라도 실천할 수 있다.
Process_Maturity_Seminar_Kevin_McCormack.pdf