Agile笔记摘录

An agile mindset is about opening up planning, design, and process improvement to the entire team.

A good developer almost always has opinions not just about his own code, but about the whole direction of the project.

Sometimes you need to see the same concept more than once before you get that “aha!” moment.

Trying to put a practice in place on a team with an incompatible mindset can end badly.

We are what we repeatedly do. Excellence, then, is not an act but a habit.

Manifesto for Agile Software Development:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Waterfall really can work. In fact, if you actually know what you need up front, then writing it down first is a pretty efficient way to build software.

A waterfall process requires a team to write down a complete description of the software at the beginning of the project, and then build exactly what they wrote.The waterfall process made it difficult to respond to change because of the focus on documentation rather than collaboration.

A user story is a way to express one very specific need that a user has.

Working software is software that adds value to the organization.

Documentation that helps them understand the problem, communicate it with the users, and correct problems before they make it into the software is documentation that saves more time and effort than it costs.

One way agile teams put this value in place is to have a product owner who is a real, first-class member of the team.

Product backlog, a list of requirements for the software. The requirements for the current sprint are called the sprint backlog.

Using simultaneous phases, an XP team produces deployable software every week.

Lean is not a methodology. Rather, it’s a name for a mindset.

Kanban is an agile method for improving the way that a team builds software. It’s built on the values of Lean.

All agile methodologies are based on the same principles, and they all rely on everyone on the team to work together and collectively own every aspect of the project. The Scrum teams, for example, typically spend a whole eight-hour day planning for a 30-day iteration.

This first principle includes three distinct and important ideas: releasing software early, delivering value continuously, and satisfying the customer.

Principle #2: Welcome Changing Requirements, Even Late In Development. Agile Processes Harness Change for the Customer’s Competitive Advantage.The first step toward welcoming changing requirements is to try to see things from the customer’s perspective. Nobody gets in “trouble” when there’s a change. We’re all in this together. We don’t sit on change until it’s too late. We stop thinking of changes as mistakes. We learn from the changes. Agile teams satisfy their customers by getting feedback early in the project, and continuously delivering software to keep that feedback up to date

#4: The Most Efficient and Effective Method of Conveying Information To and Within a Development Team Is Face-To-Face Conversation.This is why teams that deliver working software frequently should prioritize the most valuable features first by doing a real product demonstration that shows everyone exactly what the team did, they keep everyone up to date on the progress of the software in a way that is almost impossible to misread.

In fact, teams that work extreme amounts of overtime for an extended period actually deliver less work than teams that work normal, sane hours — and it’s usually of lower quality. Simplicity — the Art of Maximizing the Amount of Work Not Done — Is Essential. The most destructive thing you can do to your project is to build new code, and then build more code that depends on it, and then still more code that depends on that, leading to that painfully familiar domino effect of cascading changes...and eventually leaving you with an unmaintainable mess of spaghetti code. If a feature is not valuable, it’s often cheaper for the company in the long run to not build it at all.

The only way to become more capable as a team is to constantly look back at what you’ve done so far, to assess how well you’re working as a team, and to come up with a plan for getting better.

Sit down with individual team members and talk about their jobs. What motivates them? What frustrates them? What drives the decisions they make?

The Product Owner works with the rest of the team to maintain and prioritize a product backlog of features and requirements that need to be built. The Scrum Master, keeps the project rolling by working with the team to get past roadblocks that they’ve identified and asked for help with.

The team can only present functional, working software, not intermediate items like architecture diagrams, database schemas, functional specs, etc.

Many inexperienced project managers make the mistake of thinking that once a task is written into a plan, the team is automatically committed to it. Did you always consider your own success or failure truly dependent on that project’s success? People on an effective agile team — all pigs — genuinely feel that in order for them to succeed, their project needs to succeed. While you’re working on a sprint, making the project successful is more important than any other professional goal that you have. On the other hand, every software project needs chickens. For example, every user is a potential chicken. One of the most effective ways that they have to do this is to release working software to their users on a regular and predictable schedule. Correcting a chicken attitude among the team is one of the most difficult barriers to Scrum adoption that Scrum Masters face. A Scrum Master can help encourage team members to be pigs by treating estimates as facts that have yet to be uncovered, not commitments to be wrung from the team. Effective Scrum teams can decide during the sprint who will do which tasks, based on which people are available and the skills that they can bring to the task.

Five Scrum values: courage, commitment, respect, focus, and openness.

Switching between projects, or even between unrelated tasks on the same project, adds unexpected delays and effort, because context switching requires a lot of cognitive overhead.

It functions as an inspection of the work that the team is doing, so they can adapt that work to deliver the most value. And it gives the team the opportunity to make decisions at the last responsible moment, giving them the flexibility to have the right person do the right work at the right time. The best way we have for users to judge whether or not the team is building valuable software is to put working software in their hands as frequently as possible. The daily cycle of visibility, inspection, and adaptation allows teams to continuously use feedback from their projects to improve how they build software. The point is that the team members themselves are the source of the task assignments. Each person self-assigns her next task as soon as she’s done with the current one. They make all decisions at the last responsible moment. Take detailed conversations offline. Take turns going first (It turns out that talking to users, understanding their business, and managing that backlog really is a full-time job, and the developers respect that job more when they see that firsthand!) Use that knowledge of value, difficulty, uncertainty, complexity, etc. to help the team choose the right features to build in each sprint. It’s always better to be conservative about what commitments were delivered. When teams are motivated effectively, it’s because they’re organized around an elevating goal. And so the leader’s job, really, is to try to determine or frame the activity in such a way that people can understand what the value is. Delivering value can be a very effective elevating goal, one that can motivate the whole team. Software is valuable if it makes your users’ lives better. All members of an agile team, even ones who don’t necessarily write code — are highly motivated by pride of workmanship. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. The difference is that they deal with dependencies at the last responsible moment, Collective commitment means genuinely trying to make your software more useful. And the most effective way that we have of building working software is customer collaboration.

As a <type of user>, I want to <specific action I’m taking> so that <what I want to happen as a result>. Conditions of satisfaction are an effective tool for helping developers to know what the software will look like when it’s complete, and to gauge how close they are to done. It’s OK to leave room in the backlog, but it’s not OK to go beyond what your team has done in the past. Estimation is a skill, and the only way to get better at it is to practice — which, in most cases, means talking about how much effort certain tasks will need. Instead of trying to prevent those mistakes, he took advantage of them to create learning experiences for the team. This is called letting the team fail, and it’s a basic element of coaching. Teams that fail together and recove together are much stronger and faster than ones that are protected. The team needs a culture where it’s OK to make mistakes. The best way to do this is to lead by example: show everyone around you what it means to be open about your work, have respect for others on your team, and show courage when you run into problems. They inspect the plan for problems every day at the Daily Scrum meeting. Many effective Scrum teams block out at least an hour every week to work with the Product Owner to update the backlog (some teams call it “grooming”). Product Owners discover new potential features all the time. Everyone sucks at planning, at least at first. We review, inspect, and adapt the plan every day, so that we can react quickly when (not if) the plan turns out to be wrong. One way that Scrum teams deal with this is to break their global teams up into smaller Scrum teams that are collocated. The hardest part about global teams is that it’s very difficult to keep every single team member motivated with shared elevating goals.

What did WE achieve yesterday on Priority 1? What was OUR contribution on Priority 1 worth in Story Points? What is OUR plan for completing Priority 1 today? What, if anything, is blocking US or has the potential to slow US down today?

One of the biggest coaching challenges is helping the team to really understand collective commitment.

People really hate change. They really, really do. By writing automated tests before writing the code that gets tested, teams establish a higher level of quality in their software. Working in pairs, with two developers at a single workstation, helps get more eyes on the software to catch bugs before they’re built into the code. When a programmer does test-first programming, also known as test-driven development (or TDD), it means that before he writes code, he builds an automated test. 10-minute build: the team creates an automated build for the entire codebase that runs in under 10 minutes. This build includes automatically running all of the unit tests and generating a report of which tests passed and which failed. However, instead of self-organizing, some XP teams will stack up all of the tasks for the iteration and have each developer take the next task in the stack when his current task is done. XP teams use the quarterly cycle practice to do long-term planning. The first is sit together. Visible, always-in-your-face charts and other things that teams use to display data and make the workspace more informative are called information radiators. The more information about the project is shared, the more each individual on the team is able to influence the direction of the project. The thing that agile methodologies — and XP in particular — do really well is admit up front that we don’t know exactly what we’re going to build, and that the most efficient way we have of figuring this out is to build it. An XP team doesn’t just treat changes as a necessary evil; they recognize that the only way they can build the best software for their users is to get feedback often and respond to that feedback quickly. defect injection — is through rework. In fact, early versions of the software actually spark some of the best brainstorming. A team that’s afraid of making changes is a team that stifles innovation from the bottom up. Quality isn’t just about avoiding bugs. It’s about giving users software that meets their needs — even if that software isn’t exactly what they originally asked for. The “trick” that XP pulls is forcing the developer to think like a user — starting with having the developer actually talk to the users. In other words, BRUF lets you build what you intended. XP helps you build what your users actually need. Where Scrum is all about making sure that your customers know what you can produce and what you can’t, XP is about making it possible for you to make changes as quickly and as defect-free as possible. Communication Each team member is aware of the work everyone else is doing. Simplicity Developers focus on writing the most simple and direct solutions possible. Feedback Constant tests and feedback loops keep the quality of the product in check. Courage Each team member is focused on making the best choices for the project, even if it means having to discard failing solutions or approach things differently. Respect Every team member is important and valuable to the project. “Practices by themselves are barren. Unless given purpose by values, they become rote.” Humanity Remember that software is built by people, and there’s a balance between the needs of each team member and he project’s needs. Economics Somebody is always paying for software project and everybody has to keep the budget in mind. Mutual benefit Search for practices that benefit the individual, the team, and the customer together. Self similarity The pattern of a monthly cycle is the same as a weekly cycle and the same as a daily cycle. Improvement Do your best today, and stay aware of what you need to do to get better tomorrow. Diversity Lots of different opinions and perspectives work together to come up with better solutions. Reflection Good teams stay aware of what’s working and what isn’t in their software process. Flow Constant delivery means a continuous flow of development work, not distinct phases. Opportunity Each problem the team encounters is a chance to learn something new about software development. Redundancy Even though it can seem wasteful at first blush, redundancy avoids big quality problems. Failure You can learn a lot from failing. It’s OK to try things that don’t work. Quality You can’t deliver faster by accepting a lower quality product. Accepted responsibility If someone is responsible for something, they need to have the authority to get it done. Baby steps Take small steps in the right direction rather than making wholesale changes when adopting new practices. Why doesn’t an XP project have specific roles? This is where XP teams take opportunity and diversity very seriously. Anyone on the team might bring a fresh perspective, and that perspective could be the key to unraveling a tricky problem. For a consulting company, instead of fixing the scope and negotiating time (and, often, sacrificing quality to meet the deadline), fix the time and have an ongoing negotiation of the scope. They focus only on today’s problems, and push everything else off to a future sprint. “Always implement things when you actually need them, never when you just foresee that you need them.” a library is about separating code into small, reusable components. A framework, on the other hand, is about combining many small, reusable pieces into one large system. XP teams refactor mercilessly. A system that’s designed to immediately report a failure as soon as it happens is called a fail-fast system. The most damaging thing you can do is write bad code, and then write more code that depends on it. Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind. Giving the team an energized environment means helping every person on the team to feel like he or she has autonomy. When a system is designed so that its behavior seems to emerge from the interactions between the individual units working together, in a way that doesn’t seem to originate from one single unit, it’s called emergent design. Eliminate waste Amplify learning Decide as late as possible Deliver as fast as possible Empower the team Build integrity in See the whole even though individual people may shy away from commitments (especially under pressure in front of the boss), teams have a tendency to overcommit. Bosses often have a tendency to demand commitment, and teams often have a tendency to overcommit. They’ve only committed to the goal, and can change the tasks at any time to meet that goal more effectively based on any new information that they’ve uncovered. The best software is created when teams work together. Many teams will measure lead time for each feature. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”

“If stupid enters the room, you have a moral duty to shoot it, no matter who’s escorting it.” Kanban is a method for process improvement used by agile teams. Kanban is about helping a team improve the way that they build software. The key here is the second part of that sentence: figuring out what those problems have in common. That’s where Kanban starts: taking a look at how you work today, and treating it as a set of changeable, repeatable steps. We always follow rules. The kanban board will have columns for the steps that a work item goes through before and after the Scrum team gets their hands on it. In Kanban, the improvement is left in the hands of the team. In Kanban, visualizing means writing down exactly what the team does, warts and all, without embellishing it. That kanban boards only have stories, and do not show tasks. Limiting work in progress (WIP) means setting a limit on the number of work items that can be in a particular stage in the project’s workflow. Longer lead times seem to be associated with significantly poorer quality.