애자일을 조직문화에 도입하기 위해 연구하는 문서입니다. ( 지속 업데이트 중) |
링크 : https://miro.com/app/board/o9J_lG0n7ww=/
2001년, 소프트웨어 업계를 주도하는 17인의 리더들이 모여 다음을 선언하였다.
애자일이, 긴민함/민첩함 이란 형용사적 단어적 의미가 아닌, 애자일 선언문의 가치와 원칙을 실천하는 마음가짐이나 방법을 말한다.
우리의 시장은 과거와는 달리 변덕스럽고,불확실하며,복잡하고 모호하다
애자일은 변화를 만들고 변화에 대응하는 능력이며, 불확실하고 급변하는 환경에서 궁극적으로 성공을 거두기 위해 그 환경을 다루는 방법이다.
다음은 1950년 애드워즈 데밍이 한 이야기이다.
‘품질향상은 실질비용을 낮춘다’고 말했다. 또한 그는 “생산라인에서 가장 중요한 요소는 소비자다.
소비자를 만족시켜 주는 일이 회사의 모든 사람들이 해결해야 할 최우선 과제이다.
모든 직원들이 자기가 만든 제품의 품질에 대해서 스스로 책임을 지는 품질 책임체제를 구축해야 한다. 기
업의 수익은 제품과 서비스에 만족하고 이를 지속적으로 구매하는 단골고객으로부터 나온다.”라고 말했다.
품질과 관련한 , 현재는 당연한 이야기인것처럼 보이지만, 1950대에 위 이야기는 미국에서 무시가되었으며
오히려 일본기업인 도요타,소니,혼다등이 데밍의 이야기를 따르며 제조업에서 미국을 앞지르기 시작했으며 부흥기를 맞게되었다.
일본에서 데밍상이 생겨났으며, 추월당한 미국이 일본을 다시 연구하기 시작한다. 이 이야기를 소개하는 이유는,
애자일에서 선언하는 가치와 닮아 있으며 애자일이 2001년 갑자기 생겨난 새로운 이야기가 아니라
제조업에서 그동안 축적된 문화와 철학이 소프트웨어 개발에도 영향을 주기 시작했다란 것이다.
품질은 우리가 경쟁사로부터 살아 남을수 있는 마지막 기회이다.
더자세한 이야기 : https://steemit.com/kr/@loum/w
소프트웨어 개발 중에 고약한 성질을 품은 문제를 만났을 때 그를 합당하게 해결하는 방법을 찾아나가고 있다.
주로 사용되는 폭포수 모델의 개괄적 원리를 설명하면서, 고약한 문제를 해결하는 데 부족함을 보여준다.
폭포수 모델의 변종인 소용돌이 모델 등에 대해서도 살펴보고 있다 나아가 폭포수 모델을 극복하기 위한 프로토타이핑 등 대안적 모델을 정의하고 찾아간다.애자일 인식의 뿌리가 되는 고서이며
폭포수모델의 문제를 해결하기위해, 폭포수 모델을 이해 해야하는것은 당연하다.
고약한 문제는 해결책이 문제의 공간 안에 있는 문제를 일컫는다. 즉 문제가 완전히 풀려야 비로소 그 문제가
무엇인지 완전히 이해되는 그런 문제다. 반면 그 반대편에는 합당한 문제가 있다. 합당한 문제는 정의할 수 있
고, 이들에 대한 데이터를 수집해서 분석할 수 있으며, 해결책을 낼 수 있는 문제다. 마치 폭포수 모델의 시원한
절차처럼 말이다.
소프트웨어 개발 프로젝트에서 어떤 결과를 내는 데 필요한 정보를 제공하거나 체계화하는 것은 컴퓨터가 중심
인 것처럼 보이지만 사실 사람이 중심에 서 있다. 그리고 태생적으로 야기되는 불확실성의 문제는 그 정형성을
이루는 데 반드시 있어야 하는 객관적이고 명료한 기준을 세우기 어렵게한다.
애자일의 철학도, 기술중심/이익중심도 중요하지만, 결국 소프트웨어의 문제를 푸는것은 사람이며 사람을 중심으로 만들기위한 고급철학이 포함되어 있다.
링크 :
문제를 팀이 정의를 하고 해결해나가는 힘을 키우는것은 , 개개인의 성장과함께 일정수준이 되어야함을 의미한다.
이것은 메타인지와 연관이 있을수 있다. 탑다운의 정형화된 폭포수모델에서는 대부분의 중요문제는 상위에서만 정의를 하였다.
반대로 이야기하면, 정보가 거의 없을 초기시점 그러니까 우리가 정보를 가장 모르는 초기시기 숙련된 경험자만이
설계단계에서 문제정의를 하였다. 애자일에서는 가장 모르는지점 감으로 문제정의를 모두내리는것에 대한 리스크를 이야기하며
애자일을 하기위해서는 팀구성원 모두가메타인지 능력을 사용해서 지속적인 문제정의와 해결방법을 찾아가야 하며,
그것 자체가 팀역량이 될수 있다.
관련링크 : 메타인지 생각의기술 - IT개발Part - WebNOri
소프트웨어가 일반적으로 복잡해지는 이유는, 우리가 사용하는 기술자체의 복잡성 때문이 아니라
우리가 가진 도메인 자체의 복잡성에 기인하며, 도메인을 중심에 놓고 도메인 전문가 까지
모델을 만드는 단계에 참석을 시키는, 개발문화의 변화와 성숙에 대한 도전 과제로이야기가 이어집니다.
DDD를 하기위해서는 애자일이 필요하다. 애자일이 좋은 소프트웨어를 만들기위한 가치와 마음가짐을 포함
방법론을 이야기한다고 하면 DDD는 그것을 실천하기위한 구체적인 전략/전술을 이야기하며 애자일의 코어영역과 상당수 일치한다.
위 두가지가 있을때 무엇을 선택할것인가? 당연히 후자쪽일것이다.
개발방법/프로세스에 얽매이지 않는 Shape UP의 방식을 살펴보는것도 도움이 될것이다.
모든것(UI/UX/작동방법)을 표현하지말고 중요한것(요구사항분석,스토리보드,플로우)을 이야기할것
빈틈없는 정교함보다 심오한 간결함을 유지하고, 지속 업데이트
링크: https://brunch.co.kr/@cysstory/163
핵심은 작업에 있지 않다는것입니다. 가치를 어떻게 인식하느냐입니다.
https://ichi.pro/ko/wbsneun-ij-eo-beoliseyo-agileeseoneun-vbsga-pil-yohabnida-214235113856846
wbs 방식이 구식인건 맞는데... 근데 그래도 산업군에 따라 그런 방식이 필요합니다. 고객에 의한 “가치 폭주 현상”이 발생합니다.
피드백을 통해서 자기도 기여한다고 느끼는 고객이 자신의 가치를 가지고 지나친 피드백을 해서 불필요한 품질상태를 만들기도 하니까요. 그래서 고객의 피드백을 제동해야할 때가 있습니다.
가치가 어디로 향해야 하는지는 결국 애자일 조직 리더의 몫이니까요.
Quality is value to someone.
- Gerald Weinberg
변경을 허용하지 않는 것은 나쁜 계획이다. - 푸볼릴리우스 시루스
과거 몇년간 어떻게 작은 팀으로, 높은 품질의 소프트웨어를 그렇게 빨리 개발해내는지 물어보곤 했다. 또, 개발자들을 오랫동안 유지하는지도.
첫째, 우리는 워터폴, 스크럼같은 프로세스에 얽매이지 않았다. 둘째, 우리는 벽에 포스트잇을 줄세우지 않았다. 셋째, 우리는 데일리 스탠드업, 스프린트, 백로그, 칸반, 벨로시티 체킹등 어느 것도 하지 않았다.
우리는 우리의 길을 만들었다.
링크 :
애자일 프렉티스를 따라하다보면 해야할것들 데일리/스탠드업/백로그관리(보고를 위해 또 이중관리) 스크럼을위한 스크럼등
제대로 하면 개발자에게 코딩할 시간이 주어지지 않는게 사실이며 그것에 엄청난 공을 들입니다.( 퇴근 1시간전에 집중 코딩 필요 )
그리고 칸반보드로 보고를 대체할수 있을까요? 칸반보드는 다시 WBS로 변환되기 까지 합니다. ( 그럴꺼면 WBS만을 잘 사용하기를 권장합니다.)
다음은 애자일의 칸반보드를 잘못사용하는 팀에대한 경고이며, 도메인 주도설계 책에서 언급된 이야기입니다.
( WBS에대한 이야기가 아닙니다. 칸반보드를 폭포수모델에서 했던 WBS의 Task관리와 동일하게 사용하는것에 대한 문제 )
우리는 어떤 설계를 하고 있을까? 우리는 설계대신 "작업 보드 셔플" 이라는것을 진행하게되며
할일과 작업중 그리고 완료로 이어지는 작업의 아이템 변화과정을 지식 집약적인 일의 전부로 여기고
나머지는 프로그래머가 소스를 쏟아내기만 하면 된다라고 생각한다.
이는 잘 드러나지도 않고, 존재하지도 않는 설계에 엄청난 비지니스 비용을 쏟아붓는일이다.
좋은 설계의 다음 대안은 나쁜설계이다. 이 문구의 요점은 설계를 절대하지 않는것에대한 이야기이다.
처음부터 좋은 설계를 할수 없으며, 이것이 좋은지,나쁜지 판단할수가 없다.
나쁜설계를 시도하고, 효율적인 설계를 어떻게 할지 설계에대한 고민을 시작하란의미이다.
설계가 없는것은 지식획득이라는 중요한 것을 놓치고 ,큰 진흙 덩어리를 계속 만들어 내게되며
소프트웨어 개발을 이익중심이 아닌 원가 중심으로 생각하는 비지니스 문화가 확고한 경우 설계문화가
생겨날수 없다란것을 경고도 하고 있다.
Shape Up방식을 단순하게 따라한다고하면 또다른 애자일의 파생을 답습하는것이 될것입니다.
정형화되고 있는 애자일 개발방법론에서 어떻게 탈출해, 자신만의 방식을 만들었는지 연구해볼 필요가 있을것같습니다.
( 아직은 , 국내 관련 서적이 거의 없는 상태)