Lean Software Systems Engineering for Developers: Managing Requirements, Complexity, Teams, and Change Like a Champ

✍ Scribed by Doug Durham

• Publisher: Apress
• Year: 2021
• Tongue: English
• Leaves: 214
• Edition: 1
• Category: Library

✦ Synopsis

Beginning-Intermediate user level

✦ Table of Contents

Table of Contents
About the Authors
About the Technical Reviewer
Acknowledgments
Foreword
Introduction
Chapter 1: Focusing on Software Development Outcomes Instead of Outputs
Introduction
Software Engineering vs. Software Development
Coding Is Not Software Engineering
Defining Software Engineering
Why Does Software Engineering Matter?
Errors in Judgment
Managing the Dimensions of Complexity in Software Development
Objective Complexity
Requirements Complexity
Solution Complexity
Agility Comes from Managing Both Requirements and Solution Complexity
Our Responsibility
A Path Forward
Summary
Key Takeaways
Chapter 2: Gaining a Shared Understanding Throughout the Project
Introduction
Sources of Defects and Rework
The Danger of Incomplete Pictures
Why Developing a Shared Understanding Early Is Important
Adding Structured Processes
Leveraging Lean Approaches to Backlog Development
Journey Mapping and Story Mapping
Using Critical Thought to Decompose Requirements
How Other Engineers Tackle Big Problems
Estimation Scales
Estimating Our “Submit Order” Story
Summary
Key Takeaways
Chapter 3: Validation of User Experience
Introduction
The Evolution of UI Design
Challenges with Modern UI Design
Scenario 1: Technology
Constraints of the Modern Web Frameworks
Business Logic Bleeding into the UI Layer
Scenario 2: Process
Missing Artifacts
No Accommodation for UI Design Time
Failure to Communicate
Strategy for Effective UI Validation
Generate Good Requirements
Develop Acceptance Criteria
Develop Screen Flows and Wireframes
Review the Preliminary UI Design
Develop Mockups
Review the Mockups
Design the UI Components
Define the Client/Server Interactions
Build the UI Using Mock Data
Review the Working UI
Integrate Working UI with the Real Back End
Summary
Key Takeaways
Chapter 4: Designing Software Systems That Age Well and Adapt to Change
Introduction
Reality Check
Errors in Judgment Revisited
Case Study: Notification Subsystem
Change 1: Supplier Order Email
Change 2: Order Shipped Notices
Change 3: New SMTP Service
Change 4: Order Notices for Shipping
Change 5: Abandoned Cart Notices
Change 6: The Change That Forces the Redesign Conversations
The Redesign
What Critical Thought Might Have Uncovered
Tactical vs. Strategic Development
Case Study Wrap-Up: Common Errors in Judgment
Lack of a Design Identity and a Defined/Disciplined Methodology
Decomposing Systems Based upon Requirements Instead of Change
Thinking Tactically Instead of Strategically
Lack of Understanding of Core Concepts and Principles and the Impacts of Design Decision Trade-offs
Allowing Material Design Decisions to Be Made by Anyone
Stagnant Mental Models for Software Systems
Core Concepts and Principles of Modern System Design
Coupling and Cohesion
Information Hiding
Trade-offs Are the Norm
Information Hiding Hierarchies
Why Designing for Change Is Important
Design Stamina
Increased Comprehensibility
Meeting the Demands of Modern Applications and Business Agility
Managing Complexity in Other Systems
Choosing a Design Methodology
Summary
Key Takeaways
Chapter 5: Developers “Falling into the Pit of Success”
Introduction
Reality Check
A Developer’s Life
A Bad Week
Sound Familiar?
Creating a Pit of Success for Developers
Positive/Can-Do Team Attitude
Ensuring Requirements and Acceptance Criteria Are Understood
What Is My Understanding of the Requirements? What Is the Primary Goal or Objective?
What Are the Secondary Goals/Objectives?
What Are the Known Design Constraints?
What Are the Acceptance Criteria for the Solution (Including Non-functional)?
What Assumptions Am I Making About These Requirements and the System?
What Are the Unknowns? (i.e., What Information Is Not Currently Available?)
What Are the Trade-offs I Am Deliberately Making?
What Areas/Features Are Most Likely to Change over Time?
What Are Anticipated/Possible Failure Scenarios, and How Should They Be Handled?
Are There Any Special Considerations Related to Security?
What Are the Existing Areas Impacted?
How Will the Design/Architecture Need to Change?
How Can I Encapsulate Current and Future Change?
How Should I Test and Validate the System?
What Risks Am I Aware Of?
What Concerns Do I Have?
What Are the Specific Steps to Implemention, and What Is Their Level of Effort?
UI Design Artifacts Before Development
Design Identity
Service-Based Systems
Reviewing and Verifying the Design
Testability
Deciding What to Unit Test
Isolating Developer Environments
Maker Schedule
Mentor
Establishing Clear Developer Expectations
Pit of Success Checklist
Summary
Key Takeaways
Chapter 6: Institutionalized Quality
Introduction
Reality Check
Moving Fast vs. Maintaining a Rapid Pace
Toward an Integrated, Layered View
Quality Targets
Defect Detection Rate
Percentage of Rework
Quality Mindset
Quality Practices Review
During Requirements Analysis
Shared Understanding
Validation of the UI
During Design
Validation of the UI
Designing Systems That Age Well
Designing How to Execute the Project
During Development
Establishing Clear Developer Expectations
Reviewing the Requirements and Design Artifacts
Ensuring Requirements and Acceptance Criteria Are Understood
Enabling a Testable System
Implementing Continuous Integration with Automated Integration and Unit Tests
Using Structured Code Reviews and Pull Requests
Pull Request Code Review Checklist
Review Before Submitting
Testing
Architecture
General Code Review
New Projects
Database Changes
UI Changes
Cloud Architecture Changes
During Acceptance Testing and QA Testing
Summary
Key Takeaways
Chapter 7: The Role of Chief Engineer
Introduction
Revisiting the Football Analogy
Chief Engineer
Responsibilities of a Chief Engineer
Maintaining the Big Picture
Maintaining Conceptual Integrity
Seeing Around Corners
Coaching and Mentoring
Building Trusted Relationships
Being a Proactive Communicator
Ensuring Adequate Testing
Achieving Technical Success of the System
Summary
Key Takeaways
Chapter 8: Bringing It All Together – Creating an Action Plan
Introduction
What It Will Mean for Software Development to Be an Engineering Discipline
Starting Your Transformation
Understanding the Maturity of Your Team
Lightweight Organizational Maturity Assessment
Leadership Roles
Managing Requirements Complexity
Solution Complexity
Operational Effectiveness
The Steps Toward Transformation
Secure Your Platform
Minimize Uncertainty
Automate Your Builds
Protect Your Developer Time
Maintain Conceptual Integrity
Improve Your Productivity by Improving Quality
Reduce Rework
Improve Predictability and Visibility of Results
Achieving the Ultimate “-ility”… Funability
What Contributes to Funability
Frequent Delivery of Value to Customers
Being Part of a Team
Maintainability of Systems
Effective Management of Technical Debt
Consistent Quality of Product Releases
Productivity and Efficiency of the Developers
Sound Software Design
Now What?
Key Takeaways
Index