The Nature of Software Development를 읽고

toutbon·2023년 1월 22일
0

태스크 vs 스토리
프로젝트를 진행할 때, 커다란 피쳐를 태스크 단위로 쪼개는 것을 추천하지는 않는다. 그 이유는 개발자가 아닌 사람들은 피쳐 개발이 어떻게 진행되는 지 파악할 수 없기 떄문이다.

-> 사용자 스토리를 기준으로 개발하는 것이 더 나은 결과물을 보여줄 것이다.

어제의 날씨

  • 켄트벡, 마틴 파울러가 제안
  • 팀이 얼마나 많은 것을 해야할 지 제안

무리한 목표는 자멸하는 길입니다.

  • 서두르게 되면 더 많은 결함을 만들게 된다.
  • 결함은 방지하는 것 보다 수정하는게 더 오래 걸린다.
  • 서두르게 되면 코드를 지저분하게 짜게 되며, 지저분한 코드도 일정을 지연시킨다.
  • 압박하는 행동은 치명적이다.

제품이 가진 특징을 다듬으세요

  • 우리 제품이 가진 가장 큰 피처는 무엇이라고 생각하나요?
  • 지금 무엇을 하고 있는지, 다음엔 무엇을 해야하는지 알려주는 작은 피처를 찾을 수 있나요 ?
  • 지금 당장 보여달라고 한다면 어떤 소프트웨어를 보여줄 수 있나요 ?

피처는 계속 추가되고 개선됩니다.

  • 오직 테스트만이 결함을 최소화하는 방법입니다.
  • 테스트는 비즈니스와 개발자 관점으로 나눠 진행해야합니다.

ATDD

  • 인수 테스트 주도 개발 ( Acceptance Test Driven Development )
  • 개발 주기가 끝날 때 마다 반드시 비즈니스 관점에서 테스트해 요구 사항을 제대로 충족하는 지 검증 해야합니다.
  • 테스트 주도 개발은 실수가 줄어들고 결함을 더 빨리 찾을 수 있기 때문에 개발 속도를 높여준다 .

야영지 규칙

  • 야영지는 그곳을 발견했을 때보다 떠날 때 더 나은 곳이어야 한다.
  • 피처가 작동한 이후에는 코드를 정리하세요. 정리는 자주 할 수록 좋습니다.

먼저 애자일을 수행할 줄 아는 역량 있는 팀을 만드는 것 부터 시작하세요.

profile
뚜봉

0개의 댓글