마틴 파울러 - The State of Agile Software in 2018 Methodoloy

1. Essentially contested concept, Semantic Diffusion 

어떤식으로 표현하건 애자일 이란 용어는

개인의 지식, 경험, 믿음을 수반하는 단어가 되었다


2. faux-agile

이름뿐이고 기법과 가치가 없는 애자일 흉내 보다 최악인 행태. 

기본 원리에 상반되지만 애자일 이란 이름이 가치 판단의 도구로 사용됨. 

애자일 이 들어간 컨퍼런스에 참여하고 애자일 이 들어간 기법이면 옳은것으로 판단


3. 프레드릭 테일러와의 대척점

테일러는 작업을 하는 사람들(어리석은)이 방법을 결정해서는 안된다는 것.

그 반대지점이 스스로 작업 수행 방법을 결정해야한다는 주장

따라서 이 가치를 믿는다면 나에게 필요한 것이 무엇인지 알아내고 발견해야 한다


4. 참사를 넘어선 우스꽝스러움

각자 상황이 다르고 레거시 환경이 다르며

팀 개인마다 역학이 달라 많은 차이점이 있기 때문에

모든 사람에게 효과가 있는 한 가지 방법이 없다는 것은 너무도 자명하다

하지만 애자일 산업단지에서는

그러한 것이 존재하고 따라야 한다고 공포를 퍼뜨린다

(작업을 수행하는 사람이 방법을 결정하는 것이 아닌

(애자일 산업단지/컨설턴트가 공언한 것을 따라야 한다는 테일러식 사고


5. 책/유명인/컨설턴트가 공언한 것과 배치되는 경우 어떻게?

팀이 애자일 책에서 말하는 방식을

원치 않거나하거나 환경이 맞지 않으면

애자일 컨설턴트들이 말하는 방법들을 무시하는 것이 가장 애자일한 방법이다


덧붙인 이미지.

Democratic이 들어간 나라들은 민주주의와 거리가 멀고 

Kingdom이 들어간 나라는 보다 더 민주적인 나라

발표자가 재미로 넣은 자료지만 나름 시사점이 있다






테스터를 QA라 부르는 현상. Methodoloy

테스터와 QA는 다르다. 
- 테스트(quality control - after the fact) 
- QA(quality assurance - built into the product)
용어의 오용에서 기인하는 문제에 대해 생각해 볼 부분이 있다.

1. 팀 업무, 정체성 혼동
팀 명칭을 틀린 용어로 사용하는건
팀 업무와 정체성에 대해서 틀리게 혹은 다르게 인식하고 있다는 증거다


2. "품질 = 결과 확인"이란 잘못된 인식 강화
다른 말로 '과정은 품질과 별개'란 인식이 강화된다
우린 과정만 통제할 수 있다. 품질 향상은 과정의 향상을 통해 획득된다
따라서 결과물의 품질을 향상 시키려는 QA는 과정에 많은 리소스를 할애한다
조직이 과정을 품질관리 대상으로 인식하지 못하면 품질을 좌우하는 근본적인 부분을 놓치게 된다


3. 테스트 이전 활동에 대한 품질인식 저하
테스트를 품질로 동일시 하는 조직에선 테스트 이전 활동에 대한 품질 인식이 낮다.

소프트웨어 엔지니어링에 상식적인 것들이 있다
- 구축 완료 후 테스트는 제품 품질에 영향을 주는 일부 요소, seguetech
- 결함 제거 비용, 설계(x1), 구현(x6.5), 테스트(x15), 운영(x100), ibm sci
- 첫 테스트 케이스를 실행하기 전에 리뷰를 통해 오류의 90%까지 제거 가능, IEEE 2001
- 오류의 대부분은 요구사항 및 설계단계의 오류로 전체 결함 비용의 64%, journal of dse

품질향상 비용 효과성은 테스트 이전 활동들이 높다. 상식이다

그래서 QA는 테스트 이전의 프로세스와 프로덕트 품질 개선 활동들을 활발히 진행한다.
하지만 이름만 QA인 테스트팀을 가진 조직에선
이러한 활동을 수행하거나 관심을 갖긴 커녕 인식 조차 없다
품질을 결과확인으로 바라보는 의식이 조직에 굳게 자리잡았기 때문이다.


4. 정체되는 조직
소프트웨어 개발 조직의 성숙도를 알아볼 수 있는 CMMI란 성숙도 모델이 있다
여기서 PPQA(프로세스와 제품 품질보증)와 MA(측정과 분석)란
프로세스 영역은 성숙도 레벨 2(managed - 관리가 존재하는 조직)에서 등장한다

이것을 풀어 말하자면 관리되고 향상되는 조직은 
제품, 과정, 과정을 좌우하는 요소들에 대해서 점검, 측정, 분석, 개선하는 태스크들을
조직 차원에서 롤, 직무, 프로세스로 명시하고 수행하며 관찰/개선이 이루어진다는 의미다
조직에 이러한 부분이 없다면 CMMI 레벨1, 개인역량이 전부인 조직이라 할 수 있다

QA란 이름의 테스트팀을 가진 조직에선 팀 롤이 테스트로 규정되었기 때문에
프로세스 품질과 프로덕트 품질 영역이 공란으로 남겨지기 마련이다
그렇게 품질 향상의 근간이 되는 PPQA, MA 영역이 방치된다. 

그래서 이러한 조직은 공식적인 롤, 권한, 직무가 없기 때문에
대개 조직의 자산이 빈약하고, 프로세스와 기법이 낙후되어 있다
후진적 기법, 프로세스에 허덕이며 무엇이 문제인지 모르는 사태를 겪기 쉽다
문제는 조직이 대격변을 겪지 않는 이상 조직의 현상은 유지되고, 후진성 또한 지속된다는 점이다

측정하고 향상해야 할 부분은 언제까지고 개인 성향과 능력에 좌우되고
조직의 지식과 자산으로 누적되고 향상되어야 할 부분은 계속 공란으로 유지된다
역량이 뛰어난 개인이 있어도 직무, 성과와 무관하므로 조직에 쌓이지 않고 소실되기 쉽다.
그렇게 조직은 정체된다.
(self organized란 이름의 조직들이 스스로 기법을 개선하거나 도출하지 못하고
(유행이 휘몰아칠때까지 현상을 그대로 유지하고 정체되는 이유를 생각해 보자


5. 쓸모없는 QA팀
개발자나 관리자의 리소스 낭비를 막기 위한 지원이 주 업무인 QA팀들이 있다.
결과 확인과 리포트가 주 업무로 테스트 작성, 관리, 진행, 확인, 보고, 사업관리 지원을 한다.

정체성이 리소스 낭비를 막기 위한 팀인 경우
개발 전문성, 관리 전문성이 없으면서 현상/결과를 보고하다 보니
개발팀과 관리팀 입장에서 반갑지 않은 팀, 무능의 아이콘으로 취급되기 쉽다

과정에 어떠한 도움도 없이 결과만으로 현상을 해석하려 하고
리소스 절약을 위한 롤인데도 리소스를 크게 증가시키는 피드백을 하니
일을 하는 사람들은 달가워 하지도 않고 크게 필요로 하지도 않는다

그래서 QA란 이름의 테스터, 지원 인력들은 무능하다는 평가를 듣고
시간이 지나도 전문성이 생기지도 않고 커리어가 나아지지 않는다
그렇게 이름만 QA인 팀은 스스로의 정체성, 미래, 업무에 대해 고민하곤 한다
(연 수백~천억 이상 매출을 올리는 대기업들의 QA팀도 그러한 경우를 본다


결론, 테스트팀은 테스트팀이라고 호칭하면 된다.
QA라 칭하는 테스트팀도 그러한 팀을 가진 회사도 
몇 분 시간을 내서 위키에서 QA항목을 읽어봤으면 좋겠다.


## 잡다 ##

- 테스트가 중요치 않다는게 아니다. 테스트는 테스트고 QA는 QA다.

QA 채용공고에 필요역량으로 테스트 케이스 작성, 테스트 수행, ISQTB.. 
  이런 것들이 적혀있다. 테스터 채용이 맞다.

- 프로젝트에서 QA가 하는 일을 적어보면 테스트와 다름을 알 수 있다.
  QA는 프로젝트 계획을 돕고 개발/관리 프로세스와 기법을 정의, 가이드, 교육, 개선한다
  (진척, 소통, 관리 대상, 이슈, 위험, 형상을 규정하고 관리하는 방법을 정의한다
  (수행사의 개발/관리 프로세스를 수용하는 유형별 개발 프로세스
  (요구, 분석, 설계, 이행 기법, 절차, 산출물, 샘플, 가이드, 체크리스트를 제공하고 교육한다
  (분석하거나 설계할 때 도움이 필요한 인력, 팀에 도움을 준다. 기법을 개선한다
  활동과 결과를 측정, 분석, 모니터링, 통제하고 결과가 기대와 일치하는지 확인한다
  관련, 문제 발생시 대안을 제시한다. 위험/이슈 완화 계획 수립에 참가한다.
  (맨먼스 미신에서 언급되는 상황 - "지체되는 프로젝트에 개발인력을 더하는건 의미가 없다"
  (이런 상황에서 무얼 어떻게 해야 하는지 아이디어, 해법을 제공하는 것도 QA다
  (개발/관리 프로세스 정의 책임이 있기 때문에 그러한 활동을 한다.

- 레거시에 기능을 덧붙여 나갈때 겪는 어려움을
 기법과 조직 차원에서 해결책을 개발자와 함께 만들어 가는 것도 QA다
 보통 개발조직에선 이걸 개인의 윤리, 프로의식으로 취급하지만 그렇게 다루어질 건이 아니다
 (레거시에 기능을 덧붙이거나 차츰 리팩토링해가며 개선해 나가는 작업이 쉬웠으면
 (애초에 프로젝트가 발생할 일이 생기질 않는다. 개인 차원의 문제가 아니다
 



도메인 모델은 유용할까? Methodoloy

도메인 모델은 두가지 관점에서 유용하다.
1. 설계를 이끌어 가는 도구.
2. 정보와 지식을 집약시켜 문제영역을 학습/소통/향상 시키기 위한 도구.

첫째, 설계를 이끌어 가는 도구로 무엇이 유용할까?
비즈니스 프로세스(유스케이스, 동적관점)  ㄱ
도메인 모델(정적 관점)                                - + 책임할당(GRASP) - 정제 - 설계 모델 + 구현
위 접근은 과거 객체지향 기법들이 취하는 익숙한 방식이다.
유엠엘 컴포넌트, 유니파이드 프로세스, 도메인주도설계 모두 큰 틀에서 동일하다.

thing, 엔터티로 부터 개념 클래스 후보를 마련하고
각각의 유스케이스와 시스템간 상호작용을 도출한 뒤 개념 클래스에 할당하고
클래스간 협력관계를 보고 전체 구조에 일관성을 더하기 위해 병합/분리 하는 식으로 설계해 나간다.

과거엔 도메인 모델이란 용어는 개념의 정적관계를 나타내는 용어였고
데이터 모델, 설계, 용어집의 근간이며, 개념 설계와 책임 할당의 근간으로 유용했다.
현재 도메인 모델이란 용어는 정적관계 표현 ~ 설계모델 까지를 모두 포함하는 용어로 두루 쓰인다.


둘째, 문제영역을 학습, 소통하기 위한 도구로 유용할까?

초기 도메인 모델은 문제영역의 개념들을 소개한다.
정제된 도메인 모델은 문제영역을 소프트웨어로 해결하기 위한 
개념간의 관계, 개념묶음들간의 관계, 정책을 기술한다. 정적인 관점을 대변한다.
그렇다면 동적인 정보는 도메인 모델 어디에 담길까? 당연한 얘기지만 담기지 않는다.
(단순 도메인 모델이건 행위를 표현한 풍부한 도메인 모델이건 정적인 관점이다.
(간단히 예를들어 보자. 입금 흐름이 도메인 모델에 표현될까?

도메인 모델의 존재 이유에 해당하는
비즈니스 행위들은 정적인 도메인 모델과 분리되어 있다.
물론, 개념들간 연관관계로 행위의 면면을 이해할 수는 있지만 전체를 이해하기엔 부족하다.
비즈니스 모델링의 워크플로우를 보자.
비즈니스 모델링(조직, 워커, 프로세스 정의)과 도메인 모델링 트랙이 분리되어 있다.

비즈니스 프로세스를 SW로 떨어트리는 관점으로 살펴보면 이해가 쉽다.
도메인 모델은 어셈블리 라인들의 관계로 이해하면 된다.
어셈블리 라인과 그 관계를 살펴봐서는 
내부에 개념이 왜 있는지 어떻게 협력되는지 이해할 수 없다
어셈블리 라인이 복잡하고 밀접하게 얽혀있으면 더더욱 이해가 어렵다.
시스템 인터페이스를 분리해낸 비즈니스 타입 모델의 관점에서도도 마찬가지다.
(uml component 149 page)

즉, 정보와 지식을 집약시켜 
문제영역을 학습, 소통, 향상 시키기 위한 도구로 
정적인 관점(구조적 관계, 행위의 의존성)을 갖는 도메인 모델만으론 부족하다.
동적인 정보나 그에 준하는 단서가 있어야 해석할 수 있다.
동의하기 어렵다면 analysis patterns, ddd, appliying uml and patterns 책을 펴보길 권한다
책에 등장하는 도메인 모델을 봤을때 업무가 머리에 그려질까? 
도메인 모델을 보고 업무에 대해서 설명할 수 있을까? 쉽지않을 것이다.

DDD에서는 설계를 주도하는 모델과는 별개로 설명을 위한 모델의 필요성을 언급한다.
설계를 위한 모델은 이를 해석하기 위해서는 맥락이 수반되어야 한다.
맥락이란 위 이미지 처럼 프로세스 흐름, 프로세스의 이유, 목적, 관련 리소스 이유 같은 것들이다. 
과거에 곧잘 사용되던 분석단계의 프로세스 엔터티 매트릭스도 설명목적으로 활용할 수도 있다.

결론, SE관점에서 도메인 모델은 유용하다.
설계를 이끌어 가는 도구로 유용하며,
개념을 집약하고 구조화하며 차츰 향상시켜 나갈 수 있다.
허나, 도메인 모델의 배경, 맥락을 이해하기 위해선 설명을 위한 모델이 적절히 수반되어야 한다.
도메인 모델은 이후 책임 할당, 구조화, 정제를 거치며 코드로 나아간다.


- 기타 잡다 -

1. 모 서적에선 말-도메인 모델-코드로 민첩하게 가자고 말한다. 

현실에서 그런 방식으로 진행하면 어떻게 될까? 사례를 들어보자. 
차세대 프로젝트에서 재무업무를 개발했던 적이 있다.
고객사 보안정책상 업무 범위를 벗어나는 정보는 의도적으로 차단된다.
그래서 개발자의 손에 쥐어진건 도메인 모델과 말(BA-업무를 설명하는 직원) 뿐이다.

애자일스럽고 가벼운 최고의 환경일까? 전혀,. 
개발이 진행되어도, 개발을 완료해도 업무에 대한 지식이 깊어지지 않았다.왜?

도메인에 대한 근본적인 이해는 도메인 모델에 담기지 않는다.
BA가 말로 전달하는건 why와 what이 빠진 how에 대한 편린이다.
단편적인 말로 도메인의 배경과 의사결정이 반영된 how가 적절한 지를 판단할 수 없다.

설계의 적정성은 상호작용, 관계에 의해서 판단된다.
설계의 이유가 되는 상호작용을 일으키는 업무흐름, 요구사항, 배경에 대한
이해없이 내가 정의한 클래스만 바라봐서는 무엇이 올바른 설계인지 판단할 수 없다.

가령, 재무 컨텍스트는 계약 컨텍스트, 계약의 전체 프로세스에 대한 깊은 이해가 수반되어야 한다.
(당시엔 도메인을 이해하기 힘든 이유가 뭘까 꽤나 스트레스 받았었고
(DDD책을 아마존에서 주문해서 뒤적뒤적 읽곤했다.14년 전 이야기다.

원천적인 맥락에 대한 배경지식은 편린과 휘발되는 '말'이 아닌 다른 형태로 제공되어야 한다.
BA의 단편적이고도 휘발되는 말이 뭔가 민첩해 보이지만 실제론 전혀 민첩하지 않다.
국외 애자일 컨퍼런스나 포럼에서 product manager를 없애자는 성토가 이어지는 이유다.
(지식, 이해가 포함된 합의된 결정이 아닌 product manager에 의존하는 것은 좋지 않은 형태다.


2. 현실에서는 도메인 모델을 차근차근 작성하는 경우는 적다
설계와 구현을 "모델"에서 출발한다는 관점을 취하는 경우가 적거니와
구현에 최대한 가까운 지점부터 출발하여 도메인 모델을 생략하는게 보통이다. 아래처럼 말이다.
요구사항 - 구현
유저스토리 - 구현
TODO - 구현
요구사항 - 테스트 정의 - 구현
요구사항 - 초기 설계 - 테스트 + 구현
어느정도의 규모가 되는 프로젝트에서는 
DA가 여러 업무로부터 주제영역별 개념 데이터를 획득하고
레거시 모델을 참고해서 개념 모델을 정제하고 업무 분석설계자와 검증하는 식으로 진행한다.


3. 모델의 필요성을 부정하거나 과대평가하는 것만 조심하자
- 대형 SI프로젝트에서는 MDD를 많이 채용하지만 
  작은 시스템,앱 구축 프로젝트에선 구현이 우선이다.
  도메인이 작고 직관적이며 프로세스도 간단하고 정보처리성인 경우가 많기 때문이다.
- 현실에서는 간단한 도메인들이 많다.
  따라서 MDD(Model-Driven Design)의 필요성을 크게 체감치 못한다.
  그렇다고 해서 그것이 잘못되었다거나 후진적인 것을 의미하진 않는다.
- 도메인이 단순하면 설계와 업무설명을 요약한 작은 sheet로도 충분하다. 괜찮다.

4. 이해를 돕는 책들
  business modeling with uml - 비즈니스 view의 존재 이유, 모델링 하는 방법
                                  - 비즈니스 view를 sw 아키텍처 까지 이어가는 방법.
  applying uml with patterns -도메인 모델의 목적과 전후에 무엇을, 왜, 어떻게 하는지 설명.
  uml component - 개념을 조직하고 책임을 할당하는 방식에 대한 이해 획득.
  analysis patterns - 도메인 모델 레퍼런스
  lean architecture - 구조에 컨텍스트를 분산시킨 것의 문제점에 대한 이해
  domain driven design - ddd관점에서의 도메인 모델.

5. 혼란스러운 용어
같은 의미를 갖는 것도 있고 다른 의미를 갖는 것도 있다.
   비즈니스 컨셉 모델, 비즈니스 타입 모델, 비즈니스 오브젝트 모델, 
   도메인 모델(일반적인 용어), 도메인 모델(DDD), 개념 데이터 모델..
- 참고로, DDD의 도메인 모델이란 용어는 기존의 도메인 모델이란 용어와 완전히 다르다.
- 최근엔 도메인 모델을 ORM의 모델 용어나 
   Hexagonal architecture 레이어 의미로 사용하기도 한다. 
- 도메인 이라는 말을 남발했지만 현실에선 도메인이란 용어는 줄이는게 낫다.

1 2 3 4 5 6 7 8 9 10 다음