가치를 빠르고 자주 전달하는데 집중한다.

the nature of software development을 읽고 요약해보았다.

본질적인 방법 = 가치를 빠르고 자주 전달하는 데 집중한다는 간결한 개념 위에 만들어진 길

우리가 할 수 있는 일은 ‘길이 있다’는 것을 기억하는 일이다. 길을 잃어버렸을 때는 가치와 본질적인 방법을 떠올려라. 소프트웨어 개발에는 본질적인 방법이 존재하고 그 방법은 모두에게 도움을 준다. 왜냐하면 본질적인 방법은 가치를 더 빠르게 전달하기 때문이다. 본질적인 방법은 고민, 학습, 변화를 요구한다.

가치

가치는 본질적인 개발 방법의 핵심이다. 가치는 우리가 원하는 것이다. 가치를 확인해보고 싶다면 “작동하는 소프트웨어를 보여주세요.”라고 말하라. 오직 소프트웨어를 배포하고 사용할 때 프로젝트는 가치를 전달한다. 가치를 일찍 제공할 수 있는 피처는 항상 존재한다. 이런 피처가 무엇인지 찾아보고 먼저 배포할 수 있도록 한다. 이렇게 배포하면 프로젝트가 올바른 방향으로 가고 있는지 확인할 수 있다. 우리와 사용자 모두가 이해할 수 잇는 조각을 개발하도록 개발팀을 가이드해야 한다. 가치가 높고 비용이 적게 드는 피처를 우선으로 자주 배포해야 한다.

가이드

프로젝트를 진행할 때 가장 먼저 알아야 할 것은 바로 마감 일정이다. 프로젝트에 몸만 담지 말고, 직접 방향을 조정해라. 모든 피처를 한꺼번에 계획하고 개발하는 일은 모두를 힘들게 한다. 처음부터 여러 배포 일정을 계획하라. 가치 있는 피처들을 주기적으로 보여주면 무엇이 일어나는지 바로 알 수 있다. 눈으로 확인할 수 있는 피처들로 관리하는 것이 훨씬 쉽다.

조직 구성

피처를 만들 수 있는 작은 개발팀을 여럿으로 구성한다. 각 개발팀이 피처 전체를 개발할 수 있는 기술을 가졌는지 확인한다. 기술을 공유할 학습공동체를 만든다. 전문가는 다른 사람을 전문가로 이끌어 줄 수 있어야 한다.

계획

프로젝트에는 계획이 필요하다. 너무 세세한 계획보다는 먼저 개발해야 할 핵심 피처를 추리는 것이 중요하다. 계획을 세우되, 언제든지 변호를 줄 수 있는 환경을 만들어라. 개발팀은 일정한 작업 속도를 유지해야 한다. 각 피처는 이삼일 정도 작업할 분량이 적당하다. 쉽게 이해할 수 있는 작은 사용자 스토리로 쪼개라. 오늘은 어제의 업무량만큼 일할 수 있다. 업무량은 개인이 아닌 팀 전체를 이해하고 팀이 할 수 있는 양을 추정해야 한다. 이것은 제대로 된 일을 일관된 속도로 수행하기 위한 것이다. 서두르다 보면 결함을 더 많이 심게 된다. 지저분한 코드는 일정을 지연시킨다. 10가지 일을 형편없이 진행하는 것보다는 8가지 일을 잘 진행하는 것이 낫다.

개발

주기마다 하나의 완성된 제품을 만들도록 목표를 세워라. 피처를 반드시 완료 또는 미완료로 구분해야 한다. 모든 사람이 프로젝트의 진행 상황을 확인할 수 있어야만 조직이 나아가야 할 가장 좋은 방향을 판단할 수 있다. 각 주기가 끝나는 시점에는 소프트웨어의 결함이 없어야 한다. 모든 개발 기간에도 소프트웨어에 결함이 있어서는 안 된다. 결함이 없다는 것을 확신하려면 항상 모든 것을 확인해야 한다. 제품이 성장할 때마다 소프트웨어의 설계도 개선해야 한다.

분할

각 피처는 견고한 기반, 견고한 인프라가 필요하다. 간결하지만 작동하는 버전을 먼저 개발하는 편이 훨씬 더 안전하다. 제시간에 최상품을 배포하려면 사용자에게 중요한 모든 피처를 제품에 포함해야 한다. 작고 간결한 버전으로 시작하고, 개발 주기마다 피처를 개선하는 작업을 반복한다.

품질

제품은 점진적으로 발전하는 설계에 기반을 두고 있어야 한다. 결함을 제거해 프로젝트의 진행 상황을 명확히 해야 한다. 오직 테스트만이 결함을 최소화하는 방법이다. 비즈니스 관점에서 테스트한다. 인수테스트 주도 개발이 유명하다. 개발 단계에서도 더 자주 테스트를 수행해야 한다. 테스트 주도 개발은 개발 속도를 더 높여준다. 실수가 줄어들고 결함을 더 빨리 찾을 수 있기 때문이다. 설계도 성장해야 한다. 설계를 올바르게 유지하려면 지속적으로 설계를 개선해야 한다. 올바른 설계를 유지하는 일이 리팩토링이다. 올바른 설계를 유지하지 못하면 작업 효율은 계속 떨어진다.

가치를 평가하는 진정한 방법은 제품 책임자와 이해관계자, 그리고 팀과 함께 무엇이 정말로 가치 있는 것인지 고민하고 만들어 나아가는 것이다. 가치를 정했다면 망설임 없이 피처를 개발하여 제품을 배포한다. 그리고 사용자에게 의견을 듣는다. 이 과정을 반복하는 것이 핵심이다.

목적, 자율성, 숙련. 제품 책임자는 제품의 목적을 제시해야 한다. 팀과 소통하고, 왜 이 일을 해야 하는지, 가장 중요한 문제는 무엇인지, 어떻게 이 문제를 해결할 수 있는지 의견을 나눈다. 모든 팀이 함께 문제를 해결해야 한다. 그래야 모두 성장할 수 있다. 팀이 결정하고 만들고 결과를 확인한다.자기 조직화한 팀은 자율성이 높아지고, 창의성을 더 많이 발휘한다. 배포할 수 잇는 피처들의 품질을 더 높이고 기준을 엄격하게 만든다. 완전히 숙달할 때까지 나아가야 한다. 제품이 나아가야 할 목표를 함께 이해하는 숙련된 자기 조직화 팀이 되는 것이 핵심이다.

경영진이 가치 있는 제품을 뚜렷하고 유연하게 개발하는 효율적인 팀을 만든다면 경영진이 해야 할 일도 그만큼 증가한다. 또 다른 팀을 만들고 그 후 또 다른 팀을 만드는 일이다. 경영진이 해야 할 가장 중요한 일은 우리가 맡을 수 잇는 제품과 프로그램의 개수에 제한을 두는 것이다. 경영진이 개발 주기마다 제품을 볼 수 있다면 큰 문제가 생길 확률은 불가능에 가깝다. 소프트웨어 개발의 본질적인 방법은 일하는 사람에게 권한을 위임하는 것이다.

압박한다면 개발팀은 잘못 돼가는 것을 알면서도 포기한다. 정말로 빠르게 개발해야 한다면 일정을 지연시키는 원인을 분석해라. 개개인의 생산성보다는 팀이 가진 생산성에 주목해라. 개개인의 능력을 향상시켜라. 어떤 피처가 언제까지 완료될지 결정할 때 최고의 결과를 낸다.

개발팀은 변화를 받아들이고, 테스트하고, 실행에 옮기는 데 집중해야 한다. 개발팀이 QA팀으로 소프트웨어를 전달할 때, 그것이 결함과 함께 돌아오지 않을 것이라고 확신해야 한다. 반드시 현재 완성의 정의를 맞출 수 있어야 하고, 이 완성의 정의는 시간이 지날수록 엄격해져야 한다. 단 한 번의 빌드로 하나의 개발 컴퓨터에서 모든 피처가 작동할 수 있도록 엄격해야 한다.

개발 속도를 유지하려면 좁고 구불구불한 길은 만들지 말아야 한다. 피처를 만들 때 이런 길을 정리해야 한다. 개발팀에게 압박을 주면 리팩토링을 할 수 없다. 개발팀은 테스트를 생략하고 지름길을 사용한다. 가장 훌륭한 개발 방법은 야영지 규칙을 따른다. 야영지는 그곳을 발견했을 때보다 떠날 때 더 나은 곳이어야 한다. 피처를 추가할 때마다 주변 코드를 정리하고 시작한다. 피처가 작동한 이후에는 코드를 정리한다. 정리는 자주 할수록 좋다.

가장 중요한 것은 고민하는 것이다. 최선의 결과를 달성하는 일은 무엇이 발생했는지 관찰하고 그에 맞게 대응했을 때만 가능하다.