See Also
- Thinking Everyday
- Thinking Everyday II
- Thinking Everyday III
- Thinking Everyday IV
Shall We Talk?
如果會議中有人可以不發言, 那他就沒有參加會議的必要
專案經理最佔便宜
傳統Team 專案經理最佔便宜, 所有人都向他單線彙報, 出了事都找他, 他知道所有的問題和解決方案, 隨著項目的進行, 他的知識會被動的越來越豐富. Truck Number的一個執行個體
公交 vs. 地鐵
說的是客戶合作和開發節奏. 傳統開發就像擠公交, 影響路況的因素太多, 這趟上不去下趟不知啥時候, 所以每次發布都拚命塞feature. 好的開發節奏應該像地鐵, 穩定的持續的帶走一批批乘客, 交付一批批feature
南轅北轍
說的是提高開發效率為啥非得用敏捷, 選擇高效的平台,工具,庫不也可以提高效率嗎? 在效率上確實有很多方式. 而敏捷更關注有效性的問題. 你的平台工具和庫都極端高效, 就像你有最好的馬最好的車最好的裝備, 可以一天完成十個feature或跑個一千裡, 可它們保證不了這是正確的feature, 正確的方向. 敏捷也保證不了, 但它利用一切手段讓方向有所偏離的時候能儘快發現.
專案經理是個不好的暗示, Team Manager over Project Manager
Project Manager 是個不好的暗示,它或多或少的影響擔當這個職責的人的行為. 如果你覺得團隊建設重要, 那麼使用 Team Manager 這個頭銜,會微妙的潛在的影響擔當這個職責的人的行為. 我們說的是心理學.
天天都是新項目?
通常剛開始一個項目, 剛進入一個新團隊的時候, 積極性和創造力比較高. 那我們只需要創造一種環境, 讓大家經常有一種加入新項目的感覺
有時寫文檔有一種不安的感覺
可能此時應該有更好的溝通或傳播方式. 文檔代表的是單向的交流和較長的反饋周期, 此時你的任務是否需要更及時和更頻繁的反饋?
曾經的兩個簽名檔
- IDE 不應該提供拷貝粘貼功能.
- 點穴? 畫過. 我還給取了個特別好聽的名字,叫葵花點穴手, 後來聽說一幫小混混還在那練呢… | 科幻? 寫過. 我還給取了個特別好聽的名字,叫極限編程, 後來聽說一幫小混混還在那練呢…
古典經濟學與瀑布開發
犯了同樣的錯誤: 假設知識和資訊是完備的.
需求分析, 是分析
不是滿足使用者的每一個需求, 而是分析; 不是story寫作, 而是分析
與客戶少溝通一句話, 可能多寫1000行代碼
忘了收集證據了
兲朝夜談
F-16墜機: 區別在於, 每一次重大事故, 或者事故之後, 都帶來了某種改變, 阻止同樣事故再次發生. 每次冤假錯案背後, 都會導致法律的修訂. 在兲朝, 是兲朝夜談
站立會議最初文章的誤導
不應該說昨天做了什麼, 今天要做什麼, 而是發現什麼問題, 需要共用什麼資訊等, 就會好的多
測地線
空間的形狀: 粒子沿著最(省力/短)的路線運動, 測地線, 人是不是也一樣?
理論過分雕琢, 意味著需要新的模型
代碼設計也一樣
TDD, 獨立的開發方法學
- TDD 最有價值的一個方面是它使得我們在同一時間只關注一件事情, 要麼是在編碼, 要麼是在重構, 永遠也不會在同一時間做兩件事情
- TDD 是一種推導設計和實現的通用方法, 無論對簡單情況還是複雜問題, 區別在於這個推導過程時間長短的問題. 可對於複雜問題, 無論什麼方法都會時間相對長一點
- TDD的優勢在於把 “把問題弄清楚” 和 “解決問題” 統一在一個過程中, 並且在這個過程中隨時可以以代碼的形式驗證對問題的理解
- 不能同時忽略設計和重構
- 不要掩耳盜鈴, 視而不見, 有時設計是最簡單的實現.