(*** 필자주석) 이번 번역을 시작하기 전에 회사에서의 상황에 대해 한마디.
회사에서 프로세스를 정의하고 구체적으로 프로세스를 따라서 일을 하기 위해서는 "프로세스 다이어그램" 이라는 것을 만들게 된다. 프로세스를 관리하기 위해서는 핵심적인 문서이다. 프로세스 다이어그램은 벤처회사인 경우 10 페이지 일 수도 있고 대기업인 경우 수천 페이지 일 수도 있다. 그 만큼 회사에 따라 프로세스의 숫자와 상세도가 다양하지만 수십 명의 개발자가 일하는 회사에서 프로세스 다이어그램 하나 없이 개발을 하고 있는 경우는 아직은 프로세스의 중요성과 필요성을 인식하지 못하는 상태라고 할 수 있다. 천재라고 하더라도 프로세스 다이어그램이 필요 없다고 생각하는 것은 총 잘 쏘는 병사가 전쟁을 수행하겠다는 것과 비슷하다. 회사에서 회계관리를 머리로 하는 것과 비슷하다. 새 직원이 들어왔을 때 가르쳐 주기도 어렵다. 프로세스라는 용어에 대해 과거의 잘못된 경험에서 온 거부감을 고집하기 보다는 모든 사람이 체계적이고 편안하게 일하는 기본 규칙이라고 생각하기 바란다. 물론 더 위험한 것은 이론가들이 만들어 놓은 과도한 프로세스이다. 소크라테스가 말한 '무지한 사람이 하는 행위는 절대 선이 될 수 없다 (The only evil is ignorance)"가 잘 적용되는 경우이다. 소프트웨어 공학이라는 용어자체가 "현실" 이라는 의미를 가지고 있듯이 본질적으로 이론가들이 가이드 하기에는 매우 위험한 분야이다.
8장 Software Engineering Process (소프트웨어 공학 프로세스)
1. 소프트웨어 프로세스 정의 ( 이전 포스트)
1.1 소프트웨어 프로세스 관리 (Software Process Management)
소프트웨어 프로세스 관리의 2가지 목적은 프로세스를 새로 도입할 때나 개선을 하려고 할 때 효율성(Efficiency)과 효과(Effectiveness)를 높이기 위한 것이다. 프로세스는 개인, 프로젝트, 조직 수준에서 벌어지는 모든 프로세스를 포함한다.
통상적으로 제품을 개발하는 있어서 효율성과 효과를 증가시킨다는 기대에서 프로세스를 도입하거나 개선을 하게 된다. 최종 목표는 개발비용, 개발일정, 제품품질을 향상시키는 것이다. 그를 위한 프로세스의 도입, 조직의 변경, 그리고 인프라구조의 변경(새로운 기술 도입이나 도구의 변경 등)은 모두 밀접하게 연관되어 있다. 프로세스 변경은 소프트웨어의 제품뿐 아니라 조직의 변경도 유발한다. 프로세스 변경은 전 조직에 파급효과(Ripple Effect)를 가져온다. 예를 들면 IT의 도구나 기술의 변경은 대부분 프로세스의 변경을 요구한다.
일부 과정에서 신규 프로세스가 도입될 때 다른 기존 프로세스가 변경될 지도 모른다. 예를 들면 개발과정에 새로운 검사 프로세스를 도입하면 테스트 프로세스가 변경될 가능성이 높다. 이런 현상을 "프로세스 진화(Process Evolution)"라고 한다. 이런 진화가 대규모인 경우에는 조직의 문화와 비지니스 모델도 프로세스의 변화를 수용할 수 있도록 같이 변화해야 한다.
(*** 필자주석) 회사의 변화는 의도적인 프로세스의 변화로 일어나기도 하지만 어떤 도구를 도입할 때도 일어난다. 예를 들어 빌드 도구, 정적분석기, SVN이나 Git와 같은 소스코드관리도구의 변경 등으로 항상 벌어진다. 그럴 때 가장 많이 하는 실수가 단순한 도구의 도입으로만 생각하는 것이다. 도구의 도입은 항상 크고 작은 프로세스의 변경으로 이어진다. 그럴 때 기존 프로세스를 처음부터 끝까지 검토해보는 것이 중요하다. 이런 경우를 위해 체계적으로 작성된 프로세스 다이어그램과 같은 문서가 필수적으로 필요하다.
프로세스의 변화는 많은 비용을 초래하게 된다. 실리콘밸리와 같이 오랜 공력이 쌓인 회사에서 조차 변화는 위험하기 때문에 조심해서 수행해야 한다. 현실적으로 대규모의 급진적인 변화는 거의 없고(또 그럴 필요성도 거의 없다) 대부분은 조그만 변경을 간헐적으로 한다. 그런 조그만 변화에도 개발자들의 준법정신이 성공에 큰 역할을 차지한다. 프로세스는 모든 사람이 규칙을 따를 때 효과가 있는 것인데 독불장군이 있다면 프로세스가 제대로 정착하기는 어렵다. 특히 프로세스는 형식적인 면과 내용적인 면이 있는데 형식적인 면에서는 억지로 따라 할 지 모르지만 내용적인 면은 강제화하기도 어렵고 평가하기도 어려운 부분이다. 예를 들어 동료 검토 같은 것이 그렇다. 하는 흉내는 낼지 모르지만 시간 낭비하는 경우가 많다. 그래서 내용을 충실하게 만들 수 있는 역량이 없다면 준비된 다음에 하는 것이 좋다.
121 소프트웨어 프로세스 인프라구조 (Software Process Infrastructure)
소프트웨어 프로세스의 도입, 구현, 관리는 각 단위 프로젝트에서 시작한다. 그렇지만 프로세스는 모든 조직에서 같이 일사분란 하게 도입할 때 조직의 모든 소프트웨어에 혜택을 줄 수 있다. 소프트웨어 프로세스 인프라구조(Software Process Infrastructure)는 프로세스의 정의, 프로세스의 해석, 프로세스의 정책, 그리고 프로세스를 적용하기 위한 절차를 제공한다. 더 나아가서는 투자비용, 도구, 교육, 프로세스 도입과 유지보수에 필요한 인력을 제공한다.
소프트웨어 프로세스 인프라구조는 프로젝트의 규모와 조직의 규모에 따라 다르다. 소규모의 간단한 조직과 프로젝트는 간단한 프로세스 인프라구조가 필요하다. 반대로 크고 복잡한 규모의 조직과 프로젝트는 크고 복잡한 프로세스 인프라구조가 필요하다. 큰 규모의 경우에는 프로세스의 구현과정이나 개선활동을 가이드하는 소프트웨어공학 그룹이나 운영 위원회 같은 조직이 만들어 질 수도 있다.
가장 흔하게 벌어지는 잘못된 착각은 소프트웨어 프로세스의 도입이 소프트웨어 프로젝트에 추가적인 시간과 비용을 더한다는 생각이다. 당연히 프로세스의 도입과 개선에 들어가는 비용이 있다. 하지만 조직적인 프로세스의 개선이 높은 생산성, 비용절감, 재작업의 감소, 품질 좋은 제품의 혜택이 있다는 것을 경험이 보여주었다. 프로세스의 성능이 소프트웨어 제품의 품질에 영향을 미친다고 볼 수 있다.
(*** 필자주석) 간단하면 간단한 프로세스, 복잡하면 복잡한 프로세스가 필요하다는 너무 당연한 얘기이지만 실제로 따라 하기는 힘들다. 간단하다고 아예 안 하는 경우도 많고 큰 규모를 한 번에 하려는 경우도 많다. 변화에는 Big bang(한번에)과 Phased Approach(단계별)가 있는데 프로세스에도 Big bang이 좋은 경우도 있고 Phased Approach가 좋은 경우도 있다. 예를 들어 이슈관리시스템은 형식으로는 Big bang으로 도입하지만 내용은 Phased Approach로 서서히 향상시켜 가야 한다. 내용과 같이 경험이 쌓여야지만 제대로 수행될 수 있는 것을 Big Bang으로 수행하는 것은 불가능하다. 도구는 한 번에 준비를 해 주지만 사용은 천천히 해야 현실적이다. 골프를 하루에 다 배우겠다는 것과 같다. 단 골프채는 시작할 때 사 주어야 한다.
또 얼마나 간단한가를 판단하는 것이 중요하다. 필자가 가장 많이 본 실수는 원칙을 알고 적용하는 대신에 자신이 하고 있는 잘못된 관행을 진리로 알고 프로세스로 옮기는 것이다. 원칙을 정확히 아는 것이 중요하다. 프로세스가 다른 개발방법론이 100개가 넘게 있지만 모두 원칙은 동일하다는 것을 깨닫기 바란다. 어느 날 갑자기 획기적인 방법론을 발견했다고 도입해서 사용한다면 성공할 확률은 없다. 그런 금방망이는 존재하지 않는다. 건강식품 판매자 들의 과대선전으로 생각하면 된다. 건강식품과 같이 판단 실수와 오류를 건전한 시행착오로 미화하면 안 된다. 어떤 시행착오는 성장에 꼭 필요한 경험이기도 하지만 어떤 시행착오는 조직과 자신을 회복이 불가능한 파멸로 이끄는 경우도 있다. 모든 배움이 그렇지만 소프트웨어에서도 훌륭한 스승의 역할이 그래서 중요하다.
다음 포스트의 순서는 다음과 같다.
2. 소프트웨어 생명주기 (SW Life Cycles)
2.1 소프트웨어 프로세스의 분류 (Categories)
2.2 소프트웨어 생명주기 모델 (Life Cycle Models)
2.3 소프트웨어 프로세스 적용 (Adaptation)
2.4 현실적인 고려 (Practical Considerations)
3. 소프트웨어 프로세스 평가와 개선( SW Process Assessment and Improvement)
3.1 소프트웨어 프로세스 평가 모델 (Assessment Models)
3.2 소프트웨어 프로세스 평가 방법 (Assessment Method)
3.3 소프트웨어 프로세스 개선 모델 (Improvement Models)
3.4 연속적, 단계적 소프트웨어 프로세스 등급 (Continuous and Staged SW Process Ratings)
4. 소프트웨어 측정 (SW Measurement)
4.1 소프트웨어 프로세스와 제품 측정 (Process and Product Measurement)
4.2 평가결과의 품질 (Quality of Measurement Results)
4.3 소프트웨어 정보 모델 (SW Information Models)
4.4 소프트웨어 프로세스 측정 기술 (Measurement Techniques)
5 소프트웨어 공학 프로세스 도구들 (SW Engineering Process Tools)
댓글 없음:
댓글 쓰기