[책] 칸반과 스크럼 - 헨릭 크니버그/마티아스 스카린

도서출판: 인사이트

얇은 책(140쪽에 여백도 많고)이고 금방 읽을 수 있을 것이라 생각했는데 5일 걸렸다.

스크럼이라는 개념에 대한 지식이 있다면 칸반에 대해서 개념을 잡는데 도움이 될 것이다.

둘 다 모른다고 하더라도 두 마리의 토끼를 잡을 수 있겠지만 이게 뭐지 할 수도 있다.

뭔가 애자일에 대한 경험이 있으면 이해하기 쉬울 수 있다.

[읽기 기록]

1. 7/16 ~ p.54

2. 7/24 ~p.76

3. 7/27 ~p.94

4. 7/28 ~p.120

5. 7/29 ~p.140 (完)

[책 안에서]

p.9

 명심하십시오. 칸반이 팀의 문제를 해결해 주지는 않습니다. 가장 중요한 것은 팀의 협력과 커뮤니케이션입니다. 계속 실험하며 적응해 나가십시오.

- 역자 심우곤, 인범진

p.35

 스스로를 한 가지 도구에 제한하지 말라!

 이도류: 미야모토 무사시 - 한 가지 무기나 특정 유파에 집착하지 마라.

p.75

 조직들은 대부분 빨리 마치기(=리드 타임 단축)를 원한다. 유감스럽게도 많은 조직이 이를 더 많은 사람을 투입하거나 초과 업무를 시키라는 의미로 받아들이는 함정에 빠진다. 대게 작업을 더 신속하게 끝내기 위한 가장 효과적인 방법은, 더 많은 사람을 투입하거나 일을 더 고되게 하는 것이 아니라 작업 흐름에 방해되지 않게 하고 수용 능력(capacity)에 맞게 일을 제한하는 것이다.

p.94

 "상대방이 반드시 바뀌어야 한다" 이것이 양 팀(기술 운영팀 및 개발 팀) 모두의 공통된 주에였다.

p.137

 칸반이건 스크럼이건 그 자체가 목적이 아니다. 우리의 목적은 지속적인 배움이다. 소프트웨어 분야가 멋진 이유 한 가지는 배움에서 핵심인 피드백 주기가 짧다는 점이다. 따라서 피드백 주기를 활용하라! 모든 것에 의문을 품고, 실험해 보고, 실패하고 ,배우고 다시 실험하라. 처음부터 잘해야 한다고 걱정하지 말라.

p.138

 유일하게 실패라고 부를 수 있을 때는 실패로부터 아무것도 배우지 못했을 때다.

 하지만 역시 그 경우에도 뭔가를 배울 수 있다.