還是老話題，過程 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。