HeaderSIS.jpg

2012T2 Team Chm: Project Management

From IS480
Jump to navigation Jump to search


 Chmlogo.jpg "because there is no I in the team"

Home   Team & Stakeholders   Project Definition   Project Design   Project Management   Progress Summary   Learning Outcomes   Photos


MID-TERM WIKI            FINAL WIKI

Schedule

Version 3 (Current as at 17 APR 2013):
Schedule9.png

Versions

Project Schedule earlier versions:


Schedule Metric

The schedule will be complemented with the burn-down chart of each sprint, calculating the schedule ratio and adhering to the response actions of each ratio value.

FORMULA:

Schedule Ratio = Remaining Time / Remaining Effort
Remaining Time = Number of hours that developer would spend * Days left in SPRINT * No. of Personnel Available

Schedule Ratio Description Response
> 1.2 Ahead of Schedule Redefine Sprint backlogs
0.8 - 1.2 Within healthy schedule range No actions required if ratio is about 1. Monitor tasks closely if ratio is below 1 and prepare to re-allocate the following tasks for the following sprint.
< 0.8 Team is behind schedule Project Manager identifies the root cause and impact of the delay. Communicate with the team and client(if necessary). Set up more working meetings and discuss with lead developer for more pair-programming sessions.

Documentation

Schedule Ratio for each sprint

Sprint 13

Sprint 12

Sprint 11

Sprint 10

Sprint 9

Sprint 8

Sprint 7


Sprint 6

Sprint 5

Sprint 4

Sprint 3

Sprint 2

Sprint 1

Product Backlog


Bug Metric

Our Objective is to ensure the quality of our project through minimising the number of bugs present.
A bug is defined as an error/s in a line of code, resulting in an anomaly in the functioning of the application.
Refer to the Bug Metric Documentation.

Formula:

Bug Ratio = (2 X No. of low severity bugs) + (4 X No. of medium severity bugs) + (10 X No. of high severity bugs)

Severity Score Severity Level Description
2 LOW Errors with page aesthetics. Feature/story can still work, but at a sub optimum level
4 MEDIUM Errors that prevent an entire feature/story from working
10 HIGH Errors that prevent more than 1 feature/story from working
Bug Ratio Response
less than 6 Developers resolve issues within the Sprint on their own accord
7 - 9 If bug is discovered in a feature that is not a core feature, Project Manager to schedule debugging during buffer.
10 or more Developers attempt to resolve bug immediately. Project Manager to relieves member of his current task and set him in charge to resolve bug


Regressive Testing

Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them

The intent of regression testing is to ensure that a change such as those mentioned above has not introduced new faults. One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.

Team Chm uses regressive testing to ensure the quality of our product - Mobisupermarket, and each testing is done after each sprint as documented below;

Documentation

Regressive Testing for each sprint

Sprint 12

Sprint 11

Sprint 10

Sprint 9

Sprint 8

Sprint 7


Sprint 6

Sprint 5

Sprint 4

Sprint 3

Sprint 2

Sprint 1



Risks Analysis

S/N
Risk
Impact
Level of Impact (out of 10)
Mitigation Strategy
Project Management
1. The estimation of story points by the team for each storyboard is not accurate, resulting in an inaccurate gauge of the planned sprint backlogs Schedule will be severely affected. Storyboards may have to be pushed back to the next iteration
7
Project Manager to re-plan the resource and schedule allocation
2. The developed product is not able to be installed like a plugin, as per requested by the client. Too much time spent on designing codes appropriately
5
Lead developer to ensure that all committed codes adhere to stated guidelines & PM to ensure that schedule is kept to closely.
Stakeholder Management
1. Due to personal reasons, client Prof Shim may have to make short trips back to Korea Prof Shim may not be contactable at times when we have urgent matters
7
Set up regular meeting time slot with the client

Email the client when we are not able to talk to her personally

Technical
1. Members unfamiliar to technologies used like AJAX, JavaScript, D3 Project would take longer to complete due to learning curve
4
Start learning technologies now and practice on dummy sites
2. Business Rules such as creating of campiagns and designing of [hooks] do not adhere to marketing practices as we are unfamiliar with it Misunderstanding business rules resulting in an inaccurate result
4
Meet up regularly with marketing professors and users testing
3. Users may not know how to use the software the first time they use the application Users may have a difficult time adapting to the new software
5
Have a soft copy of a user manual or incorporate a guide in the software to guide the users
4. The steep learning curve for magento may prevent us from progressing according to our schedule Project would be difficult to integrate and code and thus take a longer time to complete
5
Project Manager to schedule more time for Magento workshops and peer learning
5. Go Daddy Server Fails Project cannot be deployed and thus take a longer time to complete
8
Project Manager to obtain working copy from repository and redeploy
6. Project Repository unavailable due to technical faults Project cannot continue
5
Project team members to obtain last known working copy from teammates
Team Management
1. Lack of manpower because it is expected that Leonard is required to go over a competition (unable to predict as the dates are not confirmed yet) Productivity of the team may decrease
6
Ensure that everyone stays healthy by planning sufficient rest time for the team
2. As this is the first time the team members are working together, different working styles of the team members may clash with each other. Productivity of the team may be severely affected.
6
Set common ground rules to ensure transparency amongst the team.

Have bonding time to understand more about each team member and strengthen the bonds within the team.

Deliverables

A Magento-based online e-commerce store, coupled with social media platforms (Facebook) that is developed along with an Business Intelligence (BI) tools application. This application allows marketing professionals and students to analyze the effectiveness of marketing strategies and campaigns being launched in the Magento e-commerce online store.


LARC would be able to use this application mainly as an education / learning tool for Singapore Management University (SMU) marketing majors students.

The project deliverables would be two-fold: a plug-in for the Magento eCommerce store, and the other is a Business Intelligence (BI) tool that will be developed on top of the existing Magento Admin

Magento.PNG

For more details about the project schedule, please click [here] More details coming your way...


Project Management Framework


SCRUM is an iterative and flexible software development method for the management of software projects and product or application development.. The process is explained by the following flow chart and SCRUM terminology list. For a more visual description click here for a youtube video, otherwise the following describes the process;


1. Roles & Responsibilities

SCRUM process flow of events
  • The Product Owner (Prof Kyong Jin Shim) is responsible for the business interest and value of the project.
  • The SCRUM Master (Project Manager) takes charge of managing the product backlog and the team’s productivity.
  • The team is a self-managed entity that ensures that the work gets completed.


2. Product Backlog

  • The process is first triggered with a wish list of requirements drawn up by the product owner (Client).


3. Sprint Planning / Sprint Backlog

  • Next, Team Chm pulls out a list of to-do items from the [product backlog] and places it in the sprint backlog.
  • Each story of a sprint has an in charge, and he shall see through the development and testing of the story.
  • He needs to update the status of the story in the product backlog.


4. Sprint

  • A sprint is a duration that the team takes to complete the tasks selected in the sprint backlog.
  • Team Chm sprint duration is can vary from 4 to 27 days.
  • Once the Sprint Backlog is up, the team scrambles to work on the sprint.


5. Weekly meetings

  • Instead of having daily meetings as depicted in the original SCRUM process, Team Chm has a weekly SCRUM meeting instead to customise to its current needs.


The SCRUM process then repeats itself until the product backlog is cleared.

Further your knowledge of SCRUM via Scrum Alliance, where Team Chm has referenced the contents of this section from.