Agile Development Overview (with a bit about builds)

This is my Tech Talk Presentation. My Tech Talk Presentation is amazing.Agile Development Overview With a little emphasis on Continuous Integration

Agile Development• a.k.a. "eXtreme Programming" (XP)• a.k.a. "Scrum"• a.k.a. “Lean Development”• All share similar practices, so generally grouped as “Agile Methodologies”

talk ingredients• 2 bits on theory• 2 bits on practice• 2 tangential asides

talk sequence• A little theory/values/principles• Some practices• A bit more theory/values/principles• A little more about Continuous Integration (automated builds)

Lets talk about methodology: “waterfall” vs. “agile”

waterfall sequence• specify• design• implement• test• deploy

Why Waterfall is easy:• easy to plan• easy to fund• easy to predict (like planning)• easy to plug into Microsoft Project

For many things, Waterfall is great.Like building new buildings, dams, U2 concerts, weddings, etc. this is ﬁne.

For software, a formal waterfall can be difﬁcult because it:• doesnt like to re-specify• doesnt like to re-design• doesnt like to re-implement• doesnt like to re-test• doesnt like to re-deploy

"doesnt like" = more money, more time, poor results

"poor results" = “You gave us what we asked for, but it isnt what we want.”

This happens a lot.

Tangential Aside #1

IT work is fun & well paid.

Ok, not always, fun.But often engaging in a particularly nice way.

I have friends who are journalists, teachers, legal aid lawyers, and accountants.Their work is signiﬁcant, inspiring, and important, but often ﬁnancially very challenging. I struggle with why this is.

I also have friends who are investment bankers, business owners, and corporate lawyers.They make heaps, and the signiﬁcance of their work is up for discussion. I struggle with this too.

Ahem, my point...is that IT work as a career is quite well paid, thanks very much.Particularly considering how much fun it is (if you are so inclined).

The converse of this is that businesses see IT work as tremendously expensive.

It is also mysterious, risky, and career threatening to run an IT project within a business.

(And they see IT people making money and having fun, and this doesnt help.)

As IT people we need to respect this.

One way is to simply cease having, or appearing to have, fun. Which is what many of the major consulting ﬁrms do. They charge quite a lot for this.

Another way to ﬁx the situation is to use processes that strive to deliver actual value as quickly as possible. This is what a lot of Agile is about.

end tangential aside #1

Four XP values:Communication Simplicity Feedback Courage

A dozen Common Agile Practices in no particular order

Morning Standup (communication) 1

Iterationsa.k.a. “Scrums”, or “Sprints” (simplicity, feedback) 2

Continuous Integration automated build (& test) (feedback) 3

Test Driven Development (TDD) (feedback, courage) 4

Retrospectives(communication) 5

Story Cards/Story Wall (communication, feedback) 6

Velocity(feedback) 7

Pair Programming (communication, ?) 8

Technical Debt(simplicity?, courage?) 9

Refactoring (courage) 10

Showcases(communication, feedback) 11

Iteration Planninga.k.a “The Planning Game”(simplicity, communication) 12

Some of these techniques need each other examples: Refactoring needs TDD TDD needs Automated build & test

Some of these techniques standalone, and can add value regardless of methodology. Retrospectives & Continuous Integration are two

Lets talk about a bit moreAgile values/theory/manifesto/dogma

“Agile Values”• Individuals and interactions over processes and tools• Working software over comprehensive documentation• Customer collaboration over contract negotiation• Responding to change over following a plan

The Agile Manifesto : Twelve principles• Customer satisfaction by rapid delivery of useful software• Welcome changing requirements, even late in development.• Working software is delivered frequently (weeks rather than months)• Working software is the principal measure of progress• Sustainable development, able to maintain a constant pace• Close, daily cooperation between businesspeople and developers• Face-to-face conversation is the best form of communication (co-location)• Projects are built around motivated individuals, who should be trusted• Continuous attention to technical excellence and good design• Simplicity• Self-organizing teams• Regular adaptation to changing circumstances

Just so you know,I am a Scrum Master.

David Benjamin September 7th 2007 [ MEMBER: 000017685 ] [ EXPIRES: 2011-04-01 ] Tom MellorCertified Scrum Trainer Chairman of the Board

There are books• Kent Beck, “Extreme Programming Explained”• Mary & Tom Poppendieck, “Lean Software Development”• and oh so many more

Tangential aside #2

I mentioned “Amiga” which was a computer that existed brieﬂy in the 1980’s Please allow me to discuss two perception issues.

1. "Anything that is in the world when youre born isnormal and ordinary and is just a natural part of the way the world works".2. "Anything thats invented between when youre fifteenand thirty-five is new and exciting and revolutionary and you can probably get a career in it".3. "Anything invented after youre thirty-five is against the natural order of things and the beginning of the end of civilization as we know it". -- Douglas Adams

In the IT profession, describing or tellingpersonal anecdotes about technology that is...• less than 2 years old - is cool and shows you are hip.• between 2 and 5 years old - is acceptable and safe.• between 5 and 10 years old - is risky and should be only mentioned vaguely, as if you read about it someplace or heard people talking.• more than 10 years old - dont talk about it. If you make the mistake and do, back away from it and pretend its an old joke of your fathers.

In reality, both jokes are perception issues.Try to rise above them and make sensible decisions about what is useful and good and what is either past its use-by date, or strongly hyped.

End of tangential aside #2

Right, we were ﬁnishing up talking about agile values a second time. One more thing: As with many things these days, the community is surprisingly small and very accessible. Tune in!

Automated Build

Build breaks can have a lot of hidden, but very immediate, costs.

Discovering integration or installation problems late can force a lot of rework, and sometimes, breathtaking hacks.

Automated build can be as simple as a script launched every 10 minutes.

build logic• has someone checked stuff in? (no -> quit, yes -> continue)• check out or update all the source• build the code• run tests (if any)• build the installers (if any)• light the green light.• any failures? light the red light.

“Green light” means• all code is compiling/building• all tests are passing• there are installers available on the build box

Most teams say, "When the light is red, nobody should commit changes until the build is ﬁxed."

If your test coverage is good, the build can give the team a lot of conﬁdenceto do major refactoring late in the project cycle. Courage.

If you need to do frequent releases, under pressure,having the installer come off the build box removes a lot of risk... and fear.

Build Tools• Hudson• CruiseControl• Bamboo• others (commercial & open source)

Note: It is important to make sure no "special magic" exists on the buildbox and that the build can be run quite easily on any dev machine. This makes sure the whole build process is checked in.It makes sure that someone (the source) always knows how to build an installer.

Questions?

Thanks!

Agile Development Overview (with a bit about builds)

by David Benjamin on Feb 09, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 127

Statistics

Agile Development Overview (with a bit about builds) — Presentation Transcript

http://slowbluecamera.com	126
http://translate.googleusercontent.com	1