visual-studio - template - 微軟agile




如何在沒有Team System的情況下使用Scrum和Visual Studio (8)

得到一個白板

開始使用SCRUM應該不需要任何工具 - 至少,在每個衝刺開始時,您將有一個計劃會議,每天沖刺會議,並在每個衝刺結束時召開一個回顧會議。

在日常會議中,圍繞白板進行討論,並使用它來跟踪每個人的任務狀態,並為衝刺進展。

您還需要跟踪您的積壓計劃 - 這可以在紙上,在白板上或在Excel中完成。

我感興趣的可能是和我的開發團隊一起使用Scrum(是的,我知道轉換到它會有點痛苦)。 但是,我們沒有團隊系統,可能目前也無法立即獲得。

在沒有Team System的.NET / Visual Studio環境中,讓Scrum成為一個團隊並運行的一些可能的工具是什麼?


我在最後一個公司參與了一個Scrum團隊,這與開發環境無關。 這是一個開發軟件的過程,通常使用過程本身的技術很少(儘管一個好的電子表格工具可以幫助跟踪進度)。

所以...我會說你對工具的擔心可能是錯誤的,除非我誤解了這個問題。


  • 源代碼管理: Subversion
  • 持續集成應用程序: Hudson (有很多.NET插件),比CruiseControlDotNet更易於使用
  • 構建工具:MSBuild - 你會想要自定義構建過程,學習MSBuild是最好的方法來做到這一點
  • 單元測試框架:無與倫比的NUnit
  • 靜態代碼分析: NDepend ,FxCop,其他?

相關說明: SVNStats - 一個java項目,可以創建一些關於倉庫中發生的事情的非常酷的報告,為您提供一些漂亮的代碼流失指標

所以MSBuild是你在開發的不同階段啟動這些工具的粘合劑,或者你可以在源代碼倉庫發生的事件中添加鉤子。 這是一個粗略的工具/應用程序列表,它提供了一個Team System提供的功能。

關於這個清單的好處 - 除了NDepend之外,所有這些都是免費的,供商業和私人使用。


@Jason和@Mike_Stone是正確的。 除了一張紙和一支筆以外,Scrum不涉及任何工具。 Scrum不太關注團隊使用什麼工具,而是關於團隊如何溝通和協作以及與其利益相關者如何優先考慮和適應變化。

另一方面, XP更多的是面向工具和開發者,主張持續集成,測試驅動開發,結對編程等等。

敏捷方法是非常不可知的工具,在這個意義上非常實用。 使用最適合你的東西。 你不需要工具a或庫b就可以變得敏捷。


我同意。 Team System只是一個包裝在IDE中的工具集。 Visual Studio默認使用MSBUILD,NUnit和任何其他選擇的插件。 唯一真正的價值是像Conchango's這樣的方法論插件,它允許工作項目的優先級和分配,以及之後生成的報告。

每天的Scrum,白板,excel和紀律是一個非常好的開始。


完全同意對excel的評論。 你最好這樣開始。 如果你是從瀑布方法來的話,Scrum可能會有點文化衝擊。 確保你的團隊首先理解哲學比你選擇使它更高效的工具更重要。

當你有一些有形的東西(一張便利貼,一張紙)代表你正在創建的資產時,Scrum似乎是最好的。 這很簡單,直接,每個人都可以得到它的頭。 有時候,當你把所有的任務都存放在某個數據庫的時候,你的意圖或者工作項目本身就會迷失或者被誤解, 特別是如果這個團隊是Scrum的新手。

現在,我的團隊正在使用Team System進行Scrum。 這很好,因為我們可以免費獲得管理和團隊報告。 然而,這是重要的,我認為我們事實上做得更快,質量更高,當我們用老式的軟木板,excel和這個模板(我喜歡這個東西,把它推薦給Scrum的每個人)

http://blog.crisp.se/henrikkniberg/2007/12/18/1197973740000.html



在過去,我使用Visual Studio 2005-2008在TFS中完成了Scrum項目,對此非常滿意。 我正在使用Eclipse在Linux環境中開發一個Scrum項目,這需要遷移到另一個系統。 我們選擇了Rational Team Concert(RTC) ,我發現它很適合我們的需求。

我發現RTC在功能和概念(比如RTC使用相同的工作項術語)方面與TFS相當,所以過渡相當簡單。 有一個用於Visual Studio IDE集成的插件,以及為項目團隊提供burndown圖表和其他進度指標的Web界面。 最多可以有10名開發人員免費使用,所以對於小團隊來說非常有用。 我不確定一旦你必須支付什麼定價模型,但是如果它符合其他IBM Rational產品,我認為它與TFS相當。







scrum