내게 말해보라. 그러면 잊어버릴 것이다.
내게 보여주라. 그러면 기억할지도 모른다.
나를 참여시켜라. 그러면 이해할 것이다.
- 필립 코틀러, ‘마켓 3.0’에서 인용한 중국 속담
그래서 인가요. 교육할때 보면 강의시간에 집중을 잘 못하던 친구들도 다 같이 참여해서 뭔가를 만들고 이야기 하라고 하면 곧잘 따라 합니다. (제 강의 스킬이 부족해서 일수도 ^^)
가끔 삼천포로 빠져서 넋두리와 재테크에 대한 이야기로 꽃을 피우긴 하지만 참여형 교육이 확실히 좋은거 같습니다.
스크럼에서의 추정은 크게 두가지 입니다. - 사용자 스토리에 대한 포인트, 태스크에 대한 시간
이중 태스크 시간은 개발자에 따라 변동이 커서 신뢰도가 떨어집니다. 물론 팀으로 추정한다거나 표준 시간을 정해준다거나 하면 좀 나아지기도 합니다.
기왕 그렇다면 차라리 태스크 시간을 같은 시간으로 고정시키는건 어떨까요? 보통 8시간 근무니까 4시간짜리 2개 태스크로 정해주는것도 나쁘지 않을거 같습니다.
그러다가 태스크를 상세히 정할 단계가 되면 더 세분화 할 수 있게 해주는거죠.
시간별로 포스트잇을 다양화 해서 시간이 많이 걸리는 태스크가 무엇인지 바로 알아차릴 수 있게 하는것도 좋을듯 합니다.
테스트 코드를 만들때 가장 많은 비용이 드는 부분은 테스트 데이터를 만드는 부분입니다. 테스트 데이터 관련 작업을 정리해 보면 다음과 같습니다.
테스트를 위한 데이터베이스 준비하기
초기 데이터 입력하기
테스트 코드를 실행하기 위한 입력 데이터 준비하기
테스트가 실행된후 데이터 초기화 하기
이중 실행을 위한 입력 데이터를 효과적으로 만드는 방법을 소개합니다.
메소드 파라미터 타입에 맞는 정적 데이터를 미리 준비하고, 이를 랜덤하게 조합하여 사용하는 것 입니다.
단순히 String name = "abc" 정도의 데이터를 생성하는 것으로는 부족합니다. 가능하면 도메인에 맞는 데이터를 입력해 주어야 합니다. 미리 "Sangchel", "Scott", "Hillery" 등의 데이터를 준비해 놓고 매번 다른 데이터를 이용하도록 한다면 좀 더 현실적인 테스트 데이터를 만들어 줄 수 있다고 생각합니다.
단위테스트를 만들때 DB나 File과 같은 IO와 엮이게 되면 여러가지 문제가 뒤따릅니다. 그래서 이런 이슈를 해소하기 위해 Mock객체를 만들어서 테스트코드와 환경을 분리(isolation)하게 됩니다.
지난주 유럽 CITCON에서 Freeman은 목 객체에 대한 생각을 레베카의 Roles, Responsibilities and Collaborations object design school에서 영감을 얻었다고 발표했습니다.
그는 Mock객체를 단순히 분리를 위해서 사용하지 말고 디자인을 위해서 사용하라고 충고합니다.
인터페이스는 호출할 메소드만을 나타내기 때문에 객체를 명세하는데 충분하지 않다. 언제 어떻게 호출하는지는 알려주지 않는다. 그래서 목 객체가 필요한 것이다.
목객체를 만드는 나쁜 경우는 표준 자바 라이브러리를 목으로 만드는 경우라고 합니다. 더 자세한건 링크를 참고하세요.
Ken Schwaber, co-creator of Scrum, says publicly that perhaps only 25% of
Scrum teams get the full benefit of Scrum. Jeff Sutherland, the other
co-creator, says publicly that all the high-performance Scrum teams he has
seen used XP-style practices.In those two sentences, we see a problem, and
part of a solution. Ken Schwaber has the Scrum Alliance working on a
possible Certified Scrum Developer program.
스크럼의 공동 저자인 켄 슈와버는 스크럼의 모든 이점을 얻게되는 스크럼 팀은 아마도 25% 정도밖에 되지 않는다고 공공연하게 말합니다. 제프 서덜렌드, 다른 저자도 높은 성과를 내는 스크럼팀은 모두 XP 스타일의 기법들을 사용한다고 공공연히 말합니다. 이 두가지 시나리오를 살펴보면 문제가 뭐고 이 문제의 해결책 이 무엇인지가 자명해 집니다. 켄 슈와버는 공인 스크럼 개발자 프로그램을 만들기 위해 스크럼 연합에서 작업을 진행중에 있습니다.
며칠전 프로젝트에서 스크럼을 적용하느라 고군분투중인 후배와 이와 비슷한 이야기를 나눴습니다.
스크럼이 처음 도입되면 사람들은 이를 환영하면서 새로운 방식에 열광합니다. 백로그를 작성하고 매 스프린트마다 이슈가 해결되는것을 보면서 기뻐하죠. 회고는 사람들을 새롭게 만듭니다.
하지만...프로젝트가 중반으로 달려가며 점점 많은 이슈가 등장합니다. 그러면서 사람들은 새로운 방식==스크럼의 한계를 느끼게 됩니다. 또 무언가 처음처럼 새로운 것을 기대하게 됩니다.
이때 스크럼의 틀 만으로는 부족합니다. 이때 부터는 XP의 기법들이 하나 둘씩 뒷받침 되어야 합니다. 습관이란것은 무섭습니다. 힘들고 어려운일을 당하면 바로 예전 방식에 대한 향수를 느끼고 회귀하게 됩니다.
제품 백로그를 구성하는 사용자 스토리를 우선순위에 따라 정렬하는건 중요합니다. 그럼 어떻게 우선순위를 매기는게 적절할까요? 발표에 앞서 마이크콘은 비즈니스 관점에서의 제품 백로그의 가치를 강조합니다. 제품 백로그에는 한 스프린트에 대한 항목뿐만 아니라 전체 릴리즈될 범위까지 들어있으며 이들에 대한 우선순위는 비즈니스 관점에서 결정되어야 합니다.
사용자 스토리와 관련해서 세가지 용어가 등장합니다.
사용자 스토리(User Story): 사용자나 고객관점에서 원하는 기능에 대한 명세
테마(Theme): 관련있는 사용자 스토리의 집합
에픽(Epic): 큰 사용자 스토리
왜 테마가 필요할까요? 사용자 스토리를 특정 테마를 기준으로 우선순위를 정하게 되면 서로 반하게 우선순위가 매겨지는걸 피할 수 있습니다. 예를 들어 보겠습니다.
자동차에서 발 뻗는 곳의 크기와 엔진룸의 크기중 어느 것이 더 중요할까요 ? 이런 내용을 그냥 판단하기는 어렵습니다. 어떤 비즈니스 적인 입장에서 보느냐에 따라 그 중요성은 달라지기 때문입니다.
비즈니스 가치를 고려하여 우선순위를 정하는 방법에 대해 알아 보겠습니다.
Theme Screening
Theme Scoring
Relative Weighting
Kano analysis
1.Theme Screening
스텝1: 다름 릴리즈에 중요한 테마를 5-9개 선정합니다.
스텝2: 베이스 라인 테마를 정합니다.
스텝3: 베이스 라인 테마를 기준으로 다른 테마를 상대적으로 평가합니다.
2.Theme scoring
스텝1: 테마에 대한 가중치를 매긴다.
스텝2: 각 판단기준(Criteria)에 대한 베이스 라인 테마를 매번 설정한다.
스텝3: 베이스라인 테마를 기준으로 각 판단기준별로 점수를 매긴다.
3.Relative Weighting
스텝1: 테마나 스토리의 이익을 1~9 사이의 숫자로 평가한다.
스텝2: 테마나 스토리의 손실을 1~9 사이의 숫자로 평가한다.
스텝3: 위 값을 이용하여 전체 테마나 스토리의 가치를 계산한다.
스텝4: 각 테마에 대한 추정치를 정한다.
스텝5: 추정치를 이용해 비용 비율을 계산한다.
스텝6: 우선순위를 결정한다.
4.Kano Analysis
사용자가 원하는 기능을 세가지 타입으로 정리하여 평가하는 방법
Exciters/Delighters: 사용자가 보기 전까지는 원하는지를 알지 못하는 기능
Linear: 있으면 있을수록 좋은 기능
Mandatory/Baseline: 반드시 있어야 하는 기능
마지막에 들은 Kano Analysis는 어떻게 정량적인 숫자로 연결되는지 좀 헷갈리네요. 제대로 이해하려면 더 찾아봐야 할거 같습니다. 첫번째 세션에서는 백로그에 대한 비즈니스 관점의 우선순위를 정량적으로 결정하는 방법에 대해 배운게 유용한거 같습니다. 마이크콘은 농담도 섞어 가며 강의를 재밌게 잘하는거 같습니다.
컨퍼런스 첫날입니다. 호텔에서 후딱 아침을 먹고 8시30분쯤 컨퍼런스 등록을 위해 Hyatt Regency Chicago 호텔 지하 2층으로 향했습니다. 왼쪽에 있는 부스에 이름을 대니 명찰과 식권, 프로그램 및 티셔츠를 교환할 수 있는 교환권을 나눠주네요.
그걸 들고 오른쪽으로 가니 큼지막한 가방에 뭘 잔뜩 넣어서 줍니다.
(사실 비회원 참가비용이 $1800, 217만원니까 매우 비싼 컨퍼런스 입니다.)
잡다한 홍보물품을 빼고 나니 남은건 컨퍼런스 프로그램, 논문집, 그리고 책이 두권입니다.(일단 책은 하나 건졌습니다.^^) 홍보성 책인줄 알았더니 Becoming Agile은 5월에 출간된 아마드 시드키 Ahmed Sidky의 신간이네요.
9시부터 세션이 시작되는 줄 알았는데 가보니 아무도 없습니다. 프로그램에는 한개 세션이 예정되어 있었는데 취소된거 같습니다. 결국 11시부터 제대로 된 세션이 열리기 시작했고 첫날 제가 들은 세션은 다음 3개 입니다.
11:00~12:30 Prioritrizing Your Product Backlog, Mike Cohn
14:00~15:30 XUnit Test Patterns and Smells, Gerard Meszaros
16:00~17:30 Zen and the Art of Software Quality, Jim Highsmith
Agile 2009 컨퍼런스를 듣기 위해 이곳, 미국 시카고에 도착했습니다. 미국 출장은 두번째지만 시카고는 처음입니다.
컨퍼런스 시작은 월요일인데 호텔로비에 있다보니 컨퍼런스 관련한 사람들이 속속 체크인 하는게 보입니다. 제가 체크인 할때 앞에 눈에 많이 익은 분이다 했더니 Agile Software Development in Large의 Jutta Eckstein 이더군요. (책과 같은 제목의 세션을 작년 xp 2008에 들어서 기억합니다.)
컨퍼런스가 열리는 Hyatt Regency Chicago 호텔은 정말 좋은 위치에 있는 비싼 호텔입니다. 전 컨퍼런스 할인만 믿고 덜컥 호텔을 정했다가 오자마자 부랴부랴 다른 싼 호텔로 옮겼습니다. (인터넷 하루 쓰는데 13달러니 뭐 딴거야..^^;;)
다른 일로라도 시카고 오셔야 하는데 괜찮은 호텔 원하시면 제가 지낸 Comfort suite Chicago를 추천합니다. 두명 자는데 140불(주중가격, 주말에는 170불)정도인데 방도 크고 깨끗하네요. 이 방만 그런건지 모르겠지만 부엌에 세탁기까지 있어서 호텔의 다른 시설을 거의 사용안하는 저에게는 정말 좋네요.
일리노이주에 위치한 시카고는 미국 제3의 도시로 '미국의 건축박물관'이라 불리는 도시입니다. 8월의 날씨는 약 17~28도 정도로 한국의 가을날씨와 비슷한데 햇살이 너무 강해서 선글라스 없으면 눈을 못뜰 정도입니다.
유명인사(?)로는 알카포네, 농구팀 시카고 불스, 시카고 컵스는 염소의 저주로 월드시리즈 우승 못하기로 유명한 팀이죠. :-)
옆 지도에 표시된 곳이 컨퍼런스 장소인데 시카고 시내 중심에 있어서 관광지를 걸어서 둘러보기에 딱 좋습니다. (작아서 안보일뿐 옆 지도에 시내주요 관광지가 들어있음)
시카고의 대중 교통도 대체로 잘 되어 있다고 합니다. 버스와 지하철 노선이 시내 곳곳을 연결하고 있고 정류장이나 버스도 깨끗해서 시내만 다닌다면 차를 빌리지 않아도 될거라고 하네요.
이 곳에는 시카고 시티패스라는게 있습니다. 9일내에 주요한 다섯개 박물관 입장이 가능하며 줄을 서지않고 입장할 수 있어서 단 시간에 여러 곳을 보고자 할때 편리합니다. 제가 오늘 돌아본 코스입니다.
밀레니엄 파크(Millennium Park) -> 버킹엄분수(Buckingham Memorial Fountain) -> 필드자연사 박물관 -> 세드 수족관 -> 애들러천문관(Adler Planetarium)
밀레니엄 파크에 딱 들어서자 마자 마주친게 신랑신부 입니다. 멋지게 차려입은 신랑,신부,들러리들이 열심히 사진을 찍고 있는걸 곳곳에서 볼 수가 있었습니다.
하지만 밀레니엄파크의 명물은 뭐니 뭐니 해도 빈입니다. 반짝반짝 빛나는 강남콩 모양의 구체는 주변의 여러 건축물을
비추는데 하늘과 사람과 건축물을 하나로 만들어서 보여줍니다.
박물관 3개가 모두 모여있다고 해서 그 지역을 뮤지엄 캠퍼스(The Museum Campus)라고 부릅니다. 그 중에서 첫번째로 간곳은 필드 자연사 박물관(The Field Museum), 이 박물관이 바로 '박물관이 살아있다.'에 나온 그 박물관입니다. 들어서자 마자 유명한 슈(Sue)가 보이네요. (실제 사이즈는 아니고 맥도날드에서 후원해서 기증한 모형이랍니다.)
총 3개층으로 되어 있는데 각 층 마다 전시관이 테마별로 꾸며져 있어서 보고 싶은 것들을 골라보기 쉽게 되어 있습니다. 남자들은 다 좋아하는 공룡화석을 주로 봤다는..^^
다음으로 간곳은 애들러 천문대 Adler Planetarum. 그런데 막상 들어가려니 상영하는 영화가 5시30분에 시작한다고 하네요. 그래서 표만 끊어놓고 쉐드수족관 Shedd Aquarium을 먼저 보기위해 다시 수족관으로 갔습니다.
그런데 이 수족관 별로 볼게 없습니다. 코엑스 아쿠아리움이 더 나은듯합니다. 4D 영화를 보여준다고 해서 잠깐 보고 바로 나왔습니다. 사진은 수족관 앞에 있는 물고기를 안고있는 사람의 분수입니다.
천문대에서 상영하는 영화는 두 편입니다.:Night Sky Live와 3D Universe: A Symphony 두 편 다 보시길 강추합니다. 피곤해서 먼저꺼를 자면서 보고 좀 쉬어야 두번째걸 잘 볼 수 있습니다.
천문대에서 시내를 바라보면 마치 호수에 도시가 면해 있는것 처럼 보여서 정말 멋진 장면을 볼 수 있습니다. 똑딱이로 찍어서 직접 봤을때의 감동이 덜하네요.
스크럼팀은 테스트에서 나온 결함을 어떤 식으로 관리해야 할까요? 제품 백로그에 추가하세요. 기능별로 유사한 결함을 모아서 스토리로 도출할 수도 있고, 크고 독립적인 결함은 별도의 스토리로 뽑을 수 있습니다. 이럴 경우 스토리의 우선순위를 고객의 가치와 개발 종속성에 따라 결정하듯이, 결함에 대한 스토리도 같은 규칙에 따라 처리할 수 있습니다.
주요 학습 내용: Spring, SpringMVC, TDD, Refactoring, Scrum, Pair programming, Design patterns, Code review, Retrospective, 등
특징: 이론 학습 + 툴 실습 + 개발 이 혼합되어 진행
이외에도 몇가지 학습의욕을 고취하기 위한 장치들이 있었는데 교육을 계속 진행해야 하기 때문에 여기에 적지 못하는게 아쉽네요. (혹시 수강할 팀원들이 알면 재미가 떨어질까 우려되서..^^)
일주일, 40시간을 진행했는데 기대했던 것 이상으로 많은 효과를 얻었습니다. 크게 세가지로 정리해 봤습니다.
첫째, 교육 자체에 대한 만족도가 매우 높았다.
프로젝트에 힘들게 일하다가 교육에 들어오게 되면 일단 교육 받는것 만으로도 즐거워 합니다.^^ 이런 것을 감안해도 다들 교육과정에 대해 "정말 좋은 교육이다."는 소감을 많이 주었습니다. 그것도 한두명이 아니라 거의 전부가 그랬습니다.
둘째, 학습 성취도가 매우 높았다.
사실 J2EE가 그렇게 쉽지는 않습니다. 그럼에도 불구하고 3일(강의등의 활동을 제외 했을때 실질 개발시간)이라는 짧은 시간에 꽤 많은 화면을 개발해 내는것을 보고 정말 놀랐습니다. 여기에는 페어의 역할이 매우 컸다고 생각합니다.
셋째, 팀워크가 좋아졌다.
저희 팀은 팀원들이 너무 많고 서로 다른곳에서 일하다 보니 팀원간에 끈끈함이 부족합니다. 5일간 정말 많이들 친해지더군요. 개중에는 그렇지 못한 친구들도 몇명 보이는걸 보니 개인성향은 어쩔 수 없는 듯 합니다.
그럼 어떻게 이런 효과가 난 걸까요? 전 이전에도 멀티캠퍼스에서 여러 교육과정을 만들고 강의를 한 경험이 있습니다. 그걸 비춰봐도 이건 잘 이해가 안가는 현상입니다. 그래서 나름 그 원인을 분석해 봤습니다.
교육 자체가 즐겁다. 감정이 풍부한 사람이 기억력도 좋다고 합니다. 기억력이 좋으면 당연히 공부도 잘하겠죠. 이번 과정은 재밌게 만들려고 많이 노력했습니다. 웃고 떠들면서 공부하다 보면 지루한지 모르고 교육을 받게 되고 자연스레 집중을 하는거 같습니다.
자기 주도형으로 학습한다. 과거 방식이 개발 분량을 강사가 할당하는 형식이었다면 이번에는 스크럼을 가르치고 스스로 교육기간에 개발할 분량을 스스로 산정합니다. 그리고 개개인의 책임을 강조하니 자습이나 과제를 따로 요구하지 않아도 팀단위로 토의하며 개발을 진행합니다.
팀단위로 학습하고 평가한다. 모든 액티비티를 팀체제로 운영하니 팀원간에 커뮤니케이션이 많아지고 팀간에 선의의 경쟁을 통해 열심히 하게 됩니다.
저를 포함해서 강의를 진행하는 강사들이 교육과정을 만들고 강의하는것 자체를 즐기다 보니 수강하는 팀원들도 과정 자체를 즐기게 된다고 생각합니다. 앞으로 7~8개 차수를 더 진행해야 하는데 다 끝나고 나면 과연 팀이 어떻게 변할지 저도 궁금합니다.
이 다음에는 일전에 애자일컨설팅 블로그에서 본 커크패트릭 모델(Kirkpatrick Model)을 가지고 성과를 측정해 보려고 합니다. 하지만 쉽지는 않아 보이네요.
오늘 Rebecca J.Wirfs-Brock의 Refreshing Patterns라는 논문을 읽다가 좋은 부분을 발견했습니다.
Reading and studying multiple pattern definition and examples helps convey the important point that it's quite natural for patterns to wiggle around a bit as they're applied.
많은 패턴책에서 패턴을 설명하기 위해 사용하는 다이어그램들은 하나의 예일 뿐입니다. 하지만 많은 사람들이 이를 그대로 구현하려 노력합니다. 그 보다는 여러 유형의 패턴정의를 비교해 보면 정말 중요한 부분을 찾을 수 있습니다. 그런 의미에서 2페이지로 예쁘게 정리해 놓은 패턴 카탈로그 하나 소개합니다.
Agile emphasizes on the opposite - getting stories which capture
onlythe "what" without the "how". It's a big shift in how we perceive
theprocess of software development to be. I guess it's as hard
forcustomers to get used to as it is for programmers.
역) 애자일은 반대로 스토리를 작성하는데 있어 '어떻게'가 아닌 '무엇을'을 정의하도록 강조한다. 소프트웨어를 개발하는데 있어
우리가 인식하고 있던것에 비한다면 이는 큰 전화점 이다. 고객에게 프로그래머처럼 생각하라고 강요하는건 무리가 있다.
GTD를 시작하기로 결심하고 나니 그 다음 떠오르는 문제는 "무엇을 기반으로 GTD를 시작할까?"였습니다. 대부분 메일을 GMail로 포워딩해서 받아 보고 있고, 커뮤니케이션도 주로 메일을 사용하니 GMail이 딱이더군요. (어떤 분들은 아웃룩이나 실제 상자를 이용하기도 합니다.)
편리한 GTD적용을 위해 GMail기반의 GTD를 지원하는 GTDInbox, 파이어폭스 부가도구를 설치했습니다. 설치하기 전에는 그냥 Label을 몇개 정의해서 사용하면 되지 않을까 생각했는데, 이 도구 나름 편리한 부분이 많다는걸 알게 됐습니다.
필요한 라벨 자동 추가
GTDInbox를 설치하고 재시작 하게 되면 아래와 같은 창이 뜨면서 상태를 나타내는 라벨을 추가할지 물어봅니다. 자동 추가를 누릅니다.
그러면 다음처럼 GTD진행을 위한 라벨이 추가됩니다. 기존에 사용하던 라벨은 Misc밑으로 들어갑니다.
대쉬보드 추가
진행상태에 따라 필터링해서 볼 수 있는 대쉬보드가 툴바에 추가됩니다.
선택상자를 내려보면 아래처럼 진행상태 라벨을 선택할 수 있습니다.
태스크 정의를 위한 메일쓰기 기능 추가
기존에 Compose Mail에 추가해서 Compose Personal 메뉴가 추가됩니다. 간단히 말하면 자기 자신에게 메일 쓰기 기능입니다.
하지만 아래 보이는 것처럼 라벨을 선택해서 보낼수 도 있고, 수신인 지정도 이미 되어 있어서 나름 편리합니다.
사실 이제 막 시작해서 얼마나 효과적일지 잘 모르겠습니다. 어떤 분은 "1년이 지났는데도 제대로 자신이 GTD를 쓰고 있는지 모르겠다" 하시더라구요. 더 써보고 느낀점을 올리려 합니다.