Mixing Agile With Waterfall For Code Quality - Slashdot

Mixing Agile With Waterfall For Code Quality - Slashdot
Close
binspam
dupe
notthebest
offtopic
slownewsday
stale
stupid
fresh
funny
insightful
interesting
maybe
offtopic
flamebait
troll
redundant
overrated
insightful
interesting
informative
funny
underrated
descriptive
typo
dupe
error
65541169
story
jones_supa
writes:
The 2014 CAST Research on Application Software Health (CRASH) report states that enterprise software built using a mixture of agile and waterfall methods will result in more robust and secure applications than those built using either agile or waterfall methods alone. Data from
CAST
's Appmarq benchmarking repository was analyzed to discover global trends in the structural quality of business application software. The report explores the impact of factors such as development method,
CMMI
maturity level, outsourcing, and other practices on software quality characteristics that are based upon good architectural and coding practices.
InfoQ interviewed Bill Curtis, Senior Vice President and Chief Scientist at CAST
, about the research done by CAST, structural quality factors, and mixing agile and waterfall methods.
You may like to read:
An Air Traffic Control System For Drones
Microsoft To Replace All C/C++ Code With Rust By 2030
Python Foundation Rejects Government Grant Over DEI Restrictions
At Amazon, Some Coders Say Their Jobs Have Begun To Resemble Warehouse Work
Ask Slashdot: Would You Consider a Low-Latency JavaScript Runtime For Your Workflow?
The Great Software Quality Collapse
Submission: Mixing Agile with Waterfall for Code Quality
OS X 10.10 Yosemite Review
This discussion has been archived.

No new comments can be posted.
Mixing Agile With Waterfall For Code Quality
More
Mixing Agile With Waterfall For Code Quality
Comments Filter:
All
Insightful
Informative
Interesting
Funny
The Fine Print:
The following comments are owned by whoever posted them. We are not responsible for them in any way.
Agile is the answer to everything
Score:
, Insightful)
by
sandbagger
( 654585 )
writes:
on Friday October 17, 2014 @09:38AM (
#48168155
The only reason why you disagree is because you're doing Agile wrongly!
Yeah right. The Agile moonies need a slap. If Agile is so wonderful why don't you walk over to payroll and tell them to adopt it?
Share
Re:Agile is the answer to everything
Score:
, Funny)
by
i kan reed
( 749298 )
writes:
on Friday October 17, 2014 @09:43AM (
#48168201
Homepage
Journal
I'm pretty sure I
like
payroll to deliver every 2 weeks.
Parent
Share
Re:
Score:
by
Anonymous Coward
writes:
But I do not want payroll to be adding or removing features to my pay every 2 weeks.
Re:
Score:
by
ArcadeMan
( 2766669 )
writes:
Someone in accounting watched Superman III a few months ago.
Re:
Score:
by
__aaclcg7560
( 824291 )
writes:
Not yet. High frequency traders on Wall Street steal pennies all the time. The practice should be outlawed.
Re:
Score:
, Interesting)
by
Anonymous Coward
writes:
Having done pretty much what this article is calling for. Dont do it.
Both methodologies work. They are however like oil and water. It allows for sloppy planing with the idea you can change it later. It does not work. Even with agile you want some sort of end goal plan. But not all the details worked out. With waterfall you try to figure out all the details and usually get them wrong or forget what you were doing 2 years ago.
You will end up with the worst of both methodologies all in one nice neat pac
Re:
Score:
by
arth1
( 260657 )
writes:
Having done pretty much what this article is calling for. Dont do it.
Both methodologies work. They are however like oil and water. It allows for sloppy planing with the idea you can change it later. It does not work.
I think the point of TFA was that it
does
work. And on average, better.
Emulsions can be good.
Re:
Score:
by
Oligonicella
( 659917 )
writes:
Pretty sure he understood the point of the article. By personal experience, he disagrees. If you're appealing to the authority of the article - pffft! - authorities on developmental and coding methodologies are a dime a dozen.
Re:
Score:
by
skids
( 119237 )
writes:
authorities on developmental and coding methodologies are a dime a dozen
I thought people who sat around opining about the code they expect other people to actually write were somehow paradoxically payed much better than that.
Re:
Score:
by
knightghost
( 861069 )
writes:
I agree that it can work - IF you have good people. That's rarely the case, so it usually fails.
Managers need to focus on dollars per result rather than irrelevant headcount.
Re:Agile is the answer to everything
Score:
, Insightful)
by
znrt
( 2424692 )
writes:
on Friday October 17, 2014 @02:02PM (
#48170645
I agree that it can work - IF you have good people. That's rarely the case, so it usually fails
this. agile was the experience of a group of highly skilled and motivated professionals in a very specific setting. they had intuitively adopted some practices that were already known, and then called their whole experience "agile" and produced a recipe for it.
what few understand is that this recipe is simply not universally transferable. talent and motivation are the real drive. given those, everything else can be figured out in many ways: probably any combination will work in such a team, they just chose what suited them best.
but none of them will work in a zoo. no matter how many evangelists and bananas you throw at the monkeys.
Parent
Share
Re:
Score:
by
Jane Q. Public
( 1010737 )
writes:
I think the point of TFA was that it does work. And on average, better.
That might be "the point" but that doesn't make it true.
Bureaucrats hate "Agile" because they perceive they have less control over the process. Which is true, but only in a way. They may have a bit less control over the process, but they still control
the product
, which is really the whole point.
Micromanagement is bad. Waterfall is micromanagement in action.
Re:
Score:
, Insightful)
by
Anonymous Coward
writes:
Bureaucrats hate "Agile" because they perceive they have less control over the process. Which is true, but only in a way. They may have a bit less control over the process, but they still control the product, which is really the whole point.
Micromanagement is bad. Waterfall is micromanagement in action.
Agile is for lameasses who can't scope a project or develop adequate specs, although it's really good for keeping a client on a payment treadmill using the creeping feature creature. That shit might fly for a
Re:
Score:
by
Jane Q. Public
( 1010737 )
writes:
Agile is for lameasses who can't scope a project or develop adequate specs, although it's really good for keeping a client on a payment treadmill using the creeping feature creature.
You can find bad business practioners in every area. This is hardly a feature of Agile. Plenty of waterfall companies are guilty of exactly the same things.
You, as the stakeholder, are in charge of features. If you don't have them under control, you're doing it wrong.
That shit might fly for a webapp (or not, in the case of healthcare.gov), but for real projects it's totally unacceptable. Real as in missile guidance systems, F-16 firmware, HDTV software, etc.
Hahahaha. Seems to me the news has been full of stories for many years about how things like
military software contracts
have CONSTANTLY been full of abuses, bugs, and cost overruns. I've been reading about them in the news since I was a chi
Re:
Score:
by
Dastardly
( 4204 )
writes:
And, many military software contracts are moving to require Agile practices because they are tired of spending a lot of money on cancelled projects with nothing to show for it except a bunch of documents.
Re:
Score:
by
kmoser
( 1469707 )
writes:
Hahahaha. Seems to me the news has been full of stories for many years about how things like
military software contracts
have CONSTANTLY been full of abuses, bugs, and cost overruns. I've been reading about them in the news since I was a child.
Projects that are delivered on time and under budget don't make the news.
Re:
Score:
by
Jane Q. Public
( 1010737 )
writes:
Projects that are delivered on time and under budget don't make the news.
Of course. But that argument works both ways. You don't often hear about the Agile successes either.
Re:
Score:
by
znrt
( 2424692 )
writes:
right except the part where you call someone a lameass just for working on a different use case.
you wouldn't use the same approach and investment for a social website and a satellite control system, would you?
Re:
Score:
by
Kazoo the Clown
( 644526 )
writes:
Bureaucrats hate "Agile" because they perceive they have less control over the process. Which is true, but only in a way. They may have a bit less control over the process, but they still control
the product
, which is really the whole point.

Micromanagement is bad. Waterfall is micromanagement in action.
My experience with Agile has been the bureaucrats transformed it into just another vehicle for micromanagement. In some ways, an even better vehicle for that than ever before. Daily standups? Sprints? Grooming? Burndown charts? Perfect for micromanagers.
Re:
Score:
by
Dastardly
( 4204 )
writes:
It kind of depends on which kind of manager, and the organization. My experience is that managers love their illusions of control, but hate actual control because then they have to be responsible for the results. Also, actual control means actual effort. They want burn down charts that they can look at once a week and pretend they are contributing something useful by beating on people when they are not perfectly on the ideal line. Of course, in two week sprints at that interval burn down charts are virtua
Re:
Score:
, Insightful)
by
Anonymous Coward
writes:
I was a QA lead for several years, and I can't the number of planning meetings I was in where the org would come up with a completely dev-centric sprint schedule, then demand that we start testing on the very same day that dev started writing code and finish the second dev made their final check-in. "Agile," they said. "Scrum." "Why can't you accept the genius of our plan?"
Buzzwords won't fix the fact that during the first week or two (or more) nothing's been checked in, and anything you slam-dunk in at
Re:
Score:
by
Anonymous Coward
writes:
Yeah orig AC here. Basically your org failed to follow the steps. It an easy to fall into trap.
Instead of that story failed and needs more time it was pushed and not really 'done' yet called 'done'.
This happens commonly with a poor estimation of time (which comes with experience of many iterations). It is why some agile methodologies call for story points. I usually see people throw out that abstraction and try to use hours which then leads them down the slippery slope of combo. And the idea you can pi
Re:
Score:
by
Dastardly
( 4204 )
writes:
One of the big tricks I have found is that you actually have to identify everything that might need to be done to get something to "release" (whatever that means in your org). I don't mean like in waterfall with every individual thing in a project plan with an estimate. I mean in general for all stories. i.e. Definition of Done. Then, you identify the things that can and must be done during the story Sprint and that is the sprint definition of done. What is left over can be called release definition of d
Re:Agile is the answer to everything
Score:
, Funny)
by
pixelpusher220
( 529617 )
writes:
on Friday October 17, 2014 @01:45PM (
#48170505
We're doing a mix of Agile and Waterfall. I call it Drunken Sailor...it's about as productive.
Parent
Share
Agile is the answer to everything
Score:
, Funny)
by
Anonymous Coward
writes:
Waterfall + Agile = Fragile
Re:
Score:
by
savuporo
( 658486 )
writes:
Exactly, we called it either fragile or scrum-fall. Glad i got out.
The reality is this : if you have a good responsible software development team with expert development leads, architects and you have generally sound software development practices you can follow any process du jour and get good quality software out. Otherwise all bets are off and no process buzzwords are going to help you.
Re:
Score:
by
Anonymous Coward
writes:
Amen. Also add in analysts who actually analyze requirements and validate functional specs, not just act as stenographers blindly writing whatever a stakeholder says. Bonus points for managers who actually manage by inspecting work products, not just going around the meeting room table asking people "is your work done? yes? ok, good enough for me".
Re:
Score:
by
jellomizer
( 103300 )
writes:
I try to mix both myself.
Agile has issues in terms of scale. It is great for small projects, works for Medium then as you get larger it begins to fall apart. As you have way too many sprints to choose, that things just do not coincide for a long time. Causing disjointed code segments.
Waterfall is too rigid where you have do this by then. Not accounting much for unforeseen issues, means you have to redo the plan, or if you find that things can be done in a different order is difficult to represent.
I find mi
Re:
Score:
by
ameen.ross
( 2498000 )
writes:
Customers need to grow up. The government of The Netherlands (a country with a GDP of ~€600 billion) wastes up to €5 billion of taxpayer money each year on badly managed IT projects. The reality is that projects with a fixed timeline
never
get completed on time, lending to the "deadlines are meant to be broken" meme. This is especially true for IT projects, as the scope is often not fully known at the start of the project, and will grow as the project progresses.
Agile is all about realism. You jus
Re:
Score:
by
Dastardly
( 4204 )
writes:
Hourly billing can work, but it does require a level of trust and openness between customer and contractor that may not be possible in many cases. The customer has to trust the contractor is billing for productive hours worked at a reasonable profit. The contractor has to trust the customer enough to open up their operations sufficiently to create the trust with the customer that they are getting the value for their money.
Re:
Score:
by
Anonymous Coward
writes:
In a waterfall, you account for unknowns. I've put right in my project plan, "3 months, stuff we didn't anticipate." Waterfall forces the business side to think about what they want. Agile lets them be creative snowflakes all throughout the project.
Remember, waterfall can have multiple phases. Phase 1 is the core of the application, what it needs to do, what it was designed for. Phase n is for all the stuff to improve, move with the times, automate, etc.
Re:
Score:
by
pixelpusher220
( 529617 )
writes:
Agile has issues in terms of scale. It is great for small projects, works for Medium then as you get larger it begins to fall apart
This. What I find funny is that it's use is generally the reverse of where it would be most beneficial. A large established mature project would be great for Agile as it can handle the smaller delta's. These are usually in larger companies who won't touch Agile.
Consulting which is generally ground up work on the other hand with major changes loves Agile.
Re:Agile is the answer to everything
Score:
, Insightful)
by
Shados
( 741919 )
writes:
on Friday October 17, 2014 @09:56AM (
#48168303
Joke aside, that's basically the issue. "You're doing it wrong". Now there's various flavors of Agile, and one size doesn't fit all. But often, when people use "hybrids", instead of using the best of both worlds, they use the worse.
So we want sprints, but I can't just let my engineers work unchecked! So we'll have a full day planning meeting every 2 weeks, and a checkpoint meeting every week. The daily standups are going to last 45 minutes, and the PM will also have a 20 minute talk with each individual every day to see if anything changed during the day!
Now, I also want the full design documents and architecture up front, before the sprint start, lets have everyone sign off on it, and if anything changes, we'll just extend the sprint.
/true story, happened at my last job...I quit a month and a half in.
Nothing is set in stone and each company has to figure out what will work for them...but virtually all the "hybrid methodologies" or pseudo-agile I've worked in only took the parts of Agile that suck, slapped in the worse parts of Waterfall on top, then wondered why it was a shit show.
Parent
Share
Re:
Score:
by
Zalbik
( 308903 )
writes:
The problem is that unless your business IS software
Exactly this.
I've found agile typically a poor solution for building non-trivial internal software for a company.
Issues I've found with in-house pure agile:
- regular access to the customer is problematic
- need to re-architect during sprints due to unforeseen requirements
- inability to produce reliable estimates or determine whether buy/build/make-do is the best option
- running over time/budget due to poorly analyzed requirements
The big "win" of agile is s
Re:
Score:
by
Dastardly
( 4204 )
writes:
That is weird. I find it much harder to get access to actual users for externally facing software. At least for internal software the user works for the same company. The fact that the company doesn't actually want the users to contribute their knowledge of how they actually do business to the creation of the software that is supposed to help them do that business seems like a dysfunction that will doom a project regardless of the methodology. Interestingly, the project itself might not get the doom, bu
Some flavors of agile fight human nature ...
Score:
by
perpenso
( 1613749 )
writes:
The problem is that unless your business IS software
Exactly this.
And it gets worse for some flavors of agile, for example where any programmer can get assigned to any task any part of the code, etc.
Aside from the implicit assumption that all parts of the code are equivalent and all programmers are interchangeable, which may be true to some degree for the corporate IT projects that some agile books use as their wonderful success stories and basis, this fights human nature. Some people are productive and happy bouncing around different parts of a project, but others ar
Re:
Score:
by
neoritter
( 3021561 )
writes:
One of the key tenants for Agile though is that developers pick the tasks they're going to work on in a sprint.
Re:
Score:
by
perpenso
( 1613749 )
writes:
One of the key tenants for Agile though is that developers pick the tasks they're going to work on in a sprint.
But some flavors say that developers are supposed to work on all parts of the project. So yes they may be able to pick the individual task but they might not be able to pick a task from an area they prefer.
Re:
Score:
by
Dastardly
( 4204 )
writes:
But some flavors say that developers are supposed to work on all parts of the project.
I think that is a misreading. Development teams should be assigned to end to end features. Development teams can be specialized in particular features and the components associated with those features. Development teams should be allowed to work on whatever component is required to implement their features, including some that may only be peripheral to their core components in order to complete a feature. Experts should be available to assist with modifying those peripheral components. That means teams
Re:
Score:
by
perpenso
( 1613749 )
writes:
But some flavors say that developers are supposed to work on all parts of the project.
I think that is a misreading. Development teams should be assigned to end to end features. Development teams can be specialized in particular features and the components associated with those features. Development teams should be allowed to work on whatever component is required to implement their features, including some that may only be peripheral to their core components in order to complete a feature.
I think we are describing two very different sized projects. I'm not referring to very large projects that are implemented by multiple development teams. I am referring to more modest sized projects where there is a single development team; several different small projects that are developed/maintained by a single development team; etc.
I'd have to go find the book that a previous manager read and fell in love with, but it was pretty clear. Don't let someone always work in the same area or always avoid a
Re:
Score:
by
hondo77
( 324058 )
writes:
I would suggest that your four issues are symptoms of a bad Scrum Master or a company that won't let the Scrum Master do his/her job. We're using Agile for large in-house projects and it works fine. The company has to buy in to it, of course, which it has. I mean, if you don't even have regular access to your in-house customers, it's not the fault of Agile.
Re:
Score:
by
ripvlan
( 2609033 )
writes:
Scaled Agile Framework or Unified Process?! Some people might call it Scrum-fall.
Working in a big org on a big product I can see why somebody would suggest mixing both. The problem is - taking the "good" things from both rather than the bad things.
For example, If you want telemetry data sent back to a repository (to track feature usage) - you might want the architecture of that figured out "up front" rather than retrofit. I say "you might." In Agile it might be an important spike to get closed up front
Agile in Aerospace
Score:
, Interesting)
by
Anonymous Coward
writes:
on Friday October 17, 2014 @10:05AM (
#48168381
Aerospace is one of the most conservative coding industries out there. We've found a combination of waterfall and agile that works. We use agile for UI development within each waterfall. It turns out that, in spite of decades of human factor research, getting UIs right is very, very hard. So, we've been using a mixture of agile for the UI itself, and waterfall for everything else, and only pushing the UI to certification when a build is going forward. This allows us to (forgive me, engineers) unfuck what the engineers dreamed up, get to a useful interface, and then still have some time to fix (really reverse engineer) the design documents to get them to match the UI. This has worked very well.
Parent
Share
Re:
Score:
by
pigiron
( 104729 )
writes:
This needs to be modded up.
Re:
Score:
by
RyuuzakiTetsuya
( 195424 )
writes:
If Agile isn't working for you, you *are* doing it wrong.
"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more."
Now, this kind of thinking is usually re
Marketing or Research?
Score:
, Insightful)
by
yorgo
( 595005 )
writes:
on Friday October 17, 2014 @09:40AM (
#48168171
Sogeti has been presenting marketing as research for years with their World Quality Report:
[sogeti.com]. This smells similar.
Share
Re:
Score:
by
yorgo
( 595005 )
writes:
Thus far, I've been unable to find the actual report. I found and downloaded the "Summary of Key Findings", which says, "This report provides a brief summary of the important results from the full 2014 CRASH Report.". But, I can't actually find the "full 2014 CRASH Report".
This is making it difficult to evaluate. Perhaps on purpose...?
Re:
Score:
by
yorgo
( 595005 )
writes:
The CRASH 2014 "Summary of Key Findings" can be found at
[castsoftware.com] / ADVERTISING-CAMPAIGNS /
(emphasis mine)
Shocking News - One Size Doesn't Fit All
Score:
, Informative)
by
i_ate_god
( 899684 )
writes:
on Friday October 17, 2014 @09:41AM (
#48168183
I'm as surprised as you are...
Share
Re:
Score:
by
yorgo
( 595005 )
writes:
On that note:
[ipetitions.com]
Help stop "one size fits all" standards!
Re:
Score:
by
Matheus
( 586080 )
writes:
...also:
Can't speak for the development community at large but I have yet to work in either a purely Agile OR a purely Waterfall project yet. Every one has been a balance of both and it has worked quite well so this research seems stale to me.
Given I've "only" been in the development world for 15 years I missed Waterfall's heyday (Thank Jebus) but its not like the switch flipped all the way over. Agile and a variety of other procedural breakthroughs just add to the development toolbox from which to pick th
I tried this. Once.
Score:
, Insightful)
by
xxxJonBoyxxx
( 565205 )
writes:
on Friday October 17, 2014 @09:52AM (
#48168251
In the late 2000's our fast-moving company was acquired by a slower one out of Boston coming from a history of using waterfall and experimenting with agile. The result was an unmitigated disaster. We had a bunch of Siemens castoffs demanding detailed project plans, down to the exact fix we would implement for every bug, for software six to nine months out. Then we ran agile within dev teams to knock off specific pieces of the application. The combination exposed the worst of both worlds: a lack of flexibility which hurt us in the marketplace and annoyed top customers, and a slow-down of team productivity once they realized that pulling additional work into a sprint wouldn't get them any rewards. And that was before we started to have to tack on "quality sprints" where QA would spend 3 weeks looking for bugs and separate dev teams would react the FOLLOWING sprint.
So...what have I seen work? Define which MAJOR features make up a release, direct agile teams to code toward those, enforce test building at all levels, and REWARD teams that are kicking butt, whether that's churning out some of the MINOR features, being the team known for "bug-less" code, working with UI folks to write up a new interface that customers love, or whatever.
Share
Re:I tried this. Once.
Score:
, Insightful)
by
tomhath
( 637240 )
writes:
on Friday October 17, 2014 @10:39AM (
#48168683
the root of that issue is that customer was not aware of the internal process change
The root of the issue was that the project managers managed it waterfall/PMI style while pretending to be agile. I've seen that happen too many times - you go into sprint "planning" and are handed the list of stories that the PMs already decided will be worked that sprint.
Parent
Share
Re:
Score:
by
xxxJonBoyxxx
( 565205 )
writes:
>> root of that issue is that customer was not aware of the internal process change, or it was not communicated in the right way
The customers here were businesses paying for some high-end commercial software. They didn't and wouldn't have given a s*** that our internal processes changed - they just saw releases slow down, quality drop, and their input seemly ignored.
I'd say the root cause here was that the acquiring company killed the feedback loop between customers and development teams with bloated
It never ends
Score:
, Insightful)
by
Forgefather
( 3768925 )
writes:
on Friday October 17, 2014 @09:55AM (
#48168293
"CAST Research on Application Software Health (CRASH)"
Is this what computer science has come to? Nested acronyms?
For fucks sake keep your names short and to the point.
Share
Re:
Score:
by
itzly
( 3699663 )
writes:
We've already had mutually recursive acronyms so this is child's play.
Comment removed
Score:
, Insightful)
by
account_deleted
( 4530225 )
writes:
on Friday October 17, 2014 @09:59AM (
#48168323
Comment removed based on user account deletion
Share
Re:
Score:
by
angel'o'sphere
( 80593 )
writes:
Agile and scrum usually have less meetings than 'traditional' methods.
So calling them an excuse for 'more' is very dishonest.
If your organization
claims
to use
agile methods
but calls you into meets, then you are not agile!
Or as we say: you are doing it wrong!
Fire your agile consultants and get real ones! And most important build up agile know how in your own environment, get rid of consultants all together!
Re:
Score:
by
Your.Master
( 1088569 )
writes:
Very short feedback loop and adaptation cycle
A common characteristic of agile development are daily status meetings or "stand-ups", e.g. Daily Scrum (Meeting). In a brief session, team members report to each other what they did the previous day, what they intend to do today, and what their roadblocks are.[14]
From
[wikipedia.org]
Can you tell us the one true agile that doesn't have lots and lots of meetings? In my experience, Waterfall frontloads a few megameetings, whereas Agile backloads them in nickels and dimes.
Re:
Score:
by
angel'o'sphere
( 80593 )
writes:
The parent talked about 'meetings' as in sitting around for hours, if not a whole day.
In agile processes you have a team meeting each day that lasts 30 seconds per developer.
So with ten developers it is 300 seconds which is 5 minutes.
So, what is your point?
Re:
Score:
by
Kazoo the Clown
( 644526 )
writes:
Agile is just another ritual. And what is ritual? Abandoning the ends and embracing the means. Someone claims Agile is the way to go and the suits have found their latest ritual. There is no comprehension, it's just a superstitious cargo cult.
duh
Score:
by
Lije Baley
( 88936 )
writes:
on Friday October 17, 2014 @10:04AM (
#48168379
You just need to use the right mix for the type of project you have, with the main factors being the amount of unknowns and the level of complexity. Iteration is necessary to understand the unknowns, and high-level design/planning is necessary to tame complexity. Just be open-minded, like the fathers of agile intended, and avoid methodology "religions" like Scrum and its multitude of counterparts on the waterfall side.
Share
Re:
Score:
by
__aaclcg7560
( 824291 )
writes:
Poll: Program while drunk? Can do, or no way?
From a QA tester perspective: Oh, hell no. Nothing worse than dealing with a new build on Monday morning after the programmers get drunk from the Friday beer bust and work all weekend long in a drunken stupor.
Selling methodologies
Score:
by
tomhath
( 637240 )
writes:
on Friday October 17, 2014 @10:19AM (
#48168497
Agile has been around long enough that consulting sales are falling; companies like this need to invent something new to sell. What better way to reach the unwashed masses than a slashvertisement?
Share
Quality and Productivity
Score:
, Insightful)
by
under_score
( 65824 )
writes:
(moc.gietreb) (ta) (nikhsim)
on Friday October 17, 2014 @10:29AM (
#48168591
Homepage
Disclaimer: I work as a consultant for large and mid-size businesses.
My experience is that there is no magic bullet for quality, but that there are a few things you can do that will dramatically improve things. What Agile methods bring to this is that they provide fast feedback with customers and users. This means that if the team actually bothers to use the feedback, that they can produce things that have better customer and user perception of quality. Additionally, Agile engineering practices such as refactoring and test-driven development can be used to effectively prevent most technical quality problems. Agile borrows heavily from Lean thinking in which one of the ideas is to build quality in (instead of testing at the end). Lots of practices of Agile methods support this idea and, on rare occasions, I have seen Agile teams building complex systems with defect rates close to 1 or 2 low impact defects per
year
That said, the disciplines of waterfall thinking are often lost when an organization switches to Agile. These disciplines around deep analysis, seeing the big picture, etc. are all still important. They should be done differently with Agile, but they shouldn't be forgotten.
Unfortunately, most teams and organizations do neither waterfall nor Agile well. This is because management has a poor understanding of what it takes to properly support staff who are doing complex creative problem-solving work. Instead, management tries to control staff as if they were assembly-line robotic resources. Ultimately, to be effective with software development, management needs to treat software developers as each being unique, autonomous, and deeply valuable for their own talents, skills and experiences. Likewise, software developers have to stop treating customers and users as idiots... they're not. Agile methods, as a set of values and principles, are about changing these relationships to make them more healthy for everyone involved.
Share
Re:
Score:
by
gov_coder
( 602374 )
writes:
I couldn't agree more. The only thing I would add is that Zed
said it
[programmin...fucker.com] best. No methodology in the world can make up for a lack of skill.
Agile requires certain assumptions...
Score:
by
swan5566
( 1771176 )
writes:
on Friday October 17, 2014 @10:31AM (
#48168607
...to be met, like being able to be completely interchangeable with other members on your team, and having prior art to reasonably predict every aspect of effort. If that's not the case (say, in an R&D project where certain people are specialists in certain areas), this method does more harm than good. My best suggestion for using which method is to let the nature of the project choose the method, rather than the other way around.
Share
New Method on the horizon!
Score:
by
Virtucon
( 127420 )
writes:
on Friday October 17, 2014 @10:44AM (
#48168715
New Methodology blah blah Agile blah blah blah Waterfall blah blah blah
Nobody wants to hear that! What they want to hear is when their software will be finished or their system ready. It has to work, work reliably, meet the requirements and be on time. That's all the customer wants.
Share
Re:
Score:
by
Anonymous Coward
writes:
And you've just pointed out why Agile is a steaming pile of crap.
Customers want to know when their software is going to be done and ready for them to use. Agile substitutes time estimates (which are hard and we all suck at) for "story points", which are supposed to be level-of-effort measurements that can be time-flexible at an individual level. So instead of a manager deciding how long each developer will take to do a given task based on their knowledge of that developer's skill level and other workload, t
That's how it always worked
Score:
, Insightful)
by
Anonymous Coward
writes:
Newsflash, this is how projects were 'managed' for the last few decades. MBAs plan using waterfall and, the project is "on track" till pretty much the end of the development phase, and then shit hits the fan during QA. Then, everyone goes "agile".
Agile is a bit like a religion
Score:
by
Anonymous Coward
writes:
The basic dogma is that it works. If it does not work for you, it is because you are doing it wrong.
Quite frankly, all these methodologies that have been foisted on the software development world throughout the years amount to little more than fads with very little in the way of a scientific basis. They are just modern day snake oil.
Re:
Score:
by
Anonymous Coward
writes:
Incorrect. The different agile methodologies are sound in theory just as waterfall is sound in theory. They all work extremely well WHEN YOU FOLLOW THEM. The problem is no one correctly follows them (due to stupid people and the world being complex). Waterfall is the best practice if your requirements don't change and communication has been 100% on what's needed. It was designed for those requirements. Most agile practices are about smaller waterfall iterations leading to more feedback from the user.
Re:
Score:
by
Kazoo the Clown
( 644526 )
writes:
Managers aren't scientists. They're bureaucrats, or politicians, or bean counters or some combination of those. And they're in charge because they dispense the paychecks. If a methodology takes any significant understanding to make it work, it's too complex for its target audience. That is why every few years a new fad methodology with a new set of buzzwords sweeps through, sold by the latest round of salesmen who make a killing on it. But when it boils down to it, it's just another bit of voodoo ritua
sonarqube integration
Score:
by
BoardHead007
( 1252142 )
writes:
if this tool can analyze structural quality they should create an open source plug in to sonarqube.
additionally they should show the results of the tool and not someone's analysis of the data in text format.
SPAC
Score:
by
unixcorn
( 120825 )
writes:
Agile, scrum, whatever. They are just buzzwords for some sort of kool-aid to empower programmers when they feel powerless. None of this can ever work unless the folks ordering the software or software changes know what they are asking for (rare) or provide an unwavering list of requirements. Most software projects go over time estimates or fail because of SPAC. Specification Provided After Completion.
How many suspension bridges...
Score:
by
pigiron
( 104729 )
writes:
and airliners were designed and built using Agile engineering methods.
That's right, exactly zero.
We should learn from municipalities, not toyota.
Score:
by
140Mandak262Jamuna
( 970587 )
writes:
Agile process has its roots in the process used by the industrial engineers of Toyota, Japan in improving the quality of the process. It is interesting to note that the success of Toyota, Japan, is not easily replicated, and even Toyota, USA and other siblings are not able to be as efficient as Toyota, Japan. This process is good for making multiple copies of a well known object using large number of workers with highly interchangeable skills, and the process could be broken down into very small pieces wher
WTF?
Score:
by
sunderland56
( 621843 )
writes:
on Friday October 17, 2014 @12:09PM (
#48169525
Agile and waterfall are *management* methods. Code quality is a function of *developers*.
If you want quality code, stop pissing off your developers, and choose the least intrusive management method, so people can do their work.
Share
Re:
Score:
by
angel'o'sphere
( 80593 )
writes:
Both is wrong.
Waterfall is a 'planning method' has nothing to do how you 'manage' the project.
Agile is a 'development method' has again nothing to do with either 'planning' or 'managing'.
If you mix up that shit it is no wonder your organization has trouble to make software.
Hint: extreme programming is an agile 'development method' where everything around crafting software is emphasized and turned into the mid of the focus of developing. No 'planning' except for sprints and absolutely no 'managing' involved
WTF?
Score:
by
SlowMovingTarget
( 550823 )
writes:
Aye:
[blogspot.com]
DevOps
Score:
by
asylumx
( 881307 )
writes:
From what I hear, this is all old news anyway and we should all be switching to devops!
Sigh...
Score:
by
biodata
( 1981610 )
writes:
Like we used to do in the 90s and just called it 'engineering'.
It's Called the Avalanche Model
Score:
by
Maltheus
( 248271 )
writes:
They already have a
name
[wikipedia.org] for this.
From the wiki:
The Avalanche model is a Software Engineering project management anti-pattern, it is a combination of a sequential process such as the Waterfall model and Agile software development methodologies. It is the result of a Project Manager's attempt to apply Agile techniques to a project, when all they really understand or were taught was a sequential development cycle. Instead of breaking the project into parts that each sequentially go through the phases of development, the entire project inhabits all phases of development simultaneously. Usually the result of attempting to use the Avalanche model is mass confusion, wasted effort, and a product that cannot meet the specifications of any requirements document.
Mix Agile with Waterfall
Score:
by
PPH
( 736903 )
writes:
We'll call it "Mudslide".
DUH
Score:
by
recharged95
( 782975 )
writes:
You use the tools the way they were designed AND purposed (folks forget the 2nd part). And you use the tools for their strengths, not their weaknesses, aka as needed--
which is also known as experience
Otherwise you're just following a religion.
Almost all management is risk management...
Score:
by
frank_adrian314159
( 469671 )
writes:
And to try to control project risks, we have many best practices. Some work well in a given industry, some don't; some work well for a given product, some don't; some work well in a given organization, some don't; some work well for a given team, some don't; and some of them work well together, others don't.
The sad thing is that we underestimate these contextual issues, everywhere in our industry - from process consultants who want to sell their expertise, to Agilistas who sacrifice their objectivity to the
Experience
Score:
by
Livius
( 318358 )
writes:
We're using FrAgile and Waterfall and our project has had to be halted for the second time in two years.
Agile (the way we're doing it, probably the wrong way) doesn't scale. If the project is 100 people, half of whom have never met the other half, then a daily meeting is impossible and attempts just degenerate into people checking off boxes but mainly consuming enormous amounts of time without actually communicating anything of value.
On the other hand, my personal suspicion is that "Agile" was really the v
Related Links
Top of the:
day
week
month
272
comments
Microsoft To Replace All C/C++ Code With Rust By 2030
265
comments
Python Foundation Rejects Government Grant Over DEI Restrictions
207
comments
At Amazon, Some Coders Say Their Jobs Have Begun To Resemble Warehouse Work
187
comments
Ask Slashdot: Would You Consider a Low-Latency JavaScript Runtime For Your Workflow?
187
comments
The Great Software Quality Collapse
next
OS X 10.10 Yosemite Review
305
comments
previous
An Air Traffic Control System For Drones
77
comments
Slashdot Top Deals
Hackers are just a migratory lifeform with a tropism for computers.
Close
Working...