Title:
함정에 빠지기 쉬운 애자일 프랙티스 피해가기
|
edited by
Youngrok Pak
at
8 years, 9 months ago.
<p>애자일에 대해 수많은 오해가 있지만, 그 중에 또 하나 독특한 것은 애자일 프랙티스에 대한 난이도 이해가 거꾸로 되어 있는 경우가 많다는 것이다. 그래서 몇몇 함정을 피해가기 위한 짤막한 조언들을 써본다. 이유나 근거는 생략한다.</p>
<ol>
<li>TDD는 바로 시작해도 좋다. 하지만 TDD에 충분히 익숙해지기 전에는 regression test 용도로 테스트를 활용하지 말라.</li>
<li>새로운 팀원이 왔을 때 소스코드를 체크아웃 받고 나서 로컬 머신에서 5분 이내에 주요 기능을 실행해볼 수 있고, 테스트 스위트를 돌려볼 수 있고(테스트 스위트를 돌리는 전체 시간이 아니라 테스트 스위트를 돌리는 명령을 실행하기까지의 시간이 5분 이내), 아주 손쉽게 테스트 케이스 중에서 특정 테스트 메서드 하나만 돌려볼 수 있는 상황을 만들기 전까지는 jenkins 등의 자동화 빌드를 사용하지 말라.</li>
<li>포스트잇으로 그럭저럭 프로젝트 관리를 할 수 있다고 느끼기 전까지는 이슈 트래커, 칸반보드 등을 사용하지 말라.</li>
<li>페어프로그래밍은 어렵다. 처음 할 때는 30분 이내로 하는 게 좋다.</li>
<li>커밋/푸시/디플로이 절차가 복잡할수록 고객은 더 오랫동안 버그를 경험한다.</li>
<li>스토리 포인트는 가능한 한 짧은 시간에 대강 추정할 것. 아니, 추정하지 마.</li>
<li>스토리 포인트는 일정과 연관 짓지 말 것. </li>
<li>이슈 트래커에서 측정할 수 있는 여러 가지 숫자는 모두 프로젝트의 진척도를 평가하는데 중요하지 않다. </li>
<li>일정과 스펙은 둘 중에 하나만 고를 수 있다. 하지만 고객, 혹은 Product Owner에게 둘 중에 하나를 선택하라고 요구하진 말라. </li>
<li>리팩토링의 목적은 다음 프로젝트가 아니라 이번 프로젝트를 빨리 끝내기 위한 것이다.</li>
<li>활발한 커뮤니케이션은 개발자에게 자주 말을 거는 것이 아니라 개발자에게 빨리 대답해주는 것이다.</li>
<li>회고에 많은 시간을 썼는데 다음 주기에 똑같이 일하고 있다면 회고한 시간은 순수한 낭비다. </li>
<li>애자일에 완벽하게 통달했다고 자부하기 전까지 스크럼은 하지 말라.</li>
</ol>
<p> </p>
<p>쉽게 요약하면, 하지마 하지마 하지마 정도가 되겠다...</p>
<p>원래 애자일은 체계적이고 <span style="text-decoration: line-through;">크고 아름다운</span> 방법론이 아니고 대충 막 개발하는 난장판식 개발에 더 가깝다. 난장판으로 놀면 이웃에 피해를 주니까 얌전하게 놀자는 게 아니라 맘 내키는대로 놀되 방음처리 잘해서 이웃 시끄럽게 하지 말고, 다 놀고 나서 깨끗이 잘 치우자는 게 애자일이다.</p>
<p>그러니까 대충 좀 해라 대충 좀. </p>
<p>
WikiNamu
영록이 홈페이지