IS480 Team wiki: 2015T1 4Sight Software Development Methodologies
|HOME||ABOUT US||PROJECT OVERVIEW||PROJECT MANAGEMENT||DOCUMENTATION|
|Project Schedule||Software Development Methodologies||Schedule Metrics||Task Metrics||Bug Metrics||Risk Management||Change Management|
Comparsion Between Waterfall Approach & Agile Methodology
|Time between requirement gathering and implementation||Long||Short|
|Collaboration between customer and developers||Low||High|
|Amount of time taken to identify problem/ issue||Long||Short|
|Project Schedule Risk||High||Low|
|Ability to respond quickly to change in requirements||Low||High|
Based on the above table of comparison between agile and waterfall, our team evaluated and chose to use the agile methodology. As requirements are constantly changing, managing risk is highly important, small incremental releases of the development work allow for greater visibility to the product owner and team. It will help the team to identify issues early and make it easier to respond to change.
The active collaboration approach needed also provide excellent visibility for key stakeholders in both the project progress and product itself. This helps to ensure that expectations are effectively managed.
Comparison Between Scrum & Kanban
|3 roles prescribed (Product Owner, Scrum Master, Team)||No role prescribed|
|Prioritization of user stories in product backlog||Prioritization is optional|
|Estimation of work hours prescribed||No estimation of work hours prescribed|
|User stories must be broken down into tasks for completion within a sprint||No specific item size is prescribed|
|burndown chart to track work progress||no visual representation is prescribed|
|Daily scrum meeting to keep team updated of individual progress||No meeting|
|Iteration by sprints||Continuous flow|
|Obstacles met are dealt with immediately||Obstacles met are avoided|
In deciding between these two popular agile methodologies, our team has decided to adopt scum as our software development methodology.
Scum provides a holistic and in-depth overview of the progress of our project. It promotes communication between our project team members and sponsor, enabling us to effectively manage our stakeholders’ expectations. It also promotes transparency where the client and team know what has to be delivered in each sprint based on the prioritization of user stories in the product backlog.
In addition, the burndown chart available will greatly help the team monitors project progress and measures sprint velocity which are both useful in helping the team identify if the project is on track or behind schedule, so that the team can take necessary adjustments needed to bring the project back on track.
Product Backlog & Task Breakdown
|Sprint||Product Backlog & Task Breakdown Document|