1

이 책을 읽으면서 꿈같은 소리가 나열되어 있어서 깜짝 놀랐다. 스크럼 같은걸 말하는 회사가 있다면 이젠 의심부터 하게 된다.

2

스크럼 관련 책이 많고 많지만 당장 내일부터 ‘스크럼’ 같은 걸 ‘해야’ 한다면 이 책을 추천.

---

왜 소프트웨어는 ‘목표’를 정하지 않고 시작하는 걸까?

즉, 본질적 어려움은 소프트웨어가 달성해야 하는 목표, 그 자체에 관한 것 입니다. 반면에 부수적 어려움이란 본질적으로 어려운 소프트웨어의 개발 과정에 수반되는 방법상의 어려움을 말합니다.

이 두 개의 기둥을 ‘반반무마니’ 할 경우 대재앙을 불러옴

리더십이 어떠한 성격인지 지금까지 여러 가지 논의가 있었습니다. […] 그 두 개의 기둥은 과제 달성 지향과 인간관계 지향이라는 기둥 입니다.

대부분의 회사에서 ‘스크럼 마스터’를 ‘PM’에게 겹임시킨 결과 ‘반반무마니’의 결과가 도출되게 됨. 그렇게 망함.

스크럼 팀에는 다음과 같은 세 가지 역할이 있습니다. 1) 제품 책임자 - 스크럼 팀이 만들고자 하는 제품의 최종 책임자, 2) 개발팀 - 제품 책임자가 결정한 요구 사항과 순서에 따라 최종 제품까지 구현하는 전문가, 3) 스크럼 마스터 - 제품 책임자와 개발팀이 실행하는 스크럼을 지원하고 스크럼이 조직에 도입되도록 지원하는 스크럼 추진자

이렇게 글로 적혀 있는건, 과도한 개입을 매번 발생하기 때문이다.

[…] 스크럼이 제대로 기능을 발휘하려면 가능한 한 이해관계자의 과도한 개입은 없어야 합니다.

그래서 요즘은 ‘마이크로서비스 아키텍처’에 대해서 알아보고 있다.

개발팀은 다기능 팀이어야 합니다. 다기능 팀이란 ‘외부에 의존하지 않고 작업을 진행할 수 있는 능력을 갖춘 팀’을 말합니다. 프로그래밍이나 디자인과 같은 제품의 완성에 필요한 능력을 모두 개발팀 내부에 보유한 것을 말합니다.

정말 이렇게 운용되는 조직이 있을까?

[…] 만약 1주일이 지나고 예정했던 일을 다 끝내지 못했더라도 스프린트 기간은 연장하지 않습니다. 일을 완료한 시간을 주기적으로 계산하면 스크럼 팀이 스프린트 기간 안에 완료할 수 있는 작업량을 추정할 수 있게 됩니다.

유니콘이나 꿈같은 이야기다.

[…] 개발 환경을 마려한 할 때 다음과 같은 준비 과정을 생각할 수 있습니다. 1) GitHub나 Bitbucket을 사용한 Pull Request 개발을 할 수 있는 환경, 2) 단위 테스트부터 엔드 투 엔드 테스트까지 자동 테스트 환경, 3) Jenkins나 Travis CI등을 사용하여 빌드나 자동 테스트 시 에러가 있으면 바로 통보해 주는 지속적인 통합 환경

그러나 시연을 하게 되면 사람들은 엄청난 짓을 하기 시작한다. 예를 들어 비난, 힐난, 질책 같은?

동작이 되는 소프트웨어로 데모 실행하기 […] 익숙하지 않을 때에는 사전에 시연 리허설을 하는 것이 좋습니다. […] 실제로 동작이 되는 소프트웨어를 데모로 보거나 조작을 해 본다면 중요한 학습 피드백을 얻을 수 있을 것 입니다.

주석 만들 시간도 안 주는 현실에서 회고라니… 이런 팀 존재하나?

스프린트 회고도 타임박스를 설정합니다. 스프린트 기간이 1개월이라면 3시간, 1주일이라면 30분에서 1시간 정도가 기준입니다.

그냥 웃을 수 밖에…

스크럼 산출물이란 […] 1) 제품 백로그, 2) 스프린트 백로그, 3) 인크리먼트

조직보다 상급자가 우선인 집단에서 이렇게 처신하면 바보취급 당하기 딱 좋다. 그러니 조심하자.

[…] “점심때에 우연히 만난 상사에게 개별적인 부탁을 받았다.” 등 개인적인 업무가 늘었다는 이유가 자주 있었습니다. 끼어들기 업무는 개인이 받았지만, 그 작업으로 발생하는 영향은 팀원 전원이 받습니다. 스프린트 계획까지 기다려 줄 수 있도록 조정할 여유가 있다면 다행이지만 그렇지 않은 상황도 많을 것입니다.

책임지지 않으려는 수 없이 많은 PM과 PM에게 책임을 전과하는 은하계의 별같은 책임자들

[…] 이와 같은 문제가 드러난 경우라도 제품 책임자가 개발팀의 우선순위 결정에 책임을 지도록 합니다. 우선순위 결정을 판단할 정보를 모으거나 이해관계자와 협상하는 것도 제품 책임자의 중요한 역할 입니다.