XXX:
你的這些問題都是很好的問題，有些問題，我們自己也在思考, 我就這些問題發表一下我自己的看法，見下面的藍字部分：
郵件正文：
您好：那天的培訓我提了幾個，還有幾個請幫忙解答一下，可能有些問題比較幼稚：）
1、敏捷合適什么樣的項目類型？ 因為IBM的項目大部分是產品研發類型的項目，可以很好的做一個比較長期的規划，明確發布計划和迭代周期，但對於那種需求不是非常明確或者經常變來變去的項目，感覺是不是不太合適？？
敏捷思想和實踐能適應的項目類型非常廣泛，但不等於適合所有的項目，我去年參加了中國敏捷開發者大會、中國軟件過程改進年會，從交流的內容來看，進行敏捷實施的項目類型很多，涵蓋產品和項目，而且項目類型分散在各個行業領域，項目周期有長的也有短的，但是很難用簡單的語言來概括哪些項目適合敏捷，哪些不適合。關鍵是在敏捷實施過程中靈活、准確的采用合適的敏捷流程和實踐。敏捷不能包治百病，有時候我們的葯方需要綜合一些，結合敏捷已經其他的開發模型。
2、對於敏捷開發，這個干系人是非常重要的，對於客戶來說，很多時候能參與到項目的人基本上是客戶的項目經理，但這個人應該不是關鍵用戶，對於一個比較復雜的項目，關鍵用戶是很多的，但這些人是不是都要參與進來？？ 實際情況下，很難做到讓他們都參與進來的，僅僅這個PM肯定是不夠的，這種情況下如何處理？
干系人的范圍比較大，在項目中我們要抓住關鍵干系人。如果關鍵干系人有很多，我們很難讓他們同時參與每次的計划、演示會議，我可以安排在不同的milestone給不同類型的干系人演示，過多的演示和反饋不但消耗大量的時間，而且容易造成干系人反饋意見難以統一。
3、敏捷開發與現在常用的分階段開發的區別，你那天也提了一下，我想有沒有更好的優劣對比？我個人認為分階段開發可能更合適些，這個階段周期可以根據需求情況可長可短，不受敏捷的固定迭代周期限制。
敏捷和其他的開發模型，我認為沒有好壞之分，關鍵是針對項目的具體情況，選擇適合的開發模型，敏捷的很多思想就來源於其他的開發模型例如Scrum、OpenUP，RUP，XP等。
4、敏捷的一個優點的是叫快速反饋，但很多項目，有時候在一個迭代內可能做的都是后端的基礎研發，在前端UI上根本沒有什么東西給客戶看，這種情況下會不會存在一定的風險？
這樣的階段不能持續時間太久，即使是后端的開發也需要有驗收的標准，比如自動化測試，或者是測試驅動開發。沒有驗收標准，如何保證質量，如何保證開發的成果能滿足客戶的需要，這種情況下的開發風險顯而易見很大。
5、對於敏捷類型的項目，如何給客戶報工作量？？常規項目，一般都是在項目開始時把全部需求整理出來，然后整體評估工作量並給出一個合理的報價，但按照敏捷的思路，它不需要這樣，只需要在每次迭代之前明確這次迭代的需求即可，它號稱的是快速響應用戶的變化，也就說通常是邊做邊確定后續的迭代需求，但這種方式貌似在開始的時候不好評估整體工作量？
我一直也在思考這個問題，敏捷的開發模式對估算整個項目的整體工作量是沒有好的辦法的，只能借助其他的手段來實現，比如，企業的組織過程資產庫，或者其他的項目流程等，IBM就是采用IPD和敏捷開發相結合的方法來實現的。
6、無論是否敏捷，其實最關鍵的都是：人的自我能動性，如果開發人員的自我素質很好，對自己的開發東西非常認真負責，而且團隊內部的溝通也非常好，那么是否敏捷是否還有必要？？
你會發現，敏捷是沒有一個固定的定義的，只有敏捷宣言和12條准則，敏捷重在方法，來確保這些目標的實現，如果你有很好的方法來實現團結成員有很好的能動性，那這本身也可以說是一種敏捷實踐，雖然這不是典型的常見的敏捷實踐。敏捷最佳實踐就是收集並分享這些好的方法。
7、敏捷轉型涉及到HR、財務等其他部門，對於IT這個對企業來說並不是很重視的部門，如何去推動整個組織的變化？？
這個問題好像在會上回答過了，我想只能循序漸進了，純的自上而下或者自下而上的去推動都是非常困難的，我們需要領導的支持和信任，同時開發團隊也願意去實踐來解決他們的頭疼的事情，在這種情況下進行敏捷轉型是比較合適的。對於IT部門在整個公司的組織結構中地位偏低的情況，我想先把開發的事情做好，讓敏捷能真正地解決我們的問題，同時帶給我們受益，改善我們的業務目標，在這個基礎上再逐漸對其他部門產生影響，這個時間會更長一些。
8、敏捷的核心是什么？？ 或者說帶來的最大的變化是什么？？ 是迭代嗎（分階段類似）？是需求管理方式的改變（這個的優劣目前不明顯）？是單元及自動化測試（這個無論是否敏捷，都是必須的）？還是TDD（這個感覺推動起來非常困難）？？
我認為敏捷的核心就是我提到的那四點：准、快、優、穩，以及確保這些目標得以實現的敏捷實踐。