실용주의이야기(Pragmatic Story)

애자일 관련 책이나 기사를 읽다보면 눈에 띄는 약어들이 가끔 보입니다. 정확한 풀 용어를 몰라 헛갈리는 분들을 위해 제가 아는 몇 가지를 정리해 봤습니다.

• BUFD(Big Up Front Design): 프로젝트 초반에 과도하게 설계를 진행하는것
• LOC(Line Of Code): 소스코드의 라인 수
  
• PO(Product Owner): 스크럼의 제품 책임자
• TDD(Test Driven Development): 테스트 주도 개발
  
• YAGNI(You Aint't Gonna Need It): 언젠가는 사용할거라 생각하고 미리 만들어 두지 말라는 경우, Simple Design을 요약해서 설명하는 용어
• NAH(Not Applicable Here): 새로운 기법,기술을 적용할때 이를 거부하려는 저항이 나타나는데 이때 공통적으로 보이는 현상. "그건 여기에 안 맞아요."
  
• SUT(System Under Test): 자동화된 테스트가 수행되고 있는 시스템, 테스트 코드가 있는 시스템

혹 더 있으면 댓글로 알려주세요. 같이 정리해 놓겠습니다.

참고 자료
[1] NAH Syndrom
[2] Is Design Dead?

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

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

처음 스크럼을 적용하면 곧잘 합니다. 그런데 2~3개월 하다보면 흐지브지 되기 쉬운데요. 그중 가장 처음 망가지는게 일일 스크럼입니다. 왜 그럴까요

• 다른 사람과 협업하는 비율이 너무 낮다.: 겹치는 일이 거의 없습니다. 개발도 혼자 합니다. 이런 경우 다른 사람일이 어떻게 진행되는지 관심도 없기 일쑤입니다.
  
• 장애요소라고 말할게 없다.: 다같이 머리를 맞대고 팀의 이슈를 해결해 나가는데서 효과가 납니다. 그런데 매일 매일 일이 너무 잘되고 장애가 하나도 없다면??
• 스토리가 업데이트되지 않는다.: 스토리가 스티커처럼 계속 똑같이 붙어있는 경우입니다.
  

첫번째 문제는 업무 배정이 잘못됐을 수도 있구요. 아니면 페어로 개발을 하도록 시키는 것도 좋습니다.
두번째 문제는 실제로 이슈가 없을수 도 있고, 말을 하지 않는것일 수도 있습니다.
세번째 문제는 완료된 스토리에 대해서 다 같이 칭찬을 해주는 방법을 써볼 수 있습니다. 스토리를 날리는것이 즐거운 일이란것을 느끼게 합니다.

쉬우면서도 어려운 기법이라 생각됩니다.

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

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

실용주의 개발환경을 구성하는데 필요한 도구들을 모아봤습니다.
혹시 틀린부분이나 더 좋은 도구가 있으시면 댓글 달아 주세요. 계속해서 업데이트 하겠습니다.

ps) 2007년에 처음 작성했던 리스트인데 새로 몇개를 수정하며 위로 올렸습니다.

1. 개발 도구
1. Eclipse : http://www.eclipse.org/
   
2. Netbean : http://www.netbeans.org/community/releases/60/index.html
   
3. Firebug : http://www.getfirebug.com/
2. 소스코드 관리
1. CVS : http://www.cvshome.org
   
2. Subversion : http://subversion.tigris.org
   
3. MS Visual SourceSafe
4. BitKeeper : http://www.bitkeeper.com
5. ClearCase : http://www-306.ibm.com/software/awdtools/clearcase/
6. Mercurial SCM: http://mercurial.selenic.com/
7. Git :  http://git-scm.com/
   
3. 빌드 스크립트 도구
1. make : http://source.redhat.com/cygwin
   
2. Automake : http://www.gnu.org/software/automake
   
3. Ant : http://ant.apache.org
   
4. NAnt : http://nant.sourceforge.net
5. Gant: http://gant.codehaus.org/
6. Rake : http://rake.rubyforge.org/
7. SCons : http://www.scons.org/
8. MSBuild: http://msdn.microsoft.com/ko-kr/library/ms171452%28VS.80%29.aspx
   
4. 빌드 시스템
1. Maven : http://maven.apache.org
   
2. Maven2 : http://maven.apache.org/maven2/index.html
   
5. CI 도구
1. CruiseControl : http://cruisecontrol.sourceforge.net
   
2. CruiseControl .NET : http://sourceforge.net/projects/ccnet
   
3. DamageControl : http://damagecontrol.codehaus.org
   
4. AntHill : http://www.urbancode.com/projects/anthill
   
5. Continuum : http://maven.apache.org/continuum
   
6. LuntBuild : http://luntbuild.javaforge.com/
7. Buildix : http://buildix.thoughtworks.com/
8. Hudson : https://hudson.dev.java.net/
9. Teamcity: http://www.jetbrains.com/teamcity/
10. Gradle: http://gradle.codehaus.org/
    
6. 이슈 추적 도구
1. Bugzilla : http://www.bugzilla.org
   
2. JIRA : http://www.atlassian.com/software/jira/default.jsp
   
3. FogBugz : http://www.fogcreek.com/FogBugz
   
4. PR-Tracker : http://www.prtracker.com
5. Trac : http://trac.edgewall.org/
6. gerrit: http://code.google.com/p/gerrit/
   
7. 테스트 프레임워크
1. JUnit : http://www.junit.org
   
2. NUnit : http://www.nunit.org
3. xUnit.NET : http://www.codeplex.com/xunit
   
4. MbUnit : http://www.mbunit.org
   
5. HTMLUnit : http://htmlunit.sourceforge.net
   
6. HTTPUnit : http://httpunit.sourceforge.net
   
7. JWebUnit : http://jwebunit.sourceforge.net
   
8. Cobertura : http://cobertura.sourceforge.net
   
9. Clover : http://www.cenqua.com/clover
10. Cactus : http://jakarta.apache.org/cactus/
    
11. Emma : http://emma.sourceforge.net/
    
12. Fit : http://fit.c2.com
    
13. Fitness : http://fitnesse.org
14. Watir : http://wtr.rubyforge.org
    
15. Systir : http://atomicobject.com/systir.page
16. AUT : http://aut.tigris.org/
17. UnitTest++ : http://unittest-cpp.sourceforge.net/
18. TestNG : http://testng.org/doc/
19. CppUnit : http://sourceforge.net/projects/cppunit
20. CppUnit2 : http://cppunit.sourceforge.net/cppunit-wiki/CppUnit2
21. Selenium : http://www.openqa.org/
    
22. Agitar : http://www.agitar.com/
23. JTest : http://www.parasoft.com/jsp/home.jsp
24. PushToSoft : http://www.pushtotest.com/
25. Eclemma : http://www.eclemma.org/
26. GoogleTest: http://code.google.com/p/googletest/
27. OCUnit: http://www.mobileorchard.com/ocunit-integrated-unit-testing-in-xcode/
28. UISpec4J: http://www.uispec4j.org/
29. UISpec: http://code.google.com/p/uispec/
    
8. 프로젝트 관리
1. OpenProj : http://openproj.org/openproj
2. dotproject : http://www.dotproject.net/
   
3. Mantis : http://www.mantisbt.org/
4. redmine: http://www.redmine.org/
5. GanttProject: http://www.ganttproject.biz/
   
9. 커뮤니케이션 도구, 위키
1. MoinMoin : http://moinmoin.wikiwikiweb.de/
   
2. Confluence : http://www.atlassian.com/software/confluence/
   
3. TWiki : http://twiki.org/
   
4. SocialText : http://www.socialtext.com/
5. Springnote : http://www.springnote.com/ko
   
10. 지표
    
1. Metrics: http://metrics.sourceforge.net/
   
11. 성능분석
    
1. ANTS Load : http://www.red-gate.com/products/ants_load/index.htm
2. JunitPerf : http://www.clarkware.com/software/JUnitPerf.html
3. Jmeter : http://jakarta.apache.org/jmeter/
   
12. 기타
1. Structure101 : http://www.headwaysoftware.com/index.php
2. FreeMind : http://freemind.sourceforge.net/wiki/index.php/Main_Page
3. Capistrano : http://manuals.rubyonrails.com/read/book/17

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

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

스크럼에는 단지 3종류의 역할만 존재합니다.: 제품 책임자, 스크럼 마스터, 팀
제품 책임자는 고객을 대변하면서 팀이 개발할 기능에 대한 백로그를 작성하고 백로그 항목에 대한 우선순위를 결정합니다. 스크럼 마스터는 팀에게 스크럼을 소개하고 팀이 스크럼을 제대로 수행할 수 있도록 장애를 제거해 나가는 조력자입니다.

그럼 기존 프로젝트에서 관리자(PM,PL 등) 역할을 했던 사람들은 어떻게 되는 걸까요? 제품 책임자나 스크럼 마스터의 역할을 맡아야 할까요? 프로젝트를 떠나야 할까요?

Case1: 관리자가 제품 책임자 역할을 하는 경우
관리자는 고객을 만나서 요구사항을 받고, 개발해야 하는 업무를 정의하기 때문에 바람직하다고 여겨 집니다. 다만 우선순위나, 개발 범위를 확정할 수 없다는 문제가 있습니다.

Case2: 관리자가 스크럼 마스터를 하는 경우
기존 관리자의 관리 스타일은 명령하고 관리하기(Command and Control)입니다. 스크럼 팀은 자기 조직적인 팀(Self Management Team)으로서 이런 방식에 맞지 않습니다. 관리자가 스크럼 마스터라는 모자를 쓴다면 형식만 갖추었을 뿐 정작 일은 똑같이 진행되는 경우가 많아 좋은 형태는 아니라고 봅니다.

Case3: 관리자 역할을 그대로 유지 하는 경우
기존 관리자의 권한이 매우 축소 됩니다. 소외감을 느낄 수도 있고, 기득권을 놓지 않으려 하면 스크럼 마스터와 충돌이 일어 납니다. 팀원들의 역량을 높이기 위한 멘토 역할을 해야 하는데 그렇지 못한 경우 팀을 떠나야 할 수도 있습니다.
반대 상황도 벌어집니다. 스크럼 마스터가 관리자의 업무를 일부 맡아서 처리해 주는 형태가 됩니다. 실제로 스크럼 마스터가 개발 관련 이슈나 파트간에 조율해야 하는 일들을 도맡아서 챙겨 주지만, 특별히 자기가 하던 역할에서 달라진게 없으니까 좋아하는 사람도 있습니다.

관리자가 어떤 역할로 자리매김을 하던, 서로 협업을 하는 분위기만 잘 조성된다면, 본인이 그런 상황변화를 잘 받아들일 수 있다면 크게 문제되지 않을거라 생각됩니다.
관리자가 어떤 역할로 자리매김을 하는가는 그 사람의 역량에 따라 다를거 같습니다.

• 개발자가 개발한 코드를 확인할 수 있는가
• 서로 협업하는 분위기를 선호하는가.
• 새로운 방식을 잘 받아들일 수 있는가.
  

이런 조건을 만족한다면 어 크게 문제되지 않을거라 생각됩니다.

참고자료
[1] Manager 2.0: The Role of the Manager in Scrum

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

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

이번해 8월초에도 Agile 2010 컨퍼런스가 미국 플로리다 올랜도에서 열릴 예정입니다. 컨퍼런스에 어떤 주제에 대한 발표가 많은지를 살펴보면 요즘 인기있는 애자일 토픽에 대한 정보를 얻을 수 있습니다.

키노트
이번 키노트는 베데라 리서치 랩(Bedarra Research Lab)의 데이브 토마스(Dave Thomas)와 마운틴 곳의 마이크 콘(Mike Cohn)이 맡았습니다. 베데라 컨설팅의 데이브 토마스는 저희 회사에 몇년간 컨설팅을 진행한적이 있어 인연이 있는 분입니다.
이 분도 애자일 선언(Manifesto for Agile Software Development)의 발제자중 한분으로 꽤 유명한 분으로 알고 있습니다. 동명이인이 한분 있는데 실용주의 프로그래머의 저자도 데이브 토마스 입니다.
발표 주제가 'An Unplugged Retrospective on the Agile Decade'입니다. 근 10년간 진행되어온 애자일의 발전에 대해 돌아보고 나아가길에 대해 이야기 하는것 같습니다.

마이크 콘은 사용자 스토리나 애자일 추정에 관한 많은 책, 강연으로 이미 유명한 분이죠. 이번 키노트 제목을 보니 ADAPTing to Agile for Contined Success 입니다.  아마도 그의 최근 책인 Succeeding with Agile의 2장 내용일거라는 생각이 듭니다. InfoQ에도 관련기사가 올라와 있습니다.

스테이지(Stage)
2009년에 비해 눈에 띄게 차이나는 부분은 보이지 않습니다. 다만 Enterprise에 대한 스테이지가 몇개 세분화되어 추가되었네요. (왼쪽이 2009년, 오른쪽이 2010년입니다.)


상세 프로그램(Schedule)
2009년에 비해 달라진 부분이 몇가지 있습니다.
처음 참가한 사람들을 위한 사전세션(First Time Attandee Orientation)이 생겼습니다. 사실 컨퍼런스 처음가면 어리둥절하기 쉬운데 전날 이런 행사에 참여하면 그래도 낫죠. 전날 관광 예정이었다면 이걸 빌미로 하루 먼저 갈수도 있고. ^^;

마지막 날 오전에 키노트 세션이 있습니다. 사실 컨퍼런스 뒤로 갈수록 뭘 들어야 할지 고민하게 됩니다. 인기 강사들의 세션이 앞날 중복으로 열리기 일쑤거든요. 근데 이번에는 마지막에 Rohn Jeffrie와 Mike Cohn의 세션이 연속으로 진행됩니다. 대박이군요.

메인 세션을 훝어보니 이름만 들으면 알수있는 쟁쟁한 애자일리스트들의 세션들이 즐비하네요. 헨리크리닉버그,스캇앰블러, 에스더 더비, 마이크콘,에릭감마,제시카 리퍼브룩, 스캇앰블러,아마드 시드키,등등

해외 컨퍼런스를 처음 갔을때 생각납니다. 세션은 정말 많은데 누구것을 들어야 할지 몰라 고민하다 제대로 된 세션을 못찾아 헤메기 일쑤였는데..그래도 몇번 갔다오고, 발표자 모집할 때부터 관심을 가지고 살펴보니 좋은 세션들이 많이 보이네요. 아쉽지만 다음 기회를 노려야 할거 같습니다.

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

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

오늘 아키텍트 대회에서 발표할때 사용했던 슬라이드입니다. 슬라이드 쉐어에 올렸더니 일부 글꼴이 없어서 깨지네요, PDF로 첨부합니다.

애자일_SA.pdf

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

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

회사에는 직무라는게 있는데 저는 약 5~6년전부터 SA(Software Architect)라는 직무를 갖고 일하고 있습니다. 그러다가 문득 궁금해졌습니다.

애자일로 개발하는 프로젝트에서 아키텍트의 역할은 어떤 것일까?

프로젝트에 스크럼과 같은 애자일 방법론을 적용하게 되면 전통적인 역할이 달라지는게 보통입니다. 프로젝트 관리자의 역할, 테스터의 역할, 아키텍트의 역할 등

기술적 장애를 해결하는 사람
일일 스크럼에서 드러나는 많은 이슈들은 제때 해결되어야 합니다. 만약 그렇지 못하면 업무팀은 이슈를 이야기 하지 않게 됩니다. 말해봐야 소용없다고 생각하는거죠. 그래서 빠른 피드백이 중요합니다. 아키텍트가 업무팀이 진행하는 일일 스크럼에 참석하는게 좋습니다. 팀이 너무 많다면 스크럼의 스크럼(Scrum of Scrum)에 참석해서 장애요소가 무엇인지 직접 듣고 해결에 앞장서야 합니다.

이터레이션 0를 진행하는 사람
프로젝트를 본격적으로 진행하기 전에 많은 것들이 검증되어야 합니다. 이를 위한 작업을 주도하는 사람이 되어야 합니다.

표준을 관리하고 정제하는 사람
분석,설계,개발을 단계적으로 진행할때는 시간이 있습니다. 개발을 위한 표준을 정의하고 확인할 시간. 하지만 이터레이션을 진행한다면 그럴 여유가 없습니다. 누구 한명이 표준을 정할 수 없으니 많은 개발자들이 진행하는 선도 개발을 정제하고 관리해 나가야 합니다. Wiki와 같은 툴을 활용하면 좋습니다. 일일 스크럼에서 공유하는것도 좋은 방법입니다.

개발자의 가려운 부분을 긁어주는 사람
개발하다 보면 반복적으로 진행해야 하는 기계적인 작업이 있는데 이런 사항을 자동화 해서 생산성을 높이는데 기여합니다. 이때 CI등의 기법이 활용됩니다.

이번주 금요일 아키텍트 대회에서 이런 주제로 발표를 하려 합니다. 

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

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

지난주 6웧 26일 토요일 애자일 초보자를 대상으로 한 Xper 세미나에서 칸반게임을 진행했습니다. 사내 교육에서 이미 이 게임을 많이 해밨기 때문에 게임 자체를 진행하는데는 큰 무리가 없었습니다.

일반 강의를 진행하면 지식 전달은 되지만 서로간의 활발한 참여를 이끌어내기는 어렵습니다. 반면 이런 게임 형태는 참여도는 높지만 깊이있고 차분한 토론은 어렵다는 단점이 있습니다. 그런 행위를 제대로 이끌어 내기 위해서는 사전에 게임의 목표나 행위,이론에 대해 자세히 설명해야 더 많은 것을 느낄 수 있습니다. 어색한 사람들이 서로 신뢰할 수 있도록 만드는데도 유용합니다.

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

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

새로운 내용은 아니지만 잘 정리되어 있는 내용이라, 한번 볼만 합니다.

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

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

내게 말해보라. 그러면 잊어버릴 것이다.
내게 보여주라. 그러면 기억할지도 모른다.
나를 참여시켜라. 그러면 이해할 것이다.
- 필립 코틀러, ‘마켓 3.0’에서 인용한 중국 속담

그래서 인가요. 교육할때 보면 강의시간에 집중을 잘 못하던 친구들도 다 같이 참여해서 뭔가를 만들고 이야기 하라고 하면 곧잘 따라 합니다. (제 강의 스킬이 부족해서 일수도 ^^)
가끔 삼천포로 빠져서 넋두리와 재테크에 대한 이야기로 꽃을 피우긴 하지만 참여형 교육이 확실히 좋은거 같습니다.

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

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

결함이 발생하여 이를 수정하는데 있어 프로젝트 초기에는 1의 비용이 들어간다.
코딩/테스팅등 개발할때는 10의 비용이 들어간다.
개발이 끝나서 고객에게 릴리즈 된후에는 100의 비용이 들어간다.


Early Testing 이 중요하다.

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

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

바둑 프로기사들은 100수 이상을 내다보기도 합니다. 어떻게 이런 일이 가능할까요?

바둑 기사들이 처음부터 100수 앞을 내다 보는 것이 아닙니다. 처음에는 정석이라는 것이 몸에 익숙해 질때까지 수없이 반복합니다. 그런 다음 복기라는 리뷰 과정을 통해서 자신이 실수한 것을 돌아봅니다. 이런 일이 반복됨으로써 다양한 수를 내다볼 수 있게 됩니다.

개발자들에게 있어 복기는 코드리뷰라고 볼 수 있습니다. 조금 넒게 보면 회고를 들수도 있을거 같네요. 처음부터 슈퍼 개발자가 될 수는 없습니다.

간단하면서도 효율적인 코드를 하나씩 하나씩 익혀나가면서 리뷰와 회고를 통해 돌아본다면 효과적인 수련이 될거라 봅니다.

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

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

Methods & Tools 에서 UML 사용에 대한 설문조사를 진행했습니다. 이 결과를 통해 UML이 현재 어느정도 사용되고 있는지 살펴봤습니다.

Not using	30%
Partial implementation (adoption of some UML techniques)	25%
Partial deployment (some projects are using UML)	20%
Deployed (all new projects are using UML)	14%
Abandoned	11%

Participants: 134
Ending date: May 2010

부분적 사용, 전면사용, 검토를 합치면 대략 60%정도가 나오네요. 이정도면 아직도 UML이 널리 사용되고 있다고 봐야 할거 같습니다. 설문 참석자수가 좀 적으니 감안해서 보세요.

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

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

포스코 VP 전사 협의회, 킥오프라는 기사를 보고 궁금해 졌습니다. VP가 뭘까? 구글링을 해보니 VP관련한 도서도 나와 있는것을 알게되었습니다.

비주얼 플래닝 카테고리 경제/경영 지은이 정택룡 (위즈덤하우스, 2010년) 상세보기

강한 현장이 강한 기업을 만든다 카테고리 경제/경영 지은이 허남석 (김영사, 2009년) 상세보기

이 비쥬얼 플래닝에 대한 포스코 사례를 정리한 책같습니다. VP와 애자일의 유사성을 많이 이야기 하는데 그래서 누군가는 VP를 드러내기라고 정의합니다.


자세한 내용은 잘 모르겠습니다만 현황판을 유지하는 형태나 기립회의등을 보건데 스크럼과 유사한 형태의 프로세스로 보입니다.

관련기사: 포스코 일 혁신 학습 원스톱 서비스

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

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

대기업에서 프로세스에 대한 기준으로 많이 사용하는게 CMMI 모델입니다. 모르시는 분들을 위해 CMMI 모델의 정의를 위키피디아에서 옮겨 왔습니다.

CMMI(Capability Maturity Model Integration, 역량 성숙도 모델 통합) : 소프트웨어와 시스템 공학의 역량 성숙도를 평가하는 모델 (출처: 위키피디아)

그럼 이 CMMI가 실제 소프트웨어 개발에 얼마나 유용할까요?

4/28일 전자신문에 실린 기사에 따르면 2009년 9월 기준으로 CMMI 레벨 2.63이상의 인증을 받은 한국 기업은 147곳입니다. 하지만

CMMI는 물론이고 GS인증을 여러 번 받은 기업도 SW 결함수가 줄지 않는다 기업들이 SW개발 프로세스를 표준화하지 않아 품질이 향상되지 않는 악순환이 반복되고 있다

이 말은 이렇게 해석할 수 있습니다. 인증은 인증일 뿐이고, 일은 일일 뿐이고 ^^;

그렇다면 이 CMMI를 실제로 일을 하는데 유용하도록 만들려면 어떻게 해야 할까요. 이 모델은 소프트웨어 프로세스 성숙도를 5개 단계로 구분합니다.

• 레벨1(Initial)
• 레벨2(Managed)
• 레벨3(Defined)
• 레벨4(Quantitively Manage)
• 레벨5(Optimising)

이 단계중에서 우리가 집중해서 봐야하는 것은 레벨5입니다.

레벨5: 지속적인 개선에 치중한다. 조직적으로 최적화된 프로세스를 적용하여 다시 피드백을 받아 개선하는 상위 단계이다.

이 정의에 따르면 레벨5는 지속적으로 개선을 해야함을 의미합니다. 현실에 안주하는게 아니죠. 뭔가 연상이 팍 되지 않으세요. 애자일 개발과 너무 잘 어울리는 단계입니다. ^^

애자일을 이용하면 CMMI와 같은 프로세스 성숙도를 이룰 수 있느냐는 질문은 잘못된 질문입니다. 비교대상이나 대체물로 말할 수 없기 때문이죠. 그것 보다는 CMMI를 장농면허로 만들지 않고 실제로 쓸 수 있는 라이센스로 만들기 위해서 애자일의 실천법들을 활용하는 것이 좋은 접근이라 생각합니다.


참고자료
[1] Scrum and CMMI Level 5: A Magic Potion for Code Warriors
[2] An Agile vs CMMI Comparison

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

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

스크럼을 진행하는데 있어 프로젝트 현황판은 정말 중요한 요소입니다. 이 현황판이 없으면 일일 스크럼조차도 제대로 진행할 수가 없습니다. 스크럼을 가르치면서 한가지 특이한 현상을 발견했습니다.

현황판은 일일 스크럼때만 업데이트 하는거라고 그렇게 이야기 해도 자꾸 태스크를 완료로 옮기려 듭니다. 옮겨놓고 짝과 하이파이브를 하며 좋아합니다.
다음 스토리를 뭘 가져올지 쳐다보며 좋아합니다.

사실 이 상황은 상식적으로 이해가 안갑니다. 개발을 즐긴다는게 눈에 보여 즐겁습니다만 일을 더 많이 하면서 좋아하는거는 참..^^

스크럼책을 보면 현황판은 일일 스크럼때만 업데이트하라고 합니다. 하지만 굳히 업데이트 하려 든다면 말릴 필요는 없는것 같습니다. 큐에 쌓여있는 일을 빨리 치우고 싶은 욕구를 막기보다는 권장하는게 낫습니다.

사람들에게 가장 큰 동기를 부여하는 것은 일이 진행되고 있다고 느끼게 하는 것 입니다. (출처)

현황판은 일의 진행을 시각적으로 표현하는 대시보드로 적격 입니다.

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

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

이전에 프로세스 모델이 필요하다고 했습니다. 또 필요한 것이 무엇일까요.

프로세스를 제대로 적용하고 있는지 확인할 수 있는 체크리스트가 필요합니다.

스크럼을 제대로 적용했는지 확인하기 위한 것으로  Scrum Checklist가 있습니다.

이 체크리스트는 헨리 크리닉 버그가 만든 것으로 스크럼을 제대로 적용하고 있는지 확인하는데 유용합니다. 링크를 따라가 보시면 우곤님이 번역하신 한글판도 있습니다.

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

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

세일즈포스 닷컴 애자일 도입에 대해 Agile 2007 Conference에서 발표한 자료입니다. 2007년 자료니 좀 지났습니다만 애자일 도입사례로 참고하기에 좋은거 같네요.

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

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

"애자일도입에 대기업이라고 딱히 뭐가 다르겠냐. 어차피 다 똑같은거 아니냐"고 생각할 수 있습니다. 하지만 아무래도 많은 사람들이 있다보니 쓸데없어 보이는 것들이 필요한 경우가 왕왕 생깁니다. 대기업에서 애자일을 도입할때 중요하게 생각해야 하는 것에는 어떤 것들이 있을까요?

얼마나 적용되고 있는가를 파악하기 위한 모델이 필요합니다.

프로세스 성숙도에 대한 모델은 CMMI가 대표적입니다. 사실 애자일을 이런 모델로 표현하는 것은 한계가 있습니다만 대기업에서는 필요합니다. 이런때 참고할 수 있는게 APMM입니다.

APMM(Agile Process Maturity Model)은 IBM의 방법론/애자일 멘토인 스캇 앰블러(Scott Ambler)가 정의한 성숙도 모델로 크게 3가지 수준으로 되어 있습니다.

• 레벨1: Scrum, XP, AM(Agile Modeling)과 같은 애자일 프로세스가 시스템을 개발하는 과정의 하나로 들어가는 단계
• 레벨2: 시스템을 개발하는 전 과정이 OpenUP나 DSDM과 같은 애자일 프로세스로 구성되는 단계
• 레벨3: 대규모 팀이나 분산팀에 애자일 프로세스를 적용하는 단계

이 모델이 맞다고 볼 수는 없습니다만 이런 모델을 참조해서 회사에 맞는 성숙도 모델을 가져가는것이 애자일을 체계적으로 도입하는데 도움이 되지 않을까요.
 

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

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

TDD 메일링 리스트를 통해 How To Make Your Java Code Understandable이라는 글을 우연히 봤습니다. 이 기사에 나오는 코드 예를 통해 어떤 코드가 읽기 쉬운 코드인지 알아보겠습니다.

첫번째 코드입니다.
coffeeShop.placeOrder(1);
커피숍에서 주문을 하는 코드입니다. 하지만 1이 무엇을 의미하는지 모르겠네요

두번째 코드입니다.
coffeeShop.placeOrder(1); // 1 is small cup size
이번에는 1이 무엇을 의미하는지 주석으로 설명하고 있습니다.

세번째 코드입니다.
enum CoffeeSize {SMALL, MEDIUM, LARGE }
coffeeShop.placeOrder(CoffeeSize.SMALL);
주석은 없지만 두번째 코드보다 가독성은 더 좋아 보입니다.

더 나은 코드를 만드는것은 작은 차이입니다.

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

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

좀 지난 기사입니다만 SAP가 자사의 SW 개발에 새로운 바람을 불어넣기 위해 애자일을 선택했다는 기사가 ZD Net에 실렸습니다.(기사원문)

사실 SAP가 어떤 회사입니까. 1972년 독일에서 시작한 SAP는 R/3 라는 솔루션으로 세계 ERP시장을 독식하다 시피 하는 전통적인 소프트웨어 회사입니다.[출처]

SAP는 엔지니어 1만2천명 가운데 20%를 애자일을 활용하도록 결정했으며 올해 애자일을 전체 개발 사업부에 도입할 계획이다.

성격은 좀 다릅니다만 SAP와 같은 엔터프라이즈 회사의 애자일 도입은 저처럼 대기업에서 애자일 확산을 진행하는 사람에게 큰 힘이 되는것 같습니다.

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

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

하인리히의 법칙을 들어보셨습니까. 1:29:300의 하인리히 법칙은 하나의 대형사고에는 29개의 경미한 사고가 이미 있었고, 또 29개의 경미한 사고 전에는 300개에 가까운 예상징후가 있다는 법칙입니다.

망하는 프로젝트에서도 수많은 징후가 나타납니다만 대부분 모르고 지나친다는게 문제입니다. 프로젝트도 망하기 전에 여러가지 징후를 보입니다.

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

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

애자일쪽 이야기를 많이 하면서도 정작 설계에 대해서는 크게 고민 안했던거 같습니다. 그래서 이번에는 애자일 모델링에 대해 생각해 보려 합니다.

애자일 모델링 하면 나오는 첫번째 레퍼런스가 스캇 앰블러(Scott W. Ambler)가 쓴 agile modeling입니다. 대머리여서 발표할때 반짝반짝 빛나던(?) 모습의 스캇 앰블러가 생각납니다. Agile2009 마지막 날에 CSM의 유효성을 꼬집는 그의 세션을 들은 적 있습니다.

애자일 모델링의 근본을 이루는 원칙에는 다음과 같은 것들을 들 수 있습니다.

• 모델이 단순해지도록 합니다.
• 변화를 기꺼이 받아들입니다.
• 조금씩 추가해 나갑니다.
• 빠른 피드백을 받습니다.
• 모델은 목적이 있어야 합니다.
• 필요하면 여러개의 모델을 유지합니다.
  

이런 원칙에서 가장 중요한 것은 모델을 어떻게 표현하느냐 보다는 어떤 내용을 표현할 것인가(content is more important than representation)에 집중해야 한다는 것입니다.

아래 그림은 위 원칙을 기반으로 어떻게 애자일 모델링을 해야하는지 애자일 모델링의 전체 프로세스를 상위 수준에서 보여줍니다.

프로세스가 있으면 이 프로세스에 따라 실제 모델링 작업을 진행합니다. 이때 사용할 수 있는 기법들 입니다.

애자일 모델링에서는 여러 모델을 동시에 작업하면서 점진적으로 조금씩 키워 나갑니다. 그러면서 여러사람의 피드백을 받아서 확신을 가져야 합니다. 모델은 코드가 아니기 때문에 이 모델이 정말 맞는지 확신을 갖기 어렵습니다. 실제 코드를 짜보기 전까지는...

시간을 두고 공부해 볼 주제인거 같습니다.

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

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

Indeed는 글로벌 취업정보 사이트입니다. Indeed의 trend 서비스는 특정 키워드에 해당하는 직종이 과거 4년동안(현재는 2005년 7월부터 2009년 7월사이) 얼마나 성장했는지 추세를 보여 줍니다.

예전에 소프트웨어 개발자가 애자일 프로젝트를 경험했다면 더 많은 연봉을 받을 수 있다고 들었는데 정말 그런지 한번 살펴보겠습니다.

먼저 그냥 소프트웨어 엔지니어로 검색해 봤습니다. 대충 봐도 성장세가 1.5배가 안되는 것으로 나옵니다.


이번에는 가장 많이 사용된다는 '스크럼'으로 검색한 결과입니다. 4배정도 상승한 것으로 나오네요.


일반적 용어인 '애자일'로 검색한 결과입니다. 훨씬 크게 10배 상승한 것으로 나옵니다.



잡의 비율이 적어서 조금만 늘어도 상승폭이 높다는데 주의해야 합니다. 하지만 가파른 증가세에 있다는 것도 무시할 수는 없습니다.  이 데이터들을 바탕으로 다음과 같은 결론을 내릴 수 있을것 같습니다.

애자일 관련 직종은 아직 시작단계이며 2~10배의 가파른 성장세를 나타내고 있는 유망한 분야이다.

애자일 관련 현황 조사를 위해 정리해 봤습니다.

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

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

VersonOne은 애자일 관련 툴을 개발하는 회사중 꽤 비중이 큰 곳입니다. 매 분기마다 애자일 도입에 대한 설문조사를 진행합니다. 설문이라는 건 대상이 누구냐에 따라 편향될 수 있지만 2009년 동향을 확인하는 측면에서 의미 있다고 봅니다.

2009년 7월부터 12월까지 총 2570명의 참가자를 대상으로 이루어진 조사이며 제가 생각했을때 의미있는 부분만 몇개 뽑아봤습니다.


500명 이상의 대기업에서 애자일을 도입하는 경우가 약 25% 정도 되는것으로 나옵니다. 애자일이 소규모에서만 쓰인다는건 옛말입니다. (제가 지금 번역하는 Enterprise Scrum은 2007년에 나왔군요.)


역시 가장 널리 사용되는 것은 스크럼이군요. 이 부분은 작년 2008년과 큰차이가 없는거 같습니다.


애자일 도입 실패원인중 가장 큰것은 무엇인가? 애자일 기법에 대한 경험 부족과 문화적 차이가 1,2위입니다. 전 2위가 더 크다고 생각하는 편입니다. 기법에 대한 경험이나 지식은 노력으로 해결 가능한 부분입니다만 문화는 하루 이틀 노력한다고 되는게 아닌거 같습니다.


애자일을 도입하는 가장 큰 이유는 무엇입니까? 역시 돈입니다. 시장점유율을 높히기 위해 빨리 제품을 내놓기 위해서 입니다. 애자일 도입의 어려움 이기는 방법은 강력한 계기입니다. 가장 좋은 계기는 돈입니다. ^^


가장 많이 쓰이는 애자일 툴은 다름 아닌 엑셀입니다. VersionOne은 18% 정도 되는걸 보고 배좀 아팠을거 같네요. 저도 백로그는 대부분 구글독의 스프레드시트에 정리하는데 그 정도면 충분하다고 생각합니다. 실제로 프로젝트 진행할 때는 이런 도구보다 직접 손으로 써서 붙이는게 더 좋은거 같습니다.

한두개만 넣으려다 거의 다 넣어버렸네요. 나머지는 원본을 참고하세요.

2009_State_of_Agile_Development_Survey_Results.pdf

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

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