Posts Tagged ‘Methodology’

Some of the problems I see in Agile Methods – Part 2

Sunday, November 22nd, 2009

Another problem I see in some Agile Methods is a lack of flexibility about the rules they propose. I see that as some kind of contradiction: for example, Scrum is empirical only for things that it does not define beforehand.

“Don’t change Scrum” is something that Ken Schwaber wrote in his book Scrum and the Enterprise. Here’s his rationale for this: Scrum isn’t a process that you can modify to fit your enterprise. Instead, it exposes every dysfunction in your enterprise while you build products… Whenever people change Scrum, it’s because they’ve run into a problem, dysfunction, or conflict that they do not want to face and fix. Instead, they change Scrum so that the problem remains invisible and remains deadly to the enterprise. If you allow this to happen, you will have lost Scrum’s primary benefit”.

(more…)

Agile Methods Versus CMMI?

Thursday, May 7th, 2009

It was logical that my first post on the Hexacta blog would be on methodology issues, since this is what I’ve been doing for so many years. And one particular issue that remains very relevant these days is the evolution of agile methods and their contrast with the methods that result from applying models such as CMMI.
On Monday March 18th I was invited to participate in a debate titled “CMMI versus agile methods?” Before the debate, there will be a lecture by Jorge Boria with a very interesting title: “Waterfalls versus Agile and other nonsense”. I don’t know exactly what Jorge is going to say, but the title is very true: sometimes there are false dichotomies that end up being nonsense.
(more…)

Continuous Integration

Wednesday, May 6th, 2009

The Continuous Integration methodology has become very important in the software development community and this is probably due to the effects of agile methodologies. On teams that have adopted such methodologies, continuous integration is one of the pillars of agility, ensuring that the entire system runs correctly on every build, even with numerous teams and high frequency of changes. But, why should we use continuous integration? What are the benefits it can provide?
(more…)

Test, test and test (I forgot … More test!)

Wednesday, May 6th, 2009

We are already able to say that a software development without automated testing is unacceptable. We can distinguish among unit, functional, integration and more, but the idea of automating is great!!! If we focus on unit test we will see that it is apparently easier to implement, although it is not trivial to be able to do testing that truly tests the functionality and, even better, that can be almost complete. TDD and “First Test” help to make all this even more believable (for unbelievers) and further encourage those who live it as an act of faith.

As a first post of automated tests, we could identify (among many things) some advantages of this practice:

  1. All tests are regression tests.
  2. The continuous integration makes better tests.
  3. We lose the fear towards code refactoring.
  4. Agile development is successful because of the tests.
  5. Those who test the code with a “main” to see if it is working … What is the difference between that time and writing a real test that will also help us throughout the project?
  6. We know exactly which change caused a compatibility bug (instead of knowing in what month it occurred).
  7. No need to remember the whole code. If you forget what the subject was, you can go and see the tests for that functionality.
  8. The design of the application tends to be better and less decoupled.
  9. You go to bed with peace of mind! You know the code you touched did not break anything (that has tests).