프로젝트 확률론
이번 프로젝트는 제때에 끝낼 수 있을 것 같았는데#
통상 시간을 추정할 때, 대표값으로 최빈값을 선택하는 경향이 있다.
케이스
자신의 집에서 가장 가까운 지하철 역으로 가는데 시간이 얼마나 걸리는지 질문하였다.
- 20분이라고 했다. 그러나 걸리는 시간이 1시간 1일 1년일 확률이 모두 0이라고는 말할 수 없다. 가다가 교통사고를 당하는 경우도 있다. 0초 미만으로 걸리는 확률은 0 이다.
이런 확률이 사실상 20분이 걸릴 확률보다 확률분포 그래프의 면적이 더 크다.
소프트웨어 공학쪽의 연구에 따르면, 통상적으로 추정하는 소요시간에 적어도 2~3 배를 해야 80% 정도의 확률로 마칠 수 있는 시간이 나온다고 한다.
일의 소요 시간을 추정할 때 사람들이 낙관적으로 추정한다는 편향에 대한 연구 결과가 많다.
케이스
한명의 관리자와 7명의 개발자가 있다.
- 관리자는 프로젝트를 7개의 독립적인 일 덩어리로 잘라 개발자들에게 나누어줬습니다.
- 개발자들은 다른 개발자의 일에 관심을 둘 필요가 없다.
개발자들에게 일정안에 가능하냐고 질문을 했다.
- 모두 가능하다고 하였고
- 각기 90% 확률의 확신을 갖고 있다고 답했다.
관리자는 잘 진행이 되고 있다고 생각할 것이다. 그러나
- 확률을 계산하려면 0.9 를 7번 곱해야 한다. 50% 가 안된다.
추정은 과거의 일과 미래이 일이 판이하면 할수록 정확도가 떨어지는 경향이 있다.
케이스
- 분석, 설계와 테스팅, 디버깅은 질적으로 너무도 다른 작업이다. 작업 단계로 나눠 일을 하면 단절 지점이 필연적으로 생긴다.
수년간의 누적된 증거가 바로 다음날 어떤 일이 일어날지조차 보장해주지 못한다.
- 수년간 빠짐없이 매일 먹이를 주는 주인에 대한 칠면조의 신뢰는 점차 오르다가 추수감사절 바로 전날 최고가 될 겁니다. 이제까지 과거를 돌아보면 내일도 주인이 나에게 먹이를 주고 잘 해 줄거라고 확신이 들겠지요. 추수감사절 날에 경험의 단절이 생깁니다.
촉박한 개발 기간으로, 구현만 하게 되는데. 배포 이후 구현했던 것들의 문서정리나 테스트 코드의 작성이 하고싶지 않았던 것 같다. 그러다가 얼마의 기간이 지나, 한 번더 촉박한 개발 기간으로, 구현만 하는 사이클이 반복되었다. 도대체 이런 사이클은 언제 끝날 것인가
애자일 확률론#
대다수의 관리자들은,
- 병렬 진행이 최대화 될 수 있도록 각자에게 한 가지씩 일을 할당할 것이다.
- 사람들에게 함께 작업하지 말라고 지시를 할 것이다.
선호하는 접근법 → 관심사의 섞임
- 관리자가 12명 모두에게 단지 3가지 일만 주고 서로 협동해서 그 일을 하도록 요청하는 것이다.
- 그 일들이 완료되면 할 일을 3개 더 만들어 낸다.
개발자들은 작업을 완료하기 위해
- 자기 조직화할 수 있는 권한이 있고
- 매 번 다르게 조직화 할 수 있다.
관심사의 섞임
서로에 대해 엄청나게 많은 것을 매우 빨리 배울 수 있다.
3월 10일 부터 시작하는 프로젝트를 기존에 계획중인 방법은 부사수가 2주일 간 프로젝트에 늦게 참여하는 동안, 프로젝트 설계를 하려고 했었다. 그 후에, 부사수가 3주간 개발을 하는 것을 생각을 하였는데, 3주간 개발을 하면서, 내가 설계한 내용을 잘 이해하고 구현할 때 나의 리소스도 내가 설계한 만큼이나 들어 갈 수 있으며, 프로젝트 진행의 불확실성 때문에 걱정이 많았다. 일단 프로젝트에서 1순위는 최대한 빠르게 구현을 해줘야 하는 것이다. 그래서 다시 생각해서, 설계(다이어그램을 그리는작업, 기존 로직을 부사수에게 전달하기 위해 문서화 하는 과정)를 3시간 정도 투자하면서 느낀점이, 설계에 생각보다 많은 시간이 소요되는데, 진행해야 하는 프로젝트와 병행하여 또 하나의 프로젝트를 병행하기에는 무리가 있다고 생각했다. 그래서 이 프로젝트의 구현을, 부사수가 투입되기전에 빠르게 처리한 후, 이 프로젝트를 마무리하고, 나머지 테스트와 문서작업은 부사수에게 위임을 해보자라는 생각이 들었다. 부사수와, 개발 시기가 겹치지는 않지만, 같은 내용을 개발 및 공유 할 수 있고 경험의 단절도 조금 무마되지 않을까 생각이 든다.
기존 개발 방식은, 기획이 모두 끝나고 난 후에, 개발을 하고, 기획이 바뀌는 것을 제때 대응하는 방식이었다. 개발 기간은 항상 촉박했다. 기획이 시작됨과 동시에 병렬적으로 개발을 하여 촉박한 개발 기간에 구현만 하는 불상사를 줄여야 하는 요구가 필요할 것 같다.
고전적 방법은
- 내 일은 내일이고 다른 사람일은 다른사람 일이다.
- 내가 일을 빨리 끝내는 것이 이 프로젝트에 큰 도움이 되지 않는다.
- 마감 시간에 맞춰 끝나도록 일부러 일을 늘리는 경향도 생긴다. (교수가 숙제 기한을 일주일 늘려줬을 때 학생들이 숙제를 하는 데 걸리는 시간도 일주일 늘어나는 현상)
애자일은
- 각자 일을 얼마나 진행했는지 매일 공유한다
- 내일 네일의 구별이 뚜렷하지 않다 → 되도록 사람들이 섞이도록 한다.
내가 일이 빨리 끝났을 때 다른 사람의 일도 도와주는 것
- 가장 일이 밀려있는 사람이 누구인지가 확연히 보이기 때문에 프로젝트에서 병목이 되는 사람을 도와주기 쉽다.
- 먼저 일을 끝낸 사람이 나머지 사람들을 도와주게 되기 때문에 해당 시점에 나머지 사람들이 일을 제시간에 끝낼 확률이 높아진다.
- 개발자 중 누구 하나라도 먼저 일을 끝내면, 나머지 사람을 돕기 때문에 0.9 일 때보다 확률이 높아진다.
지식을 공유하기 때문에 좋은 정보는 모두가 곧 알게된다.
- 관련성이 있는 것들을 진행하기 때문에, 좋은 정보는 각자의 일에 모두 도움이 된다.
- 이런 새로운 지식, 깨달음은 프로젝트 속도를 높이는데에 큰 도움이 되는 경우가 많다.
- 애자일에서 '또는' 확률
- 7명 중 한명이라도 중요한 발견을 하면, 나머지 사람이 그걸 공유해 함께 이득을 얻는다.
- 고전적 방법에서 '그리고' 확률
- 모든 사람이 제각기 깨달음을 얻어야만 전체 프로젝트의 체감 성공률이 높아진다.
- 애자일에서 '또는' 확률
일 진행단계(분석, 설계, 구현, 테스트, 전개 같은)를 두지 않으려고 한다.
- 단계가 있으면 시기에 따라 하는 일에 큰 차이가 생긴다.
- 애자일은, 부분 속에 전체가 들어가게 한다.
- 서너 번의 반복주기만 지나면 종료 가능날짜가 더 정확히 예측 된다.
애자일은 좋은 일에 대해서는 '그리고' 확률을 '또는' 확률로 바꾸고
나쁜 일에 대해서는 '또는' 확률을 '그리고' 확률로 바꾸는 경향이 있다.
- 좋은 일을 공유해서 한 사람만이라도 중요한 통찰이 있다면 공유해서 '또는' 확률로 바꾸고
- 버그 같이 나쁜 일에 대해서는 여러 사람이 중복 검토를 해서(짝 프로그래밍, 코드 공유, 퀵 디자인 세션, 코드리뷰 등) 모두가 실수해야지만 구멍이 나게 '그리고' 확률로 바꾼다.