ⓒ한빛미디어


해외에서 출간되어 번역된 애자일 관련 서적은 읽기가 힘들다. 책을 읽다 보면 손발이 오그라드는 적이 한 두번이 아니다. 기업 문화나 개발 문화의 차이라기 보다는 국가 간 문화 차이에서 비롯된 사고 방식과 행동 패턴이 다르기 때문이다. 민주주의를 수백 년간 체험하고 개인주의가 이미 일상이 되어 있는 사람들이 쓴 책에는 당연히 이러한 정서가 녹아 있다. 이를 우리 실정에 그대로 적용하기는 무리가 있다. 


다른 나라 개발자들에게 이런 내용을 자연스럽게 받아 들이는지 물어본 적이 없기 때문에 나만의 편견일 수도 있겠다. 하지만 이렇게 결정을 내릴 수 있는 근거은 평소 업무나 회의 때 보여주는 사람들의 모습이나 국내 ICT 일선에 있는 작가들이 지은 책들과 비교해 보면 분명 차이가 있기 때문이다.


그래도 나름 재미있게 읽었다. 소설이면서 그 구성이 독자의 판단에 따라 페이지를 왔다 갔다 하며 여러 가지 결론을 내릴 수 있는 방식이다. 어릴 적 추리 소설을 읽는 듯 반갑다. 이 점이 앞에서 이야기한 거부감을 낮춰 주었다. 표지는 만화로 되어 있어 싫어하는 분도 계시던데 오히려 이 점이 딱딱한 내용을 쉽고 재밌게 풀어주는 역할을 더했다고 본다.


내용은 꼬여 있는 프로젝트 팀에서 애자일 코치(주인공이자 독자)가 투입되면서 시작한다. 제품 기획자는 팀의 개발 속도를 고려하지 않고 일을 투입한다. 팀원들끼리는 사이가 대면대면하다. 애자일을 사내에서 최초로 도입해서 사용하고 있지만 불만이 많다. 이에 남은 3번의 스프린트 기간 동안 다른 애자일 팀과 협업해서 백로그를 팀의 사정에 맞게 재조정하고 경영진에게 보고하는 것으로 마무리 한다.


있을 법한 이야기를 잘 읽었다는 데에 만족하다. 실상은 이렇게 잘 풀리지 않는 경우가 더 많다. 능력있는 애자일 코치가, 아니 애자일 코치라는 인력 자체가 투입되는 경우가 드물다. 1주만에 팀웍이 눈에 띄게 좋아지지도 않는다. 결론은 애자일 도구와 실천법을 배우고 성공하는 팀의 분위기를 파악하는 데에 만족한다.


별점은 3개.

저작자 표시 비영리 변경 금지
신고

'Agile' 카테고리의 다른 글

드림팀의 악몽 애자일로 뒤엎기  (0) 2014.10.12
개인 업무 일일 회고  (0) 2014.10.12
굳어진 프로세스(시스템)  (0) 2012.01.05
애자일이 뭔가요?  (0) 2011.12.13
코드 리뷰에 관한 충고  (0) 2011.11.04
인지부조화와 스탠드업 미팅  (0) 2011.07.17

'드림팀의 악몽 애자일로 뒤엎기'라는 책을 읽다 문득 생각 나서 이 카테고리를 만들었다. 


애자일 코치인 주인공이 '코치 로그'라는 것을 남기기길래 유용하다 싶어 따라해 본다. 물론 이후의 글은 모두 비공개.


형식은 다음과 같다.

활동

  • ~~

  • ~~

잘한 일
  • ~~

  • ~~

잘못 한 일
  • ~~

  • ~~

궁금한 점
  • ~~

  • ~~

개선 활동
  • ~~

  • ~~

오늘의 점수: 10점만점에 8점



저작자 표시
신고

'Agile' 카테고리의 다른 글

드림팀의 악몽 애자일로 뒤엎기  (0) 2014.10.12
개인 업무 일일 회고  (0) 2014.10.12
굳어진 프로세스(시스템)  (0) 2012.01.05
애자일이 뭔가요?  (0) 2011.12.13
코드 리뷰에 관한 충고  (0) 2011.11.04
인지부조화와 스탠드업 미팅  (0) 2011.07.17

Xper에서 온 메일을 읽다가 좋은 글귀가 있어 옮겨 적어 봅니다.

시스템은,
이미 하고 있는 일에 낭비가 있을 때 적용되는 것이

새로운 틀이 되어버리면 프로세스에 없던 낭비도 생겨버리는 게 시스템이다.
 

저작자 표시 비영리 동일 조건 변경 허락
신고

'Agile' 카테고리의 다른 글

드림팀의 악몽 애자일로 뒤엎기  (0) 2014.10.12
개인 업무 일일 회고  (0) 2014.10.12
굳어진 프로세스(시스템)  (0) 2012.01.05
애자일이 뭔가요?  (0) 2011.12.13
코드 리뷰에 관한 충고  (0) 2011.11.04
인지부조화와 스탠드업 미팅  (0) 2011.07.17

애자일이 뭔가요?

Agile 2011.12.13 17:08

"애자일 소프트웨어 개발"이라는 프리젠테이션 자료입니다.

http://prezi.com/e4h9tu4cgyzd/presentation/


잘 정리한 것 같습니다.

 

하지만 우리의 현실은 힘듭니다.

점차 나아지리라 생각합니다.

저작자 표시 비영리 동일 조건 변경 허락
신고

'Agile' 카테고리의 다른 글

개인 업무 일일 회고  (0) 2014.10.12
굳어진 프로세스(시스템)  (0) 2012.01.05
애자일이 뭔가요?  (0) 2011.12.13
코드 리뷰에 관한 충고  (0) 2011.11.04
인지부조화와 스탠드업 미팅  (0) 2011.07.17
개발자들이 리팩토링을 하지 않는 이유  (4) 2011.06.20

안녕하세요? 요즘 바빠서 글을 쓰지 못했습니다.

저희 회사에서는 최근 구글에서 만든 Gerrit이라는 코드리뷰 시스템을 적극 활용하고 있습니다.

GIT과 연동이 잘 되고, Android를 개발하면서 코드리뷰를 시스템화하여 로그를 남기고 메일도 자동발송하여 커뮤니케이션이 자연스럽게 활성화 되도록 유도합니다.
또한 구글이 만든 만큼 속도도 보장합니다.

하지만 이를 위해서는 형상관리를 위해서는 GIT사용이 필수가 되어야 하고 각 App. 파트에서 개별적으로 쓰고 있는 SVN사용자가 불편해 하여 코드리뷰 문화가 정착되지 않는 느낌이 있습니다. 

결국 실장님이 적극(강제적으로 ㅎㅎ)쓰도록 유도하라는 지시가 내려가게 되었고, Commit사용량을 조사하여 보고하게 되자, 개발자들은 패치를 잘게 쪼개어 올리고 있습니다 @@;;
역시 개발자들이 쪼임을 피해나가는 방법을 강구하는 것은 막을 수 없습니다. ㅎㅎ

여튼 코드리뷰 문화는 활성화되어 정착되는게 좋겠죠? ^^
이와 관련하여 좋은 글이 있어 링크로 공유합니다.
함께 xper 메일링 리스트에 Min님이 번역하신 글도 같이 올립니다.

http://blogs.atlassian.com/2010/03/code_review_in_agile_teams_part_ii/ 

* 코드리뷰에 대한 오해 

- 버그를 발견하는 것을 보장하진 않는다 

- 코드의 결함을 찾는 것이 목적이 아니라, 서로 배우고 가르쳐 주고, 팀의 협업능력을 높여주는 것이어야 한다. (그렇지 않으면 팀이 
깨어진다) 

* 코드리뷰가 잘 되려면 

- 너무 많은 절차와 규칙을 만들지 마라. 절차를 아주아주아주 간단하게 하라 

- 강요하지 마라. 대신 Encourage 하라 

- 모든 코드 commit 을 리뷰하도록 한다거나 하는 형태로 Micro - Manage 를 하지마라 

- 개개인의 작업 흐름을 끊지마라 

- 코드리뷰를 통해 발견한 것들을 널리 공유하라 

- 코드리뷰를 늦게 하는것은 안하는 것보다 나쁠수 있다. Iteration 에 포함시켜라 

- 한꺼번에 덜하기보다는 조금씩 자주하라 

- 툴에 얽메이지 마라, 중요한것은 개발자들이 서로 대화를 하고 코드를 공유하는 것이다 

- 너무 많은 리뷰어를 참여시키지 마라. 2-4 명이 적당하다 

* 어떻게 잘 되고 있는지 알수 있는가 

- 쉽진 않다, 사실 필요없을 수도/불가능 할수도 있다, metric 에 집착할 필요는 없다. 

- 장기간의 이득은 측정할 수 없지만 많다 

- Simple Metric 들이면 충분할 수 있다. (리뷰에 사용된 시간, 리뷰 comment 등).

저작자 표시 비영리 동일 조건 변경 허락
신고

인지부조화(認知不調和)
사람은 자신의 태도간에 혹은 
태도와 행동간에 일관되지 않거나 모순이 존재할 때 이러한 비일관성이나 모순을 불쾌하게 여겨 이것을 감소시키려고 한다. 이러한 모순을 줄이기 위해 사람은 태도나 행동을 바꾸려 시도하는데, 태도는 다른 사람들이 모르지만 행동은 이미 다른 사람들이 알고 있으므로, 행동에 맞게 태도를 바꾸게 된다.
예)담배를 피우는 사람이 담배에 대해 몸에 좋지 않다고 생각을 하지만 담배를 끊지 못하고 계속 핀다. 이것은 생각과 행동이 일치하지 않는 인지부조화를 일으킨다. 이럴 때 사람은 담배를 끊던지 아니면 담배에 대한 부정적인 생각을 바꾸게 된다.
                                                                         - 레온 페스팅거 

최근에 읽은 "도와주세요! 팀장이 됐어요 (신승환, 위키북스)"에서 아침 스탠드업 미팅의 효과를 인지부조화 이론을 근거로 설명합니다.
스탠드업 미팅에서는 출근 후 개인당 약 2~3분 내로 각자 돌아가며 다음 이야기를 합니다.

1. 어제 한 일
2. 오늘 할 일
3. 이슈 사항
 
여기에서 인지부조화가 일어나게 되는데, 바로 내가 오늘 해야겠다고 마음 먹은 일을 지키기 위해 행동으로 옮긴다는 것입니다.

그리고 평소에 부정적인 견해를 가지고 있는 팀원은 자신이 한 말을 지키기 위해 '안되는 방향으로 행동을 옮긴다'고 합니다.
항상 긍정정적으로 생각합시다. ^^


저작자 표시 비영리 동일 조건 변경 허락
신고


  "리팩토링"(Martin Fowler저)에서 개발자들이 프로그램을 리팩토링 하지 않는 이유에 대해 Willam Opdyke가 다음과 같이 이야기 하고 있습니다.

1. 리팩토링을 하는 방법을 이해하지 못한다.
2. 리팩토링이 장기적으로 이익이라면, 왜 지금 당장 노력을 기울여야 하는가? 장기적으로 리팩토링의 이익을 챙길 그 프로젝트에 있지 않을 수도 있다.
3. 코드를 리팩토링하는 것은 오버헤드다. 여러분이 해야 하는 일은 새로운 기능을 추가하는 것이다.
4. 리팩토링은 기존 프로그램을 망칠 수 있다.


  정말 정곡을 찔러 주네요. 회사 내에서 뭔가 코드 정리활동 같은 걸 하고자 하면 늘상 하는 핑계들입니다.

  이 책에서는 위 네 가지 핑계에 대한 해답도 제시하고 있습니다.

1. 어디를 어떻게 리팩토링 해야 하는가?
  이 책과 여타 논문들에서 리팩토링을 템플릿 처럼 (이름까지 붙여가며) 만들어 놓았습니다. 물론 리팩토링 템플릿이라는 것이 고수들의 경험을 바탕으로 깔끔한 코드를 작성하는 방법을 기술한 것이기 때문에 상황에 맞게 적용해야 합니다. 각 리팩토링 예제를 무작정 따라하기 전에 왜 이런 리팩토링을 해야 하는 지 꼼꼼하게 읽고 이해해야 합니다.

2. 단기적인 이점을 달성하기 위한 리팩토링
  우리 회사에서 너무도 자주 접하는 상황입니다. 지금 진행중인 프로젝트만 끝나면 버리는 코드가 될 지도 모르고, 현재 프로젝트의 코드 베이스를 가져다 쓰게 될 다음 프로젝트에 투입될 지 말지도 모르는 데 뭐하러 노력을 들여가며 리팩토링을 하냐고 말들 합니다. 그러고는 쓰레기 같은 코드를 당연하다는 듯이 작성합니다. 이런 사람들을 보면 도대체 일을 하면서 배우고 나아지고자 하는 자세가 안되어 있는 것 같아 안타깝습니다.
  100보 양보해서 피쳐폰을 개발할 때야 플랫폼이 자주 바뀌어서 같은 코드베이스를 사용하는 모델 수가 적다고 해도, 안드로이드가 대세인 요즘에는 이런 자세를 좀 고쳐야 하지 않을까요?

  책에서 이야기하고 있는 단기적, 중기적 이점은 다음과 같습니다.
- 단기적 이점: 테스트 중 공통으로 사용되는 부분에서 발견되는 에러는 단지 한 곳에서만 수정하면 된다. 그리고 코드 크기가 더 작아진다.
- 중기적 이점: 리팩토링 과정 중 추상화가 되었기 때문에 다른 파일 시스템(또는 클래스, 기능 등으로 이해해도 무방)을 추가하기가 쉬워졌다. 

3. 리팩토링의 오버헤드 줄이기
  아, 정말 리팩토링은 무의미한 오버로드 인가요? 아니면 너무도 많은 업무에 치여 자기 코드를 손 볼 여유도 없어져 버린 건가요? 자 요즘에는 리팩토링을 자동으로 해 주는 도구가 많이 존재합니다. 코딩 능력을 향상시키고자 한다면 이런 툴을 능수능란하게 사용하는 것도 필수입니다. Eclipse를 쓰고 계신다면 Refactor 메뉴를 참고하세요.

4. 리팩토링을 안전하게
- 여러분의 코딩 능력을 믿어라
- 여러분이 놓친 에러들을 컴파일러가 발견할 것이라고 믿어라
- 여러분과 컴파일러가 놓친 에러를 테스트 스위트(test suite)가 발견할 것이라고 믿어라  (TDD는 필수입니다!)
- 여러분, 컴파일러, 테스트 스위트가 놓친 에러는 코드 검토(code review)에서 발견될 것이라고 믿어라

  위 4가지 안전장치에서도 걸러지지 않는 에러가 있을 가능성이 충분히 있습니다. 그렇다고 리팩토링을 하지 않을 건가요? 꼼꼼한 당신을 위해 추천하는 코딩습관이 더 있습니다. 리팩토링은 짝 프로그래밍을 통해 그리고 평소에 정적 분석 툴을 사용하는 습관을 들입시다.

  이 장에서 제가 가장 마음에 들었던 문장으로 마무리 합니다. 제 경험상 이는 진실입니다.

프로그래머는 그들의 코드를 리팩토링하면 할수록 더 잘 이해하게 될 것이다.
- Willam Opdyke


저작자 표시 비영리 변경 금지
신고


"실용주의 사고와 학습(Pragmatic Thinking & Learning - Refactor Your Wetware)" - 앤디헌트 / 박영록 번역/ 김창준 감수, 위키북스



오늘 부산에 다녀오는 기차간에서 드디어 이 책을 다 읽었습니다.
보통은 책을 읽다 보면 책을 거의 다 읽어 갈때 쯤 (4/3정도?) 되면 책에 대한 집중도도 떨어지고
흥미를 그다지 끌지 못한 책은 그냥 던져버리게 되죠. (저만 그런가요? @@;)

이 책이 뇌 활용방안과 학습에 대한 내용이다 보니 책 부록까지 꼼꼼하게 읽게 되더군요.
문득 다음 방법도 좋은 '의도적 학습'이 되겠다 싶은 생각이 들었습니다.

책을 다 읽고 난 후 '찾아보기'을 읽고 모르는 단어를 다시 찾아본다.


이렇게 하면 다음과 같은 장점이 있는 것 같습니다. 직접 한 번 해 보고 후기를 다시 올리겠습니다.

-. 저자가 중요하게 생각하는 키워드를 확인할 수 있다.
-. 자연스럽게 반복학습이 이루어진다.
-. 책을 읽을 때 집중력이 떨어져서 대충 읽은 것을 다시 읽게 해 준다. 전반적인 내용의 이해력이 높아진 상태에 복습이 이루어지므로 이해도가 높아진다.

위 방법의 단점
-. 전/후 문맥(context)를 파악하지 못한 상태에서 부분에만 집중해서 다시 읽으면 내용 이해가 되지 않으므로 주의.
   이로 인해 해당 챕터를 다시 읽는 이점도 있지만 시간이 오래 소요됨.
 


저작자 표시 비영리 변경 금지
신고

김창준씨의 블로그에 스터디 하는 방법이 올라와 있네요. (http://agile.egloos.com/3684946)
다음에 팀 내에서 스터디 할 때 꼭 한 번 써먹어 봐야 겠습니다.
지난 번 리눅스 커널 스터디 때에도 막판에 흐지부지 됐거든요.

같은 팀에서 스터디할 때도 하는 일도 다르고 이해하는 정도도 각자 다르니 
주로 선임자의 강의 형식으로 흐르기도 하고.. 듣고만 있으면 이해도도 떨어지구요.

무엇보다 책을 먼저 읽고 들어와야 되는데 한명이라도 읽지 않은 사람이 있으면
이해시키는 데도 오래 걸리고 스터디 일정도 계획대로 되지 않더군요. 


저작자 표시 비영리 변경 금지
신고