Selling the idea of software development, refactoring and regression testing into a social environment where we are asking dancers to "work" during their leisure time sounds absurd. Yes, I know that at least 20% of the males in Lindyhop are professionals in the IT world. There is a concentrated talent pool of people to work on a collective, sustainable and community project? Why would I who spends 8-10 hours per day writing code, working for a software development shop want to do that when I need to get our and socialize, get physical exercise and be creative in real time through dancing?
After all that dancing, traveling and sharing the passion, I know I've felt like I would like to contribute to a community in time. The local, regional or even provincial community who are the same love. The sense of community health and wellness is something that every Lindy Hopper I come across wants to be a part of. So here's your chance, but only after you have completed extensive time in and you begin to have a sense to want to contribute in different ways.
The Planning Game.
Over the years it has become very clear that there are many ways to shave this Yak. Some teams need more process around this than others. For some, a simple list of features will do. For others, a Kanban board will be sufficient. Still others will need the full suite of stories, and tasks, and releases, and story points, and... Well, you know. Choose wisely!
Customer Tests.
Lots of customers don't want to be bothered with these tests. That's a shame, since they are demonstrably the best way to specify requirements. For those teams that have customers engaged enough to specify the requirements in terms of Cucumber tests, or FitNesse tests there is no better alternative. Teams that are not so fortunate are not likely to benefit from this practice. My personal rule is: If the customers neither read nor write the tests, then high level unit tests written in code suffice.
Small Releases.
It's hard to imagine a team that would not benefit from this practice. Keep the releases small. The more time you wait between exposing the customers to the system, the more can go wrong.
Whole Team.
Again, it's hard to imagine a team that would not benefit from a close relationships between the business people, and the developers. Not all teams are so fortunate, of course.
Collective Ownership.
As far as I'm concerned any team that has individual code ownership is deeply dysfunctional. If the owner of some part of the code decides to leave, the whole team is left in crisis mode. There are many ways to achieve collective ownership, but the bottom line is very simple. No single individual should be able to hold the team hostage. Every part of the code should be known by more than one person -- the more the better.
Coding Standard.
This simply goes along with Collective Ownership. The code should look like the team wrote it, not like one of the individuals wrote it. The members of the team should agree on the way that their code will appear. This isn't rocket science.
Sustainable Pace.
This is a real simple idea. Software projects are marathons, not sprints. You dare not run at a rate that you cannot sustain for the long term. Murphy tells us that any team that violates this practice is doomed to flame out at the worst possible moment.
Continuous Integration.
Certainly there are teams who's projects are so small that setting up a CI server is redundant. However, for most teams this is such a positive win that neglecting it would be immoral, if not insane.
Pair Programming.
Some teams benefit greatly by using this practice. Others do not. For the latter, some form of code review is likely necessary. In any case, it is a very good idea for every line of code to have been seen by more than one pair of eyes.
Simple Design.
If we learned anything in the '90s it is that over-design is suicide. The level of design is team dependent, of course; but the simpler the better is simply a good rule of thumb.
Refactoring.
Does anybody really want to argue that programmers should not keep their code as clean as possible? Does anyone want to argue that code should not be improved with time? Teams may choose different degrees of refactoring; but zero is probably not acceptable.
Test Driven Development.
This is certainly the most controversial of all the Agile practices. But the controversy is not about the word Test. Virtually everyone agrees that writing unit tests is important. Some of us think that the order in which they are written is important too. Different teams will choose different strategies. But teams that ignore testing are not destined for rapid success
No comments:
Post a Comment