When starting to use Scrum for software development, many teams approach acceptance testing in a more or less traditional way. Developers focus on implementing the spring backlog items within the sprint. At the end of the sprint a new release of the system is delivered and declared ready for acceptance testing.
There are is a problem with this approach. When a Product Backlog Item is not tested for acceptance, is is not completely Done. When acceptance testing is done after the sprint, that is, during the next sprint, any corrections resulting from its feedback can only be planned in the sprint after that. Much too late! This approach tends to result in an ever increasing stack of corrections taking time that should be used to implement new Product Backlog Items, and thus slowing down development.
So, why don't we do acceptance testing within the sprint? In this way we receive earlier feedback and have the opportunity to repair any issues right away and have the Backlog Item really done by the end of the sprint. But this approach has its own problems. For instance, team members cannot do acceptance testing themselves, but someone outside has to do this. This means that the software must be made available to some acceptance testing environment, where outsiders can perform their tests. They need a reasonable amount of time for that, which means that near the end of the sprint developers have to stop developing because whatever they deliver cannot be tested anymore. That means loss of precious time.
Do you have experience with acceptance testing within Scrum sprints? By the way, this problem exists in every iterative style of development; not just in Scrum. What solutions work for you?
2011-02-10
There's no such thing as platform-independence.
The central model in the Model-Driven Architecture (MDA) is the Platform-independent Model (PIM). The functionality of a system is specified it in a way that is independent of the platform used to implement it. To realize this implementation, the PIM is transformed into one or more platform-specific Models (PSM), from which source code is generated in a programming language like C, Java or .Net. That of course still needs to be compiled into machine code or byte code, but that is so obvious that it is usually not even mentioned.
The vision of MDA is attractive: to isolate the specification of system from continuous change in current implementation platforms. The idea is that if they change, you just have to develop new transformations to PSM's for the new platform, and new code generators. The specification of the system as a PIM remains unchanged.
One widely used programming languages used as a target for code generation, is Java. That's funny, because Java itself is already platform-independent. The C programming language actually is platform-independent too, but only at the source level, so that it has to be recompiled for any combination of the underlying operating system and processor architecture. But Java itself is also a platform for which alternatives exist, like .Net/C#, Scala or Ruby.
What has become of the vision of the MDA? In any case, it has not become a resounding success. Otherwise we would now all be working with MDA. In practice, there are many practical problems associated with this approach, making it less ideal than it seemed at the time. Partly because MDA relies heavily on UML, which is not designed, and not very suitable, for code generation. The approach that resembles the MDA the most is based on Domain-Specific Languages (DSL), but the differences are significant. If ten years ago you had specified all your systems as PIM’s in UML, they would now be pretty worthless. In theory, of course you could write a transformation into a platform that is now common, but that is not as easy as it seems.
In fact, the MDA with UML is also just a platform. And a platform independent-model is not fundamentally different from a program. Only the language is different. And that is the fate of any programming or specification language that is presented as platform-independent in the beginning. Eventually, even when the platform is successful, or perhaps especially then, alternatives will be developed, just like C# was developed as an alternative to Java. And then we will need another platform-independent platform from which code for these various alternatives can be generated. And so the circle is closed. Platform-independence is a moving target, an illusion, a utopia. There is no such thing!
The vision of MDA is attractive: to isolate the specification of system from continuous change in current implementation platforms. The idea is that if they change, you just have to develop new transformations to PSM's for the new platform, and new code generators. The specification of the system as a PIM remains unchanged.
One widely used programming languages used as a target for code generation, is Java. That's funny, because Java itself is already platform-independent. The C programming language actually is platform-independent too, but only at the source level, so that it has to be recompiled for any combination of the underlying operating system and processor architecture. But Java itself is also a platform for which alternatives exist, like .Net/C#, Scala or Ruby.
What has become of the vision of the MDA? In any case, it has not become a resounding success. Otherwise we would now all be working with MDA. In practice, there are many practical problems associated with this approach, making it less ideal than it seemed at the time. Partly because MDA relies heavily on UML, which is not designed, and not very suitable, for code generation. The approach that resembles the MDA the most is based on Domain-Specific Languages (DSL), but the differences are significant. If ten years ago you had specified all your systems as PIM’s in UML, they would now be pretty worthless. In theory, of course you could write a transformation into a platform that is now common, but that is not as easy as it seems.
In fact, the MDA with UML is also just a platform. And a platform independent-model is not fundamentally different from a program. Only the language is different. And that is the fate of any programming or specification language that is presented as platform-independent in the beginning. Eventually, even when the platform is successful, or perhaps especially then, alternatives will be developed, just like C# was developed as an alternative to Java. And then we will need another platform-independent platform from which code for these various alternatives can be generated. And so the circle is closed. Platform-independence is a moving target, an illusion, a utopia. There is no such thing!
Subscribe to:
Posts (Atom)