애자일(프랙티스) - 사용자가 원하는 내용을 제공하기

설계가 강요하는 대신 안내하도록 하라

- 강기슭에 이르러 강을 건너는 방법에 대해 더 잘 판단할 수 있을 때까지, 강을 건너는 방법의 세부내용을 정하느라 시간을 낭비하지 말라

- 요구사항이 조금 변해도 계속 구현하기 쉽다면 그 설계는 좋은 설계다.

★ 균형유지 하기

● '미리 대규모로 설계할 수 없다' 는 말은 설계가 전혀 없다는 뜻이 아니다. 

   이말은 단지 실제 코드로 검증하는 일 없이 설계 작업에 매달리지 말라는 뜻이다. 설계에 대한 고민없이 코딩에 뛰어드는 것은 위험하다.

   그런 식으로 뛰어들어도 괜찮은 경우는, 배우거나 프로토타입을 만들기 위해 바로 코딩한 후에 그 코드를 버릴 때다.

● 초기 설계가 쓸모없는 것으로 결론이 나도 초기 설계는 해야 한다. 설계를 만드는 행동은 매우 가치 있다.

    꼭 설계 자체가 아니라도 설계 도중에 배우는 일은 가치가 있다.

데모를 사용하여 자주 피드백을 받으라

고객으로 부터 피드백을 받아라 왜냐하면 장기 프로젝트를 완료하고 회의를 할때 버그, 기능 수정과 같은 요구사항이 많아지게 되면 개발하기 곤란해진다. 그러므로 애플리케이션이 개발 도중 항상 눈에 띄게 하고 고객의 마음에 들게 하라. 고객과 접촉하고 매주 또는 2주에 한 번씩 데모를 사용하여 피드백을 미리 구하라!!

● 어떤 고객의 직원은 데모를 시연하는 회의에 참여하는 것이 자기 일인경우도 있다. 그 사람은 시간마다 피드백과 데모를 보여주지 않으면 만족하지 않는다. 이러면 효과야 좋겠지만, 너무 일이 많아서 감당할 수 없다는 사실을 알면서도 단지 보여주기 위해서 계속 코드를 작성하게 된다!

일정을 재조정해서 정말 완료했고 뭔가 보여줄 내용이 있을 때 만나도록 하라.

● 고객이 피드백을 주고 프로젝트를 조정하는데 데모의 목적이 있다. 

기능이나 안정성이 부족해서 고객을 동요시키거나 화나게 해서는 안 된다. 안정성이 없으면 보여주지 말라. 기능에 대한 기대를 일찍 그리고

명확하게 정하라. 즉, 고객이 보고 있는 애플리케이션은 개발 중이며, 최종 완성된 제품이 아니라는 사실을 알게하라.