Domingo 11/10 - (ver sábado 10/10)

9:15
Abertura do segundo dia
9:20
Keynote: Big Balls of Mud in Agile Development - How to Avoid Them (Joe Yoder)
11:00
Keynote: Agile Software Development in the Large (Jutta Eckstein)
12:30
Almoço para networking
13:30
Tutorial: Agile Refactoring for Making Systems More Adaptable (Joe Yoder)
15:00
16:00
Coffee Break
16:30
Tutorial: Planning, Estimating and Correction in an Agile Project (Jutta Eckstein)
18:00
Encerramento

Obs: Os horários estão sujeitos a mudanças sem aviso prévio.

Resumos

11/10 - 9:30 - Keynote: Big Balls of Mud in Agile Development - How to Avoid Them (Joe Yoder) - slides
It was back in ‘97 when Brian Foote and I first opined that: while much attention had been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture had seldom been discussed: the Big Ball of Mud. A Ball of Mud is, of course, a haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. Somewhat to our astonishment, since then, no one has ever undertaken to dispute this premise.
This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. What Agile Practices help us avoid or cope with mud? Does Agile practices such as TDD really help minimize mud? What are we doing RIGHT? What Agile Practices contribute to the problem? Encourage mud? Is Mud really the best that Agile can do? Is Agility’s utilitarian focus on process rather than design its secret weapon, or its Achilles heel?

11/10 - 11:00 - Keynote: Agile Software Development in the Large (Jutta Eckstein) - slides (inglês) - slides (português)
A lot of people still believe that agile software development is for small teams only. However, the agile value system and the principles behind as stated in the agile manifesto don't say anything about team or project size. Furthermore the projects I'm working on are typically large, distributed and mission-critical. Therefore, several years ago I took the challenge and tried agile software development in the large.
Meanwhile I made the similar experience on many large projects: Also large and even distributed teams can benefit from a value system that is beneficial for small teams.
In this keynote I want to show how to scale agile processes to teams of 300. In fact, the same techniques are also relevant to teams of ten or more developers, especially within large organizations.

11/10 - 13:30 - Tutorial: Agile Refactoring for Making Systems More Adaptable (Joe Yoder) - slides
Refactoring has become a well accepted principle within the Agile community. Uncle "Bob" (Robert Martin) even states in his Agile Software Development - Refactoring and Pair Programming book: "Refactoring, which when done as part of Test-Driven Development (TDD) is my personal favorite way to spend my development time." Agile software development promotes a process that encourages and embraces changes to requirements. Whereas Refactoring is a behavior preserving source-to-source program transformation. So how can refactoring help you make your system more adaptable? This tutorial will examine software evolution techniques such as Refactoring withing the Agile Development process for making your system more adaptable as dictated by changing requirements.

11/10 - 16:30 - Planning, Estimating and Correction in an Agile Project (Jutta Eckstein) - slides (inglês) - slides (português)
One of the key activities within agile development is continuous planning. Using short feedback cycles the whole team will be able to improve the estimates and help the customer to understand what his or her requirements really are.
This will make the planning more and more precise over time and allows for strategic software development and risk reduction. Moreover, with the help of retrospectives problems can be detected early on and corrections can be applied continuously in an easy manner - both is required for the success of every project.
In this tutorial I will explain how continuous planning works in practice.