Found this interesting link for dummies: http://bloggerfordummies.blogspot.com/
It is really cool
Saturday, March 25, 2006
Blogger for dummies
Found this interesting link for dummies: http://bloggerfordummies.blogspot.com/
It is really cool
Thursday, March 23, 2006
Change request in XP
Dave Rooney wrote the following on handing change requests in XP:
A change is simply another Story or Stories, so use new cards. They can be estimated by the developers and prioritized by the Customer. During Release Planning, we've filled the iterations based on the team's velocity. So, in order to schedule a new story into an existing iteration, a story or stories of equal size must be removed. There's no 'We'll squeeze it in', or 'We'll try to get it done'. When you do that, the developers will start to fall off the testing bandwagon in a hurry. Then, the system's quality goes out the window. The key point is that time is not variable, but scope is."
A change is simply another Story or Stories, so use new cards. They can be estimated by the developers and prioritized by the Customer. During Release Planning, we've filled the iterations based on the team's velocity. So, in order to schedule a new story into an existing iteration, a story or stories of equal size must be removed. There's no 'We'll squeeze it in', or 'We'll try to get it done'. When you do that, the developers will start to fall off the testing bandwagon in a hurry. Then, the system's quality goes out the window. The key point is that time is not variable, but scope is."
Wednesday, March 22, 2006
Documentation in agile
In one of the agile discussion forums following question was asked and the answer made sense to me(in bold)
>I have tried to limit documentation and verbally brief my >engineers on what I want doing - normally a white board >discussion. Ask them to work in pairs, keep documentation to a> minimum and get every one to understand the design by >verbal communication.
Limiting documentation isn't the world's greatest idea. It's better to let them figure out what they actually need and what's a waste of time."
>I have tried to limit documentation and verbally brief my >engineers on what I want doing - normally a white board >discussion. Ask them to work in pairs, keep documentation to a> minimum and get every one to understand the design by >verbal communication.
Limiting documentation isn't the world's greatest idea. It's better to let them figure out what they actually need and what's a waste of time."
Subscribe to:
Posts (Atom)