책/The nature of software development (6) 썸네일형 리스트형 2. 메모와 에세이 (22) 결론 Part 2. 메모와 에세이 Chapter22. 결론 Chapter22. 결론 2. 메모와 에세이 (20~21) 애자일 방법들 Part 2. 메모와 에세이 Chapter.20 애자일 방법들 Chapter.20 애자일 방법들 Chapter.21 애자일 확장 확장된 애자일은 판매회사를 늘릴 좋은 기회입니다. 하지만 이 말이 항상 좋은 조언일 수는 없겠죠. 항상 원하는 것을 얻을 수는 없다? 애자일은 간결합니다. 하지만 쉽지 않죠 확장된 애자일은 간결해야 합니다. 그렇지 않다면 애자일이 아니죠. 개발팀이 진정 애자일하다면... 단 하나의 작은 팀으로 개발할 수 있다면요? 하나의 개발팀이 할 수 있는 것보다 더 많은 것을 원할 때는 어떻게 하죠? 피처 개발팀 애자일 팀은 테스트를 통해 협업합니다. 피처 개발팀은 좋네요. 하지만 공통 인프라는 어떻게 하죠? 아직은 좋습니다. 거대한 규모의 개발 먼저, 규모를 점진적으로 성장시키세요. 최종.. 2. 메모와 에세이 (17~19) 더 강한 채찍질 Part 2. 메모와 에세이 Chapter17. 더 강한 채찍질 Chapter17. 더 강한 채찍질 Chapter18. 속도를 내기 위한, 특별한 빌드 기술 Chapter19. 리팩토링 좁고 구불구불한 길 리팩토링은 길을 정돈하는 작업입니다. 모든 길이 전부 구불거린다면 무엇을 해야 할까요? 2. 메모와 에세이 (15~16) 초기 계획을 위한 '파이브 카드' Part 2. 메모와 에세이 Chapter15. 초기 계획을 위한 '파이브 카드' Chapter15. 초기 계획을 위한 '파이브 카드' Chapter16. 경영진을 위한 소프트웨어 개발의 본질 장기적인 목표에는 어떻게 접근하는 것이 좋을까? 월이나 연 단위의 프로젝트 계획은 어떻게 세울까? 일이나 주 단위의 단기 계획은? 제 관리 경험은 대부분 프로젝트를 올바른 길로 이끄는 것이었습니다. 계획을 잘 따라가고 있는지 어떻게 확신할 수 있을까요? 어떻게 해야 최선의 결정을 내릴 수 있을까요? 인사 결정은 어떻게 하나요? 채용과 해고는 누가 결정하나요? 경영진은 프로젝트가 나아가야 할 방향을 제시해야 합니다. 하지만 업무는 반드시 관리돼야 합니다. 일 단위로 모든 것이 제대로 관리되는지 어떻게 확신할 수 있을.. 1. 가치를 이루는 것들 (3~4) 피처 단위 개발을 위한 가이드라인 [The nature of software development] Part 1. 가치를 이루는 것들 Chapter 3. 피처 단위 개발을 위한 가이드라인 Chapter 3. 피처 단위 개발을 위한 가이드라인 프로젝트를 진행할 때 가장 먼저 알아야 할 것은 바로 마감 일정이다. 마감일 전에 원하는 피처 모두를 얻을 수는 없다. 프로젝트를 그대로 두는 것보다 현실적으로 관리하는 것이 필요하다. Q. 최근 참여한 프로젝트에서 제대로 진행되지 않은 일 중 중요한 일이 무엇이었나요? - 9개의 습관 버튼 구현하는 것. Q. 제대로 진행했지만 실제로는 시간만 낭비했던 일은 무엇이었나요? - 홈페이지에 넣은 사진은 사실 큰 가치는 제공하지 않는다. Q. 너무 늦었거나 늦을 뻔했던 적이 있었는지도 생각해봅시다. - 코.. 1. 가치를 이루는 것들 (1~2) 가치 [The nature of software development] Part 1. 가치를 이루는 것들 더 좋은 방법이 있다. 본질적인 소프트웨어 개발 방법론 가치를 빠르게, 자주 전달하는데 집중한다. 길을 잃어버릴 수도 있다. 더 나은 길은 있다는 것을 기억하자. 이 책을 어떻게 읽을 것인가? 본질적인 방법은 사용자, 비즈니스, 경영진, 개발자 모두에게 도움이 된다. 이 책이 이런 내용이구나 하고 넘어가지 말고 1. 어떤 가치가 있을지 2. 어떻게 적용할지 깊이 생각한다. 이 책은 어떤 책인가? 방법을 설명하지 않는다. 방법이 어떻게 적용될 수 있는지 설명한다. 여러 길이 있고 찾는 것은 우리의 몫이다. Part 1 가치를 이루는 것들 소프트웨어 개발을 성공으로 이끌기는 어렵다. 소프트웨어 개발을 유연하고.. 이전 1 다음