The Agile Manifesto was written in 2001, and it signified the acceptance of the Agile methods. It consists of four values (that we will dig deeper into in this lesson) plus twelve principles that you should read through at some point in time.
Please take a moment to study the Agile Values from the Manifesto, replicated below, and the commentary below it before you move on to the quiz on the next page.
We would like to specifically point out that both the left and the right side of the picture are considered important. When in doubt, however, the items on the left should take precedence.
The first value, individuals and interactions over processes and tools, tells us that we don’t want big processes where humans are mere cogwheels. We would instead like people to work together, using processes and tools to get stuff done. In other words, people should be in charge.
The second value, working software over comprehensive documentation, reminds us that when all is said and done, the customer wants working products and services. Documentation has a tendency to become old and out of date.
It’s important to remember that the word “documents” here is not limited to user handbooks, but also includes design documents, code comments, project plans, progress reports and so on.
As an aside, software testing consists of a lot of repetitive, scripted actions. As it turns out, computers are extremely good at performing repetitive, scripted actions orders of magnitude faster and cheaper than humans (and with fewer mistakes). Testing is therefore a prime candidate for automation. There are ways of writing test specifications so that they are readable by humans but also executable by computers; this way the test cases are the documentation.
The third value, customer collaboration over contract negotiation, means that we prefer to work with the customer in order to identify and react to both opportunities and risks. It often happens during a project that we find better, simpler or faster ways of realising a goal, but just as often the opportunity is dismissed because it’s not what the customer ordered. We should spend our energy on working with the customer to get this done, rather than wrangling over whatever was written in the original contract.
Because we learn more about the product as we build it, we will never know less than at the beginning of the project. That is probably the worst the point in time to make detailed specifications.
The fourth value, responding to change over following a plan, means that we need to shift our focus from the plan to the activity of planning. When people sit down for a planning session, they look at the current situation and agree on what to do about it, and then for a little while everyone is aligned and on the same page. This is something we want more of.
Oftentimes these planning activities produce documents and artefacts such as project plans, backlogs, risk lists and various specifications and designs. These are initially assets (as long as people are aligned with the documents), but reality will quickly start deviating and eventually the documents become liabilities instead. And while these documents are important, we should prefer the activity over the outcome.
RingCentral敏捷教练
不懂技术的产品经理不是好教练！
长按二维码关注