실용주의이야기(Pragmatic Story)

M25라는 무가지를 보다가 우연히 광고인 '이제석'씨 인터뷰를 봤습니다. 이력부터가 참 특이합니다.

1982년 경상북도 대구 출생, 대구 계명대 시각 디자인 학과 졸업

대학졸업후 국내 광고 대행사에 입사를 못하자 뉴욕 '스쿨오브비주얼아트 SVA'로 유학

유학중 전세계 광고대전에서 50여회 입상

2008년 한국에 이제석 광고연구소 설립

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Object Mentor의 Michael Feathers가 쓴 Testable Java라는 글에 보면 TUF & TUC라는 용어가 나옵니다.

• TUF = Test Unfriendly Feature
• TUC = Test Unfriendly Construct

번역하자면 테스트와 친하지 않은 특징, 테스트와 친하지 않은 생성 이라고 할까요. Java의 특징중에 테스트를 어렵게 만드는 특징들을 코드와 같이 잘 설명하고 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

스크럼에서의 추정은 크게 두가지 입니다. - 사용자 스토리에 대한 포인트, 태스크에 대한 시간

이중 태스크 시간은 개발자에 따라 변동이 커서 신뢰도가 떨어집니다. 물론 팀으로 추정한다거나 표준 시간을 정해준다거나 하면 좀 나아지기도 합니다.
기왕 그렇다면 차라리 태스크 시간을 같은 시간으로 고정시키는건 어떨까요? 보통 8시간 근무니까 4시간짜리 2개 태스크로 정해주는것도 나쁘지 않을거 같습니다.
그러다가 태스크를 상세히 정할 단계가 되면 더 세분화 할 수 있게 해주는거죠.
시간별로 포스트잇을 다양화 해서 시간이 많이 걸리는 태스크가 무엇인지 바로 알아차릴 수 있게 하는것도 좋을듯 합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

테스트 코드를 만들때 가장 많은 비용이 드는 부분은 테스트 데이터를 만드는 부분입니다. 테스트 데이터 관련 작업을 정리해 보면 다음과 같습니다.

• 테스트를 위한 데이터베이스 준비하기
• 초기 데이터 입력하기
• 테스트 코드를 실행하기 위한 입력 데이터 준비하기
• 테스트가 실행된후 데이터 초기화 하기

이중 실행을 위한 입력 데이터를 효과적으로 만드는 방법을 소개합니다.

메소드 파라미터 타입에 맞는 정적 데이터를 미리 준비하고, 이를 랜덤하게 조합하여 사용하는 것 입니다.

단순히 String name = "abc" 정도의 데이터를 생성하는 것으로는 부족합니다. 가능하면 도메인에 맞는 데이터를 입력해 주어야 합니다. 미리 "Sangchel", "Scott", "Hillery" 등의 데이터를 준비해 놓고 매번 다른 데이터를 이용하도록 한다면 좀 더 현실적인 테스트 데이터를 만들어 줄 수 있다고 생각합니다.

관련 URL: Randomizing static test data in automated tests

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Steve Freeman과 Rebecca Wirfs-Brock은 운좋게도 개인적으로 몇 번씩 만나본 분들입니다.(뭐 그렇다고 그분들이 절 기억하지는 못하겠죠. ^^) 오늘 블로깅 하다 재밌는 글을 하나 발견해서 링크합니다.

Mocks are not about isolation, but about responsibilities

단위테스트를 만들때 DB나 File과 같은 IO와 엮이게 되면 여러가지 문제가 뒤따릅니다. 그래서 이런 이슈를 해소하기 위해 Mock객체를 만들어서 테스트코드와 환경을 분리(isolation)하게 됩니다.

지난주 유럽 CITCON에서 Freeman은 목 객체에 대한 생각을 레베카의 Roles, Responsibilities and Collaborations object design school에서 영감을 얻었다고 발표했습니다. 그는 Mock객체를 단순히 분리를 위해서 사용하지 말고 디자인을 위해서 사용하라고 충고합니다.

인터페이스는 호출할 메소드만을 나타내기 때문에 객체를 명세하는데 충분하지 않다. 언제 어떻게 호출하는지는 알려주지 않는다. 그래서 목 객체가 필요한 것이다.

목객체를 만드는 나쁜 경우는 표준 자바 라이브러리를 목으로 만드는 경우라고 합니다. 더 자세한건 링크를 참고하세요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

TDD 메일링 리스트에 XP Developers versus Scrum Developers 라는 제목의 재밌는 글이 올라와 있어서 옮겨봅니다.

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의 기법들이 하나 둘씩 뒷받침 되어야 합니다. 습관이란것은 무섭습니다. 힘들고 어려운일을 당하면 바로 예전 방식에 대한 향수를 느끼고 회귀하게 됩니다.

스크럼개발자네 XP개발자네 하는 말보다는 그냥 애자일 개발자가 어떨까요?

ps) 추석인데 일본 촌구석 독신자 숙소에 있다보니 쓸데없이 야후 메일링이나 뒤지고 있네요..^^

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

프로젝트를 하다보면 쉽사리 JDK 버전을 올릴수가 없습니다. 기존 시스템이 괜시리 문제라도 생기면 당장 난리가 나죠. "어떤 X가 그랬어.." ^^;;

그래도 일단 뭐가 달라졌는지 알아야 의견을 낼 수 있으니 한번 살펴 봤습니다.

Swith문에서 String 사용 가능

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

얼마전에 방한했던 켄트벡의 Responsive Design에 대한 기사가 Pragmatic Magazine 3호에 실렸습니다. PDF로 받아 볼 수 있습니다.

PragPub Issue3, September 2009

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

컨퍼런스를 듣는동안 InfoQ 마크가 붙어있는 카메라가 여기저기 보였는데, 오늘자 뉴스레터에 보니 시리즈로 강연이 올라와 있네요.

Agile 2009 content on InfoQ

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

지금 있는 프로젝트에서 테스트 코드 관련 이슈가 하나 생겼습니다.

테스트 코드를 실행하는데 너무 많은 시간이 걸린다.

이슈를 분석해 보니 원인이 크게 두가지로 나왔습니다.

1. 테스트 코드마다 스프링 컨텍스트 파일을 로딩하도록 해놔서 시간을 잡아먹는다.
2. 커버리지를 측정하기 위해 기록하는데 시간이 오래걸린다.

이를 해결하기 위해 첫번째 해결책은 Test suite을 쓰는 것이었습니다. 그런데 이렇게 하는데는 또 공수가 들어갑니다. 테스트케이스를 추가할 때마다 테스트 스윗에 테스트케이스를 추가해야 하는 거죠.

그런데 밑에 있는 친구가 아주 좋은 방법을 찾아서 소개합니다.

Ant에서 JUnit을 실행할 때 사용하는 junit 타겟에 forkmode="once"를 주게 되면 테스트코드를 실행할때 매번 새로운 VM을 만들지 않고 하나의 VM만을 사용합니다.

<target name="test" description="Runs JUnit tests">
        <junit printsummary="yes" haltonfailure="no" fork="true" forkmode="once" failureproperty="test.failed" errorproperty="test.failed">
            <classpath refid="test.classpath" />
            <batchtest fork="true" todir="${test.report}">
                <fileset dir="${test.src}">
                  <include name="**/*TestCase.java" />
                </fileset>
                <formatter type="xml" />
            </batchtest>
        </junit>
    </target>

• fork="true" forkmode="Once" : JVM이 두개 생성됩니다. Ant를 위한 VM, JUnit을 위한 VM
• fork="false" : JVM은 한개 생성됩니다. Ant와 JUnit을 위한 VM
  

외국의 어떤 블로그에 보니 forkmode를 once로 했을때와 안했을때 2배정도 차이가 난다고 하네요. 저도 그 정도의 속도차를 느꼈습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

제품 백로그를 구성하는 사용자 스토리를 우선순위에 따라 정렬하는건 중요합니다. 그럼 어떻게 우선순위를 매기는게 적절할까요? 발표에 앞서 마이크콘은 비즈니스 관점에서의 제품 백로그의 가치를 강조합니다. 제품 백로그에는 한 스프린트에 대한 항목뿐만 아니라 전체 릴리즈될 범위까지 들어있으며 이들에 대한 우선순위는 비즈니스 관점에서 결정되어야 합니다.

사용자 스토리와 관련해서 세가지 용어가 등장합니다.

• 사용자 스토리(User Story): 사용자나 고객관점에서 원하는 기능에 대한 명세
  
• 테마(Theme): 관련있는 사용자 스토리의 집합
  
• 에픽(Epic): 큰 사용자 스토리

왜 테마가 필요할까요? 사용자 스토리를 특정 테마를 기준으로 우선순위를 정하게 되면 서로 반하게 우선순위가 매겨지는걸 피할 수 있습니다. 예를 들어 보겠습니다.
자동차에서 발 뻗는 곳의 크기와 엔진룸의 크기중 어느 것이 더 중요할까요 ? 이런 내용을 그냥 판단하기는 어렵습니다. 어떤 비즈니스 적인 입장에서 보느냐에 따라 그 중요성은 달라지기 때문입니다.

비즈니스 가치를 고려하여 우선순위를 정하는 방법에 대해 알아 보겠습니다.

1. Theme Screening
2. Theme Scoring
3. Relative Weighting
4. 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는 어떻게 정량적인 숫자로 연결되는지 좀 헷갈리네요. 제대로 이해하려면 더 찾아봐야 할거 같습니다. 첫번째 세션에서는 백로그에 대한 비즈니스 관점의 우선순위를 정량적으로 결정하는 방법에 대해 배운게 유용한거 같습니다. 마이크콘은 농담도 섞어 가며 강의를 재밌게 잘하는거 같습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

컨퍼런스 첫날입니다. 호텔에서 후딱 아침을 먹고 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

각 세션별 자세한 내용은 따로 정리할 생각입니다. 일단 발표 자료만 첨부합니다.

Prioritizing Your Product Backlog.pdf

XUnit Test Patterns and Smells.pdf

Zen and the Art of Software Quality.pdf

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

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 두 편 다 보시길 강추합니다. 피곤해서 먼저꺼를 자면서 보고 좀 쉬어야 두번째걸 잘 볼 수 있습니다.

천문대에서 시내를 바라보면 마치 호수에 도시가 면해 있는것 처럼 보여서 정말 멋진 장면을 볼 수 있습니다. 똑딱이로 찍어서 직접 봤을때의 감동이 덜하네요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

어떤식으로 학습을 하느냐에 따라 기억률에 많은 차이를 보입니다. 그 중에서도 특히 효과가 좋은것은 '직접 해보는 것'입니다.

들은 것은 잊어버리고, 본것은 기억하되, 실제로 해본 것은 이해합니다.

해보는 것도 어떻게 하느냐에 따라 차이가 납니다. 제가 특히 좋아하는건 같이 공부하는 것인데, 집단 학습은 크게 '협동학습'과 '협력학습'으로 나눌 수 있습니다.

회사에서 직원들을 교육시키는데 가장 좋은 방법이 '프로젝트 중심 학습활동'입니다. 이런 방식의 교육의 특징은 다음과 같습니다.

• 학습자 중심으로 이루어 진다.
  
• 한꺼번에 여러가지를 학습한다.
• 실제적인 문제를 갖고 진행한다.
• 학습자의 참여를 권장한다.
• 협동을 강조한다.
• 고 차원의 사고를 강조한다.

이런 프로젝트 중심 교육은 크게 4가지 단계로 진행됩니다.

1. 학습자들에게 최종적으로 제출해야 하는 산출물을 정의해 줍니다.
2. 주제를 조사하고 프로젝트를 관리하기 위한 계획을 수립합니다.
3. 프로젝트 진행과정에서 제기되는 문제를 해결하고 프로젝트를 종료합니다.
4. 프로젝트의 결과물을 발표하고 평가하며 스스로 성찰할 수 있는 시간을 갖습니다.

하지만 어느 단계도 그리 쉬어 보이지는 않네요. 열공하세요. ^^

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

처음에는 개발자로 시작했지만 SA, TA를 거쳐 지금은 Enterprise Java CoE(Center of Excelence) Leader라는 역할을 맡고 있습니다. 오랜만에 들어간 에이콘 블로그에서 프로젝트 살리기에 대한 신간 소식을 보고 귀가 솔깃했습니다.

지금 제가 하는 일이 바로 '어느 악성 프로젝트 살리기' 입니다. ^^

어느 프로젝트이든 일을 하다 보면 해결하기 어려운 이슈는 계속 쌓여만 갑니다. 특히 어려운 이슈는 눈길을 못 받기 일쑤 입니다. 괜히 건드려 봐야 일만 커지고 자기 일만 늘어나기 때문이죠.

저는 다음과 같은일에 주력합니다. 조기에 이슈를 드러내고, 어려운 일은 어렵다고 이야기 해주고, 참고할 수 있는 좋은 소스를 제공하고, 개발과 테스트를 잘 할 수 있는 방안을 제공하고...

하지만 이런 일 중에 제일 어려운것은 사람들을 설득하는 겁니다. 회의를 잡아도 들어오지 않고, 회의중에도 바쁜 일이 있다고 나가버립니다.  저런 책좀 많이들 보고 생각을 바꿨으면 좋겠습니다.

ps) 이벤트에 당첨됐습니다. ^^ 예쁘게 포장까지 해서 엽서와 같이 보내주셨네요.
출장정리에 프로젝트일까지 정신없지만 얼른 읽고 리뷰 올리도록 하겠습니다. 
 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

스크럼팀은 테스트에서 나온 결함을 어떤  식으로 관리해야 할까요? 제품 백로그에 추가하세요. 기능별로 유사한 결함을 모아서 스토리로 도출할 수도 있고, 크고 독립적인 결함은 별도의 스토리로 뽑을 수 있습니다. 이럴 경우 스토리의 우선순위를 고객의 가치와 개발 종속성에 따라 결정하듯이, 결함에 대한 스토리도 같은 규칙에 따라 처리할 수 있습니다.

참고 URL: http://www.infoq.com/news/2009/07/coping-with-bugs

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

지난번에 이어 다시 강의를 진행했습니다. 정확히 말하면 'J2EE 개발을 위한 교육'이었는데 간단하게 교육내용을 정리해 봤습니다.

• 교육의 목적: J2EE 시스템을 잘 개발 할 수 있도록 여러 기법들을 학습하기
• 대상자: 저희 팀원 23명(이중 반은 Java를 몇년전에 해봤음, 심지어 10년된 분도..)
• 교육내용:
  
• 주어진 문제 영역을 이해한다.
• 산출물(ex 화면정의, ERD, 클래스 다이어그램 등)을 이해한다.
• Anyframe 기반으로 시스템을 개발한다.
• 새로운 기법에 대한 강의를 듣는다.
• 배운것들을 바로 개발에 적용해 본다.
  
• 주요 학습 내용: Spring, SpringMVC, TDD, Refactoring, Scrum, Pair programming, Design patterns, Code review, Retrospective, 등
• 특징: 이론 학습 + 툴 실습 + 개발 이 혼합되어 진행
  

이외에도 몇가지 학습의욕을 고취하기 위한 장치들이 있었는데 교육을 계속 진행해야 하기 때문에 여기에 적지 못하는게 아쉽네요. (혹시 수강할 팀원들이 알면 재미가 떨어질까 우려되서..^^)

일주일, 40시간을 진행했는데 기대했던 것 이상으로 많은 효과를 얻었습니다. 크게 세가지로 정리해 봤습니다.

첫째, 교육 자체에 대한 만족도가 매우 높았다.
프로젝트에 힘들게 일하다가 교육에 들어오게 되면 일단 교육 받는것 만으로도 즐거워 합니다.^^ 이런 것을 감안해도 다들 교육과정에 대해 "정말 좋은 교육이다."는 소감을 많이 주었습니다. 그것도 한두명이 아니라 거의 전부가 그랬습니다.

둘째, 학습 성취도가 매우 높았다.
사실 J2EE가 그렇게 쉽지는 않습니다. 그럼에도 불구하고 3일(강의등의 활동을 제외 했을때 실질 개발시간)이라는 짧은 시간에 꽤 많은 화면을 개발해 내는것을 보고 정말 놀랐습니다. 여기에는 페어의 역할이 매우 컸다고 생각합니다.

셋째, 팀워크가 좋아졌다.
저희 팀은 팀원들이 너무 많고 서로 다른곳에서 일하다 보니 팀원간에 끈끈함이 부족합니다. 5일간 정말 많이들 친해지더군요. 개중에는 그렇지 못한 친구들도 몇명 보이는걸 보니 개인성향은 어쩔 수 없는 듯 합니다.

그럼 어떻게 이런 효과가 난 걸까요? 전 이전에도 멀티캠퍼스에서 여러 교육과정을 만들고 강의를 한 경험이 있습니다. 그걸 비춰봐도 이건 잘 이해가 안가는 현상입니다. 그래서 나름 그 원인을 분석해 봤습니다.

• 교육 자체가 즐겁다. 감정이 풍부한 사람이 기억력도 좋다고 합니다. 기억력이 좋으면 당연히 공부도 잘하겠죠. 이번 과정은 재밌게 만들려고 많이 노력했습니다. 웃고 떠들면서 공부하다 보면 지루한지 모르고 교육을 받게 되고 자연스레 집중을 하는거 같습니다.
• 자기 주도형으로 학습한다. 과거 방식이 개발 분량을 강사가 할당하는 형식이었다면 이번에는 스크럼을 가르치고 스스로 교육기간에 개발할 분량을 스스로 산정합니다. 그리고 개개인의 책임을 강조하니 자습이나 과제를 따로 요구하지 않아도 팀단위로 토의하며 개발을 진행합니다.
• 팀단위로 학습하고 평가한다. 모든 액티비티를 팀체제로 운영하니 팀원간에 커뮤니케이션이 많아지고 팀간에 선의의 경쟁을 통해 열심히 하게 됩니다.
  

저를 포함해서 강의를 진행하는 강사들이 교육과정을 만들고 강의하는것 자체를 즐기다 보니 수강하는 팀원들도 과정 자체를 즐기게 된다고 생각합니다. 앞으로 7~8개 차수를 더 진행해야 하는데 다 끝나고 나면 과연 팀이 어떻게 변할지 저도 궁금합니다.

이 다음에는 일전에 애자일컨설팅 블로그에서 본 커크패트릭 모델(Kirkpatrick Model)을 가지고 성과를 측정해 보려고 합니다. 하지만 쉽지는 않아 보이네요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

QCon에 Sir Charles Antony Richard Hoare 라는분이 과학과 엔지니어링에 대해 비교하는 강연이 올라왔습니다. 약력을 읽어보니 이 분은 퀵소트(Quicksort)를 만드신 분이더군요. ^^;

The Science of Computing and the Engineering of Software

슬라이드는 심플합니다만 설명하는 내용은 가볍지 않네요.
 

소프트웨어 엔지니어링이 모든 엔지니어링 분야에서 가장 중요한 영역이 될거라는 말을 남기면서 강연이 끝나네요. 빨리 그런 날이 왔으면 좋겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

ZD Net, 분석, 설계 기법으로서의 테스트 주도 개발, 이종국

이런 제목의 글이 ZD Net에 실리는것을 보니 우리나라에도 애자일이 많이 확대되고 있는거 같아서 기분은 좋네요. 그런데 글 내용은 그냥 그런거 같습니다. 제가 그렇게 생각하는데는 몇가지 이유가 있는데요..

• 너무 어렵게 설명하고 있습니다.: 관련내용을 잘 알고 있다고 생각했는데 무슨 말을 하는지 이해하느라 몇 번 읽어봐야 했습니다. 나름 이해를 잘한다고 생각하고 있는데..^^
• 영어를 번역해 놓은것 같은 문장이 많습니다.: 글이 잘 익히지 않는게 마치 번역을 해 놓은듯한 느낌이네요.
• 내용상에 몇가지 오해의 소지가 있습니다.: TDD를 하면 시스템을 전부 재개발해야 하는 것처럼 설명한 부분, TDD를 하면 더 이상의 테스트가 필요없다 식의 논리는 비 현실적이라 생각됩니다.

요즘들어 글쓰기가 어렵다는걸 부쩍 느끼고 있습니다. ZD Net과 같은 기사는 더 엄히 확힌해야 하지 않을까요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

오늘 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페이지로 예쁘게 정리해 놓은 패턴 카탈로그 하나 소개합니다.

Design Patterns Quick Reference

다시 시작한 패턴공부 의외로 재미있네요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

TDD 뉴스그룹에서 올라온 글을 보다 발견했습니다.

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.

역) 애자일은 반대로 스토리를 작성하는데 있어 '어떻게'가 아닌 '무엇을'을 정의하도록 강조한다. 소프트웨어를 개발하는데 있어 우리가 인식하고 있던것에 비한다면 이는 큰 전화점 이다. 고객에게 프로그래머처럼 생각하라고 강요하는건 무리가 있다.

어찌 보면 당연한 이야기 인데 간과하며 지난다는 생각에 적어봤습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

GTD(Getting Things Done)는 이미 오래전부터 알고 있었습니다만 선뜻 시작하게 되지 않더군요. 그러던중 바탕화면을 GTD Workflow로 바꾸면서, 계속 보다가 용기를 냈습니다.


GTD에 대해 잘 모르시는 분은 아래 블로그와 책을 차근차근 읽어보시길 권해 드립니다.

• 쉐아르님의 GTD 따라 잡기 시리즈
• David Allen, Getting Thinng Done and GTD
  
• 라이프 해커님의 ZTD, GTD 관련글
• 끝도 없는일 깔끔하게 해치우기
  

GTD를 시작하기로 결심하고 나니 그 다음 떠오르는 문제는 "무엇을 기반으로 GTD를 시작할까?"였습니다. 대부분 메일을 GMail로 포워딩해서 받아 보고 있고, 커뮤니케이션도 주로 메일을 사용하니 GMail이 딱이더군요. (어떤 분들은 아웃룩이나 실제 상자를 이용하기도 합니다.)

편리한 GTD적용을 위해 GMail기반의 GTD를 지원하는 GTDInbox, 파이어폭스 부가도구를 설치했습니다. 설치하기 전에는 그냥 Label을 몇개 정의해서 사용하면 되지 않을까 생각했는데, 이 도구 나름 편리한 부분이 많다는걸 알게 됐습니다.

필요한 라벨 자동 추가
GTDInbox를 설치하고 재시작 하게 되면 아래와 같은 창이 뜨면서 상태를 나타내는 라벨을 추가할지 물어봅니다. 자동 추가를 누릅니다.

그러면 다음처럼 GTD진행을 위한 라벨이 추가됩니다. 기존에 사용하던 라벨은 Misc밑으로 들어갑니다.

대쉬보드 추가
진행상태에 따라 필터링해서 볼 수 있는 대쉬보드가 툴바에 추가됩니다.

선택상자를 내려보면 아래처럼 진행상태 라벨을 선택할 수 있습니다.
 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

지난주 저희회사 신입사원들을ㄹ 대상으로 강의를 했습니다. 강의 내용은 'J2EE 기반의 애플리케이션 개발' - 문제가 서술되어 있고 관련 산출물이 주어지면 이를 가지고 개발을 진행하는 과정

이미 만들어진 강의를 받아서 하는거라 큰 부담은 없었습니다. 하지만 강의전에 같은 강의를 들은 사원들을 인터뷰한 결과 "도무지 뭘 공부한 거야." 하는 말이 절로 나올 정도로 학습 효과가 낮다는걸 확인했습니다.

그래서 강의 내용 자체는 바꿀 시간이 없는 관계로 강의중 진행되는 실습에 스크럼을 접목하기로 했습니다. 제가 기존 강의와 다르게 진행한 부분을 뽑아 봤습니다.

• 강의 시작전에 체크아웃
• 강의가 끝나고 매일 매일 팀별로 회고, 전체 공유
• 첫날 강의 중 진행되는 실습에 대한 계획게임 실시
• 실습전에 데일리 스크럼 진행
• 실습을 페어로 진행하도록 가이드
  
• 2일 주기로 이터레이션 진행
• 매  이터레이션마다 스프린트 리뷰 미팅(시연회) 실시

이런식으로 진행하기 위해서 중간중간 미리 준비한 강의자료로 애자일, 스크럼에 대한 강의를 진행했습니다. 그 결과 거의 대부분의 학생들이 "기존에 본인이 받은 교육보다 훨씬 좋다. 이제는 뭘 배웠는지 알거 같다."는 자신에 찬 이야기를 해 주었습니다.


본인이 뭘 공부할지에 대해 명확히 알고, 그걸 학습하고, 학습결과를 매일 검토하면서 학습효과가 높아졌다고 생각합니다. 이를 가능하게  하는데 들어간 돈은 채 3만원도 안들었을거 같습니다.

• 3M 포스트 잇 소형: 10개
  
• 마커펜: 20개
  
• 3M 대형 포스트 잇: 2개
  

작은 실험이었지만 매우 좋았다고 생각하며, 앞으로 저희팀에서 받게될 개발자를 위한 교육과정을 모두 이런 방식으로 운영할 생각입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

전 아직도 린(Lean) 개념의 장점이 무언지 정확히 모르겠습니다만 아래 기사를 소개하려 합니다.

Stop Starting and Start Finishing - A Successful Lean philosophy

새롭게 시작하는 것을 멈추고 끝내는 것을 시작하라. 일을 할때 가장 힘들 때가 "언제 이 일이 끝이 날지 모를때"가 아닐까요? 안다고 하더라도 일이 끝이 없이 계속된다고 느끼면 사람들은 대게 지치게 마련입니다. 생산성 따위는 안중에도 없어 집니다.

이런 상황에서 필요한 것은 "작은 성공", "작은 마무리" 입니다. 조금씩 일이 진척되고 있다는 것을 느낄 수 있도록 작은 단위로 나누고 이를 끝내는 걸 반복하다 보면 결국 일은 끝이 납니다. 이런게 린의 원리가 아닌가 생각해 봤습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

병에 걸리고 나서 고치는건 차선이고 예방이 최선이라고들 이야기 합니다. 개발단계에서 예방은 '코드리뷰'에 비유할 수 있습니다. 코드리뷰때 생각해 볼만한 질문을 나열해 봤습니다.

코드리뷰는 언제 시작하는게 가장 좋을까요?
개발 시작할때 부터 하는게 좋습니다. 개발을 시작하려면 '개발표준'이 필요합니다. 이 표준을 아무리 잘 만들어도 부족한 부분은 있게 마련이고, 실제로 개발자들이 이 표준에 지켜서 개발하는 것도 시간이 걸립니다. 습관이 들어야  하는거죠..이 때 코드리뷰가 효과적입니다. 초반부터 아예 개발 프로세스에 포함시키는걸 권장합니다.

코드리뷰 종류에는 어떤것들이 있나요?
아주 정형화된 형태의 인스펙션(Inspection)부터 캐쥬얼하게 진행하는 피어 리뷰(Peer review)까지 다양합니다. 어떤 형태로 코드리뷰를 진행하느냐 보다는 얼마나 자주 많이 모여서 하느냐가 더 중요합니다. 코드리뷰의 목적은 코드를 개선시키기위한 것도 있지만 코드를 공유하는것도 있습니다.
코딩시 배운 팁들이 코드리뷰를 통해서 자연스레 전이가 이루어지게 하십시요.

코드리뷰는 어떤 것들에 대해 진행하나요?
저는 단위테스트 수준에 해당하는 정도로 진행하라 말하고 싶습니다. 보통 단위테스트를 클래스나 메소드 수준으로 진행하는데 이 정도가 적당할거 같습니다.  UI를 기준으로 단위테스트 한다면 특정 유스케이스 시나리오나 플로우 기준으로 UI부터 서버코드까지 같이 진행하는것도 좋을거 같습니다.

코드리뷰는 잘 정착되면 코드 품질을 높힐수 있는 좋은 기법입니다. 끝으로 자동화를 같이 병행하면 코드리뷰 효과를 배가시킬 수 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.