Practice of an Agile Developer

2008 년 08 월

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-drivenArchitecture-centric

• Fowler: UML modes• Reflection & communication• Inspiration or model

The Generic Agile Lifecycle

The Generic Agile Lifecycle

아무리 멀리 갔을지라도 잘못된 길이라면 , 돌아오라 . - 터키속담 .

결과를 위해 일하라

땜질은 늪을 만든다 .

비난은 버그를 수정하지 못한다 . 손가락질하고 누구를 비난할지 토의하는 일은 생산적이지 못하다 . ' 좋아 , 내가 뭘 도와줄까 ?'. 문제를 해결하라고 노력하라 .

• 소프트웨어 개발 프랙티스

땜질식 수정에 빠지지 말라 . 땜질식 수정은 결국에는 프로젝트의 생명을 위협하는 늪을 조금씩 넓힌다 . 증상이 아니라 문제를 고쳐라 .

• 지뢰를 조심하라 : 진짜 문제를 해결하지 못한 어설픈 수정이 문제다 . • 따로 코딩하지 말라 : 팀원들이 자신의 동료가 작성한 코드를 보는 시간 을 갖아라 .• 단위 테스트를 사용하라 : 단위테스트는 실행가능한 문서의 일종이다 .

사람이 아니라 생각을 비판하라

사람이 아니라 아이디어를 비평하라 . 관심사를 말하기 위해 동료에게 질문하라 . 의견을 말하지 못하게 하는 분위기는 좋지 않다 . 부정적인 생각은 혁신을 죽인다 .

• 마감을 정하라 : 확고한 마감은 소모적 이데올로기 논쟁에 매달리지 않게 한다 . • 상대방과 논의하라 : 장단점을 비교하고 장점이 많고 단점이 적은 해결책을 고른다 . • 중재자를 둬라 . • 결정을 지원하라 .

엔지니어 프랙티스

위험을 무릅쓰고 , 앞으로 나아가라

리듬을 느끼라

• 올바른 일을 하라 . • 맡은 코드가 엿같다면 , 불평대신에 바꾸었을때의 장단점을 상사에게 말해 올바른 해결책에 도달하도록 이유를 제시하라 . • 쟁점에 대해 감정을 제거하고 문제해결에 고민해서 동료에게 솔직히 고백하라 . 고객이나 상사에게 용기를 내어 당신의 관점을 설명하라 .

• 일이 쌓이기 전에 부딪쳐라 . • 타임박싱 : 연장할 수 없는 활동에 대해 확고하고 짧은 마감을 정하는것 . 어떤 면에서 손해를 볼지 선택해야 하지만 , 마감은 고정 ! 확고한 마감이 확고한 선택을 하게한다 '

일찍 , 자주 통합하라 •일찍 , 자주 통합하라 통합하면서 격리할 수 있다 . 모의객체를 사용해서 코드를 의존성에서 분리하여 통합전에 테스트할 수 있다 . 격리해서 개발할때의 장점도 많다 . 하지만 이것이 통합을 늦추라는 말은 아니다 . 대규모 통합을 절대 받아들이지 말라 .

실제 진척 상황을 측정하라

• 얼마나 많은 일이 남았는지 측정하라 . • 진척상황을 잘 보이게 유지하는 가장 좋은 방법은 백로그를 남기는 방법이다 . 백로그는 완료해야 하는 작업목록인데 , 작업이 완료했을때 작업을 백로그에서 삭제한다 . 새로운 작업들이 생기면 우선순위를 부여해 백로그에 추가한다 . 백로그를 사용하면 , 다음에 해야할 중요한일을 항상 알 수 있다 .

엔지니어 프랙티스

변화에 뒤처지지 말라

팀에 투자하라 .

기술 변화를 따라 가라 . 변화에 늘 대응하는것과 변화된것에 능숙해지는것은 다른이야기 . 변화에 능숙해지는데는 많은 시간이 걸린다 . 변화에 대응을 하면 , 능숙해져야하는 기술이 나타났을때 단숨에 많은 단계의 기술을 알필요가 없어 시간을 줄여 오히려 이익이다 .

• 반복해서 조금씩 배우자 : 규칙적 , 끊임없이 .• 최신소식을 얻자 : 웹 /포럼토론 /메일링리스트 /블로그 …• FT 를 적극 활용 /참석하자• 캔미팅이나 학회에 참석하자• 열심히 읽자

여러분 자신과 팀에 대한 기대치를 높여라 . 팀이 교육이 잘된 팀이어야 효율이 오른다 . 배운 내용을 공유하면 '사용하는 지식 ' 이 되어 모두에게 좋다 . ' 규칙적 ' 이라는것과 ' 짧은시간 ' 포함된 수단인 교육은 좋다 .

이해할 때까지 질문하라

계속 왜냐고 물어보라 . 문제를 해결하기 위해서는 큰 그림을 보아야하고 , 연관된 사람에게의 질문을 통해 좀더 쉽게 접근할 수 있다 . 질문은 상대방의 생각을 정리하는데 도움을 줄 수 있다 . '왜 그런가 ?' 의 연속된 - 혹은 진실된 , 마치 값진 보물을 캐는것 같은 - 질문을 통해 진짜 문제를 찾아낼 수 있다 .

코드 리뷰 모든 코드를 리뷰하자 . 작업을 끝내면 코드리뷰를 하자

엔지니어 프랙티스

응집도 높은 코드를 작성하라

해결책 로그를 기록하자

• 클래스에 집중하고 컴포넌트를 작게 유지하라 . 클래스를 만들려고 결심했을때 , 이 클래스가 다른 클래스와 비슷하거나 밀접하게 관련되어 있는지 스스로 묻자 . ' 단일 책임원칙에 따르면 모듈 변경에 대해서 단 한가지 이유만을 지녀야 한다 .

•문제와 해결책의 로그를 보존하자 두번 불에 데지 않도록 발견한 해결책의 로그를 유지하자 . 컴퓨터 검색이 가능한 형식으로 로그를 기록하고 공유하자 .

공동 소유를 실천하라 •코드 공동 소유를 강조하자 . 작업마다 팀원을 순환시키면 팀의 전체적인 지식과 경험수준이 향상된다 . 장기적으로 코드를 주시하는 다수의 시선을 붐으로써 코드 전체 품질이 향상되고 유지보수와 이해가 더 쉬워지며 에러를 줄일수 있다 .

멘토가 되자 •멘토가 되자 . 아는것을 공유하는 즐거움을 누리자 . 얻은만큼 베풀자 . 더 나은 목표달성을 위해 다른 사람을 자극하자 .

엔지니어 프랙티스

코드를 릴리스할 수 있게 유지하라

수호천사를 곁에 두기

프로젝트를 항상 릴리스 가능하게 하라 체크인한 코드는 항상 바로 쓸수 있어야한다 . 자신이 만든 변경사항에 민감해야 하고 , 자신이 시스템의 상태와 팀 전체의 생산성에 영향을 준다는 사실을 계속 명심해야 한다 .

• 로컬 테스트를 실행하라 .• 최신 소스를 체크아웃하라• 체크인 하라

지속적 통합시스템이 자동으로 문제를 지적하게 하라 . 시스템에 코드를 브랜치 할 수 있지만 조심해서 해야한다 .

엔지니어 프랙티스

자동화된 단위테스트를 사용하라 컴파일 때마다 실행되는 로컬 단위테스트와 컴파일과 단위테스트를 실행하는 지속적인 빌드머신의 조합이 우리의 수호천사다 . 무언가 고장나면 즉시 알 수 있다 .

• 단위테스트로 즉각 피드백을 방는다 . • 단위테스트는 코드를 강건하게 한다 .• 단위테스트는 유용한 디자인 툴이 될 수 있다 .• 단위테스트는 자신감을 증진시킨다 .• 단위테스트는 프로브 역할을 할 수 있다 .• 단위테스트는 믿을만한 문서다 .• 단위테스트는 학습 도우미다 .

유용한 에러 메시지를 제공하라

모든 예외를 처리하거나 전달하라 . 예외를 무시하거나 덮어두지말자 . 코드가 실패할 수 있다고 생각하며 작성하자 .

정규 대면회의를 가져라

스탠드 업 미팅을 사용하자 스탠드 업 미팅은 회의를 짧게 유지시켜주며 많은 장점이 있다 .

• 스탠드 업 미팅은 집중하는 방식으로 하루를 시작하게 한다 .• 개발자에게 어떤 문제가 있다면 , 개발자는 이슈를 공공연하게

만들고 능 동적으로 도움을 구할 기회를 얻는다 .• 스탠드 업 미팅은 추가적인 도움이 필요한 분야를 결정하고 팀

리더나 관리자가 인력을 얻거나 재할당하도록 한다 .• 스탠드 업 미팅은 프로젝트의 다른 분야에서 무엇이 진행되고

있는지 팀원이 인식하게 한다 .• 스탠드 업 미팅은 다른 사람이 해결책을 갖고 있는 분야나

중복을 재빨리 파악하도록 해준다 .• 스탠드 업 미팅은 코드와 아이디어 공유를 촉진해서 개발을

가속시킨다 .• 스탠드 업 미팅으 앞으로 나아가게 서로 북돋는다 . 즉 , 다른

사람이 진행 상황을 보고하는 것을 봄으로써 우리 각자가 같은 일을 하도록 동기를 부여한다 .

엔지니어 프랙티스

12

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

Reference

13

End of Document