[埃及、約旦] 流浪隨筆 - 約旦死海 Deadsea

死海(Deadsea)，記得在懵懂幼年就已經在書籍上閱讀到：死海不是海，其實是一座鹽水湖泊，由於身處幾乎無雨的沙漠地帶，加上水分被太陽烹曬不斷蒸發的結果，讓湖水鹹度越來越高，變成世界鹽度一番的湖泊。顧名思義，因為鹽分相當高根本沒有任何生物可以生存在死海中；而人體在這座湖上能自己浮起來。

這次的埃及行其實原本沒有約旦這個景點，因為某些因緣際會，我們再碰到兩個台灣旅遊全世界的背包客，意識到一個這麼趣的地點，立馬改行程然後上網買了廉價航空飛了過去。真是不虛此行。

到約旦機場囉

搭乘約旦當地巴士

約旦的市區街道，滿街都是豪華轎車，不愧是石油輸出國之一

約旦即將大選，路上全都是競選人的宣傳海報(原來東西方搞選舉也沒什麼新的花樣，說回來，個人也在泰國的蘇美島碰過選舉的造勢晚會)

又是因為某些因緣際會，拖了某個傻蛋的福我們多買一張用不到的機票，所以我們直奔到約旦航空公司的辦公室，結果用很破的英文盧了半天也沒用：航空公司表示因為我們不是直接跟他們買(類似你在台灣用易遊網買長榮的機票)，他們不負責，請我們找代理人。(後來回台灣是透過skype打電話到英國的代理人網站進行退訂費，但由於是廉價航空機制，大概只退了五成費用，這是某人第一次用電話跟歪國人聊天談正事...)但還是有一些特別的收穫~

我們明明就在一樓怎麼會寫0 ?

跨龍謀的電梯按鈕

Note of daily stand-up review 每日站立會議執行心得

圖片來源：http://martinfowler.com/articles

滾石不生苔的法則，適用於惡劣不斷學習的職場、男女之間的感情維持、朋友的交際應酬，當然軟體工程也不例外。

問題在於，要怎麼讓石頭滾起來呢？又要怎麼判斷有沒有滾起來呢？所以某人堅持要搞執行每日站立會議(Daily stand-up review)。

目前團隊跑了剛好一個多月，執行方式：

• 每日早上九點初準時開始，全員參與，因為開得很快，在其他團隊要用會議室前就結束了，連會議室都不用借。
• 站著開會，因為乳酸會在站立的姿勢下快速積累於雙腳，能有效加快會議速率。
• 用google doc進行條列式追蹤，追蹤項目只寫三件事情：昨天我做了什麼、今天我要做什麼、我需要什麼幫助。
• 在大家報告完後，再行同步其他資訊(某些情況這件事情可以當作熱場用)。

在這裡先澄清一件事情，並不是所有的開發團隊都適用於每日站立會議，首先有幾個條件要滿足：

• 人不能太少，四人以下團隊基本上就免了吧，因為整天就是這幾個人在你看我、我看你，幹嘛還花時間開會。
• 人不能太多，雖然目前個人團隊還沒超過十個人，但依現在的負荷量來說，超過十人來開每日會議就會浪費太多時間，每個人報告個3分鐘，全部人報告完就要半小時，還沒有加上其他議題的討論時間。
• 主席(可能是PM或SA)要有一定的技術能力，否則開了也沒意思，直接用功能完成度來追進度就好了。最好是能當場就決定某些技術環節要如何解決、誰來解決、何時解決，否則議而不決真的沒意義。

所謂的每日站立會議有幾項原則：

• 時間不能太長，因為腳會痠。
• 主席減少發言，最好是

[Weinberg - Quality Software Management][Book 4][Ch 12] 流程原則

個人看書喜歡跳來跳去，這次直接跳到第四冊啦！

軟體工程大師溫伯格在談軟體管理學的前三本書，內容主要都是在導引如何建置優良的軟體開發，直到第四本書他開始談要如何在一個發展規模龐大組織及舊環境的體制下，我們該如何進行變革。

第十二章講述的是流程原則，目的在於用方法論來克服人的惰性，關鍵在於任何環節都需要被掌握，然後怎樣的情況算是有所掌握，以下是摘要：

Note：

• 專案中的每樣東西必須是顯而易見的，包含程式碼、計畫、需求、設計、測試計劃、測試結果、進展、所有的書面資料...
• 當你發現任何一件成果看不到，或"無法接受檢驗"，一定要停掉那件事情，並開始進行矯正。要避免"吉米是唯一知道那裏面有什麼東西的人"這類情況，先派人協助吉米，然後請吉米把事情記載於文中，如果吉米拒絕，就拿掉他。看不見的事情絕對不會安頓下來。
• 通過獨立審查前，沒有一樣東西是真實的。
• 你不做評量的東西，絕對會不受你控制。