to Accomplish?PostludeRecommended Additional Reading
| PART III | | SMALL-SCALE DEVELOPMENT WITH PRACTICES |
| Chapter 13 | | Kick-Starting Development with Practices13.1 Understand the Context Through the Lens of Essence13.2 Agree upon Development Scope and Checkpoints13.3 Agree upon Practices to Apply13.4 Agree upon the Important Things to Watch13.5 Journey in BriefWhat Should You Now Be Able to Accomplish? |
| Chapter 14 | | Running with Scrum14.1 Scrum Explained14.2 Practices Make a Software Engineering Approach Explicit and Modular14.3 Making Scrum Explicit Using Essence14.4 Scrum Lite Alphas14.5 Scrum Lite Work Products14.6 Scrum Lite Roles14.7 Kick-Starting Scrum Lite Usage14.8 Working with Scrum Lite14.9 Reflecting on the Use of Scrum with EssenceWhat Should You Now Be Able to Accomplish? |
| Chapter 15 | | Running with User Story Lite15.1 User Stories Explained15.2 Making the User Story Lite Practice Explicit Using Essence15.3 User Story Lite Alphas15.4 User Story Lite Work Products15.5 Kick-Starting User Story Lite Usage15.6 Working with User Story Lite15.7 The Value of the Kernel to the User Story Lite PracticeWhat Should You Now Be Able to Accomplish? |
| Chapter 16 | | Running with Use Case Lite16.1 Use Cases Explained16.2 Making the Use Case Lite Practice Explicit Using Essence16.3 Use Case Lite Alphas16.4 Use Case Lite Work Products16.5 Kick-Starting Use Cases Lite to Solve a Problem Our Team Is Facing16.6 Working with Use Cases and Use-Case Slices16.7 Visualizing the Impact of Using Use Cases for the Team16.8 Progress and Health of Use-Case Slices16.9 User Stories and Use Cases—What Is the Difference?What Should You Now Be Able to Accomplish? |
| Chapter 17 | | Running with Microservices17.1 Microservices Explained17.2 Making the Microservice Practice Explicit Using Essence17.3 Microservices Lite17.4 Microservices Lite Alphas17.5 Microservices Lite Work Products17.6 Microservices Lite Activities17.7 Visualizing the Impact of the Microservices Lite Practice on the Team17.8 Progress and Health of Microservice DevelopmentWhat Should You Now Be Able to Accomplish? |
| Chapter 18 | | Putting the Practices Together: Composition18.1 What Is Composition?18.2 Reflecting on the Use of Essentialized Practices18.3 Powering Practices through EssentializationWhat Should You Now Be Able to Accomplish?Recommended Additional Reading |
| PART IV | | LARGE-SCALE COMPLEX DEVELOPMENT |
| Chapter 19 | | What It Means to Scale19.1 The Journey Continued19.2 The Three Dimensions of ScalingWhat Should You Now Be Able to Accomplish? |
| Chapter 20 | | Essentializing Practices20.1 Practice Sources20.2 Monolithic Methods and Fragmented Practices20.3 Essentializing Practices20.4 Establishing a Reusable Practice ArchitectureWhat Should You Now Be Able to Accomplish? |
| Chapter 21 | | Scaling Up to Large and Complex Development21.1 Large-Scale Methods21.2 Large-Scale Development21.3 Kick-Starting Large-Scale Development21.4 Running Large-Scale Development21.5 Value of Essence to Large-Scale DevelopmentWhat Should You Now Be Able to Accomplish? |
| Chapter 22 | | Reaching Out to Different Kinds of Development22.1 From a Practice Architecture to a Method Architecture22.2 Establishing a Practice Library within an Organization22.3 Do Not Ignore Culture When Reaching OutWhat Should You Now Be Able to Accomplish? |
| Chapter 23 | | Reaching Out to the Future23.1 Be Agile with Practices and Methods23.2 The Full Team Owns Their Method23.3 Focus on Method Use23.4 Evolve Your Team’s MethodWhat Should You Now Be Able to Accomplish?Recommended Additional Reading |
| Appendix A | | A Brief History of Software and Software Engineering |
| | References |
| | Index |
| | Author Biographies |
Foreword by Ian Sommerville
There’s some debate over whether the term software engineering was first coined by Margaret Hamilton at NASA in the 1960s or at the NATO conference at the end of that decade. It doesn’t really matter because 50 years ago it was clear that software engineering was an idea whose time had come.
Since then, developments in software engineering have been immense. Researchers and practitioners have proposed many different methods and approaches to software engineering. These have undoubtedly improved our ability to create software, although I think it is fair to say that we sometimes don’t really understand why. However, we have no basis for comparing these methods to see if they really offer anything new and we can’t assess the limitations of software engineering methods without experiencing failure. Although we are a lot better at developing software than we were in the 20th century, it is still the case that many large software projects run into problems and the software is delivered late and fails to deliver the expected value.
The SEMAT initiative was established with the immense ambition to rethink software engineering. Rather than inventing another new method, however, Ivar Jacobson and his collaborators went back to first principles. They examined software engineering practice and derived a common underlying language and kernel (Essence) that could be used for discussing and describing software engineering. Essence embodies the essential rather than the accidental in software engineering and articulates new concepts such as alphas that are fundamental to every development endeavor.
Essence is not a software engineering method but you can think of it as a meta-method. You can use it to model software engineering methods and so compare them and expose their strengths and weaknesses. More importantly, perhaps, Essence can also be the starting point for a new approach to software engineering. Because of the universality of the concepts that it embodies, Essence can be used across a much wider range of domains than is possible with current methods. It wisely separates the notion of specific practices, such as iterative development, from fundamental concepts so it can be used in a variety of settings and application domains.
The inventors of Essence understand that the value of Essence can only be realized if it is widely used. Widespread
