1

4부 예제만 열심히 읽어도 50%는 성공할 수 있다. 왜냐하면 나 같이 스크럼에 적합하지 않은 사람도 오늘 스크럼 보드를 대충은 만들었기 때문이라 말하고 싶다. 일단 만들지 않았는가?

2

회사에서 어마하게 배우고 있다. 파이썬은 둘째치고, 문서화 작업은 어느 정도 조금씩 조금씩 걸어나가는 정도로 배워나가고 있다. 아직 더 배우고 해봐야 할 것들이 많지만 이번달은 나름 의미있는 6월이 될 듯 싶다. (비동기 서버를 파이썬으로 만든다니 신난다!!)

---

그런데 우리는 그렇지 않쟈나?

다들 쉬쉬하고 당연하게 받아들이면 덮어두기 때문이다. 하지만 일단 문제점이 부상하면 개선은 훨씬 쉬워진다.

목적과 비용, 뭔가 빠진 것 같아서 조금 아쉽지만 그래도…

사용자 스토리는 단 두가지 정보를 작성하는 것으로 프로세스를 시작한다. 두 가지 정보는, 시스템을 통해 이루고자 하는 목적과 그것을 달성하기 위한 개략적인 비용이다.

그렇다! ‘요구사항’은 의사소통의 문제다. 갑과 을의…

소프트웨어 요구사항은 의사소통의 문제다. […] 우리에게 필요한 것은 일하는 방법이다. 그리하여 어느 한쪽이 우위를 점하지 않으면, 감정적으로 흐르거나 혹은 정치적일 수 있는 자원 할당 문제를 공동의 문제로 공유한는 것이다.

‘사용자 스토리’ 생각보다 재미있다. 시스템을 전혀 다른 관점에서 볼 수 있다!

사용자 스토리는 소프트웨어의 사용자나 구매자에게 가치를 줄 수 있는 기능을 서술한 것이다. 1) 스토리는 서술 형태로 기록되며, 계획하거나 기억하기 위한 단서로 사용된다. 2) 스토리는 대활르 통해 세부사항을 구체화한다. 3) 스토리는 테스트를 통해 세부사항을 문서화하고 전달하며, 스토리의 완료 여부를 판단한다.

고객 중심, 개발에 불편하지 않을까? 생각했지만 그것은 기우!

스토리는 고객이 가치를 평가할 수 있도록 작성되어야 한다.

2주일에 구현과 테스트! 테스트에 무게 중심을 둔다면 2주일이 모자라지 않을까? 아니면 스토리를 분량을 어떻게 조절해야 할까?

스토리는 한두 명의 개발자가 반나절에서 길어야 2주일 안에 구현하고 테스트할 수 있는 정도의 크기가 적당하다.

빠른 개발을 위한 반복!

이터레이션 계획은 이번 이터레이션에 포함할 스토리를 선택하는 일을 말한다.

개인이 아닌 조직, 팀을 생각하는 문화

우선순위를 매길 때는 조직에 최대의 가치를 가져오도록 신경써야 한다. […] 스토리 개발 비용은 개발자들이 스토리에 부여하는 추정치다.

‘추정가능’ 항목에서 항상 고민하게 된다.

‘좋은 스토리의 여섯 가지 특성’ 1) 독립적 : 의존성 배제 2) 협상 가능 : 대화를 위한 한두 문장 3) 사용지 및 고객에게 가치있음 : 기술적 가정은 배제 4) 추정 가능 : 단위를 변경하거나, 다른 개발자의 도움을 받아서라도 추정할 것 5) 작다 6) 테스트 가능

스토리를 통해 고객과 좀 더 많은 의사소통을 진행하라는 의미

스토리는 고객과 의견을 주고받기 위한 약속이지 명세가 아님

역할을 통해서 사용자 관점에 중점을 두라는 의미

스토리 작성에 앞서 사용자 역할 및 등장인물을 식별하는 것

사용자 중심으로 바라볼 것

시스템을 사용하는 사람에 초점을 맞출 것

알지 못한다는 표현보다, 자신의 욕망을 표현하는 것에 서툰것 아닐까? 아니면 무의식적인 ‘기능’ 이런거?

사용자들이 이미 모든 요구사항을 알고 있어서 우리가 그것들을 끌어내기만 하면 되는 것도 아니다. […] 사용자에게 “그래서 당신에게 필요한 것이 무엇인가요?” 하고 질문하는 것으로는 충분하지 않다. 대부분의 사용자는 정말 필요한 것이 무언지 제대로 알지 못하며, 특히 그것을 표현하는 것에 익숙하지 않다. 나는 이 사실을 어느 사용자에게 배웠다. 그 사용자는 내 사무실에 들어와서 이렇게 말했다. “당신은 제가 요청했던 것을 정확히 만들었어요. 하지만 그건 제가 원하는 게 아니군요.”

역시, 개드립을 소중하다.

문맥 무관 질문으로 시작함으로써 사용자로부터 넓은 범위의 답변을 얻게 될 가능성을 열어 둘 수 있다.

인터페이스는 언제 포함해야 해야 할까?

목적 스토리로 시작하라, 케이크 자르듯 나누어라, 닫힌 스토리. 제약사항 기록, 스토리는 시간에 맞춰어라, 인터페이스 배제 - 사용자 인터페이스에 관한 세부사항이 언젠가는 스토리에 포함될 수 밖에 없다. 하지만 이렇게 되는 것은 소프트웨어가 좀 더 구체적인 모양을 갖추고 스토리가 더 이상 새로운 기능을 나타내는 것이 아니라 기존 기능을 수정하거나 확장하는 것을 의미하게 될 때다.

자원의 한계와 효율을 고려하자.

어떤 프로젝트도 “언제 끝납니까?”라는 물음 없이는 진행될 수 없다.

One for All, All for One

스토리 추정은 팀에서 공동으로 행해야 한다. […] 고객은 자신이 수긍할 수 없는 경우라도 개인적인 추정치를 제시하거나 사견을 주장하는 것이 허락되지 않는다. […] 추정에도 반복적 방법을 이용한다.

추정이라는게 스크럼과 칸반같은 애자일 기법을 도입하는데 가장 난감한 분야라 생각한다. 쉽지 않은게 아니라 해 본적 없다가 정확한 듯

프로그래머는 스토리를 완료하기 위해 필요한 모든 것들을 추정에 포함시켜야 한다. […] 스토리가 크면 정확성이 떨어진다.

넓은 마음을 가지고 백로그를 진행해 보자.

릴리즈 주기가 아무리 짧더라도 계획없이 진행하기보다는 새 릴리즈에 포함될 기능들을 모으는 것부터 시작하는 것이 도움이 된다.

스토리는 명세가 아니다. 그래서 좀 더 유연하게 대처할 수 있다.

스토리를 구성하는 작업 중에서 추정하기 어려운 작업(예를 들어서 부사장의 승인을 얻어야 하는 지원 데이터 형식의 목록이 있는데, 그가 멀리 떨어져 있고 답변이 늦어질 떄) 해당 작업을 스토리의 다른 부분들과 따로 분리한다.

옳다.

요구사항 명세서가 소프트웨어 개발 그룹과 다른 그룹 사이를 왔다갔다 한다면, 그것은 프로젝트가 잘못된 방향으로 진행되고 있다는 징조다.

비용은 언제나 중요하다.

켄트 벡(Kent Beck)은 이를 결혼 준비와 비교하여 설명한다. 결혼을 준비하면서 희망하는 결혼 선물 목록을 만들 때는 각 항목의 비용이 얼마나 되는지 알지 못한다. 단지 원하는 선물의 목록을 적을 따름이다. 이러한 방법이 결혼에서는 통할지 몰라도 소프트웨어 개발하는 데는 적용되지 않는다. 고객이 어떤 항목을 프로젝트에 추가하고자 할 때는 그 비용을 생각하지 않을 수 없다.

빠른 실패가 성공의 필수조건

시스템의 모든 요구사항을 작성한 후 탑-다운 방식으로 솔루션을 생각해 내는 것이 가능하다고 믿는 경향이 있다. 약 20년 전 파나스와 클레멘츠(Parnas and Clements 1986)은 이러한 형태로 진행되는 프로젝트를 절대 볼 수 없을 것이라고 말했다. 그들은 다음과 같은 이유를 제시하였다. 1) 일반적으로 사용자와 고객은 자신이 원하는 것을 정확히 알지 못한다. 2) 소프트웨어 개발자가 모든 요구사항을 파악했더라도, 그 소프트웨어를 개발하기 위해 필요한 많은 세부사항은 시스템을 개발하면서 비로소 명확해진다. […] 5) 사람은 실수를 한다.

기승전 ‘테스트’

사용자 스토리와 유스케이스는 그 완결성에서도 차이가 있다. 제임스 그레닝(James Grenning)은 “스토리 카드에 인수 테스트를 더하면 기본적으로 유스케이스와 동일하다”고 언급한 바 있다.

사용자 우선!

산출물의 특징을 고려하기 보다는 사용자의 목적을 고려해 보는 것이 더 중요하다.

금도금을 주의하자!

스토리 냄새 카탈로그 1) 너무 작은 스토리, 2) 상호 의존적인 스토리 : 쪼개라!, 3) 금도금 : 필요이상의 작업을 한다, 4) 너무 상세한 스토리 : 문서화가 목적이 아님을 상기시키자! 스토리 카드 크기를 작게 만들자!, 5) 사용자 인터페이스와 관련된 세부사항을 너무 일찍 포함시키기 : 6) 너무 앞서 생각하기 7) 스토리를 너무 많이 나누기 8) 고객이 우선순위 부여를 어려워 함

팀 스포츠에 가장 어려운 부분 아닐까?

스크럼팀은 “모두 함꼐 한다”는 자세를 공유한다.