어딘가 보고 정리한 글인데 출처를 기억하지 못하겠다….

SW 품질 개선 노력의 대상

• SW 품질을 높이는데 Tool, System, People 그리고 Management중에 어떤 면을 개선하는 경우 효과가 높을까?

  • Tool : 2 배
  • System : 10배
  • People : 30배
  • Management : 60배 이상

• 그렇지만 대개의 관리자는 개선효과를 반대로 알고 있다.

• 사람은 변화해야 할 때 변화한다(더 이상 저항하지 못할 때) 그러나 위기는 갑자기 오지 않는다. 다만 위기에 대한 인지를 갑자기 할 뿐이다.

• 변화는 성능 저하를 유발한다. 그 성능 저하를 감수하고, 계속 변화해가야 변화가 주는 효과를 얻을 수 있다.

고객 가치 중심

• Agile은 가치가 높은 것을 가장 먼저 개발하여 SW의 가치를 초기부터 높이려고 노력한다.
• Action과 Result사이에 시간차가 크면 학습효과가 낮다. SW에서는 설계 내용이 Coding을 거쳐 Test하는 시점이 설계 시점과 멀면 멀 수록 학습효과가 낮아진다(잘못된 설계를 다른 기능 설계시에도 반영할 가능성이 높아진다) Agile에서는 설계/구현/Test의 간극을 줄여 학습효과를 높인다. 이를 위해 기능을 User story로 나누고, 1개 혹은 몇 개의 user story를 기준으로 빌드하여 User story를 추가해 나간다. 이때 user story는 사용자 입장에서의 사용 패턴이다.
• 하나의 Story는 여러개의 task로 나뉘어진다. Story가 사용자 측면의 기능이라면 task는 개발자 입장에서의 업무이다.
• 예) “xx 카드 승인 기능"이 story라면 해당 story를 구현하기 위해 필요한 기능들 “DB 설계”, “UI 구현"등등이 task다.

Collaboration

• 한 사람이 1시간 동안 핵심적인 버그를 발견할 확률이 0.1이라고 하면, 총 7명이 있을 때
  • 모든 사람이 버그를 발견할 확률은? 0.1^7 = 0.0000001
  • 한 사람이라도 버그를 발견할 확률은? 1 - 0.9^7 = 0.53

예측

• Task는 세분화할 수록 소요시간 예측력이 높아진다.
• 상벌은 개개인별이 아니라 팀단위로 이루어져야 효과가 높다. 동시에 팀웍 강화 노력도 필요.
• 개발자들은 절대시간으로 표현해야 하는 절대 시간 추정 능력은 떨어지지만, Story끼리의 상대적인 시간 소요를 비교할 때 필요한 상대 시간 추정 능력은 뛰어나다.