1 / 23

T-76.4115 Iteration Demo

T-76.4115 Iteration Demo. Team Tarantino PP Iteration 24.10.2006. Introduction to project (10 min) General description MUPE Project status (10 min) Achieving the goals of the iteration Project metrics Work results (15 min) Project plan Risk log Requirement document

chacha
Download Presentation

T-76.4115 Iteration 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. T-76.4115 Iteration Demo Team Tarantino PP Iteration24.10.2006

  2. Introduction to project (10 min) General description MUPE Project status (10min) Achieving the goals of the iteration Project metrics Work results (15 min) Project plan Risk log Requirement document Used work practices (5 min) Agenda

  3. Introduction

  4. Introduction to the project • Quentin primary goal is to agilize movie’s production stages. • It is a modern tools for collaboration. • Amount of information that is gathered during pre-production is huge • During production coherent information is vital since shots can be filmed in middle of nowhere. A simple misunderstanding can become very expensive! • Crew can get more tailored information

  5. MUPE – Multi-User Publishing Environment • MUPE is an application platform for rapid development of (mobile) multi-user context-aware applications and services. • All parts of MUPE are written in Java (J2ME in clients) • Everything is available under the Nokia Open Source license 1.0. • Scripted client UI script language – one client for all applications. • Context information is added to the system from the network, or from each user client. • Communications data compressed • http://www.mupe.net

  6. Key Features • Optimised for the wireless network • Minimized network data traffic (data compression) – compulsory for services whose price depends of it • Optimised graphics (download at connection) • Dynamic content (objects in the client can be referred at a later time) • Persistent content – all content is serialized • Only server side application programming • Support for camera, sound, video with MMAPI

  7. Project status

  8. Status of the iteration’s goals • Goal 1: Project planning • OK • Goal 2: Understanding the domain • OK • Goal 3: Requirements specification on general level including most important functional requirements and use cases • OK • Goal 4: Selecting appropriate tools • OK, even though we’re using much more low-end tools than planned in the first place • Goal 5: Setting up the development environment • NOT OK, because we didn’t get access to development servers until last week => Dev. environment will be ready in a couple of days • Goal 6: GUI design • OK, even though work still to be done

  9. Status of the iteration’s deliverables • Project plan • OK • Requirements document • OK, all important requirements documented both in general level and in detail. However, this document is likely change in the course of the project. • Progress report • OK • SEPA diaries • OK, only “Communication practices” has Ch 1. ready => Other SEPAs are not needed at the moment. • Instructions and quidelines for development • OK • GUI prototype • OK, crude prototype made in our team Wiki

  10. Realization of tasks (1/2) * unplanned task (= a new task added during the iteration)

  11. Realization of tasks (2/2) * unplanned task (= a new task added during the iteration)

  12. Resource usage Original plan (in the beginning of the iteration) • Project is right on its track but well under its budget • Lower than expected resource usage in the PP phase will give us significantly more slack for the rest of the project Realization and updated plan (realized hours and updates)

  13. Quality dashboard • Documents revised by other team members than the author • No relevant changes to the project so far! Legend Confidence:3 = confident 2 = pretty sure 1 = uncertain 0 = no idea Quality:3 = quality is good 2 = not sure 1 = quality is bad

  14. Work results

  15. Project plan: Stakeholders & Staffing Mentor TeamTarantino Wiki Team Mupe Team Tuomas Niinimäki Project Mgmt Juha Mertanen Req. Eng. Customer Technical Advisor Architecture Vesa Kantola & Kai Kuikkaniemi Tero Heikkinen Lauri Kolmonen Lassi Seppälä Development Jyrki Hakkola & Riku Björklund Teemu Partanen QA Peer Testing Teppo Nurminen Hermes Team

  16. Project plan: Customer goals

  17. Project plan: Development process Project Planning Iteration 1 Holiday Iteration 2 • Iterative process • Two development iterations, each divided into two sprints • Sprint contents • Planning phase, overlaps with the previous sprint • Development phase, features for this sprint are frozen • Integration phase, the implemented features are verified • Sprint planning • Features to be included are agreed with the customer at the start of the sprint • Kick-off meetings with the whole team at the beginning of each sprint • Reflection workshop at the end of each sprint, process improvement Sprint 1 Sprint 2 Sprint 3 Sprint 4 S1 S1 S1 S2 S2 S2 • Colors: • Planning • Defeloping features • Integrating features S3 S3 S3 S4 S4 S4

  18. Project plan: Planned SE methods • Enhancing communication practices • Heavy usage of team Wiki, Skype • Few face-to-face meetings due to the lack of team room • Refactoring • Usability testing & heuristics • Early victory • "Easy thing first, most business critical second" • Process improvement • What did we learn? • Which methods were worth using and which were not? • What problems did we have? • Whas the problem caused by us or some other stakeholder? • What can we do better? • Which methods should be try using in the next sprint? • + Already used practices

  19. Project plan: Risks • Risk elicitation and analysis • The potential risks facing the project have been analyzed and logged in the risk log • Risks that need the most attention • RI004 Communication between group members might be insufficient • RI006 Especially experienced developers might spend too much time too early in the project. • RI007 Project servers might be down for a while. • RI010 Misunderstandings between the project group and the customers. • RI013 Sprint time schedule might be unrealistic. • RI018 MUPE is a relatively unproven technology. • These risks will be closely monitored • Realized risks • Development server was provided later than anticipated, and some tasks were delayed. • Planned effort has been reallocated, and controlling actions taken.

  20. Requirement document • From Wiki the user must be able to • Manage scripts, scenes, shots, people, location and call-sheets • Organize scenes and shots • Schedule shots • View and insert comments related to shots and call-sheets • View timetables • From MUPE the user must be able to • View all content • Insert comments and pictures • Prototype

  21. Used work practices

  22. Used work practices • Time reporting (Excel-sheets) • Status reporting: • Achieved during the last week, going to do during the next, worries • People responsible for tasks have been updating backlog information => wasn’t very useful in this phase • Communication • 2 team meetings, 1 mentor meeting, 3 customer meetings • Wiki becoming popular, Skype and email have functioned relatively well, mobile phone still often needed • Documenting • All the documents in team Wiki, has functioned well • Document version control in Wiki

  23. Thanks for your interest! Questions?

More Related