애자일 개발방법론의 산업체 사례 및 경험

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. **

 

애자일 방법론에 대한 경험이 담긴 논문들

- 애자일 기법을 적용한다고 해서, 회사의 모든 개발자가 한 장소에서 daily standup 미팅을 하는 것은 아닐 것이다
- 여러 팀으로 구성되어 있고 각 팀이 애자일 기법을 적용하는 것.

 Choice of Software Development Methodologies

(a) 연수익 (b) 직원 수

(a) 연수익이 높은 기업에서는 Traditional, 즉 Waterfall 방법론을 사용하는 곳이 50% 이상이고, 연수익이 100M 이하인 기업은 Iterative나 Agile을 가장 많이 사용하는 것으로 나타난다.
(b) 그러나 10000명 이상의 직원이 일하는 기업도 24.4%가 Agile을 사용하는 것을 보면, 애자일 기법이 작은 규모의 프로젝트에만 적용 가능한 것은 아니라는 것을 알 수 있다.

(a) 프로젝트 예산 (b) 위험성? criticality

(a) 프로젝트 예산이 20만불 이하인 작은 규모의 프로젝트는 Agile 방법론을 50%가 채택하고 있다.

(b) 높은 criticality가 요구되는 프로젝트에서도 Agile 방법론이 사용될 수 있다.

(a) 프로젝트에 참여하는 팀의 개수 (b) 팀의 크기

(a) 1팀이 참여하는 프로젝트는 대부분 Agile이나 Iterative 방법을 사용하지만, 4팀 이상이 참여하는 프로젝트는 Agile보다는 Waterfall이나 Hybrid 방법론을 채택하고 있다.

(b) 팀의 사이즈 또한 비슷한 양상을 보인다.

프로젝트 규모가 작은 경우에는 Agile, Iterative 방법론을 선호하지만 큰 경우에는 Waterfall이나 Hybrid 방법을 선호한다.
그렇다고 해서, 프로젝트 규모가 큰 경우에 Agile이나 Iterative를 전혀 사용하지 않는 것은 아니라는 점을 명심해야 한다.

---

Project Management in Plan-Based and Agile Companies

 

(a) 주요 소프트웨어 개발에서의 어려움

(b) 애자일 방법을 채택하여 완화된 어려움

 

DSWAFOT: 필요한 모든 기능을 갖춘 소프트웨어를 제시간에 제공하기 어렵다.  → 소프트웨어 공학의 영원한 난제
LQS: 유능한 개발자 부족
HC: 높은 경쟁률
RWC: 고객과의 관계
EDC: 코드의 과도한 문서화

DMRDG: 개발 그룹 내의 관계 관리의 어려움

HTE: 직원의 높은 이직률
MR: 요구사항 관리

 

• 애자일 기법을 사용하면 review, release, 고객과의 피드백이 자주 이루어져 가능해진 것으로 보인다. (DSWAFOT, RWC)
• 고객과의 긴밀하고 활발한 협력관계가 강조 (RWC)
• 개발자들의 업무만족도가 향상된다면 어느 정도 해결이 가능하지만, 업무 강도가 낮아지는 것은 아니다. (EDC, HTE)

---

People over Process: Key Challenges in Agile Development

애자일 기법을 적용할 때 발생할 수 있는 People Challenge에 대한 대처 방법

1. Developer Fear of Skill-Deficiency Exposure
   • 애자일 기법은 자발적이고 적극적으로 일을 해야 하고 거의 매일 모여서 회의를 함
   • 경험이나 실력이 부족한 개발자 입장에서는 정신적 압박을 받을 수 있음
   • 모든 개발자들이 자신의 능력에 맞게 인정을 받고, 서로 돕고 배우는 환경을 조성해야 한다.
2. Broader Skill Sets for Developers
   • 애자일 기법은 개발자의 역할이 정해져있다기보다 멀티플레이어 역할을 해야할 가능성이 높다
   • Pair Programming 등을 이용한 지식 전달, 업무 분담 
3. Increased Social Interaction
   • 잦은 회의와 Pair Programming은 혼자서 개발하는 것을 선호하는 개발자들에게 힘들 수 있다.
   • 사회능력을 기를 수 있도록, 개발자들이 충분히 자신의 능력을 발휘할 수 있도록 환경 제공
4. Lack of Business Knowledge
   • 개발자가 관련 비즈니스 지식이 부족한 것이 보이면 신뢰를 잃게 됨
   • 교육 세션 열어주기, 비즈니스 지식이 있는 팀원 모집하기
5. Understanding Agile Values and Principles
   • 애자일 기법을 적용하긴 하지만 효과적으로 도입 X
   • 애자일 관련 교육 필요
6. Lack of Motivation
   • 애자일에 대한 동기부여 X
   • 성공 사례 보여주기...?
7. Devolved Decision-Making
   • 자율적인 의사결정으로 인한 문제
   • 민주적인 시스템 도입, PM을 진행자로
8. Implementing Agile-Compliant Performance Evaluation
   • 애자일하게 하지만, 평가는 결국 성과로만 평가
   • 평가항목에 여러 가지 추가
9. Recruting Challenges

---

Have Agile Techniques been the Silver Bullet for Software Development at MS?

애자일 기술은 MS의 소프트웨어 개발을 위한 만병통치약이 되었는가?

Microsoft사 내부의 2000명을 대상으로 설문조사
애자일 기법을 적용한다고 대답한 사람: 34% (2006) → 57% (2012)로 증가하였음
→ 애자일에 대한 연구가 2000년부터 시작되었으니 만병통치약으로 받아들여지지 않았음을 알 수 있다.

• 애자일 기법의 적용 여부와 관계없이 Code review는 거의 모두 시행되고 있으며,
  Unit testing, automated build, team coding standard 또한 마찬가지이다.
  → 이러한 기법들은 이미 MS내에서 늘 사용되는 것이기 때문
• Daily Standup Meeting: O팀 (80%) vs X팀 (30%)
  → 애자일을 사용한다고 모두가 하는 것은 아니고, 애자일을 사용하지 않는 팀도 선별적으로 적용함.
• Pair Programming: O팀 (40%) vs X팀 (25%)
  → 이미 MS내에서 "Buddy testing" 체제가 구축되어 있기 때문 (개발자1+테스터1)
  → 분산된 개발환경으로 인한 적용의 어려움
• test driven development: O팀 (60%) vs X팀 (40%) → 낮다.
  

 

애자일 기법의 장점

• 장점으로 대부분 비슷한 의견을 제시하고 있으며, 순위도 비슷함 (막대기가 평행)

애자일 기법의 단점

• 의견에 차이를 조금 보임
• Incorrect practice of Agile(애자일 적용을 제대로 못함)이 공통적인 1위 단점으로 뽑힘
• Scalability(대규모 프로젝트에 적용이 어려움)도 각각 3,2위로 뽑힘

---

A Comaparison of Issues and Advantages in Agile ~~

애자일과 Incremental 방법론은 Art Industry에 적용했을 때 경험한 장점과 단점 분석

 

Advantages in incremental agile development (state of the art)

• Better knowledge transfer due to better communication and frequent feedback from each iteration.
  각 iteration에서 잦은 피드백과 소통 덕분에 지식 전달 측면에서의 장점
• Customers are perceived by programmers as very valuable allowing developers to have discussions and get early feedback.
  고객과의 관계를 중요하게 여기기 때문에 개발자들은 함께 토론하고 초기 피드백을 받을 수 있다.
• Pair programming facilitates learning if partners are exchanged regularly.
  페어 프로그래밍은 파트너가 정기적으로 바뀐다면 학습을 용이하게 한다.
• Process control, transparency, and quality are increased through continuous integration and small manageable tasks.
  지속적인 통합 및 관리 가능한 소규모 작업들을 통해 프로세스 제어, 투명성, 품질이 향상된다.
• XP is very much technical-driven empowering engineers and thus increases their motivation.
  XP는 기술 주도적이고, 엔지니어들에게 권한을 주어 엔지니어들의 동기를 향상시킨다.
• Small teams and frequent face-to-face meetings (like planning game) improves cooperation and helps getting better insights in the development process.
  소규모 팀 + 빈번한 대면 미팅은 개발 과정에서의 협력을 개선하고 insight를 얻는데 도움을 준다.
• The social job environment is perceived as peaceful, trustful, responsible, and preserving quality of working life.
  사회적 직업 환경은 평화롭고, 신뢰할 수 있고, 책임감 있고 직장 생활의 질을 유지하는 것으로 인식된다.
• Customers appreciate active participation in projects as it allows them to control the project and development process and they are kept up to date.
  고객은 프로젝트 및 개발 프로세스를 제어할 수 있고, 프로젝트는 최신 상태로 유지되기 때문에 프로젝트에 적극 참여할 수 있다.
• Developers perceive the job environment as comfortable and they feel like working more productive using pair programming.
  개발자들은 작업 환경을 편안하게 인식하고, 페어 프로그래밍을 통해 생산적으로 작업하는 것처럼 느낀다.
• Student programmers perceive the quality of code higher using pair programming
  학생 프로그래머는 페어 프로그래밍을 통해 코드의 품질을 더 높일 수 있다.

 

Issues in incremental agile development (state of the art)

• Realizing continuous testing requires much effort as creating an integrated test environment is hard for different platforms and system dependencies.
  통합 테스트 환경을 구축하는 것은 플랫폼과 시스템 의존성이 달라 지속적인 테스트 실현에 어려움이 있다.
• Architectural design does not have enough focus in agile development leading to bad design decisions.
  architectural 설계는 애자일 개발에 충분히 초점을 맞추지 못해 잘못된 설계 결정을 일으킨다.
• Agile development does not scale well.
  애자일 개발은 큰 규모의 프로젝트에 적용하기 어렵다.
• Pair programming is perceived as exhaustive and inefficient.
  페어 프로그래밍은 exhaustive하고 비효율적이다.
• Team members need to be highly qualified to succeed using agile.
  애자일을 사용하여 성공하기 위해서는 팀원들이 유능해야 한다.
• Teams are highly coherent which means that the communication within the team works well, but interteam communication suffers.
  팀 내 의사소통을 잘 되지만, 팀 간 의사소통은 어렵다
• The empowerment of engineers makes managers afraid initially, and thus requires sufficient training of managers.
  엔지니어의 권한 부여는 관리자를 두렵게 할 수 있으므로 교육이 필요하다.
• Implementation starts very early, thus technical issues are raised too early from a management point of view.
  구현이 매우 일찍 시작되므로, 관리자의 관점에서 기술적 문제가 너무 일찍 제기된다.
• On-site customers have to commit for the whole development process which puts them under stress.
  현장 고객들은 전체 개발 과정을 위해 헌신해야 한다.
• From the perspective of students, pair programming is not applicable if one partner is much more experienced than the other.
  학생의 관점에서, 한 파트너가 다른 파트너보다 훨씬 경험이 많은 경우에는 페어 프로그래밍이 적용되지 않는다.

---

애자일 기법이 효과적으로 사용되기 위해서는 

• Empowerment and Trust: 개발팀을 신뢰하고 자율권을 줌
• 프로젝트의 관리나 개발자들의 인사고과에 대한 정책이 적절히 시행되어야 함

애자일 기법이 좋다고 추천하니 무조건적으로 적용하는 것은 바람직하지 않음.
애자일 기법이 익숙하지 않아서 무조건 사용하지 않는 것도 바람직하지 않음.

애자일 기법이 근본적으로 추구하는 것은 소프트웨어 개발에 관련된 모든 활동의 생산성을 극대화하는 것
추구하는 목표는 같아도 실천하는 방법은 조금씩 다를 수 있다.