- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- Product Owner
- Responsible for Return On Investment (ROI), final arbiter of requirements questions, Focused more on the what than on the how.
- Scrum Development Team
- Attempts to build a potentially shippable product increment every Sprint,
Small team, every one is connected one another.
- Has no management authority,
Doesn't have a project manager role,
- Product Backlog
- Everything we might ever do,
in priority order.
- Sprint Backlog
- What we have agreed to do during the current Sprint, called commited backlog items.
Categorized as: Not Started, In Progress, Completed.
- Sprint Planning Meeting, 4 hours
- Daily Scrum (repeat daily)
- Backlog Refinement Meeting, 2 hours. Prepare and refine the Product Backlog for the next Sprint Planning Meeting since most Product Backlog Items initially are too large and poorly understood.
- Sprint Review Meeting, 2 hours
- Sprint Retrospective Meeting, 2hours. What went well, what could be improved.
- SRS: Software requirements specification.
Ref. A product backlog will contain a range of requirements:
- Epics - very top-level requirements or objectives e.g. A new website
- Themes - very large user stories e.g. A new website section
- User Stories - an Independent, Negotiable, Valuable, Estimatable, Small, Testable ("INVEST") piece of functionality
As products rise to the top of the product backlog i.e. become higher priority, the Product Manager will work with the team to break Themes and Epics into User Stories.
Once broken down into User Stories, the Team will provide delivery estimations and commit to delivering a number of these stories (in line with pre-defined priorities) in the following sprint.
The Product Manager will then begin to define, prioritise and add additional User Stories to the backlog in preparation for the next sprint – this might include new requirements or changes emerging from the previous sprint.
The primary objective of the Product Manager is to deliver value. At a project-level, this value needs to be front-loaded into the development schedule – a side-benefit of this might be a self-funding project scenario. In a product development environment i.e. ongoing development, the value needs to be packed into each sprint.
The backlog should not be confused with a "requirements document".
The backlog should not describe every item at the same level of detail, or "granularity". Features and tasks which are expected to be delivered in the near future should be broken down into fine-grained items and accompanied with details such as acceptance tests, UI sketches, etc.; whereas items planned for a more distant future can be described at a more macroscopic level.
zhihu. 敏捷宣言有两个假设：1. 团队里每个人都具备足够的技能以应对团队面临的技术挑战；2. 团队里每个人都有很好的责任心。如果在你的团队中这两个假设没有被满足，那么与其设立考核制度，莫不如思考一下如何满足这两个假设，因为这两个假设不成立的话，团队是无法敏捷起来的。而如果这两个假设被满足了，为什么还要考核人呢？