最后期限 軟件工程

D E A D L I N E…

最后期限…

As a developer, this is one of your biggest nightmares or should I say your enemy? Name it whatever you want.

作為開發人員，這是您最大的噩夢之一，還是我應該說您的敵人？ 隨便命名。

Admit it. It scares you a lot. Even now, while you are reading these sentences, it makes your hair stand on the end.

承認吧 嚇死你了 即使現在，當您在閱讀這些句子時，它仍然使您的頭發直立。

Wondering how I know that?

想知道我怎么知道？

I know because I’ve felt the same. But now the fear is in the past. I’ve made peace with deadlines. I’ve embraced them.

我知道，因為我有同樣的感覺。 但是現在恐懼已經過去了。 我已經按時完成了任務。 我已經擁抱了他們。

So I suggest you do the same thing. Embrace them, make peace with them. This is the only way that you can defeat them.

所以我建議你做同樣的事情。 擁抱他們，與他們和睦。 這是打敗他們的唯一方法。

Ok but, how you can do that?

好的，但是您該怎么做呢？

There are some facts that we all tend to ignore when it comes to setting a deadline. My aim here is to show them to you so you can see that it takes so little to bury the fear and start enjoying life while you are working on your project without worrying about dates.

在設定截止日期時，有些事實我們都傾向于忽略。 我在這里的目的是向您展示這些內容，這樣您就可以發現，消除恐懼并開始享受生活時所花費的時間很少，而不必擔心日期。

在平靜的環境中工作 (Work in a calm environment)

Don’t rush. Don’t force anything.

不要著急 不要強迫任何東西。

The first thing first you should know is that you can’t find your peace by setting unrealistic dates and forcing your team to work in a rush. There are companies that throw out big words and show unrealistic things to motivate their team to move forward. But while there are some facts obvious to everyone in the team, how can you expect them to believe in what you are saying if it is far away from reality?

首先，您應該知道的第一件事是，您不能通過設定不切實際的日期并強迫團隊匆忙工作來找到自己的安寧。 有些公司大聲疾呼，展示不切實際的事情，以激勵他們的團隊前進。 但是，盡管團隊中的每個人都有一些顯而易見的事實，但是如果這與現實相距甚遠，您如何期望他們相信您所說的話呢？

Without a fixed — and most importantly believable — deadline, you can’t work calmly. Yes, keeping the calm is the key here. When you don’t trust the date, or when someone tells you to do everything within a limited period of time, or someone adds more tasks to the project without giving you more time, you start working maniacally. This is not work anymore. This is hell.

沒有固定的(最重要的是令人信服的)截止日期，您將無法冷靜地工作。 是的，保持冷靜是關鍵。 如果您不信任日期，或者有人告訴您在有限的時間內執行所有操作，或者有人在不給您更多時間的情況下向項目添加了更多任務，那么您就會開始瘋狂地工作。 這不再起作用了。 這是地獄。

When you are under stress and pressure, you can’t be productive. When you are calm, you are also conscious which means that you can make better decisions.

當您承受壓力和壓力時，您將無能為力。 當您保持冷靜時，您也會意識到，這意味著您可以做出更好的決定。

我們的估計很糟糕 (Our estimates suck)

Windows users will remember that window dialog. The estimation in the dialog is exactly like our estimations, isn’t it?

Windows用戶將記住該窗口對話框。 對話框中的估算值與我們的估算值完全一樣，不是嗎？

Let’s admit it. Our estimates suck. We think we can guess how much time something will take. We have a tendency to believe that whatever we guess will come true.

讓我們承認。 我們的估計很糟糕。 我們認為我們可以猜測某件事將花費多少時間。 我們傾向于相信，無論我們猜到什么都會成真。

However, generally, when we are guessing, we ignore some important factors that can affect our assumptions. Why? Because we are too optimistic.

但是，通常來說，在進行猜測時，我們會忽略一些可能影響我們假設的重要因素。 為什么？ 因為我們太樂觀了。

To me, the first step in making peace with the deadline and getting better at setting deadlines is to admit that we are terrible estimators. When you embrace this fact, you will be conscious next time and it will prevent you from underestimating the requirements. And here is a solution for you to get better at estimating:

對我而言，與截止日期達成和平并在設定截止日期方面變得更好的第一步是承認我們是可怕的估算者。 當您接受這個事實時，下次您將有意識，這將防止您低估需求。 以下是您可以更好地估算的解決方案：

Divide the big things into smaller things. The smaller it is, the easier it is to estimate. This will increase your chances of having more accurate estimations.

將大事分成小事 。 它越小，估計就越容易 。 這將增加您獲得更準確的估算值的機會。

足夠好就可以了 (Good enough is fine)

“Perfect is the enemy of good.” — Voltaire“完美是善的敵人?！?—伏爾泰

People like big challenges. We are best at finding a complicated solution for a simple problem. But here is a fact:

人們喜歡挑戰。 我們最擅長為一個簡單的問題找到復雜的解決方案。 但這是一個事實：

Every problem has its own simple solution that you probably ignore.

每個問題都有其自己可能會忽略的簡單解決方案。

Don’t chase a perfect solution. Your first version doesn’t have to be perfect. Build a half product that can work. If you wait too much, you will waste your limited resources and precious time, or you will miss the deadline and even worse do nothing at all because you are chasing perfection. The solution is:

不要追求完美的解決方案。 您的第一個版本不一定是完美的。 制作可以使用的一半產品。 如果您等待太久，則會浪費有限的資源和寶貴的時間，或者您會錯過最后期限，甚至更糟的是根本不追求任何東西，因為您追求完美。 解決方案是：

Find the solution that will bring you a lot of value and requires little effort. And don’t forget, good can be turned into great later.

找到可以為您帶來很多價值并且需要付出很少努力的解決方案。 別忘了，美好的事物可以在以后變成美好。

不要太樂觀。 現實點。 (Don’t be too optimistic. Be realistic.)

I see managers that are too optimistic which makes them set optimistic deadlines to motivate the team. This is so wrong. I’m not telling you that you should be pessimistic about the future. On the contrary, I am telling you that you should be able to see every possibility that can create a bottleneck. Once you can see them, you can consider them and have a more accurate estimation.

我看到經理人過于樂觀，這使他們設定了樂觀的截止日期來激勵團隊。 錯了 我并不是要告訴您您應該對未來感到悲觀。 相反，我告訴你，您應該能夠看到所有可能造成瓶頸的可能性。 一旦看到它們，便可以考慮它們并獲得更準確的估計。

There are different teams in the company. Engineering, business development, marketing, etc. When the business development team forces you to give them a deadline in the very near future, you shouldn’t get affected by them. They want their job to be done as soon as possible.

公司中有不同的團隊。 工程，業務開發，市場營銷等。當業務開發團隊強迫您在不久的將來給他們一個截止日期時，您不應受到他們的影響。 他們希望自己的工作盡快完成。

Remember that every team thinks about their own side.

請記住，每個團隊都在考慮自己的一面。

區分“您必須做”，“您可以做”和“您想做” (Differentiate between “you have to do”, “you could do” and “you want to do”)

Understanding is the key here. What are the core requirements for releasing your product? Usually, the product team has a hard time differentiating them.

理解是這里的關鍵。 發布產品的核心要求是什么？ 通常，產品團隊很難區分他們。

When you have a meeting, one of the team members will say, “we could implement it, it will bring us that much value” or another one will say “We should put this into release.” They are looking from their own perspective. Ok, we can implement this and it can bring us some value, but the important question is that “do we need it now? In the first version?”

當您開會時，其中一個團隊成員會說：“我們可以實施它，它將給我們帶來很多價值”，而另一位成員則說：“我們應該將其發布?！?他們從自己的角度看。 好的，我們可以實現它，并且可以為我們帶來一些價值，但是重要的問題是“我們現在需要它嗎？ 在第一個版本中？”

The answer is NO in most cases.

在大多數情況下，答案是否定的。

The things that you have to do are what you should focus on. Eliminate things you could do and you want to do. They are not even negotiable in most cases.

您要做的事情是您應該關注的 。 消除您可以做和想做的事情。 在大多數情況下，它們甚至都不可協商。

默認說不 (Say no by default)

There is one important fact that we usually forget when we say “Yes” to something. We are saying no to the things we already need to complete.

有一個重要的事實，當我們對某事說“是”時，我們通常會忘記。 我們對已經需要完成的事情說不。

When you say yes to something new, you’re not thinking about the impact it will have on your existing to do’s.

當您對新事物說“是”時，您并沒有考慮它會對現有工作產生的影響。

“Let’s add more tasks to the project after we’ve set the deadline. (Your project should get smaller over time, not larger.)” NO.

“在設定截止日期后，讓我們向項目添加更多任務。 (你的項目應該得到較小隨著時間的推移，沒有較大的。)” NO。

“We focused on what matters, ok. But what about the details? Let’s consider what kind of details we have that can make problems in the future.” NO. Ignore every detail for the first version. Don’t try to predict the future.

“我們專注于重要的事情，好的。 但是細節呢？ 讓我們考慮一下，我們擁有什么樣的細節，將來可能會造成問題?！?不行 忽略第一個版本的每個細節。 不要試圖預測未來。

Finding more time for things isn’t the problem here. Too much stuff to do is the problem. Differentiate between “must-haves” and “nice-to-haves”.

在這里找到更多的時間并不是問題。 問題太多了。 “ 必須有”和“最好具備”區分。

The only way to get more done is to have less to do.

完成更多工作的唯一方法就是減少工作量。

永不更改截止日期 (Never change the deadline)

I see development teams with a bad habit that can affect their product development badly: deadline rescheduling.

我看到開發團隊的壞習慣會嚴重影響他們的產品開發：重新安排截止日期。

When they miss the deadline, they set a new one. If they can’t meet this one, they set another one. When they do this repeatedly, it becomes a habit. Then this bad habit turns into their culture. Other teams in the company lose trust and question the developers’ work. Even worse, the developer team itself can lose trust in each other. In themselves as well.

當他們錯過最后期限時，他們設定了一個新的期限。 如果他們不能滿足這個要求，他們就另設一個。 當他們反復執行此操作時，它就會成為一種習慣。 然后，這個壞習慣變成了他們的文化。 公司中的其他團隊失去了信任，并質疑開發人員的工作。 更糟糕的是，開發團隊本身可能會彼此失去信任。 就其本身而言。

Changing the deadline is essentially an admission of failure. It is making statements like, “We failed to plan requirements, we didn’t say no enough, we didn’t focus on what matters, we pushed our teams to do unreasonable things in an unreasonable time.”

更改截止日期本質上是對失敗的承認 。 它發出這樣的聲明：“我們未能計劃需求，我們沒有說不夠，我們沒有專注于重要的事情，我們迫使我們的團隊在不合理的時間內做不合理的事情?！?

請注意，總會有一些問題 (Be aware that there will be always some problems)

Being too optimistic causes you to ignore the fact that there may be some problems. Be aware. Probably something will go wrong. And this will cause you to lose some time on fixing things. So better to be prepared for bad scenarios. I am not saying that you should be pessimistic and you should try to predict the future and prepare yourself and your team for the unknown. Just find a balance between optimism and pessimism. Be realistic.

過于樂觀會使您忽略以下事實：可能存在一些問題。 意識到。 可能會出問題。 這將導致您在修復問題上浪費時間。 因此最好為惡劣的情況做準備。 我并不是說您應該悲觀，您應該嘗試預測未來，為自己和團隊做好未知的準備。 只要在樂觀與悲觀之間找到平衡。 現實點。

My experience showed me that, in software development, some things always go wrong. My advice to you is:

我的經驗告訴我，在軟件開發中，某些事情總是會出錯。 我對您的建議是：

Add some time to your deadline before you set it by considering that something may go wrong.

考慮到可能會出問題，請在截止日期前增加一些時間。

不要在項目中添加更多人 (Don’t add more people to a project)

A lot of people think that they can speed up the process if they add more people to the project. However, they miss a very important point. Let’s remember Brooks’s law:

許多人認為，如果將更多人添加到項目中，他們可以加快流程。 但是，他們錯過了非常重要的一點。 讓我們記住布魯克斯定律 ：

Adding human resources to a late software project makes it later. — Freed Brooks

將人力資源添加到較晚的軟件項目中會使其變得更晚。 —釋放的布魯克斯

According to Brooks on Wikipedia, there is an incremental person who, when added to a project, makes it take more, not less time. So why does it work this way?

根據Wikipedia上的Brooks所說 ，有一個漸進式人員，將其添加到項目中后，會花費更多而不是更少的時間。 那么為什么它會這樣工作呢？

• It takes some time for the people added to a project to become productive. You will have to educate them first. You have already limited human resources and you will have to dedicate those resources to educate new member. Also since they are new, they will introduce new bugs that move the project further away from completion.

  加入項目的人員要花一些時間才能變得富有成效 。 您將必須首先對其進行教育。 您已經有限的人力資源，您將必須投入這些資源來教育新成員。 另外，由于它們是新的，因此它們將引入新的錯誤，這些錯誤會使項目遠離完成工作。

• Communication overheads increase as the number of people increases.

  通信開銷隨著人數的增加而增加。

• Adding more people to a highly divisible task, such as cleaning rooms in a hotel, decreases the overall task duration. However, other tasks including many specialties in software projects are less divisible. Another great example of this by Brooks is: while it takes one woman nine months to make one baby, “nine women can’t make a baby in one month”.
  將更多的人添加到一個高度可分割的任務中，例如在酒店打掃房間，將減少總體任務持續時間。 但是，其他任務(包括軟件項目中的許多專業)很難被整除。 布魯克斯的另一個很好的例子是：雖然一個女人要生一個嬰兒要花9個月的時間，但“有9個女人一個月不能生孩子”。

Another bit of evidence from Richard Dalton to understand why adding more people is wrong is:

理查德·道爾頓(Richard Dalton)理解為什么增加更多人是錯誤的另一個證據是：

“Teams are immutable. Every time someone leaves or joins, you have a new team, not a changed team.” — Richard Dalton團隊是一成不變的。 每當有人離開或加入時，您就會擁有一個新團隊，而不是一個變更后的團隊?！?—理查德·道爾頓

不要拖延 (Don’t procrastinate)

Let me help you to understand what I mean. Last week, we had a meeting about defining the deadline for a new feature of our product. We were talking about which tasks are our priority and how we should implement them in an effective way.

讓我來幫助您了解我的意思。 上周，我們召開了一次會議，討論確定產品新功能的截止日期。 我們正在討論哪些任務是我們的優先任務，以及我們應該如何有效地執行它們。

There was a task on which we have heavily wasted our time. There were three ways to implement that task but somehow we were stuck. We couldn’t choose because developers were trying to predict the future. They were starting each sentence with “What if”.

有一項任務我們浪費了很多時間。 可以通過三種方式來執行該任務，但是我們卻陷入了困境。 我們之所以無法選擇，是因為開發人員正在嘗試預測未來。 他們在每個句子的開頭都加上“如果”。

You can’t predict what the future will bring you. Don’t over-prepare yourself for the unknown.

您無法預測未來會給您帶來什么。 不要為未知而過度準備。

I am not talking about big technical decisions here. Of course, if you have to decide on your core technology, you should sleep on it to find the right solution. But don’t spend your time on small things. Uncertain things increase meetings and block your progress because your backend process is continuously working on them.

我這里不是在談論重大的技術決策。 當然，如果您必須決定核心技術，則應該依靠它來尋找正確的解決方案。 但是不要把時間花在小事情上。 不確定的事情增加了會議并阻礙了您的進度，因為您的后端流程一直在處理這些會議。

Don’t procrastinate it, decide on it and move forward.

不要拖延，決定并繼續前進。

Change your mentality from “Let’s think about it” to “Let’s decide now”. Decisions will speed up your progress. When something is decided, it will be clear to everyone in the team. Everyone will exactly know what to do.

將您的心態從“讓我們考慮一下”更改為“讓我們現在決定”。 決策將加快您的進度。 做出決定后，團隊中的每個人都會很清楚。 每個人都會完全知道該怎么做。

溝通：查看瓶頸在哪里？ (Communicate: See where is the bottleneck?)

You planned everything. You defined what to focus on and what to do. You know exactly how much time it will take (probably you will be wrong). So, the deadline has been settled. Is it enough?

您已計劃好一切。 您定義了要重點關注的內容和要做什么。 您確切地知道將花費多少時間(可能您錯了)。 因此，截止日期已經確定。 夠了嗎

NO.

沒有。

As I mentioned above, there is always a possibility that something can go wrong. While your team members are working on their tasks, something can block them. Something can stop them to finish their tasks on time. You have to see where is the bottleneck and what it is.

如上所述，總有可能出問題。 當您的團隊成員在執行任務時，某些東西可能會阻止他們。 某些事情可以阻止他們按時完成任務。 您必須查看瓶頸在哪里以及瓶頸在哪里。

Communication is the key here. You have to keep teams synced. Sometimes team members can go into a box and it can be very hard for them to see what is happening out of it. This is where you should enter the scene. Once you have identified the bottleneck, remove it so your team members can continue from where they were stuck.

溝通是這里的關鍵。 您必須保持團隊同步。 有時，團隊成員可能會陷入困境，而他們很難看到其中發生了什么。 這是您應該進入場景的地方。 一旦確定了瓶頸，就將其刪除，以便團隊成員可以從卡住的位置繼續進行。

I wish you good luck in meeting all your deadlines :)

祝您在所有截止日期前都好運：)

Thanks for reading.

謝謝閱讀。

Originally published at https://huseyinpolatyuruk.com.

最初在https://huseyinpolatyuruk.com上發布。

翻譯自: https://www.freecodecamp.org/news/how-to-make-peace-with-deadlines-in-software-development-6cfe3e993f51/

最后期限 軟件工程

總結

以上是生活随笔為你收集整理的最后期限 软件工程_如何在软件开发的最后期限内实现和平的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。