反模式是什么? 这是一种模式，你认为会改善事情，但事实上却相反，它使事情更糟糕了。 本文下面叙述了一些我所观察到的反模式。
The product backlog does not result in a working component. The best method of measuring an Agile project is in the working software. Something needs to be running at the end of each interval (Sprint) and be production ready. That way, everyone along the SDLC is working on getting something done earlier. Developers develop a working instance; no matter how primitive, testers can test that primitive instance (with caveats). Documentation is done, and at the end, there is always something of shippable quality.
The product backlog is not prioritized or is prioritized in multiple streams even if they require the same skill set, i.e., the items in the backlog are assigned to individuals, not the team. This again takes ownership of the development from the team, and the individual especially if the way the task is to be executed is dictated rather than worked out.
在Scrum里有两个计划会议： Sprint Planning 1和Sprint Planning 2。Sprint Planning 1是用来和产品负责人一起过一遍待办事项，并决定团队成员在这个Sprint里该接受哪个用户故事或任务？这就给团队成员提供了产品背景，所以他们对一个任务持续多长时间会有第一想法。这能让每个团队成员都有产品主人翁的意识。
The second Sprint planning session is where the team deep dives into the stories and does the nitty gritty design. Granular tasks are determined and this is where you get the cards for the Sprint. It also serves the purpose of making sure that everyone on the team is across the details of what is happening. It allows team members to contribute to tasks even if they are not involved directly with the task. This also gives the team a sense of ownership in the execution of the task.
The antipattern lies in when management or the team thinks that they know what they are doing and decide they do not need a planning session or they need minimal planning. This could be to save time, reduce meetings, etc. It is actually pretty rare that this is the case and what ends up happening instead is that team members have no idea what is happening during the Sprint. Time gets wasted explaining the situation and sometimes the situation needs to be explained more than once as one team member may ask the same questions as another.
每日站会主要是为了显示每日的工作进度。你需要谈论三个问题： 我做了什么? 我准备做什么?什么事情阻碍了我?
This can lead to failure as the team is no longer empowered. They have no say in the solution and thus mindlessly do the work as required. Yes, it is the Scrum Master's role to protect the team from this sort of thing, but if the Scrum Master has no power and all the power is in the Product Owner, the role becomes moot.
Big Bang Improvement
Another antipattern is big bang improvement. A good example is that you need automated deployment. This has been determined part way through a project. Big bang improvement is spending the next three or more months (in my case 12+ months) developing an automated deployment system without iterative or incremental use by the rest of the development team.
Part of Agile is getting value as soon as possible, even if it's not full value. Having some value early on, even if it's not directly related to the production system, is better than having nothing short-term and everything much later.
You also run the risk that your efforts in getting the big bang solution in place do not live up to scratch and add only a little value in real life.
Another antipattern is delaying improvements until there is slack in the schedule. Slack rarely happens, and more than likely will never happen if you do not include the improvements early. The reason for this is that your technical debt racks up and you spend more time fixing the issues rather than improving.
如果你还没有理解，就去实施敏捷，你会冒着做Cargo Cult Agile(只遵循敏捷开发的仪式而不理解敏捷的实际理念)的风险。
Quality and Definition of Done
An agile antipattern that tends to be done is missing the definition of done or skipping quality checks during the development process.
Quality checks could take the form of not doing unit tests, code reviews, etc. until after development is complete. This could happen days or weeks later and is usually skipped in the interest of time. Why is this a problem? Well, usually, when problems are found out after development, the developer has to get back into the mindset that they were in while developing the feature. This takes time. Then, they have to do the implementation again and recheck.
If the checks are done while development is still in progress, then you save the time that it took the developer to get back into the rhythm. This time saved is usually significantly shorter than the testing task in the first place. There will be a productivity hit initially as you are not used to doing the checks while working, but you will find in the long run that adding the checks actually saves time.
The other antipattern is not defining a definition of done or acceptance criteria. Again, this is left off due to time constraints. But what happens here is that work comes back to the developer because it is incomplete. Why is it incomplete? Well, in this case, the developer didn't know that they had to cater for that situation. Having a definition of done or acceptance criteria gives the developer a perspective on what is required and gives solid checks that they can measure their code by.
In the antipattern, you are stuck in the poverty trap based on time rather than money.
Another antipattern is that of outsourcing. You need a project done. You bring in outsiders to do the project. Once the project is complete, they hand it over to the BAU (Business As Usual) team, which then has the problem of having to understand what has been built. In the meantime, the people that have all the knowledge have long since left.
Another antipattern is buying pretty toys (tools) without knowing what your requirements are just because they look pretty and simple. However, no one ends up using them because they don't meet the use case.
This antipattern is a big one. Communication can kill an Agile project, especially when you are berated for not knowing something. Morale of the person goes down and so does their productivity.
You need to re-think your communication goals. It is not efficient to send out an email if only half your team takes in the knowledge, or do a hand over for something that won't be used for 6 months. The efficiency isn't in the dissemination of the knowledge, but in making sure that the recipient retains the knowledge. this can take the form of a one-on-one session, writing details in a wiki page for future reference (Do not use email - it is a horrible interface for knowledge). Write a tutorial.
If something is discussed at the water cooler, get everyone else together and re-discuss the topic. Even if you don't think it's relevant to someone, it might actually be.
Make sure that everything needed at some future point is documented in enough detail that it can be picked up at a later date, for example, six months down the track. Make sure it's in an easily searchable format such as a Wiki.
Finally, do pair programming or mob programming. This is an excellent method of getting everyone on the same page. You may think that it isn't efficient as you have two or more people doing one task on one computer, but there is nothing better for handover than doing the work together.
Not Making It a Safe Environment
This final lot of antipatterns has to do with not making the environment safe. I don't mean taking care of frayed power leads (although you should take care of those straight away). I mean giving an environment where people can speak their mind without being shut down, where dissent is tolerated or even encouraged if it's relevant to the job.
If you do tell those that have different opinions to shut up, then effectively, they may just do that. Then you lose your most valuable feedback, the check to see if you are doing things correctly or not or if you are going down the wrong route.
These are the antipatterns that I have encountered. If you agree or disagree or have some of your own antipatterns that you have encountered, let me know in the comments.