近日，領導給安排了指導某項目的需求分析工作，該項目面臨時間緊、任務重、人員少的窘境。需求分析只有4人，幾個複雜模塊都壓在1個經驗豐富的老手身上，其他3人經驗不足。目前最嚴峻問題是，團隊產能不足、效率低下，項目需求分析很可能要延期的風險。
考慮到有2個重點複雜模塊的需求分析仍未開始，今天組織了次小組會議，調整了下內部工作流程。將原來按照“原型->需規->客戶確認”一個接一個模塊串行推進的次序，改爲將多個模塊先做原型，需規再統一最後寫的串行順序來做。這樣的好處是，儘快開工搭出架子，避免串行工作導致後續時間倉促來不及。
對照了下敏捷宣言12條原則，今天至少做到了其中5條，一個小小的改變，也許會改變目前的困境！
1、我們的最高目標是，通過儘早和持續地交付有價值的軟件來滿足客戶。
對策：小組會上，跟組員重申了當前形勢下，儘快將多個模塊需求分析並行推進的必要性。
2、歡迎對需求提出變更——即使是在項目開發後期。要善於利用需求變更，幫助客戶獲得競爭優勢。
3、要不斷交付可用的軟件，週期從幾周到幾個月不等，且越短越好。
4、項目過程中，業務人員與開發人員必須在一起工作。
5、要善於激勵項目人員，給他們以所需要的環境和支持，並相信他們能夠完成任務。
對策：核心骨幹反映每天上下班通勤要4小時，項目負責人特批允許近期他在家辦公。
6、無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。
對策：疫情期間，電話會不直接，直接進會議室面對面談，確實溝通效率高。
7、可用的軟件是衡量進度的主要指標。
8、敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該能夠保持恆久穩定的進展速度。
對策：針對用戶方分部門分不同崗位各自提需求，每人只負責自己一攤缺乏整體業務梳理，爲避免需求設計被隨意推翻，要求啓動一個模塊的分析前，要拉上用戶端涉及到部門的所有相關人員參會，以便於後期的功能點統一確認，減少返工
9、對技術的精益求精以及對設計的不斷完善將提升敏捷性。
10、要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術。
11、最佳的架構、需求和設計出自於自組織的團隊。
12、團隊要定期反省如何能夠做到更有效，並相應地調整團隊的行爲。
對策：約定每週召開兩次小組會議，彙報進展和問題討論。