|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 22
Messages: 22
Messages: 22
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Tech Talk: Scott Ambler, on the Agile development process
Scott Ambler, author of a number of books on Agile programming such as "Agile Modeling," "A Practical Guide to Enterprise Architecture," and "The Elements of UML Style", offers this tech talk on the use of the Agile method, such as what it is, why it works so well, and why you should use it instead of the traditional development methods. He also discusses the political implications of Agile programming, and how much people new to Agile programming should commit to it.
View Tech Talk
|
|
|
Message #169192
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
what parts work well?
Vic, as your friend, I'm going to have to call bullshit on this one:
>> For consulting it's good,
>> you double up billing in pairs,
We don't increase the size of the team for the sake of pairing. In fact, we typically prefer smaller teams. If anything, we just like even numbers.
>> you have no requirements and
Not true. We have the most fine grained requirements that are practical. A step by step description of exactly what a developer will do over the course of say two or three days (up to 5 days). This is versus the traditional BINDERS of information I used to receive on waterfall projects.
The key is focus. I can focus on a story and a short set of developer tasks. A binder just gathers dust as I thrash away on a waterfall project for months at a time.
>> you have verbal deliverable and
This is crap too. Agile methods are all about visibility. Not only do we have very clear deliverables, but ANYONE can walk into the room and see exactly what those deliverables are, AND how much progress has been made.
>> make friends w/ client in pairs
Well, yes. This is true. We always like to make friends, and often do. ;-)
Cheers bud.
Clinton
|
|
|
Message #169193
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No siver bullet ... so whats news?
Briefly skimed your anti-XP propoganda. You raise what to me seems to be an obvious point. Reading "XP explained" or all 20+ XP books won't gaurantee success.
The truth is that there is no substitute for skill and experience, what ever process you choose/devise. Agile proponents are the first to highlight this fundamental truth.
The strengths of XP (and the other Agile practices) IMHO is that they draw attention to the real bottle-necks in organisations through constant concrete feedback.
The upshot of this is that organisations have the data to determine their real problems. Often these problems may not be in development, choice of technology etc, but in other areas such as organisational culture, management, inept marketing, or poor project conception.
XP allows the programmer the possibility to take responsiblity for just programming, rather than being a convienient scape-goat for all an organisations ills.
For this reason alone, if you are serious about exploiting technology for business benefit, XP is worth a look.
|
|
|
Message #169205
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
what parts work well?
Vic, as your friend, I'm going to have to call bullshit on this one. ;-)Cheers bud.Clinton
I hope I did not lose a fried....
See http://www.softwarereality.com/lifecycle/xp/xp_audience.jsp
I consider myself a student of productive development. I have another good friend who lived trough XP.
He also agrees with this:
http://www.softwarereality.com/lifecycle/xp/safety_net.jsp
I do not consider XP the ultimate in producitity, and I just gave an url, where there are lots of case stories
http://www.softwarereality.com/lifecycle/xp/forum1.jsp
http://www.softwarereality.com/lifecycle/xp/forum1.jsp
etc. form2, form3...
Since some may not link, here is a cut/paste:
"Imagine
Imagine there's no requirements. It's easy if you try
Just a bunch of coders, reachin for the sky
Imagine all the people, coding for today
Imagine there's no schedules. It isn't hard to do
No silly project deadlines, no one supervising you
Imagine all the people, coding hand in hand
You may say I'm an extremer but I'm not the only one
I hope someday you'll join us and make coding lots more fun.
Imagine oral documentation. I wonder if you can
No need for UML diagrams. Just words passed, man to man
Imagine just refactoring, playing in the sand
You may say I'm an extremer, but I'm not the only one
I hope someday you'll join us and make coding lots more fun.
"
from http://www.softwarereality.com/lifecycle/xp/extremers.jsp
If you say what's my alternative? "Scientific development" and key part is independently dupicable and repetable process, as per CMM levels of maturity.
I just try A vs B and see which makes me faster. I mostly do fixed bid, and rely on mockups of the view and reports.
Great book is "return on software", talks about ROI.
.V
|
|
|
Message #169208
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Sounds good
Sounds good to relieve developers from the weight of problems not related to the scope of their project.
However, wouldn't an approach that relies more heavily on documentation be useful to set the boundaries of that scope ?
|
|
|
Message #169227
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Sounds good
Yeah a valid point. This approach can work too but...
How many customers do you know who are willing to read a 150+ page requirements document?
If they do read it how many of them are sure what it is they are about to sign up to?
Once they've signed, how many customers change their mind?
How many businesses change so quickly that most documentation is quickly out of date?
Buy customer I mean any stakeholder outside the development team. In most organisations these folks feel free to change the development contract at will, yet expect the deliver date to stay constant.
In fact I've worked on several projects, where the only thing we knew for sure was the expected delivery date - despite loads of (useless) documentation. I'm sure this is a common experience.
Paul.
|
|
|
Message #169243
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sounds good
How many customers do you know who are willing to read a 150+ page requirements document?
Hopefully, the requirements document (e.g Use Cases) is being elaborated together with the customer and not in a devloper's ivory tower. At least this should be the common practice, and IMHO it is in most projects (at least the ones I worked in).
If they do read it how many of them are sure what it is they are about to sign up to?
Huhh? I guess most of them can read. In fact, requirements specify what is to be developed in terms of business. So, who, if not the customer, understands the business. Especially, if the requirements were elaborated together with the customer's business departments (see above).
Once they've signed, how many customers change their mind?
Many, but that is not the point. When explicitly capturing requirements and making them a part of a contract, any change of requirement induced by the customer is a change request! Explicitly capturing requirements is the only way to protect you against late changes.
In fact I've worked on several projects, where the only thing we knew for sure was the expected delivery date - despite loads of (useless) documentation. I'm sure this is a common experience.
Well, from my experience, this is clearly not the case.
Regards,
Dirk
|
|
|
Message #169285
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sounds good
How many customers do you know who are willing to read a 150+ page requirements document? Hopefully, the requirements document (e.g Use Cases) is being elaborated together with the customer and not in a devloper's ivory tower. At least this should be the common practice, and IMHO it is in most projects (at least the ones I worked in).If they do read it how many of them are sure what it is they are about to sign up to? Huhh? I guess most of them can read. In fact, requirements specify what is to be developed in terms of business. So, who, if not the customer, understands the business. Especially, if the requirements were elaborated together with the customer's business departments (see above).Once they've signed, how many customers change their mind? Many, but that is not the point. When explicitly capturing requirements and making them a part of a contract, any change of requirement induced by the customer is a change request! Explicitly capturing requirements is the only way to protect you against late changes.In fact I've worked on several projects, where the only thing we knew for sure was the expected delivery date - despite loads of (useless) documentation. I'm sure this is a common experience. Well, from my experience, this is clearly not the case.Regards, Dirk
This has been my experience. It is easy to say make it part of the contract, but in reality this is harder. This is my 10th year of working and as such I've been reflecting on the projects and customers.
I've never had a customer that cared about "change requests". From govt. to telecome to credit card, they all want what they want. And when you explain to them that they signed off on the feature set and their new items are change requests, they all, without fail threaten to drop the thing if they don't get what they want.
If you have a contract that is iron-clad enough to protect you from this, then give me the name of your contract lawyer. I can find PLENTY of work for him.
The point is that customers can and do change their minds and they want what they want.
Also, they don't read documents. Ever. I've had cases where we had to read the documents to them to get them to read. Perhaps your customers are smarter, the applications I've worked on over the years were made to help people do what I would consider drudge work do it faster and more efficiently. These guys, most of the time,didn't even know they could change the resolution on their computers or how to upgrade a browser. How many of them can understand even use case documents. Again, none.
|
|
|
Message #169305
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Points
I agree with all comments. In my experience too, requirements change so often that documentation is always out of date.
However, I do not think this would invalidate the need for thorough documentation. Take the "Vision" document from RUP, for example. It is a description of the problem and the proposed solution, in a language you and your customer can understand. I have seen at least one instance where this document was perfectly valid until the end of the project, and had to undergo only minor changes.
As to the various use cases and the implementation specifics, they certainly change a lot. Maybe at this point XP would be a good alternative.
|
|
|
Message #169307
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Points
I agree with all comments. In my experience too, requirements change so often that documentation is always out of date. However, I do not think this would invalidate the need for thorough documentation. Take the "Vision" document from RUP, for example. It is a description of the problem and the proposed solution, in a language you and your customer can understand. I have seen at least one instance where this document was perfectly valid until the end of the project, and had to undergo only minor changes.As to the various use cases and the implementation specifics, they certainly change a lot. Maybe at this point XP would be a good alternative.
Agreed. I think a small, concise vision document is very important. What are we making? I'm certainly not saying documentation isn't important. But I don't think that documenation makes development as clean as what was implied in an earlier post.
|
|
|
Message #169330
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Points
I agree with much of what has been said too. Perhaps I should not of implied that all documentation is useless.
The undelying issues are communication, accountability and transparency. A document is just a means of communication and could be effective or ineffective. Customers may choose to honour their contract with development or they may not.
Choose what works for you. If things are working than fine. If things aren't working then regular feedback to help determine what works and what doesn't must be a good thing.
Peace.
Paul.
|
|
|
Message #169433
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sounds good
Hi David,
indeed, it seems like we had totally different experiences, when realizing customer projects. In fact, I just rectnelty had a project, where more money was made by realizing change requests, than realizing the functionality of "actual" project. I also never heard a customer say "do it, or we will drop the project". Of course, there were situations, where customers said, that the effort for a change request was too high. But even in this cases, a solution could be found, satisfying both sides (i.e a compromise of making the change request cheaper, and putting less functionality into the change request).
I wonder what the reasons for this different experiences in "customer behaviour" are. "cultural gap"? Project sizes? I don't know.
Regards,
Dirk
|
|
|
Message #169497
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sounds good
Hi David,indeed, it seems like we had totally different experiences, when realizing customer projects. In fact, I just rectnelty had a project, where more money was made by realizing change requests, than realizing the functionality of "actual" project. I also never heard a customer say "do it, or we will drop the project". Of course, there were situations, where customers said, that the effort for a change request was too high. But even in this cases, a solution could be found, satisfying both sides (i.e a compromise of making the change request cheaper, and putting less functionality into the change request).I wonder what the reasons for this different experiences in "customer behaviour" are. "cultural gap"? Project sizes? I don't know. Regards, Dirk
Perhaps the size of the company? The customer doesn't come right out and say it, but I tend to front the development efforts and the implication is pretty clear. I tend to gravitate towards smaller companies and when you do a project for a big credit card company or a big wireless telecom, or a large govt agency, they tend to have a lot of sway over a company in the 30 - 150 person range.
And they know it.
We certainly have compromised:
"Well, we could add these and the time shouldn't push out."
"Well, we can add this but we'll need 3 more weeks."
"Well, how about we trade this for that?"
"Well, we just can't do it in the time allowed."
It takes a strong person on our side to look a company that is the source of a large amount of your business for a year and say "No." Ultimately, we are all talking about our experiences and I'm sure they run the gamut, but I'm always amazed at how stubborn and nasty people can get when all you are trying to do is HELP them.
A couple of weeks ago, I was pulled into a project and mentioned that we need to list out the requirements. The guy on the other side said that he just finished rolling out a $10 million system and all they had were 3 artifacts. One was a use case document, fercrissakes! I said that "strictly speaking, the requirements were in the use case documents." And for a design, he handed me a penciled sketch(unreadable) on the back of a piece of paper.
The guy was acting like he took that sheet of paper, stapled on a $10 million dollar check, and they came back with this application!
|
|
|
Message #169532
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Fixed scope, cost and time can't work
Hi David,
Your experiences are pretty similar to my own, and I've been developing for 15+ years, for much of that time I was in management managing contracts with customers like the ones you describe.
In fact such experiences lead me to get out of management completely. Now I'm a freelance consultant.
Whilst I feel that different processes can work in different environments. I have also come to think that "contract based" development is fundamentally flawed. You can get it to work, but don't rely on the contract.
The reason I say this, is that developmenet is not a defined process, and even if it was it would take a lot more detail then appears in most contracts/specs to precisely define cost, scope and project delivery date. As I've said previously, the only precise fact on a lot of projects is the delivery date. The scope nearly allways as some degree of uncertainty.
It is like the Heisenberg's Uncertainty Principle, you can fix the delivey date or the scope but not both. In most projects, precise details of the scope are determined iteratively as the team discovers issues during design, implementation and even during test.
This is why even with waterfall processes state that the pratices can not be applied in a defined way, and you must iterative through process steps as required. As a project manager I developed a good gut feeling for how much "iteration" would be needed, and added the required contingency to my plans.
Agile development just makes this iteration explicit and a lot more transparent, resulting in a more open, honest and data driven relationship with your customers.
In delivering true business value transparency and concrete feed back are really important (IMHO).
Paul.
|
|
|
Message #170152
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Fixed scope, cost and time can't work
Exactly. There's the concept of the iron triangle, you can't let all three of scope, cost, and schedule be fixed without negatively affecting quality.
I walk away from projects when the managers are unable to accept this reality.
I have an article on the subject at http://www.sdmagazine.com/documents/s=7839/sdm0303g/sdm0303g.htm if you're interested.
- Scott
www.ambysoft.com/scottAmbler.html
|
|
|
Message #170155
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
what parts work well?
The problem with the poem is that it doesn't actually reflect what happens on agile projects.
There are requirements (otherwise there's nothing to build), there are schedules (we just might not waste our time creating big, useless MS project plans), there is modeling (see www.agilemodeling.com), and there is documentation (www.agilemodeling.com/essays/agileDocumentation.htm).
Instead of quoting relatively ignorant and unsubstantiated claims, wouldn't it be better to discuss real issues based on actual experiences with agile processes? Nothing is perfect, and there is significant writings on the challenges with adopting and following agile approaches. My advice would be to focus on them.
Also, as far as CMM/I goes, why is it that in all the years the SEI has been pushing it that they have NEVER done a study comparing the effectiveness of CMM/I level 3+ firms with organizations that are good at software development aren't interested in CMM/I? I think they haven't because they know what the answer will be.
BTW, I'm the methodologist behind the OOSP, the first publicly published CMM level 5 process (when fully instantiated) for OO development. I've followed a wide range of processes, and I can tell you from experience that agile approaches seem to work a heck of a lot better than traditional approaches.
Another thing to think about: why is the SEI now scrambling to claim that their stuff can be agile too? Gotta think that they see the writing on the wall.
- Scott
www.ambysoft.com/scottAmbler.html
|
|
|
Message #171897
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
what parts work well?
Don't believe everything you read at softwarereality.
They do make some good and valid points: XP does have its issues. However, many of the points addressed by the softwarereality guys are no longer valid or pertinent, as the people shaping XP are continually improving it. And, as Mr Ambler suggested, the interpretations of what the softwarereality zealots understand XP to be are often broadly painted and even dead wrong.
I've worked with numerous teams doing XP over the past 5 years. The "real" reality: It's sometimes a disaster, it's sometimes ok, and it's sometimes wonderful--all just like any other project using any other process. My experience has been that it's usually been ok to great more often than it's sucked. To condemn it by linking to a biased site with handful of failed case studies is closing your eyes to the fact that many places are making it work, and enjoying it to boot.
-Jeff-
|
|
|
Message #176366
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
what parts work well?
Agile Programming/Modeling/Testing etc... may work for little projects or very large but less complex projects projects. But there is no way you can use it in huge and very complex projects where you thousands of business rules and constraints to deal with, and believe me pair programming wouldn't help you nor Junit (Test First in your parlance). Only a solid methodology adapted to the size and complexity of the project would work. This doesn't exclude the use of XP within small components of a huge mandate.
Another thing, assessing developer's competence on using or not your approach would be a bit harsh and inappropriate.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
