1、介紹
通過證書驗證用戶身份（瀏覽器），其核心是利用cookie實現http和https的信息共享（同域名）。如http://test.abc.com/app/index.html 發現未驗證后，跳轉到https://test.abc.com:443/app/checkCrt.html身份驗證，要求出去證書，確認后將身份信息帶入http請求頭部，跳轉到原請求頁面（http://test.abc.com/app/index.html ），讀取身份信息后進入頁面(出于安全考慮Cookie需要加密)。
流程圖
流程說明：
登錄流程詳細介紹：
1）. 未登錄用戶訪問頁面 如：http://test.abc.com/app/index.html
2）. 【CertAuthValve】判斷是否訪問受限制資源，如訪問受限制的資源則判斷用戶身份是否已驗證，未驗證則將用戶重定向到身份驗證頁面，原始請求的url做為
query的一部分，登錄成功后可以跳轉回來， 如：https://test.abc.com:443/app/checkCrt.htm?done=/index.html。
3）. 【CertAuthValve】對于https請求，apache讀取請求提供的用戶證書，獲取證書中的郵件地址，并將該信息寫入請求頭中。
4）. 【GetUserInfoValve】讀取請求頭，獲取剛剛設置的用戶郵件地址信息，進一步獲取用戶的詳細信息，然后將這些信息加密后放入cookie中。
5）. 登錄完成，將用戶外部重定向回原始頁面。
2、具體實現
1）、安裝apache、ssh、java、jboss等環境，略。
2）、生成服務證書和服務密碼
openssl req -new -x509 -nodes -out /home/admin/app/conf/ssl.crt/server.crt -keyout /home/admin/app/conf/ssl.crt/server.key -days 3600
因為要和內網證書交互，所以需要一個內網證書公鑰文件，可以通過以下方式獲取:
獲取方法：IE->工具->Internet選項->內容->證書->受信任的根證書頒發機構，找到intranet行，點擊導出，選擇下一步，選擇Base64編碼X.509,將證書文件保存為intranet-ca.crt，拷貝到目錄/home/admin/app/conf/ssl.crt/。
3）、apache(httpd.conf)配置
應用和身份驗證頁面放在一起，所以需要同時配置兩個虛擬主機，同時監聽80（處理http請求）、443（處理https請求）端口。
#監聽端口Listen 80Listen 443#app的虛擬主機配置NameVirtualHost *:80
<VirtualHost *:80>
ServerAdmin sa@abc.com
ServerName test.abc.com
DocumentRoot /home/admin/app/target/app/htdocs/
</VirtualHost>#身份驗證的虛擬主機配置NameVirtualHost *:443
<VirtualHost *:443>
ServerAdmin sa@abc.com
ServerName test.abc.com
DocumentRoot /home/admin/app/target/app/htdocs/
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+SSLv3:+EXP:+eNULL
#該指令為虛擬主機指定證書文件名。
SSLCertificateFile /home/
admin/app/conf/ssl.crt/server.crt
#該指令為證書指定一個對應的私鑰文件
SSLCertificateKeyFile /home
/admin/app/conf/ssl.crt/server.key
#該指令為指定一個包含Certificate Authority證書的文件
SSLCACertificateFile /home/admin/app/conf/ssl.crt/intranet-ca.cer
SSLProxyEngine on
RewriteEngine on
#設置客戶端證書驗證為必須
SSLVerifyClient require
#因為一個CA證書能夠被另一個CA證書驗證，所以可以形成一個CA證書鏈.使用該指令可指定服務器驗證用戶證書時可以查找多少個CA證明。
#設置認證深度：一般用默認10。
SSLVerifyDepth 10
#把mod_ssl里的變量變為全局環境的變量
RequestHeader unset SSL_CLIENT_S_DN_Email
RequestHeader add SSL_CLIENT_S_DN_Email %{SSL_CLIENT_S_DN_Email}e
</VirtualHost>
4)、代碼片段
//CertAuthValve.java
//判斷session中是否有用戶郵箱地址
SessionValue session = SessionHelper.getSessionValue(rundata);
if (StringUtil.isNotEmpty(session.getCropEmail())) {
return null;
}
// 從內網證書中獲取用戶郵箱地址: SSL_CLIENT_S_DN_Email
String cropEmail = rundata.getRequest().getHeader(SSL_CLIENT_HEADER_MAIL);
if (StringUtil.isNotEmpty(cropEmail)) {
//將郵箱地址保存到session
session.setCropEmail(cropEmail);
SessionHelper.saveSessionValue(rundata, session);
if (log.isDebugEnabled()) {
log.debug("用戶" + session.getCropEmail() + "已經通過證書驗證");
}
return null;
}
URIBrokerService uriBrokerService = (URIBrokerService) getWebxComponent().getService(
URIBrokerService.SERVICE_NAME);
URIBroker noPermissionUriBroker = uriBrokerService.getURIBroker(CHECK_CRT_URL);
//請求的原始URL & 驗證的URL
String requestPath = rundata.getPathInfo().replace("_", "");
String checkCrtUrl = (String) noPermissionUriBroker.getPath().get(
noPermissionUriBroker.getPath().size() - 1);
try {
//原始請求判斷
if (requestPath.equalsIgnoreCase(checkCrtUrl)) {
//當前是https請求，但是依然不能得到證書信息,轉到禁止頁面
//(要將禁止頁面加入到允許訪問的配置文件中，不然會導致循環重定向)
URIBroker uriBroker = uriBrokerService.getURIBroker("forbidden");
rundata.setRedirectLocation(uriBroker.render());
} else {
//轉到證書驗證頁面
rundata.setRedirectLocation(noPermissionUriBroker.render() + "?done=" + rundata.getPathInfo());
}
} catch (IOException e) {
log.error("權限驗證重定向出錯", e);
}
return new BreakPipeline();
//GetUserInfoValve.java
Object user = rundata.getSession().getAttribute("userInfo");
if (user == null) {
SessionValue session = SessionHelper.getSessionValue(rundata);
String email = session.getCropEmail();
Employe employe = PersonInfoUtil.getPersonInfoByEmail(email);
// 寫入cookie
session.setEmployeeId(employe.getEmployeId());
session.setName(employe.getName());
session.setCropEmail(employe.getEmail());
SessionHelper.saveSessionValue(rundata, session);
}
采集到花瓣
posted @
2011-12-09 16:09 josson 閱讀(2444) |
評論 (0) |
編輯 收藏
受限于證書的原因，以前經常不得已用IE打開一些應用。其實有一工具可以幫助我們導出IE證書，用于firefox，解決證書的困惑。
采集到花瓣
posted @
2011-12-09 13:54 josson 閱讀(3112) |
評論 (1) |
編輯 收藏 互聯網的產品大都是面向海量用戶的服務，且用戶分布區域廣泛，其教育水平、習慣也大多不同，具有高度不確定性，我們必須非常關注用戶的行為和反饋。因而，在互聯網產品服務的整個用戶研究，需求分析、產品研發及交付服務的過程中，都采用探索式、適應性的研發理念進行產品的研發。通常，會把整個產品研發周期劃分為若干個迭代，采用迭代式的演進過程，不斷的去交付新的產品特性，并通過觀察用戶的行為和反饋獲取，進而隨時調整產品的思路和方向。一切以用戶價值為核心是互聯網產品最核心的特點，而以價值驅動的敏捷開發方法非常符合這一特點。
一、敏捷項目管理實踐 
從阿里軟件開始，內貿團隊就一直在實行著敏捷項目管理實踐，通過小步快跑，快速迭代、增量交付用戶價值，不斷獲取用戶反饋，持續、快速的調整產品，驗證并適合用戶價值。正是通過這些實踐活動，我們以迭代的、增量的交付用戶價值，最大限度的保證產品朝著符合用戶實際需求方向發展。目前，在內貿團隊應用較成熟的敏捷實踐活動有：
1)、迭代計劃(Sprint Planning Meeting)
2)、每日晨會(Daily Scrum Meeting) & 任務墻(Task Wall)
3)、功能預演(Spring Review)
4)、項目總結(Retrospect Meeting)
5)、結對編程(Pair Programming)
6)、其他技術實踐活動等
二、敏捷團隊
１)、自組織文化
如google、facebook等互聯網企業，他們很少甚至沒有特定的項目流程，通常怎么敏捷怎么做，具有濃厚的工程師驅動文化。我們則有較完整的開發流程指導和規范我們的項目研發工作，相比而言，喪失了一些靈活性和積極性，不利于我們工程師自我管理、自我驅動意識的培養。臃腫、缺乏靈活性的流程同互聯網產品快速更新、快速發展是不相適應的，同時也弱化我們的責任心意識。除了遵守詳盡的流程，我們是否可以換個角度、換種方法，提倡和營造一種自我管理、自我驅動的開發文化，省卻一些并不能給我們帶來幫助卻影響效率的流程呢？
敏捷團隊的自組織特性弱化了團隊技術領導這個角色，強調自我管理和自我驅動。雖然這對工程師的素質要求更高，相對技術能力更難提高。但是，團隊導向很重要，我們努力營造這樣的氛圍，從小團隊做起，逐漸鍛煉和培養自組織團隊。相信在這樣的開發氛圍下，會讓我們做的更高效、更敏捷，可以走的更穩、更遠。
２）、追求一體化
一體化團隊作為敏捷開發方法中最具精益思想基因的實踐，是指每個項目團隊包括分析，開發，測試等角色，使團隊滿足一個需求從設計，開發到測試各個階段順利完成，達到符合質量標準并滿足需求的軟件。這種以項目/產品為單位的虛擬團隊，坐在一起，全身心的為共同的目標而努力，可以更好的凝聚項目組中的各種角色，消除部門墻。
3）、追求全功能
這里所指的全功能是希望項目團隊能打破工程師角色之間的邊界，如研發、測試和前端工程師的界線，消除開發、測試流程中一些潛在浪費，提高效率。在項目團隊內部通過角色互換，不限角色的結對工作，加強不同角色，不同模塊間的知識傳遞，打破技術壁壘，幫助員工從不同視角理解項目，鍛煉技能，進而增加團隊均衡生產的能力。
為什么要提倡打破邊界？項目整體效率依賴于項目過程中各環節的工作效率，而整體效率的優化往往依賴于均衡生產(精益思想的按需生產)，即消除生產的波峰(過度生產)和波谷(生產不足)，只有局部效率的增加無法直接轉換為整體效率的增加(就象桶能裝多少水，決定于最短的那塊板)。整體效率的優化要求IT團隊消除技能壁壘，培養多面手，根據計劃的的變動，彈性地調整任務，達到各角色和流程之間的平衡。
三、質量保證
我們追求開發效率，同時也注重項目質量。如何去保證質量？就象美國的一位教授愛德化.戴明（W.Edwards Deming）所說：“我們應該停止依靠大量檢驗來保證質量，而是要改進工藝流程，從一開始就生產出優質的產品”。我們要在整個開發過程中多個環節去保證質量。同時，質量保證是整個團隊的責任，就如同前面所說的追求全功能團隊，打破邊界。
至于在哪些環節采用哪些實踐，我們先做個分類，按是否能被系統用戶感知將質量問題區分內部質量和外部質量。外部質量指能直接被系統用戶感知，如運行緩慢，不可操作或是操作復雜就屬于外部質量低劣。而不能直接為系統用戶所直接感知的要素，對產品鍵壯性、可維護性有深遠影響的問題就屬于外部質量，如系統設計的一致性、代碼可讀性、邏輯完整性等。內部質量對用戶的影響比較間接，但比外部質量意義更深遠。一般來說，系統內部質量優秀，外部質量仍有可能很差。而內部質量差的系統，外部質量肯定也不怎么樣。
1）、外部質量保證
在外部質量保證上，大部分會在開發后期介入，可以通過性能測試、自動化測試及工程師的功能測試來保證，通過這些實踐活動發現并保證例如運行緩慢、不可操作等質量問題不會存在。針對交互特別復雜的web應用，可以更多的考慮采用webui自動化測試工具，如selenium、pwaitr(b2b)、automan(淘寶)等，可以很好的完成那些簡單、重復的TC用例，可以大大提高測試效率，解決測試工程師的資源瓶頸。
2)、內部質量保證
相對于外部質量，內部質量問題影響更為深遠，在開發開始階段就應該去保證。如通過單元測試、靜態代碼掃描(PMD\findbugs)、持續集成、重構、結對編程、code review等多種實踐活動來保證項目代碼的健康。
除了一些實踐活動去檢查代碼質量外，更為重要的是研發工程師對內部質量的重視，如果工程師沒有形成良好的質量意識，很可能這些實踐也只是停留于形式，并不能帶來較好的結果。如我們在開發過程中的編碼規范、單元測試的質量及覆蓋率，code review的及時性及問題是否持續跟進等等。此外，有選擇的采用結對編程實踐，有助于質量的提高。
本文以敏捷、精益（消除浪費、按需生產）思想的角度試圖去探討一種適合互聯網公司的產品開發體系，上述概要的介紹了項目管理、團隊、質量方面的一些敏捷實踐活動，主要涉及了我們對敏捷方面的經驗分享或者是些正在研究探討的課題。文中涉及的實踐活動，后續我將逐一展開詳細介紹，幫助大家更好的理解和認識。希望本文的分享能成為一個引子，引起大家對敏捷開發的思考和討論，或者更好的了解敏捷和精益思想。
posted @
2011-06-13 15:53 josson 閱讀(527) |
評論 (0) |
編輯 收藏 以下為本人在公司內部關于項目質量和工作效率郵件回復的一此意見和想法。
1、 談流程
不可否認流程的重要性，但我們需要根據具合格情況分析，不斷的梳理和優化我們的流程，讓流程更好的指導我們工作，而不是束縛。目前，我們的流程慢慢多了起來，感覺不如以前敏捷了。經過rpm改造后，無論在測試環節還是發布階段，較之前失去了很大的靈活性。測試階段，開發bugfix后想在測試環境驗證，每次必須重走aone的流程及打包布署，相比之前的build效率真的差了好多。當然，也許是我們項目組對這個流程熟練度、方法還不夠，很多環節有待改進。
發布階段，目前統一由SCM來發布，必然會導致開發對線上環境及發流程更加陌生，同我們提倡的打破邊界，敏捷響應有些相背。再者，SCM資源有限的原因，要支持ITU眾多產品線，能否應付的過來，始終是個問題。發布統一管理有好處，同樣也帶來了弊端，ITU不同于網站，大多數的技術團隊共同在維護在幾個應用，而itu的應用多、規模相對小、環境各異，這樣的產品線采用統一管理性價比不高。希望相應的owner，能不定期的搜集各產品線的意見和反饋，不斷的優化，讓我們的流程更合理。
2、 談自測
我們團隊一直在強調自測意識，也在這方面不斷的總結和改進。我覺的要提高自測，首先應讓每位開發同學形成較好的自測意識，而不是自上而下的命令式管理，只有自己有這方面的意，才會去思考、去想辦法，去實踐。再者，需要PM或技術經理去思考，目前階段實行自測會有什么困難，如沒有系統的自測方法、時間不充足（需要熟悉下階段的UC、下迭代的設計、單元測試補寫等），找到這些困難或問題，就容易對癥下藥了。最后，不斷總結和積累自測方式，優化項目流程。自測不是一種形式，而要追求效果，開發自測同樣需要計劃和方法，所以我們需要向QA同學請教，總結過去 bug常犯的錯誤，整理自己的check項。相信通過這樣的一些自測方法，能真正提高我們的項目質量，打破同QA的界線，我們的開發、測試資源比例可以得到更大的優化，將以前開發階段緊，測試階段松的狀況加以改善，使整個項目過程中的緊張度趨于平緩。
3、 談故障分
“盡量不要讓故障分成為大家包袱，可以考慮被實施產品對事故級和A類才對個人計故障分，B和C類故障分記在主管頭上！”，個人也比較支持駱駝的觀點。目前大家對線上故障都小心翼翼，大家對質量的意識很高，這當然是好事，但同時帶來的影響是效率低了。我的觀點是，作為增值服務的互聯網產品，我們更需要快速迭代增量提供用戶價值，盡快獲取用戶反饋并改善產品，產品推出的遲早，不僅影響獲得回報的時間，還影響到獲得價值的多少，錯過了一個時間窗口，產品可能就不再有任何價值。所以，我們需要找到一個平衡量點，可接受的質量狀況達到最大的效率。
從客戶第一角度談質量，某些時候，客戶可以接受服務偶而不可用重啟下，卻不能接受產品沒價值、交互性太差，操作太復雜。所以，對于客戶來說什么對他們更重要，就需要我們每個人去分析和評估。所以，我們一味只注重質量，而忽略客戶真實需求，那就太悲哀。我的觀點是，case by case，帶著這樣的觀點去思考和解決問題。
4、談敏捷項目團隊
從打破邊界，我想到了一體化的敏捷項目管理團隊，一個目標一致、自我管理的團隊，應該具備良好的目標意識和執行力，不僅能管好自己的一畝三分地，同時也能站在項目、團隊的角度看待問題。PD出現了問題，開發積極去彌補；開發出現了問題，QA積極去彌補，項目團隊的目標非常一致。每位項目組成員一定要把好每一關，萬不可把問題向下拋，因為還有開發或QA會把關，所以差不多就行了，這樣往往就是災難的開始。
posted @
2011-05-20 16:39 josson 閱讀(483) |
評論 (0) |
編輯 收藏
2010已成為歷史，記憶里2010年變化很多、做的很多、收獲也很多。2010是個轉型期、創業期，從年初開始，就在新的Marking中努力耕耘。前半年，以新產品研發為主；后半年，結合客戶使用產品后的反饋，不斷的優化和改進產品功能，努力提升產品價值和用戶體驗。通過大家的努力，幾款新產品還是彼受用戶歡迎的，最欣喜的是我們提前完成了2010年的KPI目標。
過去的一年，有著太多的痛苦和艱辛，為了新產品的上線，晚上、周未都沒了，唯一想的和做的就是確保產品如期上線。過程雖然很艱苦，但大家都努力堅持，齊心協力，確保任務如期完成，我們保持了一貫的說到做到、如期交付的作風。因為這樣的磨練，我和我們的團隊得到了更多成長。困難并不可怕，熬過去，明天的太陽會更加燦爛。
1、談談成長和不足：
1）、職業轉型，開發到管理
雖然Team Leader已經做了幾年了，但一直停留在項目上，多為管事不管人，對細節問題關注較多，所以之前談不上管理，只能算是積累些項目管理經驗。經過這一年的學習和發展，有了更多的管理意識，逐漸關注團隊建設、團隊成長，注意給小組成員更多的機會和空間，讓他們得到鍛煉和成長，承擔更多團隊或項目中的重要事項，而他們通過完成這些重要任務，不僅得到了磨練，同時在團隊中建立了自己的影響力。
放在以前，我會認為有風險，或者自己做更快，更省事，或最有把握的人去。現在想來，以前認識太膚淺了，我們需要的團隊戰斗力，而不是個別人的能力，若平常不注重團隊成員的培養，團隊的戰斗力永遠不行，承擔不了關鍵任務。
談到成長和培養，團隊需要什么樣的人呢？作為互聯網企業，同一般軟件企業不同，產品在推出之前，誰也無法肯定是否會受用戶歡迎，只能快速推出，讓市場來驗證，不斷的改進和適應用戶的需要。因而，需要我們技術人員也具備技術判斷力，改變命令式管理體制下的工作習慣，充分發揮主觀能動性和創新意識，共同做好產品。
2）、學會擁抱變化；
2010年變化很多，有些也許對個人、團隊沒有影響或影響很小，有些直接關系自己或團隊，如團隊的核心成員不斷的被抽調、人員調整、KPI的271考評等，每次的變化都會帶來不同的問題。持續輸血，新人補允，使團隊戰斗力大打折扣，很長一段時間非常的糾結和無耐。事情總是具有兩面性，往好處看，這對我、對團隊也未必是件壞事，沒有經驗過挫折和磨練，又怎能成佛呢？既然是組織需要或Boss的決定，那就多些理解和支持，支持和協助上級完成也是每個下屬的職責；況且，某些變化至少對于一些同學也是件好事，他們有更多的機會和更大的平臺去一展才華。
大概人都是喜歡按習慣辦事的緣故，每每有變化都覺的很痛苦。我覺的如何擁抱變化關鍵在于心態，我們需要理性看待變化，多往積極的方向思考，不僅更容易調整好心態，而且可以在變化中吸取經驗和教訓，鞭策我們成長。
3）、提升項目管理能力
雖然在項目管理知識上沒有太多的時間和精力去系統的學習，但通過不斷實踐和總結，還是有了不少的積累和沉淀，對項目管理有了更多的理解和把握，對敏捷項目管理也有不同的認識，結合團隊自身尋找適合我們的實踐方式。在項目管理方面，還有很多需要去提升和學習，2011年希望安排更多的時間系統的學習項目管理知識及敏捷項目管理，并結合實際應用到工作中。
4）、提升向上溝通力
在擁抱變化的同時，同樣需要理性的分析和積極的向上溝通。在過去，雖然會盡可能的去表達和反饋自己的想法和意見，但我重新審視下，總覺得表達還不夠明確或不是那么的到位，或許在表達時還有更好的方式，至少還有提升的必要。向上溝通也是門學問，需要好好研究下。
5)、提升團隊建設和輔導能力
相對來說，過去的一年所有的同學都會關注到，但領悟能力和基礎較好的同學成長更快，基礎稍弱的沒有太大變化。顯然，平常輔導工作沒有做好或做到位，關注程度不夠。越是基礎差些的同學需要關注和幫助的點越多，需要幫助他們找到不足和問題所在，一起找改進辦法，并給予必要的督促和檢查，養成好的學習習慣，促進成長。2011年，這方面需要做的還有更多。
2、談談2011年的期望
1）、團隊
解決目前團隊新人多，有效資源少的問題；積極關注和幫助新人溶入團隊，熟悉業務，以減少對項目開展的影響；
抓好梯隊建設，關注和輔導基礎較差同學的，共同制定改進計劃和Action，做好必要的監督和指導，促進成長；
2）、能力
系統學習項目管理和敏捷軟件開發方面的知識，并應用到項目管理實踐中；同時積極參與相關方面的分享和討論。
3）、影響
推動興趣小組活動的開展，借開發工具的發展和分享，建立團隊在部門或技術部的影響；
鼓勵團隊成員積極參與技術部的公共事務，提升影響力。
給力2010，加油2011!!!
posted @
2011-02-02 21:46 josson 閱讀(314) |
評論 (0) |
編輯 收藏
iteration和release是兩個不同的概念，但在敏捷實踐活動中，我們往往認識的比較模糊，一個Iteration就是一次release，其實不然。那么，具體有什么區別和聯系呢？
Iteration（迭代）：在固定的周期內，經過需求分析、設計、實現、測試等活動，完成計劃的的業務需求，迭代結束提供一個可工作的產品。計劃的業務需求，可能是一個完整的User Story，也可能是一個Story中的若干task。
Release(發布)：經過一個或若干個iteration后，完成計劃中的所有User Story，經過測試后才release，最終真正交付給客戶使用。
在我們的實踐活動中，一個User Story所需的工作量超過我們的有效資源，無法安排在一個iteration內。我們就會想當然的會去延長迭代周期，增加有效資源以適應所需工作量。殊不知，這更象是形式上的迭代開發，無異于瀑布式項目開發過程。
2、建立固定的迭代周期，保持穩定的開發節奏
Scurm方法也非常強調穩定的迭代節奏，一個穩定的迭代節奏就如同項目的的心跳。Simon Baker描述說："就像心臟有規律地跳動來保持身體運行，固定的迭代長度提供了一個恒量，有助于建立開發和交付的節奏。根據我的經驗，節奏是幫助取得不變的步幅的重要因素"（2004）。對于敏捷開發的團隊而言，穩定的迭代節奏可以讓產品保持更穩定的交付。
3、如何保持穩定的開發節奏？
當一個迭代期內可提供的有效資源無法實現一個User Story時，我們如何按排呢？ 在 談迭代周期控制的困惑 中已談到，這里不在細述。
4、如何選擇適合自己團隊的迭代周期？
一般需要考慮以下因素：
1）、整個項目周期長度（完成計劃的商業需求所需時間）
較短的迭代周期將會有以下一些好處：更頻繁的向客戶展示/交付可用的軟件；更頻繁的度量開發進度；更頻繁的取得反饋并改進；一般大的項目最好有多次(3次或以上)獲取反饋、修正的機會，根據項目周期調整迭代周期長度。
2）、不確定性的多少
不確定性有多種形式，客戶到底想要的是什么？小組的工作效率，時間？技術門檻等都不存在不確定性，不確定性越多，迭代就應該越短。
3）、獲得反饋的難易程度
指小組獲取反饋數量、頻度和及時性，視所處的環境不同，選擇合適的迭代長度；
4）、優先級要以多久保持不變
開發小組承諾在一次迭代中完成一組特定的功能，重要的是不要改變他們的目標方向，優先級不會被改變的時間長度是選擇迭代長度時需要考慮的因素。
5）、迭代的系統開銷
每次迭代的成本（時間），如迭代中進行的完整回歸測試。最佳迭代周期的目標之一就是減少或近似消除每次迭代的系統開銷。如每次回歸時間成本很高，那決定周期長度時更傾向于長一些。
6）、團隊成員的緊迫感
Niels Malotaux指出："只要項目的結束日期還在遙遠的將來，我們就不會感到任何壓力，并從容不迫的工作。當結束日期逼近時，我們才會開始更努力的工作"。意思指項目開始大家比較放松，而越臨近結束，工作越忙壓力越大。因此，選擇一個合適的迭代周期長度，讓團隊成員在整個迭代過程中感受到的壓力更平均，不是給團隊更多的壓力，而是壓力總量平均分布在迭代過程中。
每個團隊根據所在環境和條件確定一個合適的迭代長度，一般建議2~4周。在我們的實踐中，以2周一次迭代的頻率，保持相對穩定的開發和交付的節奏。
5、參考資料:
《敏捷估計與規劃》 Mike Cohn
posted @
2011-01-31 14:26 josson 閱讀(3421) |
評論 (0) |
編輯 收藏
敏捷宣言中說到："最好的架構、需求和設計來自于自組織的團隊"。在自組織團隊中，我們每個人既是團隊/項目的管理者，又是執行者，要取得優異的結果，必須加強自我管理。
如何做好自我管理呢？
1、平和的心態：我們會不斷的遇到各類或好事或壞事、或成功或挫折，什么樣的心態去對待決定了我們成長的方向及高度，"態度決定一切"。
2、目標感：大到個人職業規劃，小到每件事的期望，對于目標(期望)的制定和管理，都需要我們認真的去對待；
3、執行力：目標是方向，不能執行就不會有結果，好的執行力是優秀個人或團隊的必要條件。
4、時間管理：工作需要區分輕重緩急，不能對事情沒有計劃和按排，對事需要分析重要性和緊急程度，分別對待；
5、學習能力："學歷代表過去，能力代表現在，學習能力代表將來。"，一個人的學習能力決定他將來的成績；
任何人都不希望自己被人管著，但要想不被人管只有一種辦法：時時嚴格要求自己，主動、出色的完成每項工作，努力學習，與團隊共成長。
posted @
2011-01-28 18:56 josson 閱讀(272) |
評論 (0) |
編輯 收藏
昨日PM小組例會，談到了需求評估工作量遠大于有效資源情況下，如何保證迭代周期穩定的問題。討論的內容，對于PM如何控制、保持迭代周期穩定有較大的參考價值。
| |
有效資源 |
評估工作量 |
| 1 |
多 |
少 |
| 2 |
少 |
多 |
| 3 |
相同 |
相同 |
注：
有效資源：指迭代周期內，開發團隊所能提供的有效工作日，單位人/天。
評估工作量：指迭代周期內，產品經理提供需要實現的業務需求所評估的工作量之和。
上表描述以固定周期為兩周的迭代中，可能會出現的有效資源和評估工作量對比情況。其中，1、3兩種情況因為評估工作量小于或等同能提供的有效資源，所以不會影響迭代周期。重點需討論的是有效資源小于評估工作量時，如何保持固定周期？
例舉：一迭代周期，能提供有效資源20人/天，需求評估工作量30人/天。
1、功能較獨立，需求不能拆分發布；
安排一個release，兩個iterative。這種情況需要在迭代2中附加一些技術改造或低優先級的小需求、bugfix，release日期相對會慢幾天。
2、一個迭代中包括多個產品的需求(需要各位產品經理協商，決定需求優先級)；
a)、以保證質量為重：
忽略商業優先級，先處理一個迭代中就能全部完成的需求。
b)、保證價值
分兩個迭代完成，一次release。
通常情況下，我們盡力保證迭代周期的穩定，但也允許例外，如：商業需求，產品上確定了發布時間點，或者節假期間團隊請假比較多，一個迭代所能提供的有效資源相對比較少的情況。
保持迭代周期穩定，其核心是：
固定Timebox和可提供的資源，讓產品經理來決定需求的優先級，每迭代只接納(開發/QA資源)可承受的需求。
posted @
2011-01-13 15:31 josson 閱讀(1029) |
評論 (0) |
編輯 收藏
對于互聯網行業來說，快速推出產品占領市場、快速檢驗產品的價值和方向性、快速調整及優化是極期重要的。因此，采用小步快跑、持續迭代的敏捷實踐一種不錯的項目管理方法。我們團隊在敏捷項目管理方面持續開展了二年多時間，在scrum、xp等敏捷最佳實踐的基礎上，結合團隊自身的基礎和條件，不斷的償試和優化，總結和積累了一些經驗。目前，這些敏捷項目管理實踐在項目組開展情況良好，得到了大多數團隊成員的認同，特別是業務方、QA等合作方的認可。
上圖描述了一個基本項目迭代流程，其中涉及三個角色，其職責同等于Scrum中的Product Owner、Scrum Master、Scrum Team。迭代流程中分別包含了以下敏捷實踐：
1）、迭代計劃會議，按商業優先級篩選需求列表，確定本項目需求范圍；
2）、確認本次迭代需求、資源、時間的具體情況；
3）、簡單設計，對關鍵技術點進行必要的設計；
4）、晨會；
5）、結對編程；
6）、持續集成；
7）、showcase；
8）、項目總結會；
9）、新迭代的開始... ...
以上具體實踐活動內容及組織形式，后續將逐一介紹，敬請關注。
posted @
2010-12-16 15:57 josson 閱讀(347) |
評論 (0) |
編輯 收藏1、什么是java序列化
Java
序列化
API
提供一種處理對象序列化的標準機制。序列化（Serialization）是指將java對象用一連串字節描述的一個過程；反序列化（deserialization）是一種將這一串字節構建成一個對象的過程。
2、序列化的作用（必要性）
Java中，一切都是對象，在分布式環境中經常需要將對象從這一端網絡或設備傳遞到另一端。Java
序列化機制就是一種解決在網絡兩端傳輸數據的問題而產生的協議。下圖表示客戶端/服務器之間通信，一個對象是從客戶端傳送到服務器通過序列化的視圖。
3、如何序列化一個對象
為序列化一個對象，你需確保對象類實現Serializable接口。Serializable接口沒有方法，只要實現了序列化接口，Class
就能被序列化機制處理。
示例代碼，需序列化的java對象:
1 import java.io.Serializable;
2
3 public class TestClassSerial implements Serializable {
4 public byte version = 100;
5 public byte count = 0;
6 }
示例代碼，
把TestClassSerial對照象
輸出成
Byte
流，存儲到
temp.out
文件里：
1 public static void main(String args[]) throws IOException {
2 FileOutputStream fos = null;
3 ObjectOutputStream oos = null;
4 try {
5 fos = new FileOutputStream("c:/temp.out");
6 oos = new ObjectOutputStream(fos);
7 TestClassSerial tcs = new TestClassSerial();
8 oos.writeObject(tcs);
9 oos.flush();
10 }
11 finally {
12 if(oos != null) {
13 oos.close();
14 }
15 if(fos != null) {
16 fos.close();
17 }
18 }
19 }
示例代碼，
從持久的文件中讀取
Bytes
重建對象：
1 public static void main1(String args[]) throws IOException {
2 FileInputStream fis = null;
3 ObjectInputStream oin = null;
4 try {
5 fis = new FileInputStream("c:/temp.out");
6 oin = new ObjectInputStream(fis);
7 TestClassSerial tcs = (TestClassSerial) oin.readObject();
8 System.out.println("version="+tcs.version);
9 }
10 finally {
11 if(fis != null) {
12 fis.close();
13 }
14 if(oin != null) {
15 oin.close();
16 }
17 }
18 }
執行結果為：100.
4、對象的序列化格式
TestClassSerial對象序列化輸出的
temp.out
文件，以
16
進制方式顯示，內容如下：
AC ED 00 05 73 72 00 0A 53 65 72 69 61 6C 54 65
73 74 A0 0C 34 00 FE B1 DD F9 02 00 02 42 00 05
63 6F 75 6E 74 42 00 07 76 65 72 73 69 6F 6E 78
70 00 64
這些二進制字節就是用來描述序列化以后的TestClassSerial對象的，我們注意到
TestSerial
類中只有兩個域：
1 public byte version = 100;
2 public byte count = 0;
都是
byte
型，理論上存儲這兩個域只需要
2
個
byte
，但是實際上
temp.out
占據空間為
51bytes
，也就是說除了數據以外，還包括了對序列化對象的其他描述。
5、Java
的序列化算法
序列化算法一般會按步驟做如下事情：
1、將對象實例相關的類的元數據輸出；
2、遞歸地輸出類的超類元數據描述直到不再有超類；
3、類元數據完了以后，開始從最頂層的超類開始輸出對象實例的實際數據值；
4、從上至下遞歸輸出實例的數據；
更多序例化事例及二進制字節含義參考文檔：http://my.oschina.net/god/blog/1291
posted @
2010-12-16 14:52 josson 閱讀(819) |
評論 (0) |
編輯 收藏
1、員工激勵
通過各種外部或內部的刺激，以激發員工的需要、動機、欲望，調動人的工作積極性，充分挖掘潛力，全力達到預期目標的過程。
2、激勵形式、方法:
廣義的分物質激勵和精神激勵（職務、榮譽、目標、信任、情感等）。
3、原則：
1）、精神激勵為主；
2）、只激勵該激勵的人；
3）、只激勵該激勵的事；
4）、激勵方法、手段因人而異，把握按需激勵；
5）、鼓勵公開競爭、和諧競爭；
4、案例：
1)、壓力非常大的時候，采用激勵手段 -- 目標激勵
2)、當前員工不開心，采用的手段 -- 先溝通，明確原因
3）、表現好的員工 -- 信任激勵，肯定
4）、推行新方法 -- 目標激勵，競賽
5、附：
馬斯洛需求層次理論（Maslow's hierarchy of needs），亦稱“基本需求層次理論”，是行為科學的理論之一，由美國心理學家亞伯拉罕·馬斯洛于1943年在《人類激勵理論》論文中所提出。
安全、生理需要屬于物質性價值需求；社會需要、尊重需要、自我實現屬于精神價值需求；
posted @
2010-12-09 16:17 josson 閱讀(381) |
評論 (0) |
編輯 收藏