“소프트웨어 개발에는 본질적인 방법이 존재한다. 그 방법은 모두에게 도움을 준다." PART 1 가치를 이루는 것들 CHAPTER 01 가치 찾기 가치 Value 우리가 원하는 것 가이드 Guiding 책임감 있게 가치를 생산해줄 개발팀을 구성해 가치를 만듭니다. 조직 구성 Organizing 피처 feature 를 기준으로 맡은 일을 끝낼 수 있는 개발팀을 구성해야 합니다. 계획 Panning 필요한 순서대로 피처를 선택하여 프로젝트를 이끌어야 합니다. 가치를 제때 완성해야 합니다. 개발 Building 피처 단위로 제품을 개발해야 합니다. 이 방법은 가치를 자주 전달할 수 있게 합니다. 분할 Sicing 피처를 가치가 있되, 가장 작은 단위로 쪼개야 합니다. 품질 Qualty 항상 제품이 잘 설계되고..

DOING AGILE RIGHT 조직을 민첩하고 유연하게 바꾸는 애자일 전략 Ask the Authors - Doing Agile Right | Bain & Company 프롤로그 균형 잡힌 애자일 기업으로 나아가기 애자일 agile (혁신을 목표로 빠르게 움직이는 자율경영팀에 의존하는 경영 철학)은 이미 공식적으로 기업 경영의 주요한 방식으로 사용되고 있다. 수많은 혁신의 원천인 IT 부문은 사실상 애자일 방법이 지배적인 상황이 되었다. 최근의 통계에 따르면 소프트웨어 개발자의 85퍼센트가 업무에 애자일 기법을 활용하고 있다. Stack Overflow Developer Survey 2018 조사 대상 소프트웨어 개발자 10만 1,592 명 중 85.9퍼센트가 업무에 애자일을 사용 2019년부터는 아예..

Dominica DeGrandis – More No Less WIP 들어가며 스스로에게 과부하를 줄 뿐만 아니라, 팀에도 과부하가 걸린다. 이것이 IT분야의 일상적인 현실이다. 보통 하던 일을 중단하고, 다른 프로젝트에서 일을 시작한다. 항상 방해를 받기 때문에 한 가지 일에 집중해서 제대로 일을 처리할 수가 없다. 문맥 전환context switching은 자리 잡고 앉아 일에 충분히 집중할 수 있는 능력을 손상시킨다. 결과적으로 업무의 품질이 좋기를 바라지만 불행히도 만족스럽지 않다. 요청의 양(요구 사항)과 사람들이 요청을 처리해야 하는 시간(그들의 수용량은 늘 불균형을 이룬다. 이 때문에 새로운 업무를 시작하기 전에 이미 진행하던 일을 완료하도록 집중할 수 있는 당김 시스템pull system이 ..

Home | More Effective Agile 01 더 효과적인 애자일 1장 시작 에 따르면, “고성과 IT 조직을 갖춘 기업은 수익성, 시장 점유율, 생산성 목표를 초과 달성할 가능성이 두 배 더 높다”[Puppet Labs, 2014], 높은 성과를 내는 회사는 고객 만족도, 업무의 질이나 양, 운영 효율성, 기타 목표를 달성하거나 초과할 확률이 두 배 이상 높았다. 평균적인 스크럼팀을 건강한 스크럼팀과 비교한 도표 2장 오늘의 애자일 애자일 경계를 오해하면 기대치를 잘못 설정하여 다른 문제가 발생한다. 3장 복잡성과 불확실성에 대응하기 커네빈 프레임워크는 다섯 개의 영역으로 구성된다. 각 영역에는 고유한 속성이 있으며 대응법을 제안한다. 복잡함 영역 (Complex) 혼돈 영역 (Chaotic)..

1장 애자일 소개 중간 단계의 작은 목표를 고르고, 그 진행 상황을 측정한다는 아이디어는 너무나 직관적이고 인간적이다. 혁신이라고 할 것도 없다. 과학적 관리법은 변경 비용이 많이 드는 프로젝트에서 제일 잘 동작했고, 목표가 극도로 명확한 매우 상세하게 정의된 문제를 잘 풀었다. • 공정과 도구보다 개인과 상호작용 • 포괄적인 문서보다 작동하는 소프트웨어 • 계약 협상보다 고객과의 협력 • 계획을 따르기보다 변화에 대응하기 프로젝트 관리의 철십자Iron Cross. 좋음, 빠름, 저렴함, 완성. 이 중 셋만 고를 수 있다. 네 번째 것은 가질 수 없다. 마치 CAP theorem을 보는 느낌. 정말 깔끔한 정리. 이렇게 정리하는 능력이 있어야 이 정도로 업계를 선도할 수 있는가 감탄했다. 애자일 개발은 ..

어떻게 보면 여러가지 도구를 다루고 또 애자일에 대한 이야기를 하면서 혼란스러울 수 있으나, 협업을 잘 하기 위해 필요한 것들을 이야기한다는 관점에서 바라보면 이해가 간다. 특히 조직의 변화를 이야기하는 부분은 참 공감도 가고 현재 경험을 하고 있는 내 입장에서는 고생했겠다는 생각이 든다. 굉장히 잘 정리된 건 아니지만, 그만큼 저자가 고생했던 걸 모아놨다는 걸 생각하면 모든 노하우를 정리하기도 어려웠을 거 같단 생각이 든다. 모든 조직에 딱 들어맞는 방법론은 없다. 각 조직에 어울리는 방법론이 있을 뿐이다. Home | Scrum Guides (1) 스크럼 정의 스크럼은 사람과 팀, 조직이 복잡한 문제에 대해 적응할 수 있는 해법을 활용하여 가치를 창출하도록 도와주는 경량 프레임워크다. 간단히 말해서 ..

https://nymets.medium.com/%EC%95%A0%EC%9E%90%EC%9D%BC-%EB%A7%88%EC%8A%A4%ED%84%B0-71565c2b6bfc 맘에 안 드는 건 책 제목(원서)과 표지에 사무라이가 들어간다는 점. 일본 문화가 얼마나 영향력이 있는지 보여주는 일례인 듯 내가 생각하는 방향이 틀리지 않았음을 알게 되었다. 다만 당연히 세부사항에 대해서는 나도 더 발전해야 한다. 오래된 책이지만 역시 좋은 책은 시간과 무관하게 가치가 있다. 애자일에 대한 책이 앞으로 얼마나 가치가 있을지 모르겠으나(당연히 고전과 같은 가치가 있진 않겠지만) 그래도 상당히 오래 가지 않을까? 하는 생각이 들었다. 언젠가는 누구나 다 이런 방식으로 일하는 것을 좋아하게 될 거라고 생각하느냐고? 천만의 ..

개인적으로 시간을 낼 수도 없고, 회사도 기회를 제공하지 않은 상태로 시간만 보내게 되는 겁니다. (지금 이 문제로 내가 싸우고 있어서 정말 와닿는다) 소프트웨어 개발 프로젝트의 복잡도는 크게 두 가지 변수의 영향을 받습니다. 그것은 바로 ‘사용자 요구사항’과 ‘개발기술’인데요. 먼저 ‘사용자 요구사항’ 의 경우를 보죠. 폭포수개발방식은 프로젝트 초기에 요구사항을 고정시킵니다. 사용자와 철저한 인터뷰를 하고 문서를 만들며, 여기에 확인 서명을 받기도 하죠. 이에 반해, 애자일 방식은 요구사항의 변화를 그대로 수용합니다. 다만 반복적인 프로세스를 돌려서, 각 프로세스(이터레이션 또는 스프린트) 안에서는 요구사항이 변하지 않도록 보호하는 조치를 합니다. 그럼 기술의 변화는 어떻게 수용할까요? 프로젝트 초반에..