公司推「敏捷」了，我們的產品「被敏捷」了。
本人所在的子產品，在經歷過幾個版本的對於敏捷的自行摸索之後，隨著整個產品進入了浩蕩的敏捷程序，後cmm時代拉開序幕。
前段時間公司內部針對敏捷培訓，本來不屑這種材料，但是仔細看過之後，我對專案成員說，這個材料的是公司下大力氣準備的，很多敏捷的誤區都是前期各版本我們所經歷過的。如敏捷準備度（自動測試，持續整合），不要將敏捷活動當做走過場等等。
敏捷開始，在敏捷開始前，需求分析、介面設計、外部系統介面、內部模組間設計基本完成。
近期一次敏捷回顧。發現幾個問題，讓我感觸頗多。
1、敏捷活動中，模組級設計方案由誰來寫？
大家認可部分story是需要寫一些設計文件的。
專案成員普遍認為，應該由「專業」的設計人員來寫作模組設計文件，並給出專門的時間。
理由如下：
1）專案成員自認為對於本系統沒有全面認知，無法承擔模組設計工作
2）每個story時間並不充裕，算上寫設計的時間，消耗比較多，對於績效而言，不是好事
2、敏捷過程中的測試活動由誰來做？測試人員還是開發人員？
先說明一下，我們產品敏捷之後，開發測試在團隊管理上逐步融合，但是技能上差距很大。
說說我的看法。
在開發團隊不具備一定快速設計能力、持續重構能力、自動測試能力的情況下，強行上馬敏捷，代價很大，效果一般。
1、開發團隊不具備快速設計能力，在需求、外部介面、整體方案明確的情況下，無法快速給出模組級設計方案，或者直接構思出**實施方案，基本無法滿足敏捷快速開發、快速交付的要求。團隊中具備設計能力的人員，將會不堪重負。成為團隊向前推進 的瓶頸
2、持續重構能力不具備，對於快速設計方案，在需求變化情況下，無法迅速的進行**重構、解決技術債務，同時應對新的變化。在後續迭代中，將會舉步維艱，漸行漸慢。
3、不具備自動測試能力，隨著迭代交付的進行，修改引入問題將會無法得到有效控制，敏捷過程中通過手動測試基本是人力上無法承擔的。
4、開發成員，不具備基本的測試技能。將會直接影響開發質量。傳統的cmmv字形過程的中，開發人員要針對srs、hld、lld進行對應的測試設計和測試活動：st、it、ut。從流程上能夠牽引開發人員主動思考基本測試原則。如果敏捷過程中一味依賴原有測試人員進行把關，相當於去除了ut和it，直接讓測試人員st。效果可想而知。
時間有些晚了，先謝這麼多吧，後面有時間，再續。
企業的後ERP時代
國內應用erp軟體的企業很多，其中成功應用的案例也很多。我公司從2003年開始正式執行，國內包括庫存管理 成功管理 銷售管理和財務管理。從一開始，系統的整合性就很高，所以模組的資料都自動傳送到財務。可以說，我公司應用erp五年多以來，是非常成功的。國內應用erp企業，在當初啟動erp時，大多數都是被...
企業的後ERP時代
國內應用erp軟體的企業很多，其中成功應用的案例也很多。我公司從2003年開始正式執行，國內包括庫存管理 成功管理 銷售管理和財務管理。從一開始，系統的整合性就很高，所以模組的資料都自動傳送到財務。可以說，我公司應用erp五年多以來，是非常成功的。國內應用erp企業，在當初啟動erp時，大多數都是被...
後考研時代的前端學習
考研之旅塵埃落定也有近半個月之多,雖然沒有有幸被第一志願錄取,但也算是遂了人願轉了一圈回到高中最希望去的哈爾濱工程大學,讓我自己有學可讀,重新給我乙個機會可以為庸庸碌碌的本科階段乙個彌補的機會.休息也休息的差不多,該找點事情做了,否則距離開學的小半年時間也是荒廢,索性學習一門程式語言,現在不正是呼籲...