The Nature of Software Development by Ron Jeffries

Part 1. 가치를 이루는 것들

• 가치는 우리가 원하는 것

- 가치를 확인해보고 싶다면 이렇게 말하라. "작동하는 소프트웨어를 보여주세요"

- 소프트웨어를 배포할 때 비로소 가치는 생겨난다. - 가치 있는 부분으로 나누어 배포하라.

- 일부 피처만 배포한다면 결과를 더 일찍 얻을 수 있다. 프로젝트의 방향이 올바른지를 빨리 확인할 수 있다. 적은 비용으로 성공여부를 미리 판단가능 - 작고 가치 있는 피처를 자주 배포할 때 최고의 가치를 얻을 수 있습니다. - 활동(계획,분석,설계,개발,테스트..)을 기반으로 한 제품은 100kg짜리 돌덩어리 같습니다. 프로젝트 막바지에 들어서면 비용을 줄일 방법이 거의 없습니다.

- 피처 단위로 프로젝트를 진행한다면 더 잘 예측할 수 있습니다. - 피처 단위 개발은 더 나은 정보, 더 나은 가이드, 더 많은 결과물을 만듭니다.

• 피처 단위로 조직 구성하기

- 기술분류로 팀을 구성한다면 한 피처를 완성하기 위해 여러 팀을 거쳐야한다. - 피처는 각 개발팀이 개발해야 합니다. - 학습공동체를 만드세요

• 피처 단위로 계획하기

- 아이젠하워 장군 "계획은 쓸모없을 때가 많습니다. 하지만 동시에 없어서는 안 될 부분입니다." - 프로젝트에 계획은 필요하다 하지만 언제 어떤일이 일어날지 하나하나 기록한 세부 목록 따위는 필요하지 않다. 때가 되면 다음에 무얼할지 결정하면 된다. 너무 세세한 계획은 시간만 낭비할 뿐, 혼란만 일으킵니다. - 먼저 개발해야 할 핵심 피처를 추리는 것이 중요합니다. (이것이 없으면 살 수 없을 정도록 중요한) - 가치가 낮은 피처는 최대한 뒤로 미루어야 한다. (여기에 시간 낭비 말고 언제든 찾아볼 수 있도록 기록만 ) - 계획을 세우되, 언제든지 변화를 줄 수 있는 환경을 만들자 - 지속적인 계획 : 피처 분리 - 프로젝트는 가치를 우선하므로 계획은 프로젝트 기간 내내 필요합니다. 1~2주의 주기(스프린트) 2~3일정도 규모의 피처(스토리)로 분리할 때 가장 좋은 결과를 낼 수 있다.

- 커다란 피처를 태스크단위로 쪼개는건 추천하지 않는다. 태스크 단위는 비개발자들이 개발 진행 상황을 명확히 알 수 없다. - 커다란 사용자 스토리는 비개발자도 쉽게 이해할 수 있는 작은 스토리로 쪼개는 것이 더 낫다. - 개발팀의 업무량 : '어제의 날씨' 방법. 오늘은 어제의 업무량만큼 일할 수 있다. --> 최근 주기의 작업량을 기준으로 업무량을 계획.

- 업무량을 결정하려면 현재 진행 중인 피처를 이해하고 있어야 한다. - 업무량을 개인별로 추정하는것은 결코 권하지 않습니다. 개인이 아닌 팀 전체를 이해하고 팀이 할 수 있는 양을 추정해야 합니다. - 이 일은 추정을 정확히 하고자 하는것이 아닙니다. 바로 제대로 된 일을 일관된 속도로 수행하기 위한 것입니다! - 추정은 위험합니다! 우리는 과장하거나 비교하려는 어쩔 수 없는 욕구를 가지고 있기 때문이죠. - 추정에 너무 집중하면 이런 책임감에서 멀어지게 되며, 정확한 추정을 해야 한다는 생각 때문에 보수적으로 추정하기 쉽습니다. - 구체적 추정 없이도 오늘날 많은 팀이 성공적으로 일을 해내고 있습니다. - 해야 할 일에 대해서만 생각합니다. 해야할 일을 잘게 부숩니다. 가치 있는 사용자 스토리 하나를 테스트할 수 있는 수준까지 쪼갭니다. 개발이 얼마나 걸릴지 예측해야 할 때는 단순히 완료된 것들을 세어 봄으로써 쉽게 추측할 수 있습니다.

- 무리한 목표는 자멸하는 길입니다. - 프로젝트를 계획하면서 '더 큰 목표를 계획'하거나 '피처 하나만 더 추가'하자고 개발팀을 설득하는 행동은 프로젝트 전체에 치명적인 손상을 입힙니다. - 이렇게 부탁하거나 설득하면 개발팀은 정말로 그렇게 해보고자 무의식적으로 서두르게 됩니다. --> 몇 가지 테스트는 생략합니다. 코드도 덜 깔끔해집니다. --> 서두르다보면 결함이 늘어납니다. 결함 방지보다 수정은 시간이 더 오래 걸립니다. --> 프로젝트 일정 지연 --> 더 최악은 프로젝트 막바지에 다다라 더 늦어지면 안 될때 이 현상이 더 심해진다는 점

- 지저분한 코드는 일정을 지연시킵니다. 지저분한 코드는 모든것을 더 느리게 만듭니다. - 압박하는 행동은 치명적입니다. 절대 하지 마세요. - 추정 없이 진행해봅시다 - 소프트웨어 개발에서 추정은 아직도 논란이 많습니다. - 일반적으로 프로젝트 추정은 어긋나기 마련입니다.

- 자주 계획하고, 다음에 할 일을 정하세요. 과욕은 금물입니다. - 가끔 업무량 조절 실패로 평소보다 터무니없이 많은 업무를 해야 할 때도 있습니다. 그러나 절대 업무량을 초과해 일하면 안됩니다. - 초과 업무는 팀을 무기력하게 만들고 건강을 해칩니다. 무기력하고 건강하지 못한 코드로는 제대로 일할 수 없습니다. - 팀이 감당할 수 있는 업무량을 초과했다고 깨달았다면 즉시 업무를 덜어내야 합니다.

- 피처 단위로 개발하기 - 짧은 주기마다 작지만 완전한 제품을 완성하세요. - 개발팀에 요청하는 피처는 이해하기 어려운 기술적인 무언가가 되면 안 됩니다. 실제 눈에 보이고 작동하는 피처여야 합니다. - 비지니스 담당자는 거대하고 모호하며 광범위한 요구 사항을 작고 실질적인 피처들로 분리하는 능력을 길러야 합니다. - 제품에 반드시 있어야 하는 피처와 단순히 있으면 좋은 피처를 구분하여 제품이 가진 특징을 더욱 뚜렷하게 만들어야 합니다.

- 제품이 성장할 때마다 설계를 확장하고 개선해야 합니다. - 피처와 기반(아키텍처, 디자인, 인프라)을 동시에 - 각 피처는 견고한 기반, 견고한 인프라가 필요합니다. - 피처는 계속 추가되고 개선됩니다. - 설계도 계속 변화합니다. 그 과정에서 실수할 수도 있습니다. 그래서 끊임없이 종합적으로 테스트해야 합니다.

- 오직 테스트만이 결함을 최소화하는 방법입니다. - 테스트는 비지니스와 개발자 관점으로 나눠 진행해야 합니다. - 개발 주기가 끝날 때마다 반드시 비지니스 테스트를 수행합니다. - 새로운 피처 뿐만 아니라 이전에 있던 피처들에 문제는 없는지도 확인해야 합니다. - 새로운 피처를 추가할 때마나 테스트 부담은 점점 더 커지게 됩니다. 이 부담을 적정 수준으로 관리해야 합니다. - 그러기 위해서는 테스트에서 사용하는 비지니스 용어로 피처를 서술하고, 테스트를 자동화합니다. 이러한 방법 중 유명한 것이 바로 인수테스트 주도 개발(ATDD)입니다. - 개발 단계에서도 더 자주 테스트를 수행해야만 합니다.

Part 2. 메모와 에세이

- 가치 : 우리가 원하는 것, 정보, 삶, 자본금, 제품 배포 속도, 빠른 속도, 행복

- 소프트웨어 개발을 진행할 때, 우리는 구불구불한 길을 헤쳐 나가야 합니다. 하지만 이것만은 기억하세요. - 항상 가치에 집중할 것, 가치를 기준으로 계획하고 관리할 것, 사용자가 어떤 반응을 보이는지 살펴볼 것.

• 성장하는 개발팀 만들기

- 제품 책임자는 제품의 목적을 제시해야 합니다. - 제품 책임자는 매일 팀과 소통해야 한다. 왜 이 일을 해야 하는지, 가장 중요한 문제는 무엇인지, 어떻게 이 문제를 해결할 수 있는지 의견을 나눈다. - 제품 책임자가 논의나 문제 제기 없이 해결책만 제시하는 경우 개발팀의 목표 의식을 얻을 수 없으므로 팀의 생산성은 크게 떨어진다. - 자율성은 팀에게 책임감을 부여합니다. - Self-Organizing 팀 : 자율성이 높고 문제해결에 창의성을 더 많이 발휘, 생산성도 높아짐 - 제품이 나아가야 할 목표를 함께 이해하는 숙련된 자기 조직화 팀이 되는 것이 핵심입니다.

- 인사 활동은 관리 부서에서 다루어야 합니다. 하지만 구성원 선택, 추천은 팀에게 위임해야 합니다. 충원여부도.. - 전반적 채용 가이드라인, 계획 등을 팀이 이해할 수 있도록 도와줘야 한다. - 팀이 큰 그림을 잘 이해할수록 더 나은 결과를 보여줍니다.

• 경영진은 어떤 프로젝트와 제품에 투자할지를 결정해야 합니다.

- 개발 주기마다 제품을 볼 수 있다면 큰 문제가 생길 확률은 불가능에 가깝습니다. - 일단위 관리는 개발팀이 결정, 제품 책임자는 주단위로 관리, 경영진은 작업 결과물을 살펴보고 진행상황이 예산과 시간에 어울리는지 검토 - 이 때 프로젝트와 맞지 않는 부분이 있다면 직접개입하지 않고 해결. 조언과 훈련을 제공하되 필요하다면 예산과 인력, 책임을 조정한다. - 소프트웨어 개발의 본질적인 방법은 일하는 사람에게 권한을 위임하는 것입니다.

• 더 강한 채찍질

- 압박 > 불충분한 테스트 > 나쁜 코드 방치 > 가치를 떨어뜨리고 > 가치를 얻는데 필요한 일정을 지연시킴 > 제품의 가치하락 > 배포가 늦어짐 - 더 많은 피처를 원하는 조직 : "안돼요"라는 말을 못하는 조직, 결정하기보다 주문을 받는 조직, 가치있어 보이는 것을 개발하고 있지만 대부분 사용자와 제품에 전달하지 못함 - 교묘한 압박 : "속도를 내세요"라고 말하기 > 품질과 추정이라는 보이지 않는 다이얼을 돌림으로써 더 많은 것을 만들려고 할것이다. - 압박을 받는 개발팀은 의식적이든 아니든 보수적으로 일하게 됨. 평소보다 더 크고 더 어렵게 등급을 매기기 시작함. 그래야 그들이 더 빠르게 일한다는 인상을 주기위해

• 개발을 빠르게..

- 지연원인을 분석하라 - 개개인의 생산성보다는 팀이 가진 생산성에 주목하라 - 팀이 필요한 모든 기술을 가지고 있게 하라 - 핵심 기술을 가진 팀원은 파트타임이 아닌 풀타임이어야 한다. - 훈련과 교육에 투자하는 것은 생산성으로 되돌아온다. - 절대 채찍질해서는 안 됩니다. 다만 그들이 성장하도록 도와주세요.

• 개발 속도를 내기 위해 우리가 할 수 있는 가장 가치 있는 일은 바로 개발팀의 빌드 기술을 향상시키는 것입니다. 빌드 기술 향상에 투자하면 결함을 수정하는데 들이는 시간을 줄여주고, 부드러운 개발과 같은 형태를 통해 빠르게 되돌아옵니다.
  
• 애자일 확장 : 애자일은 확장할 필요가 없습니다. 오래전부터 있던 간결한 애자일 소프트웨어 개발을 계획할 필요가 있습니다.

- 확장된 애자일은 간결해야 합니다. 그렇지 않다면 애자일이 아닙니다.