group projects making working software as a team bruce scharlau, university of aberdeen, 2011

Group Projects

Making working software as a team

Bruce Scharlau, University of Aberdeen, 2011

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.


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.


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


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


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)


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.


What would you have done differently if you did it again?


Explain why group projects are different


Projects have a life cycle

What are the parts of the life cycle for projects in general?


Projects have a process model

Bruce Scharlau, University of Aberdeen, 2011http://www.slideshare.net/wasitova/pmbok-and-scrum-best-of-both-worlds

http://www.slideshare.net/wasitova/pmbok-and-scrum-best-of-both-worlds

Software has its own life cycle


What parts are in the software life cycle?

Software projects are different from other projects

What are the differences?


There are diverging views about software development

Big bang vs salami tactics

Manufacturing vs product development


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 customer’s specification


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?


Software is like product development

We are designing a new product. We have some ideas about it, but we’ll need to get some responses from our potential users and see if they are correct.

Maybe our idea won’t work and we’ll have to approach the problem differently.


Software projects often fail

Bruce Scharlau, University of Aberdeen, 2011http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS

Challenged means over budget, incomplete, late

http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS

Lots of delay in software projects


The project due in 12 months will arrive after 22 months, bit late if it was for specific event

Delays cost money


There are different methodologies used for software development


http://jeffsutherland.com/PracticalRoadmapMunich20091020.pdf


It doesn’t 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


Important to do project right

Often it doesn’t work out correctly… lots of failure

We need to build the project ‘right’ as well as ‘build the right project’ – balance to ensure build efficiently, and that build project business needs


What communication is there in waterfall?


Waterfall lacks sufficient communication

Documents produced at each stage of the process


Always moves forward, and client may not see anything until the end

Adding steps between parties makes software harder to build


clientdeveloper

analyst

What happens if the developer never speaks directly to the client?

Communication friendly process models are preferred

Describe the types of features you’d expect to see in a communication friendly project process model


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?


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


THERE ARE NO HERO PROGRAMMERSTHERE ARE NO HERO PROGRAMMERS

Agile adds better value than traditional projects

Bruce Scharlau, University of Aberdeen, 2011http://www.versionone.com/Agile101/Agile_Benefits.asp

http://www.versionone.com/Agile101/Agile_Benefits.asp

Agile provides better feedback

Bruce Scharlau, University of Aberdeen, 2011http://www.agilemodeling.com/essays/costOfChange.htm

http://www.agilemodeling.com/essays/costOfChange.htm

You follow regular workflow


5 days

All possiblefeatures

Prioritized current work

Ease of communication provides many benefits

• Makes it easier to discuss options

• Makes it easier to decide later in the process

• Means we don’t need to decide when we know little about the product


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 don’t have to lock-in choices early, so why should we?


Communication improves position in cone of uncertainty


Project estimates improve as we learn more about the project

Seek short project feedback loops

• Look for feedback from coding, integration, client, so that can make corrections as soon as possible


Communication enables choice of project priorities

The customer knows what is required for their application and this will be revealed more with each iteration


Stand up meetings aid communication

• Daily meetings of all of the team in the morning to determine who’s 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


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.


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


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


Use PDCA cycle for development


As <a user type> I’d like to <do x> because <reason>

Stories cover basic requirements and we supplement them with specifics

Evo process model provides clear communication of objectives


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.

IET is precise means to communicate priorities


Design Ideas Objectives #1 #2 #3 Total

Increase Market Share (12% -> 25%) 0% 0% 0% 0%

Increase Monetary Donations ($2.4m -> $3.0m) 0% 0% 0% 0%

Increase Time Donations (2,400 hrs -> 3,200 hrs) 0% 0% 0% 0%

Total Impact 0% 0% 0%

Costs (thousands)

Hardware / Software $1 $1 $1 $3

Development Effort $0 $0 $0 $0

Total Costs $1 $1 $1 $3

Performance to Cost Ratio 0.00 0.00 0.00

IET = Impact estimation tableIET = Impact estimation table

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


Limit work in progress (WIP)Limit tasks per stage speeds up delivery


Only this many tasks per stage

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


Minimize disruptions at hand-offs


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

Make workflow visible with kanban


Seeing the work in hand aids issue resolution

Shows:• Stuck

work• Priorities• Who’s

busy• Problems

We’ll use mixture of evo and lean


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)

group projects making working software as a team bruce scharlau, university of aberdeen, 2011

Documents

university of aberdeen

product bruce scharlau

different bruce scharlau

process bruce scharlau

team bruce scharlau

money bruce scharlau

life cycle bruce scharlau

working world bruce