bliki tagged by: collaboration
A while ago I was chatting with a post-doc on his way to an academic career. He was asking me about research topics wanting my input as he felt I could inform him on what would be research of practical use. I wasn't very helpful, but I did mention that the best way to do this would be to spend some time in industry to get a feel of how software development works in the wild and what problems could do with some research effort. His answer to this thought was very troubling.
17 December 2008
Here's a common misconception about agile methods. It centers on the way user stories are created and flow through the development activity. The misconception is that the product owner (or business analysts) creates user stories and then put them in front of developers to implement. The notion is that this is a flow from product owner to development, with the product owner responsible for determining what needs to be done and the developers how to do it.
4 February 2010
All agile methods stress the importance of direct interaction between the developers of a system and customers who are its eventual beneficiaries. The agile manifesto said "Business people and developers must work together daily throughout the project", which is there to stress the high frequency of interaction. Extreme Programming stresses this through its practice of OnsiteCustomer.
15 August 2003
A common thing you find in agile projects is that the development team sits in a single open team room. It was advocated early on in Extreme Programming and called out as one of primary practices in the second edition. Agilists favor a open team room as it promotes lots of informal and deep communication between people on the team.
14 June 2010
When people use the term 'software architect' they are using a metaphor from building construction to help people understand the architect's role.Ironically in doing this they misunderstand the actual role of a building architect.
14 August 2003
Open Space is an approach to help you put together self-organizing conferences. I was first introduced to it by Norm Kerth in 1997 and have since seen it used, and used it myself, many times. It seems to work well in small scales, groups of a dozen or two people, and at larger scales of one or two hundred. I've seen it for periods of one to three days. I'll describe it with variations I have seen: Crested Butte is a small annual workshop of around 20 people, Agile Universe 2002 had about 100 or so at the conference with Open Space in one track (they've continued to do this since, but I've not been able to get there), foocamp did this with a couple of hundred people. The technique was developed by Harrison Owen and is well described in his book.
24 August 2005
A project timeline is a valuable thing to produce during a project retrospective. A timeline should show the various events that occurred during the project, and how they affected the project.
2 December 2003
If you're using XP style planning, you need to get rapid consensus estimates from developers. Throwing the estimates lets you quickly tell when developers have same similar views on an estimate (so you can note it and move on) or if there is disagreement (when you need to talk about the feature in more detail.
22 June 2004