2012. 1. 26. 10:20 IT

미카도 메소드 : 리팩토링, 리스트럭처링을 위한 사고 도구 "a tool for large scale refactoring"

교육용 완구, 보드게임으로 분류되는 미카도 게임과 유사한 개념임에 착안하여 명명지었다고 합니다.



물론 이게임을 소개하자는건 아니고..

대규모 코드 베이스를 변경, 개선하는 것은 쉬운 일이 아닙니다.
하지만 그래도 손대야 한다면?
안전하게, 확실하게 변경하기 위해 추천하는 방식입니다. (물론 그전에 [Working effectively with legacy code] 책을 먼저 추천합니다. )

간단한 모듈의 수정은 과감한 리팩토링을 해볼만 하지만, 그 규모가 인간의 단기기억 저장소를 넘어서는 단계에 이르면 (빅데이터냐..) 어느순간 되돌리기도, 계속 나아가기도 어려워집니다. 

미카도 게임은 기다란 나무 막대들(mikado stick)을 윷처럼 던져 막대들이 쌓이면, 주위 막대를 건들지 않도록 하면서 하나씩 들어올려 가장 높은 점수를 얻는 게임입니다.
( 자세한 게임룰 소개는  쇼핑몰에서 검색하여 제품소개를 보면 알 수 있고, 제네스 님의 설명도 이해에 도움이 됩니다.   http://blog.naver.com/PostView.nhn?blogId=genes75&logNo=100000447201  )

이것이 바로 리팩토링, 리스트럭처링을 할때 제안하는 작업 방식에 대한 은유가 되는거죠..

높은 점수의 막대 (목표, goal) 를 들어올리기 위해서는
더이상 건들 막대가 없는(그 위에 쌓인게 없는) 막대(전제조건, prerequisites)를 먼저 들어올려야 한다는 생각이고,
이를 그래프화 한 것이 바로 미카도 그래프가 됩니다. 

제안자들이 제시하는 규칙 혹은 가이드라인은 다음과 같습니다.
1. 가장먼저 목표(goal)를 적는다.
2. 시도해볼 것을 찾아내고 
3. 깨진 코드에서 돌아오고 (roll back)
4. 순환해서 전제조건들( prerequisites )을 고쳐나간다. 

아래는 미카도 그래프의 예시입니다.
그래프가 다 그려지면 제일 위에 있는 나뭇잎부터 해결하면서 체크하면 됩니다.
마지막에는 최종 목표인 "Stranger Erons 사에 새로운 제품" 을 달성하게 된다.


출처 : [Beheading the software beast] Draft버전 , Daniel Brolund외,  pdf본 p46 그림 2.16


느낀점.

심플하지만 활용도가 높은 방법이 될듯. (물론 어느정도의 규모의 복잡도가 있어야 가치가 있다.)
목표를 중심에 두고 생각 하는 것이 중요하며, 복잡한 연관관계를 머릿속에 (물론! 머릿속에서 위와 같은 그림을 그려버리는 능력자들은 존재한다. ) 그려내기 보다 시각적으로 표현하는 것이 좀더 효과적이란것.
그리고 (정말.. 별걸 다 만들었다 싶은.. )

참고로 Method&Tools 2012 Jan. 메일을 통해서 알게되었습니다. 

관련자료
- 홈페이지 :   http://mikadomethod.org/
- PDF :  Beheading the software beast   http://www.agical.com/mikmeth/mikadomethod.pdf 
- JavaZone 동영상 : http://vimeo.com/28765431  Sep 8 2011. Oslo, Norway
posted by smplnote
2011. 12. 23. 08:33 IT
http://www.methodsandtools.com 에서 메일링으로 보내는 뉴스레터입니다.

여기에 항상 재미난 자료가 많이 나와서 관심있게 지켜보고 있는 편입니다.


어떤 주제가 나왔는지 목차 먼저

* How to Make Your Culture Work with Agile, Kanban & Software Craftsmanship  1)
슈나이더의 문화 모델에 따라 각각을 협력(Collaboration)과 성장(Cultivation), 통제(Control), 경쟁(COMPETENCE) 으로 나누어
설명해주고 있습니다.
* How Software Architecture Learns 2)
Russel Brand의 "How Buildings Learn"의 독후감이랄까.. 건축과 소프트웨어를 비교하여 서로의 배울점을 비교해서 설명하고 있습니다.

* Understanding of Burndown Chart 3)
애자일의 가장 기본적인 매트릭인 번다운 차트에 대한 설명

* The Psychology of UX - Part 2
-> 이건 part 1을 읽어야 해서 생략.

* Tools: Cucumber, Sureassert, ChiliProject, Scrum-it 4)
저는 이 툴쪽도 늘 관심있게 보는 편입니다.
Cucumber는 예전부터 알려져있던 툴이고..
Sureassert는 어노테이션 기반 단위테스트 툴인데... 어노테이션 써보려는 아이디어는 저도 제작년에 잠깐 고민했었던 기억이 납니다.
ChilliProject는 redmine의 fork라고 하고..
Scrum-it 은 예전에도 본거 같긴 한데 홈페이지 동영상에서 보여주는
그런 커다란 멀티터치 스크린을 사려면... 배보다 배꼽이 커지지 않을까 싶은 생각이 들더군요..

=============================================================

1) 요약
애자일을 방법론류가 아닌 문화로 바라보도록 하는 시각..
문화는 슈나이더의 문화 모델에 따라 네가지로 분류되는데, 협력(Collaboration)과 성장(Cultivation), 통제(Control), 능력(COMPETENCE) 입니다.


애자일 문화는 협력(Collaboration)과 성장(Cultivation)이라고 합니다.
칸반(Kanban)의 문화는 통제(Control)에 가까움 (애자일은 사람을 우선으로 하고, 칸반은 시스템 우선적이라고 분류합니다.)
물론 통제를 필요로하는 조직, 회사의 입장에서는 스크럼보다는 더 좋은 툴로 활용될수 있다고 하는군요.
소프트웨어 장인정신(Software Craftsmanship)은 능력(COMPETENCE)의 문화라고 봅니다. 
XP의 주요 프랙티스인 refactoring, tdd, atdd, 지속적통합(continuous integration), 지속적배포(continuous deployment), 코드 소유권 공유(shared code ownership), 깔끔한코드(Clean code) 등으로 대표된다.
기존에 통제 문화인 곳에서는 협력이나 경쟁 쪽으로 조심스럽게 나아가도록 권유하고 있다. 
ref) 그림 http://agilitrix.com/2011/04/software-craftsmanship-promotes-competence-culture/
스크린 캐스트 http://agilitrix.com/2011/05/screencast-how-to-make-your-culture-work-with-agile/


 
2)
Russel Brand의 "How Buildings Learn"
- 건물 설계자로부터 배울수 있다. -> 유지보수와 확장성
- 건물 설계자들과 같은 실수를 할 수 있다. 
- 반대로 건물 설계자들은 소프트웨어 설계자로부터도 배울 수 있다. -> 애자일 테크닉
 
 
3) 
스타트업 입장에서 애자일은 product에 집중하도록 해주기때문에 좋은 방법이다. 
 
remaining effort for a given period of time (sprint or release)
X : working day
Y : remaining effort (회사마다 다르게 적용)
 
cf) 
X = Story수 -> 각 스토리는 노력의 규모가 다르므로 실제 진행상태 설명에 적절하지 않다.
X = 시간 => 지나치게 세분화된 관리가 된다.
X = 남은 크기 (remaining size) story point => 계단현상이 나타난다 ( 데일리 미팅을 통해 해소할수 있다.)
 
부가작업이 추가된 경우 발생하는 진척 차이를 설명하기 위해 스프린트 백로그 총계를 표현하는 추가적인 지표가 필요할수도 있다.
 
주의할것은 velocity는 팀의 지표나 KPI가 아니다. 수행가능성을 계획하는데 쓰는 도구(capacity planning tool)일 뿐이다.
 
4) 
- Cucumber 
BDD 툴  http://cukes.info/  v1.1.2 
지원언어 : java ruby .Net
License : MIT License
Given When Then 방식으로 진행
 
장점 : 사례와 자동화의 분리 (코드와의 분리를 뜻하는듯), 지나치지 않는 구조화(심플?)
단점 : 여분의 오버헤드 (개발자만 쓸거라면 rspec이 더 낫다), 정규표현식의 복잡함
 
- Sureassert
어노테이션 기반의 unit testing 도구, 커버리지 제공
www.sureassert.com
대상언어 : java
requirement : Eclipse 3.4 + distro 
License : open source & free 
 
흐름 : declaritive testing -> test execution -> coverage reporting -> 다시..
ex)
@Exemplars(set={
 @Exemplar(instance="'hamburger'", args={"4","8"}, expect="'urge'"),
 @Exemplar(instance="'smiles'", args={"1","5"}, expect="'mile'"),
 @Exemplar(instance="'negtest'", args={"-1","5"},
      expectexception="StringIndexOutOfBoundsException") })
public String substring(int beginIndex, int endIndex);
 
- ChiliProject
웹기반 프로젝트 관리도구
이슈추적, 프로젝트 계획(애자일,스크럼 지원), 시간추적,위키,VCS통합...
http://www.chiliproject.org
requirement : ruby(1.8.7 over), db(mysql,,,)
ROR로 만들어짐.
License : GNU GPL v2
 
redmine에서 fork된 프로젝트임 (redmine이 너무 폐쇄적이라고 판단해서..)
 
 
- Scrum-it
가상 스크럼보드 
http://www.scrum-it.ch 
License : CC By 3.0 
스위스 쮜리히의 BSgroup Technology Innovation AG에서 개발.
기술기반 : java j2ee,  mysql and tomcat , html5, css3, jQuery mobile 
흥미로운건 아이패드에서 보여지는것과 멀티터치 지원..
 
posted by smplnote