Organizational Patterns of Agile Software Development

James o. Coplien and Niel B. Harrison

Community of Trust
  • It is essential that people in a ateam trust each other; otherwise, it will be difficult yo get anything done.
  • Do things that explecity demonstrate trust. Managers, for example, should make it overtly obvious that they facilitate the achievement of organizational goals, rather than playing a central role to assert control over people. Take visible actions to give control over process.
  • Both overtly ambitious schedules and overly generous schedules have their pains, either for the teams or for the customers
Therefore: Reward teams for negotiating a schedule they can meet with financial bonuses [or at-risk compensation, or time off]. Keep two sets of schedules: One for the market and one for the team

You cant wait until you have every last requirement to get started. Therefore: As soon as you have some confidence about project direction, start developing areas in which you have high confidence.

Named Stable Bases
It is important to integrate software frequently enough so that the base doesn't become stale, but not so frequently that you damage a shared understanding of what functionality is sound and trusted in an evolving software base. Therefore: Stabilize system interfaces - the architecture - about once a week. Give the stable system a name of some kind by which developres can identify their shared understanding of that version's functionality.

Incremental Integration
For iterative development to work well it's necessary to make sure that components work togheter. Therefore: Provide a mechanism to allow developers to build all of the current software periodically. Developers should be discouraged from maintaining long intervals between check-ins. Developers should also at any time be able to build against any of the Named Stable Bases (or the newest chedked-in software)

Private World
How can we balance the need for developers to use current revisions, based on periodic baselines, with the need to prevent developers from experienceing undue grief by having development dependencies changed from underneath them? Therefore: Provide a mechanism where developers can maintain a Private World development environment. In their Private World they can control the rate of integration, which allows them to avoid having an integration step interup work in progress. The environment should represent a snapshot of all of the software being developed in a system, not just the code the developers is modifying. Try to ensure that the private development area is not used as a means of avoiding integration issues.

Comments

Post a Comment

Popular posts from this blog

Possible SYN flooding on port 3306 (MySQL)

The system setup is such that the MySQL servers that put the "Possible SYN flooding on port 3306" in the log files only are exposed to system internal backend services. These in turn aren't exposed to the wild wild web. Fronting the system we have the servers publishing services to internet. Thus I was kind of stunned when the log messages started to appear and even though we had done a release of the system I found it far fetched that we should start to DOS our self. So why did the messages appear? Two different error messages could be identified in the log files and they seem to be related, especially since the Java servers with link failure do communicate with the MySQL servers. Possible SYN flooding on port 3306 @ MySQL server Communication link failure @ Java backend servers After some tcpdumping, head scratching and googling I think I have it down to the root cause, hidden in how TCP works in general, and the OS config in combi...
Read more

Part 1 - Disaster Recovery with SRM and vSphere Replication

Image
Abstract  The company I work for has needs for disaster recovery but there is also external demands for it. The company not being very big has so far not been able to implement any automated disaster recovery solution although we do have a documented disaster recovery plan. The plan regardless of how good or bad it is isn't tested in a long time and the RTO (Recovery Time Objective) is wished by management to be days but I can't see that it is anything else than weeks. Since we virtualized our production system I've been looking at VMware vCenter Site Recovery Manager as a driver but the cost array based replication has stopped any attempts dead in their tracks. VMware vSphere® Replication has been around for a while now and we hope that it's hardened enough for a slightly bigger production critical implementation. In this article I will try to document and explain how we experiment, design and implement disaster recovery and even more important, in my opinion...
Read more

Part 2 - Disaster Recovery with SRM and vSphere Replication

Image
In the previous article we went through the installation and configuration of the SRM and vSphere infrastructure. The time has now come to actually doing some tests and failover some VM's.  In the simple scenario I expect everything to go smoothly but there are a few things that I'm concerned about at this point since the protected environment I'm ultimately is failing over isn't so simple. It has multiple dvSwitches, vLans, load balancer, firewall, ldap, a set of test drivers to verify the integrity of the system and access to the system in a sensible way for administrators so there are a few things that needs to be resolved. Protected Setup Test Failover The small test In this scenario I do a test failover of a single machine and verifies that it starts and that I can log into it. The steps are: Setup the machine running RHEL 5.5.  Install VMware tools  Kick of the vSphere Replication Create a Protection Group and ... no that didn...
Read more