Agile Life

잠이 오지 않아 낯선 시간대에 깨어 있다. 달리 할일도 없이 그냥 깨어 있다.

생각들이 어쩔줄을 몰라하는데. 걔네들에겐 혼란스러운 일이겠지. 그런 혼란중에서

반짝 반짝하고 앞으로 나오려는 몇몇 생각의 갈래가 있다. 얼핏 얼핏 무슨 생각들인지

꽤 중요한 것들처럼 보여서 정리하고픈 맘에 아무런 메모장을 열어보지만

그냥 혼란함 저 너머로 사라져 버린다.

이 수줍은 생각들이 아마도 나를 더 멀리 움직이게 할 어떤 창의적 원동력은

아닐까 생각해본다.

가슴에 와닿는 사진 한장!

 

옛시간을 뒤돌아보면 수치스러운 후회들에게 쫓기게 되며

지금은 무엇 할 지를 몰라 전전긍긍하며 일상의 부질없음에 망설이게 되는데 

이로인해 다가올 시간의 망가짐은 물결치듯 쭈욱--- 퍼져만 간다.

저기 되돌아 올 수 없는 저 곳까지

막강 Solution 개발을 향한 투지를 불태우는 개발자들에게 고객과의 communication은 그 solution의 대강을 짐작케하여 고객과 함께 일할 수 있는 바탕을 마련하는 아주 중요한 프로세스이다.  대부분, 요구사항 분석 (requirement analysis) 과정으로 고객과의 communication을 시작하게 된다. 하지만 프로젝트내에서 이런 communication을 지속적으로 수행할 process가 한번의 요구사항 분석외에 더 없다면 감히 말하건대 그 프로젝트가 성공으로 가는 길은 험난할 것이다.

이 지속적인 고객과의 communication을 달리 말하면 프로젝트가 끝나는 순간까지 고객과 요구사항분석을 계속한다라는 것을 의미한다. 즉, 고객의 요구사항이 계속 변할 것이라는 mindset에서 출발하여 이런 유동적인 요구사항변화를 실시간으로 잡을 수 있는 communication 채널을 열어두어야 한다는 것이다.

Fitnesse 를 사용하면서 이 tool이 이러한 고객과의 지속적인 communication을 지원할 수 있는 잠재력을 보게 되었다. 우선 Fitnesse는 acceptance test tool의 하나이다. 이 accetpatnce test 는 달리 말하면 시스템 테스트 혹은 functional 테스트를 아우르는 포괄적인 모든 highlevel 테스트들을 포함하고 있다. 하지만 중요한 것은 acceptance라는 단어가 말하듯 고객이 시스템의 기능을 테스트를 통해서 confirm한다는 것이다. 그리고 이론적으로 이런 accepatance 테스트들의 작성자는 고객이 된다. Fitnesse는 WIKI 기반으로서 고객이나 개발자 모두가 테스트 페이지에 contribute할 수 있게함으로 이미 협업과 communication이라는 두가지 장점을 기본적으로 가지고 있다.

또한 acceptance 테스트 자체가 고객의 요구사항이 된다. 그리고 tool의 특성상 항상 testable한 형태로 존재하게 되는데 이는 요구사항과 테스트의 추적 matrix를 작성했던 개발자들이라면 이미 그 중요성을 굳이 말하지 않아도 될 것이다. 이런 요구사항은 일반 문서적이고 서술적인 요구사항 산출물보다 다음과 같은 고객의 의도를 더 간파할 수 있다.

 * user input
 * control flows
 * GUI design (primitive yet inspiring)

이런 부수적인 장점들을 가질 수 있는 이유는 acceptance test를 실제 프로그램을 상상할 수 있게끔 만들 수 있다는 데 있다. 즉, 최종 solution의 wireframe을 고객에게 먼저 보여줄 수 있기 때문이다.

솔루션 위주의 개발은 결국 고객이 원하는 산출물을 제공하는 것을 목표로 하는 프로젝트 수행 과정이다. 세상의 모든 프로젝트가 이 고객만족의 목표를 위해 뛰고 있다. 하지만 과연 성공하고 있을까? 프로젝트 일정 후반기에 고객이 요구사항을 변경하는 것도 그들의 변죽에 의한 것이 아니라 어쩌면 고객이 원하는 solution을 만들고 있지 않기 때문일 것이다. 프로젝트를 하는 mind와 solution을 만드는 mind 사이에는 엄청난 차이가 있다. 프로젝트 자체를 위한 mindset에서는 solution이 나오기가 힘들다.

Agile, TDD, Pair Programming등의 프로세스 수행방법들을 많은 사람들이 들고 나오는 이유는 이런 solution을 더 잘 만들고자 하는 고민에서이지 결코 프로젝트관리를 위해서는 아니다. 즉, 합리적이고 효율적인 프로젝트 관리보다는 고객이 원하는 solution에 접근하기 위한 mindset을 만들기 위한 도구나 아이디어들인 셈이다.

더 깊이 들어가기 전에, waterfall적인 생각을 버리기 위해서...
사전에 치밀한 요구사항의 분석과 기획에 치중하는 것이 고객이 원하는 원하는 solution을 제공할 수 있는 해결책이 될 수 있을까? 물론 이 방법으로는 실패할 확률이 많다라는 통계적인 수치는 가히 압도적이다. 즉, 다른 대안의 절실한 필요성이 있었다라는 것.

누구나 solution 위주의 개발을 하자고 할 때 반대할 사람은 없을 것이다. 고민의 시작은 어떻게 개발을 할 때 solution위주가 되느냐 하는 방법론적인 문제로 결국 돌아온다는 것이다. 이런 프로세스에 대한 고민으로 test driven development라는 것을 먼저 살펴보자.

테스트주도개발:

테스트 주도 개발은 "Test First"라는 의미를 가지고 있다. 그리고 많은 사람들이 깨닫지 못하는 것은 이것이 software design 방법론이란 것이다. Test는 오히려 부차적인 산출물일 뿐 주된 목적은 "실제 쓰일 구현을 직접 test 환경에서 써 봄으로써 그 맹점이나 개선점을 미리 발견하고자"함이다. 테스트주도개발의 의미를 망치는 대부분의 사람들이 실제 구현을 먼저 해놓고 난뒤 그 구현에 제한된 테스트만을 만드는 이들이다. 테스트없이는 구현도 없는 test first가 되어야만 한다.
이렇게 작성된 테스트들은 기획자들이 만드는 wireframe과 마찬가지로 앞으로 내가 만들 실제 solution의 구현 wireframe이 된다는 것이다. 왜냐하면 테스트들이 결국은 고객의 요구사항을 테스트하는 것이기 때문이다.

앞으로 다룰 주제;
acceptance test = replacement of prototype methodology
mock objects = domain modeling and interface design


Pair Programming:

우선 one engineer + one engineer = two engineers 란 명제는 거짓이다. more than two engineers의 역량이 창출된다는 것이다. 이런 synergy가 solution 위주의 개발 방법의 발전에 지속적으로 공헌할 것이라는 아이디어는 거의 믿음이다. 하지만 기획자와 개발자의 pair는 가공할 만한 조합이라고 본다. 그리고 pair programming을 굳이 프로그래밍만 국한시키지 말라. proposal, schedule, documents 모든 것을 pair로 할 수 있다.


Continuous Integration

solution에 가장 근접한 형태의 system을 지속적으로 테스트해나가자는 의미이지만 이또한 테스트에 중점을 두기보다는 초기에 solution의 시스템을 구축해봄으로 미래에 생길 수 있는 문제점을 빨리 발견하고 지속적으로 해결해나가자는 취지가 더 크다. 이 개념을 조금 더 push하게 되면 prototype에 가까운 의미가 될 수 있지만. 지금 구축하고 있는 시스템이 실제 산출물일 것이기 때문에 사실상 prototype은 아니다. key는 바로 가장 중요한 main 이나 baseline product을 제한된 기능으로 구축한 뒤 iterative하게 evolve시켜나가는 것이다.

이 baseline solution이 필요한 가장 큰 이유는 고객과의 communication이다. 즉, 실제 solution을 기획자와 개발자 그리고 고객이 같이 보면서 이야기를 해보자는 것이다. 최대한 빨리 실제 solution을 고객에게 보여줌으로써 그들이 생각하지 못했던 요구사항을 프로젝트 초기에 발견해 내자는 것이다. 고객이 원하는 solution에 대한 feedback도 항상 그 실체를 보고 스스로 작동해 볼때 더 풍부해지기 때문이다.


Agile

하지만 이렇게 solution centric을 위해서 baseline product을 미리 만들고 evolve시킨다는 것은 말처럼 그렇게 쉽지 않다. 우선 이런 목표를 달성하기 위해서는 agility 즉, 빨라야 한다는 것이다. 빨리 개발초기에 prototype으로 쓰일 실제 system을 구현하고 그것을 통해서 지속적인 refactoring과 iteration을 하기위해서는 프로젝트 수행과정이 유연하며 기민해야 한다. 그래서 agile 방법론이란 말이 나온 것이다. 하지만 agile이란 교과서에 나오는 step by step 절차가 아니라 팀의 mindset 변화에 의해서 내재화되는 자기들만의 프로세스여야 한다. 어느 교과서에도 모든 팀에게 맞는 절차는 없다. 그러나 한가지 확실한 것은 mind가 변할 때 자기들에게 맞는 프로세스에 대한 아이디어로 생긴다는 것이다.

앞으로 다룰 주제;
agile modeling
agile domain modeling
refactoring by layer = MVC pattern

즉, 고객만족의 궁극적인 목표를 가지고 나온 대안들이라면 기획자던 개발자던 프로젝트 매니저던 한번쯤 믿고 따라올 만하지 않을까? 많은 사람들이 snap judgment란 것을 통해서 이 방법론의 potential을 보았고 실제 프로젝트에 적용하면서 성공적인 사례도 많다. 

친구: Y! 난 agile이란 방법론을 앞으로 우리 회사 모든 프로젝트에 도입하고 싶은데, 윗 임원들을 설득할 수 있는 좋은 방법이 없을까? agile 방법이 우수하다는 것을 한방에 증명할 수 있는 그런 것!

나: 글쎄... 그런데 agile이 최선인지 아닌지는 아무도 몰라. 하지만 지금 네가 하고 있는 방법은 절대로 아니라는 거야. 현재 waterfall적인 것은 무조건 안된다는 거지. 그렇다고 무턱대고 지금 가진게 나쁘니까 agile을 하자고 할 수는 없겠지?

친구: 옆에서 네가 테스트를 만들고 mock object란 걸 통해서 domain modeling을 하는 tool들을 사용하는 걸 보니까 이건 웬지 craft를 하는 것 같다는 생각이 들어. 그냥 백지위에서 시작하는 게 아니라 test를 통해 어떤 도구의 도움에 의해 뭔가 조금씩 만들어지는 느낌을 받는다 말이야. 그게 웬지 자신감을 주는 것 같아.

나: 그 feel은 네가 제대로 받은거야. 옛날엔 우리가 software engineering을 하면서 무슨 art를 했던 것 같았었지. class들을 만들땐 무슨 번쩍하는 영감이 떠올라야 했구 그나마도 내가 제대로 하고 있는 지 항상 의문이었지. UML이란 tool을 사용해 보지만 art인 점은 여전했었어?

친구: 맞아 art였어... ^^

나: 테스트 도구를 사용하면서 디자인을 어떤 영감에 의존하지 않는거지. 이 도구들이 줄자로 측정기로 옆에서 내가 만드는 프로그램의 방향을 끊임없이 다듬어주거던. 프로그램자체가 아닌 그 방향을 잡아준다는 거는 정말 내가 너에게 저극 추천하고 싶어. 비록 전사적인 개발방법론 도입과 같이 크게 벌이지 않더라도 개인적으로 이 test tool들을 잘 활용해봐.
나: art가 아니고 craft이기에 자신감을 가질 수 있는거야 ^^. craft는 누구나 할 수 있는거잖아.

친구: 그래서 난 이왕 할거면은 처음부터 진지하게 전사적으로 시작하고 싶은거지. 이론적인 근거가 탄탄한 보고서를 만들 자료좀 줘봐.

나: 그냥 TDD 부터 시작해봐. 그건 뭐 개발 방법론이라고 말할 수도 없는거니까. 또 테스트의 중요성은 아무리 강조해도 모자라잖아? 테스트 먼저 생각하는 사고의 전환부터 시작해봐.

친구: 하지만 테스트 first라는 말은 잘 알겠는데 막상 테스트를 만들려면 막막해져. 그리고 내가 만든 테스트 자체가 도움이 안된다면 결국 개발이나 디자인에 도움이 안되는 건 마찬가지 아냐?

나: 그런 생각이 바로 '시작점'인거야. 어떻게 테스트를 꾸밀까란 고민은 한마디로 말하면 내가 뭘 테스트해야 하나라는 고민이지 않겠어?
나: 뭘 테스트하냐라는 고민에 대해서 정확한 답은 누구에게서 받겠니? 그 프로그램의 사용자겠지? 결국 고객이야.
나: 테스트를 통해서 요구사항 분석도 되는 거지. 그리고 테스트도 하나의 작은 프로그램이기 때문에 고객의 요구사항이 가질 수 있는 잠재적인 문제점들을 미리 미리 볼 수 있다는 장점이 있어. 이건 문서만을 통해서 하는 요구사항분석이 따라 올 수 없는 점이지.
나: 그리고 acceptance test을 하는 wiki tool 봤지? 웬만한 프로타잎의 역활을 충분히 하잖아? 바로 고객에게 아웃풋을 주고 즉각적인 feedback도 기대할 수 있는 거지.

나: 그리고 도구란게 자꾸 써야 느는거잖아. 처음부터 다 알고 사용하지는 못하는거구. 내가 pair programming이라는 걸 한번 소개해주면서 너랑 같이 테스트를 작성해보자. pair programming 은 지식의 인수인계를 쉽게 해주거던.

W,

한국에서 기획자와 개발자들간의 불화, 이질감, 오해들은 W 자네도 이미 알고 있으리라 믿네. 함께 100% 협력해도 성공적인 프로젝트가 될 지 안될 지 모르는 마당에 이렇게 삐걱거리는 관계는 회사의 경쟁력에 치명적일 수 밖에 없겠지. 양쪽 얘기를 다 들어봐야 서로의 입장차이만 확인할 뿐 아무런 도움이 되지 않을걸세.

왜냐하면 근본적인 문제는 기획자에게 바라는 산출물에 대한 회사와 개발자들의 요구사항이 명확하지 않다는데 있는 것일세. 즉, 언제부터 기획자들의 ppt 파일이나 doc, 혹은 visio 파일들이 기획 산출물인양 굳어져 버렸는 지. 우선 이런 문서들이 개발에 도움을 주는 지, 부족하다면 무엇을 어떻게 명확하게 요구해야 하는 지. 이런 질문에 대한 연구나 아이디어가 없다는 것은 결국 기획자와 개발자들 그리고 회사의 임원들 모두의 문제인 것일세.

일단 이 두 department간의 불화를 없애고 협업을  높이기 위해서는 개발자들이 먼저 intiative를 쥐어야 하네. 즉, 개발자들이 자기들이 필요한 기획산출물을 명확하게 요구할 수 있는 능력이 되어야 하는 것이지.

이를 위해서 testing tool과 pair programming을 활용하면 좋을 것일세. 즉, 개발자와 기획자가 pair programming기법을 통해서 test 주도 개발 방법을 실천한다면 아주 좋은 효과를 거두리라 믿네. 자네도 알다시피 testing tool은 결국 design툴이지 않은가? 개발자가 unit test 와 acceptance test를 구현해 나갈 때 함께 기획자가 옆에서 기획과 디자인의 input을 주게 하는 것이지.

이를 통해서 얻는 장점은 먼저 지금까지의 "기획먼저 개발 그 다음" 이라는 전통적인 waterfall방법을 벗어날 수 있는 것이 하나요 그리고 개발자에게 직접적으로 필요한 Test라는 산출물이 그 두번째 장점이 되는 것이지. 그리고 기획자들도 알아야 할 것은 자기가 기획한 내용의 30%는 나중에 쓰이지 않거나 변한다는 것을 깨닫고 어떻게 하면 변화하는 고객의 요구사항을 만족시키는 iterative한 기획을 할 수 있는 지를 연구해야만 한다는 것이지.

그리고 자네 회사에서 이런 test 주도 개발을 선택한다면 기획자들의 능력이 올라가지 않는다 하더라도 개발자들의 능력과 최종 프로그램의 품질은 그래도 옛날보다는 나아질 것일세. 내가 이런다고 말을 한다고 기획을 무시한다고 오해는 말아주게 난 누구보다 기획의 중요성을 잘 알고 있지. 현재 자네 회사의 mindset 안에서의 기획활동으로는 개발자와 기획자의 협업향상은 커녕 프로젝트 성공여부도 확신하기 힘들다네.

그리고 더욱 중요한 것은 이 테스팅툴들은 모두 open source들인 경우가 태반이고 내가 볼때는 일반 워드 문서 작성보다는 훨씬 재미가 난다네 개발자와 기획자 모두가 좋아할걸세. 그리고 고객과의 communication도 훨씬 명확해지면서 고질적인 막판 요구사항 뒤집기도 줄어들 걸세. 그건 나중에 내가 solution centric 디자인이라는 주제로 한번 얘기하겠네.

그럼 Y가

This is my correspondence on the mail from the customer asking how we communicate through the Fitnesse's test pages. This triggers me another topic of Requirement Analysis; we need to change our conventional notion about the requirement gathering process.

---

One of main purposes of the Fitnesse WIKI is that a customer defines the *testable* requirements on the solution s/he would like to have as the outcome of the project. This will replace the conventional discipline of the requirement analysis. You can think of Fitnesse pages as the requirement document that is under development (mainly by customer), and the Fitnesse’s nature of WIKI server enables us to collaborate on the pages. The collaboration is meant to be the ‘communication’.

Along with the normal texts, the Fitnesse’s test-case tables can also convey the following important requirements from the customer’s perspective.

• Input Data Structure
• Operational Business Logic
• Flows of Data Messages
• Output Format
• Glimpse of future GUI (It can substitute the Prototype methodology that is supposed to be the tangible object with which customer and developers can exchange clear communication each other)

A customer thinks about the solution s/he like to have for his/her requirement; if the solution is big, then break it down to smaller sub-solutions, and create the separate test pages for each sub-solution. I like to point out that the ‘solution’ and the ‘requirement’ are two different mindsets. For now, think the ‘solution’ as the ‘testable requirement’. Even in conventional requirement analysis, the requirements should be testable. These test cases from customer are tremendously valuable to developers in finding out what the customer really want; the customers are communicating his meaning of the solution.

Yes, we still need to work on the test page layouts (as communication protocol) in order for the test pages to be good communication ground—where to put comments from both stakeholders and where to put the approval etc. But I think the pages can be evolved while customer and developers start to pour their insights about the solution they are building. Probably the layout of the pages would be the easiest thing to modify.

This article is incomplete; it will be constantly in editing mode.

The 'Solution' is very similar to the conventional Requirement Analysis. For their most important goal is to pronounce the purpose and the functionals of the project. Yet, there is a subtle difference between two. I prefer the 'Solution' term to the requirement because the former sounds more focused on the coherent principal that combine the many pieces of the requirements.

The weakness in the term of requirement is that they tend to fragmentized into the incoherent pieces; sometimes one requirement conflicts with another one. Usually customers are known to be incompetent in giving their own requirements to the developers. There's a profession who work as mediator between customers and developers; their sole job is to inspire the customer so that they can come up with better requirements. By the nature of customers, any requirements can be thrown at the project schedule any time.

The 'Solution', in fact, is based on this requirement analysis at any level of completedness. The 'Solution' will start with as many requirements as currently available to the designer at the time. The main goal of 'Solution' is the designers' overall direction toward how they resolve the given problem. Here you don't need patterns or classes; you only need the high level statement that explains your plan for the 'Solution'. Therefore, 'Solution' is the better fit to the Agile; though the 'Solution' is also viewed as the supplemental perspective that helps the requirement analysis.

For example, the company A needs a inventory projection system for their products, and they will provide the formula to forecast the future target inventory based on the historical sales data. Your goal is to implement the system for the comapny A. Now you just proclaim your solution to this business problem, or requirement. The 'Solution' will take the historical sales data of a single product or multiple products, and it processes the data based on the logic that implements the forecast formula that Company A provided with. Finally, the solution will display the forecast to the users of the system.

That is solution at my best in the beginning; someone can put better solution. After this proclamation, you will decompose your statement into multiple chapters as the development goes on. Usually there is an organic ties within the statement of the 'Solution'.

The forms of the organic ties would be the sequential flow of logic or events or the conditional factors that fork several chunks of the sub divisions. From this 'Solution' statement, you can make sub-solutions to cover the details of small problems--the questions raised from interpreting the 'Solution' statement.

We are going to need to veryfy this 'Solution' as we do for classes by Unit Test Tool. That is why we need to talk about the Acceptance Test Tool, Fitnesse.