Scrum 的適合場景:「外包團隊」

在「工程師幹話」的『老闆想要成長 — 我們就讓老闆「看見」成長』這篇裡面提到了 Scrum

台灣最接近 Scrum 的組織是國軍。一個 Scrum team 不應該太大,所以一個班只有九個人,然後有一個直接的 PO,叫做班長;每天工作之前都有的 standup meeting 呢,叫做早點名;至於固定時間都有的 retrospective 會議呢,叫做榮團會。所以,如果我們真心相信有個 Scrum 外型的組織就可以提昇效率的話,就等於,我們居然會願意相信:中華民國國軍是個高效率的組織。

這篇文章花了半個小時才看完,真是有夠長的... 裡面描述了很多事情,與一些時間線對一下,大概知道哪個段落在講什麼事情。

之前跟其他朋友聊到 Scrum 的時候我都有先說我的結論,就是我覺得 Scrum 只適合用在「外包團隊」與「業主」之間的互動,目前看到的其他情境都不合理。

利用 Scrum 的架構,可以改善傳統的外包情境:

  • 通常業主給不出完整的 spec,於是外包團隊無法估算成本,所以外包團隊利用 Scrum 機制,每個 sprint 可以要求業主每次提供一點 spec,然後依照這些 spec 估時 (點數) 並且計費 (換算成 manhour,然後得出人力成本與利潤)。
  • 如果業主一開始就可以給出完整的 spec 也沒關係,spec 先切出第一個 sprint,在每個 sprint 結束後,跟業主確認下一輪的內容。

Scrum 在外包團隊可以掌握的範圍,大幅改善了傳統外包簽約的困難。

對於業主不知道要做什麼的,可以降低業主一開始就需要提供很多資料 (spec) 的門檻。

而對於業主已經知道要做什麼的,可以提供修改的時間點。這對於超長期的合作時特別有用,像是軍事外包案常常一個外包就是五年或是更長,sprint 的機制讓業主可以在中間很自然的修改規格,而不是加簽附約的方式修改 spec。

另外,在簽署 Agile Manifesto 的 17 人名單也可以看出來,裡面專搞 Scrum 的差不多都是在外包或是在當顧問,那麼,推出一個「學派」再告訴客戶這樣做會更好,是個自然不過的事情了。

而從 Scrum 裡面的其他細節也可以看出來他們怎麼把外包團隊想要避開的問題「包裝」起來賣給客戶:

  • 透過大幅縮短 milestone 的設計「sprint」,可以依照每個 sprint 收款,也因為通常 sprint 的單位長度比 milestone 的時間短很多,外包團隊的現金流的品質會比以前好。
  • 在 daily standup meeting 可以取得目前專案的進度,一方面可以在內部追蹤,避免有項目出事,另外一方面可以向業主回報,讓業主有安全感。
  • 再來是 Scrum 要求每個 sprint 的內容不可以被變更的問題,這點則是避免了客戶端的手伸進來,而改變了成本結構導致虧本。但也提供客戶修改的空間:允許下個 sprint 修改,重點在於該收的錢有收到。

而以上的這些東西放到公司內就會變得很奇怪:

  • 外包公司不在意手上做的產品是不是合理,只在意工時 (人力成本) 合不合理。而公司內的團隊合理性的才會下去執行,甚至有可能做到一半才發現不合理而需要全面中斷 (因為 startup 常常在做一些以前的人沒做過的事情)。
  • 在外包公司裡,PO 無法伸手進 sprint 修改既定事項,要硬改就是得照合約先把這個 sprint 的錢付掉,所以這情不太會發生。而在公司內 PO 常常是老闆或是大主管,伸手進來改不會有什麼賠償成本,Scrum 的這條規定在公司裡面就是沒有罰則的法律。
  • 公司成員遇到問題卡住 (不知道怎麼解、自己不會解、需要別人一起幫忙解) 或是進度會跟不上的情況應該是發現時馬上通知,而不是擺爛等到隔天的 standup meeting 才提出來。於是你會發現找不到 daily standup meeting 的目的。

另外一個問題是:

  • 營運端的成本造成估時不準確。像是上線後,系統的 downtime、bugfix 而使得原來團隊成員需要支援的情況,導致一個人的輸出不可能有 40 hours/week。

這點也是在外包公司不會遇到,而公司內不可避免會遇到的情況。

差不多把該講的都列出來了,這是我覺得外包時用 Scrum 適合的原因。

pipenv 的凋零與替代方案 poetry

看到「If this project is dead, just tell us」這個,裡面討論到了 pipenv 的前景愈來愈讓人疑惑,要官方給個意見,結果下面就馬上有人建議跳槽到 poetry

剛好前陣子看到另外一篇文章「My Python Development Environment, 2020 Edition」,裡面也提到了他把 pipenv 換成 poetry,而且提到了 pipenv 的問題:

pipenv → poetry. This move’s more complex. I stoped using Pipenv for a couple of reasons:

  • Governance: the lead of Pipenv was someone with a history of not treating his collaborators well. That gave me some serious concerns about the future of the project, and of my ability to get bugs fixed.
  • Bugs and rapid API changes. About a year ago, Pipenv had lots of bugs, and a rapid pace of change introducing or changing APIs. I ran into minor issues at least once a week. Nothing was seriously bad, but it generally felt fairly unstable. I kept having to update various automated deploy workflows to work around issues or changes to Pipenv.

看起來 tech stack 裡面要把 pipenv 轉移抽離了...

Amazon EFS 提供 7 天的 IA 選項

Amazon EFS 有 IA 的儲存方案,儲存的價位便宜很多,但需要另外收存取費用。不過這對於丟 log 之類的倒是還算方便,很多現有的程式就可以直接往裡面丟...

不過系統的設計上不是讓你指定哪些檔案放到 IA,而是設定 Lifecycle Management Policy 以及時間,當超過指定的時間後就會安排搬到 IA 裡面。

先前最低的時間是 14 天,剛剛看到 AWS 宣佈有 7 天的選項了,從 web console 上就可以看到選項可以選了:「Amazon Elastic File System Infrequent Access Now Supports a 7-day Lifecycle Management Policy」。

這樣對於開始堆資料的人,一開始塞東西進去而需要付 Standard Storage 的時間可以少蠻多的...

寫了一個可以用 '/' 在 AWS 上快速切換服務的小工具

AWS Management Console 上切換服務需要用到滑鼠,而這個 Userscript 工具提供了 / 快速鍵可以直接拉出服務選單,另外也可以用 Esc 鍵關閉服務選單:「AWS Web Console Service Shortkeys」。

這個套件應該是支援多個瀏覽器,但是需要先安裝 Tampermonkey 這類可以跑 Userscript 的套件。

主要是常常在切的時候發現需要拿滑鼠,寫了這個 script 後多了一個方式可以用,而不需要把手移開鍵盤,會順手一些...

不過還是希望這個功能直接變成內建的 :o

各種對 AWS Managemenet Console 的抱怨...

Hacker News Daily 上看到 Reddit 上面有一篇對 AWS Management Console 的抱怨文,差不多是兩個月前開始累積的:「I am stupefied every day by the awfulness of the AWS web console」。

AWS 的主力開發因為是以 API 為主,而 AWS Management Console 能做的事情一直都少蠻多的 (看起來是一個團隊在開發,然後呼叫 API),而且的確是常常中 bug,所以會有這樣的抱怨其實不太意外...

然後就有人放火了:

[–]canadian_sysadmin 24 points 2 months ago
I see you've never used Azure...

[–]myron-semack 18 points 2 months ago
AWS’s console sucks because they don’t give a damn about UI. They are API-first.

Azure’s console sucks because they tried to make it nice but failed.

[–]ryantiger658 5 points 2 months ago
I was scrolling looking for this comment. Azures interface has made me appreciate AWS even more.

Azure 被偷戳了好幾下 XDDD 然後 GCP 也被偷戳了:

[–]edgan 1 point 2 months ago
It could br better, but it is far better than than Azure and GCP. Azure's old one was better than their new beta interface last I saw it. GCP has some interesting ideas, but the side bar centric design doesn't function well. It also tries to do too much, and is too JavaScript-y happy.

通常用 AWS 自己的 CloudFormation 或是第三方的 Terraform 管理還是比較常見的方式 (基於 Infrastructure as code 的概念),而 AWS Managemenet Console 當作是輔助,因為目前的雲端服務在設計上的確是希望你多用 API...

在 Chrome 的 FileSystem API 的漏洞被補上後,偵測私密瀏覽模式的方式

Google Chrome 74 版修掉了一般模式與私密瀏覽模式下 FileSystem API 明顯的不同處後,自然就會有人研究其他的偵測方式:「Bypassing anti-incognito detection in Google Chrome」。

作者提出來的方式是透過 Quota Management API,一般模式與私密瀏覽模式下會得到不同的值,尤其是硬碟夠大的時候上限是不一樣的:

不過這個看起來應該比較好修?

ACME,RFC 8555

這邊講的是因為 Let's Encrypt 所發明的 ACME 協定,可以協助自動化發憑證的協定。

剛剛看到「Automatic Certificate Management Environment (ACME)」這個頁面,上面標 PROPOSED STANDARD,但點進去的 txt 檔開頭則是 Standards Track 了:

Internet Engineering Task Force (IETF)                         R. Barnes
Request for Comments: 8555                                         Cisco
Category: Standards Track                             J. Hoffman-Andrews
ISSN: 2070-1721                                                      EFF
                                                             D. McCarney
                                                           Let's Encrypt
                                                               J. Kasten
                                                  University of Michigan
                                                              March 2019

不知道是不是兩邊不同步 (或是我對流程有誤會?),但這有一個標準文件可以參考了...

Amazon EBS Snapshot 支援 Lifecycle Management

以往用 Amazon EBS Snapshot 需要用 Lambda 當 cron job 建立 snapshot,以及管理要存的數量 (要刪掉舊的),現在 AWS 直接提供服務幫你處理:「New – Lifecycle Management for Amazon EBS Snapshots」。文章的截圖就說明了這個新功能:

不收另外的費用,不過目前只有開放三區,東京不在裡面:

You can create and use Data Lifecyle Manager policies at no charge; you pay the usual storage charges for the EBS snapshots that it creates.

Data Lifecycle Manager is available in the US East (N. Virginia), US West (Oregon), and EU (Ireland) Regions.

先繼續用 Lambda,等東京有的時候再換過去...

用 Percona Monitoring and Management (PMM) 蒐集 PostgreSQL 的數據

難得在 Percona 的 blog 上看到專門談 PostgreSQL 的文章:「Collect PostgreSQL Metrics with Percona Monitoring and Management (PMM)」。

其實是透過 Prometheus 疊出來的:

Starting from PMM 1.4.0. it’s possible to add monitoring for any service supported by Prometheus.

在步驟也可以看到:

3. In the next dialog, choose Prometheus as a data source and continue.

這方法有點奇怪就是了,但反正會動比較重要?XD