같은 공간에서 일하기
같은 공간에서 일하는 팀은 일을 더 잘 하게 되어있다. 질문이 나오면 빨리 답을 얻을 수 있고, 문제가 생기면 그 자리에서 해결할 수 있다. 팀원끼리 교류할 때 생기는 문제도 훨씬 적고, 서로 간에 믿음도 훨씬 빨리 생긴다.
...
분산된 공간에서 일하는 팀이 같은 공간에서 일하는 팀과의 차이를 메우기 위해서 할 수 있는 일
프로젝트 초반에 모든 팀원을 한자리에 모일 수 있는 경미를 마련하는 일이다. 비록 며칠이더라도, 서로를 알아가면서 농담하며 식사를 함께 하는 동안, 각기 개성 있는 팀원들이 효율적인 하나의 팀으로서 더욱 단단한 결속력을 갖출 수 있게 말이다.
그 후로는 비록 각지에 흩어져 있더라도, 여러가지 의사소통 도구들을 이용해 팀원들 간에 소통을 지속한다면, 마치 한곳에서 서로 함께 일하는 것과 같은 기분을 느끼게 될 것이다. 15p
애자일 팀을 구성할 때 알아야 할 팁
제너럴 리스트를 찾아라
애매모호한 상황을 개의치 않는 사람을 찾아라
제멋대로 행동하는 사람이 아닌,팀 플레이어를 찾아라 30p
인셉선
어떤활동이나 단체를 시작, 설립하는 단계라는 사전적 의미를 갖고 있다. 쏘트웍스에서는 인셉션을 프로젝트 초기단계에 고객과 개발팀이 서롤르 알아가는 과정을 갖는 일정한 기간(주로 1~2주)을 일컫는다. 34p
대부분의 프로젝트가 실패하는 이유
이루어진 적 없는 합의가 이루어졌다고 믿는 성급한 가정이 대부분의 프로젝트가 실패하는 이유.
-> 현명한 선택을 하기 위해 목표, 비전, 프로젝트의 현재 상태에 대하 다른 팀원들과 소통하기
-> 이해관계자가 적절한 결정을 내릴 수 있도록 프로젝트에 관해 그가 알아야 할만한 정보 제공하기. 35p
인게이지먼트(engagement)는 고객과의 좋은 관계를 유지하고 서로를 더 잘 알아가기 위해 하는 활동을 일컫는데, 이는 프로젝트가 시작하기 전/후를 포함하여 프로젝트가 진행 중일 때도 지속적으로 일어난다. 현재 그 고객과 프로젝트를 하고 있지 않더라도 인게이지먼트는 언제든 진행될 수 있는 일이다. 36p
인게이지먼트나 프로젝트 초기에 질문을 하면그게 무엇이든 별로 잃을 게 없다. 인게이지먼트나 세일즈 초반에 어려운 질문(껄끄러운 질문)을 하라.
- 팀의 프로젝트 경험이 얼마나 되니까?
- 이런 작업을 해본 적이 있습니까?
- 예산은 얼마나 배당되어 있나요?
- 프로젝트는 누가 지휘합니까?
- 애널리스트 둘에 개발자가 서른 명 있다는 데 문제가 없을까요?
- 객체 지향언어를 사용해 본 경험이 없는 주니어 개발자들로 이루어진 팀으로 애자일 방법론을 사용해서 레거시 메인 프레임 시스템을 루비온레일스로 재구축해 본적이 있습니까? 36p
인셉션 덱
- 우리가 왜 여기에 모였을까?
- 엘리베이터 피치
- 제품의 광고를 직접 디자인해 보기
- NOT 리스트
- 프로젝트와 관련된 다양한 사람들과 알고 지내기
- 해결책 보여주기
- 야근거리
- 규모 정하기
- 우선순위 정하기
- 미리 알아야 할 비용 37p
>> 재밌게도 어제 읽은 '48분 기적의 독서법'과 이 책은 분야가 전혀 다른 책임에도 불구하고 사람에 있어서는 제너럴리스트를 지향한다.
한 팀 내에 우리가 어디로 가야 하는지,우선순위는 무엇인지,다음에 해야할 일이 무엇인지에 대해 다른 생각을 가진 여러 명의 이해당사자가 존재해서는 안된다.
그래서 여러분은 그 이해당사자들의 대표가 누구인지 분명히 알아야 한다. 이 말은 대표 외의 사람들은 아무런 의견도 내지 말아야 한다는 뜻이 아니라, 다양한 의견을 수렴해 최종적으로 선택을 하는 사람이 누구인지 알아야 한다는 것이다. 76p
단위 테스트는 피드백을 즉각적으로 준다.
단위 테스트는 회귀테스트 비용을 극적으로 낮춰준다.
단위 테스트는 디버깅 시간을 획기적으로 줄여준다.
단위 테스트는 우리가 자신 있게 배치할 수 있게 도와준다. 192p
기술적 부채란 임기응변, 난도질, 복사해 붙이기 같이 우리가 생산성과 일정이라는 미명 아래에 코드 베이스에 저질러 놓은 죄악들이 오랫동안 누적된 결과다. 200p
단위 테스트와 리팩터링, 이 둘은 소프트웨어의 설계가 빈약해 생기는 고민을 깨끗하게 해결하는 무기다. 209p
애자일 선언
프로세스와 도구보다 개인과 상호작용을
포괄적인 무너보다 제대로 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획에 따르기보다 변화에 대한 대응을 236p
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
애자일의 12가지 원칙
1. 우리가 가장 우선시하는 것은 신속하고 지속적으로 가치 있는 소프트웨어를 고객에게 전달함으로써 고객 만족을 이루는 일이다.
2, 뒤늦게 요구사항이 바뀌더라도 즐겁게 받아들여라. 애자일 프로세스는 고객이 경쟁에서 우위에 서도록 변화를 활용한다.
3,. 작동하는 소프트웨어를 몇 주 혹은 몇 달마다 고객에게 전달하라.주기는 짧을 수록 좋다.
4. 프로젝트 기간동안 업무 전문가들과 개발자들은 매일 함께 일해야 한다.
5. 의욕이 가득한 사람으로 팀을 구성하라. 그들에게 필요한 환경과 지원을 아낌없이 하고 난 후에는 이들이 맡은 바 일을 완성할 것이라고 믿어라.
6. 개발 팀 내의 누구에게든 가장 정확하고 효과적으로 정보를 전달하는 방법은 그 사람과 직접 대면하면서 이야기하는 것이다.
7. 작동하는 소프트웨어는 프로젝트의 진척을 알 수 있는 주된 척도다
8. 애자일 프로세스는 지속가능한 개발을 장려한다. 후원자나 개발자, 사용자들은 언제까지고 일정한 보폭을 유지할 수 있어야 한다.
9. 탁월한 기술력과 훌륭한 설계에 끊임없이 주목하는 것이 기민함을 향상시킨다.
10. 단순함, 하지 않아도 되는 일은 최대한 안 하게 하는 기교, 이것이 핵심이다.
11. 최고의 아키텍처나 요구사항, 디자인은 자기조직화된 팀에서 나온다.
12. 팀은 정기적으로 더욱 효과적으로 일할 수 있는 방법을 숙고하고, 그에 따라 행동을 조율하고 조정한다. 236p
1. 2013. 3. 7 12:50 AM
'머리가 뛰다 > 독서 다이어리' 카테고리의 다른 글
| 논어 - 공자 지음, 고전연구회 옮김(더클래식) (0) | 2013.03.03 |
|---|---|
| 죄와 벌 - 도스토예프스키, 유성인 옮김(하서 출판사) (0) | 2013.03.03 |
| 하루를 완성하는 시간 아침 30분 - 다카시마 데쓰지 (0) | 2013.02.22 |
| 내일이 바뀌는 새로운 습관 잠자기 전 30분 - 다카시마 데스지, 홍성민 역(티즈맵) (0) | 2013.02.20 |
| 48분 기적의 독서법 - 김병완 (0) | 2013.02.18 |