 |
|
난이도 : 초급 Roy W. Miller, 소프트웨어 개발자, RoleModel Software, Inc
2002 년 11 월 01 일 XP 실전 돌입에 앞서 생각하는 방식에 변화를 가져오는 방법 부터 설명하고자 한다. 이것은 쉬운 일은 아니다. XP에는 대부분의 프로그래머나 비지니스 관계자들의 마음자세를 달리 해야하는 무언가가 있다.
프로그래머 컨디셔닝
나는 컴퓨터 관련 학위가 없다. 따라서 "전통적인" 프로그래머 트레이닝에 대한 직접적인
경험을 말할 수 없다. 나는 많은 프로그래머들과 업계 사람들과 여러 소프트웨어 개발 프로젝트를 해왔다.
결과적으로 사람들이 생각하는 방식과 소프트웨어를 만들 때 행동하는 방식에 대해 이론적으로 말할 수 있다.
프로그래머 행동 패턴
나의 아버지는 물리학자이다. 아버지는 의과 대학에 가서 졸업하면 의사가 되라고 거듭 말씀하셨다. 이는 대부분의
컴퓨터 공학도가 졸업한 후의 상황과 비슷하다. 그들은 많은 이론을 습득한 후 대학을 나오지만 좋은 코드를
작성하는 방법에 대해서는 많이 모른다. 나는 컴퓨터공학 학위가 없기 때문에 그 많은 이론은 잘 모른다.
가끔 이것이 상처가 되긴 하지만 대부분은 그렇지 않다.
내가 프로그래밍을 시작했을 때, 나는 대학을 갓 졸업한 22살 이였다. Andersen Consulting에서
훈련을 받았고 멘토가 나에게 여러가지 방법을 알려주었고 나는 그럭저럭 헤쳐나갔다. 이는 대부분의 사람들도
다 하는 것이다. 그들은 일하면서 프로그래밍을 배운다. 결국 대부분의 프로그래머들은 일을 가능한 빨리 해치우는
것을 배운다.
네 가지의 프로그래머 행동 패턴은 매우 일관성이 있다:
- 프로그래머들은 비지니스 정책 결정 담당자들에게 잘 설명하는 방법을 모른다.
- 프로그래머들은 교과서적 문제를 기대한다.
- 프로그래머들은 혼자 일하기를 좋아한다.
- 프로그래머들은 테스팅이 코딩 후 작업이라고 생각한다.
비지니스 컨디셔닝
업계 사람들은 자신들만의 트레이닝 방법이 있다. 업계 사람들은 그들의 소프트웨어 프로젝트를 위험에 빠트리는
방식으로 행동해가고 있다.
비지니스 비용
예산을 담당하고 있는 업계 사람들은 매일매일 계산을 할 수는 있다. 하지만 소프트웨어가 필요한 이유에 대해
생각하는 방법을 모르는것 같다. 그들의 비지니스에 적합한 기능의 우선순위나 금전적 가치에 대한 현실적인
개념이 없다. 이는 충분히 이해가 된다. 왜냐하면 프로젝트의 말단 매니저와 기업의 리더 모두 그럴 수 있기
때문이다.
많은 기업 환경에서, 특별히 대기업에서, 명령은 위로부터 내려오고 하위 구조에 있는 사람들은 이를 실행하면
된다. 프로젝트 관리 책임자들에게는 생각할 권한이 주어지지 않는다. 따라서 명령이 내려지면 그들은 그저
순종해야 한다.
비지니스 리더들이 소프트웨어를 그릇되게 생각하고 있다는 것이 문제이다. 그들은 소프트웨어를 자산으로
보는 대신 비용으로 생각한다. 소프트웨어는 필요악이라고 생각하거나 생산 수단으로 생각한다.
개입을 원치 않는다.
업계 사람들이 소프트웨어 프로젝트에 "개입되어 있다"는 것은 과장된 경우가 많다. 보통
전혀 개입하지 않고 있다. 프로젝트는 일반적으로 분석 설계로 시작한다. 기술 팀은 업계 사람들이 박식하기를
바란다.
업계 사람들은 긴장되어 있다. 그들은 알지못하는 것에 대해 명확한 성명서를 원한다. 업계 사람들이 질문을
하면 개발자들은 이를 규명한다. 협동적이면서도 창조적인 행위들이 일어날 수 있겠는가?
기업 줄다리기
대립은 강도가 높다. 프로젝트 매니저로서 당신의 상사는 한바탕 욕을 퍼붓고는 지나갈 것이다. 당신은 모든
사람들을 행복하게 만들어야 한다.
틀 깨기
대부분의 기업들은 이러한 종류의 행동의 틀에 갇혀있다. 그 결과는 사람들을 무시하는 소프트웨어 프로젝트이고
프로젝트가 끝났을 때 어떤 누구도 만족시키지 못하게된다.
그럼 희망은 없는것인가? 여전히 이 상태로 머무를 것인가? 다르게 행동하지 않는 한 그럴 것이다. 나는
사고 처리에 대한 전문가는 아니다. 나는 내 경험을 말할 수 있을 뿐이다. 다르게 생각할 줄도 알아야 하며
이것이 행동에 영향을 끼칠 것이라고 믿고있다. 나는 우선 다르게 행동해야 한다. 그 다음에 행동이 뒤따른다.
나에게 있어 최선의 방법은 내 사고방식을 바꿔가며 다르게 행동하는 것이다. 이렇게 할 때 XP가 도움이
된다.
XP는 전형적인 조건에 반(反)하는 행동을 요구한다. 여기에서 최상의 결과를 얻고 이것이 맞고 틀리는지를
결정하기 위한 유일한 방법은 일정 기간동안 최대한의 연습을 하는 것이다. 시간을 투자해서 기업 내 소프트웨어를
만드는 사람들에게 이러한 건전한 습관이 배도록 하는 것이다.
XP 관례는 사람들의 생각을 바꾸는데 도움이 된다. 믿음의 도약이 필요하다. XP는 "일반적(normal)"이지
않다. 따라서 시작할 때 당연히 어색하다. 자신에게 맞지 않은 것처럼 여겨질 것이다. 기업에 결코 맞지
않을 것 처럼 보인다. 하지만 시도도 하지 않고 속단할 수는 없다. 먼저 실행하는 것이 순서이다. 두 주
정도 XP를 시도해보라. 두 가지 약속을 해야한다:
- 이상하거나 또는 적대적으로 느껴질지라도 포기하지 말라.
- 자신이 하고 있는 것에 대해 다르게 생각할 수 있도록 끊임없이 노력하라.
대단한 '사칭자'
익숙하지 않은 것을 만나면 두 가지 방식으로 가장해야 한다:
- 이 태스크를 좋아하는 것처럼 가장한다. 진짜로 이것을 좋아하는 체 해야한다.
- 이 관행이 당신에게 기대하는 바 대로 다르게 생각하도록 한다.
물론 이미 이 관행을 좋아하고 있다면 가장할 필요는 없다. 하지만 좋아하지 않는다면 좋아하는 것 처럼
행동해야한다. 언제나 연습한다. 이것 없이 코드를 작성할 수 없을 것처럼 행동한다. 이 관행을 너무 싫다면
극복하라. 불신앙을 중지하고 어떻게든 행하라.
이렇게 가장하는 것으로 습관이 형성된다. 이러한 습관은 생각을 변화시킬 것이다. 점점 자연스럽게 느껴질
것이다.
가치에 집중할 것
다음은 당신의 팀이 만들고 있는 소프트웨어 기능에 대한 두 가지 질문이다:
- 이 기능은 어느 정도의 가치가 있는가?
- 얼마만큼 써먹을 수 있는가?
기능에 대한 정확한 이해가 필요하다. 왜냐하면 누군가는 이 소프트웨어에 값을 치르기 때문이다. 그들이
무엇에 돈을 지불하는지 알아야한다.
회유자
XP로 소프트웨어를 개발할 때 생각을 바꿀 줄 알아야한다. 다음은 생각해봐야 할 중요한 문제들이다:
- 고객은 언제나 개발자를 몰고간다. 개발자는 고객을 팀의 일부로 봐야한다. 고객은 자신들을 팀의 일부로
생각해야 한다.
- 고객은 상부로부터의 임의의 압력이 아닌 비지니스 필요에 의해 움직여야한다.
- 고객은 비지니스 필요를 기능에 연결시켜야한다. 그렇지 않으면 프로그래머는 코드가 무엇을 하는지를
모른다.
- 고객은 수락 테스트를 정하여 각 단계가 끝났을 때 개발자에게 말해주어야 한다.
- 개발자들은 고객의 요구 없이 어떤 기능을 추가할 수 없다.
- 개발자들은 프로그래머 테스트를 언제나 작성해야한다.
위 사항들은 너무 다르다. 훈련이 필요하다. 훈련은 대부분의 경우 프로젝트 성공이라는 보상으로 다가온다.
언제나 총을 지녀라.
변화는 위쪽에 영향을 미쳐야 한다!
변화는 위에서부터 시작되어야 한다고 말하고 싶지만 많은 경우 그렇지 않다. 가끔 변화는 아래로 부터 와야한다.
단기적인 압박을 줄이기 위해 윗 사람들에게 거짓말 하는 것을 멈추는 것으로 변화는 시작된다. 진실을 말하라.
참고자료
필자소개  | |  | Roy W. Miller: 소프트웨어 개발자 & 기술 컨설턴트. |
기사에 대한 평가
 |
| 이 문서 북마킹 하기
|
|