Someone asked how the software development lifecycle works. I've been in and out of enough companies to know there is no standard, and every company does things differently enough. But I have come across an approach that I like and works well for my current team. Today I'm going to talk about that.
The Idea
At some point, somewhere, someone is going to have an idea.
Hey, I want to build an app to show off all my wingoose.
This person is the product owner.
Discovery
The product owner is going to go to a development team and say:
Hey, I want to build an app to show off all my wingoose.
And the development team is going to ask a ton of questions like
What the heck is a winggoose?
And the Product owner is going to correct them saying:
"wingoose" not "winggoose"
And this conversation will go around in circles, possibly with some confused weird looks between all parties, but it is all in good fun.
The developer team is going to ask a ton of questions. Who do you want to show off the wingoose too? How many wingoose do you want to show?? How do you want to show them to people? When do you want to show them to people? Why do you want to show wingoose to people?
These questions are mirrored after the five Ws and an H: Who, What, Where, When, Why, and How. The developer team wants to get a good understanding of what the problem they are trying to solve is so that they can make a proper recommendation.
Proposal
Now the developer team has to tell the product owner what they're going to build for them. In the consulting world, this is a proposal. My current team calls it an RFC, or Request For Comments document. Some may call it a software design document.
Often there is a small subset of the team that owns this document. They asked all the questions during discovery. A document like this describes everything we know about wingoose and how we're going to show them off with an app.
For the product owner, this explains what we're going to build for them. There may be screen mockups and unspoken requirements. It will include assumptions and maybe important deadlines. User flows might be included if applicable. The key players will be outlined.
To the rest of the team, this document reiterates the problem and how we're going to solve it. There may be database designs and software architecture diagrams. Multiple approaches for different levels of the stack might be examined.
The proposal is reviewed as a group where questions are asked and answers. Remember, the rest of the team had probably never heard about wingoose before now. I like to split these review meetings into two meetings. The first meeting is the "war room". Anyone can ask questions, and champion their preferred approach. Debates are had, and sometimes a new option emerges. Sometimes tensions run high and everyone needs to relax. Sometimes the proposal RFC is updated based on this meeting.
A second meeting takes place, a few days later and a decision is made. This is a more light-hearted meeting, than the first one. Everyone said their peace, argued their case, and now we come to consensus.
As a solo developer consultant, I'd jump right to the implementation stage. But, as a teammate, I would turn the proposal into actionable tickets. My own personal philosophy is that tickets should be as detailed as possible in their tech direction and define a single cog in the big machine. A lot of small tickets come together to make a big thing. My current team has even been using ticket diagrams to highlight all the tickets, and their related dependencies to give a high-level view of the project and highlight the work that can be done in parallel.
MVP
From the proposal comes the tickets, and from the ticket's developers build stuff. Get out of their way!
Depending on the size of the project, this step might take days, weeks or even months. Today, most companies are going to use some form of agile development, but everyone does it differently. Commonly, work is broken up into sprints. I actually like 3 week sprints, but 2 weeks seems to be more common. There is often some daily status meeting, called standup, and a review meeting called a retro.
Eventually, you deliver your app, and the product owner is happy.
Wait, did you say the product owner is happy?
Insert maniacal laughter here.
Maintenance
You've now built a project so that the product owner's wingoose can be shared with whomever he wants to share wingoose with! And then you're asked
how can my friends sign up?
And you say
They can't, because you didn't tell us you wanted more than one user in this app.
Your app, my dear friends, has entered the maintenance stage. You need to make changes. You'll go back to discovery and start the process again. The bulk of applications live in this circular repetition of discovery, development, and delivery for most of its life. You'll be making changes to existing code, and hopefully supporting a successful project in a successful business.
Sunset
And finally, at some point, the product owner is going to come to you and say.
No one cares about Wingoose anymore! Why did we ever build something for Wingoose! Zombores are all the rage! Zombores are where it's at! Can you make me an app to share my Zombores?"
The time has come to shut down the Wingoose app, archive the code, let things go, and move on. There are many reasons a company might decide to sunset a project. It could be the project no longer suits the business needs. It could be the project has too much tech debt to be properly maintained and needs to be replaced with something that has less baggage left. It could be the people who built it are no longer at the company and everything is afraid of touching the code. Or it could be the whim of a product owner client who just changed, and either has the political clout or money to pay change.
Final Thoughts
Thanks for reading my synopsis of how the software lifecycle works. I love software development and being part of the process, the good and the bad.
Note 1: Wingoose is a completely made-up word and any similarities to people, places, or things is completely and entirely coincidental.
Note 2: Zombores is a completely made-up word and any similarities to people, places, or things is completely and entirely coincidental.
posted by Jeffry Houser in
Software Development, CodingConventions, Professional
| 0 Comments
