Extremely Agile/General2007.09.18 17:02
사용자 삽입 이미지

출처: http://www.extremeprogramming.org/map/project.html

위의 다이어그램에서 흥미있는 부분은 Spike에 관한 부분이에요. Spike는 Release Planning을 하기 위한 기본 자료입니다. 그러니까, 일의 규모나 시간 요구량을 가늠하기 위한 솔루션이죠. Spike는 "실용주의 프로그래머"라는 책에 따르면, "프로토타입"에 상응하는 개념이에요. 폐기해도 좋은 시스템이죠. 이 시스템은 시스템의 유저와 소통하고, 일의 규모를 정확하게 산정하기 위해서만 필요합니다. 꼭 최종 시스템에 가까울 필요는 없어요.

유저 스토리가 그것과 별개로 작성되고, 이것이 '요구사항' 형태로 'Release Planning'에 입력으로 제공된다는 것을 유의해 볼 필요가 있습니다. 특정한 유저 스토리를 구현하는 데 얼마만큼의 시간이 걸리게 될지 모를 때, 스파이크 솔루션을 만들어 보는 것이죠. 그렇게 하면 일의 규모를 보다 정확하게 가늠할 수 있습니다. 기술적인 난제에 마주했을 때, 그 문제만을 따로 떼어 그 문제를 해결하는 데 드는 비용을 계산해 보는 데에도 유용하겠어요.

다만 일반적인 스파이크와, 최초의 'Architectueral Spike'는 조금 구별할 필요가 있을 터인데, 초기의 스파이크 시스템은 팀 내의 구성원이 모두 공통적으로 사용하게 될 '용어' (객체나 컴포넌트의 이름이 될 수도 있고, 개념이 될 수도 있겠습니다)를 정하기 위한 시스템입니다. 사용자 스토리가 나오기도 전에 스파이크 솔루션을 만드는 것이 언듯 이해가 잘 안 가는 면도 있는데, 사실 계약을 수주하는 순간 그 계약의 결과로 구현될 시스템의 모습은 '대략적으로' 그려진다고 봐도 무방하지 않겠어요? 아래는 Architectural Spike 솔루션의 결과로 나오게 될 산출물인 "System Metaphore"라는 것이 무엇인지를 설명하는 인용문입니다. 역시 위의 사이트에서 참조했습니다.

Choose a system metaphor to keep the team on the same page by naming classes and methods consistently. What you name your objects is very important for understanding the overall design of the system and code reuse as well. Being able to guess at what something might be named if it already existed and being right is a real time saver. Choose a system of names for your objects that everyone can relate to without specific, hard to earn knowledge about the system.

 For example the Chrysler payroll system was built as a production line. At another auto manufacturer car sales were structured as a bill of materials. There is also a metaphor known as the naive metaphor which is based on your domain itself. But don't choose the naive metaphor unless it is simple enough

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^