The whole framework of agile development Knowledge system

Agile Development Engineering Practice
Project Management

• Iterative development

• Risk Value life cycle

• Multi-level project planning

• Full Team

• Daily Standing meeting

• Task Board

• Burndown Chart

Demand management

• Demand Order

• Business Process Sketch

• Use case driven Development

• User Stories

Architecture

• Evolving architecture

• Evolution of Design

• Component-based architecture design

Development

• Pair programming

• Test-driven development

• Refactoring

• Code specification

Test

• Unit Test

• Parallel testing

• Test management

Change Management

• Continuous integration

• Auto Build

• Team Change Management

Agile Development Management Practice Description

• Definitions and feature descriptions

• Main role

• Key activities and best practices

• Primary input and output

• Work flow

Practice description of Agile Development Engineering

• Definitions and feature descriptions

• Application Notes

• Case description

Core values and principles of agile developmentAgile Software Development Manifesto

Individuals and interacting with software above the process and documentation work more than detailed documentation customer collaboration is higher than the contract negotiation response changes over the compliance plan that is, even though the right has its value, we attach more importance to the value of the left. 12345

Core values of Agile software development

The core idea of agile development is to quickly target in the simplest and most effective way, and respond to the changes in time and make rapid adjustments in the process.

Core Values

• - oriented

• Goal-oriented

• Customer-First

• Embrace change

Principles of Agile Development

• Our most important goal is to make our customers happy by delivering valuable software on a continuous and early date.

• Embrace changes in demand, even in the late stages of development. The agile process controls change for the customer's competitive advantage.

• Frequent delivery of working software, separated by weeks or months, tends to take a shorter cycle.

• Business people and developers must work with each other, every day of the project is no exception.

• Inspire individual morale and build projects with them as the core. Provide the required environment and support, supported by trust, to achieve the goal.

• The best and most efficient way to deliver information, whether inside or outside the team, is to talk face-to-head.

• Working software is the primary measure of progress.

• Agile processes advocate sustainable development. The responsible person, the developer and the user should be able to maintain their steady pace and continuity.

• With relentless pursuit of technical excellence and good design, agility is enhanced.

• To be concise, it is the art of trying to reduce unnecessary work.

• The best architectures, requirements, and designs come from self-organizing teams.

• The team regularly reflects on how they can improve their performance and adjust their behavior accordingly.

Agile Development Management practicesScrum

Scrum is an iterative incremental software development process, often used for agile software development. Scrum includes a series of procedural skeletons that practice and pre-define roles. The main roles in scrum include the role of the scrum leader, similar to the project manager, responsible for maintaining processes and tasks, the product owner representing the benefit owner, and the development team including all developers.

Roles in Scrum"Pig" role

• Products Owner (product owner)
  

• Usually by people in the marketing department

• Agile Coaching (Scrum Master)
  

• Usually by the development team leader

• Development team (Scrum team)
  

• including development, requirements, testing

"Chicken" role

• User
  

• Software is created for some people! Like "If a tree in the forest Falls, but no one hears it, does it make a sound", "if the software is not used, is it developed?" ”

• Benefit Owner (customer, provider)
  

• Those who affect the success of the project, but only directly participate in the sprint review process.

• Managers
  

• The person who is setting up the environment for the product development community

Key activities and best practices

• Iterative software Development

• Two-tier project planning (Two-level project planning)

• Overall teamwork (Whole team)

• Continuous integration

• Sprint planning meetings (sprint plan meeting)

• Daily Standing session (Sprint Daily meeting)

• Sprint review session (Sprint Review meeting)

• Sprint review session (retrospective meeting)

Primary input and output

• Products Order (product Backlog)

• Sprint orders (Spring Backlog)

• Burndown Chart (burndown chart)

• New feature Increment

Work flow

Project Management Process

• In the Scrum project management process, the product owner gets the project investment and is responsible for the success of the entire product.

• The product owner coordinates the stakeholder, identifies the initial requirements list and its priorities in the product order, completes the project's business value analysis and project overall planning, and appoints the appropriate agile instructor to carry out the project.

Project development process

In the scrum software development process, each sprint is a shorter iteration, typically 2-4 weeks.

• At the beginning of each sprint, product owners and Agile Coaches develop sprint orders (like iteration plans) by holding sprint planning meetings and best practices for two-tier project planning

• The product owner clarifies the requirements list that is implemented in this sprint and responds to the work tasks and principals.

• In each sprint iteration, the team emphasized the best practices of applying "holistic teamwork", achieving self-organization, self-adaptation and self-management of the team by maintaining a sustainable pace of work and daily stand-by meetings, and completing sprints efficiently.

• At the end of each sprint, the team holds a sprint review meeting where the team members will show the software (or other valuable products) they have developed separately and receive feedback from the product owner and other stakeholders.

• After the Sprint review meeting, the team will consciously open a sprint review meeting, review the entire project process, discuss which methods are good, what can be improved, and achieve continuous, spontaneous improvement of the software delivery process.

XpOpenupLeanAgile Development Engineering PracticeIterative development

Agile iterative development refers to the development of a short period of time in accordance with the same development of the software, or the early development of the software is not exhaustive, each development end to obtain the software can be run, for all stakeholders to observe, to obtain feedback, according to the feedback adaptability of the follow-up development, through the development of fat many times, gradually add software parts Gradually add to improve the software, eventually developed to get the final software. Each time a development is called an iteration, and in scrum it becomes sprint, and Chinese is often translated as "sprint."

Continuous integration

Continuous integration (continuous integration) is when the code is submitted, immediately start automatic compilation, automatically deploy the amount of automated testing to quickly verify the software, so as to find integration errors as soon as possible.

Multi-level project planning

Multi-level project/product planning, in the field of software development, refers to a multi-layered, progressively refined project or product plan based on iterative development. These layers of related project/product planning include:

• Project/Product Vision

• Project/Product Roadmap

• Release plan

• Iteration Plan

• Daily implementation

Project/Product Vision

In the planning phase, first of all, the project stakeholder, the project/product owner will participate in and form a working group, which is responsible for explaining the importance of the project, giving the key criteria for successful failure of the project and defining the "completion" of the project overall level; In the process, you can take advantage of a number of tools that form the vision of the project, including the Vision box (vison box), the Business benefits matrix (benefits matrix), the project scope matrix (scope matrix), the slider (slider), the cost-benefit matrix ( Cost/benefit Matrix), etc.; Finally, the project vision needs to be pinned down with as few documents as possible and guaranteed to be understood by project team members. The documentation needs to include:

• The current problem

• Opportunity Description and justification (describe the importance of the project)

• The value of the project

• How the project agrees with the Organization's strategic objectives

• Solutions Overview

• Key features included in the project

• The technical and restrictive conditions that the project must obey

• Project scope

• Key timelines for projects

• Project Revenue Analysis

• Dependencies on projects and other projects

• The risks associated with the project and how to eliminate

Project/Product Roadmap

It mainly describes the key functions and features that need to be delivered in order to achieve the product vision, which are essentially epic and feature-specific, and do not package user stories. It expresses the support and realization of the vision from the dimension of time. It expresses the support and realization of the vision from the time dimension. The project roadmap is important when the project/product needs to publish multiple versions, otherwise, it is the same as the release plan, and the project/product roadmap is maintained by the project leader and the project manager and is kept up to date. Typically, a roadmap problem or slide is formed, with large icons showing important milestones, features and release dates, etc., so that all project/product stakeholders are aware of the possible release schedules for each component of the product.

Release plan

Release plans are developed by team members and project/product owners and discussed through the release plan meeting. It includes the key features that the current release needs to deliver, which are agreed upon and prioritized, and can include epic and user story. The concepts commonly used in release plans include: Story points, iteration team rate, and priority sorting. Typically, the project/product owner makes the goal of this release, and team members sort the story according to the importance of the goal and feature, and the story points that the release needs to include based on the team rate. Previous releases used estimates that were accurate as the project/product time persisted. The release plan is a plan that adapts to the script and changes as the project evolves.

Iteration Plan

The iteration plan is a refinement of the release plan, which is also developed by team members and project/product owners, and is heard through iteration planning meetings. The Iteration conference is responsible for two things:

• Determine if you need to update the version plan based on the current state

• Develop an iteration plan for the current iteration plan

Concepts commonly used in iterative planning include: splitting Epic and user stories, tasks, task estimates. At the iteration meeting, the member first updates the release plan based on the current project changes, and then makes a detailed task split on the stories that need to be completed for the current iteration based on the updated, reordered story. When a member has finished claiming a task, it estimates the implementation time of the task, and the estimated value needs to be specific to these estimates to make it easier for any member to track the progress of the task.

Daily implementation

It's okay. Implementation is the specific process by which a team member completes a task, which updates the value based on the task estimate and based on the final implementation of the task. In an agile approach, use a daily station meeting to report progress. With 15 minutes of standing, team members report the completion of the story or task, and the problem with the resolution level is dealt with after the meeting.

Full Team

The three integrity that a scrum team must have:

Team responsibility IntegrityProducts Owner (product owner)

• Determine the functionality of the product.

• Determines the date and content of the publication.

• Responsible for the product's benefits (profitability of the products).

• Prioritize functions based on market value.

• Adjust functions and prioritize functions within 30 days.

• Accept or reject the results of the development team's work

Agile Coaching (Scrum Master)

• Oversees the entire scrum project process and adjusts the development plan

• Ensure that team resources are fully available and that they are all highly productive.

• Ensure good collaboration among roles and responsibilities.

• Solve the obstacles in team development.

• As a team and external interface, shielding the outside of the team members of the interference.

• Ensure that the development process is planned, organized Daily Scrum, Sprint Review and Sprint planning meetings.

• You need to know what tasks have been completed, which tasks have been started, which new tasks have been discovered, and which estimates may have changed. According to the above situation update reflects the work done daily and how much has not been completed燃尽图

• Need to identify obstacles and dependencies that hinder scrum and prioritize plans to address these barriers

• Personal problems or conflicts need to be addressed in scrum. These need to be clarified, or resolved through internal communication, or to management and HR to help resolve

• Scrum Master needs to know what tasks have been completed, which tasks have been started, which new tasks have been discovered, and which estimates may have changed. The Scrum master needs to update the work done on a daily basis and how much of the Burndown Chart has not been completed, based on the above situation. Scrum Master must also carefully consider the number of open tasks in progress, and work in progress needs to be minimized to achieve the benefits of lean productivity.

• Scrum master needs to find obstacles and dependencies that hinder scrum. They need to prioritize and track. Specify the plan to address these barriers according to the priority level. Some of these problems can be solved within the team, while others need to be coordinated between teams, and some have to be managed to intervene.

Development team (Scrum team)

• Team members with different strengths, with a population of 5-7 or so, across functions, including development, requirements, testing

• Weaken the division of labor, everyone involved in design, development and testing

• Determine the outcome of your sprint goals and specific instructions.

• Having the right to do anything within the scope of the Project Wizard ensures that the Sprint's goals are met.

• Demonstrate the product features to the products owner.

Team Quality Integrity

• To have a strong spirit of collective cooperation.

• Must have good communication skills.

• Must be able to actively accept new things, to have the ability to innovate

• To have a strong self-management ability and proactive spirit

Integrity of communication

• Sprint startup will

• Daily Standing meeting

• Sprint Review

CaseAcceptance test Driver Development ATDD

TDD is a developer's responsibility to drive the implementation of functional code through unit test cases. Before the ATDD is ready to implement a feature or feature, the team first needs to define the desired quality standards and acceptance rules, with a clear and agreed acceptance test plan (including a series of test scenarios) to drive the developer's TDD practice and test script development for testers. For developers, emphasize how to implement the system and how to test it.

• Pick a user Story

• Write a test for a story

• Implementation testing

• Realization Story

Pair programming

Pair programming can be seen as an agile code Review

New pair Programming

Two programmers new knot pair team, each person a computer, sitting in the adjacent station, the two partners to complete a set of functions (can be two or more independent modules) design, code implementation. But for a certain module design and code is separate, one person is responsible for the design, the other person is responsible for writing code, for other modules and vice versa.

Determine the sprint planDefinition and description

• Purpose: St and PO together determine the goals and requirements for those functions and tasks to be completed during the next sprint cycle

• Main roles: ST, PO, SM

• Key inputs: Product backlog, team capabilities

• Main output: Sprint Backlog

Sprint meeting divided into two parts
1. What needs to be done to resolve this sprint?
2. How the need to resolve these options is to be fulfilled

CaseStory Point estimation

A story point is a unit of measurement that expresses the overall size of a user story, a feature, or a work piece. The value itself is unimportant, and it is important that the comparisons between these stories reflect relative size.

Plan Poker

• At first, the beauty Gets a poker with a task point (?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, Infinity). The representative cannot estimate, the infinity represents the story too big

• Begin to estimate the story, first the PO to describe the story. Then clarify the problem

• Each team member from the poker to choose can represent the story of the card, collective showdown

• Top scores and lowest scores of members like the team to make explanations

• Free discussion of all group members for a few minutes

• Re-score until the whole group is unified.

Agile Estimation 2.0 (Agile estmating 2.0)

• PO like team members introduce each user story to ensure that all requirements related issues are resolved before estimating

• The whole team participates in the game: one person will put a story card in the right place, small size in the left, large scale in the right, the same big vertical row. Move the story cards in turn until the entire team agrees on the sorting of the story cards on the whiteboard.

• The team assigns story points to each story.

Demand order (Product Backlog)

A list of user requirements is recorded, including all required features of the product.

• Each item contains the requirement title, description, importance, story point (or other number representing the size)

• Requirements are open to order, and each member of the team can write and maintain

• Throughout the project's open life cycle, demand orders need to be continuously maintained, managed and tracked for changes in demand

Burndown Chart

A visual representation of the work that needs to be done before the project is completed. Burn story points. Update once a day

• With visibility

• Risk assessment to remind team of current completion

• With measurable, direct display of the current time required.

Burndown Chart FAQsDaily standing meeting (Daily Scrum)

Daily stand-up meetings are designed to allow the team to unify goals and to coordinate internal issues, not progress reports. Generally no more than 15 minutes.

• What did you do after our last meeting?

• What are you going to do before our next meeting?

• How much time is left for each of the tasks you're responsible for?

• Is your work hindered?

Taskpad (Task Board)

• Provide a convenient tool for the project team to manage their work

• Is the team members of this sprint work at a glance

The task board is usually set up on one side of the public space of the project team's daily work. The information on the taskpad includes the user stories and the corresponding tasks that the flushing program completes, unloading the cards separately, and pasting them on the task board in a certain way (to doing, in Progress, done). Team members reflect the performance of the task by adjusting the position of the task card and the information above.

User Story Card

Each card records a user story, a story point.

Task Card

Each user story card corresponds to multiple task cards. Each card records a task and the amount of work (hours) required to complete the task so far. Try updating with progress.

Use of the task boardUser Stories

As a < a role, what I want < to achieve, so that the < brings the value of;.

For example, as a user, I want to be prompted to save before exiting the system so that everything is stored successfully.

Test-driven Development (TDD)

Develop the test case before you develop the code

The whole framework of agile development Knowledge system