행복한 아빠

애자일이 야근을 막아주는 3가지 이유

행복한아빠 — Fri, 18 May 2012 10:51:22 +0900

애자일을 한다고 야근을 완전히 막지는 못합니다. 애자일 역량이 뛰어난 팀이라 해도 야근을 하는 경우가 많습니다. 그렇습니다. 여러분은 제목에 낚인 것입니다. ^^

그러나 애자일을 하면 야근을 막을 수 있는 몇 가지 이유는 있습니다.

팀원 - 내 성과를 인정받을 수 있다.

개개인의 성과를 측정하기 애매한 환경에서 팀원들은 자신이 인정받기 위해 할 수 있는 일은 하나 밖에 없습니다. 오래 일하는 것입니다. 그렇습니다. 이런 환경에서는 야근을 많이 하고 주말 근무를 많이 하는 직원이 인정받게 됩니다.

스크럼의 개발방법은 사실 성과주의적인 면이 있습니다. 팀이나 개인 얼마나 성과(백로그)를 냈는지가 만천하에 투명하게 공개됩니다. 성과를 충분히 내었다면 불필요한 야근을 할 이유가 없습니다.

스크럼마스터 - 팀 속도 유지가 중요하다.

오랫동안 스크럼팀을 관리하다 보면 스크럼마스터는 안정적인 프로젝트 진행을 위해서는 팀 속도 유지가 중요하다는 사실을 압니다. 즉 팀원들이 항상 최상의 컨디션을 유지해야 안정적인 속도가 보장된다는 것을 알죠.

당장 급하다고 팀원들의 컨디션이나 사기를 떨어뜨리는 일은 지양합니다.

고객 - 원하는 결과를 얻었다.

아무런 결과(문서를 결과로 생각하지 않죠)를 받지 않은 고객이 프로젝트 팀에 관심을 가질 수 있는 것은 오직 팀원들의 근태(투입인력상황,출퇴근)와 근거를 알 수 없는 진척률뿐입니다. 근거를 알 수 없는 진척률이 나오지 않을 경우 우리가 고객에게 할 수 있는 것은 야근을 통해 놀고 있지 않다고 안심시키는 일뿐입니다. ㅠㅠ

애자일은 고객이 가장 원하는 것을 가장 먼저 되도록 빨리 전달합니다. 애매모호한 분석/설계 문서가 아니라 돌아가는 소프트웨어로 제공합니다.

이제 고객은 근태보다는 자신이 당장 써보거나 만져볼 수 있는 소프트웨어에 관심을 갖게 됩니다.

팀의 역량에 맞는 속도 유지가 중요합니다. 야근이나 주말근무로 팀속도를 높이지 마십시오. 그렇게 높인 팀속도는 뒤에 대가가 따릅니다.

팀속도를 높이는 방법은 팀이 일하는 방법을 지속적으로 개선하여 팀의 역량을 높이는 것입니다.

* 팀속도란 한 스프린트(반복 또는 작은계획)내에서 팀이 처리하는 일의 양을 점수화 한 것입니다.

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

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

'애자일' 카테고리의 다른 글

애자일이 야근을 막아주는 3가지 이유 (0)	10:51:22
TO DO or DONE 이것이 문제다 (0)	2012/05/17
실전! 플래닝 포커 (0)	2011/11/23
다수결로 프로젝트가 성공한 예 (0)	2011/10/12
급한 이벤트로 계획(스프린트)이 자꾸 망가질 때... (0)	2011/07/13
새로운 형태의 작업이 추정이 어려울 때 (0)	2011/07/11

TO DO or DONE 이것이 문제다

행복한아빠 — Thu, 17 May 2012 17:31:56 +0900

진척률 98.1%의 전설을 아시나요. 프로젝트 초반에는 10%, 20% 순조롭게 가던 진척률이 프로젝트 막판에는 98.1%, 98.2% 이런 식으로 진척률이 진행됩니다.
도대체 0.1% 진척향상이 뭘 의미하고 이렇게 되는 이유가 뭘까요? 제가 경험한 바로는 프로젝트 막판에 더 열심히 일(야근, 밤샘)을 하던데... 갑자기 생산성이 급락하는 이유가 뭘까요?

로그함수 형태의 진척률의 원인

이는 대부분 주관적인 판단에 의한 진척률 측정에 기인합니다. 프로젝트 초반의 일들이 분석이나 설계등의 일이고 이 진척들은 순조롭게 진행되는 경향이 있습니다.
문제는 "이 분석이나 설계가 100% 완료되었는지 검증이 가능한가?"라는 것입니다. 완벽한 분석이나 설계라 두번 다시 재작업이 없을 거라고 누구도 장담하지 못할겁니다.
이 때 이러한 작업의 진척률은 "이만하면 되었다"라는 주관적인 판단으로 내리는 것이죠...

작업의 기준을 바꾸자

물론 전체적인 분석이나 설계작업이 필요할 수도 있습니다. 그러나 되도록 검증이 가능한 작업을 기준으로 계획하는 것이 여러모로 유리합니다.
애자일에서 이야기하는 사용자 스토리 기준 또는 기능을 기준으로 작업을 관리하는 것입니다.
이 때 주의할 것은 사용자 스토리나 기능의 완료 기준은 엄격하게 관리해야 합니다. (엄격한 테스트케이스...)

최소단위 작업에 50%란 없다

최소단위 작업의 진행상태를 관리할 경우 되도록 몇%의 진척을 관리하지 마십시오. 완료 또는 미완료로 관리하시는게 유리합니다.
최소단위의 작업이 40%라고 보고되면 이게 의미하는 것이 뭘까요? 주관적인 판단입니다. 이것이 주는 혜택은 단지 어느정도 되었구나라고 안심시키는 일 밖에 없습니다.
이런 주관적인 판단이 모여 다시 한번 전체 진척률을 왜곡시킵니다.

그래서...

사용자 스토리를 되도록 작게 나누고(1~3일) 최소 단위 작업은 0% 아니면 100%로 관리하는게 유리합니다.
처음에 진척이 팍팍 올라가지는 않겠지만 좀더 정직한 진척을 보게 될 것입니다.
물론 일일 스크럼 미팅에서 "지금 반쯤 된 것 같아요"라고 말할 수 있고 그렇게 알려주는게 좋겠지요. 그러나 "반쯤 된 것 같아요"를 Burndown chart에 반영하지 마십시오. 98.1%를 현실에서 만나지 않으려면...

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

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

'애자일' 카테고리의 다른 글

애자일이 야근을 막아주는 3가지 이유 (0)	10:51:22
TO DO or DONE 이것이 문제다 (0)	2012/05/17
실전! 플래닝 포커 (0)	2011/11/23
다수결로 프로젝트가 성공한 예 (0)	2011/10/12
급한 이벤트로 계획(스프린트)이 자꾸 망가질 때... (0)	2011/07/13
새로운 형태의 작업이 추정이 어려울 때 (0)	2011/07/11

실험은 실험실에서...

행복한아빠 — Fri, 09 Dec 2011 13:13:07 +0900

얼마전 나가수에서 인순이씨가 7위를 했습니다. 굉장히 실험적인 음악을 했고 그 실험은 결국 방청객들의 좋은 반응을 이끌어내지 못했습니다. 전 그 노래를 들으며 저 실험적인 음악을 충분히 연습했고 나가수 나오기 전에 다른 곳에서 평가를 받아본 적이 있는 상태였었나 물음을 던져보고 싶었습니다.
(이미지출처)

인순이씨의 실패

인순이씨의 도전정신은 충분히 본 받아 마땅하지만 시간내서 그 곳에 온 방청객에게, 인순이씨의 노래에 잔뜩 기대하고 온 팬들에게 내놓을 수 있는 노래였는지는 납득하기 어려웠습니다. 혹시 나가수에서 처음 시도한 것은 아닌지... (인순이씨 디스하려는 것 절대 아닙니다. 그 연륜과 위치에서 나가수에 나왔다는 점은 매우 존경합니다.)

임상실험

어떤 약을 연구하고 내놓기 전 반드시 임상실험을 합니다. 아무리 철저히 연구했더라고 하다라도 그 약에 결함이 있으며 생명에 치명적인 영향을 주기 때문에 세상에 나오기 전 충분한 테스트를 거쳐야 합니다.
자동차 역시 비용이 많이 드는 충돌 테스트를 반드시 거칩니다. 세상에 나오기 전, 고객이 사용하기 전 그만큼의 비용은 반드시 들여야 합니다. 너무 당연한 것입니다.

소프트웨어 현실에서

소프트웨어를 만드는 사람들도 고객에게 소프트웨어를 인도하기 전 이러한 검증절차를 거쳐야 합니다. 그러나 그렇지 않은 경우를 종종 보게 됩니다.
자신이 정확히 이해하지 못한 설계 패턴을 책에서 보고 고객 사이트에 적용하려는 시도, 아직 적용해 보지 못한 신기술, 검증받지 않은 최신의 매력적인 기술들을 고객의 시스템에 적용해보려는 시도를 과연 도전정신으로 받아들여야 할까요?

최악의 경우는 테스트 코드가 없거나 테스트를 하지 않은 코드를 고객에게 인도하려는 것입니다. 이런 것이야 말로 무모한 도전이고 그 위험 부담을 고객에게 전가시키는 것입니다.
기본적인 테스트 비용은 고객이 부담하는 것이 아니고 소프트웨어를 만드는 사람들이 부담하는게 맞습니다.

그래서 해야 할 일

이런 이야기를 하면 항상 프로젝트 중이라 새로운 기술을 배우거나 적용할 기회가 없다고 합니다.
그러나 가끔은 고객이 새로운 기술을 적용하기를 원하는 도전적인 프로젝트를 주는 기회가 있기도 합니다. 이 경우는 행운입니다.

그렇지 않더라도 소프트웨어를 좋아하여 항상 탐구하려는 자세를 가진 개발자들이라면, 실전에 신기술을 적용하기 전 충분히 연구하고 동료들과 검토하고 검증할 기회는 많습니다.

최악의 경우처럼 테스트가 없는 코드를 고객에게 인도하는 일은 없어야 합니다. 기본적인 테스트도 하지 않는 코드를 인도하는 개발자는 기본적인 직업의식도 없는 거나 마찬가지지요. 테스트하기 어렵거나 지친다면 TDD를 해보는 것도 좋은 방법입니다.

외부의 환경에 의해 소프트웨어 직군이 3D라는 말을 듣고 불평만 하지 말고, 소프트웨어 종사자가 단순 노동자가 아니라 전문적인 직업이라는 평가를 받기 위해 우리도 좀 더 프로답게 일할 필요가 있지 않나 생각해 봅니다.

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

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

'하고싶은말' 카테고리의 다른 글

실험은 실험실에서... (0)	2011/12/09
벽돌쌓기, 성당짓기 (4)	2010/08/08
멀티 태스킹을 할 때와 하지 말아야 할 때 (2)	2010/03/10
내 프로그램에는 얼마나 많은 버그가 있을까? (2)	2010/02/10
난 착한아빠가 싫다 (0)	2010/02/03
짝 프로그래밍이 더 생산성이 좋은 이유 (2)	2010/02/01

실전! 플래닝 포커

행복한아빠 — Wed, 23 Nov 2011 11:40:16 +0900

애자일 추정에서 많이 사용하는 플래닝 포커 사용법을 소개합니다. 애자일에서 추정은 매우 중요합니다. 추정은 단지 계획을 세우기 위해서만 이루어지는 활동은 아닙니다. 플래닝 포커를 이용한 추정을 통해 어떤 효과가 있는지 알아보도록 하겠습니다.

플래닝 포커 구성

점수(0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, 무한대, 커피)가 표기된 4벌의 카드로 구성되어 있습니다. 점수는 많이 사용하는 피보나치 수열을 이용합니다.

플래닝 포커

1. 모든 사람들은 카드를 한 벌씩 나누어 가집니다.
모든 팀원들이 같이 추정을 합니다. PM이나 스크럼 마스터 혼자 추정하는 것은 의미 없습니다. 모든 팀원이 같이 추정함으로써 작업에 대한 이해를 공유할 수 있습니다. 기억하십세요. 이해하기 전에는 추정할 수 없습니다.

2. 추정할 작업을 가장 잘 이해하는 사람이 작업에 대해 설명합니다.
보통 제품 소유자 (Product Owner)나 고객이 작업에 대해 추정이 가능한 만큼만 설명합니다. 대략적인 기능의 목적과 내용을 설명합니다.

3. 다른 사람들은 추정을 위해 필요한 질문을 하고 의논을 합니다.
추정하는 사람들은 구현하기 위해 확인할 내용을 질문합니다. 주로 제품 소유자나 고객이 답을 하겠지만 누구라도 질문에 대한 답을 할 수 있습니다.

팀원1: 이 작업의 키워드 검색기능의 범위가 어떻게 되나요? 자연어 검색도 되어야 하나요?
고객: 자연어 검색까지는 필요하지 않습니다. 키워드로 제목과 본문내용이 검색되는 수준이면 충분합니다.
팀원2: 검색을 위해 검색엔진 구현이 필요한 부분일까요?
팀원3: 우리는 이미 사용할 수 있는 검색엔진이 있습니다. 검색엔진 구입이나 구현은 필요없어요.

4. 질문이 끝나면 각자 자신이 추정한 점수를 보이지 않게 내려 놓습니다. 그리고 동시에 카드를 뒤집어 확인합니다.
모든 팀원들이 각자 자기가 이해한 수준에서 작업의 규모를 결정합니다. 다른 사람의 눈치를 볼 필요는 없습니다.

5. 모두 같은 점수가 나오면 그 점수로 작업의 점수를 결정합니다.
한 번에 동일한 점수가 나오지 않는 경우도 많습니다. 그런 경우 다음 단계로 이동합니다.

6. 가장 낮은 점수 또는 가장 높은 점수를 제시한 사람부터 그 점수를 제시한 이유를 설명합니다.
예를 들어 모두 3점을 제시했는데 누군가 1점을 제시했다면 다른 사람이 모르는 중요한 정보를 알고 있을 가능성이 있습니다. 반대의 경우 아무도 모르는 작업의 위험을 알고 있는 사람이 있을 수도 있습니다.

7. 모든 사람이 자신이 제시한 점수에 대해 논의한 후 다시 점수를 제시합니다.
모든 사람이 자신의 점수를 제시한 이유를 논의함으로써 작업에 대한 이해를 공유할 수 있습니다. 이 때 제품 소유자나 고객이 작업에 대한 중요한 의사결정을 내릴 수도 있습니다. 이 대 작업카드에 그 내용을 기입해 둘 수 있습니다.

팀원1: 로그인을 하지 않은 상태에서 장바구니의 내용을 다시 접속할 때 기억하려면 특별한 장치가 필요합니다. 이를 위해서는 이틀의 시간이 더 필요합니다.
고객: 아 그렇다면 로그인을 한 상태에서만 장바구니 내용을 보관하도록 하죠.

8. 모두 동일한 점수를 제시할 때까지 반복합니다.
이런 과정을 통해 모두의 점수가 합의될때까지 반복합니다. 익숙해지면 보통 2~3회 반복으로 점수가 합의됩니다. 이러한 과정을 통해 작업의 내용을 더 구체화되고 공유됩니다. 이러한 의논을 통해 반드시 확인할 내용이 나오면 카드 뒷면에 테스트케이스로 기록해 둡니다.

플래닝 포커 Q&A

Q. 점수의 기준 어떻게 되나요?
A. 점수의 기준은 팀마다 다를 수 있습니다. 보통은 이상적인 작업시간(하루 8시간)을 기준으로 1점을 잡습니다.
즉 다른 방해없이 집중해서 하루 8시간 작업에 투자하여 3일이 걸린다면 3점을 잡습니다.
중요한 점은 점수 기준에 대한 일관성을 확보해야 한다는 점입니다.

Q. 그렇다면 2점은 반드시 이틀에 끝내야 하나요.
A. 이상적인 작업시간이라는 것을 기억하세요. 이상적인 팀에서 아무 방해없이 종일 몰입해서 한다면 2점은 이틀 에 끝나는게 맞겠지요. 그러나 그렇지 않은 경우가 많습니다. 2점이 3일 걸릴수도 있습니다. 그만큼 팀의 작업 집중도가 떨어지는 것이고 이는 팀의 속도에 반영됩니다. 자연스러운 현상입니다.
점점 팀의 작업 집중도를 높여 속도를 높일 방법을 지속적으로 찾아보세요.

Q. 도저히 합의에 이르지 못할 때는 어떤 방법이 있나요?
A. 작업이 너무 애매해서 점수합의가 어려울 경우 지금까지 추정한 카드를 점수별로 분류하여 추정하려는 작업이 어느 작업과 가장 유사한 규모인지 비교해 보고 비슷한 작업의 점수로 결정합니다. 이를 삼각측량이라고 합니 다. 1, 2 점으로 너무 논쟁하지 마세요. 추정은 반복적이며 앞으로 재추정할 수 있는 기회는 많이 있습니다. 겨 우 1, 2 점이라고요.

Q. 개인의 역량에 따라 점수가 달라집니다.
A. 고참이 하면 1점인데 신참이 하면 3점인 작업이 있을 경우 고민됩니다. 누가하면 얼마나 걸릴지가 아니라 우리 팀이 하면 얼마나 걸릴지 추정해야 합니다. 즉 평균적인 속도로 추정하는 것이 좋습니다. 이런 경우 너무 고민 하지 말고 2점을 주세요.

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

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

'애자일' 카테고리의 다른 글

애자일이 야근을 막아주는 3가지 이유 (0)	10:51:22
TO DO or DONE 이것이 문제다 (0)	2012/05/17
실전! 플래닝 포커 (0)	2011/11/23
다수결로 프로젝트가 성공한 예 (0)	2011/10/12
급한 이벤트로 계획(스프린트)이 자꾸 망가질 때... (0)	2011/07/13
새로운 형태의 작업이 추정이 어려울 때 (0)	2011/07/11

다수결로 프로젝트가 성공한 예

행복한아빠 — Wed, 12 Oct 2011 11:08:08 +0900

많은 경우 프로젝트 실패의 원인을 요구사항 변경관리 실패에서 찾습니다. 그래서 프로젝트 초반 철저한 분석을 통해 요구사항을 확정하고 철저한 요구사항 변경프로세스로 함부로 요구사항변경을 하지 못하게 하는 경우 프로젝트가 성공하는지 생각해 보았습니다. 사실 이런 프로젝트가 현실에서 발견하기 어렵기 때문에 아래와 같이 사고실험을 해 봅니다.
(이미지출처)

어떤 프로젝트가...

6개월동안 모든 프로젝트 이해관계자가 정확한 일정관리와 빈틈없는 요구사항 관리로 프로젝트를 제때에 끝냈습니다. 프로젝트에 참여한 사람들의 회고입니다.

개발자

내게 주어진 업무를 정확하고 깔끔하게 제때 모두 끝냈것 같아. 자 봐 이렇게 완벽한 테스트케이스가 걸린 소스코드를 찾아보기란 쉽지 않을 거야. 게다가 소스코드는 누가 봐도 읽기 쉽게 깔끔하게 작성되었어. 내가 만든 소스코드 중 제일 맘에 들어.

설계자

내가 설계한 의도대로 구현까지 모두 완벽히 된 것 같아. 내가 설계한 업무에 논리적인 결함이나 빈틈이 없잖아. 게다가 업무가 어떻게 확장되든 충분히 대응할 수 있다고 봐. 하하. 이렇게 완결한 설계와 다양한 디자인 패턴을 적용한 경우는 처음이야. 다른 프로젝트에 참고자료로 쓰여도 손색이 없을거야.

아키텍트

고객이 요구한 보안이나 성능에 대한 요구사항은 충분히 만족시킨 것 같아. 고객이 예상한 사용자의 2배도 견디는 걸. 좀 사용하기 까다롭기는 하지만 시스템 접근에 대한 인증/인가도 충분해. 보안쪽이 뚫리기는 쉽지 않을거야. 만족해. 진짜 만족해

프로젝트 관리자

역시 철저한 일정관리와 요구사항 변경관리가 프로젝트 관리의 핵심이었어. 처음 계약한 대로 요구사항을 on-time에 모두 완결했어. 역시 프로젝트 관리가 내 적성인가봐. 회사에서도 이번 프로젝트로 수익이 좋게 나왔다고 좋아하는 걸...

고객

다행하게도 프로젝트는 비용넘지 않고 제 때 끝났네. 처음 그린 그림대로 잘 나온 것 같고. 그런데 처음 그린 그림대로 만들고 나니 뭔가 업무가 어색하게 돌아가네. 이런 이런 이건 현실과 좀 맞지 않은 부분이네.
그건 그렇고 오픈 한 지 한달이 넘는데 사용하는 사람이 거의 없네. 이거 핵심업무인데도 말이야. 뭐라고! 아직도 엑셀로 처리하고 있다고? 후~

모두가 각기 자신의 업무를 성공적으로 수행했고 프로젝트에 관여한 사람 모두 만족한 프로젝트입니다. 다만 고객만 좀 찜찜해 하는군요.
성공한 프로젝트 맞나요? 애매하니까 다수결로 성공했다고 치죠. -.-; 뭐가 문제인가요?

(이미지출처)

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

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

'애자일' 카테고리의 다른 글

TO DO or DONE 이것이 문제다 (0)	2012/05/17
실전! 플래닝 포커 (0)	2011/11/23
다수결로 프로젝트가 성공한 예 (0)	2011/10/12
급한 이벤트로 계획(스프린트)이 자꾸 망가질 때... (0)	2011/07/13
새로운 형태의 작업이 추정이 어려울 때 (0)	2011/07/11
애자일 게임을 하다 (0)	2011/06/20

jQuery의 이벤트 ajax 핸들러에서의 scope 문제 해결책

행복한아빠 — Tue, 19 Jul 2011 08:46:36 +0900

오랜만에 Javascript 코딩해 보려는데 참 힘드네요. javascript로 컴포넌트 만들고 컴포넌트내에서 ajax 호출시 this.someFunction 식으로 callback 넘겨주는데 scope가 달라져 someFunction 내에서 this 접근이 되지 않습니다. ㅜㅜ 이러면 메소드 못나누고 내가 만든 클래스 못쓰게 되는 사태가 발생!!!
Ext.js에서는 이런 경우를 위해 scope을 지정하는 옵션이 있었는데 쩝~
(이미지출처)

구글신 소환해봅니다. 역시 같은 문제로 고생하는 분 많았네요.
그 중 제 맘에 꼭 드는 솔루션을 제시한 블로그가 있어 소개합니다.

Go! Workaround for jQuery's lask of scope management in event / AJAX handlers

대략적인 내용

글쓴이도 저와 같은 상황으로 고생했고 다음과 같이 scope function 정의해서 간단히 해결했다는 내용입니다.
제 코드는 좀 길고 복잡해서 원문 코드 그대로 사용합니다. 이런 생각을 왜 못했을까?

아래와 같이 scope function 정의(overload)하고...

아래와 같이 쓰면 this 스코드 그대로 가지고 가는 callback function을 넘길 수 있다는 이야기입니다.

이렇게 하지 않으면 위의 element 클릭해서 handeClick function이 호출되더라도 scope 바뀌어 this.doStuff()하면 정의되지 않은 function이라고 에러 나옵니다.

scope를 유지하고 싶다면 그냥 호출하지 말고 아래 코드를 이용하여 넘기세요~

Thanks Kier Darby.

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

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

'웹기술들' 카테고리의 다른 글

jQuery의 이벤트 ajax 핸들러에서의 scope 문제 해결책 (8)	2011/07/19
Java 웹애플리케이션에서 Flash scope 구현 - 메시지 출력 문제 (0)	2011/06/23
Struts 태그에서 자동생성되는 TD 태그 없애기 (4)	2010/03/22
스프링 프레임워크 3.0 GA 릴리즈 - 기능 요약 (0)	2009/12/30
Flex에서 ExternalInterface 사용시 동기화 문제 (1)	2009/12/23
Java로 엑셀 다운로그 구현하기 (0)	2009/12/20

언어가 사고를 제한한다. 기술이 가능성을 제한한다.

행복한아빠 — Mon, 18 Jul 2011 12:56:22 +0900

우리는 꿈에서 한국말을 사용합니다. 그리고 생각을 하더라도 한국말을 이용하여 생각합니다. 물론 영어권에 사는 사람들은 영어로 꿈을 꾸고 영어로 사고를 하겠지요. 문화의 특성 때문에 각 나라에서 사용하는 언어가 표현할 수 있는 정도는 매우 다양합니다. 예를 들면 에스키모가 표현하는 "눈(雪)"은 수십가지가 됩니다. 우리가 눈에 대해 상상할 수 있는 것과 에스키모인이 눈에 대해 상상할 수 있는 것은 그 차이가 크겠지요.

마찬가지로 우리가 사용하는 기술이 가능성을 제한합니다. 물론 자기가 잘 알고 있는 기술로 안되는 것 없습니다. 다만 시간이 좀 걸리고 비용이 올라가는 것일 뿐이죠.

간단한 아키텍처 vs 복잡한 아키텍처?

이 글은 제가 제품을 개발하면서 느낀 부분이고 새로운 서비스를 만드는 것을 가정하고 쓴 글입니다. 모든 곳에 적용될 수는 없습니다.

여기서 이야기하는 간단한 아키텍처는 최소한의 기술만 사용하는 간단한 구조의 설계방식을 이야기합니다. 이러한 아키텍처를 사용하면 초기 생산성이 높고 유지보수가 편해 보입니다. 그러나 결국 어려운 서비스 구현에서 한계를 갖고 편법이 동원되는 경향이 있습니다.

반면 복잡한 아키텍처는 좀 더 복잡하고 자동화되며 제약과 규칙이 많은 아키텍처를 이야기합니다. 많은 레이터나 티어 그리고 프레임워크들로 포진된 아키텍처들이죠.
이렇게 학습곡선이 높은 기술을 사용하면 초기 생산성이 낮아지고 유지보수 비용 높아지지만 구현의 난이도가 높은 기능도 쉽게 해결된다.
(초기 생산성 및 유지보수 비용은 논란거리입니다. 많은 프레임워크가 이 비용을 낮춘다고 이야기하지만 학습곡선, 인력수급, 프레임워크 유지비용 등 이야기할 거리가 많아 단정짓기는 어렵습니다. 확실한 건 복잡하고 거대한 아키텍처가 단순한 아키텍처보다 유지하는데 비용이 많이 드는 사실입니다.)

어느 것을 선택해야하나?

서비스 초기에는 간단한 아키텍처가 당연히 유리합니다. 우선 초기에는 비즈니스 성공을 위한 time to market이 중요하고 비즈니스 향방에 따라 민첩하게 움직일 수 있는 간단한 아키텍처가 유리합니다.

비즈니스 규모가 성장하면 더 이상 시스템이 따라가기 어려운 때가 올 것입니다. 이 때가 아키텍처 개선이 필요한 때입니다. 어느 정도 성장하면 미래의 비즈니스 방향과 규모가 예측될 것이며 그 비즈니스 목표를 이루기에 무리없는 좀 더 복잡한 아키텍처로 이동합니다.

초기부터 복잡한 아키텍처를 적용할 경우

그러면 애초부터 견고한 아키텍처를 가지고 가는 것이 맞지 않냐는 반문을 할 수 있습니다. 비용이 많이 들어 초기부터 투자하기 어렵다니 이런 것은 빼더라도 초기부터 복잡하고 견고한 아키텍처를 적용하기 어려운 이유는

첫째 미래는 예측하기 어렵습니다. 초기에 구축한 아키텍처가 미래에 필요한 기능에 적합한 아키텍처라고 장담할 수 없습니다. 비즈니스가 예측한 방향으로 가지 않을 경우 아키텍처를 고쳐야 할 수도 있습니다.

둘째 비즈니스 향방에 따라 빨리 쫓아가기 어려울 수가 있습니다. 많은 경우 프레임워크나 아키텍처가 견고해 질수록 여러가지 제약과 규칙이 있어 다양한 방법의 기술적인 시도가 어렵습니다. 이는 대기업 조직이 그 규모를 지탱할 수 있는 모양으로 견고하지만 비즈니스 민첩성에 불리한 이유와 같습니다.

(이미지출처)

이런 전략을 피해야 할 경우

- 차세대 프로젝트

이런 프로젝트는 이미 비즈니스는 거의 확정되어 있고 그간의 문제를 해결하고 업그레이드 하는 경우입니다.

즉 위에서 말한 성장을 위한 거대한 구조개선인 경우입니다. 이런 경우 쉬운 기술로 접근할 것이 아니라 비즈니스의 목표를 이룰 수 있는 견고한 기술과 아키텍처가 필요합니다.

- 이미 전사 아키텍처가 결정된 경우

당연히 그냥 따르십시오. 다양한 기술구조를 가진 아키텍처는 비용이 많이 듭니다. 아키텍처의 변화가 필요하다면 POC(또는 스파이크)와 파일럿을 통해 해결하고 점차 비즈니스 요구가 있는 곳부터 바꿉니다.

비즈니스 규모에 맞는 아키텍처

무조건 어려운 기술과 멋진 아키텍처가 좋지도 않습니다. 그렇다고 쉽고 가벼운 아키텍처가 무조건 좋다는 이야기도 아닙니다.

회사가 처음에는 낮은 비용의 민첩성을 요구하는 구조가 필요하고 회사가 성장하면 규모를 지탱할 수 있는 견고한 구조가 필요합니다. 작은 회사가 대기업의 구조를 가지는 것도 불리하고 대기업이 적은 비용의 관리 구조를 가지는 것도 역시 불가능합니다.

목표 시스템의 비즈니스 규모에 따라 아키텍처도 변해야 합니다.

우연히... JavaService Net 에서 VO를 써야한다 말아야한다 논쟁하는 쓰레드를 보았습니다. 양쪽 다 일리가 있지만 어떤 상황과 가정없이는 끝나지 않는 논쟁같습니다.
아키텍처 논의나 결정에서는 Mission, Environment, Stakeholder과 같은 상황과 가정을 바탕으로 타당성(Rational)을 따져야 합니다. 기술로만 이야기하면 끝없는 논쟁에만 빠집니다.

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

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

'아키텍처' 카테고리의 다른 글

언어가 사고를 제한한다. 기술이 가능성을 제한한다. (2)	2011/07/18
정경유착 (政經癒着) (0)	2010/04/06
'을(乙)'을 위한 아키텍처 (2)	2010/03/25
개발자 그룹을 장악하는 방법 (6)	2010/03/24
사람을 위한 아키텍처 (2)	2010/03/05
비즈니스에 관심이 없는 아키텍트 (0)	2010/02/17

급한 이벤트로 계획(스프린트)이 자꾸 망가질 때...

행복한아빠 — Wed, 13 Jul 2011 12:42:07 +0900

세상이 계획대로 흘러가면 좋겠지만 항상 그렇지는 않습니다. 항상 제일 바쁠 때 일이 생기고 항상 급할 때 장애물이 발견됩니다. 우리 부서는 제품도 개발하고 제품 시연도 해야하고 특히 기술 지원도 해야 합니다.
제품 개발이야 정확한 추정에 따른 계획으로 진행되지만 기술지원 같은 것은 예상치 못한 때 발생합니다. 스크럼에서 팀원들이 업무에 집중할 수 없도록 방해하는 이런 것들을 퉁쳐서
"잡음(noise)"라고 하죠. (이미지출처)

내 인생의 방해물 노이즈

이처럼 계획을 망치는 잡음을 줄이는 책임은 스크럼마스터가 주로 담당합니다. 즉 스크럼마스터가 얼마나 업무 잡음을 줄이는가에 따라 프로젝트 계획(스프린트)들의 성공여부가 결정되는 경우가 많습니다.
스크럼마스터나 팀의 역량 그리고 상황에 따라 이런 잡음을 막느냐 못 막느냐가 결정되는데 역량이 부족한 팀일 경우 아래 그림과 같이 일정의 상당부분을 계획된 작업보다는 그 때 그 때 발생하는 작업에 주로 사용합니다.

잡음은 계획을 아주 쉽게 무너뜨린다.

갑자기 발생하는 급한 업무가 발생하면 그 일정에 해당 업무에 대한 Todo(백로그)를 넣습니다. 그럼 그 계획(스프린트)에서 새로 발생한 업무량(스토리점수)만큼 우선순위가 낮은 업무를 제거하거나 연기해야 합니다.
이런 계획 조정이 빈번하게 발생하면 아무리 철저하게 계획(스프린트)을 관리하는 조직일지라도 어느 순간 계획은 계획일 뿐 계획대로 움직이지 않게 됩니다.

(이미지출처)

이런 상황이 되면 팀원들은 목표를 잃게 되고 그날 그날, 그냥 그냥 일하게 됩니다. 그냥 그냥 열심히...

제어할 수 있는 영역을 점점 넓히자.

잡음이 계획에 나쁘기는 하지만 중요하지 않다는 것은 아닙니다. 대부분 급하고 중요하기 때문에(그렇지 않은 경우도 많이 있고 ㅜㅜ) 계획을 무시하고 먼저하게 됩니다.

우선 자기 팀이 일정한 기간동안의 계획(스프린트)중에 어느 정도 계획 외의 작업(잡음)에 시간을 쓰지는 대략적으로 계산합니다. 만일 2/3는 일정에 있는 작업보다 그 때 그 때 발생하는 업무를 처리하는데 쓰인다면 계획의 2/3는 아무 이름이 없는 작은 작업으로 만듭니다. 스크럼 용어를 빌리자면 스프린트의 백로그 중 2/3를 이름 없는 백로그로 만듭니다. 예를 들어 팀이 한 스프린트당 30점을 수행한다면 이름없는 백로그를 2점짜리 10장을 만들어 20점을 할당합니다. 10점에 대해서만 계획에 의한 백로그를 할당합니다.

이 이름 없는 작업(백로그)로는 어떤 일도 할 수 있습니다. 즉 작업수행에 있어 백지수표와 같은 거죠. 계획대로 수행하다가 잡음에 의한 업무가 발행하면 이름 없는 작업카드를 이용하여 처리합니다. 그리고 가능한 10점은 계획대로 수행합니다.
그 다음 스프린트에서는 계획된 10점을 15점으로 그 다음은 20점으로 계획대로 진행하는 업무비중을 넓힙니다. 즉 백지수표 양을 점점 줄입니다.

이런 식으로 할 경우 최소한의 목표를 달성할 수 있어 팀은 목표를 잃지 않게 되며 점점 성과를 나타내게 됩니다. 그러면 이상하게도 급한 일은 줄어들고 많은 일들이 그 팀이 제어할 수 있는 영역에 속하게 됩니다.

중요도와 긴급도

아래 표는 시간관리에서 종종 볼 수 있는 표입니다. 모든 일들을 중요한 일과 긴급한 일로 구분하면 아래 표에 다 넣을 수 있습니다.

시간관리의 노하우는 II 영역의 일에 집중하는 것입니다. 그렇게 한다면 오히려 제일 중요한 것 같았던 I 영역이 줄어들면서 작업을 쫓아가는 인생에서 벗어나 중요한 일들을 미리 미리 준비하는 인생으로 전환하는 거죠~
이런 방법과 유사하다고 생각하면 됩니다.

응용...

소프트웨어 결함의 출몰은 계획을 망치기도 합니다. 결함이 발견되면 즉시 처리해야 가장 효율적입니다. 발견된 시기가 결함에 대한 정보가 가장 많고 고치기도 쉽습니다. 미루면 결함은 숨거나 잊혀지곤 하죠. 그리고 나중에 우리를 심하게 괴롭힙니다.
그래서 우리는 위의 방법을 응용하여 계획 중에도 결함이 발생되면 즉시 처리할 수 있는 방법을 사용합니다. 결함카드라는 방법을 이용합니다. (결함카드)

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

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

'애자일' 카테고리의 다른 글

실전! 플래닝 포커 (0)	2011/11/23
다수결로 프로젝트가 성공한 예 (0)	2011/10/12
급한 이벤트로 계획(스프린트)이 자꾸 망가질 때... (0)	2011/07/13
새로운 형태의 작업이 추정이 어려울 때 (0)	2011/07/11
애자일 게임을 하다 (0)	2011/06/20
Agile에 대한 12가지 질문들 (2)	2011/06/13

새로운 형태의 작업이 추정이 어려울 때

행복한아빠 — Mon, 11 Jul 2011 20:22:21 +0900

새로운 형태의 작업들을 수행하게 되었습니다. 팀원들이 이제 추정에 익숙해 웬만한 작업들은 2~3번의 플래닝포커로 상당히 정확한 추정치를 내놓습니다. 그러나 세상은 그리 간단하지 않은가 봅니다. 추정에 대해 좀처럼 의견일치를 보이지 않습니다.
(이미지출처)

상황

제품 리뉴얼 작업을 진행하고 있는데 작업 개수가 상당합니다. 기능이나 난이도는 잘 알고 있는 내용이라 추정을 빨리 끝내고 싶습니다. 그런데 이 모든 작업을 하나하나 논의를 거쳐 모두 추정하기를 어렵습니다.

그리고 작업의 형태로 아직 정확하지 않습니다. 어떤 이는 각 작업이 상당히 쉽게 끝날 것이라고 예상하고 어떤 이는 시간 걸리는 작업이 많다고 주장합니다.

스프린트를 멈추고...

직접 수행해보고 속도를 측정하기로 합니다. 일단 스프린트를 멈춥니다. 그리고 충분한 양의 백로그를 만들어 놓습니다. 그리고 대략적인 우선순위로 백로그를 길게 상황판에 늘어놓습니다.
이제부터 복불복 시작입니다. 모두 백로그 카드를 집어들고 하나씩 공략합니다. 한 카드를 완료한 사람은 무조건 우선순위에 따라 다음 카드를 수행합니다. 고르지 않습니다. 그냥 복불복 게임입니다. 고를 경우 쉬운 것부터 수행하는 경향이 있어 속도가 실제보다 더 빠르게 측정됩니다.
이렇게 그냥 일주일동안 해봅니다. 이제 새로운 작업에 대한 대략적인 속도가 나왔습니다.
그렇습니다. 그냥 일단 해보는 겁니다.

(이미지출처)

고민하지 말자.

어떤 하나의 사건에 대해 갑론을박하는 경우 회의를 통해 허송세월 보내지 말고 될 수 있으면 직접 해보면 됩니다. 모든 일이 그렇지는 않겠지만 이 상황과 같이 머리 싸매고 따지는 것 보다는 직접 해보는 것이 이득인 경우가 많습니다.

이렇게 해서 우리는 일주일 스프린트는 멈추었지만 새로운 형태의 작업에 대한 제법 정확한 추정치와 속도를 얻었습니다. 물론 일주일 동안 상당량의 백로그도 끝냈지요.

머리가 안되면 몸이 고생?

물론 그런 경우도 있겠습니다만... 저는 몸 고생(?)하지 않으려고 회의만 주구장창하는 경우를 더 많이 보았습니다. 결국은 이상한 결론에 도달하거나 시간에 쫓겨 수 많은 밤샘으로 더 몸을 혹사시키는 경우도 많습니다.

새로운 형태의 도전을 위해 이것 저것 생각하다가 결국 시간에 쫓겨 못하거나 포기하는 경우가 종종 있습니다. 일단 그림을 그리기 위해 도화지(편집기)에 점(코드)을 하나 찍으세요. 우리에게는 수정할 기회가 있습니다.

후~ 써놓고 보니 저 자신에게 하는 이야기를 썼습니다.

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

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

'애자일' 카테고리의 다른 글

다수결로 프로젝트가 성공한 예 (0)	2011/10/12
급한 이벤트로 계획(스프린트)이 자꾸 망가질 때... (0)	2011/07/13
새로운 형태의 작업이 추정이 어려울 때 (0)	2011/07/11
애자일 게임을 하다 (0)	2011/06/20
Agile에 대한 12가지 질문들 (2)	2011/06/13
복불복 스프린트 (4)	2010/11/09

Java 웹애플리케이션에서 Flash scope 구현 - 메시지 출력 문제

행복한아빠 — Thu, 23 Jun 2011 20:27:43 +0900

우리는 Spring + Jersey (JAX-RS JSR311 구현체) 프레임워크를 이용하여 웹 애플리션을 구현하고 있습니다. JSR311에 충실한 웹프레임워크라 필요한 기능들은 좀 추가해야 합니다.
Flash scope를 지원하는 프레임워크도 있는데 우리가 쓰는 프레임워크에서는 지원하지 않아 추가해봅니다.
(이미지출처)

Flash 범위란?

기본 Java 웹 애플리케이션에서는 값을 전달하는 방법으로 page, request, session 그리고 application을 지원합니다. 그런데 웹 애플리케이션을 작성하다보면 페이지 리로드(F5)에 의해 여러 번 submit이 되는 것을 방지하기 위해 post/redirect/get 설계방식을 사용합니다.

1. POST: 등록을 위해 post로 submit 한다.

2. Redirect: 조회페이지로 리다이렉트한다.

3. GET: 브라우저는 GET 방식으로 리다이렉트하는 페이지를 조회한다.

여기서 1.POST 와 3.GET은 서로 다른 요청이기에 이 요청사이의 연결은 이어지지 않습니다. 그런데 등록 후 조회페이지에서 "등록되었습니다."라는 메시지를 출력하고 싶은 경우가 있습니다. Java 웹 애플리케이션에서 기본적으로 제공하는 scope이나 장치를 쓰면.

1. 우선 page, request로는 메시지를 다음 요청으로 넘길 수 없습니다.

2. parameter로 메시지를 넘기는 방법:

긴 메시지가 URL에 나타나고 페이지 리로드(F5)하면 메시지가 또 출력됩니다.
사용자가 혼란스러워 합니다.

3. session scope를 이용하면:

session에 저장된 메시지를 매번 삭제해야 하고 혹 남아 있을 경우 오작동을 할 가능성이 있습니다.

session 사용은 restful한 서비스 작성에 좋지 않을 뿐더러 전역변수 같은 성격이 있어 좋지 않습니다.

4. application scope??:

이 놈은 전체가 공유하는 놈이라 쓸 수 없습니다. A 사용자의 메시지가 B 사용자에게도 보일 수 있습니다.
-.-;

Rails나 Grails 같은 프레임워크는 이러한 경우를 위해 바로 다음 요청까지만 유효한 flash scope를 지원합니다.

구현방법

서블릿 필터를 이용하여 쉽게 구현할 수 있습니다. 구동방식을 아래와 같습니다.

POST

1-1. 먼저 Action 클래스같은 비즈니스 로직에서 등록 후 request scope에 "flash."로 시작하는 키값으로
메시지를 저장하고 조회페이지로 redirect 합니다.

1-2. 서블릿 필터에서는 "flash."로 시작하는 값이 있을 경우 이를 잠시 session에 넣어둡니다.

Redirect 후 GET

2-1. 서블릿 필터에서는 session에서 위 값을 꺼내고 해당 요청의 request scope에 값을
"flash." prefix는 제거하고 request scope에 저장합니다.

2-2. 그리고 이 session값은 지웁니다. (이 다음의 요청에서는 사용 못하도록)

2-3. 비즈니스 로직을 실행 후 JSP에서는 request scope에 저장된 메시지를 출력합니다.

예를 들어 등록 후 다음과 같이 메시지를 저장합니다.

다음 요청의 JSP에서는 다음과 같이 메시지를 출력합니다.

서블릿 필터 소스는 아래와 같습니다.

import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
import java.io.IOException;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Map;

public class FlashScopeFilter implements Filter {

private static final String FLASH_SESSION_KEY = "FLASH_SESSION_KEY";

@SuppressWarnings("unchecked")
    public void doFilter(ServletRequest request, ServletResponse response,
					FilterChain chain) throws IOException, ServletException {

//reinstate any flash scoped params from the users session
	//and clear the session
        if (request instanceof HttpServletRequest) {
            HttpServletRequest httpRequest = (HttpServletRequest) request;
            HttpSession session = httpRequest.getSession(false);
            if (session != null) {
                Map<String, Object> flashParams = (Map<String, Object>)
									session.getAttribute(FLASH_SESSION_KEY);
                if (flashParams != null) {
                    for (Map.Entry<String, Object> flashEntry : flashParams.entrySet()) {
                        request.setAttribute(flashEntry.getKey(), flashEntry.getValue());
                    }
                    session.removeAttribute(FLASH_SESSION_KEY);
                }
            }
        }

//process the chain
        chain.doFilter(request, response);

//store any flash scoped params in the user's session for the
		//next request
        if (request instanceof HttpServletRequest) {
            HttpServletRequest httpRequest = (HttpServletRequest) request;
            Map<String, Object> flashParams = new HashMap();
			Enumeration e = httpRequest.getAttributeNames();
            while (e.hasMoreElements()) {
                String paramName = (String) e.nextElement();
                if (paramName.startsWith("flash.")) {
                    Object value = request.getAttribute(paramName);
                    paramName = paramName.substring(6, paramName.length());
                    flashParams.put(paramName, value);
                }
            }
            if (flashParams.size() > 0) {
                HttpSession session = httpRequest.getSession(false);
                session.setAttribute(FLASH_SESSION_KEY, flashParams);
            }
        }
    }

public void init(FilterConfig filterConfig) throws ServletException {
        //no-op
    }

public void destroy() {
        //no-op
    }
}

이 소스는 특정 웹 프레임워크와 관계없이 작동합니다. 그대로 사용하거나 본인이 사용하는 프레임워크에 맞게 고쳐 사용할 수 있습니다.

우리의 응용

우리는 비즈니스 로직을 수행하는 Action(Jersey에서는 Resource라고 함)을 POJO로 작성하기에 request 객체 접근이 부자연스럽습니다.(쉽긴 하지만) 그래서 서블릿 필터에서 request 객체를 ThreadLocal에 저장하고 비즈니스 로직에서는 투명하게 메시지를 저장할 수 있도록 변경했습니다. 물론 요청을 빠져 나올 때는 필터에서 ThreadLocal에 저장한 request 객체를 지워야 합니다.

Flash.java

FlashScopeFilter.java

...
if (request instanceof HttpServletRequest) {
...
Flash.setRequest(httpRequest);
}

chain.doFilter(request, response);

if (request instanceof HttpServletRequest) {
...
Flash.clearRequest();
}

POST: 등록 후

GET: 다음 요청 JSP에서 메시지 출력은 동일합니다.

참고원문: http://blog.smartkey.co.uk/2011/01/implementing-flash-scope-in-java-web-applications/

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

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

'웹기술들' 카테고리의 다른 글

jQuery의 이벤트 ajax 핸들러에서의 scope 문제 해결책 (8)	2011/07/19
Java 웹애플리케이션에서 Flash scope 구현 - 메시지 출력 문제 (0)	2011/06/23
Struts 태그에서 자동생성되는 TD 태그 없애기 (4)	2010/03/22
스프링 프레임워크 3.0 GA 릴리즈 - 기능 요약 (0)	2009/12/30
Flex에서 ExternalInterface 사용시 동기화 문제 (1)	2009/12/23
Java로 엑셀 다운로그 구현하기 (0)	2009/12/20