Practice of an Agile Developer 2008 년  08 월
Scaling via Rational Unified Process (RUP) <ul><li>RUP Use Case Driven </li></ul><ul><li>RUP is really a process framework...
The Generic Agile Lifecycle
The Generic Agile Lifecycle
 
<ul><li>아무리 멀리 갔을지라도 잘못된 길이라면 ,  돌아오라 . -  터키속담 .  </li></ul>결과를 위해 일하라 땜질은 늪을 만든다 . 비난은 버그를 수정하지 못한다 .  손가락질하고 누구를 비난할지 토...
위험을 무릅쓰고 ,  앞으로 나아가라 리듬을 느끼라  <ul><li>올바른 일을 하라 .  </li></ul><ul><li>맡은 코드가 엿같다면 ,  불평대신에 바꾸었을때의 장단점을 상사에게  </li></ul><ul>...
변화에 뒤처지지 말라  팀에 투자하라 . <ul><li>기술 변화를 따라 가라 .  변화에 늘 대응하는것과 변화된것에 능숙해지는것은 다른이야기 .  변화에 능숙해지는데는 많은 시간이 걸린다 .  </li></ul><ul...
응집도 높은 코드를 작성하라  해결책 로그를 기록하자  <ul><li>클래스에 집중하고 컴포넌트를 작게 유지하라 .  클래스를 만들려고 결심했을때 ,  이 클래스가 다른 클래스와 비슷하거나 밀접하게 관련되어 있는지 스스...
코드를 릴리스할 수 있게 유지하라 수호천사를 곁에 두기 <ul><li>프로젝트를 항상 릴리스 가능하게 하라 체크인한 코드는 항상 바로 쓸수 있어야한다 .  자신이 만든 변경사항에 민감해야 하고 ,  자신이 시스템의 상태...
정규 대면회의를 가져라 <ul><li>스탠드 업 미팅을 사용하자 스탠드 업 미팅은 회의를 짧게 유지시켜주며 많은 장점이 있다 .  </li></ul><ul><ul><li>스탠드 업 미팅은 집중하는 방식으로 하루를 시작하...
<ul><li>밴캣 수브라마니암 저자 직강 ,  http://www.infoq.com/presentations/venkat-agile-practices-nfjs </li></ul>Reference
End of Document
Upcoming SlideShare
Loading in …5
×

애자일프랙티스

790 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
790
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 6 page style 로 가능한 한다 . 첫줄에 요약 비슷하게 . 오창환
  • 사내에 존재하는 다양한 이슈트래킹 Needs 중 팀장 /PM/ 실무자 측면의 Needs 를 살펴보겠습니다 . 팀장의 경우 팀원의 정확한 현재를 파악해야 하는 필요가 있습니다 . 어떤 일을 … 프로젝트팀원이 FunctionalManager 에 소속된 StrongMatrix/Composite Organization 의 PM 의 경우 프로젝트팀원이 운영업무를 제외한 프로젝트업무에 할당할 수 있는 시간을 정확하고 체계적으로 가늠할 수 있는 방법이 필요합니다 . 실무자의 경우 정확한 정보를 간결하게 적시에 필요인력에게 제공하고 제공받는 것이 필요함 . 메신저 쪽지 및 구두전달을 통한 업무요청보다는 체계적이고 이력관리가 되는 체계를 선호하며 , 요청부서장 또는 처리부서장의 업무의도에 맞게 적절한 통지체계가 필요하며 , 보고자와 담당자간에 예상작업기간 , 작업시작여부 , 작업완료여부 등의 적절한 통지체계를 필요로 함 .
  • 사내에 존재하는 다양한 이슈트래킹 Needs 중 팀장 /PM/ 실무자 측면의 Needs 를 살펴보겠습니다 . 팀장의 경우 팀원의 정확한 현재를 파악해야 하는 필요가 있습니다 . 어떤 일을 … 프로젝트팀원이 FunctionalManager 에 소속된 StrongMatrix/Composite Organization 의 PM 의 경우 프로젝트팀원이 운영업무를 제외한 프로젝트업무에 할당할 수 있는 시간을 정확하고 체계적으로 가늠할 수 있는 방법이 필요합니다 . 실무자의 경우 정확한 정보를 간결하게 적시에 필요인력에게 제공하고 제공받는 것이 필요함 . 메신저 쪽지 및 구두전달을 통한 업무요청보다는 체계적이고 이력관리가 되는 체계를 선호하며 , 요청부서장 또는 처리부서장의 업무의도에 맞게 적절한 통지체계가 필요하며 , 보고자와 담당자간에 예상작업기간 , 작업시작여부 , 작업완료여부 등의 적절한 통지체계를 필요로 함 .
  • 사내에 존재하는 다양한 이슈트래킹 Needs 중 팀장 /PM/ 실무자 측면의 Needs 를 살펴보겠습니다 . 팀장의 경우 팀원의 정확한 현재를 파악해야 하는 필요가 있습니다 . 어떤 일을 … 프로젝트팀원이 FunctionalManager 에 소속된 StrongMatrix/Composite Organization 의 PM 의 경우 프로젝트팀원이 운영업무를 제외한 프로젝트업무에 할당할 수 있는 시간을 정확하고 체계적으로 가늠할 수 있는 방법이 필요합니다 . 실무자의 경우 정확한 정보를 간결하게 적시에 필요인력에게 제공하고 제공받는 것이 필요함 . 메신저 쪽지 및 구두전달을 통한 업무요청보다는 체계적이고 이력관리가 되는 체계를 선호하며 , 요청부서장 또는 처리부서장의 업무의도에 맞게 적절한 통지체계가 필요하며 , 보고자와 담당자간에 예상작업기간 , 작업시작여부 , 작업완료여부 등의 적절한 통지체계를 필요로 함 .
  • 사내에 존재하는 다양한 이슈트래킹 Needs 중 팀장 /PM/ 실무자 측면의 Needs 를 살펴보겠습니다 . 팀장의 경우 팀원의 정확한 현재를 파악해야 하는 필요가 있습니다 . 어떤 일을 … 프로젝트팀원이 FunctionalManager 에 소속된 StrongMatrix/Composite Organization 의 PM 의 경우 프로젝트팀원이 운영업무를 제외한 프로젝트업무에 할당할 수 있는 시간을 정확하고 체계적으로 가늠할 수 있는 방법이 필요합니다 . 실무자의 경우 정확한 정보를 간결하게 적시에 필요인력에게 제공하고 제공받는 것이 필요함 . 메신저 쪽지 및 구두전달을 통한 업무요청보다는 체계적이고 이력관리가 되는 체계를 선호하며 , 요청부서장 또는 처리부서장의 업무의도에 맞게 적절한 통지체계가 필요하며 , 보고자와 담당자간에 예상작업기간 , 작업시작여부 , 작업완료여부 등의 적절한 통지체계를 필요로 함 .
  • 사내에 존재하는 다양한 이슈트래킹 Needs 중 팀장 /PM/ 실무자 측면의 Needs 를 살펴보겠습니다 . 팀장의 경우 팀원의 정확한 현재를 파악해야 하는 필요가 있습니다 . 어떤 일을 … 프로젝트팀원이 FunctionalManager 에 소속된 StrongMatrix/Composite Organization 의 PM 의 경우 프로젝트팀원이 운영업무를 제외한 프로젝트업무에 할당할 수 있는 시간을 정확하고 체계적으로 가늠할 수 있는 방법이 필요합니다 . 실무자의 경우 정확한 정보를 간결하게 적시에 필요인력에게 제공하고 제공받는 것이 필요함 . 메신저 쪽지 및 구두전달을 통한 업무요청보다는 체계적이고 이력관리가 되는 체계를 선호하며 , 요청부서장 또는 처리부서장의 업무의도에 맞게 적절한 통지체계가 필요하며 , 보고자와 담당자간에 예상작업기간 , 작업시작여부 , 작업완료여부 등의 적절한 통지체계를 필요로 함 .
  • 사내에 존재하는 다양한 이슈트래킹 Needs 중 팀장 /PM/ 실무자 측면의 Needs 를 살펴보겠습니다 . 팀장의 경우 팀원의 정확한 현재를 파악해야 하는 필요가 있습니다 . 어떤 일을 … 프로젝트팀원이 FunctionalManager 에 소속된 StrongMatrix/Composite Organization 의 PM 의 경우 프로젝트팀원이 운영업무를 제외한 프로젝트업무에 할당할 수 있는 시간을 정확하고 체계적으로 가늠할 수 있는 방법이 필요합니다 . 실무자의 경우 정확한 정보를 간결하게 적시에 필요인력에게 제공하고 제공받는 것이 필요함 . 메신저 쪽지 및 구두전달을 통한 업무요청보다는 체계적이고 이력관리가 되는 체계를 선호하며 , 요청부서장 또는 처리부서장의 업무의도에 맞게 적절한 통지체계가 필요하며 , 보고자와 담당자간에 예상작업기간 , 작업시작여부 , 작업완료여부 등의 적절한 통지체계를 필요로 함 .
  • 애자일프랙티스

    1. 1. Practice of an Agile Developer 2008 년 08 월
    2. 2. Scaling via Rational Unified Process (RUP) <ul><li>RUP Use Case Driven </li></ul><ul><li>RUP is really a process framework, not a process </li></ul><ul><li>RUP: </li></ul><ul><ul><li>Addresses the fully development lifecycle </li></ul></ul><ul><ul><li>Is risk-driven </li></ul></ul><ul><ul><li>Architecture-centric </li></ul></ul><ul><ul><ul><li>Fowler: UML modes </li></ul></ul></ul><ul><ul><ul><li>Reflection & communication </li></ul></ul></ul><ul><ul><ul><li>Inspiration or model </li></ul></ul></ul>
    3. 3. The Generic Agile Lifecycle
    4. 4. The Generic Agile Lifecycle
    5. 6. <ul><li>아무리 멀리 갔을지라도 잘못된 길이라면 , 돌아오라 . - 터키속담 . </li></ul>결과를 위해 일하라 땜질은 늪을 만든다 . 비난은 버그를 수정하지 못한다 . 손가락질하고 누구를 비난할지 토의하는 일은 생산적이지 못하다 . ' 좋아 , 내가 뭘 도와줄까 ?'. 문제를 해결하라고 노력하라 . <ul><li>소프트웨어 개발 프랙티스 </li></ul><ul><li>땜질식 수정에 빠지지 말라 . 땜질식 수정은 결국에는 프로젝트의 생명을 위협하는 늪을 조금씩 넓힌다 . 증상이 아니라 문제를 고쳐라 . </li></ul><ul><li>지뢰를 조심하라 : 진짜 문제를 해결하지 못한 어설픈 수정이 문제다 . </li></ul><ul><li>따로 코딩하지 말라 : 팀원들이 자신의 동료가 작성한 코드를 보는 시간 </li></ul><ul><li>을 갖아라 . </li></ul><ul><li>단위 테스트를 사용하라 : 단위테스트는 실행가능한 문서의 일종이다 . </li></ul>사람이 아니라 생각을 비판하라 <ul><li>사람이 아니라 아이디어를 비평하라 . 관심사를 말하기 위해 동료에게 질문하라 . 의견을 말하지 못하게 하는 분위기는 좋지 않다 . 부정적인 생각은 혁신을 죽인다 . </li></ul><ul><li>마감을 정하라 : 확고한 마감은 소모적 이데올로기 논쟁에 매달리지 </li></ul><ul><li>않게 한다 . </li></ul><ul><li>상대방과 논의하라 : 장단점을 비교하고 장점이 많고 단점이 적은 </li></ul><ul><li>해결책을 고른다 . </li></ul><ul><li>중재자를 둬라 . </li></ul><ul><li>결정을 지원하라 . </li></ul>엔지니어 프랙티스
    6. 7. 위험을 무릅쓰고 , 앞으로 나아가라 리듬을 느끼라 <ul><li>올바른 일을 하라 . </li></ul><ul><li>맡은 코드가 엿같다면 , 불평대신에 바꾸었을때의 장단점을 상사에게 </li></ul><ul><li>말해 올바른 해결책에 도달하도록 이유를 제시하라 . </li></ul><ul><li>쟁점에 대해 감정을 제거하고 문제해결에 고민해서 동료에게 솔직히 </li></ul><ul><li>고백하라 . 고객이나 상사에게 용기를 내어 당신의 관점을 설명하라 . </li></ul><ul><li>일이 쌓이기 전에 부딪쳐라 . </li></ul><ul><li>타임박싱 : 연장할 수 없는 활동에 대해 확고하고 짧은 마감을 정하는것 . </li></ul><ul><li>어떤 면에서 손해를 볼지 선택해야 하지만 , 마감은 고정 ! 확고한 마감이 </li></ul><ul><li>확고한 선택을 하게한다 ' </li></ul>일찍 , 자주 통합하라 <ul><li>일찍 , 자주 통합하라 통합하면서 격리할 수 있다 . 모의객체를 사용해서 코드를 의존성에서 분리하여 통합전에 테스트할 수 있다 . 격리해서 개발할때의 장점도 많다 . 하지만 이것이 통합을 늦추라는 말은 아니다 . 대규모 통합을 절대 받아들이지 말라 . </li></ul>실제 진척 상황을 측정하라 <ul><li>얼마나 많은 일이 남았는지 측정하라 . </li></ul><ul><li>진척상황을 잘 보이게 유지하는 가장 좋은 방법은 백로그를 남기는 방법이다 . 백로그는 완료해야 하는 작업목록인데 , 작업이 완료했을때 작업을 백로그에서 삭제한다 . 새로운 작업들이 생기면 우선순위를 부여해 백로그에 추가한다 . 백로그를 사용하면 , 다음에 해야할 중요한일을 항상 알 수 있다 . </li></ul>엔지니어 프랙티스
    7. 8. 변화에 뒤처지지 말라 팀에 투자하라 . <ul><li>기술 변화를 따라 가라 . 변화에 늘 대응하는것과 변화된것에 능숙해지는것은 다른이야기 . 변화에 능숙해지는데는 많은 시간이 걸린다 . </li></ul><ul><li>변화에 대응을 하면 , 능숙해져야하는 기술이 나타났을때 단숨에 많은 단계의 기술을 알필요가 없어 시간을 줄여 오히려 이익이다 . </li></ul><ul><li>반복해서 조금씩 배우자 : 규칙적 , 끊임없이 . </li></ul><ul><li>최신소식을 얻자 : 웹 / 포럼토론 / 메일링리스트 / 블로그 … </li></ul><ul><li>FT 를 적극 활용 / 참석하자 </li></ul><ul><li>캔미팅이나 학회에 참석하자 </li></ul><ul><li>열심히 읽자 </li></ul>여러분 자신과 팀에 대한 기대치를 높여라 . 팀이 교육이 잘된 팀이어야 효율이 오른다 . 배운 내용을 공유하면 ' 사용하는 지식 ' 이 되어 모두에게 좋다 . ' 규칙적 ' 이라는것과 ' 짧은시간 ' 포함된 수단인 교육은 좋다 . 이해할 때까지 질문하라 계속 왜냐고 물어보라 . 문제를 해결하기 위해서는 큰 그림을 보아야하고 , 연관된 사람에게의 질문을 통해 좀더 쉽게 접근할 수 있다 . 질문은 상대방의 생각을 정리하는데 도움을 줄 수 있다 . ' 왜 그런가 ?' 의 연속된 - 혹은 진실된 , 마치 값진 보물을 캐는것 같은 - 질문을 통해 진짜 문제를 찾아낼 수 있다 . 코드 리뷰 모든 코드를 리뷰하자 . 작업을 끝내면 코드리뷰를 하자 엔지니어 프랙티스
    8. 9. 응집도 높은 코드를 작성하라 해결책 로그를 기록하자 <ul><li>클래스에 집중하고 컴포넌트를 작게 유지하라 . 클래스를 만들려고 결심했을때 , 이 클래스가 다른 클래스와 비슷하거나 밀접하게 관련되어 있는지 스스로 묻자 . ' 단일 책임원칙에 따르면 모듈 변경에 대해서 단 한가지 이유만을 지녀야 한다 . </li></ul><ul><li>문제와 해결책의 로그를 보존하자 두번 불에 데지 않도록 발견한 해결책의 로그를 유지하자 . 컴퓨터 검색이 가능한 형식으로 로그를 기록하고 공유하자 . </li></ul>공동 소유를 실천하라 <ul><li>코드 공동 소유를 강조하자 . 작업마다 팀원을 순환시키면 팀의 전체적인 지식과 경험수준이 향상된다 . 장기적으로 코드를 주시하는 다수의 시선을 붐으로써 코드 전체 품질이 향상되고 유지보수와 이해가 더 쉬워지며 에러를 줄일수 있다 . </li></ul>멘토가 되자 <ul><li>멘토가 되자 . 아는것을 공유하는 즐거움을 누리자 . 얻은만큼 베풀자 . 더 나은 목표달성을 위해 다른 사람을 자극하자 . </li></ul>엔지니어 프랙티스
    9. 10. 코드를 릴리스할 수 있게 유지하라 수호천사를 곁에 두기 <ul><li>프로젝트를 항상 릴리스 가능하게 하라 체크인한 코드는 항상 바로 쓸수 있어야한다 . 자신이 만든 변경사항에 민감해야 하고 , 자신이 시스템의 상태와 팀 전체의 생산성에 영향을 준다는 사실을 계속 명심해야 한다 . </li></ul><ul><ul><ul><ul><li>로컬 테스트를 실행하라 . </li></ul></ul></ul></ul><ul><ul><ul><ul><li>최신 소스를 체크아웃하라 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>체크인 하라 </li></ul></ul></ul></ul><ul><li>지속적 통합시스템이 자동으로 문제를 지적하게 하라 . 시스템에 코드를 브랜치 할 수 있지만 조심해서 해야한다 . </li></ul>엔지니어 프랙티스 <ul><li>자동화된 단위테스트를 사용하라 컴파일 때마다 실행되는 로컬 단위테스트와 컴파일과 단위테스트를 실행하는 지속적인 빌드머신의 조합이 우리의 수호천사다 . 무언가 고장나면 즉시 알 수 있다 . </li></ul><ul><li>단위테스트로 즉각 피드백을 방는다 . </li></ul><ul><li>단위테스트는 코드를 강건하게 한다 . </li></ul><ul><li>단위테스트는 유용한 디자인 툴이 될 수 있다 . </li></ul><ul><li>단위테스트는 자신감을 증진시킨다 . </li></ul><ul><li>단위테스트는 프로브 역할을 할 수 있다 . </li></ul><ul><li>단위테스트는 믿을만한 문서다 . </li></ul><ul><li>단위테스트는 학습 도우미다 . </li></ul>유용한 에러 메시지를 제공하라 모든 예외를 처리하거나 전달하라 . 예외를 무시하거나 덮어두지말자 . 코드가 실패할 수 있다고 생각하며 작성하자 .
    10. 11. 정규 대면회의를 가져라 <ul><li>스탠드 업 미팅을 사용하자 스탠드 업 미팅은 회의를 짧게 유지시켜주며 많은 장점이 있다 . </li></ul><ul><ul><li>스탠드 업 미팅은 집중하는 방식으로 하루를 시작하게 한다 . </li></ul></ul><ul><ul><li>개발자에게 어떤 문제가 있다면 , 개발자는 이슈를 공공연하게 만들고 능 </li></ul></ul><ul><ul><li>동적으로 도움을 구할 기회를 얻는다 . </li></ul></ul><ul><ul><li>스탠드 업 미팅은 추가적인 도움이 필요한 분야를 결정하고 팀 리더나 </li></ul></ul><ul><ul><li>관리자가 인력을 얻거나 재할당하도록 한다 . </li></ul></ul><ul><ul><li>스탠드 업 미팅은 프로젝트의 다른 분야에서 무엇이 진행되고 있는지 </li></ul></ul><ul><ul><li>팀원이 인식하게 한다 . </li></ul></ul><ul><ul><li>스탠드 업 미팅은 다른 사람이 해결책을 갖고 있는 분야나 중복을 재빨리 </li></ul></ul><ul><ul><li>파악하도록 해준다 . </li></ul></ul><ul><ul><li>스탠드 업 미팅은 코드와 아이디어 공유를 촉진해서 개발을 가속시킨다 . </li></ul></ul><ul><ul><li>스탠드 업 미팅으 앞으로 나아가게 서로 북돋는다 . 즉 , 다른 사람이 진행 상황을 보고하는 것을 봄으로써 우리 각자가 같은 일을 하도록 동기를 부여한다 . </li></ul></ul>엔지니어 프랙티스
    11. 12. <ul><li>밴캣 수브라마니암 저자 직강 , http://www.infoq.com/presentations/venkat-agile-practices-nfjs </li></ul>Reference
    12. 13. End of Document

    ×