Agile Development Engineering Practice
Project Management
Demand management
Architecture
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
Practice description of Agile Development Engineering
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)
Agile Coaching (Scrum Master)
Development team (Scrum team)
"Chicken" role
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:
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)
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