Session 1

What is "Agile"?


810:188
Agile Software Development


Opening Question

Does anybody what this course is about?
Good. At least I'm not alone. :-)



Opening Discussion

What are the characteristics of a great software team?

Some answers: Delivers software that is reliable, on schedule, and under budget. Communication between the customer and the developer. Well-defined goals, so that team members know what to do.

What are the problems you face as a developer?

Primary answer: More experience!



What is "Agile"

In recent weeks, when students asked, "What is is your summer course about?", I sometimes told them to google "agile software development" to find out a little about what the course title means.

Back when I last taught an agile development course, I recorded that the result of the query on August 24, 2004, was:

Results 1 - 10 of about 336,000.
Search took 0.25 seconds.

When I made the same query this morning, May 10, 2010, the result was:

About 1,670,000 results (0.19 seconds)

That is a five-fold increase in documents in the last six years. Clearly, the topic is still a topic of discussion.

Today when I pressed the "I Feel Lucky" button, Google gave me the Wikipedia page for agile software development. Wikipedia wasn't nearly as large or popular in 2004 as it is today. When I pressed "I Feel Lucky" back then, Google served the The Agile Manifesto.



Manifesto for Agile Software Development


We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

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

That is, while there is value in the items on
the right, we value the items on the left more.



Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.


READ IT OUT LOUD...

Read that page. Follow the link to Principles of Agile Software and read some more. Without any technical detail, these two pages tell you an awful lot about the term "agile software development".

When I pitched this course, here is what I was thinking: The 'agile' movement has blossomed in the software industry in the last five years, but its values and practices are as old as computer programming itself. Yet our students don't get to learn about or from it, because, if they get any exposure to software development principles at all, it is from the traditional software engineering community.

In this course, I would like students to learn (more) about:

All of these ideas and software tools draw heavily from existing practices. In the mainstream commercial world, they first grew in the object-oriented communities around Java and C++. Going farther back and into smaller communities, these ideas have long been known and practiced in the Smalltalk and Lisp communities. You can also see many of these ideas in the work of building architect Christopher Alexander. They share a common theme of growing software, organically, rather than master planning it.

(How many of you have taken 810:172 Software Engineering?) The 'agile' movement grew in part as a reaction to many of the kind of traditional software engineering practiced in large, hierarchical organizations. This course will explore some alternative ways to develop software, ways that are pragmatic practices of master programmers that complement or replace traditional software engineering methods.



What Will We Do?

I am not entirely certain yet. The Agile Manifesto will also be our guide as we develop and run the course. I have several key ideas that I want us to cover, several practices and tools that I want you to learn, but no fixed course. You are advanced CS students and so can help set the direction for the course.

Here is what I know we must do:

BUILD SOFTWARE

We must:

Building software is our central activity. It will allow us to understand these methods, tools, and patterns, not just memorize them. It will allow us to write about them, discuss them, and draw conclusions about them.

How, and how much, we build software is still open question. So is how we will evaluate our progress.

When preparing for this course, I reviewed many textbooks, on-line sources, and software tools. Here is a stack of them...



Mechanics of the Course

project -- 3-4 iterations
diversity
  - programming language
  - experience
team(s)

what class will be like
  - short, short lectures
  - discussion
  - coding and demos of code
  * meet in 335 as our studio?

time expectations: 4-6 hours a day out of class
work expectations: gotta do this stuff


Wrap Up


Eugene Wallingford ..... wallingf@cs.uni.edu ..... May 10, 2010