2019년 2학기 고려대학교 차성덕 교수님 소프트웨어 공학
개념과 특징
Wikipedia에서는 애자일 소프트웨어 개발에 대해서 아래와 같이 설명한다.
애자일 소프트웨어 개발(Agile software development) 혹은 애자일 개발 프로세스는 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이다.
애자일 개발 방법론은 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나간다. 다른 고전적인 방법론과 구별되는 가장 큰 차이점은 less document-oriented, 즉 문서를 통한 개발 방법이 아니라, code-oriented, 실질적인 코딩을 통한 방법론이라는 점이다.
애자일 방법론의 대표적인 특징은 다음과 같다
- Daily Standup
- Short iterations
- Prioritized backlogs
- Iteration planning
- Retros
추가적인 설명은 다음과 같다.
- 프로세스나 도구보다는 개인과의 상호 작용을 중시한다.
- 회의는 5–10분 정도로 짧게 진행한다(daily standup meeting). 이를 위해 인원은 10명 이하가 적당하다.
- 고객으로부터 피드백을 자주 받는다. 그렇기에 사용자가 원하는 결과물을 만들 수 있고 변경도 덜할 수 있다.
- 동기 부여가 잘된 팀에게 효과적이다. 회의에서 잘하는 사람은 스스로 일을 선택할 수 있지만 비교적 경험이 부족한 사람은 회의에 참석하는 자체가 고역이 될 수도 있다.
전통적인 모델과의 비교
페어프로그래밍
페어프로그래밍은 애자일 대표적인 기법 중 하나이다. 경험이 부족한 사람에게는 많은 도움이 될 수 있으나 경험이 많은 사람에게는 별로 도움이 안될 수도 있다. 그럼에도 불구하고 페어프로그래밍을 하는 이유는 핵심적 목표가 프로그래밍의 오류 최대한 빨리 찾고 싶기 때문이다. 다른 사람 눈에는 나에게는 안보이는 오류가 잘 보일 수 있다.
해당 표는 페어 프로그래밍의 효과 정도를 나타낸다.
경험이 없는 사람끼리(Junior-junior) 하면 effort가 32 늘어나고, 경험 많은 사람끼리(Senior-senior) 하면 effort가 줄어들수 있다 등의 내용을 알수 있다.
애자일의 위험(Agile Pitfalls)
Agile anti-patterns나 agile smells라고 불리기도 하는 것들에는 아래와 같은 사항들이 있다.
- 전반적인 프로젝트 디자인 결여 — 눈 앞에 닥친 사항부터 먼저 신경 쓰기 때문에 전반적인 계획의 우선순위가 높지 않을 수도 있다. 전반적인 부분에서 중요한 부분에 대해 신경을 덜 쓸 수도 있다.
- 훈련/교육 부족— 트레이닝이 쉽지 않을 수도 있기 때문에 애자일에 참여하는 사람들이 능력이 모두 좋아야 효율이 좋다.
- 완성하기 위해 technical debt 허용
애자일이 실패하는 이유
- 회사 문화가 애자일의 가치와 맞지 않음 — 애자일의 초기 결과물의 성과는 안좋을 수도 있는데 그것 때문에 인사고과에 영향을 받는다던가.. 이러한 이유로 애자일이 스타트업에서 더 잘 맞을 수도 있다.
- 애자일 기법에 대한 경험 부족
- 운영 지원 부족 — 애자일에 관심있는 사람들의 스터디나 학회 모임 등을 지원해주고 리스크가 적은 프로젝트를 맡겨서 실행 해볼 수 있게 하는 등의 지원이 필요하다.
스크럼 (Scrum)
스크럼은 애자일 개발 프로세스로 불리는 개발 방법론 중 하나이다. 30일마다 동작 가능한 제품을 제공하는 스프린트(Sprint)를 중심으로 하고 있다. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다.
Agile Challenges
People Challenges
📌 중간고사 pick : 이 중 다른 것 보다 중요한 것 2가지 선택하고 그 이유와 구체적인 해결방안 2가지 제시
- 스킬이 부족한게 투명하게 드러날 수 있다.
- 담당 영역이 정해지지 않을 가능성이 높으므로 모든 영역에서 뛰어나야한다.
- 기술 스킬보다 소셜 스킬이 더 중요할 수도 있다.
- 그냥 하는 것이 아닌 그 속에서 애자일의 가치를 배울 수 있어야 한다.
- 정량적 목표(MBO)를 달성하기 어려울 수도 있다.
방법론에 따른 회사 규모 & 예산 & criticality & 팀 규모
‘연간 수익 1B가 넘는 큰 프로젝트에서는 전통적인 방법을 가장 많이 쓰는구나’ 등을 읽을 수 있다.
여기서 criticality는 자율 주행 등에서 인명적으로 사고날 수 있는 확률을 말한다.
생각해볼점
- 애자일의 개념과 장점
- 워터폴의 개념과 장점
- 애자일 기법 중에 몇가지가 있는데(ex. pair programming, TDD) 그것을 왜 할까, 장점은 뭘까 생각해보기. — 만약 정말 효과적이고 획기적이라면 모든 개발이 페어프로그래밍 하면 되는데, 왜 굳이 안하는 회사도 많을까
- 위의 Pair Programming Experience 표 보고 페어프로그래밍 언제 추천하겠냐, 추천 한다면 그 이유 말할 수 있어야
- 위에서 나타난 애자일의 위험(리스트) 줄이려면 어떻게 할 수 있을까
- technical debt가 생기는 흔한 10가지 이유 중 이것들을 줄이기 위해 무엇을 할 수 있을까 생각
- 방법론에 따른 회사 규모 & 예산 & criticality & 팀 규모 등의 표를 읽고 해석을 통해 가장 중요한 메시지 2가지를 생각
