We all know that software is a never-completed product but released. Agile Methodology adopt a change but make change frequently.
How can a middle-level developer know how a project is completed?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (7)
Software development is never having to say you're done.
But for a project, it should have.
I don't think so. In all these years writing code and maintaining applications for many different companies I've never found a project that was "done" or "complete" even after years of development. What we actually have, I believe, is something more like "ready" - ready to production, ready to use.
But for project, I think it require a cut off as the cost may be fixed price.
Maybe in your view, the application need to be released.
My current project has been going for 31 years now. Still not done.
We've released 19 times. Not include dot releases (minor releases) and dot-dot releases (bug fix releases).
How do you define what would be included for each release?
We have 15 development teams (Scrum teams). Each team has a PM (product owner).
On paper, all the teams are fungible. In practice, each team has an area of expertise and "owns" that functionality.
The PM of each team prioritizes big features, small features, and bugs. The team carves out 2 weeks (a sprint) of work items from that prioritized backlog.
Ship dates are set far in advance. Those dates are set in stone.
Features are pencilled in on the calendar for when they will be worked on, and how long they will take. This schedule is a WAG for planning purposes, and subject to revision over the course of the cycle.
The council of PMs have a grid of all the features (big and small) across all teams, and track the status of those features. The status being: on track, concerned, in trouble. Features that are on track and finished for the release will ship. Features that were incomplete have to wait for the next shipping date.
Ostensibly, each team is using by-the-book Scrum as a lightweight management process. But in actuality, each team does "Scrum, but..." which is at some variance from by-the-book Scrum.