Page History

...

제조업에서 그동안 축적된 문화와 철학이 소프트웨어 개발에도 영향을 주기 시작했다란 것이다.

품질은 우리가 경쟁사로부터 살아 남을수 있는 마지막 기회이다.

• 잭 웰치

더자세한 이야기 : https://steemit.com/kr/@loum/w

...

폭포수모델의 문제를 해결하기위해, 폭포수 모델을 이해 해야하는것은 당연하다.

고약한 문제는 해결책이 문제의 공간 안에 있는 문제를 일컫는다. 즉 문제가 완전히 풀려야 비로소 그 문제가

무엇인지 완전히 이해되는 그런 문제다. 반면 그 반대편에는 합당한 문제가 있다. 합당한 문제는 정의할 수 있

고, 이들에 대한 데이터를 수집해서 분석할 수 있으며, 해결책을 낼 수 있는 문제다. 마치 폭포수 모델의 시원한

절차처럼 말이다.

소프트웨어 개발 프로젝트에서 어떤 결과를 내는 데 필요한 정보를 제공하거나 체계화하는 것은 컴퓨터가 중심

인 것처럼 보이지만 사실 사람이 중심에 서 있다. 그리고 태생적으로 야기되는 불확실성의 문제는 그 정형성을

이루는 데 반드시 있어야 하는 객관적이고 명료한 기준을 세우기 어렵게한다.

애자일의 철학도, 기술중심/이익중심도 중요하지만 결국 사람을 중심으로 만들기위한 고급철학도 포함되어 있다.

...

문제를 팀이 정의를 하고 해결해나가는 힘을 키우는것은 , 개개인의 성장과함께 일정수준이 되어야함을 의미한다.

이것은 메타인지와 연관이 있을수 있다. 탑다운의 정형화된 폭포수모델에서는 대부분의 중요문제는 상위에서만 정의를 하였다. 

반대로 이야기하면, 정보가 거의 없을 초기시점 그러니까 우리가 정보를 가장 모르는 초기시기 숙련된 상위 책임자의경험자만이

설계단계에서 문제정의를 하였다. 애자일에서는 가장 모르는지점 감으로 문제정의를 모두내리는것에 대한 리스크를 이야기하며능력이 대단해야 했다. 

애자일을 하기위해서는 팀구성원 자체가 메타인지 모두가메타인지 능력을 사용해서 문제인지와 지속적인 문제정의와 해결방법을 찾아가야 하며,

그것 자체가 팀역량이 될수 있다. 여기서 주니어이기 때문에  

관련링크 : 메타인지 생각의기술 - IT개발Part - WebNOri

DDD와 애자일

소프트웨어가 일반적으로 복잡해지는 이유는, 우리가 사용하는 기술자체의 복잡성 때문이 아니라

우리가 가진 도메인 자체의 복잡성에 기인하며, 도메인을 중심에 놓고 도메인 전문가 까지 

모델을 만드는 단계에 참석을 시키는, 개발문화의 변화와 성숙에 대한 도전 과제로이야기가 이어집니다.

DDD를 하기위해서는 애자일이 필요하다.  애자일이 좋은 소프트웨어를 만들기위한 가치와 마음가짐을 포함

...

• 구성원들이 일을 지금보다 빨리해서 결과물이 빨리나오길 기대하면, 그것은 애자일이 아니라 스피드이다. 팀이 지시를 받아 수동적으로 움직이는게 아니라 권한을 위임받아 주변 환경 변화에 스스로 민첩하게 대응할수 있게만드는것이 애자일이다. 사실은 변화에 대응하여 우리의 프로덕트가 살아남을수 있을까? 생존과 관련된것이다.
• 선거제도(애자일 프랙티스)만 있다고 민주주의 국가가 아니지만, 애자일 프렉티스를 작게 수행해보면서 애자일을 수행하다보면 애자일이 어디쯤 있는가? 가늠은 할수 있다.
• 애자일 마인드셋과 환경제공을 하는것 'Being Agile'은 탑다운에서, 실천하는 'Doing Agile' 은 바텀업을통해 균형을 이루어질때 작동된다. 
• 애자일을 하면서 생기는 문제가 애자일때문이 아닐수 있다. 원래 드러나지 않았던 고약한 문제이며 애자일을 통해 발견할 가능성이 더 크다.어떻게 하면 애자일 협업 온라인툴 또는 미팅을 잘할수 있을까? 잘생각해보면 오프라인 미팅 조차 잘해본적이 없다. 
• 애자일에 숙련되기전 애자일을 위한 조직변경은 추천되지 않는다. 애자일을 하면서 성숙도가 생기면 스스로 팀이 어떻게 구성되야 효율적일지 생각하게된다. 좋은 애자일팀은 변경이되는것이 아니라 오래 지속된다.
• 자율성을 준다고하여, 마음대로 하는것을 의미 하지 않는다. 책임이 따르게 되며 , 책임에 따라 책임에는 더 높은 수준이 요구되기도 한다수준의 개인역량이 필요할수도 있다.

개발방법론의 선택

• 규모와 문화와 처해있는 상황이 비슷한 회사의 성공방법을 따라할것인가?
• 우리만의 새로운 방법을 찾아서 그들보다 앞서 나갈것인가?

...

( WBS에대한 이야기가 아닙니다. 칸반보드를 폭포수모델에서 했던 WBS의 Task관리와 동일하게 사용하는것에 대한 문제 )

우리는 어떤 설계를 하고 있을까? 우리는 설계대신 "작업 보드 셔플" 이라는것을 진행하게되며

할일과 작업중 그리고 완료로 이어지는 작업의 아이템 변화과정을 지식 집약적인 일의 전부로 여기고

나머지는 프로그래머가 소스를 쏟아내기만 하면 된다라고 생각한다. 

이는 잘 드러나지도 않고, 존재하지도 않는 설계에 엄청난 비지니스 비용을 쏟아붓는일이다.

좋은 설계의 다음 대안은 나쁜설계이다.  이 문구의 요점은 설계를 절대하지 않는것에대한 이야기이다.

처음부터 좋은 설계를 할수 없으며, 이것이 좋은지,나쁜지 판단할수가 없다.

나쁜설계를 시도하고, 효율적인 설계를 어떻게 할지 설계에대한 고민을 시작하란의미이다.

설계가 없는것은 지식획득이라는 중요한 것을 놓치고 ,큰 진흙 덩어리를 계속 만들어 내게되며 

소프트웨어 개발을 이익중심이 아닌 원가 중심으로 생각하는 비지니스 문화가 확고한 경우 설계문화가

생겨날수 없다란것을 경고도 하고 있다.  

Shape Up방식을 단순하게 따라한다고하면 또다른 애자일의 파생을 답습하는것이 될것입니다.

...