1. Project Management of A Practical Guide to Uppsala

2. Agenda  Introduction  Individual Responsibility and experience  Conclusion  Q&A

3. Introduction

4. Background & Motivation  Thousands of International students come to Uppsala every year  They need all kinds of practical information to settle quickly at the start of their programmes.  A Practical Guide to Uppsala collects some necessary information and classifies it into several aspects A Practical Guide to Uppsala  We wanted to do something that was useful to not only us

5. Our Members  Project Manager: Yunyun Zhu  Website Architect: Gregory Humber  Content Creators: Fei Liu Xiaochong Tian  Tester: Hanzheng Zou

6. The Model of the Project  Requirements: Project lasting for only 2 weeks Five members with 30 hours for each Problems needing to be solve once there is  Using scrum Focusing on the parts of homepage, members, housing and supermarkets first Regular meetings (most being online):  Update working hours  Yahoo Group  Discussing problems and looking for solutions

7. Process of the Project Specification Creating Contents TestingReleasing Reporting bugs

8. Responsibility & Authority

9. Project Manager (Yunyun Zhu):  Holding meetings  Allocating tasks  Writing the specification  Keeping the communication with the team  Logging and updating working items

10. Gregory Humber – Website Architect – Brief Into  Born 1980  Home Country is Jamaica  I have experience developing websites  Career objective is to do Computer Science research within Academia/Industry

11. Gregory Humber – My contribution  I am referred to as the ‘Website Architect’ in this project. I was basically responsible for aggregating all the technological components so that we have a functioning Website  I decided on things such as where to host, what server technology & database etc  The website was done with pre-built software components which needed to be installed and configured. I had the responsibility for getting that done.

12. Gregory Humber – What was good  I was able to learn a new publishing system which I can use in future projects  I was able to put into practice time management and prioritizing techniques. I had a lot of other non-project tasks which I had re-order so I could meet the deadlines  I was able to get a better insight into the thought processes of people who have been brought up in a different culture. It’s through understanding people that, I think you are able to be a better team member.

13. Gregory Humber – What was bad  Looking back I think we should have chosen a different project. It required too much creative writing skills.  We should have done something of a more technical nature, computer science related. We would benefit more from the skill-set of the team

14. Gregory Humber – General View  Participating in this team has been a positive experience generally, and I definitely would do it again Thank you. My colleagues will continue from here and talk about is own personal experience

15. Content Creator (Xiaochong Tian)  Attending meetings and discussing the content of the website with teammates  Researching techniques  Creating contents of the webpages of supermarkets and members  Fixing bugs

16. Content Creator (Fei Liu)  Development of webpages Housing information Selection of mobile phone companies

17. Things we have learnt  Always start by well planning and estimating tasks that I am about to do  Power of cooperation  Be active in a project The more I communicated with my teammates, the smoother my work was carried out

18. Exposed Problems  Not planning my work well Underestimating the workload Disordered working process  Did not communicate with my teammates sufficiently Overlooking potential problems

19. Tester (Hanzheng Zou)  Think about the Project Management and discuss with Manager.  Be a tester. Write the > >. >

20. How to act as a tester?  Try to be professional. Then should at least one tester in the team.  Plan the test in the beginning.  Evaluate the testing in the end.

21. Test Procedure  Test and dev is more like a parallel work...  When the dev start, the tester should start to plan the test.  Then after the specification done, the test should work out the test cases.  Then when something done. Do the testing and give the feedback to the developer by sending him the test result report.  18 Test cases. 16 succeeded, 2 failed.

22. Conclusion

23. Hours Members Number of Hours spent A26 B31 C27 D25 E28

24. Good  Having 2 members with experiences of ‘real projects’  Meeting most goals  Clear roles  Leaving buffer time  Having Communication

25. Not Good  Starting too late  Communication not enough which resulted in some misunderstood to the working items

26. Q & A

28. Thank you