RI TE Shipping Software AL 1 MA WHAT’ S IN THIS CHAPTER? Understanding what you need to ship software: vision, insight, resources, planning, and product features. ➤ Understanding three approaches to management methodologies: Scrum, MSF, and Waterfall. ➤ Comparing the three project management methodologies. GH TE D ➤ PY RI This chapter covers the high-level process of shipping software. You’ll learn how to start with a compelling vision and the resources you need to build a product.
❘ CHAPTER 1 SHIPPING SOFTWARE to solve. So, shipping great software really begins with vision and insight into how something works, how it can be improved, and why people care. This section discusses the following requirements for shipping software: ➤ Vision ➤ Insight ➤ Resources ➤ Planning ➤ Product features Vision Great software starts with a great vision. It starts with a simple description of what you’re setting out to build, for whom, and why.
What Do You Need to Ship Software? ❘ 3 Based on your vision, the reader will conjure up ideas about what the product may do. It’s a good start, but this vision, as stated, is much broader than your intent. Your idea involved fantasy football, and the vision you’ve created could be interpreted much more broadly. Therefore, you might rewrite the vision as follows: Many websites are available for fantasy football leagues. They have great features but lack powerful search capabilities.
❘ CHAPTER 1 SHIPPING SOFTWARE role in engineering and design. It involves translating the needs and desires of the user or market into instructions for engineering. (We use the term instructions very loosely here, as it may take the form of requirements, storyboards, user stories, mockups, visual comps, or other design artifacts.) As you’ll read in Chapter 2, product management is an essential element of Scrum. Say that you’re working with a highly skilled, cohesive, experienced engineering team.
What Do You Need to Ship Software? ❘ 5 Building a commercial product is much more difficult than creating software for yourself. You need to clearly understand what the customer wants before you can start building. You need to know how much the customer is willing to spend before you begin to buy technology or hire the team for the job. Whether you’re building something for just one customer or thousands, the work requires significantly more resources than building something for your own use.
❘ CHAPTER 1 SHIPPING SOFTWARE People and Technology Unlike time, money can easily be converted to other resources you might need. Two obvious resources you need for software development are people and equipment. For people, you’ll likely want a mix of generalists and specialists. You’ll need product managers to defi ne the feature set that exactly meets your client’s needs.
What Do You Need to Ship Software? ❘ 7 FIGURE 1 -1: Waterfall and Scrum planning. The Waterfall method of project management is the method most commonly used to run software projects. When using the Waterfall method, you schedule tasks sequentially, completing one phase of activity before beginning the next. Later in the chapter, in the “Approaches to Project Management” section, we’ll look more closely at the Waterfall method and compare it with Scrum.
❘ CHAPTER 1 SHIPPING SOFTWARE Figure 1-2 shows a Gantt chart from a project planned using the Waterfall method. Note that each task is scheduled with a known duration. If a task completes early or late, this will impact all other tasks in the release. This works well if you have a high degree of confidence in your task estimates, but it falls apart quickly if the estimates are incorrect. In a Scrum project, you must plan tasks.
What Do You Need to Ship Software? ❘ 9 An artifact is something that is useful to a project but isn’t part of the product itself. Common examples of artifacts are task lists, schedules, and test cases. Figure 1-3 shows a list that combines backlog items and tasks, to easily organize and use them together. Budget Planning It is extremely difficult to accurately forecast the cost of software development before you start. We all wish this weren’t the case, but indeed it is.
❘ CHAPTER 1 SHIPPING SOFTWARE You need a well-developed product backlog. The backlog items must be ranked into a list, based on the value they deliver to the customer. By looking at the prioritized backlog, you can identify the fi rst set of backlog items to implement. You might even be able to identify the second or third set of related backlog items. In other words, by working with the backlog, you can make a reasonable estimate of how much you can get done within a fi xed time period.
What Do You Need to Ship Software? ❘ 11 defi nes a product. Assuming that there is variability in terms of product features, your job is to optimize the use of time and resources to build a feature set that maximizes the value of the product. In some business discussions, people are referred to as resources . This is offensive to some and misleading to others. Here, we refer to resources as just what it sounds like — sources of supply. A resource can be a supply of labor, money, or equipment.
❘ CHAPTER 1 SHIPPING SOFTWARE Using Scrum doesn’t change the reality of the constraints that define a project. However, Scrum is designed to react to changes gracefully. With respect to scope, Scrum assumes that the feature set is not fully defined up front. Rather, as the product emerges with successive sprints, features are added to and cut from scope.
Approaches to Project Management ➤ Customer collaboration over contract negotiation ➤ Responding to change over following a plan ❘ 13 These are not values in any moralistic way but preferences for working with products, individuals, teams, and customers on Agile projects. In addition, 12 principles guide Agile software development: ➤ Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
❘ CHAPTER 1 SHIPPING SOFTWARE product that contains features which meet customer expectations. After a number of sprints, typically 3 to 10, the product contains enough value to warrant deployment. Figure 1-5 shows the release and sprint cycle. (Chapters 8 and 9 cover using Visual Studio TFS for release and sprint management.) Sprint 1 Sprint 2 Sprint 3 Release 1.0 Sprint 5 Sprint 6 Sprint 4 Release 2.0 FIGURE 1 -5: The Scrum release and sprint cycle.
Approaches to Project Management ❘ 15 ➤ Product owner — The product owner is responsible for all aspects of product definition. This person is the voice of the customer and is always available to meet directly with the development team to discuss and review features. There must be at least one product owner on a project at all times. ➤ Team members — Team members are responsible for building the product.
❘ CHAPTER 1 SHIPPING SOFTWARE circle. There are five corresponding project phases in each iteration. These are labeled on the inside of the circle. The project moves from one phase to the next as each milestone is achieved: 5. Deployment complete 4. Release readiness approved Deploying Envisioning 1. Vision/scope approved Stabilizing Planning 3. Scope complete Developing 2. Project plan approved FIGURE 1 - 6: The MSF process model. 1.
Approaches to Project Management ❘ 17 The MSF Team Model MSF uses a well-published team model, shown in Figure 1-7. MSF defi nes six roles, all of whom are peers on the project team. Each of these roles should be filled at the beginning of the project, although full-time involvement will vary during each cycle: Program management Product management Development User experience Quality assurance Release management FIGURE 1 -7: The MSF team model.
❘ CHAPTER 1 SHIPPING SOFTWARE expectations. It works closely with the development team to test the product throughout the developing and stabilizing phases. ➤ Release management — Release management is responsible for the logistics of deploying the product in a target environment. This often includes writing and testing the installation instructions to ensure smooth rollout.
Approaches to Project Management ❘ 19 Don’t underestimate the language barrier between customers and engineers. Customers may have difficulty articulating what they want, and engineers may not fully understand what they need to build. If these people are speaking different languages, each will be misunderstood. Planning Each phase in the Waterfall method is predicated on successfully completing the prior phase.
❘ CHAPTER 1 SHIPPING SOFTWARE While heavy documentation has advantages in terms of oversight and traceability, there are major problems with it. First, it assumes that people will read the documents. This is rarely the case, as documents frequently exceed hundreds of pages. Second, it assumes that the reader can understand the documents. This is also rarely the case. Business users don’t speak or write in terms of “requirements,” yet they are expected to approve a document written in that language.
Comparing Methodologies ➤ MSF — MSF features iterative development that reacts well to change. Requirements are locked at the beginning of a release but can be added in subsequent releases. Major and minor releases can be scheduled based on new requirements. ➤ Scrum — Scrum assumes that features will be added to the product backlog after work begins. Because change is expected, it has less of a ripple effect throughout the system.
❘ CHAPTER 1 SHIPPING SOFTWARE Documentation What form of documentation is needed and produced? The three project management methodologies address documentation as follows: ➤ Waterfall — Documentation is the rule of law. Documents describe what’s needed and how the system will work. Documents enable team members to come and go because they provide a permanent record of decisions. Microsoft Project and Gantt charts are tools commonly used for documenting the project schedule.
Summary ❘ 23 ➤ Insight — Shipping great software requires a deep understanding of the desires, needs, and tastes of the customers. It is the product owner’s job to have this understanding. ➤ Resources — It takes a surprising amount of resources — including time, money, people, and technology — to build and ship software. You need to allocate and spend resources carefully. ➤ Planning — For planning, you need a process, and you need tools. Scrum is a planning process, and TFS is a planning tool.
