1. Practice of an Agile Developer 2008 년 08 월

2. Scaling via Rational Unified Process (RUP) RUP Use Case Driven RUP is really a process framework, not a process RUP: Addresses the fully development lifecycle Is risk-driven Architecture-centric Fowler: UML modes Reflection & communication Inspiration or model

3. The Generic Agile Lifecycle

4. The Generic Agile Lifecycle

6. 아무리 멀리 갔을지라도 잘못된 길이라면 , 돌아오라 . - 터키속담 . 결과를 위해 일하라 땜질은 늪을 만든다 . 비난은 버그를 수정하지 못한다 . 손가락질하고 누구를 비난할지 토의하는 일은 생산적이지 못하다 . ' 좋아 , 내가 뭘 도와줄까 ?'. 문제를 해결하라고 노력하라 . 소프트웨어 개발 프랙티스 땜질식 수정에 빠지지 말라 . 땜질식 수정은 결국에는 프로젝트의 생명을 위협하는 늪을 조금씩 넓힌다 . 증상이 아니라 문제를 고쳐라 . 지뢰를 조심하라 : 진짜 문제를 해결하지 못한 어설픈 수정이 문제다 . 따로 코딩하지 말라 : 팀원들이 자신의 동료가 작성한 코드를 보는 시간 을 갖아라 . 단위 테스트를 사용하라 : 단위테스트는 실행가능한 문서의 일종이다 . 사람이 아니라 생각을 비판하라 사람이 아니라 아이디어를 비평하라 . 관심사를 말하기 위해 동료에게 질문하라 . 의견을 말하지 못하게 하는 분위기는 좋지 않다 . 부정적인 생각은 혁신을 죽인다 . 마감을 정하라 : 확고한 마감은 소모적 이데올로기 논쟁에 매달리지 않게 한다 . 상대방과 논의하라 : 장단점을 비교하고 장점이 많고 단점이 적은 해결책을 고른다 . 중재자를 둬라 . 결정을 지원하라 . 엔지니어 프랙티스

7. 위험을 무릅쓰고 , 앞으로 나아가라 리듬을 느끼라 올바른 일을 하라 . 맡은 코드가 엿같다면 , 불평대신에 바꾸었을때의 장단점을 상사에게 말해 올바른 해결책에 도달하도록 이유를 제시하라 . 쟁점에 대해 감정을 제거하고 문제해결에 고민해서 동료에게 솔직히 고백하라 . 고객이나 상사에게 용기를 내어 당신의 관점을 설명하라 . 일이 쌓이기 전에 부딪쳐라 . 타임박싱 : 연장할 수 없는 활동에 대해 확고하고 짧은 마감을 정하는것 . 어떤 면에서 손해를 볼지 선택해야 하지만 , 마감은 고정 ! 확고한 마감이 확고한 선택을 하게한다 ' 일찍 , 자주 통합하라 일찍 , 자주 통합하라 통합하면서 격리할 수 있다 . 모의객체를 사용해서 코드를 의존성에서 분리하여 통합전에 테스트할 수 있다 . 격리해서 개발할때의 장점도 많다 . 하지만 이것이 통합을 늦추라는 말은 아니다 . 대규모 통합을 절대 받아들이지 말라 . 실제 진척 상황을 측정하라 얼마나 많은 일이 남았는지 측정하라 . 진척상황을 잘 보이게 유지하는 가장 좋은 방법은 백로그를 남기는 방법이다 . 백로그는 완료해야 하는 작업목록인데 , 작업이 완료했을때 작업을 백로그에서 삭제한다 . 새로운 작업들이 생기면 우선순위를 부여해 백로그에 추가한다 . 백로그를 사용하면 , 다음에 해야할 중요한일을 항상 알 수 있다 . 엔지니어 프랙티스

8. 변화에 뒤처지지 말라 팀에 투자하라 . 기술 변화를 따라 가라 . 변화에 늘 대응하는것과 변화된것에 능숙해지는것은 다른이야기 . 변화에 능숙해지는데는 많은 시간이 걸린다 . 변화에 대응을 하면 , 능숙해져야하는 기술이 나타났을때 단숨에 많은 단계의 기술을 알필요가 없어 시간을 줄여 오히려 이익이다 . 반복해서 조금씩 배우자 : 규칙적 , 끊임없이 . 최신소식을 얻자 : 웹 / 포럼토론 / 메일링리스트 / 블로그 … FT 를 적극 활용 / 참석하자 캔미팅이나 학회에 참석하자 열심히 읽자 여러분 자신과 팀에 대한 기대치를 높여라 . 팀이 교육이 잘된 팀이어야 효율이 오른다 . 배운 내용을 공유하면 ' 사용하는 지식 ' 이 되어 모두에게 좋다 . ' 규칙적 ' 이라는것과 ' 짧은시간 ' 포함된 수단인 교육은 좋다 . 이해할 때까지 질문하라 계속 왜냐고 물어보라 . 문제를 해결하기 위해서는 큰 그림을 보아야하고 , 연관된 사람에게의 질문을 통해 좀더 쉽게 접근할 수 있다 . 질문은 상대방의 생각을 정리하는데 도움을 줄 수 있다 . ' 왜 그런가 ?' 의 연속된 - 혹은 진실된 , 마치 값진 보물을 캐는것 같은 - 질문을 통해 진짜 문제를 찾아낼 수 있다 . 코드 리뷰 모든 코드를 리뷰하자 . 작업을 끝내면 코드리뷰를 하자 엔지니어 프랙티스

9. 응집도 높은 코드를 작성하라 해결책 로그를 기록하자 클래스에 집중하고 컴포넌트를 작게 유지하라 . 클래스를 만들려고 결심했을때 , 이 클래스가 다른 클래스와 비슷하거나 밀접하게 관련되어 있는지 스스로 묻자 . ' 단일 책임원칙에 따르면 모듈 변경에 대해서 단 한가지 이유만을 지녀야 한다 . 문제와 해결책의 로그를 보존하자 두번 불에 데지 않도록 발견한 해결책의 로그를 유지하자 . 컴퓨터 검색이 가능한 형식으로 로그를 기록하고 공유하자 . 공동 소유를 실천하라 코드 공동 소유를 강조하자 . 작업마다 팀원을 순환시키면 팀의 전체적인 지식과 경험수준이 향상된다 . 장기적으로 코드를 주시하는 다수의 시선을 붐으로써 코드 전체 품질이 향상되고 유지보수와 이해가 더 쉬워지며 에러를 줄일수 있다 . 멘토가 되자 멘토가 되자 . 아는것을 공유하는 즐거움을 누리자 . 얻은만큼 베풀자 . 더 나은 목표달성을 위해 다른 사람을 자극하자 . 엔지니어 프랙티스

10. 코드를 릴리스할 수 있게 유지하라 수호천사를 곁에 두기 프로젝트를 항상 릴리스 가능하게 하라 체크인한 코드는 항상 바로 쓸수 있어야한다 . 자신이 만든 변경사항에 민감해야 하고 , 자신이 시스템의 상태와 팀 전체의 생산성에 영향을 준다는 사실을 계속 명심해야 한다 . 로컬 테스트를 실행하라 . 최신 소스를 체크아웃하라 체크인 하라 지속적 통합시스템이 자동으로 문제를 지적하게 하라 . 시스템에 코드를 브랜치 할 수 있지만 조심해서 해야한다 . 엔지니어 프랙티스 자동화된 단위테스트를 사용하라 컴파일 때마다 실행되는 로컬 단위테스트와 컴파일과 단위테스트를 실행하는 지속적인 빌드머신의 조합이 우리의 수호천사다 . 무언가 고장나면 즉시 알 수 있다 . 단위테스트로 즉각 피드백을 방는다 . 단위테스트는 코드를 강건하게 한다 . 단위테스트는 유용한 디자인 툴이 될 수 있다 . 단위테스트는 자신감을 증진시킨다 . 단위테스트는 프로브 역할을 할 수 있다 . 단위테스트는 믿을만한 문서다 . 단위테스트는 학습 도우미다 . 유용한 에러 메시지를 제공하라 모든 예외를 처리하거나 전달하라 . 예외를 무시하거나 덮어두지말자 . 코드가 실패할 수 있다고 생각하며 작성하자 .

11. 정규 대면회의를 가져라 스탠드 업 미팅을 사용하자 스탠드 업 미팅은 회의를 짧게 유지시켜주며 많은 장점이 있다 . 스탠드 업 미팅은 집중하는 방식으로 하루를 시작하게 한다 . 개발자에게 어떤 문제가 있다면 , 개발자는 이슈를 공공연하게 만들고 능 동적으로 도움을 구할 기회를 얻는다 . 스탠드 업 미팅은 추가적인 도움이 필요한 분야를 결정하고 팀 리더나 관리자가 인력을 얻거나 재할당하도록 한다 . 스탠드 업 미팅은 프로젝트의 다른 분야에서 무엇이 진행되고 있는지 팀원이 인식하게 한다 . 스탠드 업 미팅은 다른 사람이 해결책을 갖고 있는 분야나 중복을 재빨리 파악하도록 해준다 . 스탠드 업 미팅은 코드와 아이디어 공유를 촉진해서 개발을 가속시킨다 . 스탠드 업 미팅으 앞으로 나아가게 서로 북돋는다 . 즉 , 다른 사람이 진행 상황을 보고하는 것을 봄으로써 우리 각자가 같은 일을 하도록 동기를 부여한다 . 엔지니어 프랙티스

12. 밴캣 수브라마니암 저자 직강 , http://www.infoq.com/presentations/venkat-agile-practices-nfjs Reference

13. End of Document