首先和客户的最初接触或深入接触的时候，询问到整体业务模型，(因为最初客户为了降低我们的警觉和报价时间及价格，有可能对业务模型有所隐瞒)，这能加快我们理解所有问题，有的甚至不需要看需求就知道合不合理，现实中能不能用这个系统。
首要職責明確：
1，項目經理：
1），把握需求，everything，整理需求列表，客戶回答的整理，見后面關于問題及bug管理，最終形成一個成形的最終需求。
2），與客戶溝通業務模型達到對系統相同的認知，以避免客戶人員驗收最初需求與開發過程中確認問題最終形成的一致理解的不同導致的問題。
3），驗收tester的結果。
4），搜集程序員的潛在顧慮
5），通知程序員問題及變更管理列表的更新
2，系統分析師：
1），把握需求
2），現實需要－》抽像出軟件開發模型－》設計代碼結構－》設計數據庫，與項目經理一起傳達現實需要和抽像出來的開發模型，以節省其他人員閱讀需求的時間，如開發過程中客戶提供了部分過程，比如數據庫已設計好，也要和客戶溝通明白業務模型與數據庫之間的對應關系并搞懂整體，把握住項目整體不向不可控制的方向發展。
3），整理代碼，檢查每個人的工作是否都按照需求來執行，檢查遞交給Tester之前的開發成果。
4），搜集程序員的潛在顧慮，并考虑解决方案
3，開發者：
1），根據傳達過來的現實需求及開發模型去理解需求，要從整體上理解自己的工作與其他子系統之間的耦合，只有理解現實需要才能發現開發過程中的做法是否合理。
2），認真執行需求及需求變更的要求達到的效果，普通功能自己測試在10遍，有效率及特殊效果的要自行測試在20遍，想辦法發現自己代碼中的不足及考慮問題缺乏的方面，以達到一個中等的提交質量。
3），遇到問題首先和項目經理和系統分析師溝通，并用最直觀的方式說明自己的問題，添加至內部問題列表。
4），每人早上必看問題與變更列表的更新最終決定。
4，Tester:
1），開始就參與到項目中來，一塊理解需求，并發現需求中的問題，是非常有必要的，并不是后期參與，發現前期與實際需要有不一致的地方導致返工的時間會更多。
2），設計用例
3），測試由系統分析師把握的開發人員的開發成果
4），按照需求一章一節測試后，包括程序穩定性、執行效率和業務是否合理性測試，提交測試成果給項目經理
問題及變更管理列表：
采用PMS問題列表現有的方式，不過有所不同
以下為一條記錄：我們可以提取來查看，方便日后的問題和需求跟蹤與原始需求不一致，導致驗收無法順利進行。
字段：
原臺需求分類：取章的名稱
原始需求標題：取小節標題
原始需求內容： 。。。。。。。。。。。。
在需求文檔的location：XX頁XX章XX節
前期問題跟蹤1： 本次跟蹤的郵件主要內容，溝通問題及答案（從郵件或聊天內容中提取出來）
跟蹤1的最終決定
前期問題跟蹤2： 同上
跟蹤2的最終決定
。。。。
需求變更1： 本次變更主要內容
本次變更形成的最終決定
需求變更2： 本次變更主要內容
本次變更形成的最終決定
。。。。。
Bug 跟蹤1：問題描述
Bug 跟蹤1的最終結果
Bug 跟蹤2：問題描述
Bug 跟蹤2的最終結果
。。。。。
會有很多的跟蹤和需求變更，需求變更的和跟蹤的最終決定，跟蹤最終決定可以顯示在一個列表，也就是可以顯示在一塊，形成一個最終決定，這樣其他人員可以直接查看這個客戶與我們協商的最終決定。
此方法的好處是，從第一開始原始需求－》問題－》變更－》bug跟蹤 都能一目了然，我們看到了這個需求到最終需求的一個過程，在和客戶有不同認知的時候可以發給客戶查看，一切都是經過確認的。
目前的弊端是既有excel,也有word,也有郵件，也有聊天，而且在不同的人那里，根本無法順利查閱，最終是什么情況，無法跟蹤。
總結：我發現其他企圖節約成本和時間的做法，實現上是更浪費成本和時間的做法，比如：自已看自己的需求，測試的后期參與，項目中的溝通結果未及時傳達，開發人員不知道需求已變更等
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
