This seems counter intuitive to me and to the Test Driven Development philosophy but this article from Dr. Dobbs Code Talk states that there are far more effective techniques for Code Verification than Unit Testing. I let you judge.
[via Dr. Dobbs Code Talk]
ur-ban.com has an article describing in details the Law of Demeter. The law states that a method M of and object O may only invoke the methods of the following kind:
1. a method on O itself
2. any parameters passed to M
3. any objects instantiated within M
4. any direct components of O
[ via ur-ban.com]
When things go wrong and projects do not get delivered on time, on schedule, and on budget, it is easy to blame the team or the team lead. However, one should not forget that the organization as a whole can play a role in delaying projects. Ron Ronsenhead lists in his article some Organizational Issues preventing effective project delivery.
[via Ron Rosenhead]
Jason Gorman is pesting about the fact that some individuals in the Agile community are obsessing about project management and applying specific methods. He suggests that energies should be directed at delivering quality code instead since this is much harder to master that the simple Scrum or Kanban methodologies.
He is right on.
Speaking of Scrum and Kanban, you may also want to read my previous post.
[via Parlez UML]
I am interested in everything that can help improve my teams’ productivity and consequently helps us provide better value to our customers. As such, I have started reading about Kanban, a project management methodology that appears to “compete” with Scrum. Scrum is the methodology that I am currently using.
Scrum is an iterative method that provides incremental value to stakeholders at the end of each iteration. The product owner provides requirements at the beginning of each iteration. During the iteration, the team designs, implements, tests, documents, debugs new features based on those requirements. At the end of the iteration, the team demonstrates the new features to the product owner who accept or reject them.
Kanban on the other hand, is not an iterative process. The product owner provides ranked list of requirements. The team pulls requirements from top of the list one at a time. The team designs, implements, tests, documents, debugs new features based on those requirements. The product owner review the new features as soon as they are produced.
Project Management Hut presents an article describing Kanban as the next step in Agile Evolution.