Project plan - stacc-dasso/woocommerce-extension GitHub Wiki
Roles in project
- Lauri Leiten
- Team lead
- Back end
- Hannes Saariste
- Front end
- Help with back end
- Stiivo Siider
- Testing
- Help with back end
- Martin Jürgel
- Documentation
- Help with back end, testing
Communication means
- At least a biweekly meeting with the customer, more often if necessary.
- Slack
- Discord
Work process
How and using what materials the customer is going to understand what you are going to build
We will be discussing the project plan with the customer, they’ll also have access to our repository and during the biweekly meetings we will showcase and discuss what have we built and what are we working on.
How do you determine that the customer is accepting your solution proposal
Through feedback from the customer, from either online or in-person meetings. If the customer supports our proposal, we consider it as accepted.
How you are internally going to build the accepted solution (who assigns the tasks, who is going to implement it, will the tests be written, will code be reviewed, who is going to verify, who is doing the validation, etc)
Tasks will be assigned by the team leader. Back end tasks will be mainly for Lauri, Stiivo and Martin. Hannes will look after the front end tasks, with Stiivo and Martin helping as needed. Progress will be documented and all challenges encountered along the way written down in the wiki as per the client's request.
Initial development of a feature will be done in a new local branch (feature branch). Unit tests for all new features will be written by the developer in charge of writing the feature. Once the developer wishes to merge their code into the dev branch, they will do a pull request. After this, the code will be reviewed by a team member and if approved, the code will be merged with the dev branch. At this point, the feature is considered "done" and ready to be demonstrated to the customer.
The dev branch will be merged with the master branch every time a milestone is reached - in our case, at the end of every iteration. Before merging, all team members must have looked at the code and given their approval.
When do you consider something ready to be published to the customer for review
As the customer will have access to our repository, they can review our work at any time. Other than that, everything that'll get merged to the dev branch will be ready for customer review.
How do you gather feedback from the customer and/or end users.
For the customer, we communicate online through Slack and Discord and have biweekly meetings where we show our work and ask for feedback.
What is the definition of DONE on a task
A task is done when it reaches the development branch and the customer has reviewed it.
Scope
Iteration 1
- Meetings with the client (Everyone, 4h each)
- Project vision (Stiivo, 2h)
- Functional requirements (Stiivo and Martin, 4h each)
- Use Cases (Martin, 1h)
- Non-functional requirements (Martin, 4h)
- Project plan (Everyone, 10h total)
- Work process (Hannes, 5h)
- Scope (Lauri, 5h)
- Collaboration Infrastructure - VCS (1h total)
- Setting up VCS (Lauri, 15 minutes)
- Basic Wordpress plugin structure (Lauri, 30 minutes)
- Informative README (Hannes, 15 minutes)
- Collaboration Infrastructure - Wiki (Stiivo, 1h)
- Collaboration Infrastructure - Issue Tracker (Lauri, 1h)
Iteration 2
- Meetings with the client (Everyone, 4h each)
- Continous Integration (Hannes, 5h)
- Detailed requirements (Stiivo, 8h)
- Front end (15h total)
- UI mockup (Hannes, 10h)
- Admin panel (Hannes, 5h)
- Back end (100h total)
- Wordpress plugin (Lauri, 15h)
- Admin panel (15h total)
- Extension settings (Stiivo, 10h)
- Extension information (Hannes, 5h)
- Events (40h total)
- Access and process add-to-cart events (Martin, 8h)
- Access and process product view events (Martin, 8h)
- Access and process purchase events (Martin, 8h)
- Access and process search events (Martin, 8h)
- API (30h total)
- Framework for connecting to the API (Lauri, 20h)
- Request API status from the API (Stiivo, 10h)
- Release notes for Iteration 2 (Hannes, 1h)
- Unit tests (Everyone, 5h each)
Iteration 3
- Meetings with the client (Everyone, 2h each)
- Front end (15h total)
- Recommendation widget (Hannes, 15h)
- Back end (135h total)
- Recommendation widget (50h total)
- Widget placement (Martin, 15h)
- Widget settings (Martin, 15h)
- Fetching recommendations from the API connection framework (Hannes, 15h)
- Logging errors, warnings and syncing informations (Hannes, 15h)
- API (70h total)
- Sending events to the API (Lauri, 20h)
- Syncing store's inventory (Stiivo, 15h)
- Sending logs through the API (Stiivo, 15h)
- Fetching recommended products for a user (Lauri, 20h)
- Recommendation widget (50h total)
- Comprehensive testing - (10h total)
- Unit tests (Everyone, 5h ea)
- Selenium tests (Stiivo, 5h)
- Documentation (15h total)
- Checking that everything is documented per standards (Martin, 15h)
- Release notes for Iteration 3 (Hannes, 1h)
Iteration 4
- Meetings with the client (Everyone, 2h each)
- Internal accceptance testing (Everyone, 15h each)
- General refactoring (Everyone, 2h each)
- Logging improvements (Everyone, 2h each)
- Automatic system to run tasks daily (Lauri and Hannes, 5h each)
- Better error handling (Lauri, 5h each)
- Comprehensive testing
- Unit tests (Everyone, 5h each)
- Selenium tests (Stiivo, 8h)
- Release notes for Iteration 4 (Hannes, 1h)