Project Management

• 외주 업체 개발
• Books
  • Rapid Development _{1996, 2003}
  • 애자일 & 스크럼 프로젝트 관리 ²⁰¹⁶

외주 업체 개발

(p309, 『테슬라 모터스』, 2017, 2020)

Books

Rapid Development _{1996, 2003}

‘쾌속 개발 프로젝트’란 개발 속력을 강조하는 모든 프로젝트를 일컫는다. 요즘과 같은 분위기에서는 프로젝트 대부분이 이에 해당한다. p.26

• 쾌속 개발 전략
• 전형적인 실수 ^{Classic Mistakes}
  • 사람: 문제 인물 방치. 팀이 팀장에게 가지는 가장 흔한 불만은 문제 팀원에 대해 조치를 취하지 않는 태도다(Larson and LaFasto 1989)
  • 영웅적 행동. 일부 소프트웨어 개발자는, 어떤 영웅심은 이로울 수 있다고 생각하며, 프로젝트에서 영웅적 행동을 강조한다(Bach 1995). 그러나 어떤 식이든 영웅적 행동을 강조하는 분위기는 이익보다는 해가 된다. 사례 연구에서 중간 관리층은 꾸준하고 일관성 있는 진행과 의미있는 보고보다 ‘할 수 있다’식 태도를 더 중시했다. 그 결과, 모험적이고 극단적인 일정을 세웠고 연이은 일정 지연을 발견하지 못하고 그것을 인정하지 않았으며, 마지막 순간까지 경영진에게 보고하지도 않았다.
  • 프로젝트 후반에 인력 추가. 이것이 어쩌면 가장 전형적인 실수다. 프레드 브룩스는 프로젝트 후반의 인력 추가를 불에 기름을 붓는 행위에 비유했다(Brooks 1975)
  • 제품: 연구중심 개발. 세이모어 크레이는 실패할 위험이 너무 크기 때문에, 자신은 한 번에 두 영역을 초과해서 공학적 한계를 뛰어넘는 시도는 하지 않는다고 말했다(Gilb 1988). 새로운 알고리즘이나 계산법 고안이라는 전산학 한계에 도전하고 있다면, 그것은 소프트웨어 개발이 아니라 소프트웨어 연구다. 소프트웨어 개발 일정은 예측 가능하다. 하지만 소프트웨어 연구 일정은 이론상으로도 예측 가능하지 않다.
• Does One Size Fit All? No Silver Bullet.
• 개발 속력 강조의 득과 실 Development-Speed Trade-Offs
  일정, 비용, 제품은 소프트웨어 삼각 시소다. 프로젝트를 성공적으로 수행하려면 사이에 균형을 유지해야 한다. p.139
• 지나치게 낙관적인 일정 Overly Optimistic Scheduling
  윈워드의 최종 일정 5년은 원래 계획한 일정보다 대략 5배가 길었다. 일정을 지나치게 촉박하게 잡았을때 생기는 전형적인 문제점을 찾아볼 수 있다. 윈 워드는 달성할 수 없는 목표를 세웠다. 빌 게이츠는 팀에게 ‘역사상 가장 우수한 문서 작성기 개발’과 ‘가능한 빨리, 가급적이면 12개월 안에’라는 지시를 내렸다. 이 중 하나였다면 달성이 가능했을 것이다. 그러나 둘 다는 불가능했다.
  • 도랑을 치는데 삽질을 더 빨리 하라고 일꾼을 독려하듯이, 설계와 구현을 더 빨리 하라고 개발자를 독려할 수는 없을까? 이 간단명료한 논쟁에 직관적인 대답은 “소프트웨어에서는 효과가 없다”다.
• 일정 압력 해소하기
  • 막연한 기대
  • 소프트웨어 예측 이야기나 낙관적인 일정이 미치는 영향에 대한 무지
    초기 단계에서는 정확하게 예측할 수 없다. 논리적으로 불가능하다. 그럼에도 불구하고, 개발자들은 비현실적인 예측값이라도 내놓으라는 요구를 거절하지 못한다.
  • 협상 기술 부족
    필립 메츠거는 개발자들이 예측은 꽤 잘하지만 예측값을 제대로 변호하지는 못한다고 진술했다(Metzger 1981)
• 시험 프로젝트
  호손 효과 ^{hawthorne effect}: 전등을 밝게 했더니 생산성이 올라갔다. 다음으로 전등을 어둡게 했더니 생산성이 또 올라갔다. 전등 밝기를 그대로 유지했을 때도 생산성은 여전히 올라갔다(Boehm 1981). 실험을 수행한다는 상황 그 자체가 생산성을 향상시켰다는 결론을 내렸다.

애자일 & 스크럼 프로젝트 관리 ²⁰¹⁶

• 전통적 프로젝트 경영에서 벗어나기
  • 스티브 맥코넬은 요구사항 정의를 확정한 이후에도 전체 일정이나 비용은 60~150%까지 변동될 수 있으며 상세 디자인을 완료한 후에야 90~110% 이내로 줄어든다고 이야기한다.
• 애자일 주요 원리
  • 스스로 일하는 개발팀: 자기 조직화된 팀
    ¹
    자율성과 책임감을 주어야 한다. 대규모 개발 프로젝트에서 수행되는 많은 표준화된 절차와 규칙은 개발자의 창의성을 저해하는 요인으로 작용한다.
  • 몇 년 전 IT 담당 공무원을 대상으로 프로젝트 관리 워크숍을 수행하면서 한 관리자에게 “공공 기관에서 진행하는 프로젝트는 대부분 업무 범위와 일정, 비용을 준수하기 때문에 좀처럼 실패하지 않는다.”라는 말을 들은적이 있다. (정해진 일정에 요구 기능을 모두 구현하는게 성공이 아니다. 단 한 가지 기능이라도 제대로 쓰이는게 성공이다.)
• 애자일 프로젝트 계획
  • 스토리 점수: 상대적인 비교 점수, 일관성 유지
• 애자일 프로젝트 진행 관리
• 효과적인 애자일 팀 구성
• 대규모 프로젝트에서 애자일 적용법
• 애자일 프로젝트 관리 적용 사례
  • 스크럼 마스터를 기술 리더와 분리하여 별도 선임. 개발자들의 오너십을 저하시킬 수 있다는 이유로 협력업체 인력을 거의 쓰지 않음. 아웃소싱을 활용하면 비용은 줄일 수 있을지 몰라도 정보 공유와 오너십이 부족하여 창의적인 제품을 개발하는 환경에는 좋은 방법이 아니다.
• 전사 애자일 적용 방안

Last Modified: 2021/06/08 13:03:45