Whiteship's Note


[봄싹] XP 적용 시나리오 3. 개발하기

모하니?/Coding : 2009. 10. 29. 00:57


본격적으로 개발을 해야하는데, 봄싹에서는 오프라인에서 페어로 작업을 해보기도 했지만, 그렇게 자주 충분히 페어 프로그래밍을 했다고 볼 수는 없습니다. 앞으로도 좀 더 꾸준히 시도를 해봐야 그 효용이나 장단점을 파악할 수 있을 것 같습니다. 개인적으로는 뭔가 대화를 나누면서 코딩할 상대가 있어서 안심이 되긴 합니다. DB update 쿼리가 어떻게 되더라? 이거 무슨 리팩토링이지? 이 메서드 이름 맘에 들어? 여기 중복인데 어떻게 제거하면 좋을지 잘 모르겠네.. 같은 식으로 대화를 나눌 수 상대와 함께라면 좋치 않겠어요?


먼저 개발을 진행하기에 앞서 구현하려는 기능을 한 번도 만들어 본적이 없다면, 어느 정도 자신있게 개발을 진행할만큼의 학습이 필요합니다. 그 과정을 파일럿이고 표현했는데, XP 책에서도 파일럿이라고 헀었는지 잘 모르겠습니다. (뭐라고 했는지 찾아보려고 다시 살펴 봤는데 못 찾아서 그냥 썼습니다.)

그다음 과정은 좀 특이하게 바로 개발을 진행하지 않고, 인수 테스트를 만듭니다. 고객이 해당 작업이 완료 됐다는 것을 확인할 수 있는 모종의 장치를 마련하는 것이죠. 고객이 코드를 볼 수 있다면 아주 행복할텐데, 봄싹은 다행히(?) 고객이 전부 개발자 입니다. 굳이 엑셀로 이쁜 포맷을 만들고, 테스트에서 엑셀 로딩해서, 결과를 엑셀에 다시 찍어주고, 고객은 엑셀에서 수식 비교로 해당 테스트가 잘 됐나 안 됐나 확인하는 귀찮은 일은 할 필요가 없습니다. 그렇치만, 인수 테스트 코드가 고객이 원하는 시나리오를 제대로 표현해주지 못하거나, 고객이 개발자인데도 테스트 코드를 읽기가 난해하다면 테스트를 수정해야겠죠.

그다음은 페어 프로그래밍과 TDD로 해당 작업을 구현하는 일입니다. 페어 프로그래밍은 사실 오프라인에서 만났을 때의 얘기지 주중 저녁이나 회사에서 틈틈히 코딩을 하는 봄싹 개발자에데는 다소 난해한 일입니다. 그래도 메신저등을 통해서 의견은 주고 받을 수 있으니 그것도 페어 프로그래밍으로 치도록 하죠.

그렇게헤서 작업이 끝나면, 담당자 두 명은 자신들이 예상했던 난이도와 시간에 비해 실제로는 난이도가 어땠으며 실제로 소요된 시간은 어느정도인지 기록합니다. 고객은 해당 작업 결과를 본 뒤 간략한 피드백을 줍니다. "담부턴 더 빨리 만들어 주세요" 라던지.. "참 잘했어요" 라던지 ㅋ

top

Write a comment.


[봄싹] XP 적용 시나리오 2. 배포 계획하기

모하니?/Coding : 2009. 10. 29. 00:43


봄싹이 언제 배포됐었더라... 기억이 가물가물 합니다. 8월 30일이었나. 이제 두 달을 향해가고 있군요. 다음 배포 일정은 임의로 11월 30일로 잡아두었습니다. 세 달은 지나치게 긴 것 같습니다. 이미 봄싹 개발자들끼리는 새로운 UI를 만끽하고 있는데 봄싹 회원들에게 멋진 UI를 빨리 보여드리지 못하는게 아쉽습니다. 배포 일정과 스코프를 잘못 계획했기 때문입니다. UI 개선만을 1차 유지보수 스코프로 정하고 배포했다면 이미 봄싹 회원들은 멋진 UI를 감상하고 계실텐데 말이죠...


먼저 배포 일정을 잡은 다음, 모든 개발자들의 측정이 완료된 스토리 카드 중에서 해당 일정 안에 개발을 할 수 있을 것으로 보이는 스토리 카드들을 고릅니다. 이 일은 전적으로 고객이 합니다. 고객 생각에 어떤 것이 가장 필요하고 비즈니스에 도움이 되는지 생각해서 고르면 되겠죠. 일단 최대한 빨리 중요한 것부터 서비스하고 싶다면 다소 어렵고 일정이 긴 스토리 하나만 고를 수 있겠고, 중요한 건 나중에 공개하고 일단은 기반이 되는 소소한 것들 부터 서비스하고 싶다면, 쉽고, 개발 일정이 짧게 걸릴 것으로 측정된 것들을 고르면 되겠습니다.

그런다음, 하나의 스토리를 구현하는데 필요한 세부 작업들을 개발자들과 논의합니다.

"발표 도메인 객체를 추가해야겠습니다."
"발표와 모임 객체에 연관 관계를 설정해야 겠어요."
"발표에 댓글/첨부자료/발표자 정보가 필요하겠군요."
"새로운 모임을 추가할 때 아예 발표 정보도 추가할 수 있도록 하죠."
"스프링 웹 플로우 학습이 필요할 것 같습니다."
"발표정보 추가할 때 발표자를 선택하는 부분에서는 Ajax를 도입할 수도 있겠네요."
...

이런식으로 하나의 스토리를 구현하는데 필요한 세부적인 작업목록들을 만들어 나갑니다. 이때, 개발자들이 의견을 많이 주어야 하며, 작업 목록 작성은 고객이 담당합니다.

고객이 작업 목록 하나를 작성할 때 마다, 스토리를 등록했을 때 처럼, 평가하는 과정을 거칩니다. 해당 작업은 덩어리가 너무 크다거나, 좀 더 명시적으로 수정해 달라거나 의견을 제시하면서 투표를 할 수 있죠. 혹은 고객이 명시한 작업을 코딩할 수 있겠다는 판단이 들면, 난이도, 걸리는 시간, 같이 작업하고 싶은 사람을 적어서 측정해줍니다.

고객은 가장 낮은 난이도를 제시한 개발자, 가장 낮은 시간을 제시한 개발자, 가장 많은 지명도를 가진 개발자 등의 정보 통계를 보고 해당 작업의 적입자를 찾아서 작업 담당자와 그 파트너를 지정해줍니다. 이렇게해서 하나의 작업에 두 명의 담당자를 지정해 주는겁니다.

그럼 이제 그 두명의 담당자는 서로 의견을 나눠가며 개발을 진행하면 되겠죠!

다음은 개발 과정에 대해 생각해보죠.
top

Write a comment.


[봄싹] XP 적용 시나리오 1. 스토리 만들기

모하니?/Coding : 2009. 10. 29. 00:21


봄싹 프로젝트 개발이 지나치게 자유롭다 보니 프로젝트 스코프도 애매해지기 시작했고, 현재 누가 어디를 얼만큼 개발했는지 파악하기가 힘들어졌습니다. 나름대로, 이슈트래커, CI 환경, VCS까지 갖출 건 다 갖추고 진행하고 있지만 그래도 뭔가 좀 부족한 감이 없지 않습니다. 그래서 XP 책에서 읽은 내용을 토대로 봄싹 나름대로의 개발 프로세스를 정리해볼까 합니다.

물론, XP installed 책에 나와있는 그대로 할 필요도 없고, 그 책도 일종의 권고사항이지 반드시 따라야 하는 건 아니것 같기 때문에 제 맘대로 봄싹에 필요하면서도 재미있게 개발을 진행할 수 있는 방법을 궁리해봤습니다. xp 책은 그런면에서 좋은 아이디어를 떠올리는데 아주 좋더군요!


먼저, 현재 이슈트래커나, 구글 그룹에 올리고 있는 할 일을 스토리로 정리하는 방법을 생각해봤습니다. 누군가가 고객의 입장에서 스토리를 하나 만듭니다.

"모임에서 있었던 발표 정보를 별도로 관리하면 좋겠다."

이런 카드를 만드는 순간, 그 사람은 고객이 됩니다. 그리고 해당 스토리를 수정/삭제/세부 스토리 등록 등을 하는 권한이 생기죠. 그리고 이 카드가 생기는 순간 모든 개발자에게 메시지가 갑니다. 평가해 달라고..

그럼 일부의 개발자들은 해당 스토리가 너무 애매하다고 더 구체적으로 설명해 달라고 "고치자"를 클릭하며 어떻게 고쳐달라며 '의견'을 제시합니다.

또 다른 일부의 개발자들은 해당 스토리가 너무 방대하다면 좀 더 세부적으로 쪼개 달라며 "나누자"를 클릭하고 어떻게 나누면 좋겠는지 '의견'을 제시합니다.

또 다른 일부의 개발자들은 현재 스토리를 개발할 수 있다는 판단하게 '얼마나 걸릴지', '난이도가 어느정도인지', '누구와 함께하고 싶은지' "측정"을 합니다.

모든 개발자들의 측정이 이루어지기 전까지 사용자는 개발자들의 의견을 반영하여 계속해서 스토리를 수정하거나, 스토리의 하위 스토리를 등록하게 되고, 개발자는 스토리가 변경되거나, 새로운 스터디가 추가될 때마다 계속해서 측정 또는 투표를 할 수 있습니다.

이런식으로 스토리를 정제해 나가는 겁니다. 재밌지 않을까요? JIRA를 어떻게 잘 설정해서 쓰면 이렇게 할 수 있을것도 같긴 한데.. 좀.. 복잡해 보이는 UI가 위 시나리오에 적당해 보이지는 않습니다. 적당한 툴이 있으면 좋겠는데 없으면 봄싹 이슈트래커도 나중에 만들어야겠네요.

다음은 이렇게 정리된 스토리들을 가지고 배포 계획을 세우는 방법에 대해 생각해보겠습니다.

top

Write a comment.


개발자들의 수다 후기

모하니?/그냥 놀아 : 2008. 11. 9. 00:28


1, 2, 3부 전부 "국내 XP 적용"을 주제로 이야기를 듣고 나누다 왔습니다. 뒷풀이는 따라가지 못했지만, "수다"가 발전하는 모습을 본 것이 인상적이었습니다.

1부는 주로 테스트에 관한 얘기를 했었습니다. 테스트 작성 비용 떄문에 오히려 일정이 늘어나서 프로젝트가 실패한 사례를 들을 수 있었습니다. 반면 테스트를 작성함으로써 얻을 수 있는 장점들도 들을 수 있었죠. 테스트 코드 작성 때문에 추가 시간이 필요하긴 하지만 장기적으로 봤을 떄 유지보수 시간을 단축시킨다는 측면까지 고려한다면 결국은 개발 시간이 늘어나는게 아니라 오히려 단축시키는 걸 수도 있겠다고 생각하고 있습니다. 그리고 페어 프로그래밍 적용에 관한 이야기도 들었는데, 이 것과 관련해서는 2부에서 더 많은 논의가 이뤄졌습니다.

2부에서는 주로 페어 프로그래밍에 관한 이야기를 나눴습니다. 맨먼스를 어떻게 고려할 것이며, 작업 할 당은 어떻게 하며, 짝을 어떻게 구성하는지, 개발팀원이 자주(6개월 내지 1년) 변경 되는 경우에도 가능한지와 관련하여 페어 프로그래밍 적용을 해보신 분들의 경험담을 들을 수 있는 아주 드문 기회가 있었습니다. 정말 흥미로웠고 저도 페어프로그래밍을 꼭 해보고 싶어졌고, 지금보단 좀 더 사람이 많은(10명 이내) 프로젝트에 참여 해보고 싶단 생각이 들었습니다. 2부도 1부와 마찬가지로 주로 경험이 있으신 분들의 발언이 많았는데, 김창준님의 등장으로 분위기가 새롭게 바꼈습니다. 좀 더 Agile 스럽게 바꼈다고 해야하나. ㅎㅎ

3부에서는 해당 주제에 모인 사람들이 자신이 듣고 싶거나 전달하고 싶은 주제를 제시하고, 한 사람당 세 표를 행사하여 가장 관심이 많은 주제 두 개를 다뤘습니다. 그 중 하나는 애자일 관련 도구에 관한 이야기였습니다. 그 자리에 계신 분들이 XP에 관심이 있으셔서 그랬던 건지는 몰겠지만, 이슈 트래커, CI 툴도 사용하고 계시고, 기본적으로 SVN이나 CVS 같은 소스 코드 관리 툴 뿐만 아니라, GIT까지 사용하고 있단 얘기를 들었습니다. 그 사용 사례에 대해 더 자세히 듣고 싶었지만 시간 관계상 그럴 순 없었습니다. 또 하나는 제가 궁금했던 거. 데이터베이스 스키마와 데이터도 소스 코드처럼 버전 관리를 할 수 있는 도구가 있는데 그것을 사용하고 있는지, 사용하고 있지 않다면 앞으로 사용할 계획은 있는지를 물어봤었는데. 데이터베이스의 데이터가 워낙 중요하고 스키마 변경도 조심스럽기 때문에 해당 도구를 얼마나 신뢰할 수 있느냐가 관건이라는 의견을 들을 수 있었습니다. 또 그 중에는 그런 비슷한 기능을 하는 툴을 직접 만들어서 사용하고 계신 분도 있었습니다. 3부에서 다룬 두 번째 주제는 국내 Agile 적용 데이터 마이닝이었습니다. XP 실천 사항들의 상관성을 살펴볼 수 있었고 조직의 성숙도와 Agile 적용 만족도의 상관 관계도 들을 수 있었습니다. 이와 관련된 자세한 내용은 조만간 김창준님께서 글로 정리하신다고 하셨습니다. 기대됩니다.

오늘은 어떻게 하면 좀 더 체계적이고 효율적으로 논의를 나눌 수 있는지 경험할 수 있었고, XP에 대한 관심이 한층 증가하는 날이 되었습니다. 조만간 XP 실천 사항들을 점검해 봐야겠습니다. 열 몇 개라던데 뭐뭐가 있는지 말이죠... @.@

'모하니? > 그냥 놀아' 카테고리의 다른 글

저는 이제 Alabama에 왔습니다.  (0) 2008.12.07
LA에서 보낸 하루(?)  (6) 2008.12.01
지금은 공항이에요  (8) 2008.11.30
LA, 마이애미, 아틀란타 날씨  (0) 2008.11.28
회사 이사 중  (2) 2008.11.21
개발자들의 수다 후기  (0) 2008.11.09
꺄오~~ 살꺼야. 키보드. 카시오 PX-320  (8) 2008.10.30
보고 싶은 피아노 공연  (0) 2008.10.22
방송탔네~  (0) 2008.10.01
KSUG 도배 성공  (2) 2008.10.01
HP CP1215 맥에서 사용하기  (0) 2008.09.25
top

Write a comment.