|
I been through dozen places in my time, everyone is talking about it, even have policies written enforcing that they practice it, but when comes to the metal, a few actually do what they claimed. Most places where they called themselves fast-pace and agile are examples of not doing what was preached.
Does any place(shop) doing formal software engineering? Formal requirement, formal specification (yes I meant the difference documents in requirement and specification), formal design(UML stuff), code and more importantly formal software quality assurance. I know few places where they do them to concur with laws or government regulations.
Share your shop's experience.
|
|
|
|
|
I've never seen 100% formal agile in practice, in my experience at least. Personally, that's a good thing. Too much rigidity dehumanizes us. I mean, I understand the need for structure... believe me if a company got halfway there that's probably still better than most pretending to implement it.
Unfortunately, this doesn't just apply to agile.. this industry is a lot of fluff. So many experts that don't know what they're talking about, and only fool the even more clueless. Welcome to technology.
Jeremy Falcon
|
|
|
|
|
Leng Vang wrote: Does any place(shop) doing formal software engineering?
Nope. Everywhere I've been, it's pretty much a free for all when it comes to software development. The saving grace is that I've occasionally had the pleasure of working for and with people that I would call professionals, meaning that they are self-disciplined to formalize their own processes.
Marc
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
