[10분 테코톡] 라이언의 애자일

라이언의 애자일
https://www.youtube.com/watch?v=3y5rCRys4t0

>> Agile Software Development
     (iteration with the customer) - iteration 단어 기억

- 소프트웨어 개발 프로세스는 어디서부터 왔는가
   - 퀄리티 컨트롤(백그라운드 이야기) - product-centric(제품중심적인 관점) 
                                                    - process-centric(과정중심적인 관점)
      : 흔히 아는 소프트웨어 개발과정은 Process-centric 방식
        >> 즉, 프로세스 중심의 개발 과정
      : 옛날 제조업계 퀄리티 컨트롤 == product-centric(상품 중심적인 방법론) 방식
        > 주기적으로 상품의 아웃풋을 테스트
        > 필요하면 공장에 수정할 부분 요청 >> 제품 발전 도모
        >> 이 때의 문제점
           ex ) 자동차에 문제가 생기게 되면? 
                   > 그냥 폐기.. 돈이 많이 듦
                   > 자동차를 부품 별로 쪼개서 하나씩 테스트하면?
                          -> 자동차를 통으로 버릴 일은 없음

        > 그래서 20세기 중반부터는 제조 퀄리티를 보장하기 위해
               >> Process-centric(과정 중심적인) 방법 채택
                    : 예전과 같이 제품에 대한 아웃풋을 테스트
                    : 과정 중에 있는 요소들을 측정
                           ex ) 계획에 문제가 존재하는지 확인
                                 일하는 사람들의 업무 여건 체크(지각 체크)
                                 적합한 공구를 사용하는지 체크
                    : cause and effect model(원인과 결과 모델)을 사용
                       > 과정 중에 변경할게 있으면 반영
                    : 통계치를 이용해서 변화에 대해서 정밀하게 추적

  >> 소프트웨어 개발에서는? - 이러한 레거시 상속
       - 통계를 사용, Process - centric(과정 중심적) 방법론을 선택
          >> 과정이란? 
               : 어떻게 무엇을 만들었는지를 의미
                    - 주어진 시간 내에, 예산에 맞게, 결함없이 고객이 원하는 것 전달하는 과정
 
  >> 소프트웨어 개발 과정 3 단계
   - Planning(계획)
       : 어떻게 할 것인가
       : 언제 할 것인가
       : 무엇을 할 것인가 
      >> 계획 실행

   - Execution(실행) 
       : 계속 검증
       : 계획이 있으면 계획대로 가고 있나 알 수 있음(25%를 했나 10%를 더 해야하나)

   - Measurement(검증) - Statistical Process Control 
       : 서비스를 검증하기도 하지만 과정을 계속 검증
       : 버그가 얼마나 많이 나오나
       : 과정은 어떤가
       : 얼마나 걸리나
       : 기능이 클라이언트에게 적합한가
      >> 계속 검증 + 문제 발생 시 수정
   
     > 키워드 Statistical Process Control 
        : 통계 베이스의 과정 제어
       ex ) 전날 20분 잡아놨던 데일리 미팅 존재
              > 10분이 소요
            >> 다음 날은 데일리 미팅을 10분으로 잡음
       >> 과거에 있었던 통계를 바탕으로 현재 과정에 수정을 주는 것
           : 측정하고 수정하는 과정

  - 에자일 개발 방법론
   >> 많은 리소스를 Head first software development 책에서 발췌

  - 애자일은 무언인가? 
     >> 가장 중요한 개념 : iteration
     ex ) 프로젝트를 할 때 
           데모데이에 따라 스프린트1, 스프린트2 로 나눔
           > 이때 이런 스프린트들이 각각의 iteration이라고 생각하면 됨

- 간단한 퀴즈!
    >> Iteration을 가짐으로서 얻는 이득은?
       1. 코드를 빨리 쓸 수 있다
       2. 테스트를 빈번하게 돌려 버그를 더 많이 찾을 수 있다
       3. 변화하는 조건에 대해 바로 적응할 수 있다.
   정답 : 3번
     애자일의 전부는 adaptation, "적응"
     1번이 정답이 아닌 이유 : 애자일 프로세스 사용 시 더 느려짐
          >> measuring & delivering 많이 사용 == 시간적으로 더 오래 소요
      >> 처음에는 느리지만 점차 빨라지는 것이 애자일
          ? 소비자의 니즈를 더 빨리 적응하기 때문
     2번이 정답이 아닌 이유 : 테스트를 많이 한다고 버그를 더 찾을 수 있지는 않음
                                        버그를 빨리 찾음으로써 오히려 버그를 덜 찾음 

      >> 애자일 개발 방법론은 계획을 통해서 주도해 나갔던 과거의 방법론과는 다르게
            예측하며 개발을 하지 않고 일정한 주기를 가지고 끊임없이 프로토 타입을 만듦.
            + 그때그때 필요한 요구 추가 및 수정
            >> 하나의 커다란 소프트웨어 개발해 나가는 adaptive style
   
   >> 프로젝트를 자주 release하면 좋은가?
       - 오히려 시간이 더 오래 걸림
           > 소비자와 자주 소통해서 release를 적게 하는 것,
              adaptive하게 그때 그때 요구를 받고 프로젝트를 발전
       >> 이것이 "애자일"

     < 기억해 놓으며 >
    >> 애자일 = "동그란" 사이클
         워터폴 = "계단 같은 폭포"
 
>> 소비자와 어떤 것들을 함께 정하고 프로젝트를 시작하는가
  1. 요구사항 또는 기능들에 대한 리스트 
  2. 예산 
  3. 데드라인

    > Iron Triangle(Project Management Triangle)
        >> Fast(속도), Good(퀄리티), cheap(비용) : 두 개만 선택 
          : 계획을 수립할 때, 
            엔지니어적 측면에서 "빠르고 좋으면서 싸게" 세 개다 가져가는 것은 불가
          > 속도와 비용을 선택 - 퀄리티 하향
          > 속도와 퀄리티를 선택 - 비용 증가
          > 비용과 퀄리티를 선택 - 속도 느림
   >> 이 것들을 감안하면서 계획 수립
    
    ex ) 앞의 슬라이드처럼 잘 짰다고 가정
      빅뱅(aka Waterfall)모델에서 어떤 과정으로 개발이 이루어지나
       > customer와 대화 -> "일하러 가! 2년 뒤에 확인하도록 하지"
           >> 2년 뒤에 목표했던 것과는 다른 엉뚱한 제품 탄생...
                >> 소비자는 비즈니스를 운영하면서
                     첫 대화에서 생각했던 것과는 달리 계속 원하는 것이 발전
                     >> "원하던 제품이 아닌데.. 1년 더 줄테니 다시 해주세요"

                >> 개발자가 상상한 것
                     >> 어느정도 목표를 달성해 놓고 약간의 피드백을 받아 목표한 것을 완성

 >> 애자일한 방법론을 사용해서 나타내면?
    > 가장 현실적인 것은 직선으로 목표치로 이동  - 하지만 현실은 그렇지 않음
      1. 소비자가 원하는 것을 기능에 맞춰서 알아내기(요구사항 파악)
      2. 빠르게 데모를 만들어서 생각 묻기(빠른 데모)
      3. 소비자는 기능에 대한 생각을 바꿈(수정 사항 반영)
            > iteration을 통해 알아냈기에 조금만 수정하고 다시 진행
      4. 개발자의 잘못된 선택을 갈 수도 있음(잘못된 선택)
            > iteration을 가지기 때문에 목표한 path에는 벗어나지 않음
      5. 소비자가 원하는 것과 지금하는 것이 일치(생각 일치)
            > 제대로 한다는 확신 성립
      6. 계속 iteration을 가지면 목표한 것 성립(keep iterate + payday)
   >> iteration?
        : 개발중인 소프트웨어에 대해서 자주 체크하는 것
          > 방향성이 옳은지 체크

 - Bigbang 방법(Waterfall) 방법 - 오랜기간 요구사항 수집 + 디자인 
                                           오랜기간 코드짜고 테스트
   >> measurement point
        : 진행 상황을 체크하는 순간이 네 군데 존재.
            > 하지만 이 요구사항이 제대로 작성되었는지 어떻게 확인하는가?
            > 엄청 긴 글로 된 요구사항만 보고 판단 가능한가?
            > 변동된 일이 없을까?
            > 디자인은 어떻게 판단하는가? - 추상적일 것
            > 코드 작성해보면 될 것
                  >> 하지만 이 때는 벌써 예상한 기간의 3/4이상 온 상황
                          >> 제대로 된 measurement point는 마지막 한 곳 뿐
                                : 돈도 다 쓰고 시간도 다 쓴 상황에서 
                                  원하는 상품은 나오지 않음
 >> 책에서는 "미니 프로젝트를 계속해서 하자"
 - 에자일 방식, iteration 방식
   >> 기능에 대한 계속된 measurement point를 받을 수 있음
        + 계속해서 변경사항 반영 가능
      >> 한 번의 기능검증이 아닌 다섯 번의 기능 검증이 가능

- measurement point?
   무엇을 measure?
      > 개발하는 도중 여기서 잘못되면 큰일난다는 촉 존재
   >> 이런 것들을 측정 == RISKS 라고 한다
      : 소프트웨어 엔지니어링 + 리스크 관리 = 뗄 수 없는 관계
      > 중요한 것을 할 때는 항상 리스크 수반
  > Upside risk(상방향 리스크) 
      : 긍정적인 결과의 불확실성

  > Downside risk(하방향 리스크)
     : 부정적인 결과의 불확실성

>> 소프트웨어 엔지니어링에서는
   Upside risk 최대화
   Downside risk 최소화
                   두 가지를 중요하게 생각
 
>> Risk라는 단어가 왜 나왔는가?
   : 소비자를 가장 중요한 리스크
    > 잘못 이해하는 경우, 소비자가 원치 않는 방향으로 개발
    > 소비자의 마음 체인지
    > 다른 사업을 한다고도 함
         - 경쟁자 발생, 법이 바뀜, 등...

 >>>> 그래서 자주 확인!
              adaptive하게 그때그때 요구 받아들여서 프로젝트를 발전시키는 방법
    >> 에자일 방법이 중요하다!!!