分到了乙個專案，開發流程是什麼，首先要做什麼？
之前很多人也問過我這個問題，我總是根據經驗不加思索的說出幾個大概步驟：做需求，畫原型，設計資料庫，定架構分層，編碼測試，部署發布。
有這種思路很正常，因為我們一直在嚴格遵循軟體工程的思想，文件很重要，文件驅動。想當年學習寫文件的時候，把十幾個文件都嘗試了一遍，整個寫下來足足用了半個月，印象之深可想而知。進而形成了我們之後的開發流程：組長寫文件，組長畫uml圖，組長畫原型。組長做完這些工作，沒有一周基本是不可能的。但是往往出現這種情況：uml圖剛畫完，原型也快出來了，突然有點需求有問題，或者需求有變更，那麼就得改！！補圖，文件，沒開發呢，修訂版文件1.1已經出來了。組長成了實實在在的文件農，組員成了碼農。組長壓力山大，組員學不到東西。
當然這樣開發也自然有其好處：組長如果很厲害，設計乙個結構效能都不錯的資料庫，需求細節做的也很好，做出來的東西就是想得那樣，也有詳細的文件可查，很好維護。但是也就過於依賴組長了，或許有人說可以把文件分下去寫，但這道理是一樣的，也就是這是乙個開發流程的問題，先出文件再做開發，就是面向實體程式設計，先需求確定，做好實體，從下往上開發。
現在參與了gxpt專案，工期很緊，我們組做的這個塊是對之前的乙個系統的重構。雖然算是有原型了吧，文件就沒有寫那麼多，但是之前的系統還是有好多問題，我在分發任務的時候還是按照之前的思路，作為組長要先把需求弄好，其他組員先搭建開發環境。我做需求用了兩天，做完之後我們就開始設計實體，用了一天。之後才開始全組寫實體，用了一天的時間。實體層出來了，這樣前期的工作算是完成了，之後就是做上層的開發。我們在做專案之初就說本次要採用敏捷開發，但是我們這是敏捷開發嗎？
當時不是。為什麼需要敏捷？我們之前的開發模式只是適用於小作坊或者有積累的重構，如果乙個大的專案，需求都還不確定，如何寫文件，即使需求確定了，寫文件的時間是否消耗的起。當然，敏捷不止是開發文件多少的問題，關鍵是開發流程思路的轉變！敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。充分發掘組員的能力，需求模組分配下去，有專人負責，這樣的開發就是面向需求，有關這個需求實現的介面、service以及實體都需要該人來設計和維護。這樣開發速度很快，還有乙個好處就是快速迭代，對於一些理解偏差的需求能及時發現和修訂。
敏捷，還需要在實踐中慢慢理解，希望本次專案完成後有所提高。
ERP還需要創新嗎
published on 05 19,2006 近日，某erp 公司售前顧問在談到 創新 時語出驚人，這不僅讓erp業內人士大吃一驚，更讓使用者們大跌眼鏡。無獨有偶，浪潮集團高階副總裁王興山也坦言，中國erp儘管走過了近10年，但所面臨的真正挑戰還是產品。二者談的都是大產品的概念 包括狹義的產品概念...
買了 bi 還需要上報表嗎
這個要看實際的需求來確定，bi 主要用於資料分析，所以裡邊也帶有資料呈現的功能，但是乙個比較常見的問題就是 bi 主要側重於資料分析，裡邊展現的結果通常為網格 分組 交叉這幾類格式的報表，稍微複雜點的格式是不支援的，所以如果專案裡邊有格式較為複雜的報表，一般來說還是需要由專業的報表工具來實現的。實際...
網校搭建完成，課程還需要設計嗎？
面對課程效果不好，課程結構不清晰等情況，我們是否認真的想過網校課程的邏輯結構？不同的課程展現形式有什麼特點 適合什麼內容？曾參加過因酷科技的網校運營私享會，某位產品大咖對此有深刻的理解，我也是聽後進行一番總結。先說 課程設計 沒錯，人們的學習模式正在發生著極大的變化，學習過程呈現 非固定 碎片化 狀...