Changes for page Bill of Rights

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,74 +3,32 @@
1		-# Introduction
2		-
3	3	The purpose of the [Bill of Rights](https://www.informit.com/articles/article.aspx?p=2990402&seqNum=3) is to resolve common disputes between customers and developers by defining a clear, distinct sets of rights and expectations for effective cooperation. Make sure that developers and customers can always visit a bill to resolve disputes that arise during discussions.
4	4
5		-# Commented Bill of Rights
6		-
7	7	### 1. Customer Bill of Rights
8	8
9	9	You have the right to
10	10
11	11	* an overall plan and to know what can be accomplished when and at what cost.
12		-
13		-{{info}}
14		-Developers can't predict the exact amount of work for a story, but they must specify the uncertainties and take steps to mitigate the uncertainties. Example: "80% of the first 10 stories will be done in 5 iterations" or use probability curves.
15		-{{/info}}
16		-
	8	+ * Developers can't predict the exact amount of work for a story, but they must specify the uncertainties. See [[Planning Game|doc:Software Engineering.Agile.Extreme Programming.Planning Game.WebHome]].
17	17	* get the most possible value out of every iteration.
18		-
19		-{{info}}
20		-Developers must work on the features that have the highest level of usable business value. "Usable" means ready to be used effectively by end users.
21		-{{/info}}
22		-
	10	+ * Developers must work on the features that have the highest level of usable business value. "Usable" means ready to be used effectively by end users.
23	23	* see progress in a running system, proven to work by passing repeatable tests that you specify.
24		-
25		-{{info}}
26		-Developers must write acceptance tests that are developed in collaboration with customers.
27		-{{/info}}
28		-
	12	+ * Developers must write acceptance tests that are developed in collaboration with customers.
29	29	* change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.
30		-
31		-{{info}}
32		-Software is always expected to be flexible by design, so functional customization should be affordable. In each iteration, customers have the opportunity to re-prioritize stories and define which stories to implement in the next iteration.
33		-{{/info}}
34		-
	14	+ * Software is always expected to be flexible by design, so functional customization should be affordable. In each iteration, customers have the opportunity to re-prioritize stories and define which stories to implement in the next iteration.
35	35	* be informed of schedule and estimate changes, in time to choose how to reduce the scope to meet a required date. You can cancel at any time and be left with a useful working system reflecting investment to date.
	16	+ * Customers have the right to be informed in time if there is a delay. They then have the right to decide which stories should be dropped from the project scope, so that at least the most important stories are completed by the deadline. Customers do not have the right to demand that developers implement all originally planned stories and meet specific deadlines if the developers estimate that this is not possible.
	17	+ * Because each iteration produces a tested, production-ready and deployable release, customers can technically exit the contract at any time.
36	36
37		-{{info}}
38		-1. Customers have the right to be informed in time if there is a delay. They then have the right to decide which stories should be dropped from the project scope, so that at least the most important stories are completed by the deadline. Customers do not have the right to demand that developers implement all originally planned stories and meet specific deadlines if the developers estimate that this is not possible.
39		-1. Because each iteration produces a tested, production-ready and deployable release, customers can technically exit the contract at any time.
40		-{{/info}}
41		-
42	42	### 2. Developer Bill of Rights
43	43
44	44	You have the right to
45	45
46	46	* know what is needed with clear declarations of priority.
47		-
48		-{{info}}
49		-Developers can ask customers to clarify requirements. Customers have the right to change requirements outside of an iteration, but not within an iteration.
50		-{{/info}}
51		-
	24	+ * Developers can ask customers to clarify requirements. Customers have the right to change requirements outside of an iteration, but not within an iteration.
52	52	* produce high-quality work at all times.
53		-
54		-{{info}}
55		-No developer should be forced to damage their reputation or violate their work ethic by delivering low-quality code.
56		-{{/info}}
57		-
	26	+ * No developer should be forced to damage their reputation or violate their work ethic by delivering low-quality code.
58	58	* ask for and receive help from peers, managers, and customers.
59		-
60		-{{info}}
61		-With the right to ask for help comes the responsibility to give help.
62		-{{/info}}
63		-
	28	+ * With the right to ask for help comes the responsibility to give help.
64	64	* make and update your own estimates.
65		-
66		-{{info}}
67		-Estimates are intelligent guesses, not commitments. Of course, estimates get better over time as new insights are gained.
68		-{{/info}}
69		-
	30	+ * Estimates are intelligent guesses, not commitments. Of course, estimates get better over time as new insights are gained.
70	70	* accept your responsibilities instead of having them assigned to you.
71		-
72		-{{info}}
73		-For each iteration, customers specify the tasks to be done, but developers internally negotiate who does what. Developers have a deeper understanding of the technology and team experience, resulting in a more efficient allocation of resources. An individual developer has the right to say "no" to a task during the negotiation process, due to the availability of better alternatives or a lack of confidence in their abilities, and take on another task instead.
74		-{{/info}}
	32	+ * For each iteration, customers specify the tasks to be done, but developers internally negotiate who does what. Developers have a deeper understanding of the technology and team experience, resulting in a more efficient allocation of resources. An individual developer has the right to say "no" to a task during the negotiation process, due to the availability of better alternatives or a lack of confidence in their abilities, and take on another task instead.