1 / 20

Implementation I - demo

Implementation I - demo. Schedule. * Project status -achieving the goals of the iteration -project metrics * Used work practices * Work results -presenting the iteration’s results -Demo * More on work practices (not part of this presentation). Project description.

medea
Download Presentation

Implementation I - demo

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementation I - demo

  2. Schedule * Project status -achieving the goals of the iteration -project metrics * Used work practices * Work results -presenting the iteration’s results -Demo * More on work practices (not part of this presentation)

  3. Project description • http://3.bp.blogspot.com/_0arosa8qIkc/SCkQ0fZOliI/AAAAAAAAAz0/i1Wt-UN8a5g/s400/mobile+camera.jpg Internet

  4. Project stakeholders

  5. Status of the iteration goals basic functionality – proof of concept

  6. Status of the iteration deliverables *Updated project plan V *Updated requirements document (no changes) V *Technical specification V *Updated QA plan V *Test cases, QA report and test log (not applicable yet) * Progress report V

  7. Realization of the tasks

  8. Resource usage Resource usage after PP Resource usage after I1

  9. Resource usage

  10. Used work practices * Version control: bitbucket.org (Mercurial) * Continuous integration: Hudson * Weekly meetings -> to two times per week * Weekly info letter sent by PM * Retrospective meetings held in PBL style * Sprint planning sessions to be renewed

  11. Quality issues www.lumaxart.com Proof of Concept

  12. Quality plans • Tests are to be based on user stories • Unit tests are planned as tasks during sprint planning • Because of proof of concept and prototype building no implemented practices exist at the moment

  13. Risks

  14. General architecture

  15. Mobile architecture

  16. Web UI layout sketch

  17. Demo-Proof of concept

  18. More on used practices The iteration and sprint planning needs more effort. The problems in planning have realized in the communication towards the mentor and the customer. The team has used Agilefant in planning and keeping track of tasks, but the Agilefant tasks have not described properly the current situation of the project. Therefore, the team is introducing the following process regarding the sprint planning: • 1. The product backlog consists of higher level user stories that can be demoed to the customer. These user stories are split and described more thoroughly in use cases. • 2. Based on the use cases, the SE-trio will make the initial plans regarding the sprints. The use cases are split into sprint level stories and these further into small tasks that can be demoed in the team meetings. • 3. After the initial planning is made, the team will keep a sprint planning session and adapt the Delphi-method and estimate the effort the tasks require. Furthermore, new tasks might be created in the planning session if the team sees this appropriate. • 4. After the estimation, the iteration-level backlog stories are assigned appropriate story points. The story points are also assigned to the appropriate product-level backlog stories. • 5. Based on the story-points and previous iterations the tasks are chosen that can be implemented in the current sprint. • 6. The progress is monitored in the weekly meetings with the following definition of ready and done task. The person responsible for a certain task will mark it ready when it can be demoed to the team. The team then decides if the task can be regarded as done. When all the sprint-level story tasks are done, the story is marked done. At the product-level, the stories are marked done when all related lower-level stories are done and the product-level story is demoed to the customer.

  19. More on used practices *Agilefant is being updated to represent the process described in previous slide. The work has started, but the story points are not yet correctly defined.

  20. More on used work practices Weekly meetings:The weekly meetings were held once a week. However, this is not enough and during the following sprints the amount is raised to two meetings per week. This is done in order to achieve faster response time to changes and risks.

More Related