客户项目经验报告中的敏捷软件开发

Note: I drafted this post about 3 years ago. I don’t know why I never published it. Some days ago I already published a post with a similar history. As I want to bring my blogging activity back to life I will keep finishing up and publishing older drafts besides writing completely new ones. I didn’t further edit the draft besides removing todo comments and correcting some typos. Just keep in mind that stuff may be out of date and have fun.

注意：大约3年前，我起草了这篇文章。 我不知道为什么我从未发表过。 几天前，我已经发表了一篇类似历史的文章。 当我想使自己的博客活动恢复活力时，除了编写全新的草稿外，我还将继续完成并发布较旧的草稿。 除了删除待办事项注释和更正某些错别字外，我没有进一步编辑草稿。 请记住，东西可能已经过时了，并且会很有趣。

I am so happy to see that more and more big companies, which used to have heavyweight processes regarding software engineering, are moving to more agile software engineering methodologies.

令我感到高兴的是，越来越多的大型公司曾经使用过有关软件工程的繁重流程，现在正朝着更加敏捷的软件工程方法论发展。

Right now in my job, I have to engineer a piece of software for a customer with a small team trying to be as agile as possible. Fortunately, the customer supports agile software engineering, but still, there we encountered some challenges.

现在，在我的工作中，我必须为一个具有小型团队的客户设计一款软件，以使其尽可能地敏捷。 幸运的是，客户支持敏捷软件工程，但是仍然遇到了一些挑战。

In this article, I want to share my experience realizing that project and the lessons learned from doing that.

在本文中，我想分享我实现该项目的经验以及从该项目中学到的经验教训。

复杂的软件工程 (Sophisticated Software Engineering)

I have a pretty specific idea of how sophisticated software engineering should look, which might differ from your point of view. Short version, I think software should be developed in small cycles where engineers show a DevOps mindset.

我对如何看起来复杂的软件工程有一个非常具体的想法，这可能与您的观点有所不同。 简短的版本，我认为软件应该以工程师展示DevOps思维方式的小周期开发。

反馈回路 (Feedback loops)

It is all about feedback loops. Feedback loops on different abstraction layers.

这全都与反馈循环有关。 反馈在不同的抽象层上循环。

• Continuous Integration with automated tests gives feedback about whether new modifications on the codebase are working the existing code.
  与自动化测试的持续集成可提供有关代码库上的新修改是否正在使用现有代码的反馈。
• Cycles of development time frames in combination with demos for the customer give feedback about whether the requirements match or not.
  开发时间周期与针对客户的演示相结合，可提供有关需求是否匹配的反馈。
• Retrospectives give feedback about whether the process itself should be improved.
  回顾会提供有关是否应改进流程本身的反馈。

You apply the mantra Inspect and Adopt and the more cycles you have, the more you can actually and respond to change. I think this is what it means to be agile. You constantly pull yourself out of the comfort zone, or even better you can prevent yourself from even getting to the comfort zone.

您应用“ 检查和采用”的口头禅，您拥有的周期越多，您实际可以对变化做出的React就越大。 我认为这就是敏捷的含义。 您不断地将自己拉出舒适区，甚至更好的是，您甚至可以阻止自己进入舒适区。

开发运维 (DevOps)

Yes I know, you are tired of buzzwords. Anyway, I have to mention it, because, in my opinion, it is a very important engineering mindset or culture.

是的，我知道，您厌倦了流行语。 无论如何，我不得不提到它，因为我认为这是非常重要的工程思维或文化。

In classic software engineering, software is developed by developers and operated by operators or admins. The problem with that is:

在经典软件工程中，软件由开发人员开发，并由操作员或管理员操作。 问题是：

• developers usually have no clue about operating software
  开发人员通常对操作软件一无所知
• operators usually don’t know anything about the implementation of it.
  操作员通常对它的执行一无所知。

This makes debugging and releasing the software kind of heavyweight process, which is referred to as Gap between developer and operations.

这使得调试和发布软件成为一种繁重的过程，这被称为开发人员和操作之间的差距。

This gap somehow prevents us from being agile because it enlarges the development cycles, which by the way is the reason why those “Big Bang” deployments are most likely used in classic software engineering.

这种差距以某种方式阻止了我们的敏捷性，因为它延长了开发周期，这就是为什么那些“ Big Bang”部署最有可能用于经典软件工程中的原因。

So … you will probably find several definitions out there of what DevOps exactly is, but we will look at it as a mindset of engineers who control the whole software lifecycle from development to operation.

因此…您可能会发现DevOps到底是什么的几个定义，但我们会将其视为控制开发从开发到运营的整个软件生命周期的工程师的思维方式。

You build it, you run it!

您构建它，然后运行它！

挑战性 (Challenges)

Knowing about how to do sophisticated software engineering, unfortunately, is not enough to also actually do it, there are different challenges you will face especially when working with a customer. I will discuss these in the following sections.

不幸的是，仅仅知道如何进行复杂的软件工程还无法实际完成，尤其是在与客户合作时，您将面临不同的挑战。 我将在以下各节中讨论这些内容。

软件工程实践的分歧 (Divergence of software engineering practice)

So in the company, I am working for, we know about how to engineer software in an agile way, as we are implementing the Kanban framework for our software engineering process.

因此，在我正在工作的公司中，我们知道如何以敏捷的方式设计软件，因为我们正在为软件工程流程实施看板框架。

Our customer uses Scrum which is also an agile software engineering framework but is slightly more strict and has more ceremonies than Kanban.

我们的客户使用Scrum，它也是一种敏捷的软件工程框架，但是比看板更为严格，并且具有更多的仪式。

Even though there are some similarities in both the Kanban and Scrum framework which can be described as abstract agile principles, basically the principles of the agile manifesto, people tend to stick to specific details of the respective framework instead of following the agile principles behind them.

尽管看板框架和Scrum框架之间有一些相似之处，可以描述为抽象敏捷原则，基本上是敏捷宣言的原则，但人们倾向于坚持各自框架的具体细节，而不是遵循其背后的敏捷原则。

So the challenge for us here is to somehow synchronize the customer and our team regarding the software engineering process. Not only because of the different approaches and understanding of agile software engineering practices but also because we have different separate boards to visualize our work, this is a very challenging task.

因此，对我们而言，这里的挑战是以某种方式使客户和我们的团队在软件工程流程方面保持同步。 不仅因为对敏捷软件工程实践的方法和理解不同，而且由于我们有不同的独立板来可视化我们的工作，这是一项非常具有挑战性的任务。

开发与运营之间的鸿沟 (The Gap between Dev and Ops)

Even though we know that the gap between developer and operations is a bad thing, working with a customer you will most likely have to face this situation. The reason for that is, that customers will probably want to use their infrastructure while not being able to give you access to it you would need.

即使我们知道开发人员与运营之间的差距是一件坏事，但与客户合作您很可能不得不面对这种情况。 这样做的原因是，客户可能希望使用他们的基础结构，而又无法让您访问所需的基础结构。

In our case the customer uses AWS and we have only restricted access, but they supported us with a such called Infrastructure Engineer who should help us with the tasks regarding the infrastructure.

在我们的情况下，客户使用AWS，而我们只有受限的访问权限，但是他们得到了称为基础架构工程师的支持，该工程师应帮助我们完成有关基础架构的任务。

The challenge here is communication. On the one hand, we have to communicate what we need for the software we are implementing to be operated. But on the other hand, he also has to communicate to us what exactly he is doing, because in the end “we build it, we run it” or “we build, we fix it if it fails”.

这里的挑战是沟通。 一方面，我们必须就所实施的软件进行交流。 但是另一方面，他还必须向我们传达他到底在做什么，因为最终“我们来构建它，然后运行它”或“我们来构建它，如果失败则修复它”。

The more this knowledge gap is diverging, the more you will fall into old patterns of engineering software and the more rigid your process will be.

这种知识鸿沟越是分散，您越会陷入旧的工程软件模式，您的流程就会越僵化。

低估任务 (Underestimating tasks)

Estimation is a hard topic. Some people out there completely rely on the estimation of tasks while mostly having some kind of deadline, while some people say completely refuse to give estimations and work with deadlines.

估计是一个很难的话题。 有些人完全依靠任务估计，而大多数人都有某种截止日期，而有些人则说完全拒绝给出估计并按截止日期进行工作。

And here you have the problem. Most customers want you as engineers to give estimations and work with deadlines. But, this contradicts the agile software development approach where you show the progress of the project on a regular base.

这里有问题。 大多数客户都希望您作为工程师提供估算并按时完成工作。 但是，这与敏捷软件开发方法相矛盾，在该方法中，您定期显示项目进度。

To cut a long story short, you will most probably have to estimate and work with deadlines, as we had to, and I guarantee that you will underestimate and overestimate tasks.

简而言之，您很可能必须像我们一样必须估计和处理截止日期，我保证您会低估和高估任务。

范围蠕变 (Scope Creep)

We refer to scope creep as changing of requirements or scopes. We all know (at least I hope so) that it is simply not possible to specify every single requirement of a software system upfront, which has different reasons.

我们将范围蠕动称为需求或范围的变化。 我们都知道(至少我希望如此)，根本不可能预先指定软件系统的每个需求，这有不同的原因。

The customer himself will not know them all up front, they will change and even then, information gets lost while communicating them to the engineers, just to name some problems.

客户本人不会一开始就知道它们，它们会发生变化，即使如此，在与工程师进行交流时，信息也会丢失，仅是列举一些问题。

Scope Creep will happen and it will happen in the most unpleasant situations, in the middle of a sprint or even some days before a deadline. It will make you feel upset but you will have to somehow deal with it.

范围蠕变会发生，并且它会在最不愉快的情况下发生，发生在冲刺中，甚至是截止日期之前的几天。 它会让您感到沮丧，但您必须以某种方式处理它。

解决方案 (Solutions)

So, we had a quite tough job to overcome these challenges, but here is how we tried to tackle them.

因此，我们在克服这些挑战方面做得相当艰巨，但是这就是我们试图解决它们的方式。

It is very important to understand that finding solutions for the different challenges resulted in constantly reflecting on the work we are doing and being willing to adopt as well as being honest to ourselves.

非常重要的一点是要理解，为不同的挑战寻找解决方案会导致不断地反思我们正在做的工作，愿意接受以及对自己诚实 。

每日站立 (Daily Standups)

We started the project with two engineers on our side, so we didn’t need a daily synchronization on the current progress or occurring impediments as communication between us was very regular and lightweight.

我们是在我们的身边由两名工程师开始该项目的，因此，由于我们之间的交流非常正常且轻巧，因此我们不需要每天同步当前的进度或出现的障碍。

As soon as we realized that there will be this gap between implementing and operating the software I mentioned before, we decided to do a daily standup to synchronize with the Infrastructure Engineer.

一旦我们意识到在实现和操作我之前提到的软件之间将存在差距，我们决定每天进行一次站起来，与基础架构工程师进行同步 。

行动展示 (Ops Showcase)

As the project proceeded we realized that, even though we synchronized daily with Infrastructure Engineer and also did pairing sessions with him, the gap began to get bigger and bigger.

随着项目的进行，我们意识到，即使我们每天与基础架构工程师同步并与他进行配对会议，两者之间的差距也越来越大。

To tackle that problem we decided to have such called ops showcases, where the Infrastructure Engineer introduces us in the work he did to operate the software we implemented.

为了解决这个问题，我们决定设立所谓的ops展示柜，在该展示柜中， 基础架构工程师向我们介绍了他操作所实施软件的工作。

任务整理 (Task Grooming)

As already mentioned, task estimation is a tricky topic and we found ourselves giving wrong estimates on tasks or even forgetting to specify every single detail about a task while creating tickets on our board.

如前所述，任务估计是一个棘手的话题，我们发现自己对任务的估计错误，甚至忘记了在板上创建工单时都指定任务的每个细节。

Therefore we started to do a weekly technical Task Grooming where we went through all tickets and checked for the right description and tried to estimate them right before Sprint Planning. This way we tried to compensate wrong specification and estimation as well as making our work more precise and predictable.

因此，我们开始进行每周一次的技术任务整理 ，在此过程中，我们检查了所有故障单并检查了正确的说明，并试图在Sprint计划之前对它们进行估算。 这样，我们试图补偿错误的规格和估计，并使我们的工作更加精确和可预测。

Note: A precondition for this is that the backlog is prioritized by the Product Owner

注意：这样做的先决条件是，积压工作由产品负责人确定优先级

冲刺计划 (Sprint Planning)

While engineering a piece of software in a customer project, the customer will most likely want to see the current progress of the project and have a certain degree of predictability of how the progress will in the near future.

在客户项目中设计软件时，客户最有可能希望查看项目的当前进度，并对近期的进度有一定程度的可预测性。

In the Sprint Planning session, which takes place at the beginning of each sprint we create transparency about all the tickets on our board(especially the ones in the backlog) and let the customer decide which tickets should be worked on in the upcoming sprint. At the same or directly afterward we, as the team implementing the software, decided how much of the chosen tickets we can achieve.

在每个冲刺开始时进行的Sprint计划会话中，我们为董事会上的所有凭单 (特别是积压订单中的凭单) 创建透明性，并让客户决定在即将到来的冲刺中应处理哪些凭单。 在此之后或之后，我们作为实施该软件的团队，决定了我们可以实现多少张所选票 。

This way has little to no surprise regarding the outcome, the progression of the work we are going to achieve, as we all come to a commitment about the work we think can be achieved in every sprint.

这种方式对于结果，我们将要完成的工作的进展毫不奇怪，因为我们大家都对我们认为可以在每个冲刺中都能实现的工作做出承诺。

By the way, do you remember what I told you about the connection of feedback loops and the ability to engineer software in an agile way? Well having sprints(with Sprint Planings and Demos) also allows the customer to be agile as he can also inspect and adapt based on the results of every sprint.

顺便说一句，您还记得我告诉过您的有关反馈回路的连接以及以敏捷方式设计软件的能力吗？ 拥有冲刺(以及Sprint Planings和Demos)还可以使客户变得敏捷，因为他还可以基于每个冲刺的结果进行检查和调整 。

回顾性 (Retrospective)

Doing Retrospectives on a regular bases is probably the most important ceremony we have in agile software engineering. We want to get feedback about how the team feels and performs, as well as figuring out how we can improve.

定期进行回顾可能是我们在敏捷软件工程中最重要的仪式。 我们希望获得有关团队感觉和表现的反馈，并弄清楚如何改进。

The Retrospective usually takes place at the end of each sprint. There are different ways how to do a Retrospective but basically, you want the team to reflect and them to think about ways to optimize their work.

回顾通常在每次冲刺结束时进行。 进行回顾的方式有多种，但是基本上，您希望团队进行反思，让他们考虑优化工作的方式。

In our Retrospective, we first catch the general feeling about the last sprint of every team member by letting them choose one of the following smileys to express their feelings: :), :/, :(. This way we can get a very basic first impression.

在回顾中，我们首先让每个团队成员选择以下一个笑脸来表达他们的感受，从而大致了解每个团队成员的最后冲刺：:) ， ：/ ， :(这样，我们可以得到一个非常基本的第一印象。

After that, we show data like how many tickets were done and the divergence of the estimated and real effort for every done ticket. Doing that allowed us to get a feeling about the quality of our estimations.

之后，我们将显示数据，例如已完成多少张票以及每张已完成票的估计和实际工作量的差异。 这样做可以使我们对估计的质量有所了解。

The last part of the retrospective is probably the most important and valuable. Each member notes his/her lessons learned as well as things the team should start, stop, or continue doing. Now we try to extract Action Items out of those notes and assign a team member to it, which is then responsible for the progress of that respective item. On each Retrospective, we also check which of the Action Items of the last Retrospective were achieved to decide if they are still important for the team or can be neglected.

回顾的最后一部分可能是最重要和最有价值的。 每个成员都记录他/她的经验教训以及团队应该开始，停止或继续做的事情。 现在，我们尝试从这些注释中提取操作项，并为其分配一个小组成员，然后由该小组成员负责相应项目的进度。 在每个回顾会议上，我们还检查上一个回顾会议的哪些行动项已实现，以决定它们对于团队仍然重要还是可以忽略。

Note: The last part is not a complaining session. Instead of just complaining, try to formulate your complaint positive, as something the team should start doing. This way you avoid team members being offended.

注意：最后一部分不是投诉会议 。 团队应该开始做一些事情，而不仅仅是抱怨，而是尝试将您的投诉表述为积极的。 这样可以避免团队成员被冒犯。

得到教训 (Lessons Learned)

This project was an awesome opportunity to move from a DevOps mindset to a NoOps mindset and to play around with serverless technologies. But don’t get me wrong this was a serious project for a big customer which is now used in production.

这个项目是从DevOps思维方式转变为NoOps思维方式并尝试无服务器技术的绝佳机会。 但是请不要误会我的意思，对于一个大客户来说这是一个严肃的项目，现在已经投入生产。

In my opinion, we not only learned a lot about serverless technology and AWS but also we got a lot of knowledge of how to do agile software engineering in a better way. Let’s summarize the most important things:

我认为，我们不仅学到了很多有关无服务器技术和AWS的知识，而且还获得了很多有关如何以更好的方式进行敏捷软件工程的知识。 让我们总结一下最重要的事情：

• Embrace Transparency
  拥抱透明度
• Try to achieve predictability
  尝试实现可预测性
• Communication is key
  沟通是关键
• Fail fast, escalate fast
  快速失败，快速升级
• Sync, Sync, Sync
  同步，同步，同步

翻译自: https://medium.com/the-innovation/agile-software-development-on-a-customer-project-experience-report-e1059505e2ce