封閉式時間緊、任務急，而且是好不容易向老闆那裡要來的資源。還有，沒有其它的干擾，所以對於我們這個
team
來說，應該是沒有任何藉口的，不管這是乙個產品研發，還是乙個專案開發，都不容許有任何差錯。
但是在前期沒有客戶直接接觸，確切的說，只有乙個產品經理獲得了一些基本的客戶需求時，我們怎麼做出成績，或者相對的能做出一些被認可的東西來了呢？思來想去，我們沒有按原來的從需求分析到測試到編碼的傳統流程。
我們使用了敏捷。
這裡不敢說完全按照了
scrum
，或者其它的敏捷過程管理，因為在敏捷開發的群集中，我們畢竟還算新手，但是為了能輕裝上陣，速度取勝，我們盡量的把一些省時省力的，而且輕文件的好的實踐引入到封閉式開發中。在這個時間段，我們只有把減輕文件，從開發的平行化轉為開發的縱向化，即從流程為主導轉向以業務為主導
瀑布過程
原來的以過程為主導就是先把需求做細，向各方確認，然後由產品經理彙總，再交於介面互動設計師和架構師，再經確認後再交給開發去編碼，最後功能點全都達標後，再交給測試，最後是
qa。這樣有個問題，好多文章都說了，錯誤到最後才這發檢查出來，或者直接被否定了，鬱悶。
封閉式開發是不容許出現這種問題的，我們只有乙個目標，做出客戶想要的。所以，我們只能
從業務導向，把乙個需求從基本的描述到開發，到測試，深入的做好乙個個需求，到給客戶看的時候，我們就能拿得出手，講的好聽點，我們可以隨時拿出乙個可以演示的版本來給產品經理去做演示。而不是原來的到提交測試前一天，開發人員的**都是寫好的，可是沒有經過驗證，因為測試沒過。每個功能點的完成度都是
90%多，沒有乙個版本是拿得出來的。客戶急了，我們的老闆更急。
scrum過程
上面講了一些閒話，主要是說明了為什麼在我們在封閉式開發中要引用敏捷，下面著重介紹幾種比較好用的
幾條建議：
1.
輕文件描述
不要複雜的，重量級的需求說明書。每個需我們簡單的用一段話，或乙個小小的流程圖來說明，有時候直接寫到了筆記本上，根本沒有電子化。
下面是簡單的乙個使用者故事。假設我們開發的是乙個類似於
qq的即時通訊專案，這裡描述的是乙個建立群的故事：
故事描述：
作為乙個使用我們產品的客戶，我需要建立乙個群組，並且選定群組的人數和群組名稱，以用來向這些群組內的所有人傳送相同的訊息，而不用為每個人傳送。
簡單流程圖：
使用者接受測試：
點選建立群組按扭，輸入群名稱，指定群成員，建立群，系統返回成功或失敗。
2.
單元測試
每個小組對於自己開發的模組在給其它小組呼叫的時候，都要至少通過單元測試，這裡特別要強調對於輸入驗證和輸出格式返回。有時候當介面的引數十分特別的時候會減少反覆的時間。
如果team
中的其他人呼叫到你的介面，出現了問題，你可以及時把這個
bug轉化成單元測試，下次提交的時候則同一樣的錯誤不會重犯。如果有時間多的話，可以提高下**覆蓋率，也是一種不錯的選擇哦。
同理，如果你發現了其它小組提供的介面中有些
bug，則也可以為這個
bug編寫乙個單元測試用例。這樣，使這個
bug重複出現的成本變成零，也方便驗證那個小組在重構後會反覆的問題。
3.
**交流（
tdd）
如第2點所示，我們之間的呼叫和被呼叫，都被固化在了單元測試中，不用直正到產品中的**中才能發現或被除錯。小組間不再花更多的時間在爭吵或者改沒改上面，只要原來的測試能滿足，現在卻不能滿足了，誰的問題，也就沒有爭的必要了。
4.
每日構建
這個十分十分的重要，要及時給大家匯報，我們現在完成的故事是多少了，現在能看到結果是哪些，時間安排
[l2]
，我們每天都有乙個小時專門用於匯報和討論，在這裡大家能及時看到完的業務故事情況。也方便進行討論。如果乙個版本比較穩定，我們會打乙個版本，並且發布到外網上去。並在原始碼上做好版本的標記。
5.
編碼規範
我們是用
rest
的模式進行開發，所以要對
url進行規範，每個小組在開發時，都需提前把自己的
url頭，和可能用的到列表都發給乙個人進行管理。
功能說明
url增**
增加使用者
登入
weather/
查詢本地天氣
?areacode=
weather/
查詢溫度差
**編寫和命名規範是直接用公司的統一規範。
6.
主動索取任務
原來是經理對所有開發人員說，你的任務是什麼，你的是任務是那些。現我們一開始在討論會中把所有的任務都列了出來。然後，我們自己規劃這兩周能做哪任務。化備動為主動。
7.
互相幫助
由於每個開發人員開發效率不同，可能有的先完成任務了，有的還沒完成。由於我們不再像原來的那樣，資料庫開發只管資料庫開發，前台只管前台，框架只管框架。如果後台人員完成開發任務了，會主動幫助前台進行開發。像我雖然是後台通訊開發小組的，可是在完成自己的開發任務後，我也參與了樣式布局和前台指令碼的開發。任務是我們自己選的，一定要一起完成他。
8.
**審查
按照編碼規範去檢視**，乙個迭代大概花半天時間。再半天時間重構**和用測試去驗證。
9.
白板討論
我們討論的時候不再紙上畫，我們也可以用白板。畫簡單的流程圖或序列圖。這樣讓更多相關人員都能進來。
不足之處：
1.
整合測試
由於我們是基於單個故事開發，到整合測試的時候，可能由於每個小組進度不一，而時間會有所拖延。所以至少要花半天時間來做這個工作，而不是原先期望的半小時內。在這個時候，介面會有所調整，要及時編寫對應的單元測試進行驗證。
2.
**覆蓋率
由於時間不足，這部份沒有達到理想的
90%以上。只能
80%多吧。
3.
文件不足
我們大多以**為文件，把命名做好了後，幾乎沒有寫什麼文件，需要多方確認的需求除外。如果有時間多，還是需要把這些基本的故事整入
backlog
中。以備做戰鬥力評估和團隊成長的記錄。
思路決定出路！
目錄：
封閉式開發小記(3)：封閉式開發的人員配備
封閉式開發小記(4)：封閉式開發的架構設計
封閉式開發小記(5)：封閉式開發的敏捷開發
封閉式開發小記(6)：封閉式開發的文件管理
封閉式開發小記(8)：封閉式開發的專案討論
(10.9)
封閉式開發小記(9)：封閉式開發的最後一天
(10.10)
封閉式開發小記(10)：封閉式開發的專案匯報(10.11)
封閉式開發小記 1 封閉式開發的基本裝備
金秋十月，丹佳飄香，正好有些時間整理下在山里的日子，大家一直在尋找銀彈 上個月公司上了個新專案，公司決定在全公司 內選出乙個team 由乙個技術 經理和乙個產品經理帶隊，前期準備主要有以下幾個東西 筆記本 14臺 台式電腦 5臺，其中三颱伺服器，2臺是給資料處理人員使用。無線路由 三個 回來的時間都...
具體數學 3 和式與封閉式
將 sum nk 轉為封閉式 方法 成套方法 轉為遞迴式 令 s n sum nk 不難看出,s n s n 1 n 一般化令 r n 為 s n 的一般形式 即 r 0 alpha qquad r n r n 1 beta n gamma 1 令 r n 1 therefore r 0 1 the...
今天重點分析乙隻封閉式基金
豐和 184721 份額30億。投資風格 價值型。管理公司 嘉實。二季度報告已經出來 淨值從36億增長到43億 主要是 增加了6個億，債券現金類增加約1個億 截止6月30日的每單位淨值為1。4354元 其中 合1。12元，債券合0。29元，貨幣等0。02元 當天的交易 是0。764 今天是0。73 ...