Presentation is loading. Please wait.

Presentation is loading. Please wait.

Group Projects Making working software as a team Bruce Scharlau, University of Aberdeen, 2011.

Similar presentations


Presentation on theme: "Group Projects Making working software as a team Bruce Scharlau, University of Aberdeen, 2011."— Presentation transcript:

1 Group Projects Making working software as a team Bruce Scharlau, University of Aberdeen, 2011

2 This is a full time course You are expected to spend 40+ hours a week on this course. This works best when everyone meets at agreed times and works together. Communication and learning occurs best when working together. Bruce Scharlau, University of Aberdeen, 2011

3 Teams will have two supervisors Every team will have me plus someone else helping them manage the project and the software development. You must come to the supervisor meetings to sign in with the department. Teams also work with their external clients. Bruce Scharlau, University of Aberdeen, 2011

4 This is work-like experience Follow same practices and use the same tools as professional software houses. The more you participate, and follow our guidelines, the more you will have to show on your cv, and discuss at job interviews Bruce Scharlau, University of Aberdeen, 2011

5 You work on a real project Real projects for real clients using the same processes as you will when working after graduation Provides insights into software processes and craftmanship needed in working world Bruce Scharlau, University of Aberdeen, 2011

6 Current week provides details for summer work Set up laptops and other machines Learn skills needed for development Games offer insight into working practices Set up blog for use with individual report: use ruby, rails and git (source control) Bruce Scharlau, University of Aberdeen, 2011

7 How well did you make your software last term? Did it work, could it have been better? Discuss in your group what you would do to build a project together. Make a list of main points. Bruce Scharlau, University of Aberdeen, 2011

8 What would you have done differently if you did it again? Bruce Scharlau, University of Aberdeen, 2011

9 Explain why group projects are different Bruce Scharlau, University of Aberdeen, 2011

10 Projects have a life cycle What are the parts of the life cycle for projects in general? Bruce Scharlau, University of Aberdeen, 2011

11 Projects have a process model Bruce Scharlau, University of Aberdeen, 2011 http://www.slideshare.net/wasitova/pmbok-and-scrum-best-of-both-worlds

12 Software has its own life cycle Bruce Scharlau, University of Aberdeen, 2011 What parts are in the software life cycle?

13 Software projects are different from other projects What are the differences? Bruce Scharlau, University of Aberdeen, 2011

14 There are diverging views about software development Big bang vs salami tactics Manufacturing vs product development Bruce Scharlau, University of Aberdeen, 2011

15 Software is like manufacturing Build product step by step, just like a car, etc Take design and then build each part and assemble in workshop to customers specification Bruce Scharlau, University of Aberdeen, 2011

16 Is it really like manufacturing? Build product step by step, just like a car, etc Take design and then build each part and assemble in workshop to customers specification Are these statements correct? Bruce Scharlau, University of Aberdeen, 2011

17 Software is like product development We are designing a new product. We have some ideas about it, but well need to get some responses from our potential users and see if they are correct. Maybe our idea wont work and well have to approach the problem differently. Bruce Scharlau, University of Aberdeen, 2011

18 Software projects often fail Bruce Scharlau, University of Aberdeen, 2011http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS Challenged means over budget, incomplete, late

19 Lots of delay in software projects Bruce Scharlau, University of Aberdeen, 2011 The project due in 12 months will arrive after 22 months, bit late if it was for specific event

20 Delays cost money Bruce Scharlau, University of Aberdeen, 2011

21 There are different methodologies used for software development Bruce Scharlau, University of Aberdeen, 2011 http://jeffsutherland.com/PracticalRoadmapMunich20091020.pdf

22 It doesnt have to be like that Incremental and iterative delivery means ship part of application early and get feedback Firm can use and learn, and refine ideas Firm can start gaining income from product Bruce Scharlau, University of Aberdeen, 2011

23 Important to do project right Often it doesnt work out correctly… lots of failure We need to build the project right as well asbuild the right project – balance to ensure build efficiently, and that build project business needs Bruce Scharlau, University of Aberdeen, 2011

24 What communication is there in waterfall? Bruce Scharlau, University of Aberdeen, 2011

25 Waterfall lacks sufficient communication Documents produced at each stage of the process Bruce Scharlau, University of Aberdeen, 2011 Always moves forward, and client may not see anything until the end

26 Adding steps between parties makes software harder to build Bruce Scharlau, University of Aberdeen, 2011 client developer analyst What happens if the developer never speaks directly to the client?

27 Communication friendly process models are preferred Describe the types of features youd expect to see in a communication friendly project process model Bruce Scharlau, University of Aberdeen, 2011

28 The agile principles cover many aspects of communication The manifesto has the basics http://agilemanifesto.org/ These form twelve principles: how many are about communication? Bruce Scharlau, University of Aberdeen, 2011

29 Ease of communication means common code base for team Use source control with anyone on the team expected to work on any part of the code as required Work in pairs whenever possible Bruce Scharlau, University of Aberdeen, 2011 THERE ARE NO HERO PROGRAMMERS

30 Agile adds better value than traditional projects Bruce Scharlau, University of Aberdeen, 2011 http://www.versionone.com/Agile101/Agile_Benefits.asp

31 Agile provides better feedback Bruce Scharlau, University of Aberdeen, 2011 http://www.agilemodeling.com/essays/costOfChange.htm

32 You follow regular workflow Bruce Scharlau, University of Aberdeen, 2011 5 days All possible features Prioritized current work

33 Ease of communication provides many benefits Makes it easier to discuss options Makes it easier to decide later in the process Means we dont need to decide when we know little about the product Bruce Scharlau, University of Aberdeen, 2011

34 Knowing that can communicate when required allows decisions to be postponed Why decide early on, when the client knows less about the product, when we can postpone the decision until later? We dont have to lock-in choices early, so why should we? Bruce Scharlau, University of Aberdeen, 2011

35 Communication improves position in cone of uncertainty Bruce Scharlau, University of Aberdeen, 2011 Project estimates improve as we learn more about the project

36 Seek short project feedback loops Look for feedback from coding, integration, client, so that can make corrections as soon as possible Bruce Scharlau, University of Aberdeen, 2011

37 Communication enables choice of project priorities The customer knows what is required for their application and this will be revealed more with each iteration Bruce Scharlau, University of Aberdeen, 2011

38 Stand up meetings aid communication Daily meetings of all of the team in the morning to determine whos did what yesterday, what they intend to do today, and what issues are holding them up, which need to be resolved Short, 10-15 meetings only: follow up as needed with longer individual meetings Let people work on project if not needed for meeting Bruce Scharlau, University of Aberdeen, 2011

39 Pair programming aids communication Two people work together at ONE computer to program a feature, or task One person types, while the other catches typos, suggests algorithms to make the code work, asks questions This is proven to work better than two people working separately and joining code together later. Bruce Scharlau, University of Aberdeen, 2011

40 TDD and BDD confirms that communication is ok The client writes tests that the team use to confirm the program does what it should. These guide the team in development. Use Cucumber to clarify with the client what is needed and then can use RSpec for more testing underneath Bruce Scharlau, University of Aberdeen, 2011

41 Continuous integration is a form of communication CI is the process of using a tool to download the group source code and building the project to see that it passes its tests and runs as expected. Assumes that everyone is submitting their code regularly to the group repository Bruce Scharlau, University of Aberdeen, 2011

42 Use PDCA cycle for development Bruce Scharlau, University of Aberdeen, 2011

43 As Id like to because Stories cover basic requirements and we supplement them with specifics

44 Evo process model provides clear communication of objectives Bruce Scharlau, University of Aberdeen, 2011 Evo checks that the application has clear business objectives and determines how to measure them along an appropriate scale to know whether the application is helping to meet desired organisation goals.

45 IET is precise means to communicate priorities Bruce Scharlau, University of Aberdeen, 2011 Design Ideas Objectives#1#2#3Total Increase Market Share (12% -> 25%)0% Increase Monetary Donations ($2.4m -> $3.0m)0% Increase Time Donations (2,400 hrs -> 3,200 hrs)0% Total Impact0% Costs (thousands) Hardware / Software$1 $3 Development Effort$0 Total Costs$1 $3 Performance to Cost Ratio0.00 IET = Impact estimation table

46 Lean and Kanban principles ensure we only do what is needed Limit the work in progress Delay decisions until last possible moment Minimize disruption at hand-offs Make workflow visible Bruce Scharlau, University of Aberdeen, 2011

47 Limit work in progress (WIP) Limit tasks per stage speeds up delivery Bruce Scharlau, University of Aberdeen, 2011 Only this many tasks per stage

48 Too many tasks creates a queue of work If you shuffle too many tasks for team members everything slows down, and –Feedback loops lengthen –Work takes longer –There is more work in progress –The quality goes down Bruce Scharlau, University of Aberdeen, 2011

49 Minimize disruptions at hand-offs Bruce Scharlau, University of Aberdeen, 2011 Provide work for next stage in suitable format For example, build to test to deploy hand-offs Improve throughput by focusing on done after sprint Improve throughput by focusing on ready before sprint

50 Focus on preparation and completion Bruce Scharlau, University of Aberdeen, 2011 © Jeff Sutherland 1993-2009 http://jeffsutherland.com/PracticalRoadmapMunich20091020.pdf

51 Make workflow visible with kanban Bruce Scharlau, University of Aberdeen, 2011 Seeing the work in hand aids issue resolution Shows: Stuck work Priorities Whos busy Problems

52 Well use mixture of evo and lean Bruce Scharlau, University of Aberdeen, 2011 Use stories to gather minimum features Use evo (IET) to determine implementation Use kanban board to limit and see WIP Automate testing and continuous build Work in weekly iterations (stages)


Download ppt "Group Projects Making working software as a team Bruce Scharlau, University of Aberdeen, 2011."

Similar presentations


Ads by Google