公司在上cmmi ，雖然很多人都覺得那是那是形象工程。公司的同事說，上cmmi可以忽悠一下**可以，最怕的就是領導把上cmcmi還真當回事了。在專案裡面試用了幾個月沒感覺到很大起色,曾經有人說中國根本就不適合去追求印度式的那種軟體開發過程，印度人太死板，適合做這些沒有創造力的活兒。中國國情不同，中國的開發人員都是一群很有創造力的人，他們的創造力曾經給一些錯誤的開發方法磨滅了，曾經的一段時間，大家極力推崇印度的軟體開發過程，現在聰明的人清醒過來了，通過採用敏捷開發方法能有效的降低軟體開發成，thoughtwork中國公司一直採用敏捷開發就是個很好的證明。可是國內很多軟體公司缺乏創新，還是老一套。
工作中要勇於嘗試，看看scrum是否真的合適我們專案還要從實踐中得出整理，
下面是我給團隊定義的一些開發規範
團隊中的一些基本原則：
開發、共享、坦誠、快樂的工作，團隊所有成員是乙個整體、不應為任何問題追究到個人，
而應把它歸為團隊集體責任，所有人都是平等的地位和責任集體所有制。
開發要求：
1、 遵循《專案開發規範》和checkstyle的要求寫**
2、實行tdd開發
tdd能給設計帶來好處：
迫使你在編寫**之前，考慮更多物件之間的互動
迫使你把物件的建立封裝在乙個更好的層次上
寫出更加小而內聚的方法，從而使方法的重用及糾錯變得更加方便、快速。
3、實行老鳥帶新鳥的原則
專案過程定義
專案過程說明：
每一次迭代時間週期為30天（sprint）
乙個sprint週期內需要完成的模組（backlog）
1、每天早上10-15分鐘站立會議（morning meet）
報告的主題是：今天完成了什麼？、是否遇到了障礙？、即將要做什麼？
2、每週
二、四晚上**檢查（code check）
乙個人寫的**至少兩個人檢查測試，進行**複查的人需要針對程式提出意見或建議，然後反饋給**開發員
3、每2周專案回顧（review meeting）
開發團隊中成員需要在會議上說明自己實現了哪些功能、並作展示自己的工作成果。
尋找專案和團隊中存在的問題，並作後續的工作給予改進
4、每月初專案計畫會議（ sprint planning meeting）
一般為一天時間（7小時）。該會議需要制定的任務是：產品owner（業務人員）和團隊成員將自己的功能模組（backlog）分解成小的功能模組,
決定在即將進行的sprint裡需要完成多少小功能模組，確定好這個product backlog的任務優先順序。另外，該會議還需詳細地討論如何能夠按照需
求完成這些小功能模組。制定的這些模組的工作量以小時計算。
5、每週五下午技術會議（technologic session）
專案中遇到的一些困難、難題、陌生的技術或是你得最佳實踐都可以拿出來共享與討論
會議上，可以丟擲任何疑問大家討論，不同的思考會讓大家對問題了解更加深刻，討論也可以幫助我們解決一些疑難症狀。
6、協作、反饋（feedback）
ba在每天在晨會後總結一封報告郵件給客戶（客戶代表）和pm，讓客戶（客戶代表）能及時了解進度情況。
每週一總結bug明細並發給小組全體成員。
ba盡量保持每日與客戶代表溝通、討論各個業務細節，力保每個業務細節的正確性。
dev可從開發者，以及整體系統架構設計者角度考慮一下需求的可行性，是否能以最簡單的方式提供同樣的功能。
一些聰明的做法
不做簡單重複的勞動，讓這些工作給機器代替。（手工執行簡單的任務只會讓你變得更傻）
快捷化常用命令
必要時候結對程式設計
迭代要有固定的時長（timebox），不能超過六個星期。
每一次迭代的結尾，**必須經過qa的測試。
scrum團隊必須有產品負責人，而且團隊都清楚這個人是誰。
產品負責人必須有產品的backlog，其中包括團隊對它進行的估算。
團隊必須有乙個燃盡圖，而且要了解他們自己的生產效率。
在乙個sprint中，外人不能干涉團隊的工作。
backlog是scrum的核心，從根本上說，他就是乙個需求、或故事，或特性組成的列表，並且按照重要性進行了排序，一定是客戶想要的東西，並且用客戶的語音進行描述，沒乙個條目是乙個故事（story），建議每個故事包含這些字段：
id（統一標示）
name（名稱）
imp（重要程度）
est（初始估算）
how to demo（如何做演示）
notes（其它）
每乙個故事有3+1個變數（範圍、重要性、估算）+質量，無論如何不能在質量上讓步。
質量分為內部質量和外部質量：
外部質量是使用者可以感知的，如執行緩慢，讓人迷糊的介面等。
內部質量一般指使用者看不見的原素，它對系統的可維護性有深遠的影響，如系統設計的一致性、測試覆蓋率、**可讀性等。
記住，在鬆散的沙灘上永遠不能建立起精美的樓閣，經驗證明犧牲內部質量是乙個糟糕透頂的想法，現在省下來的一點時間，接下來的日子，你就要一直為它付出代價。
在scrum中一切事情都是有時間盒的，到時必須交貨。
「這個sprint讓大家不太好過，但是我們應該看到它的正面影響，整個團隊從中獲益匪淺，下個迭代會議會更有效率。」
學會按照時間盒安排工作，學會制定各種合乎情理的時間盒，這對sprint會議的長度同樣有效。
典型的sprint時間表，每乙個小時休息10分鐘：
30分鐘的總體介紹，概括產品的backlog。
20分鐘的時間估算。
1個小時的story選擇，計算生產率。
1個小時的站立會議安排和將故事拆分為任務。
比較理想的乙個sprint長度為3個星期，（目前公司每日的build版本，發布到測試部進行測試，應該是乙個自動化測試的過程，而人工測試的應該是每個月發布的正常版本）
半死不活的目標比什麼都沒有強。
在sprint中包含多少個故事由團隊決定，而不是產品的負責人或其它人，但是產品負責人要對sprint中放入哪些story產生影響。
計畫指派的點數：0、1/2、1、2、3、5、8、13、20、40、100、？、coffee。
Scrum敏捷開發
只有實踐起來才能提出有針對性的改進建議 在這個框架中，整個開發過程由若干個短的迭代週期組成，乙個短的迭代週期稱為乙個sprint，每個sprint的建議長度是2到4周 網際網路產品研發可以使用1周的sprint 在scrum中，使用產品backlog來管理產品的需求，產品backlog是乙個按照商業...
能否在硬體專案中應用敏捷方法？
他提出了乙個問題 將敏捷方法應用到硬體開發中的做法是否存在爭議？那些用來指導敏捷軟體開發團隊的方 在片上系統 soc，system on chip 的團隊中是否仍舊有著相同的指導意義呢？在這兩個截然不同的領域中是否存在很大差異？接著，他在文章中提到了一段關於敏捷宣言 www.agilemanifes...
敏捷軟體開發方法 scrum
這學期的軟體工程課，老師一開始就談到了乙個詞 敏捷開發。下面來詳細談一下敏捷開發。就老師課上說講解的內容，首先說一下敏捷軟體開發的核心價值觀，它包括承諾 commitment 專注 focuse 公開 openness 敬重 respect 勇氣 courage scrum的框架，它包括三個角色，四...