|
My company has to get FDA approval, so that requires a very stringent process. So yes, we're doing Agile and have a very detailed documentation process.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: we're doing Agile and have a very detailed documentation process.
Illegal!!!
Agile does not allow documentation!!!
Yes, this was a troll.
Except I'm kind of serious. The code is the documentation in Agile.
This message is only to create controversy which requires you to reply.
However, in replying you will fail.
Please reply soon.
Yes, I'm kidding. 
|
|
|
|
|
|
See, I told you so!
|
|
|
|
|
Both ends of the spectrum are a bloody nightmare.
Rarely, however, you come across a place that has found the sweet spot, where the focus is mostly on getting the bloody code written and tested, rather than focusing on poorly-thought-out processes, and where a main part of the process is repetitively demanding requirements.
It's really simple:
0. Tell us what you want, in as much detail as you can.
1. OK, it's done.
2. Tell us what else you want, or what you want different.
3. Iterate 1-2
I will say, however, that the agile morning stand-up is an absolute treasure.
It might be a bit of a pain, but it gets the less communicative members of our community to at least tell everyone what they've done.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Frack, no. We don't have time for that; there's work to do, budget to spend. ![Badger | [badger,badger,badger,badger...]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/badger.gif)
|
|
|
|
|
Actually, agile places that don't formalize the process are doing exactly what they're preaching.
|
|
|
|
|
No, not really. Every job I have worked at the code was put together and then documented afterwards. And that includes defense work too, which is supposed to be designed formally.
In fact most non defense jobs there isnt any documentation, the design and test is all in the head of a few engineers.
|
|
|
|
|
so true, often i often hear/experience companies talking agile but in reality the company slacks off a lot of the time
|
|
|
|
|
The most 'formal' development team I've heard of would be the former NASA Space Shuttle software group. I've read a couple of articles about their practices, which were stringent and regimented to a degree hard to believe.
Software Zen: delete this;
|
|
|
|
|
I've read about them too and can understand why they would have to be that regimented. I mean, a bug in the software at most places means someone doesn't get a correct paycheck or something but with that software a bug might mean someone dies!
|
|
|
|
|
I am just about to order another T-shirt that says "Life is too short for best practices".
I am not sure if this in any way relates to your question, though. But I think it does.
|
|
|
|
|
Others mentioned that most places fall on the spectrum from 0.99% and I would agree.
In our line of work, we are often asked to bid a project with incomplete details.
We have clients who "don't understand a wireframe" as we walk them through it! Or worse, they okay the wireframe, and then scream when the product works in a similar fashion... Because they were not paying attention, or could not understand it.
Most of our projects are 3 months in duration. We do formal code reviews. We do Post-Mortems and we do very little documentation (outside of project documentation). We have a small stable team.
But we would not win a bid too often if we had to write a ton of documentation, and do a complete spec review before we ever started. And we had a change management system that worked its way up and down the management chain in order to get things done.
So, I will argue that You SHOULD see a range. Based on what is needed. What the customer wants. And the risk of failure or errors. If errors kill people, then I would imagine a stringent process.
In the end, our clients trust us to deliver what they NEED and listen to the end-users over the managers (who usually have no idea what their employees ACTUALLY do). Which is no different the those who manage programmers 
|
|
|
|
|
I've only done that once, when the dev team I was on was given complete freedom in design and implementation of a project. We decided to go that UML design route, starting with stories, then sequence diagrams, then more formalities. It was a fun experience, but it delayed us finding out that our purely OOP reporting system was as slow as all hell, where with an agile approach would have taken about two weeks to find that out.
|
|
|
|
|
I've never seen it. Starting to doubt it's even real!
|
|
|
|
|
|
Wow, I had never come across that resource before. That thing is a monster! -- and a bit scary too! It must have taken years to produce.
|
|
|
|
|
|
Yes, been there, done that, safety critical software to DO178 Level A (so that's aerospace software - flight software specifically).
Yes, formal requiremenymts and design (plus full traceability from requirements down through design, code and up through unit test, requirements test and validation). The most stringent part is verification - peer review of all artefacts, unit test with 100% coverage of statements, branches, decisions and as high as possible with MC/DC (modified condition/decision coverage). Oh, and coverage from source to object code because the (Ada) compiler isn't formally qualified.
Don't do that now, but still have close contact with it - it's expensive, but it's what's required by the standards...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Formality seldom survives the first missed deadline.
Software engineering is not a programmer's term; it is a manager's term.
|
|
|
|
|
It is often overseen that a users does not use software like she/he uses a car but uses the services that the software "produces" together with other components like devices, clouds, etc. So software is part of a production site that generates the IT-Services the user needs to run her/his tasks better and more efficiently.
So when looking for professionalism in IT-services the first and most important question is what quality of service the user needs to get the wanted benefit out of that IT-service. And the whole process to define, engineer, develop, deploy and run the production site that delivers the IT-service as "promised" is much more complex than the formal software engineering process delivers today. SO what we need is a formalized approach in Business Analysis that is also delivers quality criteria relevant to the user and not only functional specifications. This is far apart from being a trivial task.
Best regards
UP
|
|
|
|
|
Sure. In government or military contracts.
Mostly what we produce is a _huge_ pile of documentation showing how no taxpayers money was wasted (not including producing said huge pile of documentation).
The unstated aim is to move money from the public sector into the private. An actual working product at the end is pretty much an afterthought. Or if it's a working product, then it's not what the users want - rather what the users bosses they _said_ they wanted several years ago, which leads to the next contract.
That's not to say formal specs don't have their place. Many medical devices will have formal specs due to the risk that lives could be lost if there's a serious bug.
|
|
|
|
|
Government contractor here, and I can concur. A colleague of mine often points out that the the documentation we produce must produce stacks of paper that are tall enough that we can use them to build a fortress to protect ourselves when the auditors attack the castle. I produced a 1000-page ATR just last month (I didn't actually print it out, though).
Having said that though, I should also mention that I am on a team that is introducing Agile methodology to this heavily waterfall-dominated workplace, and we are making some real headway. One of the keys that has helped us a lot is the use of quality tools: Jama for requirements development, JIRA for issue tracking, etc. Introducing these tools has really helped us to start enjoying the best of both worlds. (That 1000-pg ATR, for example, was automatically generated from our Jama repository.)
|
|
|
|
|
ALL MEN MUST DIE?
The warden of an overloaded prison decided to ease the situation in a somehow brutal way...
He told to the inmates, that from the next day he will line up the inmates from each section (between 20 to 30) in a way that they can see the inmates before them, but not those behind. The guards will but a black or white party-hat on the head of each inmate in a random way...
From back to front, each prisoner have to say what color the hat is on his own head. Those are guess wrong will be executed...
What the inmates can do?
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Since you didn't add any other rules, why not take off their hat, look at it, and then give the answer?
| 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 |
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
