[코딩전에 보자] 개발팀이 갖춰야할 역량

* 해당 내용은 김익환, 전규현 님이 지은 '소프트웨어 개발의 모든 것'에 나와있는 내용을 기준으로 작성하였습니다.

 

좋은 소프트웨어란 뭘까?

많은 조건들이 있겠지만 몇가지 뽑아보자

 

1) 유지보수가 용이해야한다.

2) 설계가 간결하고 명료해서 설계대로 만들어졌다.

3) 다른 팀원의 합류에 무리가 없다.

4) 표준이 있어서 관리가 용이하다. 

5) 확장성과 유연성을 가지고 있다.

6) 버그 혹은 변경사항을 기록하고 공유 가능해야한다.

등등 지금 바로 떠올려도 많은 것들이 떠오른다. 

 

책 '소프트웨어 개발의 모든 것'에서는

소프트웨어 프로젝트 팀이 갖춰야할 역량에 대해 다음과 같은 20가지를 말한다.

 

• 전사적으로 소스코드 관리 시스템을 딱 하나만 사용해야 한다.(SVN, GIT 등등)
• 모든 소스코드 및 개발문서는 소스코드 관리시스템에 저장되어야 한다.(공유가능하고 산재되어있지 않다.)
• 각 개발 마일스톤마다 베이스라인을 설정해야 한다.
• 모든 직원이 이슈관리시스템을 사용하여 버그/이슈 관리해야 한다.(JIRA 등등)
• 프로젝트의 스펙문서를 가지고 있어야 한다.
• 스펙문서를 모든 관련자가 충분히 리뷰해야 한다.(대표, 마케터, 테스터, 설계자, 개발자 등등)
• 스펙이 바뀌면 스펙문서를 업데이트해야 한다.
• 스펙 변경이 통제 관리되고 있어야 한다.(스펙을 변경하는 절차와 관리자가 있어야한다.)
• 적어도 하나의 작업 단위의 상세한 일정을 가지고 있어야 한다.
• 일정을 개발자가 산정해야한다.(통보식으로 개발자의 의견이 무시되면 안된다.)
• 일정을 지속적으로 업데이트해야 한다.(진척도와 수정이 필요하면 수정)
• 별도의 테스터나 테스트 팀이 있어야 한다.( 개발자가 구현과 테스트 모두하지 않고 별도의 테스터가 있어야 한다.)
• 테스트 케이스를 가지고 있어야 한다.(주먹구구식으로 버그를 찾지말고 테스트 케이스가 있어야한다.)
• 프로젝트 리스크 관리를 해야 한다.(리스크 관리 대장이 있어야한다.)
• 리스크에 대한 백업 플랜이 있어야 한다(리스크 관리 계획이 주기적으로 수정되어야 한다.)

책에서는 최소 15개 이상은 부합해야하고 20가지를 충족시키도록 노력해야한다고 말한다.

 

또한 현재 문제가 되는 관행들은 아래와 같다고 한다.

• 프로젝트 초기에 문서를 대충만들고 일단 코딩부터 한다.
• 개발일정을 상급관리자가 결정하고 개발팀에게 무리하게 하달, 이로인해 충분한 요구분석/설계 생략, 추후 문제가 커짐
• 무리하게 일정을 잡았기 때문에 일정이 늦춰지면 프로젝트 후반에 급하게 인력 투입, 하지만 효과가 없다.
• 고객 혹은 모델별로 소스코드를 다르게 사용해서 개발, 모든 고객의 요구를 중간중간 들어주다보니, 결국 소스코드가 갈라지게 되고 여러개를 관리해야하니 유지보수가 힘듦
• 갑작스레 외부의 개발방법론을 도입해 러닝커브가 발생함 그러면서 개발도 해야하니 문서는 프로젝트 다끝나고 작성
• 개발 과정에서 제품의 기능이 변경된 것이 문서에 충분히 반영이 안됨, 쓸모없는 문서가 된다.
• 프로젝트 일정이 너무 짧아서 개발 정보가 개발자들 머리 속에만 있다.
• 소수의 개발자가 거의 모든 개발을 맡음, 개발에 대한 지식이 다른 개발자에게 쉽게 확산되지않음 
• 설계를 했으나 설계자가 구현 담당자에게 지속적으로 설명을 안해주면 코딩 작업을 하기가 어려움, 이로인해 코딩과 설계를 동일한 개발자가 하는 문제 발생 
• 매일 야근, 일정이 너무 촉박해서 야근하기도 하지만, 사내 분위기가 야근을 하는 분위기라 야근을 하는 경우도 발생