실용주의이야기(Pragmatic Story) ::

모델링도 애자일로 해보자

Work & Study/애자일 개발 2010/02/26 11:02 posted by k16wire

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

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

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

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

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

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

[AMDD, Agile Model Driven Development]

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

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

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

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > 애자일 개발' 카테고리의 다른 글

프로젝트가 망하기 전에 나타나는 징후 (11)	2010/03/04
모델링도 애자일로 해보자 (0)	2010/02/26
애자일 관련 직업(job) 얼마나 성장하고 있는가 (3)	2010/02/23
2009년에는 애자일이 얼마나 성장했을까 (2)	2010/02/22
좋은 디자인이란? (0)	2010/02/11
요구사항이 라면 심부름이라면 (4)	2010/01/26

TAG 애자일, 애자일모델링

받은 트랙백이 없고 , 댓글이 없습니다.

애자일 관련 직업(job) 얼마나 성장하고 있는가

Work & Study/애자일 개발 2010/02/23 13:09 posted by k16wire

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

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

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

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

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

agile Job Trends graph

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

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

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

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > 애자일 개발' 카테고리의 다른 글

프로젝트가 망하기 전에 나타나는 징후 (11)	2010/03/04
모델링도 애자일로 해보자 (0)	2010/02/26
애자일 관련 직업(job) 얼마나 성장하고 있는가 (3)	2010/02/23
2009년에는 애자일이 얼마나 성장했을까 (2)	2010/02/22
좋은 디자인이란? (0)	2010/02/11
요구사항이 라면 심부름이라면 (4)	2010/01/26

TAG 스크럼, 애자일 소프트웨어 개발

트랙백 2개 , 댓글 3개가 달렸습니다.

2009년에는 애자일이 얼마나 성장했을까

Work & Study/애자일 개발 2010/02/22 12:16 posted by k16wire

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

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > 애자일 개발' 카테고리의 다른 글

모델링도 애자일로 해보자 (0)	2010/02/26
애자일 관련 직업(job) 얼마나 성장하고 있는가 (3)	2010/02/23
2009년에는 애자일이 얼마나 성장했을까 (2)	2010/02/22
좋은 디자인이란? (0)	2010/02/11
요구사항이 라면 심부름이라면 (4)	2010/01/26
리팩토링을 하면 안되는 진짜 이유 (4)	2010/01/23

트랙백은 하나 , 댓글 2개가 달렸습니다.

좋은 디자인이란?

Work & Study/애자일 개발 2010/02/11 15:47 posted by k16wire

요즘 팀에서 '설계'에 대한 교육과정을 만들고 있습니다. TDD 메일링 리스트를 읽던 중 좋은 디자인 good design 이란 단어가 눈에 띄어 옮겨봤습니다. 밥 아저씨가 한 말입니다.

One reasonable definition of good design is testability. It is hard to imagine a software system that is both testable and poorly designed. It is also hard to imagine a software system that is well designed but also untestable.

Robert C. Martin (Uncle Bob)

설계의 끝이 어디냐? 저는 '개발을 시작할 수 있는 곳'이라고 생각합니다.

그럼 좋은 설계는 뭐냐? 개발된 코드가 테스트 하기 좋으면 좋은 설계다. 이 두 질문을 합쳐보면 어떻게 설계를 해야 하는지 답이 나오는 거 같습니다. :-)

한편으로 초보자도 숙련자처럼 잘 쓸 수 있게 만든 UI가 잘 만든 UI이듯 좋은 설계는 초보 개발자도 숙련 개발자 처럼 잘 이해할 수 있게 만든것은 아닐까요.

좋은 설계는 테스트를 잘 할 수 있는가(testability)로 정의할 수 있습니다. 설계의 목적은 결국 무엇입니까? 잘 작성된 설계 산출물을 만드는건가요? 아닙니다. 결국 잘 동작하는 시스템을 만드는 것입니다.

설계, 개발, 테스트는 따로 분리할 수 있는 작업이 아니라 한꺼번에 이루어져야 합니다.

그럼 테스트 용이성은 또 뭐라고 정의할 수 있을까요 ? :-)

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > 애자일 개발' 카테고리의 다른 글

애자일 관련 직업(job) 얼마나 성장하고 있는가 (3)	2010/02/23
2009년에는 애자일이 얼마나 성장했을까 (2)	2010/02/22
좋은 디자인이란? (0)	2010/02/11
요구사항이 라면 심부름이라면 (4)	2010/01/26
리팩토링을 하면 안되는 진짜 이유 (4)	2010/01/23
구글이 만든 새로운 언어 Go (0)	2010/01/21

트랙백은 하나 , 댓글이 없습니다.

광고인 '이제석'을 알다.

Work & Study/TechTalk 2010/01/31 22:15 posted by k16wire

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

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

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

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

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

대학 급수로 사람을 평가하는 이 더러운 세상이 싫어서 유학을 감행한 그 용기도 멋지지만 이후 행보가 사람을 감동하게 합니다. 사실 미국이라고 텃세나 차별이 없나요. 인종차별은 Made in USA

동양인, 그것도 남학생은 관심밖이었다고 하네요. 그래서 학교밖, 광고대전에 응모해서 많은 상을 받습니다.

싸움이 불리하면 룰을 바꿔라.(출처:광고인 이제석)

아래 광고는 이제석씨가 독도영유권을 주장하는 일본의 만행을 세상에 알리기 위해 뉴욕곳곳에서 진행했던 게릴라 광고입니다.

그 만큼 미국에서 잘 나가면 굳히 돌아오지 않아도 됐을텐데 2008년 한국에 돌아온 이후 비영리 단체 후원과 광고 교육원 설립을 위해 기획중이라 합니다.

가르쳐 주는 것 없이 대학 등록금이나 삼키는 대학들 내가 다 망하게 할 겁니다.

인터뷰: 신기한 인간 뉴욕의 광고인 이제석

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > TechTalk' 카테고리의 다른 글

광고인 '이제석'을 알다. (0)	2010/01/31
Testable Java (0)	2009/11/21
추정에 대하여 (0)	2009/10/26
테스트 데이터를 효과적으로 만드는 방법 (2)	2009/10/19
Mock 객체가 단위테스트를 컨텍스트와 분리하는일만 하는 것은 아니다. (0)	2009/10/18
XP 개발자 VS 스크럼 개발자 (2)	2009/10/04

받은 트랙백이 없고 , 댓글이 없습니다.

요구사항이 라면 심부름이라면

Work & Study/애자일 개발 2010/01/26 21:20 posted by k16wire

며칠전 일입니다. 사내 IT관련 교육기관에서 외부 강사를 뽑는데 와서 심사를 해달라고 해서 갔습니다. 전문적으로 강의를 하시는 분들이어 그런지 참 강의 잘하시더군요.

심사자라고 앉아있었지만 부끄러웠습니다. 반대로 많이 배우고 양념으로 요구공학 강의하신 분이 사용하신 비유가 너무 좋아 남겨 둡니다.

우리가 하는일을 '라면 심부름'에 비유해 보겠습니다. 고객이 말했습니다.

라면 사다 주세요.

그럼 우리 어떻게 하죠. 예 라면 사러 갑니다. 라면은 2시간 이내에 사와야 합니다. 2시간을 넘으면 페널티를 물게 됩니다. 라면을 파는 가게까지 가는데는 50분이 걸립니다.
열심히 라면을 사서 돌아오는 중입니다. 거의 다 왔는데 고객이 전화를 합니다.

무슨 라면 사오셨어요?
신라면이요.
어 전 매워서 신라면 싫어하는데...삼양라면으로 사다 주시면 안되나요.
....

우리가 할 수 있는 일은 뭐가 있을까요? 택시를 타고 빨리가서 사오는 방법이 있습니다. 하지만 택시비가 들어갑니다. 아니면 걸어가면 50분이 걸리는 길을 열심히 뛰어 가야 합니다.

만약 라면을 잘 아는 사람이었다면 라면을 사다 달라는 고객 요구에 이렇게 말했을 겁니다.

무슨 라면 사다드릴까요?

만약 그랬다면 택시를 타거나 뛰어갔다와야 하는 일은 발생하지 않았을 겁니다. 그러려면 라면에 대한 지식을 알고 있어야 그런 질문이 가능합니다. 이게 바로 업종지식, 기술지식 입니다.

라면파는 가게에 어떻게 하면 빨리 갔다 올수 있는지 길을 잘 알아도 유리합니다. 여기서 길은 방법론, 프로세스에 해당한다고 볼 수 있습니다.

고객도 자기가 원하는 것을 잘 모를수 있습니다.

너무 미워하지 말고 서로 잘 맞춰나가면 좋은 결과가 나오지 않을까요. :-)

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > 애자일 개발' 카테고리의 다른 글

2009년에는 애자일이 얼마나 성장했을까 (2)	2010/02/22
좋은 디자인이란? (0)	2010/02/11
요구사항이 라면 심부름이라면 (4)	2010/01/26
리팩토링을 하면 안되는 진짜 이유 (4)	2010/01/23
구글이 만든 새로운 언어 Go (0)	2010/01/21
Standish Group Report - Chaos (0)	2010/01/12

TAG 요구사항

트랙백은 하나 , 댓글 4개가 달렸습니다.

리팩토링을 하면 안되는 진짜 이유

Work & Study/애자일 개발 2010/01/23 23:52 posted by k16wire

훌룡한 프로그래머는 어려운 문제를 간단한 방식으로 해결함니다. (출처: 훌룡한 프로그래머의 딜레마)

이 글을 읽다가 언젠가 프로젝트에서 있었던 일이 생각났습니다.

개발이 한창 진행중이어서 코드 리뷰를 진행했습니다. 별로 복잡할 이유가 없는데 아키텍처가 복잡했습니다. 그러다 보니 코드도 괜히 길고

복잡했습니다. 리팩토링을 제안했습니다. 기대했던 대로(?) 안된다는 이유가 주루룩 나왔습니다. 그 중 결정적 이유 하나..

LOC(Line of Code) 가 개발자 단가 산정 기준에 들어갑니다.

더 이상 할 말이 없어서 포기했습니다. 이렇게 살지 맙시다. ^^;

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > 애자일 개발' 카테고리의 다른 글

좋은 디자인이란? (0)	2010/02/11
요구사항이 라면 심부름이라면 (4)	2010/01/26
리팩토링을 하면 안되는 진짜 이유 (4)	2010/01/23
구글이 만든 새로운 언어 Go (0)	2010/01/21
Standish Group Report - Chaos (0)	2010/01/12
마음이 열리면 생각도 열린다. - 열린모임 (2)	2010/01/08

받은 트랙백이 없고 , 댓글 4개가 달렸습니다.

구글이 만든 새로운 언어 Go

Work & Study/애자일 개발 2010/01/21 18:45 posted by k16wire

'Go'라는 언어가 있습니다. Google이 새롭게 만든언어 라고 합니다. 일단 간결하고 구글 스러운 이름은 참 마음에 듭니다. InfoQ에 실린 Google Go A Primar 에서 이렇게 Go에 대해 정의하고 있습니다.

구글 Go는 새로운 프로그래밍 언어로서 여전히 시스템 영역에서 인기를 끌고 있는 C를 기반으로 현재 사용하는 프로그래밍 언어의 장점들을 모아 설계 되었다. 아직도 진화중에 있다.

실제로 언어를 보면 C 언어와 유사합니다. 하지만 변수 선언은 비쥬얼 베이직을 떠올리게 만듭니다. 가비지 컬렉션을 지원하는건 가상머신 기반의 언어와 유사합니다.
하지만 여러개의 리턴값을 지원하는 등의 기능이 참신합니다. 참 재밌네요.

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > 애자일 개발' 카테고리의 다른 글

요구사항이 라면 심부름이라면 (4)	2010/01/26
리팩토링을 하면 안되는 진짜 이유 (4)	2010/01/23
구글이 만든 새로운 언어 Go (0)	2010/01/21
Standish Group Report - Chaos (0)	2010/01/12
마음이 열리면 생각도 열린다. - 열린모임 (2)	2010/01/08
'애자일 선언'의 원칙이 주는 의미 (0)	2010/01/08

트랙백은 하나 , 댓글이 없습니다.

Standish Group Report - Chaos

Work & Study/애자일 개발 2010/01/12 13:08 posted by k16wire

많은 기사나 책에서 참조로 등장하는 Standish Group 'Chaos' Report

입니다.

chaos-report.pdf

이올린에 북마크하기

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

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

'Work & Study > 애자일 개발' 카테고리의 다른 글

리팩토링을 하면 안되는 진짜 이유 (4)	2010/01/23
구글이 만든 새로운 언어 Go (0)	2010/01/21
Standish Group Report - Chaos (0)	2010/01/12
마음이 열리면 생각도 열린다. - 열린모임 (2)	2010/01/08
'애자일 선언'의 원칙이 주는 의미 (0)	2010/01/08
'애자일 선언'의 가치가 주는 의미 (0)	2010/01/06

받은 트랙백이 없고 , 댓글이 없습니다.

마음이 열리면 생각도 열린다. - 열린모임

Work & Study/애자일 개발 2010/01/08 22:38 posted by k16wire

평소 비형식 컨퍼런스, 열린 모임에 관심이 많습니다. 그래서 이런 모임에는 어떤 것이 있는지 찾아봤습니다.

바캠프((Bar Camp)
자발적인 참여를 기반으로 하는 비형식 컨퍼런스
열린 환경에서 서로 배우고 공유하기 위해 만들어 졌으며 심도있는 토론과 상호 교류, 데모 등이 이루어 진다. 모든 참가자는 하나의 발표를 하거나 자원 봉사자로 참여해야 한다. (출처: BarCamp Seoul, BarCamp)
사례: UX Camp Seoul

푸캠프(Foo Camp)
오렐리에서 매년 여는 해커들의 이벤트
미리 초청자 명단을 정하고 이들이 모두 참여할 수 있는 일정을 화이트 보드에 썼다 지웠다를 반목하며 정하는데서 위키 컨퍼런스라고도 부름. 새로운 기술을 알고자 하는 사람들간에 교류를 높히기 위해 시작함.
(출처: Foo Camp - Wikipedia)

OST(Open Space Technology)
사전에 모임의 상세한 진행이나 발표자를 정하지 않은채 특정 주제나 목적만을 갖고 진행하는 참여 주도형 모임. 적게는 5명에서 많게는 2000명까지 가능하다. 주관자는 모임의 목적을 공지하고, 참여자들이 스스로 세션을 개최한다.(앞에 있는 보드에 세션을 적는데 이 보드를 'Market'이라 부름)
세션별로 둥그렇게 모여 토론을 진행하는데, 참여자들은 자유롭게 세션들을 돌아다니며 중간에 새로운 세션이 열리기도 하고 진행되던 세션이 닫히기도 한다. 이런 OST의 특징을 '주체적 이동의 법칙 The Row of Two Feet'이라 부른다.(출처: Open Space Technology-Wikipidia, 오픈스페이스란?)

대안 언어 축제
다양한 프로그래밍 언어와 관련 기술을 통해 개발자들의 사고와 문제 해결 방식의 지평을 넓히기 위해 발표자와 참여자가 상호 교류하는 축제형식의 컨퍼런스(출처: P-Camp & 대안언어축제 2008)

P-Camp
같은 가치를 추구하지만 상호 이질적인 도메인들간에 커뮤니케이션 통로를 확보하자는 차원에서 기획된 모임으로 IT 개발환경 개선을 지향한다.(출처: P-Camp)

Ignite
오렐리 후원으로 시애틀에서 처음 시작. 발표자는 20장의 슬라이드가 15초 간격으로 자동으로 넘어가는 5분동안 발표를 진행한다. 자유로운 주제를 가지고 전문가가 아닌 일반사람이 참여하는데, 발표자료 역시 글 보다는 그림, 사진, 메시지 위주가 된다.(출처: Ignite-Wikipidia, Ignite Seoul Intro)

페차쿠차(Pecha Kucha Night)
영국출신 건축가 부부가 여행사진을 친구들과 나눠 보고 싶다는 동기에서 처음 시작.
페차쿠차라는 이름은 재잘재잘 이라는 일본어에서 유래했다. 건축, 아트, 디자인에 대한 주제를 다루는데 발표는 20장의 슬라이드를 20초 간격으로 자동으로 넘기면서 6분 40초동안 진행된다. 이를 '20-20'의 규칙이라 부름.(출처: W-Korea 6월,)

제가 아는 것은 여기까지 입니다. 다른 형태를 추가하고 싶으신 분은 댓글 부탁드립니다. 사내에서 맡고 있는 커뮤니티가 하나 있는데 이런 모임들중 하나라도 해봐야 겠습니다.

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > 애자일 개발' 카테고리의 다른 글

구글이 만든 새로운 언어 Go (0)	2010/01/21
Standish Group Report - Chaos (0)	2010/01/12
마음이 열리면 생각도 열린다. - 열린모임 (2)	2010/01/08
'애자일 선언'의 원칙이 주는 의미 (0)	2010/01/08
'애자일 선언'의 가치가 주는 의미 (0)	2010/01/06
플래닝 포커 Planning Poker는 "잘 모르겠다."고 말하는 것 (2)	2010/01/05

TAG 애자일, 열린모임

트랙백은 하나 , 댓글 2개가 달렸습니다.

'애자일 선언'의 원칙이 주는 의미

Work & Study/애자일 개발 2010/01/08 14:28 posted by k16wire

애자일 동맹(Agile Alliance)은 애자일 선언의 '가치'를 실천하기 위해 12가치 '원칙'을 정의했습니다. 이 원칙이 주는 의미도 한번 생각해 보겠습니다.

우리의 최고 가치는 유용한 소프트웨어의 빠르고 지속적인 공개를 통해 고객을 만족시키는 것이다.

연구결과에 따르면 작은 기능을 고객에게 빨리 전달할 수록 품질은 높아진다. 기능을 사용 할 수 있다면 바로 사용하면 되고 아직 부족하면 계속 개발할 지 여부를 결정 할 수 있다.

개발 후반부에 접어들었다 할지라도, 요구 사항 변경을 확인한다. 애자일 프로세스는 고객의 경쟁 우위를 위해 변화를 이용한다.

애자일 개발에서는 고객도 팀의 일원이 된다. 시장의 요구는 변하기 때문에 고객의 요구사항이 시간에 따라 변하는것은 당연하다. 팀은 이를 요구사항의 변경으로 보지 않고 시장의 요구를 더 정확히 알게 된 것으로 본다.

개발 중인 소프트웨어를 2주에서 2개월 사이, 혹은 더 짧은 간격으로 자주 인도한다.

프로젝트 전체 과정 동안 비즈니스를 하는 사람과 개발자는 계속 함께 일해야 한다.

프로젝트를 빨리 진행하기 위해서는 고객, 개발자와 같은 이해 당사자간의 빈번한 대화가 필수적이다. 이를 위해서 함께 같은 장소에서 일하는게 좋다.

의욕적인 개인을 중심으로 프로젝트를 구성한다. 환경과 필요한 것을 지원하고 그들이 그 일을 해 낼 것이라는 믿음을 갖고 일을 맡긴다.

프로젝트에서 가장 중요한 것은 사람이다. 사람에게 장애가 되는 환경은 모두 바꿔야 한다.

개발 팀 내부에서 정보를 전달 및 공유하는 가장 효율적이고 효과적인 방법은 직접 일대일로 대화하는 것이다.

의사소통에서 가장 효과적인것은 직접 이야기 하는 것이다. 문서에 모든 것을 담으려 할 필요는 없다.

개발 중인 소프트웨어가 진척 상황의 일차적 척도이다.

문서가 30% 완성되었다고 해도 시스템이 완성된게 없다면 아무 의미가 없다. 중요한 건 일이 끝나는 것이다.

애자일 프로세스는 지속 가능한 개발을 촉진한다. 스폰서, 개발자, 사용자는 꾸준히 지속가능한 속도를 유지할 수 있어야 한다.

소프트웨어 개발은 마라톤이지 100m 달리기가 아니다. 과도한 근무는 집중력을 떨어뜨리고 피로를 누적시켜 오히려 일을 망치게 된다.

우수한 기술과 좋은 설계에 대한 지속적인 관심은 진행 속도를 향상시킨다.

빨리 개발하기 위해 품질을 낮추는것은 어리석은 생각이다. 초반부터 좋은 품질을 유지하기 위해 노력한다면 오히려 개발이 진행되는 동안 개발속도를 빨라진다.

단순성(아직 끝내지 않은 일의 양을 최대화하는 기술)은 필수적이다.

할 수 있는 하는게 좋다. 불필요하게 어려운 기술을 사용한다거나 미래를 생각해서 복잡한 구조를 선택하는 것은 개발 속도를 느리게 할 뿐이다.

최고의 아키텍처, 요구 사항, 설계는 자기 조직적인 팀에서 나온다.

팀은 최고의 결정을 하기위해 각 멤버가 전체 분야에 참여한다. 팀 전체는 이 결정에 대한 책임 역시 공유한다.

규칙적으로, 팀은 좀더 효과적인 방법을 반영해야 하고, 적절히 그 동작을 조율하고 조정해야 한다.

프로젝트 상황은 계속 변한다. 변화를 따라가려면 팀이 일하는 방식도 수시로 변해야 한다.

참고자료: 로버트 C 마틴 '소프트웨어 개발의 지혜'

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > 애자일 개발' 카테고리의 다른 글

Standish Group Report - Chaos (0)	2010/01/12
마음이 열리면 생각도 열린다. - 열린모임 (2)	2010/01/08
'애자일 선언'의 원칙이 주는 의미 (0)	2010/01/08
'애자일 선언'의 가치가 주는 의미 (0)	2010/01/06
플래닝 포커 Planning Poker는 "잘 모르겠다."고 말하는 것 (2)	2010/01/05
요구사항을 성공적으로 관리하기 위한 7가지 팁 (0)	2010/01/03

받은 트랙백이 없고 , 댓글이 없습니다.

'애자일 선언'의 가치가 주는 의미

Work & Study/애자일 개발 2010/01/06 00:02 posted by k16wire

스크럼이나 XP를 구성하는 기법들은 관심이 많지만 정작 애자일 선언(Manifestor of Agile Alliance)의 가치나 원칙에 대해서는 별로 관심이 없습니다. 하지만 이 선언의 가치와 원칙은 애자일 개발을 이해하는데 매우 중요합니다.

개인과 상호작용이 프로세스와 툴보다 우선이다.

일을 잘하는데 있어 프로세스와 툴은 두번째 입니다. 첫번째는 상호간의 커뮤니케이션 능력입니다. 훌룡한 개발팀은 뛰어난 개발자들이 모여야만 가능한것은 아닙니다. 개발역량은 좀 떨어져도 팀웍이 좋으면 충분히 좋은 개발팀이 될 수 있습니다.

프로세스 역시 이를 위해 존재하는 것입니다. 프로세스를 위한 프로세스는 의미가 없습니다.

적당한 툴 역시 중요합니다. 그러나 무조건 툴을 맹신하는것은 좋지 않습니다. 너무 어려워서 툴 자체를 배우고 적용하는데 비용이 많이 든다면 과감히 포기하고 화이트보드를 선택하는것도 나쁘지 않습니다.

최소한의 기능을 가진 오픈소스로 시작하는게 좋습니다.

동작하는 소프트웨어가 포괄적인 문서보다 우선이다.

코드만 있고 문서가 없는 시스템은 애자일 프로젝트라 해도 좋은 시스템이 아닙니다. 중요한 설계 결정에 대한 이유나 배경, 시스템 구조에 대한 설명은 사람이 읽을 수 있는 문서 형태로 있어야 합니다.

코드와 문서를 일치시키기 위해 노력하는것은 시간낭비 입니다. 그 보다는 필요한 내용만 요약해서 작성하고 적당한 수준에서 유지하는게 좋습니다. 팀원간에 교육이나 새로운 팀원을 위한 가장 좋은 자료는 코드와 팀원간의 페어 프로그래밍입니다.

고객 협력이 계약 협상보다 우선이다.

계약서에 명시된 프로젝트 범위나 일정을 지키는건 현실적으로 어렵습니다. 계약 당시에 범위나 일정을 정확히 정의한다는것 자체가 불가능합니다. 결국에는 어긋날 수 밖에 없습니다.

프로젝트를 성공적으로 끝내기 위해서는 한정된 비용으로 일의 범위와 기한을 맞추려 노력하기 보다는 고객과 협력해서 이를 관리하는게 중요합니다.

변화에 대한 반응이 계획을 따르는 것보다 우선이다.

소프트웨어 개발은 계획대로 진행되기 어렵다. 비즈니스 환경은 변하기 쉽고, 시스템이 동작하는 것을 본 고객은 좀 더 높은 요구사항을 내고 싶어한다. 개발자는 변경된 요구사항을 반영하는데 얼마나 많은 시간이 걸릴지 잘 예상하지 못합니다.

프로젝트 전체에 대한 계획을 세우고 이를 맞추려 노력하기 보다는 2주~3주 단위로 짧게 계획을 세우면서 변화에 대응해 나가는게 중요합니다.

참고자료: 로버트 C 마틴 '소프트웨어 개발의 지혜'

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > 애자일 개발' 카테고리의 다른 글

마음이 열리면 생각도 열린다. - 열린모임 (2)	2010/01/08
'애자일 선언'의 원칙이 주는 의미 (0)	2010/01/08
'애자일 선언'의 가치가 주는 의미 (0)	2010/01/06
플래닝 포커 Planning Poker는 "잘 모르겠다."고 말하는 것 (2)	2010/01/05
요구사항을 성공적으로 관리하기 위한 7가지 팁 (0)	2010/01/03
제품 책임자 Product Owner 란? (2)	2009/12/30

트랙백은 하나 , 댓글이 없습니다.

플래닝 포커 Planning Poker는 "잘 모르겠다."고 말하는 것

Work & Study/애자일 개발 2010/01/05 17:10 posted by k16wire

애자일 프로젝트에서 계획을 세우는 일은 계획게임 Planning Game으로 대표됩니다. 계획게임을 할때 제일 재밌어 하는게 바로 플래닝 포커 Planning Poker 입니다. 플래닝 포커는 보통 이렇게 진행합니다.

사용자 스토리를 테이블 가운데 놓는다.
각자 마음속으로 스토리에 대한 포인트를 결정한다.
포커 카드를 책상에 뒤집어 놓고 동시에 연다.
가장 높은 숫자를 낸 사람과 낮은 숫자를 낸 사람의 의견을 듣는다.
스토리 포인트에 합의가 이루어 질때까지 1-4를 반복한다.

이 플래닝 포커의 핵심은 "지식의 공유", "경험의 공유"입니다. 이때 서슴없이 던져야 하는 말은

"잘 모르겠는데요."

모른다는것이 잘못된건 아닙니다. 모르면서 아는체 하는것이 잘못된겁니다.

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > 애자일 개발' 카테고리의 다른 글

'애자일 선언'의 원칙이 주는 의미 (0)	2010/01/08
'애자일 선언'의 가치가 주는 의미 (0)	2010/01/06
플래닝 포커 Planning Poker는 "잘 모르겠다."고 말하는 것 (2)	2010/01/05
요구사항을 성공적으로 관리하기 위한 7가지 팁 (0)	2010/01/03
제품 책임자 Product Owner 란? (2)	2009/12/30
실용주의 개발환경 구성도구 (0)	2008/10/22

TAG 스크럼

트랙백은 하나 , 댓글 2개가 달렸습니다.

요구사항을 성공적으로 관리하기 위한 7가지 팁

Work & Study/애자일 개발 2010/01/03 11:23 posted by k16wire

요구사항을 정확히 받는다는것 정말 중요합니다. 말이 필요없죠. 요구사항 수집에 대한 좋은 글이 있어 소개합니다. 7가지 팁을 소개하고 있는데 어떤 팁들이 있는지 살펴 보겠습니다.

Tip1: 항상 연결되어 있어라. Stay Connected.
        모든 사람이 같이 있는것 만으로도 이슈는 해결될 수 있다.
Tip2: 지금 바로 행등하라. Take Action Now.
        완벽한것은 없다. 아무것도 안하는 것 보다는 뭐라도 하는것이 낫다.
Tip3: 바퀴를 또 발명할 필요는 없다. Don't reinvent the Wheel
        기존에 만들어진 것중에는 유용한 것들이 많습니다.
Tip4: 모호한 것들을 제거하라. Elimate Ambiguity.
        요구사항 관리를 잘하는 것은 요구사항을 잘 작성하는것에서 부터 시작한다.
Tip5: 고객을 다시 만나봐라. Reconnect with Your Customers.
        고객을 만나기 위해 반드시 전문가가 될 필요는 없다. 일단 만나봐라.
Tip6: 목적에 우선순위를 정하라. Prioritize Objectively.
        고객이 필요로 하지 않고 사용하지도 않을 기능을 만들지 마라.
Tip7: 부담을 최소화 하라. Minimize Overhead
        업무에 적용할 수 있는 적당한 도구를 선택하라.

7_Essential_Tips_to_Ensure_Success_with_Requirements_Manage.pdf

아래 슬라이드는 유스케이스와 유저스토리를 잘 설명하는 자료라 같이 첨부합니다.

From Use case to User Story

View more presentations from ckunta.

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > 애자일 개발' 카테고리의 다른 글

'애자일 선언'의 가치가 주는 의미 (0)	2010/01/06
플래닝 포커 Planning Poker는 "잘 모르겠다."고 말하는 것 (2)	2010/01/05
요구사항을 성공적으로 관리하기 위한 7가지 팁 (0)	2010/01/03
제품 책임자 Product Owner 란? (2)	2009/12/30
실용주의 개발환경 구성도구 (0)	2008/10/22
실용주의 개발환경 구축하기 (0)	2008/02/14

TAG 요구사항관리

받은 트랙백이 없고 , 댓글이 없습니다.

제품 책임자 Product Owner 란?

Work & Study/애자일 개발 2009/12/30 14:50 posted by k16wire

스크럼 프로세스 모델을 보면 제품 책임자 Product Owner라는 역할이 나옵니다. 이 사람은 어떤 일을 하는 사람일까요 ?

고객일까요 ?
PM, PL 일까요 ?

보통 이런식으로 정의합니다.

고객과 같은 이해 당사자들을 대신하여 시스템 요구사항을 정의하는 제품 백로그를 작성하고 각 항목에 대한 우선순위를 결정하는 사람.

여기에 한가지 더 덧붙이고 싶습니다.

제품이 지원할 비즈니스 프로세스를 사용자 입장에서 살펴보는 사람.

프로젝트 일정은 PM, PL이 책임지고, 기술적인 이슈는 SA가 책임지고, 코딩/테스트는 개발자가 책임진다면 사용자 관점에서 필요한 사항을 책임질 사람이 비게 됩니다.
그럼 고객은 뭐할까요? 머릿수를 세고 술을 마시느라 바쁘죠. 하하하.

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > 애자일 개발' 카테고리의 다른 글

'애자일 선언'의 가치가 주는 의미 (0)	2010/01/06
플래닝 포커 Planning Poker는 "잘 모르겠다."고 말하는 것 (2)	2010/01/05
요구사항을 성공적으로 관리하기 위한 7가지 팁 (0)	2010/01/03
제품 책임자 Product Owner 란? (2)	2009/12/30
실용주의 개발환경 구성도구 (0)	2008/10/22
실용주의 개발환경 구축하기 (0)	2008/02/14

TAG 스크럼

받은 트랙백이 없고 , 댓글 2개가 달렸습니다.

Testable Java

Work & Study/TechTalk 2009/11/21 21:01 posted by k16wire

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

TUF = Test Unfriendly Feature
TUC = Test Unfriendly Construct

번역하자면 테스트와 친하지 않은 특징,

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

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > TechTalk' 카테고리의 다른 글

광고인 '이제석'을 알다. (0)	2010/01/31
Testable Java (0)	2009/11/21
추정에 대하여 (0)	2009/10/26
테스트 데이터를 효과적으로 만드는 방법 (2)	2009/10/19
Mock 객체가 단위테스트를 컨텍스트와 분리하는일만 하는 것은 아니다. (0)	2009/10/18
XP 개발자 VS 스크럼 개발자 (2)	2009/10/04

받은 트랙백이 없고 , 댓글이 없습니다.

추정에 대하여

Work & Study/TechTalk 2009/10/26 19:27 posted by k16wire

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

이중 태스크 시간은 개발자에 따라 변동이 커서 신뢰도가 떨어집니다. 물론 팀으로 추정한다거나 표준 시간을 정해준다거나 하면 좀 나아지기도 합니다.
기왕 그렇다면 차라리 태스크 시간을 같은 시간으로 고정시키는건 어떨까요? 보통

8시간 근무니까 4시간짜리 2개 태스크로 정해주는것도 나쁘지 않을거 같습니다.
그러다가 태스크를 상세히 정할 단계가 되면 더 세분화 할 수 있게 해주는거죠.
시간별로 포스트잇을 다양화 해서 시간이 많이 걸리는 태스크가 무엇인지 바로 알아차릴 수 있게 하는것도 좋을듯 합니다.

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > TechTalk' 카테고리의 다른 글

광고인 '이제석'을 알다. (0)	2010/01/31
Testable Java (0)	2009/11/21
추정에 대하여 (0)	2009/10/26
테스트 데이터를 효과적으로 만드는 방법 (2)	2009/10/19
Mock 객체가 단위테스트를 컨텍스트와 분리하는일만 하는 것은 아니다. (0)	2009/10/18
XP 개발자 VS 스크럼 개발자 (2)	2009/10/04

TAG agile, 개발

받은 트랙백이 없고 , 댓글이 없습니다.

테스트 데이터를 효과적으로 만드는 방법

Work & Study/TechTalk 2009/10/19 13:00 posted by k16wire

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

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

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

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

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

관련 URL: Randomizing static test data in automated tests

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > TechTalk' 카테고리의 다른 글

Testable Java (0)	2009/11/21
추정에 대하여 (0)	2009/10/26
테스트 데이터를 효과적으로 만드는 방법 (2)	2009/10/19
Mock 객체가 단위테스트를 컨텍스트와 분리하는일만 하는 것은 아니다. (0)	2009/10/18
XP 개발자 VS 스크럼 개발자 (2)	2009/10/04
JDK 7에서 바뀐 특징들 (1)	2009/09/23

TAG Test Automation

받은 트랙백이 없고 , 댓글 2개가 달렸습니다.

Mock 객체가 단위테스트를 컨텍스트와 분리하는일만 하는 것은 아니다.

Work & Study/TechTalk 2009/10/18 10:30 posted by k16wire

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객체를 단순히 분리를 위해서 사용하지 말고 디자인을 위해서 사용하라고 충고합니다.

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

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

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > TechTalk' 카테고리의 다른 글

추정에 대하여 (0)	2009/10/26
테스트 데이터를 효과적으로 만드는 방법 (2)	2009/10/19
Mock 객체가 단위테스트를 컨텍스트와 분리하는일만 하는 것은 아니다. (0)	2009/10/18
XP 개발자 VS 스크럼 개발자 (2)	2009/10/04
JDK 7에서 바뀐 특징들 (1)	2009/09/23
Pragmatic Magazine에 실린 Responsive Design (0)	2009/09/19

TAG TDD

받은 트랙백이 없고 , 댓글이 없습니다.

XP 개발자 VS 스크럼 개발자

Work & Study/TechTalk 2009/10/04 00:00 posted by k16wire

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) 추석인데 일본 촌구석 독신자 숙소에 있다보니 쓸데없이 야후 메일링이나 뒤지고 있네요..^^

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > TechTalk' 카테고리의 다른 글

테스트 데이터를 효과적으로 만드는 방법 (2)	2009/10/19
Mock 객체가 단위테스트를 컨텍스트와 분리하는일만 하는 것은 아니다. (0)	2009/10/18
XP 개발자 VS 스크럼 개발자 (2)	2009/10/04
JDK 7에서 바뀐 특징들 (1)	2009/09/23
Pragmatic Magazine에 실린 Responsive Design (0)	2009/09/19
InfoQ Agile 2009 특집 (0)	2009/09/18

TAG agile

받은 트랙백이 없고 , 댓글 2개가 달렸습니다.

JDK 7에서 바뀐 특징들

Work & Study/TechTalk 2009/09/23 10:44 posted by k16wire

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

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

Swith문에서 String 사용 가능

String s = ...

switch(s) {

  case "foo":

    processFoo(s);

    break;

}

Generic Type의 개선
이전

Map<String, List<String>> anagrams = new HashMap<String, List<String>>();

이후

Map<String, List<String>> anagrams = new HashMap<>();

그외 다른 부분들은 여기를 참고하세요.

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > TechTalk' 카테고리의 다른 글

Mock 객체가 단위테스트를 컨텍스트와 분리하는일만 하는 것은 아니다. (0)	2009/10/18
XP 개발자 VS 스크럼 개발자 (2)	2009/10/04
JDK 7에서 바뀐 특징들 (1)	2009/09/23
Pragmatic Magazine에 실린 Responsive Design (0)	2009/09/19
InfoQ Agile 2009 특집 (0)	2009/09/18
JUnit 테스트코드를 단일 클래스 로더에서 실행하는 방법 (0)	2009/09/10

받은 트랙백이 없고 , 댓글 하나가 달렸습니다.

Pragmatic Magazine에 실린 Responsive Design

Work & Study/TechTalk 2009/09/19 00:19 posted by k16wire

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

PDF로 받아 볼 수 있습니다.

PragPub Issue3, September 2009

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > TechTalk' 카테고리의 다른 글

XP 개발자 VS 스크럼 개발자 (2)	2009/10/04
JDK 7에서 바뀐 특징들 (1)	2009/09/23
Pragmatic Magazine에 실린 Responsive Design (0)	2009/09/19
InfoQ Agile 2009 특집 (0)	2009/09/18
JUnit 테스트코드를 단일 클래스 로더에서 실행하는 방법 (0)	2009/09/10
Agile 2009 Conference 참관기 - 1일, Priorizing Your Product Backlog (0)	2009/09/01

TAG 켄트벡

받은 트랙백이 없고 , 댓글이 없습니다.

InfoQ Agile 2009 특집

Work & Study/TechTalk 2009/09/18 01:49 posted by k16wire

컨퍼런스를 듣는동안 InfoQ 마크가 붙어있는 카메라가 여기저기 보였는데, 오늘자 뉴스레터에

보니 시리즈로 강연이 올라와 있네요.

Agile 2009 content on InfoQ

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > TechTalk' 카테고리의 다른 글

JDK 7에서 바뀐 특징들 (1)	2009/09/23
Pragmatic Magazine에 실린 Responsive Design (0)	2009/09/19
InfoQ Agile 2009 특집 (0)	2009/09/18
JUnit 테스트코드를 단일 클래스 로더에서 실행하는 방법 (0)	2009/09/10
Agile 2009 Conference 참관기 - 1일, Priorizing Your Product Backlog (0)	2009/09/01
Agile 2009 Conference 참관기 - 1일 (0)	2009/09/01

TAG agile2009

받은 트랙백이 없고 , 댓글이 없습니다.

JUnit 테스트코드를 단일 클래스 로더에서 실행하는 방법

Work & Study/TechTalk 2009/09/10 16:54 posted by k16wire

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

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

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

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

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

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

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

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

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

이올린에 북마크하기(0)

이올린에 추천하기(0)

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

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

'Work & Study > TechTalk' 카테고리의 다른 글

Pragmatic Magazine에 실린 Responsive Design (0)	2009/09/19
InfoQ Agile 2009 특집 (0)	2009/09/18
JUnit 테스트코드를 단일 클래스 로더에서 실행하는 방법 (0)	2009/09/10
Agile 2009 Conference 참관기 - 1일, Priorizing Your Product Backlog (0)	2009/09/01
Agile 2009 Conference 참관기 - 1일 (0)	2009/09/01
Agile 2009 Conference 참관기 - 0일 (2)	2009/08/28

받은 트랙백이 없고 , 댓글이 없습니다.

'Work & Study'에 해당되는 글 260건

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > TechTalk' 카테고리의 다른 글

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > 애자일 개발' 카테고리의 다른 글

'Work & Study > TechTalk' 카테고리의 다른 글

'Work & Study > TechTalk' 카테고리의 다른 글

'Work & Study > TechTalk' 카테고리의 다른 글

'Work & Study > TechTalk' 카테고리의 다른 글

'Work & Study > TechTalk' 카테고리의 다른 글

'Work & Study > TechTalk' 카테고리의 다른 글

'Work & Study > TechTalk' 카테고리의 다른 글

'Work & Study > TechTalk' 카테고리의 다른 글

'Work & Study > TechTalk' 카테고리의 다른 글

Notices

recent Entries

recent Comments

Search

Categories