2019年3月3日：开源日报第353期

开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。

今日推荐开源项目：《色彩 ColorUI》

今日推荐英文原文：《Why deadlines and sprints are bad for you》

今日推荐开源项目：《色彩 ColorUI》传送门： GitHub链接

推荐理由：一个小程序 UI 组件库，最大的特点是鲜明的颜色。这已经是这个库的 2.0 版本了，增加了更多的配色，如果你正在寻找一些具有鲜明颜色的组件的话它会是一个好的选择。不过它升上 2.0 的时日尚早，在线文档还没有编写完成，如果想要寻找文档的话只能去它提供的 demo 中学习了。

今日推荐英文原文：《Why deadlines and sprints are bad for you》作者：Antti

原文链接：https://medium.com/@niant/why-deadlines-and-sprints-are-bad-for-you-7ee87be5d0f0

推荐理由：赶 DDL 是一种动机，但是也是一种危害

Why deadlines and sprints are bad for you

The development team’s capabilities for battling deadlines are fairly restricted

In a software development project, it’s important to find a suitable process for the project. A good process helps developers, managers, customers and users. A great process should improve the day-to-day life for everyone involved and help avoid generating problems or health issues.

In this article, I’m mainly focusing on fairly long agile projects that continue over multiple years, though these principles or opinions may apply to shorter projects as well.

Roles in the team

A software project team typically consists of a mix of software developers, UX designers, graphic designers and a product owner. The roles can be roughly split in two: development and product management. Product management steers the development team towards building the “right stuff” at the correct time and attempts to ensure the continued relevance of the product. The development team, on the other hand, decides how to build the “right stuff” and how to deliver it. In addition to this, the development team is responsible for ensuring the software is usable and for validating the overall quality of the product.

In short:

• Product management: What should we build? When should we build it?
• Development: How should we build it? How should we deliver it?

Sprints create deadlines for short cycles

During recent years, agile development has been rising in popularity. It also made SCRUM famous as a process method, so much so that some use it as a synonym for agile development.

One of the key elements in SCRUM is sprints. A sprint is a time-boxed iteration of development (usually lasting from one to three weeks), during which the team focuses on a set of tasks planned at the start of the sprint. At the sprint planning, the team takes the highest priority items from the backlog (work queue mostly managed by product management), plans them, and commits to an amount of work they think they can deliver. At the end of the sprint, there’s usually a review meeting about what was done.

This system generates multiple short deadlines for the project. In essence, sprints force deadlines into people’s everyday work regardless of the length of the project.

This commitment to sprints generates multiple problems. In order to commit to the amount of work, the team now needs to assess, for instance, the following factors:

• How much effort goes into each task?
• Is someone going to be on a personal leave during this time?
• Is everyone 100 percent committed to project-related work or are there some other + responsibilities on the side? Training? This week or always?
• How many sick days are there going to be in the sprint?
• How many bugs is the team going to come across during the sprint? How difficult will they be + to solve?
• Is someone leaving or joining the team?
• Are there any company events during the sprint?
• Are national holidays going to affect the sprint?
• Are there any hardware issues going to come up?

While these assessments can be made easier with statistics: “Generally, we get this much work done per sprint”, and so forth. The bottom line is this: There’s a wide range of variables that cause the output to vary over different sprints. Sometimes you hit the goal and sometimes you don’t. But you do have a goal, a deadline.

Some think that sprint commitment is not necessary (disregarding SCRUM process to some extent) and that sprint should not be thought as a deadline. I like the idea in theory, but in practice, people end up confusing sprints to deadlines regardless of the intention. Especially when sprint commitment is supposed to be an instrumental part of the SCRUM process by default.

Even the semantic idea of the word “sprint” is ill-advised for a long project. It suggests a mentality of a 100-meter sprint running to do whatever it takes to get to the finish line as fast as possible. A long software project is more accurately compared to a 50-kilometer run that is won with a steady pace, and during which overexertion at any midpoint ruins the whole run or sends you to a hospital. In long projects, people might not even know where the finish line is. Sprint seems more like a marketing term that shouldn’t be used as a term for a method of working in the first place.

Deadlines in human health

Deadlines can have multiple effects on humans. Especially when they are closing in. Some of them include health risks such as increased stress, loss of brain cells, lessening creativity, digestion issues, headaches, etc. When deadlines are closing in, the human body may eventually feel threat to its survival and trigger the fight or flight response. (Source: Psychology Today, The Dark Side of Deadlines)

Other effects include motivational enticement. There are studies that show deadlines can have a positive effect on work motivation. I would argue that there are other more worthwhile and less damaging motivational enticements in existence as well. Just to list a few to get you started:

• Creating an awesome product
• Delivering good quality
• Improving people’s lives
• Helping people with their problems
• Making people happy Deadlines can even undermine the motivation generated by other motivational enticements. (Source: Psychology Today, How deadlines can be murder on motivation)
  Additionally, the stress caused by deadlines “sets up a vicious feedback loop and keeps a person dependent on deadlines like a caffeine junkie reaching for their morning cup of joe.” For some people, meeting a deadline gives such an adrenaline rush that next time they may put off a task until they get physical symptoms of the fight or flight response. (Source: Psychology Today, The Dark Side of Deadlines)

Deadlines in software projects

How many times have you heard these explanations before?

• We had to skip tests…
• We had to add technical debt…
• We could not fix the code…
• We had to do it quickly…
• We couldn’t design it properly…
• We had to take a shortcut…

Too often these sentences end with …because we didn’t have enough time. Why didn’t people have time? There’s probably multiple reasons, but in the end, it often comes back to deadlines, right?

People will try to cut corners, produce lower quality and take risks while disregarding their own health to meet deadlines. (Source: ISHN, Deadlines can erode safety and promote risk-taking)

The deadline is closing in and we’re late, now what?

As mentioned earlier, the variables often lead to unpredictability and the project ends up missing the deadline. So what can be done now?

• Cut corners (lowers quality)
• Work overtime
• Skip or forbid team other responsibilities like training
• Forbid personal leave
• Reduce the number of features
• Refine the feature scope
• Hire more team members
• Move the deadline

Cutting corners usually ends up damaging product quality and generating loads of technical debt. This type of debt has a very high interest rate, and the project will have to pay it sooner or later. The worst case scenario is that it causes bugs in the production environment, which can be extremely costly.

Making people work overtime or denying leave (essentially meaning rest), on the other hand, might lead to a range of health issues and other problems in life management.

Denying or skipping other responsibilities, such as employee training, is another form, a more slowly moving type of technical debt: It will eventually result in people with outdated skills and a project that will not benefit from new skills.

The development team’s capabilities for battling deadlines are fairly restricted

In simple terms:

The tools the development team has for combatting the deadline are unsustainable:

• Cutting corners (essentially lowering quality)
• Working overtime
• Skipping training or other responsibilities

Product management controls the only sustainable options:

• Reducing the number of features
• Refining the feature scope
• Hiring more team members
• Moving the deadline

The above categorization means that management could resort to the unsustainable options as well, if required. I believe that it is far better if management makes that choice knowingly rather than have individuals within the team make this choice on their own. These individual responses to deadlines are exactly at the core of the issue: they generate invisible problems that jump at you unpredictably.

Well, what choice do we have?

Instead of SCRUM, there’s another similar process called Kanban (Lean development) that does not have the concept of sprints and time-boxing, because in Kanban, they are considered a waste.

In Kanban, there’s only the “stuff” to be done, and the development team should do it in the order prioritized by product management. It’s a very continuous process that fits naturally into long development projects. There is no need to use time on discussing commitments, dates, deadlines or anything related to sprints. More importantly, the system does not generate deadlines or deadline-like systems so the stress of having deadlines is removed. Rather, when a task gets done, the development team takes the next task from the top of the backlog and so on.

The Kanban (Lean) process removes a number of unnatural things that SCRUM, in turn, entails.

For instance:

• What happens when a sprint is completed early?
• What happens when a sprint is not completed in time?
• What happens when bugs emerge during a sprint?
• What if we can’t plan enough at a sprint planning?
• What if we plan too much at sprint planning?
• What if we want to release before the end of the sprint?
• What happens if product management really wants to re-prioritize during a sprint?
• What happens if everything is not ready for development at the start of the sprint?

These questions can be answered with more processes or steps and guidance. In Kanban however, many of the questions are not even applicable because they are not necessary in order for us to get the project done — it’s just noise.

Conclusion

Deadlines have a lot of negative impacts on human health, but some say they are a must-have for work motivation and for project organization. I argue that there are other motivational enticements and other ways to organize projects than deadlines and sprints. This takes me to my main argument, which is that the negative impacts of deadlines and sprints outweigh the positive impacts.

SCRUM as a popular agile framework brings us a bunch of deadlines to our day-to-day life in form of sprints. Teams end up committing into sprint content, with no sustainable tools to manage it. Some say sprint commitment is not necessary, and a sprint should not be thought as a deadline. I’m inclined to agree, but then again, I ask you this: Why have it in the first place?

Sprints and time-boxing add a lot of artificial noise to a project. That noise has few major undesirable side-effects, the biggest ones being the possible life-threatening health issues and unsustainable teams and projects. In the end, there are other ways to work (like Kanban) that do not have this noise and give more flexibility in return, too.

If the stakeholders and product owners are not ready to pull the plug on deadlines, product management might be left to play with them on some level. Development teams should not be dealing with deadlines, since they don’t possess the tools to manage them. Rather, the team should focus on the delivery of the tasks and make sure they are delivered in the order that product management sees fit. One could think of it as a layer of protection for the development team. In this case, a team might need to give out estimates on how long each task takes, but that’s still very different from committing to a deadline.

下载开源日报APP： https://openingsource.org/2579/

加入我们： https://openingsource.org/about/join/

关注我们： https://openingsource.org/about/love/