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]
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.
Today, ytechie has posted a good introduction to distributed source control. It is nice to see that we now have more options when it comes to SCM.
While I can see the need for distributed source control systems in large projects like the Linux kernel or FreeBSD, I have found over the years that with the evolution of broadband around the world, bandwith is no longer a bottleneck and it is possible to use a centralized source control system with teams working on different continents.
In addition, I am wondering if distributed source control systems would have a tendency to impede continuous integration as individuals are no longer obligated to check-in their changes in the central repository.
I am interested in your comments. Do you have experience with Distributed Source Control systems and do you feel that they have helped improved your productivity?
[via ytechie]
Here are two Agile articles that I found interesting, and would like to share with you.
On his blog, Kai Gilb has started a series of posts entitled “7 truths about Agile and Scrum that people don’t want to hear” The first part, Wrong Focus, describes how developers should focus on providing value to stakeholders rather than creating software for the sake of developing software. It also states that the Agile Manifesto may be a cause for this wrong focus. For my part, I believe that while the creation of value falls in the developers realm, the definition of this value and its correlation with the stakeholders wants and needs is the responsibility of the Product Owner. Kai’s article is very good and I am looking forward to the six other parts.
In another seven posts series, Jack Milunsky introduces us to Lean Development and describes how seven manufacturing wastes (In-process Inventory, Over-Production, Extra Processing, Transportation, Motion, Waiting, Defects) matches wastes in software development (Partially done work, Extra Features, Relearning, Handoffs, Task Switching, Delays, Bugs). His articles are well structured and informative.