Agile Life

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.

흔히 이젠 잊었어 그래서 아무렇지도 않아 말한다. 전에는 평생 잊지 못할 사건이었고 인생의 모든 걸 결정하는 분기점이었던 사실들이 시간이나 상황이 지나면서 무덤덤해졌을 때 하는 얘기이다. 하지만 웬지 일부러 괜찮다고 말을 하는 것은 아직 잊지 못하고 있다는 자각증세이다. 아마 정말 잊었다면 그런 말 조차도 나오지 못할 정도로 기억의 저 뒤안편에서 수북한 먼지 속에 이미 그 모습을 잃어가고 있을테니까.

혹은 이렇게 묻혀있던 정말 잊었던 사실들이 어떤 계기로 불거져 나왔을 때, 이걸 다시 파묻으려는 주술이 바로 '이젠 잊었어, 아무렇지도 않아' 일 것 같다. 지금 누리고 있는 이 익숙해진 사실과 서로 충돌하는사실들이 다시 떠오를때 우리는 이 주술을 읊조리게 된다. 그 충돌이 심하여 아픔이 되기 때문에 애써 잊어진 사실들을 다시 묻으려는 것이다.

어쩌면 옛날의 진실들이 잊혀질 수 있는 건 그러고 싶은 나의 의식에 의해서가 아니라 지금 현재 진실이 더 다급하고 중요해지면서 서서히 그 설 자리를 스스로 잃어가는 것이 아닌가 싶다. 따지고 보면 내가 잊고 싶다고 해서 잊어질 수 있는 것들은 없어보인다. 우리의 마음이 그리고 정신이 그렇게 움직이지 않기 때문이다.