Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

우리의 시장은 과거와는 달리 변덕스럽고,불확실하며,복잡하고 모호하다

폭포수 모델이 규모를 다루는 방법이 방법였다라고 하면

애자일은 변화를 만들고 변화에 대응하는 능력이며, 불확실하고 급변하는 환경에서 궁극적으로 성공을 거두기 위해 그 환경을 다루는 방법이다.

애자일의 기원

다음은 1950년 애드워즈 데밍이 한 이야기이다.

‘품질향상은 실질비용을 낮춘다’고 말했다. 또한 그는 “생산라인에서 가장 중요한 요소는 소비자다.

소비자를 만족시켜 주는 일이 회사의 모든 사람들이 해결해야 할 최우선 과제이다.

모든 직원들이 자기가 만든 제품의 품질에 대해서 스스로 책임을 지는 품질 책임체제를 책임체제구축해야 한다. 기

업의 수익은 제품과 서비스에 만족하고 이를 지속적으로 구매하는 단골고객으로부터 나온다.”라고 말했다.

...

폭포수 모델의 변종인 소용돌이 모델 등에 대해서도 살펴보고 있다 나아가 폭포수 모델을 극복하기 위한 프로토타이핑 등 대안적 모델을 정의하고 찾아간다.

애자일 인식의 뿌리가 되는 고서이며고서이며 폭포수모델의 문제를 해결하기위해, 폭포수 모델을 이해 해야하는것은 당연하다.

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

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

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

절차처럼 말이다.

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

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

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

...

문제를 해결하려는 이야기는 "Wicked Problems Righteous Solution" 30년도 더된 IT고서에서 이야기를 하고있으며

애자일의 애자일이 생기기전 인식의 뿌리가 되는 내용입니다.


링크 :

...

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

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

팀의 공유된 메타인지(shared meta-cognition)라고 부르기도합니다.


DDD와 애자일

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

...

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


애자일과 수평

수평적 개발문화를 이해하기위해 애자일의 선언을 다시 살펴보자

...

Beging Agile 은 회사 또는 기존 관리자급에서 고찰을 해야하는 내용입니다.

애자일의 시작은 사실, 실무자뿐만 아니라 권한과 책임을 나눌수 있는 분위기및 함께  학습하는 분위형성이 중요합니다.

전통적인 워터폴에서 사용되었던 관리방식이 완전하게 바뀌어야함을 의미하고 생각보다 많은 변화와 큰 비용이 들수 있습니다.

가령 다음과 같은 고민입니다.


"착수와 계획이 완료되어야 시작되는 기획/PM팀이 있는 개발  프로세스에서 팀을 없애고 스스로 움직일수 있는 팀을 만들수 있는가?"==>기획과 PM이 없어야된다는 이야기는 아니고~ 애자일을 수행하는 팀내에서 역활을 수행해야함을 의미합니다.개발팀이 스스로 계획을 세우려면 무엇이 필요할까?"


Doing Agile은 기존 실무자가 고찰해야하는 내용입니다.

수평적 개발절차를 워라벨(캍퇴보장칼퇴보장/워터폴 보다 스트레스가 적은/수평으로인한 편안함)로 생각하면 오해입니다.

오히려 애자일을 너무 열심히 한나머지 해서 프로덕트를 런칭시킨팀에서 번아웃이 올수 발생할수 있습니다.

수평은 가만히 있어서 유지할수 있는 상태가 아니라, 연필을 손바닥에 세워 떨어트리지 않으려고 계속 균형을 맞추는 

사실은 모두의 구성원이 능동적이고 적극적으로 프로젝트에 참여하고 책임을 분산하는 밸런스 게임이며 구성원이 적극적이지 않고 움직이지 않으면 그 수평은 유지될수 없습니다.

>실리콘밸리의 애자일은, 움직이지 않는다고 판단되면 다음 스프린트에 제외(해고)되는 제외되는 사실은 무서운 수평게임입니다. 


다음과 초급 실무자가 다음은 실제 인터뷰때 많이 하는 불만중 들은 이야기중 하나입니다.

"수평적 업무절차를 문화 희망합니다, 제 사수는 어디있나요? , 프로세스가 없어요~ 없어요 "

==> 이 경우, 워터폴이라도 제대로 경험해보는것을 권장합니다. 애자일에서는 시킨일만 하는 코더가 존재하지 않습니다~ 모두가 기획자이자고,설계자이며 개발자는 또한 구현자이기도합니다. 이것이 요즘 개발자의 몸값이 오르는 이유이기도 합니다. 여기서 사수는 군용어로 가장 수직적 단어이며, 프로세스 또한 워터폴을 의미할수 있습니다.


개발방법론 지속발전과 직원경험

어떠한 개발방법론이던지, 그 목표는 비즈니스의 성공에 있으며,복지와 관련된것이 아닙니다. 

좋은 개발팀은 구성원이 계속 변경되어 새로운것을 시도하는것이 아닌 오래가는 팀입니다.

...

이 시대에 근속 3년을 채우지못한 경력 지원자는서류 광탈이였지만,  지금은 1년 경력도 소중한 시대가 되었습니다.(특히 개발자군)

평균적으로 직장 라이프사이클이 짧아졌다란 것이며 충성도로 더이상 구성원을 이끌수 없습니다.


그러면 것입니다. 직장충성의 반대말은 무엇이 있을까? 고민을 해보았습니다해봅시다. 

모두가 동의할수 없지만, 직장이 직원에게 좋은 경험을 줘야한다는 컨셉인 직원경험입니다.

...