[소프트웨어공학] 애자일 기법 이슈와 해결방안

대규모 시스템에 애자일 접근법 사용

• 대규모 시스템은 개발에 오랜 시간이 걸려서 몇 가지 문제점이 발생할 수 있다.
  1. 애자일 개발은 약식으로 진행
     → 큰 기업에서는 계약 사항을 정하기 위한 법적 방식과는 안 맞음
     
  2. 애자일 기법은 소프트웨어 유지보수보다 소프트웨어 개발 때가 적합
     → 큰 기업엣 발생하는 소프트웨어 비용은 대부분 기존 소프트웨어 시스템의 유지 보수 비용임
     
     
  3. 애자일 기법은 소규모이며 같은 장소에서 일하는 팀을 대상으로 고안
     → 요즘 소프트웨어 개발은 전 세계에 분산된 팀에서 이뤄지는 경우가 많음

 

 

 

 

 

계약 관련 이슈

• 애자일 기법 사용 시 발생하는 주요 문제
  • 소프트웨어 개발과 관련된 계약 (고객이 시스템 개발을 위해 외부 조직을 활용하는 경우)
  • 소프트웨어 요구사항 문서(고객과 공급자 사이에 발생하는 계약의 일부)
    
    
• 계약 시, 사용할 수 있는 요구사항 문서를 정의할 수 없음
  ← 요구사항과 코드를 동시에 겹쳐 개발하기 때문
  
  
  
• 애자일 기법은 시스템 개발에 필요한 시간에 대한 비용을 지급하는 것으로 계약해야 함
  • 문제가 발생하는 경우 책임소지와 비용 지불에 관련한 논쟁이 발생할 수 있음

 

 

 

 

 

소프트웨어 유지 보수

• 제품이나 앱의 새로운 릴리스는 애자일 접근법을 단순히 이어 나가는 것
  • 유지보수와 기존 소프트웨어 시스템 진화는 막대한 양의 소프트웨어 공학적 노력 필요
    
    
• 새로운 비즈니스 요구사항에 맞추어 변경해야 하는 경우 문제 발생 가능
  • 제품 문서 부족
  • 고객의 지속적인 참여
  • 개발팀의 연속성
    
    
• 고객 참여와 개발팀의 연속성을 유지하는 것도 문제

 

 

 

 

 

애자일과 계획 주도 방법

• 조직들은 각자의 문화와 업무 방식에 맞춰 애자일 기법 도입
  • 애자일 접근법의 가치와 이점을 알게 됨
  • 애자일 기본 원칙이 적용하기 어려운 경우 종종 발생
    
    
• 대규모 애자일 소프트웨어 개발 프로젝트
  → 계획 주도 접근법과 애자일 접근법을 묶어서 사용
  
  
• 계획 기반과 애자일 접근법 사이의 균형점을 정하려면 포괄적 범위에서 고민해야 함
  • 기술적, 인간적, 조직적인 질문
  • 개발하는 시스템, 개발하고 조달하는 개발팀, 조직과 관련된 질문
    
    
• 소프트웨어 시스템 구매자의 가장 중요한 관심사
  • 소프트웨어 시스템이 구매자의 욕구를 충족시키고, 유용한 것들을 해줄 수 있나?

 

 

 

 

 

애자일 원칙과 조직의 실무

• 고객 참여
  • 개발팀과 시간을 함께 할 의지가 있고, 모든 시스템 이해 당사자를 대표할 수 있는 고객을 확보해야 함
  • 규제 기관 같은 외부 이해 당사자들이 있는 경우에는 대표단이 그들의 견해를 팀에 전달하기 어렵다.
    
    
• 변화 수용
  • 이해 당사자가 많을수록 변경에 대한 우선순위를 정하는 것이 점점 더 어려워진다.
    ← 각각의 변경에 대해서 서로 다른 우선순위를 주기 때문
    
    
• 점증적 인도
  • 빠른 개발 반복과 단기 계획이 비즈니스 및 마케팅 장기 계획 주기와 항상 맞아떨어지는 것은 아니다
    → 마케팅 관리자가 캠페인을 효과적으로 준비하려면 수개월 전부터 제품의 기능을 파악할 필요가 있다.
    
    
• 단순성 유지
  • 제품 인도 일정에 대한 압박 때문에 팀 구성원들은 시스템 단순화 작업 시간이 부족하다.
    
    
• 프로세스가 아닌 사람
  • 팀 구성원들이 애자일 기법에서 요구하는 강도 높은 참여에 대해 적절한 인성을 갖추지 못해
    다른 팀 구성원들과의 상호작용이 이뤄지지 않을 수도 있다.

 

 

 

 

 

개발하는 시스템과 관련된 주요 이슈

• 개발하는 시스템은 얼마나 큰가?
  • 애자일 기법은 평상시에 의사소통이 가능한 상황에서 가장 효과적
    
    
• 어떠한 유형의 시스템을 개발하는가?
  • 구현 전에 분석이 많이 필요하고 상세한 설계가 필요하면 계획 주도 접근법이 적합
    
    
• 시스템의 예상 수명은?(장기 수명을 가지는 시스템인가?)
  • 개발자의 의도를 전달하기 위해 많은 설계 문서가 필요할 수도 있음
  • 최신 상황을 반영하지 못하며 유지보수에 거의 활용되지 않음
    
    
• 시스템이 외부 규제를 받아야 하는가?
  • 외부 감사인의 승인을 받아야 한다면 시스템 안전성 사례의 일부로 상세한 문서 작성

 

 

 

 

 

 

 

개발팀과 관련된 주요 이슈

• 개발팀에서 설계자와 프로그래머의 실력은?
  • 계획 기반 접근법에 비해 애자일 기법은 높은 수준의 숙련도 요구
    
    
• 개발팀의 구성은 어떻게 되는가?
  • 개발팀이 분산되어 있을 경우엔 의사소통을 위해 설계 문서가 필요할 수도 있음
    
    
• 시스템 개발을 지원하기 위해 어떤 기술이 가능한가?
  • 프로그램 가시화와 분석을 제대로 지원 못하면 더 많은 설계 문서가 필요할 수도 있음

 

 

 

 

 

 

문화와 관련된 이슈

• 매우 상세한 명세나 설계를 확보하는 것이 중요한가?
  • 요구 공학을 위해 계획 주도 접근법을 써야 할 수도 있음
  • 시스템 구현을 할 때에는 애자일 개발 지침을 따를 수도 있음
    
    
• 점증적 인도 전략이 현실적인가?
  • 고객 대표가 있는지, 그 대표가 팀에 합류할지?
    
    
• 시스템 개발에 영향을 줄 수 있는 문화적 문제가 있는지?
  • 전통적인 개발 조직은 계획 기반의 개발 문화를 가짐
    • 애자일 프로세스에서 사용하는 평상시의 지식보다는 많은 양의 설계 문서 작업이 필요

 

 

 

 

 

 

대규모 시스템을 위한 애자일 기법

• 여러 시스템이 모여서 이루어진 시스템
  • 각각의 팀이 개별 시스템 개발
  • 각 팀이 전체 시스템 보기는 불가능
  • 맡은 부분을 완료하는 데에 우선순위
    
    
• 브라운필드 시스템
  • 여러 기존 시스템을 포함시킨 후 상호작용을 통해 시스템을 구성
  • 대부분의 요구사항이 상호작용 관련
    • 요구사항에 유연성과 점증적 개발을 추가하지 않음
      
      
  • 기존 시스템을 바꾸는 것이 가장 좋은 해결책이 되는 경우가 많음
    
    
• 많은 시스템을 통합하여 하나의 시스템을 구축하는 경우
  • 본래 코드 개발보다는 시스템 환경 설정이 개발의 중요 부분
  • 반드시 점증적 개발과 잦은 시스템 통합을 고려해야 하는 것은 아님
    
    
• 외부 규칙이나 규정 때문에 제약을 받는 경우
  • 따라야 할 특정 준수 요구사항을 가지고 있을 수 있음
    • 프로젝트 문서화 완료 필요
      
      
  • 예) 특정 유형의 시스템 문서 작업을 작성
    
    
• 대규모 시스템을 조달하고 개발하는 경우
  • 많은 시간 필요 → 프로젝트 기간 동안 시스템에 대해 잘 아는 팀을 유지하기 어려움
    
    
• 서로 다른 관심과 목적을 가진 이해 당사자들
  • 모든 이해당사자를 개발 프로세스에 참여시키는 것은 불가능

 

 

 

 

 

 

 

애자일 스케일링 모델(IBM)

• 애자일 기법의 대규모 적용을 목적으로 함
  
  
  
• 규모 조정 단계
  • 핵심 애자일 개발: 기존 애자일 접근법
    
    
    
  • 체계적 애자일 인도:통제된 조직 설정을 위한 지침을 도입
    • 팀이 요구사항 및 아키텍처 설계 등의 소프트웨어 공학단계를 고려한다는 것을 인지하는 과정 포함
      
      
  • 규모에서의 민첩성: 대규모 프로젝트 고유의 복잡도를 가지는 스케일링에서 기민함을 얻는 것
    • 분산 개발, 복잡한 기존 환경과 규제 준수 요구사항 등을 고려

 

 

 

 

 

 

애자일 기법의 규모 조정을 위한 접근법

• 요구공학에 대한 완전한 점증적 접근은 불가능
  • 초기 소프트웨어 요구에 대한 어떤 초기 작업은 필수
    
    
• 단일 제품의 소유자나 고객 대표는 있을 수 없음
  • 다양한 사람들이 시스템의 여러 부분들과 관련
  • 개발 프로세스를 거치는 동안 지속적으로 의사소통과 협상 필요
    
    
• 시스템의 코드에만 집중하는 것은 불가능
  • 선행 설계를 더 많이 하고 시스템 문서도 작성할 필요 있음
  • 중요한 관점을 설명하는 문서 작성 필요
    
    
• 팀 사이의 의사소통 체계를 설계하고 사용해야 한다.
  • 다양한 의사소통 체계를 설계하고 사용해야 한다. (전화, 화상회의, 전자우편, 메시지, 위키)
    
    
• 변경을 가할 때마다 전체 시스템을 빌드하는 지속적 통합은 불가능
  • 여러 개의 분할된 프로그램을 통합하여 시스템을 만들어야 하는 경우
  • 자주 시스템을 빌드해서 정기적 릴리스를 관리하는 것은 필수
  • 여러 팀이 소프트웨어를 개발하도록 지원하는 형상 관리 도구도 꼭 필요

 

 

 

 

 

 

대규모 기업들이 애자일 기법을 쓰기 어려운 이유

• 경험이 부족한 프로젝트 관리자
  • 애자일 기법이 개별 프로젝트에 어떤 영향일 미칠지 알 수 없음
  • 새로운 위험 감수 x
    
    
• 대규모 조직의 관료적인 속성
  • 대규모 조직은 준수해야 하는 절차와 표준이 있음
  • 소프트웨어 도구를 통해 절차와 지원 표준화를 하기도 함
    
    
• 실력 부족한 사람들
  • 애자일 프로세스에서 효과적인 팀 구성원으로 활동하기 어려움
    
    
• 문화적 저항
  • 전통적인 시스템 공학 프로세스를 오랜 기간 사용해 온 조직

 

 

 

 

 

 

애자일 기법과 병행하기 어려운 기업 절차

• 변경 관리
  • 변경의 방향을 예측하고 비용을 통제하기 위해 시스템에서
    발생하던 변경사항을 제어하는 프로세스
    
    
    
  • 변경 전에 모든 변경 사항들을 미리 승인받아야 함
    → 리팩토링의 개념과 상충
    
    
• 테스팅 절차
  • 대규모 시스템의 경우 시스템 빌드를 외부 테스팅 팀에 전달
    → 테스트 우선 접근법과 상충

 

 

 

 

 

 

애자일 도입은 일종의 문화적 변화 과정

• 문화적 변경
  • 구축하는데 장시간 걸림
  • 경영의 변화가 필요한 경우도 자주 발생
    
    
• 변경 촉진을 위한 에반젤리스트가 필요
  • 기업들은 열정적인 개발자 그룹으로부터 애자일 기법을 하나씩 적용하는 것이 시작이라고 생각
  • 성공적인 애자일 프로젝트에 참여했던 팀이 애자일 기법을 조직에 퍼뜨려야 함
    
    
• 애자일이라는 개념이 널리 알려지면 애자일 기법을 조직 전체에 퍼뜨리기 위한 활동 수행 가능