n個月前，公司中標了某航空公司的外包。
由於本地技術中心處於大患血狀態，急需要一名有經驗的技術/專案經理。
上個月招到了這位曾經在華為工作多年的夏經理。
最近專案組進場了，陸陸續續的完成了專案的專案原型後，夏經理使用撲克估算的方式對這個專案的工時進行估算。
估算撲克的基本上的操作是，在原型畫好之後，每個開發人員根據自己對專案的了解，在沒有別人的影響下，對每個原型畫面估計自己完成需要多久的時間。
之後，進行會議，每個開發這亮出自己的估計時間，如果相差不大，那沒什麼好說的，少數服從多數的原則。如果相差較大，那麼則兩個極端的人員或者多個極端的開發者說說為什麼要用這麼多的時間。這樣做主要是考慮到有些人說的可能是其他人沒考慮到的。
以上是基本的背景。
昨天2017-11-2參加完估算會議後，我覺得我有必要寫下一些參與的感受。
第一點感受，這會議真的很耗時間，我不知道是不是就是要這麼久的呢，還是因為夏經理的原型很多地方都沒整清楚，很大一部分時間都是在和客戶經理（當時也在現場）討論很多實現的上的問題。
不得不說，夏經理確實是能看的很細，思維連貫，能縱觀全域性，作為乙個小程式設計師，我確實很是佩服。然而，夏經理和客戶溝通過程中，不少充斥著火藥味，客戶經理也有不耐煩的回答這夏經理的問題，而夏經理在討論到他沒有考慮到的點的時候，會不自覺的說口頭禪，比如我去，嘆氣等消極的詞彙資訊。
總結第一點就是，原型上可能做的不夠詳細，溝通上存在問題。
第二點感受，我們再會議前是對模組做過評估的，對系統也參加過培訓。 然而估算時間上多少還是有很多考慮不周的事情，這就讓這估算會議的討論變得有意義。在會議過程中，看著大螢幕上的模組點，還是會出現懵懂的情況，心裡嘀咕，這tm是什麼模組？沒什麼印象啊。看著都犯睏。
不知道是只有我這樣，還是其他同事也這樣（**心理）。
最後呢，還是得表揚下自己，參加會議的時候，能夠插幾句自己的意見和看法，雖然很多都是直接被兩個經理無視的。再接再厲吧。
填報工時小助手之Shell Alfred的合理使用
最近部門檢查工時及其繁瑣,而考勤只有第二天才能出來,系統做得不夠友好,工時涉及到乙個計算,而工時填報只能在下班以後操作,每次都需要自己去算一遍無疑很低效,很是影響下班的效率,順手擼了乙個可互動的shell指令碼配合alfred完美執行,遂成此篇.執行效果如圖 工時計算規則 工時 下班時間 上班時間 ...
函式之形參與實參
def fn a,b,c print a print b print c print x print y print z x 100y 1000z 10000 x,y z 是外界實際存在的值 呼叫函式時，實參可以有常量，變數，表示式或三種組合。在函式的外部不能直接使用函式的形參，原因 函式呼叫完畢後...
UML核心元素之參與者
一 概述 在系統之外與系統互動的某人或某事物。1 如何找到參與者，確定系統邊界。在乙個業務中可以問自己兩個問題 a.誰對系統有著明確的目標和和要求並且主動發出動作。b.系統是為誰服務。參與者還有另一種叫法 主角。參與者容易讓人誤解為只要參與了業務的，都是參與者，而主角很明確的指出，只有主動啟動這個業...