Jutta Eckstein
Objects in Action
|
|
Jutta Eckstein is an independent consultant and trainer from Munich, Germany. Her experience in agile processes is based on over ten years experience in developing object-oriented applications. Besides engineering software she has been designing and teaching OT courses in industry. Having completed a course of teacher training and led many 'train the trainer' programs in industry, she focuses also on techniques, which help teach OT, and is a main lead in the pedagogical patterns project. She has presented work in her main areas at OOPSLA, OT and EuroPLoP. She is a member of the board of Hillside Europe e.V., the association to advance expert knowledge (in the shape of patterns) about practice- proven techniques for analysis, architecture and programming of software systems as well as for the formation of organizational and team structures for software development. She is furthermore a member of the program committee of XP 2002, XP- and Agile Universe 2002, EuroPLoP 2002, OT2002 and OOPSLA 2002.
|
|
TUTORIAL, half day, Friday afternoon "Scaling Agile Process: Agile Software Development in Large Projects" One saying is that, if you have a hundred people on a development team, get rid of at least eighty of them and keep the top twenty (or less). As a result the chances for project success will raise significantly. But maybe you don't have even twenty top ones and/or the company just have these hundred people sitting around. It seems like the only places where large projects with huge teams seem to really work are projects where everything is formalized, the requirements are fixed and, most importantly, they don't change over time. A detailed plan can be set up and every successive action will stupidly follow the plan. Example are defense projects or projects with a similar structure, such as in airlines or nuclear power plants. We as software-engineers tend to question software engineering in the large not only because most of the agile processes claim to work only for small teams, also because most of the failed projects are really large ones. (Well, maybe nobody talks about failed small projects.) However, there are more than enough projects that are large in some sense. So, the question arises, how to use aspects of agile software development in large projects. This tutorial doesn't want to focus on every aspect of agile processes, but on those who we encountered to be mainly different in large projects. The differences might be that some things have to be implemented differently, because at a specific size of the project things don't work out the normal way anymore. Other differences are based on problems, which pop up especially in large teams, or rather which won't be problems at all in small teams. This tutorial is based on our experience coordinating - so far successfully - a large (currently 160 people) project. Although we are still in the process of learning we would like to share our experiences about how agile processes can serve large projects.
|
