1. what is agile
agile is a mindset that refers to a set of methods and related ideas that enable teams to think more effectively, work more efficiently, and make better decisions
2. the four values of the agile manifesto
the four values are meant to discover better ways to develop software by developing it yourself and helping others develop it
1. individuals as well as interactions rather than processes and tools
2. available software instead of full documentation
3. customer cooperation rather than contract negotiation
4. respond to changes instead of following a plan
the items on the right are valuable, but agile values the items in the left column more. a core tenet of the values and principles of the agile manifesto is to emphasize the importance of the individual and interaction. agile optimizes the value stream, emphasizing the rapid delivery of functionality to customers rather than how to "use" people.
3. the twelve principles of the agile manifesto
1. our highest goal is to meet the needs of our customers through the continuous delivery of valuable software this morning
2. welcome to propose changes to requirements, even in the later stages of project development, agile processes should be good at taking advantage of requirements changes to help customers gain a competitive advantage
3. deliver usable software as often as possible, with cycles ranging from a few weeks to several months, and the shorter the better
4. business people and developers must always work together during project implementation
5. be good at motivating project personnel, giving them the environment and support they need, and trusting them to get things done
6. whether it's for the development team or within the team, the most effective way to convey information is through face-to-face conversations
7. the available software is the primary measure of progress
8. agile processes promote sustainable development. project sponsors, developers, and users should be able to keep a steady pace at all times
9. the continuous improvement of technology and the continuous improvement of design will increase agility
10. simplicity, i.e. minimizing unnecessary work as much as possible, is an art
11. the best architecture, requirements and design will come from self-organizing teams
12. the team should regularly reflect on what can be done more effectively and adjust the team's behavior accordingly.
4. benefits of agile solutions
1. agile projects can be completed on time, bringing the gospel to teams struggling with delivery deadlines and budgets
2. agile projects deliver high-quality software, and teams that are stuck in bugs and inefficient software will usher in a huge change
3. agile teams build code that is well-structured and easy to maintain, and teams that often maintain responsible and messy code are relieved
4. agile teams will keep users happy and no longer deliver software that doesn't bring value to users
5. on top of that, in a great agile team, developers don't have to work overtime and can spend evenings and weekends with friends and family
5. the lifecycle type of an agile project
1. predictive lifecycle: this is a more traditional approach where a lot of planning work is done in advance and then executed at once; execution is a continuous process
2. iterative lifecycle: this approach allows feedback on unfinished work to improve and modify that work
3. incremental lifecycle: this approach provides customers with individual completed, potentially immediately available deliverables
4. agile life cycle: this method has both iteration and increment, which is convenient for perfecting work and frequent delivery, which is characterized by its simultaneous use of iteration attributes and incremental characteristics. when teams use agile methods, they iterate on the product to create the finished deliverables. the team will receive early feedback and provide customer visibility, confidence and control over the product. because teams can release products early, and teams will be the first to deliver the most valuable work, projects can generate a return on investment earlier.
6. the project manager applies servant leadership
when working on agile projects, the role of the project manager shifts from the center of the team to the team and managers providing services. in an agile environment, project managers act as servant leaders whose focus shifts to guiding those in need, facilitating team collaboration, and aligning with the needs of interested parties. as servant leadership, project managers are encouraged to assign responsibility to team members and to those who have the knowledge needed to complete the task.
characteristics of servant leadership:
1. promote self-awareness; 2. listen; 3. serve the team; 4. help others grow; 5. guide and control; 6. promote safety, respect and trust; 7. promote the energy and intelligence of others. 8. remove organizational barriers
project managers need to be good at motivating project personnel, providing them with the environment and support they need, and trusting them to get the job done.
7. project charter
features:
1. why are we doing this project? this is the project vision.
2. who will benefit from this? how can i benefit? this may be part of the project vision and/or project objectives.
3. for this project, what conditions are met to mean that the project is completed? these are the publishing criteria for the project.
4. how will we work together? this illustrates the expected workflow.
having a project charter is a great way to get started. in addition, team members may want to collaborate to understand how they will work together.
8. team charter
1. team values, such as sustainable development speed and core working hours;
2. how to define a work agreement, such as "ready", which is a prerequisite for the team to accept the work; how to define "done" so that the team can consistently judge the completeness; consider the time box; or use work process restrictions;
3. basic rules, such as rules relating to a person speaking at a meeting;
4. team specifications, such as how teams treat meeting times.
9. common agile practices
9.1 review
retrospective is one of the most important practices because it allows teams to learn, improve, and adjust their processes.
retrospectives can help teams learn from previous product development efforts and their processes. one of the principles behind the agile manifesto is: "teams should reflect regularly on how they can be more effective and adjust their behavior accordingly."
teams can benefit by allocating enough time to learn, either in the middle of a project or at the end of a project. teams need to understand their work products and work processes. for example, some teams have difficulty getting their work done. teams can plan to spend enough time organizing retrospectives to collect data, process it, and decide which experimental practices to try later.
first and foremost, retrospectives are not blame; retrospectives are allowing teams to learn from previous work and make small improvements.
review qualitative (human feeling) and quantitative (metric) data, and then use that data to find root causes, design countermeasures, and develop action plans. there are many action items that project teams can take to remove obstacles.
9.2 to-do list preparation
the to-do list is an ordered list of all work that is presented to the team in the form of a story. before the work begins, you don't need to create all the stories for the entire project, just understand that the main content of the first release is correct, and then you can develop enough projects for the next iteration.
the product owner (or product owner value team, which includes the product manager and all relevant product owners in the product area) may make a product roadmap that shows the expected sequence of deliverables. the product owner re-charts the roadmap based on the team's actual results. (see annex x3, "agile suitability filtering tool," for an example of a roadmap.) ）
9.3 refinement of the to-do list
in iteration-based agile, product owners often work with the team in one or more meetings in the middle of an iteration to prepare some stories for upcoming iterations. the purpose of these sessions is to refine enough stories for the team to understand what the story is about and how they relate to each other.
9.4 daily stand-up meetings
team members use the daily station to make small commitments to each other, identify problems, and ensure that the team's work runs smoothly. the time box is set for the daily station meeting, which does not exceed 15 minutes. the team somehow "over" the kanban board or task board, and anyone on the team can host a standoff.
in iteration-based agile, everyone takes turns answering the following three questions:
a. what have i accomplished since the last stand-up meeting? b. what do i plan to accomplish between now and the next meeting? c. what are my obstacles (or risks or problems)?
9.5 presentation/judging
the general guideline is to present the team's work product at least once every two weeks. this frequency is sufficient for most teams so that team members can get feedback and prevent them from moving in the wrong direction. this frequency is also frequent enough that the team can keep product development clear enough to build a complete product at the frequency they want or need.
9.6 planning for iterative agile
agile teams don't plan only once in a block of work. instead, agile teams start planning a little, delivering, learning, and then replanting more in a continuous loop.
9.7 executive practices to help teams deliver value
the following helps the team deliver as quickly as possible:
1. continuous integration. regardless of the product, work is frequently integrated into the overall and then retested to make sure the whole product is still working as expected.
2. test at different levels. use system-level testing for end-to-end information and unit testing for building blocks. in between, learn if integration testing is needed and where. the team found that the smoke test helped test whether the working product was good. the team found that deciding when and which products to run regression tests could help them build performance well while maintaining product quality. agile teams have a strong preference for automated testing, so they can build and maintain momentum for delivery.
3. Acceptance Test Driven Development (ATDD). At ATDD, the entire team comes together to discuss acceptance criteria for a working product. The team then creates tests, which allow the team to write enough code to automate tests to meet the standard requirements. For non-software projects, consider how to test the work as the team accomplishes a lot of value.
4. Test-driven development (TDD) and behavior-driven development (BDD). Writing automated tests before writing/creating a product can actually help people design products and protect against product errors. For non-software projects, consider how to pass the "test-driven" team's design. Hardware and mechanical projects often use simulations for intermediate testing of designs.
5. spying (timebox study or experiment). snooping is useful for learning and can be used in processes such as assessment, definition of acceptance criteria, and understanding user behavior through products. spying can be helpful when the team needs to learn some key technical or functional elements.
10. SCRUM ITERATIVE INCREMENTAL SOFTWARE DEVELOPMENT PROCESS
Scrum is a single team process framework for managing product development. The framework includes Scrum roles, events, artifacts, and rules that take an iterative approach to delivering work products. Scrums are time boxes that run on 1 month or less and contain multiple sprints of consistent duration that result in potentially publishable product increments. Table A3-1 lists the Scrum events and artifacts utilized in project execution.
The Scrum team consists of a Product Owner, a Development Team, and a Scrum Leader
the product owner is responsible for maximizing the value of the product.
a development team is a cross-functional, self-organizing team whose development members have all the resources they need to deliver work products without relying on other resources outside the team.
The Scrum Lead is responsible for ensuring that the Scrum process is supported and that the Scrum team adheres to practices and rules, and that the team is guided to remove obstacles.
11. extreme programming
Extreme programming (xp) is a software development approach based on frequent lead times. the name is based on the idea of distilling a particular best practice into its purest and simplest form and then applying it continuously throughout the project lifecycle.what gets the most attention about xp is promoting a full set of practices designed to improve the outcomes of software projects. the method initially contained twelve main practices, but gradually evolved to employ a number of other inferential practices.
this evolution is the result of designing and adopting technology by sifting through core values (communication, brevity, feedback, courage, respect) and based on information based on key principles (humanity, economy, mutual benefit, self-similarity, improvement, diversity, reflection, processes, opportunities, redundancy, failure, quality, step-by-step, responsibility).
12. other keywords of agile
lifecycle/phase: the vision ----------- product roadmap ----------- release plan ----------- iteration
SM/PM ROLE: SERVICE/SERVANT LEADERSHIP, MAINTAINING AGILE METHODOLOGIES/PROCESSES/TEAMS
INTEGRATION: AGILE METHODOLOGY FRAMEWORK (IPECC)
Change: Added to the Product Backlog
Requirements/Scope/Features: Prioritization of product backlogs, user stories, MoSCoW, etc
progress: story point estimation, iterative burndown chart, product ignition chart
COST: S-CURVE
Quality/Bug/Vulnerability: DoD. Major defects in acceptance ----- continuous integration to avoid
resources/teams: self-organizing teams, virtual teams (sun principles, fish tank window)
communication: information transmitter source, four meetings/ceremonies
stakeholders: review/presentation
risk: information emission source, risk burndown map
13. agile transformation steps
it can be divided into the following steps:
1. develop an implementation strategy
2. build a transformation team
3. construct rituals and cultivate enthusiasm
4. identify a pilot project
5. determine metrics of success
6. adequate training
7. develop product strategy
8. develop product roadmaps, product backlogs and estimates
9. run your first sprint
10. make mistakes, collect feedback, and improve them
11. mature
12. promotion
if it helps you, if you want to walk by, raise your hand and give a thumbs up
No comments:
Post a Comment