프로젝트를 어떻게 관리할까?(레고 스크럼을 갔다와서)

Table of Content

가서 뭘 했지?

생략:)

느낀점

더 못생기게

고객의 요구사항과 변경사항을 모두 충족했지만, 피쳐 하나하나(소방서, 병원 등) 완성도의 퀄리티는 다른팀들에 비해 매우 떨어졌다. 하지만 더 잘만들었어야 했다는 생각보다는 더 못만들고 스프린트나 이터레이션 주기를 더 짧게 가져 가는게 맞다는 생각이 들었다. 퀄리티는 매우 떨어졌지만 확인할 수 있는 수준이였고, 고객에게 더 빠르게 보여주는 방향이 맞다는 생각이 들었다.

또 구현에 집중하다 보니 어떻게든 병원을 만들려고 했던 것은 좋았지만, 끝나고 보니 요구사항에 크기가 없었음에도 아마 병원은 이렇게 생겨야지 라고 생각해서 지나치게 크게 만들었던 것이 큰 깨달음으로 다가왔다.(YANGI나 KISS가 계속해서 떠올랐다.) 그냥 하얀색 레고 블럭 하나를 놓고 병원이라고 해도 되는 것이다. 다만 이런게 가능하려면 위에서도 얘기했듯, 이터레이션의 주기가 빨라야 하는데 이러면 칸반이 더 낫지 않을까 싶다. 생각을 계속 이어가자면, 이런 특성을 모두 이해하고 적재 적소에 도구를 사용하는 것이 아주 큰 능력인 것 같다.

또 회사 동료와 이야기를 나누어본 결과 만약 실제 소프트웨어 개발이라면 최소 구현을 해놓고 디자인적으로 조금더 유연하게 만들었으면 어땠을까라는 생각이 들었다.(물론 레고라서 쉽지는 않겠지만),

요구사항에 병원을 만들려고해서 직사각형 레고를 크게 쌓았다. 사실 요구사항에는 크기가 없었기 때문에

그러나 더 자주, 더 빨리

결국 팀 동료에게도 나누었던 말이지만, 프로젝트를 수행하기 위한 다양한 애자일 도구들이 있지만, 이 도구들의 특성을 잘 분간하고, 시기와 상황, 팀원들에 맞게 써주는 것이 PL, PM, PO, SM 들 중 하나의 역할이라는 생각이 들었다.

경험(피드백)을 통해

경험을 통해 배운다는 내가 소프트웨어의 길로 들어서기 전부터 추종했던 것이다. 모든 것은 경험하기 전에는 믿거나, 받아들일 수 없다. 다만 우리는 모든 것을 다 경험할 수 없으므로 축적된 경험을 바탕으로 추론할 수 있을 것이다.

TDD, 스크럼, 린스타트업은 모두 닮아 있다.

피드백을 적시에 그리고 빈번하게 받는 것.

소스 코드로 구현한 제품으로 사용자의 반응을 보는 것은 너무 늦다.

플래닝 포커

세미나가 끝나고 와이프와 저녁을 먹으면서 두런두런 얘기를 하다가 플래닝 포커를 해보게 되었다. 문제는 세미나와 똑같은 문제를 가지고 하였는데 '요쿠르트 병에 맥주를 담으면 얼마에 팔아야 할까?'이다.(200원에 1점). 이런저런 토론을 마치고나서, 와이프가 이 도구가 참 별것 아니면서도 강력하다라는 생각을 나누어 주었다. 사실 평소에도 이런저런 얘기를 하면서 의사결정을 하는 편이라 서로 의사결정이 잘 된다고 생각했는데, 이 도구를 통해서는 더 상대방이 해당 안건에 대해서 얼마만큼의 가치를 느끼는지 또 왜 그렇게 느끼는지 정량적으로 공감할 수 있다는 것이다.

사람은 막연한 것에 대해서는 자의적으로 해석하는 경향이 강한 것 같다. 예를 들자면 상대방이 의견을 적극적으로 어필하지 않으면 아마 상대방이 생각하는 해당 안건에 대한 점수가 낮을 것이다고 생각해서 의견을 펼치게 되고, 조금씩 알아가는 과정에서 시간도 걸리고, 감정도 상할 수 있게 되는 것 같다.

여기서 조금 의문점은 저 점수를 여기서는 돈으로 했지만 시간으로 바꿀 수 있는 건가?

그래서?

생각을 여기에 계속 정리하고 있다. 사실 현재 다니고 있는 회사가 애자일 문화가 있는 회사가 아니기 때문에, 스스로 학습해서 이렇게 저렇게 해보려고 하는 수 밖에 없는 것 같다. 다만 애자일에 속한 용어들이 추상적이고, 각각 배경과 원리가 다르기 때문에 여기에 조금씩 정리해가면서 어느 정도 애자일 진영의 지도가 그려지면 그때 하나씩 실행해보면 좋을 것 같다.

미완성

참고하면 좋은 글