HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2012T1 Evynty Project Management"

From IS480
Jump to navigation Jump to search
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

Logo 2 - confirmed.png


  Home   Team   Project Overview   Project Management   Usability Studies   Documentation   Resource & References


 

Timeline

 

Sprint Features Dev

 

Performance Management

 

Risk Management

 

Complexity & Learning Tools

 

Project Highlights

 

Meeting Minutes

 

Weekly Updates


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:

  • Past Sprint Progress
  • Team's Confidence
  • Estimation in time taken
  • 45 hours per owner per Sprint

    Evynty Project Timeline as of 3 October 2012



    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
  • Login
  • Register
  • Login
  • Logout
  • Dashboard Settings
  • Simple search
  • Homepage
  • View Venue Profile
  • Not Available
    1
  • Refine Register
  • Refine Login / Logout
  • Forgot Username / Password
  • Past Bookings
  • Add Venue
  • Refined Dashboard
  • Refined Settings
  • Verification of email
  • Verification of phone
  • Notification
  • Static Pages (About, Team, Support, Contact Us)
  • User Profile
  • Register
  • Login/Logout
  • Forgot Username / Password
  • Add Venue
  • Dashboard
  • Settings
  • Verification of email
  • Notification
  • Static Pages (About, Team)
  • View
    2
  • Schedule Management
  • Venue Profile
  • Edit Venue Profile
  • Account Settings Improvement
  • Manage Venue
  • Manage Packages
  • Search Results
  • Review
  • User Profile
  • Schedule Management
  • Venue Profile
  • Edit Venue Profile
  • Account Settings Improvement
  • Manage Venue
  • Manage Packages
  • Search Results
  • View
    3
  • Bookings
  • Manage Booking
  • Reviews
  • Redesign of Login/Register
  • Redesign of Homepage
  • Redesign of Venue Profile
  • Redesign of Manage Packages
  • UI Fixes
  • Manage Booking
  • Redesign of Homepage
  • Redesign of Venue Profile
  • Redesign of Manage Packages
  • Stay tuned

    Performance Management


    Purpose Tool Description
    Feature Tracking
    Feature Backlog.png

    Feature Backlog:
    Allows team to track all features suggested to be implemented in evynty. Enable visibility on what features are in the "Idea" box, which are being developed and which has been developed. Team members are to add ideas as cards into the "Ideas" box anytime. Features that are being developed will be in the "In Development" Board, and those completed will be in the "Developed" Board.

    Feature Selection
    Product Feature Scoring.png

    Product Feature Scoring Metric:
    Helps team select features to be developed in upcoming sprint by running against certain criteria. Top ranked features by score will be developed and the rest pushed to the following sprints. Number of features selected to be developed also depends on the number of hours estimated needed.

    Sprint Schedule
    Sprint Backlog.png

    Sprint Backlog:
    Established to assign tasks to individual owners and also determine who are involved in each tasks. Backlog documents down the number of hours remaining for each task and is updated by respective owners individually every Wednesday and Sunday of each week. When individual tasks' hours remaining are collated and compared over time, team is able to see speed and progress within the sprint. Data will be fed into the Sprint Velocity Chart for analysis.

    Sprint Performance
    Sprint Velocity Chart.png

    Sprint Velocity Chart:
    Visualize speed and progress of sprint. Ideal line is shown to enable team to aim and hit ideal progress speed. Color rating allows team to visualize progress and completion status, whether there would be a risk or need for improvement.

    Sprint Performance
    Evynty Daily Scrum.png

    Daily Scrum:
    To be more efficient and allowing individual owners to develop in their own time, and not having the need for the team to meet together for development. There needs to be a way to let everyone know of happenings every week, and the work progress of each member and whether it would affect others. Done every Wednesday and Sunday by each member of the team to allow everyone to be on the same page and understand what each other is doing.

  • What have you done the past 3 days?
  • What will you be doing the next 3 days?
  • Is anything stopping you from progressing?
  • Sprint Performance
    Evynty Weekly Update Sample.png

    Click here to view sample of weekly update

    Bi-Weekly Evynty Progress:
    Share current progress and raise alerts if theres any to the team. Allow team to understand how individual tasks are building up to the progress of the project. Integrates inputs from Daily Scrum and Sprint Backlog to provide feedback.

    Bugs Tracking
    Evynty Bug Metrics.png

    Bug Metrics:
    To determine whether bugs will be solved during schedule development time or before start of next Sprint. Bug metrics will be logged when bugs are found during Internal and User Testing at the end of each sprint. It is not done during development as evynty is adopting SCRUM, which ensures codes are bug free and deployable once tasks are completed.

    Project Performance
    Project Velocity Chart.png

    Project Velocity Chart:
    Visualize overall project progress and determine health status of project. Allows team to see how much is done per sprint, whether there are improvements or need for improvement.

    Project Success
    Project Success Calculator.png

    Project Success Calculator:
    Puts a number to whether project would be a success or not (negative: unsuccessful; positive: successful). Takes into consideration Stakeholders Satisfaction and Team's ability to stay on course for project completion and overall team's satisfaction.

    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


    Team Meetings Supervisor Meetings
    Team Meeting Minutes 1 Supervisor Meeting Minutes 1
    Team Meeting Minutes 2 Supervisor Meeting Minutes 2
    Team Meeting Minutes 3 Supervisor Meeting Minutes 3
    Team Meeting Minutes 4 Supervisor Meeting Minutes 4
    Team Meeting Minutes 5 Supervisor Meeting Minutes 5
    Team Meeting Minutes 6 Supervisor Meeting Minutes 6
    Team Meeting Minutes 7
    Team Meeting Minutes 8
    Team Meeting Minutes 9
    Team Meeting Minutes 10
    Team Meeting Minutes 11
    Team Meeting Minutes 12
    Team Meeting Minutes 13
    Team Meeting Minutes 14
    Team Meeting Minutes 15
    Team Meeting Minutes 16
    Team Meeting Minutes 17
    Team Meeting Minutes 18
    Team Meeting Minutes 19
    Team Meeting Minutes 20

    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