對於乙個初創企業來說，有什麼比速度更珍貴的呢？sam altman如是說:「快速推進。速度是你逃離巨大競爭吸力的最主要的方法」。 而eric ries所提出的當前炙手可熱的「精益創業」理念大部分說得也就是速度的問題。那麼對於乙個初創企業來說，速度最大化以避免你的企業墜毀得灰飛煙滅屍骨無全究竟意味著什麼呢？下面我們就好好分析分析！
物理學上有個術語叫「逃逸速度」，指的就是乙個物體如果要逃離萬有引力的約束所要達到的速度。乙個火箭上公升的初始速度如果能達到11.2km/s以上的話就能夠衝出地球走向宇宙一去不復還。如果低於這個速度的話，那對不起，你將需要消耗更多的燃料慢慢的推動著火箭往上公升，最終的結果可能就是上演一出真實版的「重返地球」最終墜毀化作一團火球，只是電影《重返地球》中人家是從外太空來回到地球，而你卻從來沒有離開過地球。
對於乙個初創企業來說，有什麼比速度更珍貴的呢？sam altman(天地會珠海分舵注：大名鼎鼎的yc董事長，更是大名鼎鼎的"矽谷創業教父「paul graham的**人，他說的話我們就別懷疑了。本人有幸翻譯過他們兩者的文章，大家有興趣的可以到本人官網www.techgogogo.com進行檢視和參考閱讀。)如是說:「快速推進。速度是你逃離巨大競爭吸力的最主要的方法」。 而eric ries所提出的當前炙手可熱的「精益創業」理念大部分說得也就是速度的問題。那麼對於乙個初創企業來說，速度最大化以避免你的企業墜毀的灰飛煙滅究竟意味著什麼呢？下面我們就好好分析分析！
初創企業跟火箭一樣都是按著乙個速度往前推進的。在物理學中速度指的是在某個時間內推進的距離。而對於初創企業來說，速度意味著企業發展的進度(上圖右上的progress)除以所需的時間(上圖右下的time)。假設乙個初創企業所需要投入的資源成本就是時間，進度就等同於獲取到的商業價值，那麼替換到以上的公式就得出了你的roi(投資回報率)！
作為乙個初創公司來說，你將會面臨很多的不確定性。你很難去**你下一次迭代的功能點收效如何。你的**結果也許會命中，但大部分情況下往往結果會是錯的。你所能做的事情就是去快速投放市場驗證然後觀察效果。總的來說，初創企業在每次迭代時所取得的進展平均起來都是很小的，因為在10個功能點快速驗證當中，你如果有幾個效果是很成功的話已經是非常阿彌陀佛的了。
為了在我們的初創企業速度模型中更好的描述這些令人擔憂的因素，讓我們把迭代進度進一步細化成「預期功效「(下圖右上的expected win)和「成功機率」(下圖右上的success chance)。在下圖中你就能看到每次迭代中低迷的」成功機率「會大大的拖住每個初創企業的發展速度。這我們總不能坐視不管啊。
好訊息是在上面的迭代效率模型的底部你還有個叫做時間(time)的東西讓你扳回一城。你將需要竭盡所能的在每次迭代中用盡量短的時間將功能推出市場進行快速驗證。同時，迭代時間又可以細分成以下兩個主要部分：
最終得出的細分的迭代效率模型圖如下：
從中可以看到，如果能把開發時間(上圖右下的development time)和所有間接消耗時間(上圖右下的overheads time)拉下來的話，你就能大幅度的提公升你的初創企業的迭代速度。如果僅僅測試乙個小改動你就需要花費幾個小時的測試時間的話，那麼，兄弟，這意味著你的產品開發正面臨著一些嚴重的問題，是時候開始做點事情了。同理，在你費盡口舌耗費幾個小時來說服你的小夥伴們來認同你的觀點期間，你其實已經可以將它實現出來並開始進行測試了。少說，多做！
那麼我們可以做些什麼事情來加快我們每次迭代的進度呢？答案是肯定的，建議如下：
好的，理論分析完了，完整的初創企業速度模型和迭代效率模型我們都有了，那麼是時間來找個麻雀來解剖下了。
不久之前我正好給乙個面臨著開發時間嚴重挑戰的初創企業進行指導。他們的組成成員其實都是一級棒的，非常有天分。其實他們都非常想做出點改變，但是事實上又對他們的產品開發程序裹足不前這種狀態束手無策。開發和部署乙個小功能往往都會耗掉大家超過乙個星期的時間。很多不錯的功能點一直都只能在他們的product backlog(scrum術語：產品清單)或者sprint backlog(scrum術語: 衝刺清單)中長眠不醒無人觸碰。大夥慢慢變得意志消沉備受打擊但又無可奈何。
為了解決這個問題他們也嘗試過想出乙個這樣的解決方案來：根據商業價值和實現技術複雜度來對每個功能點進行評估(其實和我們上面的迭代效率模型已經很接近了，只是他們沒有把風險/成功機率給考慮進去)。他們希望對每個功能點都做詳盡的分析以便更精確的把握這些功能點的潛在回報率，然後再從中挑選一些出來進行迭代實現(天地會珠海分舵注:可以想象這樣的流程在乙個迭代中將消耗大量的間接時間)。
為什麼他們得做法不奏效呢？
後來的方案沒有把大功能點的潛在風險考慮進去。這就導致了他們高估了(擁有最高風險的)大功能點所帶來的價值，而反過來又低估了小功能點優化所帶來的價值。
最開始方案的過長的開發和部署時間的消耗導致了大量的優秀功能點沒有辦法在迭代中完成，時間不夠。
後來的方案中對每個功能點進行額外分析所帶來的間接時間消耗就讓上面模型方程式中的分子變得越加龐大，分子變大了，結果當然是等式左邊的迭代效率下降了。
所以，該方案一開始就走錯了方向，因為沒有把問題定位到過慢的開發時間上面來。通過限制從product backlog中取出的功能點數量，並要求對每個功能點投入額外的調研時間來確定哪些功能點需要放進當前的sprint backlog上面，這只會大大的拖住你的初創企業往前邁進的後腿。其實他們更應該關注的是去降低開發部署時間以及其他間接消耗時間(包括那些額外的調研)，以確保盡量多的功能點能得到盡快實現並投入市場進行驗證。
以下各點就是從初創企業速度模型提煉出來精髓：
在產品開發期間把目標瞄準那些具備可操作性的優秀功能點上—把功能點的實現並推向市場的時間最小化。把你的開發周期壓縮到以小時為單位，而不是以多少周來衡量。交付mvps(最小可行產品)而非大而全的產品。
別妄想你能準確**使用者對功能點的接受效果。離開你舒服的椅子，走出你的辦公大樓去尋找真正的使用者進行驗證。別害怕失敗。只要你能從中學習，別在同乙個位置上栽兩次跟斗就行了。
別把好的功能點都放在你的product backlog中睡懶覺，確保你有足夠的「頻寬」來處理那些最「有前途」的功能點。
別讓上面說的那些「間接消耗時間」拖了你的後腿。避免那些過長的無謂討論或所謂的長期計畫。快速迭代反饋才是王道。
盡量把大功能點細化成小的步驟來付諸實現和驗證。耗時的大功能點只會讓你舉步維艱。
最後容天地會珠海分舵感嘆下：道理每個人都懂，為毛國人都這麼浮躁沒人去總結呢！？
英文文章參考：
作/譯者：天地會珠海分舵，原文出處：
白盒測試（初）
又稱為結構測試或者邏輯驅動測試，是一種按照程式的邏輯和編碼結構設計測試資料的方法 白盒測試是關注程式的內部邏輯實現的 目的 白盒測試主要目的是發現問題，找bug 不一定是功能bug 邏輯bug，冗餘 注釋率 太複雜 改正問題，使得 執行正常 角色 白盒測試也是由測試人員參與，開發人員可以做單元測試 ...
機器學習初入門 舉例中學習
是英文名稱machine learning 簡稱ml 的直譯機器學習領域，又或者更大而化之的說人工智慧方向，因為 阿爾法狗 等一系列的熱門爆點話題，被推到了人前，受到越來越多人的關注 無論你是什麼領域的工作者，都一定多多少少聽說過它的名號。而與此同時，隨著機器學習領域理論的成熟，越來越多的相關技術被...