Agile Software Reuse - Key Ingredients
October 5, 2009 | Author: PM Hut | Filed under: Agile Project Management
Agile Software Reuse - Key Ingredients
By Vijay Narayanan
Pursuing systematic software reuse is fraught with risks – hence the motivation to take a pragmatic, agile approach. What exactly does that entail? This post will introduce four key ingredients when pursuing agile software reuse:
1. Reuse Roadmap
You can keep building one-off components and services and hope they all fit together nicely. But, that would be wishing for something that is extremely unlikely. Hence the need for a roadmap. The reuse roadmap is your guiding compass that provides business vision/objectives, a set of phases that transform the way you build software, and planned high-level milestones. Why is this roadmap important? Because you need to make sure that your reuse objectives are aligned with tangible business goals. Reuse pursued as a technology-focused objective will yield only minimal benefits. This shouldn’t be vaporware or slideware but based on ground realities in your organization. My recommendation: start small and keep things simple by pursuing reuse within a pilot project or two, get traction, and build on it. Start firmwide and your chances of success will dwindle very rapidly.
2. Continuous Alignment
You need to ensure that every iteration is aligned with your reuse roadmap. Your iteration has tangible features that are being implemented. They become much more effective if they are aligned with your overall vision. This isn’t meant to make every feature reusable or every iteration produce reusable assets. Just the opposite. Continuous alignment accepts that building reusable software is hard, takes time, and is iterative. You can fight that and stand firm on producing perfect assets. That will not only add needless complexity but increase schedule risk for your iterations. Instead the idea here is to align assets towards reuse. This could be refactoring existing code, wrapping legacy service capabilities, or building a sub-set of a new asset’s features. Make your best efforts to align project backlog and refactorings with reuse objectives. This won’t always be possible and that is okay. Agile practices advocate exploration and alignment rather than prediction and certainty. Continuous alignment simply extends these ideas towards systematic reuse.
3. Iterative Design
Agile practices espouse simple design and avoiding big design upfront (BDUF). Iterative design is to build a reusable asset in successive iterations. Too many systematic reuse initiatives have failed in pursuit of the perfectly reusable software component or service. Business requirements, motivations, and goals change continuously and trying to implement the perfect asset only makes design risky. Iterative design also is about building for your immediate requirement and nothing more. Have a very cool idea to extend an asset? Add it to your project lists of tasks or refactorings and align them with iterations as appropriate. Just design what you must. There are times when you know future requirements and you can build towards that but those are still predictions. When in doubt, go back to the basics: understand your domain, clarify existing domain models/relationships, refactor the design, and build towards reuse. Never hesitate to delay commitment.
4. Teamwork
Systematic reuse isn’t about technology or software techniques alone. It is a rich-interaction activity that involves every member of your team. Teamwork is key and foundational in achieving reuse objectives. Your daily standup meetings, iteration retrospectives, and code reviews are all opportunities for your team to examine work in light of your reuse roadmap. Collective code ownership, continuous refactoring, and integration are practices that require your team’s contribution. Simply put – without constructive dialogue, reuse-friendly conversations, and passion, reuse will remain a dream. Your team is practicing iterative design, pursuing continuous alignment when planning iterations, and ensuring your codebase is in the accordance with the systematic reuse roadmap. No teamwork, no reuse!
Vijay Narayanan is a software professional building reusable data services and business process automation components. He has worked on several software projects ranging from single user systems to large, distributed, multi-user platforms with several services. He’s a speaker on software reuse, agile development, and Service Oriented Architecture (SOA), as well as a contributing author on Agile. Vijay runs a professional blog: agile and software reuse at http://artofsoftwarereuse.com/.
Related Articles
No comments yet.
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.










