學習程式設計，首先關注到團隊與軟體開發過程，這是因為，對於軟體開發而言，其三要素是團隊（人）、過程、技術
&工具。軟體開發是乙個智力遊戲，建立在溝通與協作的基礎之上；技術和工具，只是其因素之一。所以，同學在學校中所體驗到的，多是技術和工具的應用，而對於團隊和過程，大家則是通過閱讀些軟體工程的材料去了解。如我們所見的，都會提到瀑布模型、原型開發、螺旋模型等等，材料新的，將會介紹
rup或敏捷。
但對於這些
「書面知識
」，你覺得該如何理解呢？如何結合你現在的團隊或環境？
我們回到根本上來，軟體開發的目標是什麼？
——如之前所說，學習計算機語言和程式設計，就是學習交流能力，那麼交流的目標又是什麼呢？
首先，軟體開發的目標是，交付可以工作的軟體。如果沒有可以工作的軟體，再漂亮的**也成兒戲。就像一輪談判，沒有階段性共識或了解，漂亮的話也沒什麼意義。所以，如果你身在乙個開發團隊中，需要首先學會在過程中審視，這樣做真的有利於這乙個目標嗎？
其次，一般而言軟體一次交付並不意味著終結，而往往是新一輪遊戲的開始
——維護、公升級、迭代等等。因為有這些後續的行為，前乙個過程你需要留下足夠的資訊
——為下乙個延續行為展示足夠清晰的狀態。就像一場談話，如果不了解上下文場景，乙個新切入的人是難以繼續的。
對於眾多的模型和團隊而言，都會在這兩個目標上找乙個合適的平衡點。其實採取什麼樣的模型並不是非常關鍵，重要的是對於你當下的情況，實現目標存在什麼樣的問題，這些問題可以用什麼樣的辦法去解決？開發模型給我們一種樣例，一種思路。
另外，作為以智力和交流為基本特徵的團隊，其管理和團隊組建也是需要考量的。所以我們會對團隊建立各個角色，比如產品經理、架構師、專案經理、工程師、
qa人員、
surfer
、過程改進人員、配置管理人員等等，外部人員還有客戶、使用者、老闆
:)等等。對於管理而言，要達到目標是（1
）如期提供高質量軟體（2
）控制過程風險（3
）應對需求和團隊變化
但管理的目標能否達到，最重要的是執行的過程，執行過程中人的感受。
scrum
whole team
。在這樣的團隊中，不同職業角色的人雖然分屬不同部門，但日常工作都是跟著專案團隊走。產品、工程師、
qa相對集中在一些產品線上的，可形成乙個
team——
我們建立為乙個
scrum
。然後通過
sprint
（通常是乙個自然月）來進行專案迭代。其實這是乙個輕量級的專案管理框架，對於
scrum
首先對於這樣的團隊，角色上有三種：
scrum master
，保證專案能夠遵循
scrum
要求進行下去，
product owner
，負責產品要做成什麼樣子，並進行驗收，
member
，專案團隊成員，則是開發、測試等等所有的人，對於
member
而言，團隊是扁平化的、且強調隨時溝通。
其次，對於溝通而言，我們
scrum
有約定的機制進行保證或促進隊員的交流，主要是三個會議：每個月初的需求規劃會議——需求
pk、吹風及
plan meeting
，scrum
執行期間的站立晨會，以及
scrum sprint
結束時的總結及成果展示會。需求吹風及
plan meeting
的會議，是要求
scrum
全員參加的——
pm、工程師、
qa以及
surfer
和過程改進人員，這時候確認的是做什麼、資源規劃及里程碑。晨會則最主要的目的是
share
你的狀態給團隊中的每乙個人，並報出你的困難，發言權利只有
scrum
內部人員才有，而關心該
scrum
的人員則可以選擇自由旁聽。總結及成果展示則是對一次迭代的
review
，需要總結出團隊的優點、缺點及挑戰，就本
sprint
而言。最後，對於
scrum
過程中需要交付或使用的視角結構，則是分解好且團隊已經規劃完畢的專案列表，專案
bug任務列表，以及專案的進度圖——無論是
backlog
、白板或者靈活的工具進行展示。重要的是這些資訊是大家共識的、為每個人所易於看到。
所以在這樣的團隊中，溝通和反饋是被尤其推崇，關注的結果是需求被做到了什麼程度——每天都會有晨會報告大家你昨天完成的任務，今天的計畫以及遇到的困難，並在
sprint
結束後回顧做的優點、缺點及需要迎接的挑戰。報事貼、白板是最常用的交流工具。
當然，這樣的方式中也會存在一些需要考慮的地方。
一方面，並不是採取了敏捷的形式，就具備了敏捷的能力。太多的會議可能為你帶來溝通的成果，也可能為你帶來困擾；大家都坐到了一起，卻未必提高了溝通的效率。廣而言之，對於其他模型也是如此，做乙個形式並不等於我們就具備了相應的成熟度。這個過程中，仍然是聚焦到我們軟體開發的目標完成上，聚焦到人的感受上。
另一方面，因為可工作的軟體才是目標，那麼文件和流程需要執行到什麼樣乙個力度？這對於團隊而言仍然是需要認真考慮和靈活應用的——完全的文件是困難的，時刻保持文件和**和需求每個細節一致的成本也是非常高昂的，但必要的文件與流程對於過程的控制也是意義很可見的。所以在這個過程中，仍然需要依據業務和團隊特點，做乙個合適的規範和流程，以輔助溝通確認和過程控制。廣而言之其他模型也存在這樣乙個問題，如果你定義嚴格的流程和細緻的規範，那麼對於交付軟體的目標，以及變化響應應該如何去做，也是需要考慮。
還有一方面，並不是所有的業務型別適合敏捷——比如，我們的研究性專案，指標難以界定，時間、資源也相對難以界定，方案不是非常明確的情況下，去做敏捷的迭代執行上也會具有很多困難。再比如，對於大型的、周期長的專案，實行敏捷方式也需要考慮——你或許會分割團隊、建立超級
scrum
，但這中間一定要有規範的、流程化的內容去協調團隊之間的協作和控制。
所以，親愛的同學，針對具體的業務和團隊，思考獲得合適的開發模型與團隊管理協作方式，這對要學習程式設計的你，絕對是非常必要的一課！把問題放在心上，勝於放在腦後。即使今日你忽略之，一旦你要動手開始做，也會不得不抬起頭來環顧思索你的環境。
對於我們的虛擬團隊，也面臨非常實際的問題——這時就是機會：我們的目標是什麼？我們的效率如何得到提高？
希望這次做作業的兩個小組，能夠花一段時間考慮一下，我們的團隊如何會更有效率？可以指定什麼樣的流程或規範？如何促進溝通？這不是作業，但對於大家會有幫助。
和大家說明一下，我們的作業有兩類，一類是討論式的，大家對於乙個問題收集材料，並給出自己的答案；另一類是小型開發專案——對於這一類作業，我們將採取類敏捷的方式進行。後面隨著具體專案的展開，我們的開發協作也將開始。
團隊與軟體開發模型 團隊2
csdn c 學習小組 張進昌 杜萬智 王鍇 一 軟體開發模型 a 軟體開發模型包括的範圍及作用 軟體開發模型 software development model 是指軟體開發全部過程 活動和任務的結構框架。軟體開發包括需求 設計 編碼和測試等階段，有時也包括維護階段。軟體開發模型能清晰 直觀地表...
軟體開發模型與測試模型
1 優點 強調開發的階段性 強調需求分析和早起計畫 強調產品測試。2 缺點 依賴於早期進行的唯一一次需求分析，不能適應需求的變化 由於是單一流程，開發中的經驗教訓不能的及時反饋給應用於本產品的過程 風險往往遲至後期的測試階段才顯露，因而失去較早的糾正機會。瀑布模型的乙個大缺陷在於，如果在需求引入的乙...
軟體開發模型
軟體開發模型 software development model 是指軟體開發全部過程 活動和任務的結構框架。軟體開發包括需求 設計 編碼和測試等階段，有時也包括維護階段。軟體開發模型能清晰 直觀地表達軟體開發全過程，明確規定了要完成的主要活動和任務，用來作為軟體專案工作的基礎。對於不同的軟體系統...