Adress:
Prvomajska 3, SI-2000 Maribor, Slovenia
Company:
FJA OdaTeam d.o.o., Meljska c. 36, SI-2000 Maribor, Slovenia (http://www.fja-odateam.com,
http://www.fja.de)
Email:
uros.grajfoner@fja-odateam.com
Position
paper for workshop:
FJA OdaTeam has been founded in 1993
and is currently located in Maribor, Slovenia.
Our business is consulting and construction of insurance information systems.
At this point, eight insurance companies in seven different countries in
Central and Eastern Europe use our insurance information system. We have used
OO-paradigm from the very beginning, developing mainly in Smalltalk and in the
last two years also in Java. Since 1998, we have gradually adopted eXtreme
Programming (XP). Since then, the number of developers has almost tripled to
14. The application of XP practices has helped us in many ways in sense of keeping
the same goals, having the same motivation and, most importantly, still
producing quality code. I’m a part of this team since 1996.
Training and education for new
developers, human interactions
In our case, most of developers are
students and after-graduate students. About half of developers are not working
on the full time basis, which makes our planning game a bit trickier on the
start of each iteration. Our development process includes “classic” XP
practices, such as pair programming, merciless refactoring, planning game,
test-first, rapid feedback, continuous integration, 40-hour work week, coding
standards, etc.
Training of new developers is done
mainly by pair programming (or sometimes even “group programming”), where more
a novice is accompanied by more experienced developer. Implementation of
various tasks includes education of the domain, test-first practice, rapid
integration and refactoring. The design is often done in groups, which include
all developers on the project, plus some of senior developers (coaches) and a
customer.
In my opinion, the discipline in
agile process has quite an important role when it comes to readability of
the code, planning the iteration and distribution of new releases to the
customer. It should not be imposed to the developers as controlling device, but
should actually be introduced as means of more effective development of better
systems. One of the values could therefore be stated as: self-organized discipline over imposed
controlling.
Thus, managing of the agile
process must assure well-defined and understandable tasks and user stories
(use cases) for the developers. Their completion and gathering of the new
knowledge, accompanied with running tests, makes developers feel more
comfortable. The customer, on the other hand, must be a part of the
development process. He has to understand the scope and complexity of the
desired change and/or functionality, in order to feel comfortable with the
result of each iteration.
My further
contributions to the topic would include further notions of self-organizing
co-workers, group programming, group design sessions and human interactions
during whole development cycle.