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을 고객에게 먼저 보여줄 수 있기 때문이다.

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.