Whitepaper On Agile Implementation Outline
0 likes311 views
This whitepaper discusses implementing an Agile methodology to address challenges in software development lifecycles (SDLC). It outlines problems like vague requirements, lack of documentation, and inability to track progress. The goals are to keep team morale high during deadlines, ensure full understanding of what is being built, communicate requirement changes, and deliver on time with quality. The challenge case study describes forming a small "commando" team, setting up environments, dealing with requirements issues without a business analyst, delivering prototypes through iterations, and a project manager entering to help manage requirements.
Whitepaper On Agile Implementation Outline
- 1. Whitepaper on Agile implementation Wednesday, March 03, 2010 10:11 PM TOC Introduction Introduction The story (problem domain) Over the years I'd been hearing about different methodologies to manage the The challenge SDLC. I had felt a lot of pain along with my fellow devs as we were on pur path of The goals developing and delivering software. I would see mistakes repeated again and again. Many times I would change jobs hoping to find a place with more The problem domain successful SDLC practices, greater control on quality and more experienced As a company/team we would have major issues with the following: management. 1. associating what we were building to what the customer wanted Time and time again I would be disappointed, only to find the same mistakes I 2. Keeping track of our progress had run away from in one place being repeated in the other. Only the names 3. Tracking the impact of changes in requirement on the rest of the would change, but the story remained the same. development cycle 4. Keeping our documentation up to date Vague requirements, would spark a project with a lot of assumptions, we would 5. More importantly communicating changes/ designs/decisions/ assume our way through the proposal phase, making the proposal itself guidelines to the team extremely vague. If by chance we would succeed in securing the deal, the 6. Measuring h0ow well the team was doing in terms of progress and requirements would be gathered in an extreme rush and the design document quality would be a 2 week effort max, where we would spend the time creating pretty diagrams. The development phase is where we would start to have the real pain since this i…... The challenge 1. Keeping the team morale during tough deadlines 2. Making sure the team fully understood what was being built and how the components would fit together 3. Convincing the team of the necessity of documenting change and making sure they have the discipline to do that 4. Communicating the effect of changing requirements on the delivery schedule to the customer while negotiating more favorable payment terms 5. Ensuring delivery on time with even the minimal acceptable quality The Story I was a new hire in the company, with high hopes that I would be Lessons learned capable of changing the way we delivered projects. I was expected to create a team, run a process and deliver a project all in one. I really enjoyed the challenge and the idea that I would e allowed to create my own team, the way I wanted to. We started hiring, I made sure we had really high standards before we accepted any resource. I was a firm believer in the "commando theory" where a small team of really smart people would be better than a large army of average skilled devs. Team creation Environment setup (night;ly builds, source control) User stories-- the requirements issue (no BA) Iteration 0-- delivering the prototype to production (minor refactoring -- arrow anti pattern ) Iteration 1-- refactoring the prototype/ adding features/ fixing bugs Iteration 2-- the P.M. enters the project Managing requirements, canceling the build, technology decisions Presentations Page 1