Flow VS Agile

還是老話題，過程 VS 敏捷。

公司對項目過程有一定的要求，必須產出要求的Flow Documents。雖然沒有強迫一定要上一個Flow的文檔產出才能做下一個Flow文檔，允許平行處理。但是還是有一定的依賴。

目前碰到的一個問題就是，Flow裡要產出Software Develop Plan才可以到進行開發階段。而公司和使用者在工時上面又咬的很緊。真的很為難。其實按照過程式控制制來說，確實需要計劃的比較準確才可以開始開發。但是按照敏捷的觀點應該是越早動工越好，而不在於計劃又多準確，計劃時刻都是在變的。敏捷強調的是產出和價值，儘早做出使用者可用的“東西”出來。目前只能抓緊評估以及與使用者溝通，促使儘早進入Iteration。

第一次接觸公司Product External Special文檔。感覺有點像敏捷裡的User Story，只不過比User Story更文檔化一點，更規範一點。但我覺得都可以理解為是在做使用者需求。這裡我要做檢討，前期我做PES文檔時沒有很好的與客戶溝通，只是在靠我自己的理解在編寫PES，這是非常不好的。後面我會多跟客戶溝通，更好的確定使用者需求是什麼。而且目前我正在嘗試用User Story的方式去和使用者溝通去理解需求，然後逐步添加到PES中去。

還有一點要注意的，因為項目前期做業務分析也做的不多，所以這裡就非常必要把營運目標加進來，再則就是重要的商務程序。通過商務程序去理解使用者情境、使用者故事，更好的引導使用者挖掘使用者真正有價值的Story。

 

這裡引入一個概念：軟體需求的三個層次

1.業務需求

       描述組織或客戶的高層次目標，通常問題定義本身就是業務需求。業務需求就是系統目標，它必須是業務導向、可度量、合理、可行的。這類需求通常來自與高層，例如項目投資人、購買產品的客戶、實際使用者的管理者、市場營銷部門或產品策劃部門。業務需求從總體上描述了為什麼要開發系統（why），組織希望達到什麼目標。一般使用前景和範圍（vision and scope）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。組織願景是一個組織對將使用的軟體系統所要達成的目標的預期期望。比如“希望實施CRM後公司的客戶滿意度達到80％以上”就是一條組織願景。這些最進階別的需求數量很少（2－5條）。

2.使用者需求

       使用者需求是指描述使用者使用產品必須要完成什麼任務，怎麼完成需求，通常是在問題定義的基礎上進行使用者訪談、調查，對使用者使用的情境進行整理，從而建立從使用者角度的需求。使用者需求必須能夠體現軟體系統將給使用者帶來的業務價值 ，或使用者要求系統必須能完成的任務，也就是說使用者需求描述了使用者能使用系統來做些什麼（what），這個層次的需求是非常重要的。用例、使用者故事、特性等都是表達使用者需求的有效途徑。戶需求層次上的重心轉移到如何收集使用者的需求上，即確定角色和角色的用例，需求分析是很難的，因為很多需求是隱性的，很難擷取，更難保證需求完整，而需求又是易變的。

3.功能需求

       系統分析員描述 開發人員在產品中實現的軟體功能，使用者利用這些功能來完成任務，滿足業務需求。功能需求是需求的主體，它描述的是開發人員如何設計具體的解決方案來實現這些需求（how），其數量往往比使用者需求高一個數量級。 這些需求記錄在軟體需求規格說明（Software Requirments Specification）中。SRS完整地描述了軟體系統的預期特性。SRS我們一般把它當作文檔，其實，SRS還可以是包含需求資訊的資料庫或試算表；或者是儲存在商業需求管理工
具中的資訊；而對於小型項目，甚至可能是一疊索引卡片。開發、測試、品質保證、專案管理和其他相關的項目功能都要用到SRS。