今天在參加與吳穹博士的敏捷交流中不禁讓我想起了目前正在進行的乙個專案。
專案是我們與國外的開發團隊合作開發，說白了就是我們給出需求，他們來設計、開發、測試，且對方是嚴格的cmmi5。
專案的初期是對方的se與我們通過原型來收集需求，之後他們會根據對需求的理解整理出乙個設計需求，實際上就是乙個功能分解，然後根據設計需求進行專案估算（開發+測試），測試團隊也會使用這個文件來寫測試用例。另外對方還會準備乙份軟體需求規格。
過程中我發現，原型的製作大概耗費了我們一兩個月時間（由於是第一次合作+時差問題，這點可以理解），之後的事情就讓我感覺不是很爽了：
之後他們就開始準備設計需求文件，需求文件的內容也是反反覆覆，review來review去，而且寫需求設計文件的se很少參與原型的討論，折騰了幾個星期設計文件終於出來了....
再後面，開始準備軟體需求規格了，這份軟體需求規格是由他們的開發團隊分工寫出來的，洋洋灑灑寫了n頁，完成後發給我們review，結果發現，這個軟體需求規格實際就是前期原型製作的文本版，而且是由開發團隊來寫的，由於理解問題結果錯誤還不少，澄清來澄清去.....
今天吳博士就講到可以用user story+原型來給出需求，我覺得這個正好能解決我遇到的問題：
1、基於user story，我們應該是可以估算專案規模的，這樣就不需要準備他們的設計需求文件了；
2、測試團隊可以基於這兩樣交付件來編寫測試用例，而且基於user story測試團隊能真正了解功能的意圖，這樣才能設計出更好的測試用例並及時發現問題；
3、其實我覺得這時需求規格完全可以省掉不寫了；
這樣的話即解決了開發/測試團隊不能真正理解系統使用的問題，也省了對方和我們的工作量。
但是如何使用user story挖掘並完整描述系統需求應該也不是一件簡單的事情。
拿什麼來承救你，我的爺爺？！
爺爺 小的時候，你照顧我 我長大了，您卻要走了 讓我把事業放下，來照顧你，爺爺！前幾天，家裡人打 告訴我，爺爺您病得很嚴重，連說話的力氣也沒有了。您是很想我回來看看您吧，還想交代很多事給我吧！但是，你一聽到家裡人說怕影響我的工作，你就搖頭了，就叮囑家人不要我回來看你。上面是我聽到 寫的話，爺爺，有時...
我拿什麼來簡化你，我的保養單？
今天以前的同事和我聊起it 系統的乙個問題。按照itil理論來分析，我們談論的是ppt中 t 即技術 工具。他的疑問在於如何自動生成保養單據？每天他都為此而大傷腦筋。保養是計畫性的工作，內容統一，差別的只是時間。如果每次都是人工來開單，乙個月有上百張保養單，量很大，開單的人也很累。就此問題，我詢問過...
阿蒙 我拿什麼來留你 我的人才
軟體業的人才流動率之高，已成為眾所周知之事，在我過去的若干嘮叨文章裡也不只一次地提到過這個問題，作過一些簡單的原因分析，也曾不止一次地提倡程式設計師的人文管理，我們 都不想成為一種程式設計的機器，不想成為企業利用的工具，讓技術成為時尚，讓程式設計變得快樂 這是多麼美妙的理想，我們為什麼不去努力實現呢...