Process Presentation 27 th May 2010 Team BASH Sher Jun Tan, Rosh Sam Abraham, Sascha Morris, Waqas Khalid Lone, Rafael Zuniga,

Project phases Initial analysis and vision statement User stories, analysis and modeling Spiking Base Iteration Pair Programming Refactoring

Key Learnings User Stories – Different approach to requirements gathering Prototyping based on user stories Spiking – Bridging the knowledge gap Automated testing and build Continuous integration Tools and technologies – JSP, JavaBeans, JUnit, PMD, Emma, Ant, SVN, Derby

Practices Used Project reporting and getting customer feedback Pair programming Refactoring Group communication via Google Groups

What worked Google Code Weekly meetings Wikis, Spikes and Knowledgebase Pair programming Refactoring

What we could’ve done better Development environment setup (i.e. Eclipse)  Root cause: Team members new to IDE Code integration and automated test/build  Root cause: Disciplined practice / Work culture Pair programming  Root cause: Time was more focused on discussions rather than actual driver/navigator interaction Communication  Root cause: No formal task allocation, thus no issue owners

Recommended Agile Process Model Scrum Product Backlog Sprint Planning Meeting Sprint Backlog Daily Scrum Scrum sprint Executable increment Product Owner Scrum master Scrum team

Why Scrum? Encourages client involvement  Deliverables are based on user stories provided by client  Product delivered incrementally based on clients priorities Need for project team leader – Scrum master Clearly identified deliverables  Sprint backlog frozen when Scrum sprint commences Progress can be tracked during project lifecycle and each iteration  Daily/Weekly/Iteration Scrum Adaptive & Predictive  Early identification of forthcoming problems

Recommended Practices/Techniques Paper prototyping TDD Refactoring Continuous integration Pair programming Automated builds and tests Retrospective and plan corrective actions Planning poker

Any Questions?