|
|
Sorry all I'm stuck in a meeting all morning and haven't got a CCC prepared - can anyone stand in for me ?
We can’t stop here, this is bat country - Hunter S Thompson RIP
modified 30-Oct-17 5:53am.
|
|
|
|
|
|
You deliver a brand new solution as per spec and business starts using the application. After a week or two they have few suggestions and improvements request. Should that go to issues register or form a part of new project ?
As a developer you are happy to do the work either way. If it ends up in issues register it looks poor on quality of initial product which is not the case and if it form a part of new project there is not months of work to justify a project.
How you deal with such cases ?
Zen and the art of software maintenance : rm -rf *
Maths is like love : a simple idea but it can get complicated.
|
|
|
|
|
I deal with this type of situation constantly. I make sure to say that if the project sponsor has any improvements, then it's an enhancement. Thus, it's a new project and not an issue. Typically, I'm pretty quick, but whenever a handshake or some type of acknowledgement that the software is what the project sponsor desires through user acceptance testing, then it is complete. And any new enhancement will be prioritized. You have to be firm with the business unit, because it you're not then the business unit is now your management and they're running the show. And they have to realize that there is a cost to every enhancement.
|
|
|
|
|
What is an "issues register", a bug list I suppose, that is for stuff that should work but doesn't.
Post production scope creep is something to look forward to, the business begins using the app and discovers there are bits missing or it can be done a better way, this gives you an opportunity to rewrite some stuff that you are not happy with in the original delivery.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
virang_21 wrote: If it ends up in issues register it looks poor on quality of initial product
Sorry but it is BS...
Issue is not a bug! There are bugs and there are feature requests - they are different... If someone, somewhere thinks that missing feature is bad reputation, then one is an idiot!!!
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
You as a developer know these are new requirements and you suggest so but most of the time project manager don't want to go through the administrative task of spinning up new project and justifying why there needs to be a new project to the project sponsor. They just want to add those new request in issues log for old project and keep that project open and hence slipping the timeline. At the end of the year review these things look bad as upper management looks at those and thinks oh this project was suppose to finish a month ago but due to all those issues it got delayed. Most of the time I accommodate those needs but this time I pushed back saying these are new enhancements and there needs to be separate project for these. Lets see what happens this time.
Zen and the art of software maintenance : rm -rf *
Maths is like love : a simple idea but it can get complicated.
|
|
|
|
|
So this is all about your internal procedures! If adding an enhancement to an existing requires a new project with all the admin bullshit required by a new project then I can understand your PM wanting to tack it onto an existing project.
We simply branch the existing project and continue developing the solution.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
It sounds the bureaucrats took over your company...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: It sounds as if the bureaucrats took over your companyinsane took over the asylum...
FTFY 
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
First, I would consider the financial arrangement with the client: are they paying you well, now ? Client not paying now, after you met the spec and they accepted your code: new contract for maintenance, or new version ... then you go to work.
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it. A few hundred years later another traveler despairing as myself, may mourn the disappearance of what I may have seen, but failed to see.» Claude Levi-Strauss (Tristes Tropiques, 1955)
|
|
|
|
|
Aside from your internal bureaucracy hell, I would not let them call this any sort of bug. There is one caveat which I use with my own prioritizing: if they took my advice on design, flow, and such, I take some responsibility for the TWEAKS they request - if they ignored my suggestions, then it is back to the end of the line - with a written response.
Usually, the ignore-me people are really asking me to rewrite an old application so it looks and feels and works just like the one they use (which makes it a waste of time). If, on the other hand, they listened and let allowed the design to be organized to allow for changes/expansion (often without re-coding a line), then they go to the fast lane. This prioritization acts, by the way, as instructional to the participants and bystanders for future levels of cooperation.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
If the project delivered what was asked for, then the business requesting changes has two option: put the item in an enhancement queue or start a new phase of the project.
|
|
|
|
|
Sounds more like an enhancement. Improvements and/or suggestions, are enhancements, not issues. Issues are usually bugs or defects found in the original code base that cannot be attributed/linked to a user story or unit of development work.
Defects/bugs are spawned from a user story or unit of development work.
-- My two cents.
Edit: if your team considers enhancements to be new projects, then yes, this is a new project. With that said, I think you are using the term "project" incorrectly. The term "project" should be the High Level application that you are working on, which is run by a Project Manager/team.
modified 30-Oct-17 10:14am.
|
|
|
|
|
In our company, we have a 30-day post deployment window where the project team continues to support the project, and all issues - whether they are enhancements or defects - goes to the project team to work on. During this time, the project team is also transitioning the project (through KT sessions) to the maintenance team.
After the 30 day window is up, all future issues are entered into the helpdesk system where the maintenance team takes care of them. Any enhancements that are beyond a certain deliverable threshold (i.e. an enhancement that takes more than 80 hours of developer time, or some other measurement) are usually deferred to an "Application version 2" project that will spin up some time in the future.
|
|
|
|
|
Sounds like version 2.0. The question of course is who will pay for the enhancements?
"Go forth into the source" - Neal Morse
|
|
|
|
|
virang_21 wrote: As a developer you are happy to do the work either way. If it ends up in issues register it looks poor on quality of initial product which is not the case and if it form a part of new project there is not months of work to justify a project.
How you deal with such cases ?
As a developer...
You mention it "looks poor on quality".
Is someone actually tracking this? Does it come up in the developer reviews? In project reviews? Are bonuses directly or indirectly impacted by that? Is there any other way that it objectively impacts something?
If the answer to any of those is yes, then as a developer I would scream bloody murder if it was pushed as a bug.
If it doesn't then it is more subjective. And as a developer I might ask, but not insist that each be noted in some way as a new feature, even if the tracking system noted it as a bug.
Now if there are other criteria in the company where tracking occurs but where it doesn't impact the developer then I still might insist that it not be entered as a bug. If it is used as a metric elsewhere then either it is important or it isn't. If it isn't then why is it being used? If it is then in must reflect something real and not imaginary.
Of course the viewpoint outside of the developer, is if there is a customer and a contract then the contract should specify the acceptance criteria. It it was met then additions are extra. If not then it must be corrected. If there is no acceptance criteria then one or more people made a mistake (including the lawyer or lack of one if that was the case.)
|
|
|
|
|
So, scientists don't know what happened to all the anti-matter after the big bang.
Seems pretty obvious to me...
(p = particle)
p+ + p- = Boom!
p+ + p+ = sweet.
p- + p- = p+ (minus plus a minus is a plus) meets a p- = Boom!
I had to go shopping this morning - amazing what pops into your head when looking at dresses. 
|
|
|
|
|
With that much pee no wonder it went boom.
Someone's therapist knows all about you!
|
|
|
|
|
|
|
|
R. Giskard Reventlov wrote: amazing what pops into your head when looking at dresses.
"Does my bum look big in this?"
R. Giskard Reventlov wrote: p- + p- = p+ (minus plus a minus is a plus) meets a p- = Boom!
You got that wrong by the way.
-p + -p = +p
No 'minus meets a plus. 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
