Agile development [closed]
At university we talked about agile programming, but also how many agile methods aren't used in business, like pair programming.
I would like to know which methods belong to agile programming (extreme programming, pair programming) and which are really used / do you use. What about iterative and incremental development?
edit: to those who wanted to close that Question because of "subjective and argumentative". This question can be answered,because agile development is a defined expression. http://en.wikipedia.org/wiki/Agile_software_development. Further more开发者_开发技巧 many Users are interested in this Question, to close it isn't well considered
Agile development is not a methodology in itself, it's an umbrella term that describes several agile methodologies (that all belong to the Iterative and Incremental Development - IID - family).
alt text http://img62.imageshack.us/img62/6374/dd997578teamprojagileum.png
At the signing of the Agile Manifesto in 2001, the following methodologies were represented: eXtreme Programming (XP), Scrum, DSDM, Adaptive Software Development (ASD), Crystal, Feature-Driven Development (FDD), Pragmatic Programming. Each of them share the core values of the Agile Manifesto but implement them with a slightly different approach.
In contrast, pair programming is an engineering practice (it is one of the practices of XP which captures many practices as an indivisible set but you can use it outside of XP). And, while I value practices very much, just keep in mind that practices are not an end, they are just a mean as I wrote previously. Agile is not about doing pair programming, stand up meetings, etc. Agile is about maximizing the customer value while minimizing waste to provide the most optimal ROI. Agile is business oriented, practices are just a way to achieve this goal in a given context.
Scrum and XP (used together) are the most commonly used nowadays.
Some Recent Empirical Data About Practices in Use in Industry:
I just came across the Agile Practices Survey Results: July 2009. It's a fairly small sample set (123), but it offers some interesting perspective. For instance, the top 10 most effective agile agile practices (as reported by respondents) were:
- Continuous Integration
- Daily Stand Up Meeting
- Developer TDD
- Iteration Planning
- Code Refactoring
- Retrospectives
- Pair Programming
- Active Stakeholder Participation
- Potentially Shippable Software
- Burndown Tracking
There are also charts for top 10 agile practices that:
- are believed to be easiest to learn.
- are believed to be hardest to learn.
- were most likely to be tried and then abandoned.
- people want to adopt but have not yet done.
The Practices are Not the Point
We don't do the practices for the practices's sake. The agile practices come out of following the agile principles as explained on the manifesto website. The highest agile principle is: "to satisfy the customer through early and continuous delivery of valuable software". Early, continous, and valueable are the key words there. If a team doesn't understand the how the principles drive the practices, then they run the risk of being, as @Guildencrantz said, cargo-cult, not having the magic-bullet success that they expect, declaring agile a failure, and abandoning it.
It's Easier to be Agile on a New Project Than it is to Convert a Project to Agile:
I don't have a good citation at hand, but it's generally thought of as easier to be agile on greenfield projects than it is to convert a brownfield project to agile. One reason for that is that existing code is often written in a way that makes it hard to add automated tests. Michael Feathers wrote a whole book about adding tests to legacy code.
Sounds like you really want to know what people are actually using in the real world. There are plenty of sites about what is in and what is not an Agile practice/methodology.
So, my experience so far in my recent (last 5 years) roles:
- Nobody used pair programming except in panic situations (major bug fix in zero time), managers still just don't buy into the idea at all - and I'm talking AT ALL, which is a shame as I quite like it.
- User stories and users choosing a deck for next release - doesn't really work unless the users really really buy in, which I've not seen yet. Users in my area always say that everything is of top importance, they cannot live without any of it. I personally just rephrase into "what order should I personally work on these tasks in your opinion?".
- Test driven dev - very little of this happens, but a lot of unit tests get written (after the code does though), so a near miss imho
- Continuous integration - this is highly dependent on the team, in last 5 years all my teams had it, but it often lapsed (broken build) for days/weeks at a time before it got attention. A lot of people still don't buy into this.
- Refactoring often - this is actually getting some serious buy-in. Refactoring is a skill that if you don't have is likely to be a serious problem.
- Small releases - this (in my work) is generally the norm anyway, although probably being done
- Coding standards - yes
- Collective code ownership - blame is still pretty much rife, and often a "bad" module never really gets fixed cos the coder that produced it just fixes and fixes it till it "works".
- No overtime - nearly, but highly dependent on the team lead - I've seen the worst stuff (death marches) going on within a few feet of my team...
- Tests first when find bugs - this happens in my experience. Is a very good thing.
Most of experienced developers have become project managers since or IT directors. Back then, about 20 years ago, those methodologies such as Agile Software Development didn't even exist, and they were able to produce and to deliver working systems.
These same guys might lack the knowledge of such proposed practice from these new methodologies resulting of some sort of resistance against bringing forward those approach.
We cannot be rough at them for so, they only resist to changes they don'T know or even understand, just like let's say a customer who is used to work one way, and then we come with our new methods and then change this customer's habits within a day! It's quite normal that these resistances occur, they're human bahviours.
Furthermore, for some of these more experienced-guys, they don't just don't get the point of working in pair, for example. Just like they generally don't believe in scrum meetings, they prefer the old-school way, which has known its success in some way, of a meeting lasting from 1 to 2 hours a week.
As for administrators, those responsible for the budgets of programming resources, it is seen, as for pair programming, to pay a programmer doing nothing while this doing-nothing-programmer could work on another part of code to multiply productivity. You cannot really blame them neither, as what they think makes full of sense.
Some suggestions from the Agile Software Development are easier to get the benefit from in comparison to some others. While pair programming might not know a real success in practice, or even daily scrum meetings, what is a success though, in my experience, is beginning coding as soon as we get a precise enough sketch of the software, its requirements and features, never to forget the priorities given from the customer himself. Then, updating the UML analysis while developing for an iteration.
Software iterations, in my experience, begin a growing success.
Let it time, Agile Software Development, such as Test Driven Development, well in my region, are still new stuff. Once they will get more practitioners, their practiced practices will grow with it, I believe.
It depends on company to company. I work for a company that does all TDD, all pairing, all CI, all the time. The team isn't afraid to call you on it if you submit code, but didn't submit unit/FitNesse tests, and less than a minute after you submit code, the CI server runs the whole suite of tests, and if your code breaks the build or Amy ofthe tests fail, lights go off and you're flagged as the one that broke the build.
It's not the most common situation, but there are companies out there that truly do practice Agile.
In business I think you generally will see teams taking the aspects they like from different programming methodologies and combine them into their own practices. They they will probably apply whatever term they want to it even though it's not 100% accurate.
In our team we apply daily stand-ups and team programming (about half the time--depends on the task). We don't claim to do agile though.
The agile methodology is a basis for agile development.
In other words, eXtreme Programming, Scrum and so forth are agile methodologies based on agile principles. Checking out these in depth will answer your questions.
As for agile itself, and what all these types of agile development have in common check out Wikipedia for a nice overview.
Thoughtworks is one of the companies that have Agile Development in force. Read more about Agile development directly from Martin Fowler's website.
- Scrum is very popular (although it's just a management technique rather that a technical discipline)
- Extreme programming is a lot less popular, although it does get applied. (I've done loads of commercial XP projects - although it is hard to find teams that want to do XP.
- Test-Driven Development (TDD) is part of XP, although many people do it (and a lot more say that they do...)
Lots of people seem to misunderstand concepts like refactoring, pair programming and the general concept of self-organising teams... those can be difficult for people who've gotten a measure of success from waterfall and have gotten entrenched in that way of doing things. It is a problem getting those people to try XP.
As others have mentioned agile is an umbrella term and can be implemented in a number of different ways; that being said agile's current buzzword status has lead to a lot of companies trying to implement agile who really just implement a set of cargo cult-esque procedures and expect agile's flexibility.
In my previous company, the managers grabbed a hold of agile like it was the answer to all their problems. But the only thing it did was create a whole lot more problems.
We had very regular meetings that were called "standups" (some sort of agile term).
I think they tried a lot of agile techniques but it didn't really work well for us at the time.
加载中,请稍侯......
精彩评论