reklama - zainteresowany?

Building Software Teams. Ten Best Practices for Effective Software Development - Helion

Building Software Teams. Ten Best Practices for Effective Software Development
ebook
Autor: Joost Visser, Sylvan Rigal, Gijs Wijnholds
ISBN: 978-14-919-5181-1
stron: 136, Format: ebook
Data wydania: 2016-12-12
Księgarnia: Helion

Cena książki: 80,74 zł (poprzednio: 94,99 zł)
Oszczędzasz: 15% (-14,25 zł)

Dodaj do koszyka Building Software Teams. Ten Best Practices for Effective Software Development

Why does poor software quality continue to plague enterprises of all sizes in all industries? Part of the problem lies with the process, rather than individual developers. This practical guide provides ten best practices to help team leaders create an effective working environment through key adjustments to their process.

As a follow-up to their popular book, Building Maintainable Software, consultants with the Software Improvement Group (SIG) offer critical lessons based on their assessment of development processes used by hundreds of software teams. Each practice includes examples of goalsetting to help you choose the right metrics for your team.

  • Achieve development goals by determining meaningful metrics with the Goal-Question-Metric approach
  • Translate those goals to a verifiable Definition of Done
  • Manage code versions for consistent and predictable modification
  • Control separate environments for each stage in the development pipeline
  • Automate tests as much as possible and steer their guidelines and expectations
  • Let the Continuous Integration server do much of the hard work for you
  • Automate the process of pushing code through the pipeline
  • Define development process standards to improve consistency and simplicity
  • Manage dependencies on third party code to keep your software consistent and up to date
  • Document only the most necessary and current knowledge

Dodaj do koszyka Building Software Teams. Ten Best Practices for Effective Software Development

 

Osoby które kupowały "Building Software Teams. Ten Best Practices for Effective Software Development", wybierały także:

  • Windows Media Center. Domowe centrum rozrywki
  • Ruby on Rails. Ćwiczenia
  • DevOps w praktyce. Kurs video. Jenkins, Ansible, Terraform i Docker
  • Przywództwo w Å›wiecie VUCA. Jak być skutecznym liderem w niepewnym Å›rodowisku
  • Scrum. O zwinnym zarzÄ…dzaniu projektami. Wydanie II rozszerzone

Dodaj do koszyka Building Software Teams. Ten Best Practices for Effective Software Development

Spis treści

Building Software Teams. Ten Best Practices for Effective Software Development eBook -- spis treści

  • 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
    • OReilly Safari
    • How to Contact Us
    • Acknowledgments
  • 1. Introduction
    • Software Development as an Observable Process
    • Software Quality According to the ISO 25010 Standard
      • Software Product Quality in ISO 25010
    • The Contribution of Each Developer Matters
    • Measuring and Benchmarking Development Process Maturity
    • The Goal-Question-Metric Approach
    • An Overview of the Development Best Practices in This Book
  • 2. Derive Metrics from Your Measurement Goals
    • Motivation
    • How to Apply the Best Practice
      • Goal
      • Question
      • Metric
    • Make Assumptions about Your Metrics Explicit
      • Assumption: Measurements are comparable
      • Assumption: Trends are more important than precise facts
      • Assumption: Averages are more important than outliers
      • Find Explanations Instead of Judgments When Metrics Deviate from Expectations
      • Using Norms with the GQM Approach
    • Common Objections to GQM
      • Objection: Yes, Good Metric, but We Cannot Measure This
  • 3. Make Definition of Done Explicit
    • Motivation
      • With a DoD You Can Track Progress and Prove Success
      • A DoD Focuses on Software Quality
    • How to Apply the Best Practice
    • 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
  • 4. Control Code Versions and Development Branches
    • Motivation
      • Tracking Changes
      • Version Control Allows Independent Modification
      • Version Control Allows Automatic Merging of Versions
    • How to Apply the Best Practice
      • Commit Specifically and Regularly
      • Integrate Your Code Regularly
    • Controlling Versions in Practice
    • 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)
    • Metrics Overview
  • 5. Control Development, Test, Acceptance, and Production Environments
    • Motivation
      • Controlled DTAP Clarifies Responsibilities Between Development Phases
      • Controlled DTAP Allows for Good Predictions
      • Controlled DTAP Reveals Development Bottlenecks and Explains Problems More Easily
      • Controlled DTAP Reduces Dependence on Key Personnel
    • How to Apply the Best Practice
    • Measuring the DTAP Street in Practice
    • Common Objections to DTAP Control Metrics
      • Objection: A Controlled DTAP Street Is Slow
      • Objection: There Is No Need to Distinguish Test and Acceptance Environments
    • Metrics Overview
  • 6. Automate Tests
    • Motivation
      • Automated Testing Finds Root Causes of Bugs Earlier with Little Effort
      • Automated Testing Reduces the Number of Bugs
    • How to Apply the Best Practice
    • Managing Test Automation in Practice
      • Assumptions Regarding These Metrics
    • Common Objections to Test Automation Metrics
      • Objection: Failing Tests Have No Noticeable Effects
      • Objection: Why Invest Effort in Writing Unit Tests for Code That Is Already Working?
    • Metrics Overview
  • 7. Use Continuous Integration
    • Motivation
      • CI Is Efficient
      • CI Gives Feedback Quickly and Thereby Speeds Up Bug Fixing
      • CI Is More Reliable Than Manual Merging
      • CI Facilitates Further Automation
    • How to Apply the Best Practice
      • Requirement: Version Control
      • Requirement: Automated Builds
      • Requirement: CI Server
      • Requirement: Automated Tests
      • Additions to the CI Server
      • Important Best Practices for CI
    • Controlling Continuous Integration
    • Common Objections to Continuous Integration Metrics
      • Objection: We Cannot Get Control Over Our Build Time
      • Objection: My Colleague Broke the Build, Not Me
    • Metrics Overview
  • 8. Automate Deployment
    • Motivation
      • Automated Deployment Is Reliable
      • Automated Deployment Is Fast and Efficient
      • Automated Deployment Is Flexible
      • Automated Deployment Simplifies Root Cause Analysis
    • How to Apply the Best Practice
    • Measuring the Deployment Process
    • Common Objections to Deployment Automation Metrics
      • Objection: Single Platform Deployment Does Not Need Automation
      • Objection: Time Spent on Fixing Deployment Issues Is Increasing
      • Objection: We Are Not Allowed to Deploy in Production By Ourselves
      • Objection: No Need to Automate Because of Infrequent Releases
      • Objection: Automating Deployment Is Too Costly
    • Metrics Overview
  • 9. Standardize the Development Environment
    • Motivation
      • Development Standards Lead to Predictable Software Development
      • Development Standards Help Enforce Best Practices
      • Development Standards Simplify Both the Development Process and Code
      • Development Standards Decrease Discussion Overhead
    • How to Apply the Best Practice
      • Standardize Tooling and Technologiesand Document It
      • Considerations for Combinations of Technologies
      • Defining Process Standards
      • Coding Style
      • Code Quality Control
    • Controlling Standards Using GQM
    • Common Objections to Standardization
      • Objection: We Cannot Work Like This!
      • Objection: Can You Standardize on Multiple Technologies?
      • Objection: Organization Unfit for Standardization
    • Metrics Overview
  • 10. Manage Usage of Third-Party Code
    • Motivation
      • Using Third-Party Code Saves Time and Effort
      • Third-Party Code Has at Least Base-Level Quality
      • Managing Usage of Third-Party Code Makes a Systems Behavior More Predictable
    • How to Apply the Best Practice
      • Determine the Specific Maintainability Advantages of Using an External Codebase
      • Keep Third-Party Code Up-to-Date
      • Ensure Quick Response to Dependency Updates
      • Do Not Let Developers Change Library Source Code
      • Manage the Usage and Versions of Libraries and Frameworks Centrally
    • Measuring Your Dependency Management
    • Common Objections to Third-Party Code Metrics
      • Objection: Safety and Dependability of Third-Party Libraries
      • Objection: We Cannot Update a Particular Library
      • Objection: Does Third-Party Code Actually Lead to Maintenance Benefits?
    • Metrics Overview
  • 11. Document Just Enough
    • Motivation
      • Documentation Retains Knowledge and Helps to Avoid Discussion
      • Documentation Helps You to Know Whether You Are Reaching Your Goals
    • How to Apply the Best Practice
      • Keep Documentation Current, Concise, and Accessible
      • Required Elements of System Documentation
        • Quality control is enforced to keep the nonfunctional requirements in check
    • Managing Your Documentation
    • Common Objections to Documentation
      • Objection: No Time to Write Documentation
      • Objection: Disagreement in the Team
      • Objection: Knowledge about System Is Scattered
    • Metrics Overview
  • 12. Next Steps
    • Applying the Best Practices Requires Persistence
    • One Practice at a Time
    • Avoid the Metric Pitfalls
    • What Is Next?
  • Index

Dodaj do koszyka Building Software Teams. Ten Best Practices for Effective Software Development

Code, Publish & WebDesing by CATALIST.com.pl



(c) 2005-2024 CATALIST agencja interaktywna, znaki firmowe należą do wydawnictwa Helion S.A.