Hello all intelligent guys,
I get this newsletter on Agile… This edition was pretty interesting… thought of sharing it with all the intelligent people I know… ok not all the intelligent people I know... but all the intelligent people I can share it with...
It also has a little section on funding... which is always a big question with agile processes... check it out...
Kanbay Software (I) Ltd.., Cell Phone: +91-98600-59190
From: Dr. Dobb's Agile Newsletter [mailto:ddj@newsletters.sdmediagroup.com]
Sent: Tue 9/19/2006 2:24 AM
To: Nilotpal M. Das
Subject: Dr. Dobb's Agile Newsletter September 2006
Scott W. Ambler In This Issue:
The Implications of Agile Requirements ManagementAgile software development teams embrace change. An agile team will work down "a stack" of prioritized and estimated requirements which need to be implemented--Extreme Programmers will literally have a stack of user stories written on index cards, whereas Rational Unified Process (RUP) teams are a bit more sophisticated and will write use cases with a word processor. Regardless, the development team takes the highest priority requirements from the top of the stack which they believe they can implement within the current iteration. Iterations are typically one to four weeks in length. At the end of each iteration, including the early ones, you should produce working software which you can demo to people and better yet deploy into your pre-production testing environment. The decision to take an agile approach to requirements management ripples through your software process. Gone are the days of detailed schedules early in the project which you would onerously keep up to date throughout the project. Gone are the days of detailed estimating early in the lifecycle, only to go hat in hand throughout the project begging for additional funding. Gone are the days of creating a detailed design up front, getting it reviewed and accepted, only to discover that the technology changed while you were doing all this and/or the developers ignored the design anyway. Gone are the days of reporting "earned value" throughout the project, only to cancel the project when senior management discovered that the team didn't have a hope of actually delivering, which really implied that you had never actually earned any value at all. So how does an agile approach to requirements management affect the rest of the lifecycle? In several ways. First, you create a high-level plan early in the lifecycle and maybe perform detailed planning on a just-in-time (JIT) basis. Because you're taking an evolutionary approach to requirements elicitation you must now take an evolutionary approach to project planning as well. Second, you should take a staged approach to funding. We've known for decades that you need to give ranges early in the lifecycle because of the range of unknowns, and that's never going to change. When forced to give an "accurate" up front estimate a good project manager will pad it, but in doing so you're effectively lying both to yourself and to your stakeholders. A truly agile approach would be to provide funding a bit at a time, perhaps provide sufficient funding for a single quarter or even a single month. At the end of a funding period you would determine whether good value has been received for your IT investment, which should be the case if the team is producing working software on a regular basis and is working on requirements in priority order. This approach enables the business to both control the budget and to maximize their return on investment by funding the project teams which are most effective. Third, you should design your system in a JIT manner. You can't do design until you understand the requirement(s) that you're designing to, so an evolutionary approach to requirements implies you must also take an evolutionary approach to design. This doesn't mean that you have to shoot yourself in the foot. With an Agile Model Driven Development (AMDD) approach you still identify an architecture model which addresses the "big issues" early in the lifecycle, thereby addressing major risks, but the "little issues" are addressed on a JIT basis. Fourth, accept the fact that the delivery date will vary (this is pretty much the case with traditional projects as well). The stakeholders are in complete control of the delivery date, so if there is a hard date to meet then they must vary the scope and budget accordingly to meet that date. Fifth, measure true "earned value" through delivery of working software, not through delivery of documentation. I'm sure that you've seem project teams deliver lots of documentation, make their milestones, claim "earned value" throughout the effort, yet fail to deliver anyway. The so-called "earned value" wasn't, and should more accurately have been called "justified bureaucracy". The only accurate measure of progress on a software development project is the delivery of working software. Book Review: Agile Java DevelopmentAgile Java Development, by Anil Hemrajani, is one of those rare books which teach you skills that you will use throughout your career. Yes, it does cover the fundamentals of Spring, Hibernate, Ant, and a bunch of other stuff that you need to succeed today. But, more importantly, it goes beyond the technology to describe agile techniques, adopted from Extreme Programming (XP) and Agile Modeling (AM), which enable you to succeed at modern software development. These are the skills that you'll be using years from now, long after the really cool technologies have evolved and/or disappeared completely. Most Java developers have heard about XP and many have adopted some of its techniques such as test driven design (TDD), refactoring, and even pair programming. This is a good start, but it's not enough. In this book Hemrajani brings his years of experience to the table, describing what actually works in practice; this is different from other books which often share a vision of what the author thinks will work in theory, but as we all know theory and practice are often two completely different things. An interesting feature of this book is that it is one of the few where the author appears to describe what he actually does on real-world projects. For example, his diagrams are similar to what you develop yourself on actual projects, a refreshing change from the advice presented in many of the modeling books available today. More importantly, he describes how to move from those simple models to the often complex code that you write on a daily basis. This I think represents the greatest strength of this book: it presents real-world advice which reflects what top-notch developers actually do in practice. Hemrajani also shows how many of the common tasks that we perform, such as acceptance testing, unit testing, object/relational mapping, system integration, and refactoring fit into the software development picture. The book starts with the "5000 foot" process point of view, but dives down to ground level and describes how to use the tools in practice. Most books focus on one view but not the other; this one doesn't make that mistake. Agile Java Development with Spring, Hibernate, and Eclipse Hot LinksThe Agile Alliance homepage is the best starting point for anyone interested in learning more about agile software development. Agile requirements change management is described in detail at www.agilemodeling.com/essays/ changeManagement.htm The article "Examining the Big Requirements Up Front (BRUF) Approach" overviews and discusses evidence as to why comprehensive modeling up front puts your project at risk. For project teams creating use cases, you'll find that "Driving Iterative Development With Use Cases" by Kurt Bitner provides wonderful information for taking an evolutionary approach to development. I present a collection of agile project planning tips at http://www.ambysoft.com/ essays/agileProjectPlanning.html The principles of Agile Modeling v2 are described at www.agilemodeling.com/principles.htm. The practices of Agile Modeling v2 are described at www.agilemodeling.com/ practices.htm. Check out the Agile Modeling mailing list. ADVERTISING INFORMATION For more information on advertising in Dr. Dobb's Portal newsletters, contact our account managers: www.ddj.com/advertise Copyright © 2006, CMP Media LLC. | **ADVERTISEMENTS** .NET 3.0 2006 ROADSHOW - Coming to a City Near You This October!Brought to you by Dr. Dobb's, the .NET 3.0 2006 Roadshow is a two-day, multi-city event that will focus on the Microsoft .NET Framework 3.0. In-depth sessions taught by industry-leading experts. Register today at: www.net3roadshow.com Online Project Management Certificates from Boston U. Project Mgmt was recently cited as one of the hottest professional skills. Enhance your project management skills with Boston U'?s PMI-certified Project Mgmt Certificates in as little as 8 weeks, 100% online via The College Network. Skills apply in the IT industry Sign up today! Dr. Dobb's Newsletters Don't miss out on other essential Dr. Dobb's newsletters! Topics include Eclipse & Open Source, Java, Embedded Systems, Mobility, Security, Architecture & Design, and more. Go to ddj.com to view a complete list of free newsletters for software developers, architects and managers. Sign up today! FREE TUTORIAL Automatically Prevent, Test and Analyze your Java Applications. Learn how in this FREE Parasoft Tutorial. OVER 1200 DEVELOPERS RANK THE FEATURES OF THE TOP IDES Evans Data asked over 1200 developers worldwide to rate the features and capabilities of the top eleven IDEs. Find out how they ranked IDEs such as Visual Studio, Eclipse, and others. Download the free Developers' Choice IDE Scorecard today! Are C# and Java fast enough for Numerically Intensive Applications? Which is faster? Are there limitations? Find out... Join Visual Numerics for a Free Web Seminar: Performance of C#.NET Compared to Java for Numerically Intensive Applications Now available on-demand. Register Today! | |
