Cargando…
Building software teams : ten best practices for effective software development /
| Clasificación: | Libro Electrónico |
|---|---|
| Autor principal: | |
| Formato: | Electrónico eBook |
| Idioma: | Inglés |
| Publicado: |
Sebastopol, CA :
O'Reilly Media,
2016.
|
| Temas: | |
| Acceso en línea: | Texto completo (Requiere registro previo con correo institucional) |
Tabla de Contenidos:
- Copyright; Table of Contents; About the Authors; Preface; The Topic of This Book; Why You Should Read This Book; Who Should Read This Book; What You Need to Know to Read This Book; What This Book Is Not; About the Software Improvement Group (SIG); Related Books; Conventions Used in This Book; O'Reilly Safari; How to Contact Us; Acknowledgments; Chapter 1. Introduction; 1.1 Software Development as an Observable Process; 1.2 Software Quality According to the ISO 25010 Standard; Software Product Quality in ISO 25010; 1.3 The Contribution of Each Developer Matters.
- 1.4 Measuring and Benchmarking Development Process Maturity1.5 The Goal-Question-Metric Approach; 1.6 An Overview of the Development Best Practices in This Book; Chapter 2. Derive Metrics from Your Measurement€Goals; 2.1 Motivation; 2.2 How to Apply the Best Practice; Goal; Question; Metric; 2.3 Make Assumptions about Your Metrics Explicit; Find Explanations Instead of Judgments When Metrics Deviate from Expectations; Using Norms with the GQM Approach; 2.4 Common Objections to GQM; Objection: Yes, Good Metric, but We Cannot Measure This; Chapter 3. Make Definition of Done Explicit.
- 3.1 MotivationWith a DoD You Can Track Progress and Prove Success; A DoD Focuses on Software Quality; 3.2 How to Apply the Best Practice; 3.3 Common Objections to Using Definition of Done; Objection: DoD Is Too Much Overhead; Objection: DoD Makes the Team Feel Less Responsible; Objection: With DoD There Is No Room for Technical Maintenance; Objection: Changing the DoD May Mean Extra Work; Chapter 4. Control Code Versions and Development€Branches; 4.1 Motivation; Tracking Changes; Version Control Allows Independent Modification; Version Control Allows Automatic Merging of Versions.
- 4.2 How to Apply the Best PracticeCommit Specifically and Regularly; Integrate Your Code Regularly; 4.3 Controlling Versions in Practice; 4.4 Common Objections to Version Control Metrics; Objection: We Use Different Version Control Systems; Objection: Measuring the Recommendations Is Unfeasible (for Example, Whether Commits Are Specific); 4.5 Metrics Overview; Chapter 5. Control Development, Test, Acceptance, and Production Environments; 5.1 Motivation; Controlled DTAP Clarifies Responsibilities Between Development Phases; Controlled DTAP Allows for Good Predictions.
- Controlled DTAP Reveals Development Bottlenecks and Explains Problems More EasilyControlled DTAP Reduces Dependence on Key Personnel; 5.2 How to Apply the Best Practice; 5.3 Measuring the DTAP Street in Practice; 5.4 Common Objections to DTAP Control Metrics; Objection: A Controlled DTAP Street Is Slow; Objection: There Is No Need to Distinguish Test and Acceptance Environments; 5.5 Metrics Overview; Chapter 6. Automate Tests; 6.1 Motivation; Automated Testing Finds Root Causes of Bugs Earlier with Little Effort; Automated Testing Reduces the Number of Bugs; 6.2 How to Apply the Best Practice.