開源日報 每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文，堅持閱讀《開源日報》，保持每日學習的好習慣。
今日推薦開源項目：《色號召來 chinese-colors》
今日推薦英文原文：《Write Better Quality Software Without Deadlines》
今日推薦開源項目：《色號召來 chinese-colors》傳送門：GitHub鏈接
推薦理由：在成千上萬種顏色中選出一個剛好合適的總是不太容易。這個項目收錄了一些中國傳統顏色的具體屬性，包括 CMYK 的印刷四色模式和 RGB 三原色模式，作為平時的備忘錄使用剛剛好。而且每種顏色都附贈了一句古典詩詞，更突顯了整個頁面的文化氣氛，這個細節著實是令人眼前一亮。
今日推薦英文原文：《Write Better Quality Software Without Deadlines》作者：Jamie Morris
原文鏈接：https://medium.com/swlh/write-better-quality-software-without-deadlines-4526dc3edc19
推薦理由：一種不同的看法：應當保證產品的質量，哪怕拖延一些時間

Write Better Quality Software Without Deadlines

How would you write software if you had all the time in the world? Would you do anything differently to what you do now? This is a question asked in Extreme Programming.

You must have heard of the project management triangle, right? Make a triangle and on each point you have some variation of the following: cost, time, scope. You can only control two of the three. In the centre of the triangle is a dot, and as it moves towards any corner it must then move further from the others. It is a useful concept, but there is something missing.

What about quality? Let』s abandon the triangle and imagine instead a series of dials that control each facet. As the client, and the person paying the bills, you turn scope up to 10, signalling that getting all of the features is the most important consideration. But by doing so the cost, and time dials are also set to 0. They will be sacrificed on the altar of scope. So you dial up time a little, because you need all of the features by Christmas. Doing so will turn down the quality dial, because the only way to deliver the features asked for is to accept technical debt and skip things like testing, refactoring and peer reviews.

This is pretty typical. Quality is usually the most flexible element in the eyes of both developers and stakeholders, even if they don』t admit it. I』ve heard numerous teams say things like 「I want to write tests but I don』t have time」 or 「we』ll refactor after the next release」. Sometimes this is necessary — there is a missed opportunity cost to delivering late, no matter how beautiful your architecture. Sometimes you simply don』t have the money to hire 30 expert developers, so you make do with what you have.

But I had the privilege once to work at a company where quality was paramount. So much so that despite a team of 40 developers and 5 years of software in production, they only ever had two people working on support, and those 2 people changed every week. When my turn came, I continued with my day job and dealt with a total of two simple support tickets during the week. I have worked at much smaller companies with dedicated teams of support staff who were raking leaves in a hurricane. The quality in this team came from their strict adherence to Extreme Programming and to something they called the golden rule.
The development team are not allowed to know any deadlines
They didn』t invent the concept, but it was the first place I saw it work, because everyone believed in it. The only person who knew the deadline was the Product Owner, and they had the integrity, conviction and authority to stick to the golden rule.

So why do I think it was important? Take this conversation:
  • Boss: 「How long will this feature take to deliver?」
  • You: 「A week.」
  • Boss: 「Not good enough!」
  • You: 「Ok, a day.」
What changed? Were you lying the first time? Did your boss inspire you to write more code in less time? You probably adjusted your estimate to make it more palatable. We』ve all done it and regretted it later.

I see the same happening with immature scrum teams all the time: you impose these artificial deadlines where every two weeks you end up rushing to get things done. With a little smoke and mirrors you get the user story through the sprint review without the tests or with some hard coded data. Whatever you need to get sign off. This is bad, because now you』re starting the next sprint on the back foot. You just told the Product Owner that Story A is complete, according to whatever your definition of done is. Presumably your definition of done does not say 「it looks finished to the casual observer」. So in the next sprint when the Product Owner thinks you』re working on Story B, you』re actually still finishing what you didn』t get done in Story A. Or worse, you cut your losses and move on, accepting that technical debt is something that gets paid by other people.

So let』s assume we are going to deliver late and want to try and fix it. What are the things we think we can control?
  • The first is scope. Well, this is the obvious one to cut, but as it happens, the team I worked in was already very good at figuring out what the Minimum Viable Product was for any given story, so the scope was already about as thin as it could get. Sure, the Product Owner may have the clout to trim it down even more, but most of the time that wasn』t the case. For those of you not blessed with supreme harmony between stakeholders, Product Owners and developers, scope is absolutely the first thing you should consider cutting if a deadline can』t be met on time.
  • Next is cost, which usually means resource (I hate the term resources because developers are not fungible, but let』s go with it). One proposed solution is to work overtime. One of the core tenets of XP is that if your team has to work overtime two weeks in a row, something is broken and needs to be fixed. Don』t use overtime except in emergencies, because you will burn out your team. The other proposed solution is usually to hire more developers. That might work in the long term, but it takes time for even the most experience developer to become acquainted with the project. Hiring more developers is a long term fix for a short term problem. It won』t help you deliver faster now. And sometimes it won』t even help in the long term. Remember that nine women can』t make a baby in one month.
  • The last thing we can sacrifice is quality. In other words, we can cut corners. You might skip peer reviews or disable some failing tests for now because they need to be rewritten. You build up technical debt, buying time from tomorrow to pay for today』s problems.
At the company I worked for, sacrificing quality was not an option in almost every case. Where quality had to be sacrificed it was temporary, with a firm commitment to pay it back later. Although come to think of it, I can』t think of a single time I saw them resort to this.

So by eliminating scope, cost and quality as mutable values, the only conclusion is that time cannot be of paramount importance. It isn』t necessarily the least important, since by adhering to the MVP, scope is already being sacrificed to facilitate quick delivery. But it is less important than quality, and dialling up the cost won』t make an appreciable impact until it is too late.

So don』t give developers the temptation to cut corners. Remove the deadline from view and let them make the right choices to deliver high quality software. This will pay dividends in the long term by reducing the cost of a dedicated support team, and often allows for faster delivery by writing code that is easy to work with.

I』d like to pose a challenge to those of you who think this couldn』t happen in your team. Explain the concept to your stakeholders. Be sure to explain the concept of a Minimum Viable Product (which I will blog about separately). Ask them to rank the four variables in order of importance. I hope they give you something like this:
  • High Quality
  • Quick Delivery
  • Low Cost
  • Broad Scope
Hold them to account, and make sure your Product Owner does so, too. You might be surprised at how much this kind of thinking resonates with the people paying the bills.
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/