• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

The Art of Agile Development - is Agile for anybody

 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mr Shore & Warden,

I've never used Agile, and never read a book on it either. I guess I'll have to one day or another. The title of your new book, "The Art of Agile Development", has caught my attention. Up to now, I have considered Agile to be elitist. Probably because I've never used it. But I can't help it. To hear "agile" is like to hear some kind of cult-driven thing Some people call Spring or Hibernate buzzwords, I call "Agile" a buzz word. The "Art" of agile reinforces that image. I don't expect a development methodology to be an art, but to be something anybody can go with. Do you find Agile to be aimed at a bunch of connoisseur, or will your book show me that even I, mere mortal, should give it a try ?
 
Penicela Vasco
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have been reading about Agile Modeling at http://agilemanifesto.org/ and at www.agilemodeling.com , I think its something interesting, I have used it to write my thesis... at Mozambique!...

I think, I take an Agile Approach on you development, You are in the write way to get success!....

I think Agile Develoment is for everbody, anyone can use it! and anyone can have sucess wit it!
 
James Shore
author
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Christophe,

"The Art of whatever" is a common title for books that provide "how to" guides with lots of practical experience-based tips and tricks. That's what our title means, too.

In other words, we're not saying that software development is "art" in some way. I personally feel that software development is more like design engineering than art or craftsmanship, but this is a subject that people get very passionate about, so I'm not going to push my view on anyone.
 
Jayesh Shere
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi James and Shane,
My question pertaining to usage of Agile technologies with teams of relatively less experienced developers.
Do you think pairing can work effectively when there is a gap in the skill levels of the various developers in a team?
Does the reduction in the amount of documentation hamper the learning (or handover) of new team members?
I'll be thankful if you could share your thoughts on these questions.

Jayesh
 
Allan Felipe Santos
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, we have a team of 30 programmers here, we are using netbeans (6.0 beta2, very good IDE, I think sun is ready to fight Eclipse now in JEE) and scrum to develop the software, little meetings every morning to define the tasks and find the problems, every month we need to delivery something running to our client. The project is a JEE framework with Adobe Flex interface (FDS Flex data services).
Did you think SCRUM is a good strategy?
[ October 30, 2007: Message edited by: Allan Felipe Santos ]
 
Shane Warden
author
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jayesh Shere:
My question pertaining to usage of Agile technologies with teams of relatively less experienced developers.
Do you think pairing can work effectively when there is a gap in the skill levels of the various developers in a team?
Does the reduction in the amount of documentation hamper the learning (or handover) of new team members?
I'll be thankful if you could share your thoughts on these questions.


Hi Jayesh,

Pairing is the most effective way I know to transfer knowledge, both of the system under development and in software development in general. For the junior developer, it's a chance to work with a mentor. For the experienced developer, it's a chance to explain the system by walking through it, which often provides the opportunity to check some assumptions by having to explain things.

I can't tell how how many problems I've seen solved just by talking through them with other people, let alone reviewing code together. Pair debugging is highly effective; pair programming more so.

Your point about reduced documentation and handoff is a good one. For that reason, we recommend a rolling handoff, where you bring the new maintainers into the team gradually and let them pair with the existing maintainers. As well, we suggest a specific practice of documentation for the sake of handoff and ongoing maintenance.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic