Difference between revisions of "IS480 Team wiki: 2012T1 Evynty Project Management"
Line 410: | Line 410: | ||
|- | |- | ||
| Sprint 3, Week 1, Sunday || [[Media:Evynty Progress (Sprint 3, Week 1, Sunday).docx|Download]] | | Sprint 3, Week 1, Sunday || [[Media:Evynty Progress (Sprint 3, Week 1, Sunday).docx|Download]] | ||
+ | |- | ||
+ | | Sprint 3, Week 2, Wednesday || [[Media:Evynty Progress (Sprint 3, Week 2, Wednesday).docx|Download]] | ||
+ | |- | ||
+ | | Sprint 3, Week 2, Sunday || [[Media:Evynty Progress (Sprint 3, Week 2, Sunday).docx|Download]] | ||
+ | |- | ||
+ | | Sprint 3, Week 3, Wednesday || [[Media:Evynty Progress (Sprint 3, Week 3, Wednesday).docx|Download]] | ||
|} | |} |
Revision as of 16:41, 26 October 2012
Home | Team | Project Overview | Project Management | Usability Studies | Documentation | Resource & References |
Timeline
Below describes a high level project schedule of Evynty. Individual features that will be developed in each Sprint will only be decided and broken down during each Sprint's Planning. The number of features being developed is determined by factors such as:
Sprint Features Development & Breakdown
The following table describes in detail what feature of Evynty is planned to be completed in each Sprint, and what is actually completed by the end of the Sprints.
List of features that will be developed in each Srpint will only be updated after Sprint Planning, which will occur at the start of each Sprint. Note the complexity of feature development affects the total number of features being developed in each Sprint.
Sprint | Features planned to be worked on | Features that were worked on | Work Assignment Breakdown |
---|---|---|---|
0 | Not Available | ||
1 | View | ||
2 | View | ||
3 | Stay tuned |
Performance Management
Purpose | Tool | Description |
---|---|---|
Feature Tracking |
Feature Backlog: | |
Feature Selection |
Product Feature Scoring Metric: | |
Sprint Schedule |
Sprint Backlog: | |
Sprint Performance |
Sprint Velocity Chart: | |
Sprint Performance |
Daily Scrum: | |
Sprint Performance |
Click here to view sample of weekly update |
Bi-Weekly Evynty Progress: |
Bugs Tracking |
Bug Metrics: | |
Project Performance |
Project Velocity Chart: | |
Project Success |
Project Success Calculator: |
Risk Management
May be encountered:
Scope Creep (High)
The team is developing the features of Evynty for the first time. The complexity and exact requirements of each feature/page, although is discussed during Sprint Planning, is easily subject to change during each Sprint during development. There is a medium risk that a change in complexity will cause the estimated time to complete a feature to be extended/shortened. This may affect the completion of project scope within in Sprint. The mitigation for this would be to reassess the scope of the Sprint when such incidents happen, developing the most critical ones needed by the end of each respective Sprint, with design taking the backstage.
Phone Vendor (Medium)
We would need to source for a phone vendor to perform several operations. We would need to send verification codes when users verify their phone number. When users book a venue and/or receive acceptance, they will receive a notification through a phone message. The risk of sourcing for a free vendor would be high as this is a service that is usually paid for. The team would look for low cost vendors that could provide us with the minimum service required, with the lowest cost possible. When this happens, we would be hoping to get a sponsor for the company.
Team (Low)
The team needs to work on being more cohesive as this is the first time working together. Xander, the Project Manager will step in to resolve and mitigate any possible conflict between members and let everyone understand the motive behind each person's argument as they ultimately contributes to the success of Evynty. Bonding sessions is also planned for greater team bonding, such as weekly badminton session, thus reducing the risk of bonding within the team.
Complexity of Framework (High)
The team aims to embark on a framework for front end development (backbone or bootstrap) to increase the technical complexity of the project. However, it takes quite some time to learn the framework and implement it. The team has tried to implement backbone in Sprint 1, but due to the complexity and time needed, the risk were too high as we need to deliver a prototype by midterm. Thus the attempt to increase complexity brings about high risk. Team would attempt to pick up framework as much as possible in Sprint 3 and 4. With the time given to learn the framework, the risk would possibly be reduced to medium. However, if the team feels that it is too difficult to implement a framework for the project, it might be dropped depending on the situation.
Realized:
Technical and Learning Risks (High)
The risk exposure is medium high as the team plans to embark on the project using Python with Django frameworks, where most developers are not familiar with the programming language and thus poses a steep learning curve in the development works.
However, the benefits that can be reaped from Django caused the team to stick with the language although being new. With the countless online tutorials available on the internet together with the determination of the team members, we try to reduces the risks incurred.
Member being away (Medium)
There is a low risk that a member might be away during the project. This might cause massive delays in the project, especially when it happens at the back end. To mitigate this, the team would attempt to cover the responsibilities of the away member. Tasks will also be assigned to the member with deadlines attached and close monitor by the project manager.
Schedule (Low)
The risk exposure is medium as working in a six member team creates huge differences in identifying time slots for meeting. Thus we have chosen to work fairly individually with each member having the responsibility to meet another if a task needs to be completed together. We have also put in place Wednesday and Sunday to be check in days where everyone updates each other through Daily Scrum and the Sprint backlog to understand the progress. Meeting will only be held when the need arises. Therefore, as these measures in place, schedule risk would be reduced to low.
Project Management Risks (Low)
The risk exposure is high in comparison to SE, the PM role for FYP requires much more dedication and planning; for changes especially. There is a need to manage the expectation of the team’s supervisor and as sponsors are not required in a self-proposed FYP, the expectations of an external party has been reduced and as such, changes to the project would perhaps be minimised, reducing the risk to medium.
Complexity & Learning Tools
As a startup, our project aims to leverage on all open source softwares in order to avoid sunk cost as well as to provide an opportunity to increase our competencies with open source technologies.
The project will be developed using Python on Django framework which is not familiar by the team. However, using Python on Django will enable us to ride on the functionality of the framework to develop a custom application suitable for our needs. Albeit a steep learning curve, learning Python on Django gives us more exposure to the many programming, and it provides additional functionality not available with other languages.
Using the framework in tandem with our chosen database system, PostgreSQL, may pose as an obstacle as we are new to this powerful, open-source database. Although there exists documentation and tutorials to integrate PostgreSQL with Django, difficulty still lies in ensuring all the configurations of the different apps to get the best out of Django.
Using Git for subversioning may be another obstacle for us as we only have experience with Tortoise SVN and we have not configured it for an actual project use. The use of Git as SVN is of paramount importance as is helps to keep track of changes to the project files, and also allowing us to retrieve previous file versions if needed.
Ubuntu 11.04 will be used as the server for our web application as it is free and robust. The likely difficulty would be the initial stage of setting up the server and getting used to Linux operating system.
Despite the learning curves to grasp all the different technologies, we believe our technical competencies will be greatly improved by the end of this project.
Project Highlights
The following table highlights the special events that happened during the phase of the project.
SN | Incident | Action Taken |
---|---|---|
1 | One of our group members, Xueting was overseas during Sprint 1. This would potentially cause her to deliver her tasks with a delay, posing a danger to the team's progress | Allocated her work tagged with deadlines through email with constant communication through email and whatsapp group. Once she came back, she was new to SCRUM compared to the rest of the team. Dependencies and bottlenecks are critical events that could affect the progress of the team. Project Manager met up with her to run her through the process of work that is being implemented, to prevent her from causing any bottleneck and to have her contribute in the best way possible |
2 | There was a communication gap between front end and back end. This was not suppose to happen if Daily Scrum was done everyday. However, because of school work, Daily Scrum was held every Wednesday and Sunday in Evynty, calling it the "Check-in-days". As back-end and front-end development are done separately, there may be time when work is being done by the back-end would affect front-end development or processes, vice-versa. | A meeting was held and it was decided that changes to development that might affect the other party would be documented in Evynty Dropbox. Thus whenever an error is encountered, team members just have to visit the dropbox to identify what were the changes and make the necessary adjustments. This would allow development to be smoother and not run into stoppages whenever something goes wrong. |
3 | Front end team faces a difficulty when designing and developing the individual pages in Evynty. The flow of user events is missing to allow the front end team to develop the pages with a next step in mind. | The front end team sat down to identify what is actually missing that could prevent this from happening. And we decided that a "storyboard" should be created to prevent future instances from happening. This storyboard will document down for each page, what are the features and next steps that users can access, and when they access another feature, how will the user experience it. Example: pop-ups, new page, color change, etc. |
4 | Team faces problem with postgresql and initial setup constantly as they are still fairly new to git, python and django environments. This causes some problems, especially for the front end team, as there is a constant need to push to the server to make sure things are able to integrate properly. | Nikunj, one of our team members who has experience with the environment was asked to give a "setup 101" to prevent similar things from happening in the future. |
5 | There was slow progression of GUI Designs to allow the front end developers to code out the pages. This slowed down the progress. | The front end team sat down and designed a workflow where things can be more efficient. Xueting will now create the wireframes and pass them to the front end team to code out the frames. While front end is doing that, Xueting then builds on her wireframes and work on the exact GUI specifications. After which, they will be passed to the front end to implement and hopefully create good webpages. |
6 | There was a severe overlooked by the project manager and the team, that user testing needed to be done for the mid term. The initial plan was to do user testing only after mid term, with the consent and approval from our supervisor. However, after revisiting the requirements stated on the IS480 website, the project manager realized the mistake. Thus the scope for Sprint 2 had to be changed. | The team got together to reassess the scope of Sprint 2, with the need to complete by Wednesday 26 September 2012. This forces the team to re-prioritize tasks to focus on completion and delivery, features such as design of pages and schedule management were affected. |
7 | One of our team member's grandparent passed away during User Testing and Fixing Period, causing her to need take some time off the project. | The team member is asked to take time off, and given some tasks to try to do in the meantime. As one member is away during this critical period, the rest of the team takes on most of the responsibilities handled by the team member which he/she recover from his/her loss. |
Meeting Minutes
Evynty Progress Weekly Updates
Project Phase | Weekly Update |
---|---|
Sprint 1, Week 1, Wednesday | Download |
Sprint 1, Week 1, Sunday | Download |
Sprint 1, Week 2, Wednesday | Download |
Sprint 1, Week 2, Sunday | Download |
Sprint 2, Week 1, Wednesday | Download |
Sprint 2, Week 1, Sunday | Download |
Sprint 2, Week 2, Wednesday | Download |
Sprint 2, Week 2, Sunday | Download |
Sprint 2, Week 3, Saturday | Download |
Sprint 3, Week 1, Wednesday | Download |
Sprint 3, Week 1, Sunday | Download |
Sprint 3, Week 2, Wednesday | Download |
Sprint 3, Week 2, Sunday | Download |
Sprint 3, Week 3, Wednesday | Download |