에자일방법론 45가지원칙

작성날짜 : 2011-05-11

출처 : GIS 프로그래밍 연구소 | http://cafe.naver.com/gisdev | aliasgis
원문 : http://cafe.naver.com/gisdev/1767

책 구매 사이트 : http://kangcom.com/sub/view.asp?sku=200708130026

에자일 프랙티스
Agile Practice

1.비난은 버그를 수정하지 못한다.

손가락질 하는 대신, 가능한 해결책을 제시하라 중요한 것은 긍정적인 결과이다.

2.땜질식 수정에빠지지 말자

깔끔하고 모든 것이 드러나도록 코드에 정력을 쏟자.

3.사람이 아니라 아이디어를 비평하라.

누구 아이디어가 더나은지를 입증하는 것이 아니라 해결책에 도달하는 데에 자부심을 가져라

4.올바른일을 하라

정직하라.그리고 진실을 얘기할 용기를 가져라.때론 이렇게 한다는 것이 어려울 수도 있지만 그렇기 때문에 용기가 필요한 것이다.

5.기술변화를 따라가라.

모든분야에서 전문가가 될 필요는 없지만, 업계가 어디로 가는지 알고 있어야 하고, 그에 맞춰서 계획을 세워야 한다.

6.여러분 자신과 팀에 대한 기대치를 높여라

도시락 회의를 통하여 모든 사람의 지식과 숙련도를 올리고 사람들이 화합하게 하자. 즉, 팀이 흥미를 보이는 기술이나 프로젝트를 이롭게 할 기술을 도입하자.

7.새로운 기술을 배우고 예전 기술을 버려라

새기술을 배울 때, 여러분을 방해 할 낡은 습관을 버려라. 결국 구형차보다 새차가 훨씬 낮다.

8.계속왜냐고 물어보라

여러분이 들은 얘기들을 액면그대로 받아들이지마라. 쟁점이 되는 내용의 핵심을 이해할 때까지 계속 질문하라

9.일이 쌓이기 전에 부딪쳐라

사건들사이에 꾸준하고 반복적인 간격을 유지해야 일상적으로 되풀이 되는 일을 해결하기 쉽다.

10.고객이 결정하도록하라.

개발자,관리자, 비즈니스 애널리스트가 비즈니스에 치명적인 결정을 내려서는 안된다. 사업주가 이해할수 있는언어로 세부내용을 설명하고 사업주가 결정할 수 있도록 한다.

11.좋은 설계는 지도다.

설계는 바른 방향으로 인도한다. 그것은 허물 수 없는 경계가 아니다. 특정한 방식을 강요 해서는 안된다. 여러분은 설계(혹은 설계자) 에게 인질로 잡혀서는 안된다.

12. 필요에 따라 기술을 택하라

먼저 무엇이 필요한지 정하라. 그리고나서 특별한문제에 기술사용여부를 판단하라.어떤 기술의 사용에 결정적인 질문을하고 진실하게 답해보라

13. 프로젝트를 항상 릴리스 가능하게 하라

프로젝트를 항상 컴파일 할 수 있고, 실행할 수 있으며, 테스트 하고 당장에 배치 할 수 있게하자.

14.일찍, 자주 통합하라.

코드 통합은 주요 위험요인이다. 이 위험을 완화 시키려면, 일찍통합하고 규칙적으로 계속 통합해야한다.

15. 시작부터 어플리케이션을 자동배치하라

의존성 테스트를 위해 다양한 구성의 머신에 어플리케이션을 설치 할 때, 이자동배치를 사용하라. 품질보증은 어플리케이션 뿐 아니라 배치를 테스트 해야 한다.

16. 분명히 보이게 하라.

어플리케이션이 개발도중 항상 눈에 띄게 하고, 고객이 마음에 들게 하라. 고객과 접촉하고 매주 또는 2주에 한번씩 데모를 사용하여 피드백을 미리 구하라

17.점진적으로 개발하라

최초의 유용한 기능단위로 묶어서 제품을 릴리스 하라. 각 추가 기능의 개발에 1~4주 정도의 반복주기를 사용 하라

18. 실제일을 기초로 해서 견적하라.

실질적인 견적을 내기위해 팀이 현재프로젝트를 고객과 함께 수행하도록 하라. 고객이 기능과 예산을 조절하도록 하라.

19. 자동화 된 단위테스트를 사용하라

좋은 단위 테스트는 문제를 즉시 경고한다. 견고한 단위테스트는 자리 잡지 않았다면 설계나 코드 변경을 하지 말자.

20. 만들기전에 사용하라.

테스트 주도 개발을 설계툴로써 사용하자.테스트 주도 개발은 여러분을 더 실용적이고 더 간단한 설계로 인도할 것이다.

21.차이는 결과를 만든다.

지속적 통합 툴을 사용해서, 지원하는 플랫폼과 환경의 조합마다 단위테스트를 실행하자. 문제가 여러분을 부르기 전에 능동적으로 문제를 찾자.

22.핵심 비즈니스로직에 해당하는 테스트를 만들자.

고객이 이러한 테스트를 격리해서 검증하게 하고, 일부러 이러한 테스트를 자동적으로 시험하게 하자

23. 얼마나 많은 일이 남았는지 측정하라.

현실성이 떨어지는 측정기준으로 자신이나 팀을 기만하지말자. 해야할 작업의 백로그를 측정하자

24. 모든 불평은 진실을 담고 있다.

진실을 찾아 , 진짜문제를 해결하라

25. 독창적이지 않고, 명확하게 코드를 작성하자.

코드를 읽는 사람에게 의도를 명확하게 표현하자. 읽기 쉽지않은 코드는 독창적이지도 않다.

26.이야기하는 주석

잘고르고, 의미 있는 이름을 사용해서 코드를 문서화 하라. 메서드의 목적과 제한조건을 설명하는 주석을 사용하라. 좋은코드를 대신하려고 주석을 사용하지말자.

27.능동적으로 트레이드 오프를 평가하자

성능, 편의성, 생산성, 비용, 적시 릴리스를 고려하자. 성능이 적당하면, 다른요소를 향상 시키는 데 집중하자. 하찮거나 미미한 성능이나 우아함을 위해서 성능을 복잡하게 하지 말자.

28.짧은 수정/빌드/테스트 주기 안에서 코드를 작성하자.

긴 주기동안 코딩을 하는 것보다 짧은 주기에서 코딩을 하는 편이 더 낫다. 유지보수 하는 데 더 명확하고 간단하면 쉬운코드를 만들 것이다.

29. 동작하는 가장 단순한 해결책을 만들자

패턴,원칙, 기술을 사용해야 하는 부득이 한 사정이 있을 때만 패턴,원칙, 기술을 포함하자

30. 클래스에 집중하고 컴포넌트를 작게 유지해라.

커다란 클래스나 컴포넌트 혹은 다방면에서 잡다한 클래스를 만들고픈 유혹을 피하라.

31. 묻지말고, 말해라

다른 객체나 컴포넌트의일을 떠맡지 마라. 객체나 컴포넌트에 무엇을 하는지 알리고 , 자신의 일에 충실해라

32. 코드를 교체해서 시스템을 확장하자

인터페이스계약을 존중하는 클래스를 교체해서 기능을 추가 하거나 강화하자.위임은 언제나 상속보다 바람직하다.

33. 문제와 해결책의 로그를 보존하자.

문제를 해결하는일의 일부는 나중에 해결책을 찾고 적용할 수 있도록 해결책의 상세내용을 보존하는 것이다.

34. 경고를 에러처럼다루자

경고가 있는 코드를 체크인 하는 것은 에러가 있는코드나 테스트에 실패한코드를 체크인

한 만큼 나쁘다.체크인한 코드는 빌드툴에서 어떤에러도 만들어서는 안된다.

35. 문제를 격리해서 공격하라

문제를 해결할 때 문제를 주위와 분리시켜라. 특히 큰 애플리케이션의 경우에 말이다.

36.모든예외를 처리하거나 전달하라

예외를 덮어두지말자.임시라도 말이다. 코드가 실패할 수 있다고 생각하며 작성하자

37. 유용한 에러메시지를 제공하자

에러의 상세내용을 알아내기 쉬운 방법을 제공하자.문제가 생겼을 때 문제에대해서 할 수 있는 많은자원과 관련된 상세정보를 제공하라, 그렇지만 이정보와 함께 사용자를 파묻지말자

38. 스탠드 업 미팅을 사용하자.

스탠드 업미팅은 팀을 같은 곳에 둔다. 회의를 일상적이면서 짧고, 집중적으로 유지하자

39. 좋은디자인은 활동적인 프로그래머로부터 진화 한다.

진짜 통찰력은 활동적인 코딩작업에서 나온다. 코드를 작성하지않은 아키텍트를 기용하지말자. 시스템의 현실을 알지못하는 아키텍트는 설계를 할 수 없다.

40. 코드 공동소유를 강조하자

개발자들을 순환시켜 전체시스템의 다른 영역에 있는 서로 다른 모듈이나 테스크를 교차해서 개발 시키자.

41. 멘토가 되자

아는 것을 공유하는데 즐거움이 있다. 얻은 만큼 베풀어라 더나은 목표를 달성하기 위해서 다른 사람을 자극하자. 팀의 전체적인 역량을 향상시키자.

42. 다른 사람에게 문제를 해결할 기회를 주자.

다른 사람에게 해결책을 주는 대신에 올바른 방향을 알려주자. 그 과정에서 모두 먼가를 배울 수 있다.

43. 준비되었을 때만 코드를 공유하라

다른 사람이 쓸 수 있도록 준비 되지않은 코드는 절대체크인 하지마라. 컴파일이 안되거나 단위테스트를 통과하지 못한 코드를 체크인 하는 것은 프로젝트의 범죄적인 태만해위로 간주해야 한다.

44.모든 코드를 리뷰하자

코드리뷰는 코드 품질을 개선하고 에러를 낮추는 데 매우 가치 있는 것이다. 코드리뷰를 올바르게 했다면 , 리뷰는 실용적이고 효과적 일 수 있다. 다른 개발자로 하여금 작업이 끝날때마다 코드리뷰를 하게 하자

45.다른 사람에게 계속해서 알리자

여러분이 조사한 좋은자료나 자신의 상황. 아이디어를 발표하자. 다른 사람이 일의 상황을 물을 때까지 기다리지 말자