T-76.4115 Iteration Demo

1. T-76.4115 Iteration Demo Team Androids Implementation 19.12.2010

2. Agenda • Project status (10 min) • goals, tasks, effort, quality, risks, changes • Experiences of work practices and tools (5 min) • Process improvement (5 min) • Work results (20 min) • presenting the iteration’s results • demo • Comments and questions (10 min) • Customer and mentor discuss privately on the evaluation (10min) 2

3. Introduction to the project • Customer: TVKaista, a company that brings you all TV shows from all free national channels from the past weeks. A user can view these recordings from multiple different platforms from mobile phones to computers and game consoles. • Their need: Better experience when using Playstation 3 as platform. • Our mission: Improve user interface in terms of usability. 3

4. Status of the iteration’s goals 1/2 • Goal 1: Communicate through updated project plan • OK, project plan experienced multiple updates through risks and updated processes • Goal 2: Communicate through updated requirements document • OK • Goal 3: Plan and document technical specification for the solution • Goal 4: Well-tested solution • OK, solution was under constant testing twice a week • Goal 5: Working flash video player • OK • Goal 6: Functional and usable user interface for browsing shows • OK, also 2 additional prototype interfaces • Goal 7: Solution has improved security and usability because of user authentication • OK • Goal 8: Hear and learn from other projects experiences • OK, group participated in 3 Experts Exchange Sessions (EES) • Goal 9: Keep all stakeholders informed • OK, customer was met three times during the implementation, besides that, a weekly report kept customers updated about the projects situation • Goal 10: Hold two sprint demo presentations • First one held, you are watching the second 4

5. Status of the iteration’s deliverables • Software • www-based user interface • 13/15 tasks done, 1 partial (search), 1 moved to next sprint • Flash video player • 5/9 tasks done, 2 cancelled (layout), 2 moved to next sprint • Layout / design • New color theme • OK • Documents • Project plan • Multiple updates • Requirements document • Some updates • Technical specification • OK • Test cases and test log • OK • Progress report • OK 5

6. Realization of the tasks 6

7. Resource usage Original plan (in the beginning of the iteration) Realization and updated plan 7

8. Requirements • F12 and F13 were abandoned due lack of resource and importance for customer. • No major changes at any point during project.

9. Quality assurance in I2 • Pair programming has been carried out mainly by developers. Weekly working times has been excellent for pair programming but also self-organized meetings has been occurred. • Performance tests are done by all team members. Performance issues have mainly come across with Flex player (small pictures). • Two code review sessions were held. Practically each line of code was reviewed with architect's guidance. • End user usability session were held in sprint 3. A great amount of usability issues were found and most of them are fixed since. • Test case based testing was done to cover things that exploratory testing might have missed. And unfortunately some issues indeed appeared. Test cases were modified from use cases. • Peer testing was done cooperating with group 3. Charters were edited to focus on usability, while it was the main quality goal. No big suprises here, most issues were known from end user usability sessions. 9

10. Quality status of subsystems • Interactions in UI have improved a lot from I1 because usability tests have been extremely informative. • A lot of effort is used to make UI more desired. • Flex player's controls have been completely renewed. Quality: 1 = poor 2 = good 3 = release stage Number of defects • Number of total defects is low because pair programming ensures that code is well evaluated before related task is marked ready. 10

11. Software size in Lines of Code (LOC) 11

12. Changes to the project Team androids participated into Root Cause Analysis (RCA) study which allowed the team to experiment new kind of method for reflecting their work. During the root cause analysis the group formed a tree about all bad experiences during project, from this tree, 2 issues got selected and deeply analyzed by the team members. From these analysis the team decided to take action by clarifying communications guidelines and improving the quality of task descriptions and requirements especially during the start of the sprint. Also, the team discussed about how to handle customer expectations better. 12

13. 10.9.2002 Jari Vanhanen

14. Changes to the project • New process before sprint start meeting • SE-trio prepares in advance a draft about sprints tasks. This draft includes hour estimations, DONE-requirements, and tasks in general. • In the actual sprint start meeting with customer and all members of the group, the group finishes draft by adding/removing tasks, prioritizing and assigning them and correcting hour estimates. • Communication guidelines • Clarified the role of groups communication tools (e-mail, IRC, wiki, calendar, virtual meeting) • Team skills and performance is being more carefully looked into when discussing about customer requirements. • Adjustments in time sharing between different parts • From sprint 1 the team realized that problems need time for figuring them out, therefore more time was shared for bugs and problems. • Project Manager has started to study and keep track about spend hours shares in different parts of the project, this will help adjusting the hour shares and estimations in sprints 3 and 4. 14

15. Future changes to the project • Even better and more precise hour share for sprint • Less confusion amongst the developers during sprint start by more clearer view about each ones work • Improved co-operation between developers, layout-designer and requirements engineer. • Tasks, especially those related to project management are better planned beforehand. 15

16. Risks list: • Short list of risks: • A developer quits in the middle of the project • The customer decides to quit the course • Power loss or computer malfunction in school computer during working hours. • Schedule overlap in periods II-III when developers attend new courses. • Playstation 3 doesn’t support AJAX • The team cannot find suitable working space for PS3 testing • Uncontrollable disaster (fire, flood, etc.) that damages servers. • Decent development tools are not found • End-users won’t adapt to the new interface or are unhappy with it. • NEW! Solution is too demanding for playstation performance, causing it to work slowly • NEW! Playstation lacks support for certain kind of basic web-browsing functionality 16

17. Risks • Current situation regarding the risks • Materialized risks • Playstation 3 performance wasn’t good enough to run Adobe Flex framework. • Solution: Breakthrough in code • One of the developers had so busy schedule in his personal life that he couldn’t deliver the tasks he was assigned to • Solution: Decision to assign 2 responsible persons per task • Authentication problem due poor support of playstation 3 browser • Solution: Workaround found after numerous hours • Agilefant tool went offline right before customer meeting • Solution: Backups were used during the meeting • New risks • Solution is too demanding for playstation performance, causing it to work slowly • Playstation lacks support for certain kind of basic web-browsing functionality 17

18. Used work practices • Experiences of planned work practices • Team held two sprint start meetings and one sprint end meeting. First sprint start meeting was a bit rushed as was the sprint itself due exam week. However the team managed to pull out good results at the end of the sprint. • In sprint 2 start meeting the team was better organized, however some lacks were still found in hour estimations and requirements. Also the relationship between layout and requirements and tasks wasn’t monitored carefully enough. • Usability improvement workshop was held right before teams kickoff party. It offered good chance for group to discuss about usability issues and decide how to fix them. • Root Cause Analysis experiment was a great success. Having 3rd party helping the group to find out it’s problem points was something that was definitely needed to open discussion about problems. 18

19. Results • During Implementation 1 the team has developed a good understanding about the product and can concentrate more on careful details in Implementation 2 • Development process has improved by adding better task descriptions. • Team has developed stronger bonds and is less worried about bringing up possible issues. • We are loving to hate Playstation 3s own viewpoint about internet browsing. 19

20. Demo time • Presenting the current interface side by side with the Team Androids one • Cases: • Comparison of program list view • Opening a video • Video player comparison • Series and List –pages • Searching • Changing settings 20