애자일 프래티스

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.   능동적으로 트레이드오프를 평가하자.
성능, 편의성, 생산성, 비용, 적시 릴리스를 고려하자. 성능이 적당하면, 다른 요소를 향상시키는데 집중하자. 하찮거나 미미한 성능이나 우아함을 위해서 디자인을 복잡하게 하지 말자.

  참고 사이트
http://groups.google.com
http://www.objectmentor.com/resources/articles/ocp.pdf