Over the Christmas holidays I finally had time to read the excellent report "Scrum and XP from the Trenches". In it Henrik Kniberg describes in great detail how his company has implemented Scrum. Most notable is that he does not spare out the trails and errors they encountered along the way and also describes the problematic areas. One of them: testing. In Scrum you produce a release every, say, 3 weeks. The term "release" IMO implies that the software is tested (otherwise it might be just another build). In order to get that done you will need to code test-driven (well, duh, it's agile after all). That means: unit tests and back box tests. The latter are often much harder to implement and a pain to set up (so save some time at the beginning of your project to get the infrastructure right). But even then you might find that there is a remaining part of your system which you need to test manually. And that will be the same repetitive process every three weeks. That's painful. I wonder how Kent intends us to do this. Any experience/opinions?
Lately, I had a lot of conversations about multi-tenancy (MT). So I finally wrote up my thoughts on that term. In this post I will argue that MT is a value that depends on a continuous variable. Therefore, any statement about a system being “MT” can only be made in the context of the given requirements. It is not a property of the system itself . I will also show that perfect multi-tenancy is indistinguishable from single-tenancy (ST). MT is a value that depends on a continuous variable Imagine a step-function "ST-MT" (values are either 0 or 1) that determines if a given system is MT (1) or ST (0). That function will look like this: ST-MT = function (system, business requirements) Look at the function’s arguments: the first one is obvious – the result will depend on the system itself. The second one is more interesting: it is the cumulative set of business requirements . Typically, these requirements will include: Resource sharing: systems typically declare...
Comments