Agile Engineering Practices serve as actual backbone for developing software in an agile way.
Currently, Scrum is the most popular agile method.
At the same time Scrum does not specify any engineering practices. Scrum Primer recommends, instead, putting good engineering practices in place over time.
Origins of Agile Engineering Practices
In difference to Scrum there are two agile methods with well-defined engineering practices systems. They are Extreme Programming and Feature Driven Development. These methods are coming from different backgrounds and thus, put a stress on different aspects.
In this post the following difference between practices and methods is used.
Method describes a common framework, how software development should be performed (typical roles, required meetings, artefacts, etc.) and can have as well a recommended set of engineering and management practices that should be used, when this method is applied on the project. To agile methods belong Scrum, Kanban, XP and other.
Among agile methods, there are methods that have only project management part specified. To them belong, for example, Scrum and Kanban. There are as well method containing both project management and engineering practices. Among them are Extreme Programming, FDD, and Tracer Bullet Development.
Engineering Practice is a specific software development practice that is proposed to be implemented by agile method.
Extreme Programming (XP)
XP inventors were using Smalltalk as their primary development language. Smalltalk was one of the first object-oriented dynamic software development languages. The productivity of Smalltalk programmers was really high in comparison with C++.
Due to the nature of the language, the primary way to verify the correctness of code was to run it. Thus, checking big pieces of code was tedious and error-prone. So, the solution found was to use a lot of unit tests .
When developing in dynamic language, the usage of pair programming is well justified. Many errors, small and big, got detected up-front. A lot of time is saved by reducing the number of error-correction/code reexecution cycles.
The set of engineering practices of Extreme Programming is following:
- Pair Programming
- Test Driven Development/Unit Testing
- Continuous Integration
- Refactoring
- Acceptance Testing
- Small Releases
XP as well contains a set of practices for maintaining shared understanding:
- Simple Design
- Coding Standards
- Shared Metaphor
- Collective Code Ownership
Feature Driven Development
Feature Driven Development , on the other hand, was created for very different type of projects.
It was first applied on a fixed priced project with 50 developers running for two years.
For the fixed price project refactoring and rework can be quite harmful. As well, it is really important to have a well-defined scope.
The first stage of the project was lightweight domain modeling. This served several purposes:
- fixing project scope
- minimizing refactoring on the model level (thanks to special modeling technique, called color modeling)
- estimation of project’s duration .
The resulting model than was used throughout the project. Model allowed coordinating all development and reporting activities.
To the engineering practices of Feature Driven Development belong:
- Domain Object Modeling
- Develop By Feature
- Individual Class Ownership
- Inspections
- Regular Builds
- Configuration Management.
In difference to extreme programming, builds in FDD should be done at least daily.
Each class in the domain model was assigned to an individual developer. He was responsible for maintaining this class for the whole project. For each feature the classes modified by it were identified. After that a feature team from developers responsible for these classes was gathered.
The process of developing a feature in FDD is clearly defined. Chief Programmer could make a decision whether to perform or skip individual steps. The implementation phase of FDD projects contains two processes. They are “design by feature” and “build by feature“.
During the “design by feature” step a feature team performs the design of feature together. This involves joint design session, creating sequence diagrams and developing stubs for classes. This stage completes by a design inspection.
“Build by feature” stage includes coding, code inspection, unit testing and promotion to build.
Formal inspections , in difference to Extreme Programming, are the primary means for achieving quality. Developers apply them on different levels: first architecture, then design, and then code.
Unit testing is also encouraged, but is not “the number one” tool for achieving quality.
In the next installment we will consider further development and the actual trends in agile engineering practices.
Would you like to exchange experience about individual practices? Would you like to share your war stories?
Then visit the next 11. Agile Stammtisch Frankfurt, where one can discuss all the questions related to agility.
The topic of the lightning talk would be “Agile Engineering Methods – a short overview”
Was this post helpful?
More articles
from
31.3.2021 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.