[소프트웨어 공학] 이슈 관리 시스템을 보면 회사를 안다.

---

안녕하세요 돼지왕 왕돼지입니다.

오늘은 "이슈 관리 시스템을 보면 회사를 안다" 를 주제로 이야기 하고자 합니다.

이 글은 "글로벌 소프트웨어를 꿈꾸다" 를 요약 정리한 내용입니다.

09. 이슈관리 시스템을 보면 회사를 안다.

- 이슈관리시스템은 전사적으로 보았을 때 가장 중요한 기반 시스템이다. 

- 이슈는 오류 혹은 버그는 당연하고, '새로운 기능' 도 이슈에 포함된다. 작업 요청, 사소한 질문이나 의견도 포함된다.

- 이슈를 등록할 떄 처음부터 정확한 정보를 입력하기는 힘들다. 하지만 각자 아는만큼만 입력하고 진행하면, 저절로 데이터가 추가 정리되고, 대화를 통해 모든 정보가 정확하게 기록으로 남는다. 따라서 데이터를 입력할 떄 정확해야 한다는 강박관념을 없애는 것도 중요하다.

이슈관리 시스템의 사용성

- 전사적으로 제품이 몇 개나 있는지 한 눈에 알 수 있다. 버전과 컴포넌트 갯수도 알 수 있다.
- 어떤 제품이 회사의 핵심 제품인지를 알 수 있다. 고객이 누구인지도 알 수 있고, 얼마나 많이 팔리는 제품인지 추측할 수 있다.
- 각 제품의 안정성, 버그나 기능 요청이 얼마나 있는지, 어제 새로 발생한 심각한 문제가 있는지 알 수 있다.
- 제품의 개발 혹은 유지보수의 진행 상태를 알 수 있다. 다음 버전이 언제 나오는지 몇 퍼센트나 이슈가 해결되었는지를 알 수 있다.
- 어느 개발자 혹은 어느 부서의 업무가 과도한지 혹은 한가한지를 알 수 있다. 즉, 관리자가 필요로 하는 많은 정보를 알 수 있다.
- 데이터베이스로 관리되므로 필터를 이용하여 보고 싶은 정보를 항상 여러 각도로 볼 수 있다.

이슈관리 시스템의 장점

- 전사 커뮤니케이션 효율성이 높아진다. 따라서 생산성도 올라간다.
- 전사적으로 투명성을 제공한다. 관리와 개발 모두의 위험요소가 줄어든다.
- On-line 으로 정보를 주고받음으로써 종이 문서가 줄어든다.
- 회의가 줄어들어 시간이 절약된다.
- 이슈에 관한 다양한 통계를 제공한다. 미래 개선의 근거가 된다.
- 과거 이슈에 대한 모든 데이터를 저장한다.
- 모든 임직원의 평가를 할 수 있는 중요한 데이터를 제공한다.
- 대화, 모니터링, 투명성의 조합으로 간접결재의 기능을 제공한다. 

 

10. 소스관리시스템은 개발팀의 축소판이다.

소스관리 시스템 사용시 체크사항

- 소스코드의 코딩 컨벤션이나 프로그래밍 스타일이 통일되어 있는가.
- 주석은 다른 사람이 이해할 수 있게 적는가.
- Commit 할 때 로그를 어떻게 남기는가? 이슈 번호는 있는가? 동료검토한 이름은 있는가?
- Broken Tree 는 발생하지 않는가?
- 몇명이나 개발하는가? 그리구 누가 어떤 Component 를 개발하는가?
- 5년 전, 3년 전, 1년 전에 누가 개발했는지, 그리고 지금은 누가 개발하고 있는가?
- Tagging ( Labeling ) 을 언제, 무슨 목적으로 했는가?
- Rollback 을 한 적이 있는가?
- 버전이 몇 개나 있는가?
- 얼마나 자주 브랜치를 만들고 머지를 했는가?
- 공통으로 사용하는 코드는 얼마나 있는가?
- 스펙, 설계, 테스트 문서는 보관하는가?
- 빌드스크립트는 있는가?
- 문서나 빌드스크립트와 소스와 같은 Baseline 에 포함되어 있는가?
- 국제화와 지역화는 어떤 방식을 사용하는가?

11. 문서를 적으면 개발시간이 단축된다는 것을 진정으로 믿어라.

- 제대로 작성하는 방법을 알고 나서 하면 엄청난 효과를 얻을 수 있다. 믿어라.

12. 스펙( SRS ) 이란 무엇인가?

- SRS (Software Requirements Specification ) 은 분석단계의 결과로 나오는 산출물.

- SRS 는 좋은 품질의 소프트웨어를 최소비용과 최소시간에 개발하기 위해 적는 문서. ( 정보 공유 )

- SRS 는 모든 부서의 사람이 동시에 제품개발에 참여할 수 있도록 명시되어 있어야 한다. 

13. SRS를 작성하려고 노력하라. 그리고 그것은 항상 가능하다.

- 개발을 위해서 주어진 시간이 1시간에 불과하더라도 SRS 작성은 가능하며 꼭 해야 한다.

- SRS 의 작성은 효율적으로 개발하느냐 안 하느냐의 문제. 

14. SRS 쓰는 법은 속성이 안 된다.

- SRS는 배우는데 10년이 걸릴지 20년이 걸릴지 모른다. 부단한 노력이 필요하다.

15. 초가집과 기와집, 어느 것이 더 잘 지었는가?

- SRS는 고객이 원하는 품질 좋은 소프트웨어를 최소시간에 최소비용으로 개발하기 위한 모든 것을 "왜"라고 생각하며 적는것.

16. 장식용 방법론, 제출용 방법론, 실용적인 방법론.

장식용 방법론

- 비싼 방법론을 도입하여, 외부 과시용으로 문서를 많이 만든 형태. 영업용 즉 장식용 방법론이다.

제출용 방법론

- 개발 후반부에 제출하기 위한 용도로 문서를 만드는 방법론. 아무도 보지 않는 문서가 되며, 유지보수가 대부분 안 된다.

실용적인 방법론.

- 개발을 실용적으로 하기 위한 것이 주가 되며, 형식에 치우치지 않는다. 프로젝트에 필요한 만큼의 문서만 골라서 작성하고, 유지보수를 한다.

17. 증상치료와 원인치료

- 증상치료는 응급처치고, 원인치료는 그동안 쌓아온 역사를 거슬러 올라가 치료해야 한다. 증상치료보다 원인치료가 더 중요하다. 

18. 원인치료가 컨설팅의 핵심이다.

- 증상치료보다는 원인치료에 집중해야 한다.

 

도움이 되셨다면 손가락 꾸욱~

---