從需求分析到開發上線的一些理解
軟體開發一般分為 問題收集，需求分析、軟體設計、開發、測試上線幾個階段。我將會以我過去的學習和經驗從需求分析階段開始談起。
在我們開發軟體產品之前，我們先要問自己幾個問題。我們的目標群體是哪些人？它的核心功能是什麼，滿足了使用者什麼樣的痛點需求？如果這些沒想好，我想很難去開發好一款好的軟體產品。然後就是我們應該考慮它有什麼樣的價值，它能給公司或者說老闆股東們帶來多少價值或者商業機會。
在需求分析階段，你會發現需求不是一個，或者兩個，而是很多個，它們是來自不同人的需求，而我們應該如何權衡呢？我們可以從需求的 緊急程度、使用者的量級、投入的回報比、風險 等角度考慮。假如，這幾個參考仍然不能做出選擇，應該按照公司或者部門的戰略發展方向走，讓最高領導人幫忙選擇和推動。
明確需求，將使用者的需求轉化成產品功能，劃分功能模組，對輕重緩急的進行排序，最終轉化為 版本計劃 。 一般以兩週作為一個版本迭代週期（非APP版本）。若是 需求變更 ，需要召開會議，討論是否新變更能夠加入當前版本迭代週期裡。會議時間視緊急情況而定。同時，一般不允許在迭代第二週插入或者變更需求。
在我們需求功能模組確定之後，我們的一個版本里面，包含哪些內容呢？假如我們一個迭代開發團隊有2個前端、1個後端開發人員。有A 、B 、C三個功能，一個迭代，10個工作日。
前端：
A需要5天，B需要10天，C需要五天，
後端：
A需要3天，B需要8天，C需要4天
最終，雖然B功能前端開發已經完成，但是後端開發資源不足，可能我們會選擇A、C功能進入本次版本釋出。B將進入下一個版本釋出。假如A、B、C都不能進入版本釋出，可能功能模組任務還可以拆得更小。總之每次版本釋出不應該是空內容。
上述還涉及到一個重要的過程，那就是對於功能點複雜度和開發工時的評估。我們可以對一個 功能複雜度 劃分為1、3、5、8個點。一開始，我們可以選擇以前的一個開發任務作為參考，比如，列表從單個條件支援多個條件篩選。大家開始投票，假如多數投成3個點，那就按照此任務作為3個點 的標準（後面可不斷優化），將其他需求與其比較、投票。最終我們會得到所有需求的功能點的總和（有什麼用，接下來會提到）。另外，一般對於8個點的功能，可以繼續拆分成更小的點。所以通常不會有直接8個點的任務。
對於一個功能釋出所需的開發量、工時，不能片面的按照前端人員，或者後端人員去評估。而是兩者結合。因為一個功能的完全交付時間，應該是按照最長的一方工時做為最終的完成時間。
綜上所述，我們按照先前的假設，可能會得到一份這樣的迭代開發計劃表：
最後，走完對應的測試、上線流程，釋出版本上線通知。同時，我們會得到一個版本里的功能點總數。這個點數可以作為衡量團隊開發水平的一個參考依據，當一個team在一個開發週期內完成的點數越高，他們的能力越強，當他們完成的點數有明顯的提升時，說明團隊的水平提升了或者大家最近加班比較多。另外強調， 功能點數並不是代表所需的開發量 。比如實現一個複雜的演算法和修改1000欄位的顏色樣式，後者開發量雖然大耗時長，但是並不複雜。但是仔細想想，為什麼這個團隊一直選擇做一些複雜度低的工作。只能說明一個問題，他們的能力有待提高。