|
Unsure about "most broken", but definitely "least fixed".
|
|
|
|
|
|
Diligence work which can be theoretically done in one hour takes at the end several hours, days.... because it is only boring stuff.
New requests which needs estimated weeks, can be done in days because I'm keen on to solve it?
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
|
I've got a mix of old projects needing new features and new projects that my customers keeping coming up with. I keep having nightmares where a line of end users are waiting in front of my desk, when another comes in and breaks line to ask for another report or program tweak...a fight breaks out and I find myself paralyzed...then I wake up! 
It's the new stuff that seems to take forever, mostly because there's no roadmap...unlike the rest of you, the only project specs I've ever gotten were handwritten on scratch paper or bar napkins...if I'm lucky, there might be a drawing! 
Personally, I'd rather add features/fix bugs in existing projects than work on new stuff.
When asked, I always give multiply a reasonable time estimate by 3.
"Go forth into the source" - Neal Morse
|
|
|
|
|
kmoorevs wrote: the only project specs I've ever gotten were handwritten on scratch paper or bar napkins
You guys are getting specs?
|
|
|
|
|
In classic waterfall (the thing before agile/nonplanning/adhoc) writing specs is the devs' work. From that, a basic design is formed, and from that, a technical design. AFAIK, agile skips that and goes directly to implementation.
Makes estimating so much harder; it's like guessing at what date you finish the book filled with sudoku-puzzles, and putting a price tag on it. That sounds a lot like gambling 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: writing specs is the devs' work
That should NEVER be the devs work!
Especially in a waterfall environment, a business analyst (or more) should talk to users, stakeholders, etc. and only when it's finished hand it over to development.
In fact, if a developer strays from the written specs a tester should make note of it and either the software should be fixed or the specs should be changed accordingly by the analyst.
A developer is probably the least suitable person to write specs.
Agile doesn't skip it, it just doesn't plan too far ahead.
It's more like, let's write the specs for this particular feature.
Which features are getting specced or built next is up to the product owner who decides on priority (also with input from users and/or stakeholders).
The specs are then made into stories (or perhaps the stories make up the specs) which are estimated by the developers.
If any story isn't fully clear it goes back to the product owner who can then try to clear things up, probably by talking to the users.
In agile, you also don't estimate time, but complexity, in terms of story points.
The story should be done by the end of the sprint (usually two weeks) and every sprint can have x story points.
Estimating anything else than complexity of user stories isn't agile, it's a team trying to do agile in an otherwise waterfall company.
At least that's what I understood.
|
|
|
|
|
That's a lot of explanation in one post.
Thank you
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
|
That can work for small companies or small products or products that are your own.
When working for bigger companies and with demanding customers you can't get away with that unless you can clone yourself and work five weeks in a week 
I've been there too and it has its merits 
|
|
|
|
|
Is reading between the lines a good idea unless there is a train coming?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
or as the song says "...there's light at the end of the tunnel, lord I hope it ain't no train!"
They call me different but the truth is they're all the same!
JaxCoder.com
|
|
|
|
|
If you see a train coming, is it better to make tracks, or unmake them?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
modified 11-Nov-19 11:16am.
|
|
|
|
|
Unless you have some sort of loco motive to risk injury, it just depends upon how you conduct yourself.
| 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 seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
You have a one track mind.
/ravi
|
|
|
|
|
Interesting train of thought, but of course you are known for your excellent track record in thoughts.
|
|
|
|
|
So, where you are the trains actually come?
|
|
|
|
|
112 - Ah - The element of surprise
Ok I've got so much to do today but decided to take a break...I'll give it back now!
They call me different but the truth is they're all the same!
JaxCoder.com
|
|
|
|
|
/ravi
|
|
|
|
|
I didn't see that coming! 
|
|
|
|
|
Now that caught me by surprise 
|
|
|
|
|
|
|
that web browsing on the iPad has become complete crap since the latest update came out a week or so ago?
I can on,y browse to a couple of websites - ALL of the others I try to go to refuse to render. This is in both Safari (which absolutely sucks balls), and FireFox.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
