소프트웨어 공학 - 요약 #3

---

애자일(Agile) 프로세스

• 이 시대에는 큰 프로젝트는 많지 않고 소형 중형이 많음 → 큰 프로젝트를 위한 통합 프로세스나 폭포수 모델, 나선형 모델은 문서 중심이기 때문에 옳지 않음
• 폭포수 모델 단점의 극단적인 해결방법
• 절차나 문서 규칙도 중요하지만 개인과의 소통을 제일 중요시함
• 잘 쓴 문서보다 잘 실행되는 소프트웨어에 더 가치를 둠
• 계획을 따라 하는 것보다 어차피 고객들은 변덕스러우니 변경에 잘 대응하는 것이 더 중요함
• 객체지향처럼 개발하려고 하는 시스템이 어떤 경우에 어떤 목적(사용사례)으로, 어떤 목적으로, 어떻게 사용자가 사용하는지에 대한 스토리를 뽑아놓고 그걸 단위로 진행(또는 피쳐 단위)
• 테스트 중심 개발 : 사례나 스토리 작성 시 테스트 시나리오 함께 작성
• 대규모 프로젝트를 하더라도 옛날처럼 한 곳에 모여서 하는게 아님
• 이해관계자도 돈을 주는 사람 한명만 있는 것이 아님
• 중소규모에 엄격한 개발 모형을 적용할 때에는 오버헤드가 너무 크고 고객도 너무 답답함 → 빠른 인도 불가능
• 점진적 개발, 빠른 인도, 고객 참여, 변경의 유연한 수용 필요
• 반복-점진 모델에 기반을 둔 새로운 접근법
• 애자일 연합체는 일련의 근본적인 원칙을 세움
• Extream Programming(XP), Scrum, Crystal 등 다양한 기법 존재

1. 어떤 것을 개발할지 스토리 추출 : 각 스토리의 기간과 비용 예측, 먼저 빌드할 스토리(우선 순위) 선택, 각 빌드는 여러 태스크로 나눔, 태스크들에 대한 테스트 케이스 선정
2. 짝 프로그래밍 : 두 명이서 매 순간 앉아서 코딩
3. 태스크의 계속적인 통합

• 애자일 프로세스는 분석과 설계에 대해 크게 강조하지 않음
• 빠른 구현을 통해 돌아가는 소프트웨어를 만듦
• 변경에 대한 응답도 빠르게 진행
• 클라이언트와 더 밀접한 협업 진행

---

1. Manifesto에서의 원칙

• 작동하는 소프트웨어를 자주 인도
• 이상적으로 2~3주 마다 작동하는 것을 보여줘야 함(극단적으로는 일주일, 하루 단위일 수도 있음)
• 그러므로 고객과의 소통이 제일 중요

2. 달성된 방법 중 하나는 타임박싱

• 고정된 시간 / 고정되지 않은 개발 기능
• 시간은 고정하고 그 안에 들어가는 일의 양은 고정하지 않겠다는 것
• 시간의 명시된 양은 작업 양을 설정(실제 작업량은 바뀔수 있음)
• 일반적으로 각 반복은 2~3주
• 그 다음 팀 멤버들은 해당 시간 동안에 할 수 있는 최적의 업무를 수행
• 애자일 프로세스의 장점 : 클라이언트들이 좋아함
• 클라이언트들은 추가적인 기능을 가진 새로운 버전이 2~3주마다 인도된다는 것을 알고 신뢰감을 갖게 됨
• 개발자들은 어떤 종류의 클라이언트 간섭 없이 2~3주간 새로운 반복을 인도해야 한다는 것을 알게 됨
• 만약 타임 박스 안에 전체 태스크를 완료하는 것이 불가능하다면, 작업은 줄어들 것 → 애자일 프로세스는 고정된 시간과 고정되지 않은 기능

3. 애자일 프로세스의 또 다른 공통적인 특성은 스탠드-업 회의

• 일의 진행이 되지 않을 때 회의 진행
• 매일 규칙적인 시간에 간략한 회의를 가짐
• 모든 팀 멤버는 회의에 참석해야 함
• 스탠드업 회의 미팅에서 각 팀 멤버는 돌아가면서 아래와 같은 다섯가지 질문에 답변

1. 어제 회의 이후에 한 일은 무엇인가?
2. 오늘은 무슨 일을 할 것인가?
3. 그 일을 달성하는데 내가 예방해야 하는 문제는 무엇인가?
4. 우리가 잊어버린 것은 무엇인가?
5. 팀과 함께 공유하고 싶은 교훈은 무엇인가?

• 스탠드업 회의의 목적은 문제를 제기하는 것
• 그 팀의 관리자가 문제를 분석하여 곧바로 관계자들만 불러서 후속 회의 진행(그것들을 해결하는 것 아님) → 더욱 시간 절약 가능
• 스탠드업 회의, 타임박싱, 짝 프로그래밍 등은 애자일 프로세스에 깔린 공통의 원칙 
• 커뮤니케이션을 늘리고, 클라이언트의 요구를 가능한 한 빨리 만족시키기 위함

---

애자일 프로세스의 결론

1. 클라이언트의 요구사항들이 모호할 때, 소규모 소프트웨어를 구축할 때 유용한 접근법(소규모 소프트웨어에서는 성공사례 많음)
2. 그러나 중간이자 대규모 소프트웨어는 완전히 다르기 때문에 이에 사용될 수 있음을 의미하지는 않음
3. 프로세스의 몇몇 좋은 특성들은 다른 생명주기 모델에 효과적으로 이용될 수 있음

---

XP 기법

1. 매일 빌드와 통합
2. 테스트 주도 개발
3. 사용자 스토리
4. 짝 프로그래밍

스크럼(Scrum)

1. 개발 직원 모두가 함께 소통하고 협력하여 짧은 주기를 반복하며 소프트웨어를 개발하는 작업, 역할, 결과물
2. 백로그(Backlog)를 정하고 여기에 우선순위를 부여
3. 짧은 주기(스프린트)

---