A while ago I took a
class on Scrum and Agile Project Management. During the discussion on
Scrum, it became apparent to me that there are several unchallenged
assumptions in many peoples' minds that make accepting Scrum difficult.
People assume that Scrum/Agile takes away something they have, but in
reality they don't have it. People assume they have the assurance of a
fixed schedule and proper documentation. In reality, they have
neither. They are like security blankets. The thought of them makes
people feel safe, but the reality isn't that they help.
The Agile Manifesto prefers working software over comprehensive documentation. That doesn't mean no documentation, but it does mean limiting the output of documentation. Some projects create reams of paper before writing any code. Their managers gain comfort from the idea that everything is planned well in advance. Unfortunately, that comfort is usually founded on hope, not reality. Projects that do a lot of documenting up front run into one of two problems. Either the project is in a straight-jacket and can't react when the plans are wrong or it does react and the documentation gets out of date. I have seen many a project with a lot of documentation that is completely useless because it hasn't been updated. The trick to getting good documentation is to use it. As with many things in life, if it isn't being measured, it won't be accurate. Moving to an agile project model may reduce the overall amount of documentation, but it shouldn't reduce the amount of useful documentation.
But how will the team know what to do? Won't there be miscommunication without documentation? No. Not if things are done right. If "customers" are close enough to give feedback on iterations and teams work to agreed-upon interfaces and integrate often, these problems can be dealt with.
The Manifesto also calls for responding to change over following a plan. Agile projects work on iterations. At the end of each iteration, the project will be in a working state and closer to the final goal. The difficulty many managers have is that Agile projects won't commit to getting all N features done by M date. With a more traditional waterfall model, marketing knows when the product will ship and what features will be present. It makes life a lot easier. Except that it doesn't. The dates are not realistic. With an Agile project, the team is just admitting that they don't know how long everything will take. This means everyone can react to the reality of the project rather than making plans based on unrealistic expectations that will be shattered later. The expected ship date is just a security blanket. Agile makes it clear you are giving this up (or giving up control of what features will be ready), but doesn't actually make the project any less predictable. It's merely exposing the unpredictability that is innate in software development.
Many of the objections to an agile or lean software project are based on perceived loss of control. The trouble is, that control is not real. Losing something you don't really have isn't actually a loss.
http://blogs.msdn.com/b/steverowe/archive/2008/05/20/get-rid-of-your-security-blankets.aspx
The Agile Manifesto prefers working software over comprehensive documentation. That doesn't mean no documentation, but it does mean limiting the output of documentation. Some projects create reams of paper before writing any code. Their managers gain comfort from the idea that everything is planned well in advance. Unfortunately, that comfort is usually founded on hope, not reality. Projects that do a lot of documenting up front run into one of two problems. Either the project is in a straight-jacket and can't react when the plans are wrong or it does react and the documentation gets out of date. I have seen many a project with a lot of documentation that is completely useless because it hasn't been updated. The trick to getting good documentation is to use it. As with many things in life, if it isn't being measured, it won't be accurate. Moving to an agile project model may reduce the overall amount of documentation, but it shouldn't reduce the amount of useful documentation.
But how will the team know what to do? Won't there be miscommunication without documentation? No. Not if things are done right. If "customers" are close enough to give feedback on iterations and teams work to agreed-upon interfaces and integrate often, these problems can be dealt with.
The Manifesto also calls for responding to change over following a plan. Agile projects work on iterations. At the end of each iteration, the project will be in a working state and closer to the final goal. The difficulty many managers have is that Agile projects won't commit to getting all N features done by M date. With a more traditional waterfall model, marketing knows when the product will ship and what features will be present. It makes life a lot easier. Except that it doesn't. The dates are not realistic. With an Agile project, the team is just admitting that they don't know how long everything will take. This means everyone can react to the reality of the project rather than making plans based on unrealistic expectations that will be shattered later. The expected ship date is just a security blanket. Agile makes it clear you are giving this up (or giving up control of what features will be ready), but doesn't actually make the project any less predictable. It's merely exposing the unpredictability that is innate in software development.
Many of the objections to an agile or lean software project are based on perceived loss of control. The trouble is, that control is not real. Losing something you don't really have isn't actually a loss.
http://blogs.msdn.com/b/steverowe/archive/2008/05/20/get-rid-of-your-security-blankets.aspx
No hay comentarios.:
Publicar un comentario