Adaptive Code via C# Agile coding with design patterns and SOLID principles (2014)
Part III: Adaptive sample
CHAPTER 10 Adaptive sample: Introduction
CHAPTER 11 Adaptive sample: Sprint 1
CHAPTER 12 Adaptive sample: Sprint 2
This part of the book takes you through the initial phases of developing a software product. Using a fictitious team and project, the following chapters describe the conversations the team members have and the decisions they must make along the way.
The code examples reflect a selection of some of the patterns and practices that were covered in Parts I and II. Not everything is covered, but some of the more common implementation questions are answered.
As in the rest of this book, working code samples are available on GitHub. See Appendix A, “Adaptive tools,” for a brief introduction to using Git for source control, and Appendix B, “GitHub code samples,” which you can download from this book’s catalog page in the Microsoft Press Store, for a reference of code listings for each chapter to branch names in the Adaptive Code repository on GitHub.
Chapter 10. Adaptive sample: Introduction
In this chapter, you will
Learn about the team that will develop the adaptive sample application.
Understand the features of the product for the adaptive sample application.
Create an initial product backlog for the application in sprint zero.
The chapters in this part of the book incrementally build a working application by using Scrum and by adhering to the adaptive design principles detailed in this book. It is the culmination of all of the content thus far, presented to form a coherent whole picture. As with the rest of the chapters, I recommend that you study the accompanying code1 while reading these chapters. Without the content of these chapters, the code alone lacks context. Similarly, without the full Microsoft Visual Studio solution, the listings provided in the following chapters will only give you a small window onto the full picture.
1 See Appendix A, “Adaptive tools,” for instructions on how to access the code for the sample application and the rest of the code in this book.
The format of this chapter is intended to mirror a real-world scenario, but there are some concessions made for brevity and clarity. The rest of this chapter is an introduction to a fictitious Scrum team and an outline of the product that is to be developed.
Trey Research
The sample application will be developed by an imaginary company, Trey Research. The company prides itself on writing adaptive code that is resilient to change.
The team
The sample application will be developed by using the Scrum process, so the team needs members who will fulfill the roles of Scrum. For a refresher of these roles and the Scrum process, refer to Chapter 1, “Introduction to Scrum.”
The team includes all of the roles that are required to advance the application from its inception to its delivery. The product owner has knowledge of how she wants the application to function, which features are of the highest priority, and which features will generate the greatest amount of revenue for the business. The Scrum master is focused on the process that is being used by the team. His concern is that the process works for the team, that the team has no impediments to its work, and that the product owner is informed of any issues that arise during the development of user stories. Trey Research’s development team consists of developers who will implement stories and a test analyst who will design test cases and verify that stories meet a certain standard of delivery.
Product owner
The product owner is Petra. She is a veteran business analyst who has recently joined the company. Her specialization is in finding exactly what the customer wants—an invaluable skill for a product owner. She readily admits that Agile processes are alien to her, but she is eager to learn more about her new role.
Throughout the development process, Petra liaises with the client company to find out exactly what it is that they want and why they want it. Also, she will calculate the value of various features to the client so that she can better prioritize work for the development team.
Scrum master
Steve holds two roles in the company. He is simultaneously a Scrum master and the technical team lead. This is a common scenario that the company is keen to remedy in the near future, freeing Steve up to concentrate on his preferred role as Scrum master. To facilitate this, the company is looking to hire an experienced developer into a dedicated technical team lead role.
In his capacity as Scrum master, Steve ensures that the team follows the Scrum process and that the team members are happy with the current incarnation of the process. He prides himself on working honestly and transparently with any assigned product owner or customer—never altering metrics or over-promising on delivery.
Although Steve rarely has time to write code, he still attends design meetings and tries to steer the development team in the right direction whenever he can.
Developers
David and Dianne are the company’s two dedicated developers. David is considered a junior developer because he was brought into the company after graduating from college, whereas Dianne is at more of an intermediate level.
One of the reasons that Steve hired David is his continued self-education on programming practices and techniques. David tries to stay current on the latest trends and is always hungry to learn. However, he does tend to view each new technique or technology as a cure-all and liberally applies it whenever he can. This is excellent practice for David, but often his code is a morass of needless indirection.
Dianne is more advanced than David, but she has a tendency to sound jaded by the tidal wave of new technologies that have emerged over the last few years. She has been burnt by the same issues that David is currently working through. Dianne is vying for the technical team lead role and is determined to prove her credentials to be promoted from within. To this end, she is keen to work closely with David to help him to improve.
The Hype Cycle
The Hype Cycle was developed by Gartner, an IT research and advisory firm. It is a useful tool for assessing the progress of new techniques and technologies. It is shown in Figure 10-1.
FIGURE 10-1 The Hype Cycle can help explain attitudes toward new techniques and technologies.
The x-axis of the graph represents advancing time, and the y-axis represents expectations. Initially there is a trigger, which could be a new technological discovery or a helpful new technique or procedure. Soon thereafter, expectations rise rapidly until they hit the “peak of inflated expectations.” At this point, the technology or technique begins to be viewed as less all-powerful than was initially believed. This causes expectations to plummet rapidly to the “trough of disillusionment.” All is not lost, however, because the “slope of enlightenment” gradually leads to a “plateau of productivity.” At this point, the technology or technique is established and has more realistic expectations attached to it.
The expectations of developers are often located somewhere on this graph with respect to one or more programming technologies or techniques. For example, at Trey Research, David is nearing the peak of inflated expectations with respect to design patterns, the SOLID principles, unit testing, and refactoring. Dianne is just crawling out of the trough of disillusionment. In the sprint meetings detailed throughout this chapter, pay close attention to their questions and responses and consider how they are shaped by their relative positions on the Hype Cycle.
For completeness, it is worth noting that Steve’s experience has moved him along the graph sufficient for him to be on the plateau of productivity. Not only that, but Steve is no longer as susceptible to the Hype Cycle as he once was. He is cautious when approaching new techniques and technologies that are purported to increase productivity, quality, efficiency—or any other metric. As a result, his expectations do not oscillate as wildly when he is presented with a new technique or technology.
Test analyst
Tom is the team’s test analyst. His focus is on test automation. He has always had an ability to find a software product’s weaknesses and improve the overall user experience through an increased robustness. He likes to treat features as black boxes and is less concerned with how something is implemented than in whether it works to specification—and beyond.
Tom feels like he is overworked in the team because he is constantly rejecting work that has been implemented. This means that he has to test and retest a story at least twice before it works to his exacting standards. It is a point of pride for Tom that defects are rarely deployed to a client’s machine and are instead caught early by his automated tests.
The product
Trey Research has been hired by a client to develop a new online chat application called Proseware. This is a web-based application that will allow people to chat from around the world. During first discussions with the client, Petra was able to determine that the client has a lot of ideas for the project but would like to put something small together so that they are better able to decide the direction of the application. Trey Research is well suited to this product because of its incremental development style and its ability to balance this against potentially rapid changes in requirements.
Petra spoke to the client before the project started so that she could prepare the team with some information about what they will develop. The client wants Proseware to be hosted by Trey Research, thus the team is free to choose whichever platforms and tools the team members think are best for the project. Petra was sure to ask the client what their requirements were with regard to Proseware’s capacity for users. She agreed with the client that the application needs to only support 20 concurrent users at a time, and this has become a key nonfunctional requirement of Proseware.
Before the team sets to work on writing any code, Petra calls a team meeting so that the team members can discuss the project and try to create an initial backlog of user stories. With these stories in place, the team can set to work on creating something demonstrable within a single sprint.
Initial backlog
The client provided Petra and the team with a list of features for Proseware. This was provided as a prose description, and the team’s goal for the meeting is to turn this into one or more user stories.
We view Proseware as the primary site for people to chat. However, we realize that Rome was not built in a day, so we have limited our mission statement somewhat so that something can be delivered in the fastest possible timeframe.
Although we do want to allow users to be able to send each other images or files, the key functionality will be centered around textual communication. Anyone who is in a room should receive all the messages that are sent from anyone else.
Because the textual side of chat is so important, we need the members of a room to be able to send each other formatted text—something like HTML. Of course, they shouldn’t be able to spam the chat with lots of meaningless images or videos!
Some of the conversations in Proseware should be not be editable by some users, and some users should only be allowed to read, but not contribute.
Petra brings this short description to the meeting, and the team sets to work trying to find the user stories.
Finding stories in prose
Sometimes clients write prose descriptions of their expectations, as in the previous section. From this, the team must extract and negotiate the user stories to be implemented. The Trey Research team arranges a meeting to find the user stories in the description of Proseware that was supplied by the client.
PETRA: Okay, has everyone read the description? [Everyone nods, displaying a range of enthusiasm.]
STEVE: There’s a lot here!
DAVID: Not really—we could probably get through this in a single sprint. [Steve smiles broadly.]
PETRA: Can someone please show me how this is going to give us a list of user stories?
DIANNE: First thing we can do is pick out the verbs and nouns: send, receive, format, spam...room, conversation, users, members, chat...
STEVE: True, that’s a lot right there.
PETRA: As a user, I want to... So that...
DIANNE: Are they just users?
STEVE: Sounds like there’s more than one role here.
DAVID: They call them users, and then they call them members.
TOM: Aren’t you a participant in a conversation, though?
STEVE: Perhaps, but we should use their ubiquitous language. There are some roles around conversations being read-only or not, surely?
DIANNE: Yeah, that sounds like it’s hinting toward some kind of permissions system.
PETRA: Can someone pick out a story, please?
DAVID: As a member, I want to send formatted text so that others can... view... stuff?
STEVE: Shall we focus on the roles and the behavior for now? Petra, you can add the business value bit, can’t you?
PETRA: Sure.
DIANNE: Yeah, but even that seems a little bit too big. It feels like an epic, not a user story.
PETRA: Sorry, what’s an epic again?
DAVID: It’s just a big story, really. Dianne thinks this story is too big to fit into a single sprint, but I don’t know how it could be smaller.
DIANNE: Well, what’s simpler than formatted text? Ignore the HTML part—that’s just the client imposing implementation! Think about any formatted text: what’s simpler?
DAVID: Err... Unformatted text?
STEVE: Also known as plain text. [David smiles sheepishly.]
DIANNE: As a room member, I want to send plain text messages to other room members. [Petra looks for dissenters but finds tacit consensus.]
TOM: Excellent! Ladies and gentlemen, we have our first user story! [Everyone but Petra bursts into a spontaneous round of applause.]
PETRA: But they asked for formatted text?
STEVE: Don’t worry, that’s another story—it just comes later, after plain text has been delivered.
PETRA: Okay. As a room member, I want to send formatted text messages to other room members.
STEVE: That’s two. Any more?
DAVID: I want to create rooms?
DIANNE: Yes. I think this will surely make that person a room owner, won’t it? As a room owner, I want to create rooms for categorizing conversations?
STEVE: Good.
TOM: They said they wanted to send images and files, too.
PETRA: Yes, that’s another story.
STEVE: One more: I want to create read-only conversations.
DIANNE: That’s the last sentence covered. I think we’re done.
Story point estimation
By now, the team members agree that they have found the user stories from the client’s requirements. They create user story cards from each of the following bullet points:
I want to send plain text messages to other room members.
I want to create rooms for categorizing conversations.
I want to send formatted text to other room members.
I want to send images and/or files.
I want to create read-only conversations.
The team arranges the cards on the table ready for assigning story points. There are only five stories, so the team decides to use planning poker to estimate the effort required.
PETRA: Sending plain text messages can’t be too difficult, surely?
DAVID: It would only take me an hour! [Steve and Dianne raise their eyebrows. Tom rolls his eyes.]
STEVE: Well, you can’t really do this one first. Without rooms, you have no participants.
DIANNE: True, there’s a dependency there, but it doesn’t alter the size. [Steve nods in agreement.]
PETRA: Is everyone ready?
After some final card shuffling, the team members show their cards:
PETRA: Hmm, that’s a bit of a mix. David, why one?
DAVID: There’s almost nothing to do here: it’s just taking some input and writing it to the screen.
DIANNE: Not exactly, David. There’s more to it than that. We need to save the text somewhere and be able to read it back. Other room members need to read it, too.
STEVE: Indeed, Dianne’s right. We need to think about the architecture here.
DAVID: Oh, yeah. I thought it was just about writing it out to the browser window. But, of course, that’s only going to be viewed by the person who wrote it—not shared. Wow, that’s much harder!
PETRA: Okay, shall we re-estimate?
The team members count down from three and show their cards again:
STEVE: Can we split this story up into “reading” and “writing”?
DIANNE: Sorry—I’m not sure what you mean.
TOM: I think he means that we could have a story for viewing the messages that have been sent to a room and another story for sending messages to that room. Right, Steve?
STEVE: Yes. I just think it would help for us to start really small. I know an estimate of five is not all that large, but it is significant at such an early stage of development.
DIANNE: Okay, I’m happy with that. Shall we re-estimate sending messages?
DIANNE: And now let’s estimate just viewing the messages already sent to a room.
STEVE: Tom, David—will you accept a two?
TOM: Yes, two is fine.
DAVID: I agree. Two makes sense.
STEVE: Excellent. Two it is. [Steve marks a two on the user story and reads out the next.] I want to create rooms for categorizing conversations.
DIANNE: How do we demonstrate this?
TOM: Petra and I spoke about this, and one of the acceptance criteria is that we should be able to view the list of the rooms that have been created.
DIANNE: Another candidate for splitting into “read” and “write” stories?
STEVE: I think so, yes.
DIANNE: Let’s estimate the read part first: I want to view a list of rooms that represent conversations.
The team members show their cards:
DIANNE: Wow! Unanimous. And now the story for creating new rooms?
The team members show their cards:
STEVE: David, are you okay to take a two?
DAVID: Yeah, that’s fine.
STEVE: Next: I want to send formatted text to other room members.
PETRA: So this is just adding in formatted text?
STEVE: Yes—assume that the plain text story has been completed and is a prerequisite to this story.
TOM: What sort of formatting do they want? Embedded images or something?
DAVID: Images is a separate story. I think of this more as bold, italic, underline—things like that.
PETRA: Yes, that’s what the client said that they wanted. HTML was the only format they could think of, but I don’t think we’d want to go there. Just simple text formatting, nothing too strenuous.
STEVE: Okay, ready?
The team members show their cards:
STEVE: Hurray! We’re all agreed on that, then. Next: I want to send images and/or files.
DIANNE: I don’t like the “and/or” bit in this story. Can we be less ambiguous?
TOM: Well, what’s the difference between sending an image and sending a file?
PETRA: From my conversation with the client, they wanted images to be shown in the browser, whereas files would be downloaded to other users’ machines.
DAVID: Then this is surely two different stories, isn’t it? One for downloading files and one for showing images.
DIANNE: Exactly, this is too big at the moment. We should tackle them separately. It feels like files would be the simpler of the two, so we could put that first, with images using it as a prerequisite.
STEVE: I agree. So let’s change this to two stories. I want to send files to other room members. I want to show images to the room. Let’s estimate them separately.
The team members show their cards for the first story:
STEVE: Hmm, why fives?
TOM: Testing this is going to be difficult. There are a lot of unusual test cases that we will need to consider. For instance, what if the file is very large? What if the file is malicious? Will we keep hold of the file on our servers? For how long?
STEVE: I take your point. I was considering only the development effort here, sorry. I can tell now that you will be spending a lot of time trying to break this.
DAVID: Shall we re-estimate, or just take five?
STEVE: I’m happy with five.
DIANNE: Me too.
STEVE: And what about images?
PETRA: This is just about showing the image to the users on the page?
STEVE: Yes, the upload part should have been completed by now, so this is just about showing the image on the page.
The team members show their cards:
STEVE: David, a five?
DAVID: Yes—I think this is a bit harder than it looks. What if the image is inappropriate? What if there are a lot of users and the image takes a long time to download? That will put a load on our servers.
DIANNE: I agree, those are all concerns, but I think they are out of scope for now. Petra, make a note to ask the client what they think of a content filter—not just for images, but for text, too. But, at the moment, we only need to support 20 users. That should not represent a significant load.
PETRA: Good idea about the content filter, David.
STEVE: Happy to take a three, David?
DAVID: Actually, now I think it’s a two! But, yes—a three is fine.
STEVE: Good stuff. Final story: I want to create read-only conversations.
The team members show their cards:
STEVE: Oh dear. That’s all a bit random! Tom, one?
TOM: Sorry, forgot about analysis and development effort. This just seems really, really easy to test in comparison to the other stories.
STEVE: Okay. Petra, Dianne, eight?
DIANNE: At this point, we won’t have roles or permissions, which we’ll need. I think there’s a lot of work here.
DAVID: Oh, I didn’t think we needed roles or permissions at this point. I thought we’d just flag a conversation as read-only.
STEVE: It needs to be read-only on a per-user basis. Still, I don’t think we need any heavy infrastructure for permissions or roles as yet. I think it should be implemented with a very simple solution first, and we can elaborate on it later.
DIANNE: That sounds fine to me.
PETRA: Yeah, I trust you guys.
STEVE: The average here was exactly five. Shall we take that? [Everybody agrees.]
STEVE: David, still think this is a single sprint of work?
DAVID: Hmm... No!
The meeting ends.
Summary
Over the course of the meeting, the team has taken a short description from the client and broken it down into user stories. The team then estimated the stories and created a prioritized backlog. They can now begin development.
Notice how the conversation allowed all sides of the development process to give input: analysis, implementation, and testing. For each story, the team reached a consensus for the effort required to complete the story.