关于可持续软件开发

“Hero” programming only lasts so long.

“英雄”编程只能持续这么长时间。

It’s 9:45 pm on New Year’s Eve. I was supposed to be downtown a few hours ago with a group of friends to and stay up to be part of the Raliegh NYE celebration (which, btw, features an acorn drop).

在除夕晚上9:45。 我原本应该在几个小时前和一群朋友一起去市中心，然后继续参加Raliegh NYE庆祝活动(顺便说一句，以橡子糖为特色)。

Instead, I was on my computer. Hunched over, manually verifying the last of our billing statements were ready to go out. The past day had been an exhausted one. Every process had gone wrong, no one was around due to the holiday, but we had to get statements out.

相反，我在电脑上。 弯腰，手动验证我们的最后一个对帐单是否准备就绪。 过去的一天真是精疲力尽。 每个过程都出了问题，由于假期没有人在附近，但是我们不得不发表声明。

We thankfully did, and everything was fine.

值得庆幸的是，我们做到了，一切都很好。

Except it wasn’t fine.

除非那不是很好。

It wasn’t fine that I was still in the office.

我还留在办公室里不好。

It wasn’t fine that I had broken promises to my friends because of work.

我因为工作而违背了我对朋友的诺言，这是不好的。

It wasn’t fine that we were keeping this system afloat by sheer willpower.

我们靠纯粹的意志力让这个系统运转下去是不好的。

软件开发不应该成为英雄 (Software Development Shouldn’t Be Heroics)

How many of you have worked on a team that always had to be putting in “heroic work” or were always “stepping up to the plate” in 11th-hour situations? Were it was normal for team members to work late, over the weekend, or skip lunch — or all three.

你们中有多少人在一个团队中工作，他们总是在第11个小时的情况下必须进行“英雄式的工作”或总是“站出来”？ 团队成员上班迟到，在周末或跳过午餐是正常的，或者这三者都是正常的。

These teams usually get praised if they hit the deadline, and their achievement is hailed as “grit” or “great work.” If they miss the deadline, though — they are scolded for not making the deadline and wind up working just as long to get in done when they can.

这些团队通常会在截止日期之前获得称赞，他们的成就被誉为“勇气”或“出色的工作”。 但是，如果他们错过了截止日期，他们会因没有按时完成而被责备，并尽可能延长工作时间以尽其所能。

While these situations are nearly inevitable — every team will hit some form of crunch time that requires some extra work — it should be the norm. And it shouldn’t be seen as heroic work.

尽管这些情况几乎是不可避免的-每个团队都会遇到某种形式的紧缩时间，需要做一些额外的工作-这应该成为常态。 而且它不应该被视为英勇的工作。

When teams are constantly in this state of frantic overwork, something is just plain wrong. They aren’t building the right software. They aren’t investing in the right places. They aren’t having the correct retrospectives with themselves or with product owners. Something needs to change.

当团队一直处于疯狂的过度工作状态时，那肯定是错误的。 他们没有构建正确的软件。 他们没有在正确的地方投资。 他们自己或产品所有者没有正确的回顾。 有些事情需要改变。

发展应该是可持续的 (Development Should be Sustainable)

One of the core principles behind the Agile Manifesto is

敏捷宣言的核心原则之一是

Agile processes promote sustainable development.The sponsors, developers, and users should be ableto maintain a constant pace indefinitely.

敏捷过程促进可持续发展，发起人，开发者和用户应能够无限期保持恒定的步伐。

Its often an overlooked one too. Why?

它也经常被忽视。 为什么？

I believe it’s because teams that embrace all the other principles — continuous delivery, short iterations, prioritizing developer efficiency, etc. — leads naturally to a sustainable pace. It also means that if a development team is doing those things well, there can be useful estimates from the team about when they can complete work. This makes product owners happy as their job of predicting features to users, and setting direction for the product is now more straightforward.

我相信这是因为团队遵循所有其他原则-持续交付，短期迭代，优先考虑开发人员效率等-自然会导致可持续发展。 这也意味着，如果开发团队将这些事情做好，则可以从团队获得有关他们何时可以完成工作的有用估计。 这使产品所有者很高兴，因为他们可以为用户预测功能，并且现在为产品设置方向更加简单。

I also think there is a slight tendency for developers to want to be perpetually busy. There is a false sense of meaning that comes from always being busy, isn’t there? Our whole society says that if we are busy or hustling or continually working that we are doing something meaningful.

我也认为开发人员有一种想永久保持忙碌的趋势。 总是忙碌会产生一种错误的意义，不是吗？ 我们整个社会都说，如果我们忙于，忙碌或不断工作，那么我们正在做有意义的事情。

I’m not condemning hard work at all! I am simply saying there are more meaningful things than working long hours to fix a bug on New Year’s Eve.

我根本不谴责辛勤工作！ 我只是说，要解决除夕上的错误，比花很长时间工作还有更多有意义的事情。

到那里怎么走 (How to Get There)

How does one take a team that regularly feels up against the wall or behind and create a sustainable cadence?

一个团队如何定期面对墙壁或后面，并创造可持续的节奏？

I’ll be blunt: it won’t be simple or easy. Chances are you will find that there is pushback from not only the product owners or managers but even pushback from the team. Teams who have lived in this “hero” world might start to think they won’t get noticed or that they won’t be needed. Change is hard.

我会直言不讳： 它不会简单或容易 。 您可能会发现，不仅有产品所有者或经理的回馈，甚至还有团队的回馈。 生活在这个“英雄”世界中的团队可能会开始认为自己不会受到关注或不需要。 改变很难。

In my experience, getting onto a path towards sustainable pace requires a few things:

以我的经验，迈向可持续的步伐需要做一些事情：

1. Admit the team is overworked. This is harder than you might think. Some developers don’t want people they work long hours because they are afraid it means they will look inadequate (i.e., “You had to work the weekend to finish that simple task?”). The team and managers need to agree.
   承认团队劳累。 这比您想象的要难。 一些开发人员不希望他们长时间工作的人，因为他们担心这会使他们看起来不够用(例如，“您必须在周末工作才能完成这个简单的任务吗？”)。 团队和经理需要达成共识。

2. Start holding a retrospective. It doesn’t need to be an hour-long, and it doesn’t need to be every two weeks. Heck, you don’t even need a big meeting to start. Create a shared document and pass it around, asking team members to add things they would think the team should keep doing, stop doing, and start doing. After a day or two, share the feedback during your typical standup or set up a 15-minute summary.

   开始举行回顾展。 它不需要一个小时的时间，也不必每两个星期。 哎呀，您甚至不需要开会就可以开始。 创建一个共享文档并传递给周围，要求团队成员添加他们认为团队应该继续做，停止做并开始做的事情 。 一两天后，在典型的站立时分享反馈或设置15分钟的摘要。

3. Identify from your retrospectives one thing — yes, one thing — to try. It could be starting something, stopping something, investing in a system, etc. Just pick something you think will help your team.

   从回顾中找出一件事-是的， 一件事 -要尝试。 可能是开始，停止，对系统进行投资等。只需选择您认为对您的团队有帮助的内容即可。

4. Keep doing that over and over!
   不断重复做！

It sounds too simple, right? The truth is that this process is simple. It’s a framework for the team to own something they think will make them better. Given that chance, most engineers will go to things that will improve their codebase and their lives overall.

听起来太简单了吧？ 事实是，此过程很简单。 这是团队拥有自己认为可以使他们变得更好的东西的框架 。 有了这个机会，大多数工程师将着手改善其代码库和整体生活。

It’s just also hard to follow. It takes real work and a commitment to change for a retrospective process to make an impact. Everyone needs to commit to the process, and everyone needs to be honest about their opinion.

这也很难遵循。 它需要真实的工作和对变更的承诺才能使回顾过程产生影响。 每个人都必须致力于这一过程，每个人都必须诚实对待自己的意见。

Before wrapping up, consider your team’s “one thing” for a retrospective to define what constitutes an emergency and what does not. Define if there are cases in which someone needs to work late or over the weekend to complete or when it can wait till the next workday. This definition is important because it will help your team get out of the feeling of perpetually being against the wall.

在总结之前，请考虑您团队的“一件事”进行回顾，以定义什么构成紧急事件，什么不构成紧急事件。 定义是否有某些情况下某人需要工作至深夜或周末才能完成工作，或者何时可以等到下一个工作日。 这个定义很重要，因为它可以帮助您的团队摆脱永远被困在墙上的感觉。

Development shouldn’t be a constant state of exhaustion and hero programming. We need to work together as teams to create sustainable workflows that allow our teams to build software effectively for the long-haul. I hope this guide helps you and your team!

开发不应该是精疲力竭和英雄编程的恒定状态。 我们需要作为团队一起工作，以创建可持续的工作流，从而使我们的团队能够有效地构建长远目标的软件。 希望本指南对您和您的团队有所帮助！

Happy coding!

编码愉快！

翻译自: https://medium.com/dev-genius/on-sustainable-software-development-69acd0749559