•
이 장에서는 개발자에게 관리자가 고려할 문제를 이해하는데 도움을 주는 내용들이 들어있다.
1. 훌륭한 코딩 장려
•
코드는 구현의 주요 산출물이기 때문에 구현 관리에서 좋은 코드 작성 습관을 어떻게 장려할 것인가는 매우 중요하다.
•
일반적으로 관리자가 기술적인 표준을 정하는 것은 좋은 생각이 아니다. 프로그래밍 표준을 정할 것이라면 개발자가 직접 정하는 것이 좋다.
표준을 정할 때 고려할 사항
•
엄격한 표준을 정했을 때, 이를 받아들이지 않는 그룹에 속해있다면 유연한 지침이나 지침이 아닌 제안 모음, 가장 좋은 습관을 구체화한 예제 모음 등을 대안으로 고려해본다.
좋은 코딩을 장려하는 기법
•
프로젝트의 모든 영역에 두 사람을 할당하라
◦
페어 프로그래밍, 멘토, 2인 1조 검토 방식 등이 있다.
•
모든 코드를 검토하라.
•
검토를 위해 좋은 에제 코드를 돌려보라.
•
코드가 공용 자산이라는 것을 강조하라.
•
좋은 개발 방식에 대해 보상을 하라.
•
한 가지 쉬운 표준
2. 형상 관리
형상 관리란 무엇인가?
•
형상 관리는 시간이 지나도 시스템이 무결성을 유지할 수 있도록 체계적으로 프로젝트의 부산물을 파악하고 변화를 처리하기 위한 행위로, 변경 관리라고도 한다.
◦
형상 관리는 제시된 변경 사항에 대한 평가와 변경 추적, 다양한 시점에서 시스템의 복사본을 유지하기 위한 기법을 포함한다.
•
요구사항에 대한 변경을 관리하지 않으면 무의미한 변경이나 시스템의 새로운 부분과 호환되지 않는 코드를 작성할 수도 있다.
•
코드에 대한 변경을 관리하지 않으면 충돌이 발생할 수 있으며 원래보다 코드를 더 여러번 테스트해야 하게끔 만들 수도 있다.
요구사항과 설계의 변경
•
다음은 설계의 변경을 제어하기 위한 몇 가지 지침이다.
◦
체계적인 변경 관리 절차를 따르라.
◦
변경 요구사항을 그룹으로 처리하라.
◦
각 변경 비용을 산출하라.
◦
지나친 변경을 주의하라.
◦
변경 관리 위원회나 프로젝트에 맞게 그와 비슷한 것을 결성하라.
◦
관료주의를 주의하되, 관료주의에 대한 두려움이 효과적인 변경 관리를 방해하지 않도록 한다.
•
종종 변경 관리에 어려움을 겪는 프로젝트가 있다. 그렇다고 해서 변경 관리를 하지 않아서 어려움을 겪는 프로젝트가 10배는 더 많다.
소프트웨어 코드 변경
•
버전 관리는 팀 프로젝트에 필수적이다. 버전 관리와 결함 추적, 변경 관리가 통합되면 훨신 강력한 도구가 된다.
도구 버전
•
컴파일러와 링커, 코드 라이브러리를 포함하여 해당 소프트웨어의 특정한 버전에 해당되는 환경을 구성할 필요가 있다면 버전 관리에 추가해야 한다.
3. 구현 일정 예측
예측 방법
•
프로젝트의 크기와 프로젝트를 완료하는 데 필요한 노력은 다양한 방법으로 예측할 수 있다.
•
다음은 프로젝트를 예측하는 좋은 접근법이다.
◦
목표를 수립하라.
◦
예측을 위한 시간을 내서 계획하라.
▪
무작정 예측하면 정확하지 않다. 큰 프로젝트를 예측하고 있다면 예측을 하나의 작은 프로젝트로 취급하여 계획을 수립하는 시간을 갖도록 하라.
◦
소프트웨어 요구사항을 자세히 적어라.
◦
하위 수준의 세부 사항을 예측하라.
◦
여러 가지 예측 기법을 사용하고 그 결과를 비교하라.
◦
주기적으로 다시 예측하라.
▪
프로젝트에 관련된 요인은 변하기 때문에 주기적으로 예측을 갱신하기 위한 계획을 수립하라.
구현의 양에 대한 예측
•
구현이 프로젝트 일정에 영향을 미치는 영향의 정도는 상세한 설계, 코드 작성 및 디버깅, 단위 테스트와 같이 구현이 프로젝트에서 차지하는 비중에 달려 있다.
•
구현이 차지하는 비중은 프로젝트의 크기에 따라 달라지며 회사가 자체적으로 프로젝트 이력 데이터를 가지기 전까지는 위 그림을 참고하여 출발점으로 삼는 것이 좋다.
일정에 미치는 영향
•
일정에 가장 큰 영향을 미치는 것은 만들 프로그램의 크기다. 하지만 다른 요소 역시 개발 일정에 영향을 미치는데, 다음과 같이 다양한 요인들이 존재한다.
◦
정량화 가능한 요인
Factor | Potential Helpful Influence | Potential Harmful Influence |
Source: Software Cost Estimation with Cocomo II (Boehm et al. 2000). | ||
Co-located vs. multisite development | −14% | 22% |
Database size | −10% | 28% |
Documentation match to project needs | −19% | 23% |
Flexibility allowed in interpreting requirements | −9% | 10% |
How actively risks are addressed | −12% | 14% |
Language and tools experience | −16% | 20% |
Personnel continuity (turnover) | −19% | 29% |
Platform volatility | −13% | 30% |
Process maturity | −13% | 15% |
Product complexity | −27% | 74% |
Programmer capability | −24% | 34% |
Reliability required | −18% | 26% |
Requirements analyst capability | −29% | 42% |
Reuse requirements | −5% | 24% |
State-of-the-art application | −11% | 12% |
Storage constraint (how much of available storage will be consumed) | 0% | 46% |
Team cohesion | −10% | 11% |
Team's experience in the applications area | −19% | 22% |
Team's experience on the technology platform | −15% | 19% |
Time constraint (of the application itself) | 0% | 63% |
Use of software tools | −22% | 17% |
◦
정량화할 수 없는 요인
▪
요구사항 개발 경험과 능력, 개발자의 경험과 능력, 팀의 동기, 관리 품질, 재사용된 코드의 양, 인원 교체율, 요구사항의 변동성, 고객과의 관계의 품질, 요구사항에서의 사용자 참여, 응용 분야에 대한 고객의 경험, 개발자가 요구사항 개발에 참여하는 정도, 컴퓨터와 프로그램, 데이터에 대한 보안 환경, 문서의 양, 프로젝트 목표
•
각 요인들을 중요도에 따라 고려한다.
예측과 관리
•
예측을 완료했다면 이제 정해진 시간과 명세에 맞춰 제품을 출시하기 위해 사람과 기술 자원 사용을 어떻게 제어할 것인가가 문제다.
•
그런 면에서 초기 예측의 정확성은 일정을 맞추기 위한 자원 제어의 성공보다는 훨씬 덜 중요하다.
일정에 뒤처졌을 때 해야 할 일
•
일반적인 프로젝트는 거의 100%의 확률로 계획된 일정을 초과한다. 일정을 늘릴 수 있다면 그렇게하고 그렇게 할 수 없다면 다음 해결책들을 시도해볼 수 있다.
◦
일정에 맞출 수 있다는 희망을 품는다.
◦
팀을 키운다.
◦
프로젝트의 범위를 축소한다.
4. 측정
•
다음은 프로세스를 측정해야 하는 합당한 이유다.
◦
어떤 프로젝트 속성이든 측정하는 것이 측정하지 않는 것보다는 낫다.
▪
측정 결과가 완벽할 것이라는 보장도 없고 측정이 어려울 수 있으나 측정은 측정하지 않고는 가질 수 없는 지침을 제공한다.
◦
측정의 부수 효과를 주의하라.
◦
측정을 반대하는 것은 실제 프로젝트에서 무슨 일이 일어나고 있는지 모르는 게 낫다고 주장하는 것이다.
5. 개발자를 사람으로 대우하기
개발자들은 어떻게 시간을 보내는가?
•
의외로 그들은 많은 시간을 코드 작성에 보내지 않는다. 산책, 커피, 잡담으로 꽤나 많은 시간을 보낸다.
성능과 품질의 다양성
•
개발자 개인별 능력과 노력은 모든 분야에서 그러하듯 굉장히 다양하다.
•
좋은 개발자를 고용하기 위해 더 큰 비용을 지불해야 한다면 기꺼이 그렇게 하라.
신앙적인 문제
•
관리자가 개발자에게 특정한 프로그래밍 습관을 따를 것을 요구하고 있다면 그것은 개발자의 화를 돋구게 하는 것이다.
•
다음은 일반적으로 널리 알려진 신앙적인 문제다.
◦
프로그래밍 언어, 들여쓰기 방식, 중괄호의 위치, IDE 선택, 주석 작성 방식, 효율성과 가독성 간의 상충관계, 방법론의 선택, 유틸리티, 네이밍 컨벤션, 전역 변수의 사용, 측정
•
이러한 영역을 관리자가 진정 다루기 원한다면 다음 사항들을 충분히 고려하라.
◦
자신이 민감한 영역을 다루고 있다는 것을 인식하라.
◦
해당 영역에 대한 제안이나 지침을 사용하라. 규칙이나 표준을 정하지 말라
◦
개발자들이 자신만의 표준을 개발하게 하라.
6. 관리자 관리
•
다음은 관리자를 관리하는 몇 가지 방법이다. 그들을 관리하면서도 내가 그들에게 관리받고 있게끔 느끼도록 만들어야 한다.
◦
자신이 원하는 것에 대한 아이디어를 정한 다음, 관리자가 그 아이디어를 수행하는 것에 대해 생각할 때까지 기다린다.
◦
작업을 수행하기 위한 올바른 방법에 대해 관리자에게 교육하라.
◦
관리자가 자신에게 바라는 것을 처리하면서 관리자의 흥미에 초점을 맞추고 관리자가 불필요한 구현 세부 사항으로 방해받지 않게 하라.
◦
관리자가 지시하는 것을 거부하고 자기 일을 올바른 방식으로 계속 진행하라.
◦
다른 직장을 찾아라.
•
데일 카네기의 카네기 인간 관계론을 읽으면 최고의 장기적인 해결책인 관리자를 교육하는 노하우를 쌓는데 도움이 될 것이다.
요점 정리
•
좋은 코드 작성 관행은 표준을 강요하거나 더 솜씨 있는 접근 방법을 통해 달성될 수 있다.
•
형상 관리는 잘 사용하면 개발자의 일을 더 쉽게 만들어 준다. 특히 형상 관리는 변경 관리를 포함한다.
•
소프트웨어를 잘 측정하기란 쉽지 않다. 성공적으로 측정하기 위한 핵심 사항은 여러 접근 방법을 사용하고 프로젝트를 진행하면서 측정을 조율하고 측정을 하기 위하여 데이터를 활용하는 것이다.
•
측정은 성공적인 구현 관리를 위한 핵심 요소다. 프로젝트의 일부라도 측정하면 측정을 전혀 하지 않는 것보다 더 나은 길을 찾을 수 있다. 정확한 측정은 정확한 일정, 품질 관리, 개발 프로세스 향상의 핵심이다.
•
개발자와 관리자도 사람이기 때문에 사람으로 대우받을 때, 업무 성과가 가장 뛰어나다.
