Presentation is loading. Please wait.

Presentation is loading. Please wait.

Agile Projects Making working software as a team Bruce Scharlau, University of Aberdeen, 2012.

Similar presentations


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

1 Agile Projects Making working software as a team Bruce Scharlau, University of Aberdeen, 2012

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

3 Projects have a process model Bruce Scharlau, University of Aberdeen, 2012

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

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

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

7 Delays cost money Bruce Scharlau, University of Aberdeen, 2012

8 There are different methodologies used for software development Bruce Scharlau, University of Aberdeen, 2012

9 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, 2012

10 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, 2012

11 What communication is there in waterfall? Bruce Scharlau, University of Aberdeen, 2012

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

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

14 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, 2012

15 The agile principles cover many aspects of communication The manifesto has the basics These form twelve principles: how many are about communication? Bruce Scharlau, University of Aberdeen, 2012

16 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, 2012 THERE ARE NO HERO PROGRAMMERS

17 Agile adds better value than traditional projects Bruce Scharlau, University of Aberdeen, 2012

18 Agile provides better feedback Bruce Scharlau, University of Aberdeen, 2012

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

20 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, 2012

21 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, 2012

22 Use your real options to procrastinate deciding to do something is not the same committing yourself to an action Bruce Scharlau, University of Aberdeen, 2012 When you commit early, then you must know WHY you do so and what the costs will be Go see lean procrastination blog

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

24 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, 2012

25 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, 2012

26 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, 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, 2012

27 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, 2012

28 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, 2012

29 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, 2012

30 Use PDCA cycle for development Bruce Scharlau, University of Aberdeen, 2012

31 Can also be seen as lean startup Bruce Scharlau, University of Aberdeen, 2012

32 Follow the TDD principles Bruce Scharlau, University of Aberdeen, 2012

33 Use red, green, refactor to code Bruce Scharlau, University of Aberdeen, Write a little test 3. Get test to pass 2. Stub out code. Watch test fail 4. Refactor Cycle time < 10 minutes Make it green, then make it clean

34 As Id like to because Stories cover basic requirements and we supplement them with specifics Bruce Scharlau, University of Aberdeen, 2012

35 User stories provide basic requirements

36 Stories are ranked by business priority and risk

37 Use burndown charts to measure progress

38 Evo process model provides clear communication of objectives Bruce Scharlau, University of Aberdeen, 2012 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.

39 IET is precise means to communicate priorities Bruce Scharlau, University of Aberdeen, 2012 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

40 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, 2012

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

42 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, 2012

43 Minimize disruptions at hand-offs Bruce Scharlau, University of Aberdeen, 2012 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

44 Focus on preparation and completion Bruce Scharlau, University of Aberdeen, 2012 © Jeff Sutherland

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

46 Well use mixture of evo and lean Bruce Scharlau, University of Aberdeen, 2012 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)

47 Build incrementally per greatest need at the time Small slices of functionality with working software at end of cycle Build with tests so you know it all works Track progress to see whats left Provide release for people to use and offer feedback Review your process regularly to improve it Bruce Scharlau, University of Aberdeen, 2012


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

Similar presentations


Ads by Google