scrum工具大家有什麼推薦？
有方便，操作簡單的工具推薦嗎
Worktile 團隊對於開發和Scrum的一些理解，希望有所幫助，我們的方案叫做：開發，從未如此清晰
我們的開發流程是利用六個項目構成的一套開發系統，這六個項目分別是，路線圖Roadmap，靈感Ideas，計劃Planning，缺陷Bugs，設計Design，開發Development。這六個項目中，以開發項目為核心，其他的項目中的任務通過篩選匯總，最重構成可執行的開發計劃。這個系統的構造為：
- 任務標題可以簡要概括某個功能點；
- 任務描述可以作為詳細的解釋；
- 任務檢查項可以分拆一個比較大的功能，或者用於標記開發中的注意事項；
- 任務分配讓責任到人，功能由哪個工程師負責開發一目了然；
- 關注任務可以讓PM或者team leader跟進開發進度；
- 截止日期可以敦促工程師應該在什麼時間完成；
- 任務標籤將開發的優先順序醒目的標示出來；
- 附件可以用於添加輔助資料或者圖片；
- 如果需要溝通，使用任務評論會非常便捷。
而通過任務（或者整個任務列表）的跨項目複製或者移動，這些任務就可以猶如血液一般在這個系統內流動起來，讓整個系統煥發出活力。
管中窺豹【開發Development】是開發過程中最主要的項目，也是落實計劃的最前端。通過重點介紹這個代表性的項目，也可以一窺整個開發系統的運作模式。
該項目由技術負責人負責，新的任務來源於系統其它五個項目的匯總，其中的任務分為以下幾個列表：
要做：每周的例會上確定新一周的開發計劃，然後將【計劃Planning】【缺陷Bugs】【設計Design】中的相應任務添加到該列表中，並對新添加的任務按照優先順序排序，但在這個階段並不進行任務的分配；
進行中：一個功能進行設計或開發的時候，將其從要做當中拖拽到當前列表，然後分配給相應的工程師進行開發，並指定任務截止日期；待測試：開發完成的任務會進行到待測試列表，由測試人員負責質量保證；如果測試有問題，則退回到進行中，由工程師去處理；沒有問題的話，就可以推進到下一階段；
待發布：測試人員檢查沒有問題的任務會移動到當前列，等待部署發布；已發布：對於已經發布的特性會進入到當前列，一般會把已發布任務在當前項目保留1個月左右，確保沒有問題後，歸檔已發布的任務。需要注意的是，如果產品是對應多平台的，可以將開發分為多個項目，這樣可以讓開發更為清晰，比如【Web端開發】、【iOS端開發】和【Android端開發】。
除了上面介紹的【開發Development】，這套系統的另外五個項目分別承擔著各自的功用，並且各具特色。
【路線圖Roadmap】
這是一個中長期的產品路線圖，一般可能會包含未來長則一年，短則一個季度的重點功能和版本規劃。主要由產品經理負責，其中的任務既可以按照功能模塊劃分，也可以按照版本進行劃分，目前Worktile團隊按照功能模塊進行劃分。【靈感Ideas】
這裡面主要是匯總來自於團隊內部，或者是用戶的比較好的想法或者靈感；並且我們會使用三列表將這些想法進行分類：功能和設計是分別針對功能和設計的想法的收集列表，而Magic Points裡面則是用於收集一些比較新奇有趣，又充滿人性化的小亮點。【計劃Planning】
這是一個中期產品計劃的雛形，主要是由前面兩個項目中的任務「匯流」而成，周期一般為一個季度或者一個月。這個計劃其實可以說是整個系統中最難也是最關鍵的一環，因為這體現出了產品規劃和用戶需求的取捨與平衡。一個產品的發展過程其實就是一直尋找這兩者平衡點的過程。所以在制定這個項目的計劃的時候，往往也是最為耗費精力和討論最激烈的時候。【缺陷Bugs】
這個項目匯總了用戶反饋的Bug，按照反饋的問題針對的平台，可以分為【Web端】、【iOS端】和【Android端】三個列表；考慮到用戶反饋渠道的多樣性，用戶反饋同樣可以使用一套系統來支持，這個我們下面會詳細講到。而經過檢測確認的bug，就會最終放到開發裡面去修復。【設計Design】
從設計角度和用戶體驗角度對產品提出的優化建議。這幾個項目按照我們最開始介紹的架構，通過任務的流動成為了一個整體。
從用戶到產品用戶反饋在一個產品初始的快速成長期可能不是很被重視，一方面是這一階段產品的「規劃儲備」還是足夠的，另一方面也是因為用戶反饋的樣本量比較小，無法形成有一定基數同時又可以提煉出價值的用戶反饋；但是隨著產品的不斷成熟，用戶量的積累，對於用戶反饋的響應、分析並最終體現在產品上，就變得愈發重要。所以收集用戶反饋，開發中非常重要的一環。
對於一個較為完備的用戶反饋系統，一個項目可能會顯示的很吃力，所以我們同樣可以使用多個項目來構建。
【反饋收集】項目，可以將來源於後台、社區、QQ群、微信、微博的反饋，按照反饋的問題針對的平台，可以分為【Web端】、【iOS端】和【Android端】三個列表；收集來的建議或者缺陷反饋，經過測試、確認之後，確定有價值或者需要列入開發計劃的，可以分發到各個開發項目中。
但是開發流程的複雜程度，是取決於你對開發計劃的精細化要求的，如果產品很簡單，甚至團隊規模較小，你甚至使用一個項目就可以完成開發。
關於會議必要的會議溝通，是保持團隊處於同一節奏，並且推進多個項目之間流轉的重要環節。目的的不同、與會人員的不同，也就要求採取不同的會議形式。
周一產品例會
與會人員為產品部的所有成員，由PM來主持。明確未來一周的開發計劃，推進開發系統內任務的流轉，並且在【開發Development】項目中，明確開發的優先順序，給任務進行分配，設置截止日期。
周五總結例會
與會人員為PM、公司各個部門的team leader、CTO和CEO，會議由CEO主持。首先產品部需要總結過去一周的開發進度，讓運營市場部門可以獲知當前狀態，進而可以配合進行一些用戶運營和市場活動。周三Tech Share
這是公司內部進行的技術分享，主要是產品部參加。這是一個主動分享和討論互動的內部沙龍，每期由不同的工程師和設計師做分享，幫助大家在自己的領域之外有所提高。一些經驗這套系統內的項目要盡量採用統一的優先順序標準，換言之，就是這六個項目要用一套【任務標籤定義】。只有這樣，不同項目內的任務在幾個項目間流動的時候才會非常順暢，不會因為標準不一造成什麼問題。
每周在開發的【要做】中，僅添加一次任務，不要讓工程師們覺得工作總是一望無際的，讓他們看到一個個可以完成有限目標，最終，這自然會彙集成為一個Big Dream！
完成的任務別急著歸檔。對於已經完成的開發內容，都不要急著在路線圖、計劃或者開發中去歸檔，可以保留一段時間，比如一周或者一個月，這樣可以便於我們回溯過去一段時間的工作成果。
無論你想把這套開發系統弄的多麼的精簡（比如一個項目）或者多麼複雜（三層以上的項目），首先要明確的一點是——這套系統是不是讓你的開發變得更加清晰了？為了確定這一點，你要檢視一下，在這套系統之下，你的團隊目標是不是清晰了，讓你的開發計劃是不是清晰了，並且讓你的團隊職責是不是清晰了。如果沒有，你就需要作出調整。
分實體工具和電子化工具：
實體工具：故事牆，用戶故事卡，燃盡圖等等
電子工具: Trac, Redmine用於項目管理和缺陷管理；CruiseControl，Hudson用於持續集成；Git，SVN用於版本管理；MediaWiki用於知識管理
以上工具都是免費的
BTW，樓上推薦的Jira也不錯，pivotaltracker不要用了，我個人覺得不好。以前用過ScrumWorks。Basic edition是免費的。最近在使用禪道系統，是個開源免費的（也有更強大的付費版本），擴展性偏差，應對大公司需求可能不足，對小團隊來說還是相當好用的。
2015年11月8日補充
沒想到多了好些答案，而我的回復還是0支持，呵呵。
敏捷宣言就講：個體和互動 高於 流程和工具
這是一個各有所好、見仁見智的問題，此題的各種答案也都是推薦各種工具，但問題是這些工具背後的理念、假設的操作方式是否與你的適用場景相吻合，都需要去琢磨。挑選工具是一件嚴肅的事情，尤其是給非常多人的大組織挑選工具，最好是多多嘗試，再做決定。而且，最好是允許團隊使用不同工具，但要能夠把你們需要的信息匯聚起來。
------------------相信如上這麼多答案也給了樓主一些感覺，工具這種具體的東西，每個人每個團隊都有不同的喜好和順手的工具，畢竟每個人的手也是不一樣的嘛。
鑒於這個問題十分開放，我會建議你們從使用低科技含量的白板（White Board）+便利貼（Post-it Notes）的方式開始，先用起來。你們會發現自己對Scrum應該如何運作、這些工具應該如何使用的理解也會不斷地變化，而在這個領悟和變化過程中，這種低技術含量實體工具無疑最能夠快速地響應。便利貼寫錯了？撕了重寫嘛！
待到有了一些經驗之後，便可以根據自己的經驗，提出對Scrum工具的非常具體的需要和傾向，此時，再挑選一款得心應手的工具，就很容易了。
這篇維基（獨孤求敗）與大家共勉：「獨孤求敗的武學，一生境界分為利劍、軟劍、重劍、木劍、無劍。「四十歲後，不滯於物，草木竹石，均可為劍。自此精修，漸而進於無劍勝有劍之境。」」最近看到的 targetprocess 不錯，網站 http://www.targetprocess.com 。自己的項目開始用它，之前用過Trello，不是不好，但太簡單了。tp的關鍵是5人以下團隊終身免費，而且可以使用所有功能。Ctrix 和 Cisco 的選擇哦
jira可以用插件，故事板，燃燒圖，分配任務都可以用。但是最好的scrum工具還是越簡單越好，越熟悉越好，比如白板，比如excel。
沒有用專門的敏捷工具，主要是redmine + 白板：redmine用於記錄故事和bug，白板記錄本次迭代的故事和燃盡圖。
TFS2010中有scrum模板可以應用，
http://blogs.technet.com/b/chrad/archive/2011/02/13/tfs-2010-msf-agile-vs-visual-studio-scrum-1-0-smackdown-planning-w-agile-part-iii.aspxhttp://blogs.msdn.com/b/bharry/archive/2010/06/07/a-scrum-process-template-for-tfs.aspx 我們用的是Rally，不過這個付費，只是供參考一下。http://Leangoo.com ,scrum中文網研發的，專註scrum敏捷!
根據我以前的經驗，我會給大家推薦Trello。
在使用Trello之前，我是用白板＋站會的模式，有了Trello後變成了投影＋坐會（晨會），但效率更高。
上面這個圖是我用Trello做的一個Scrum實例，格局和Scrum白板差不多，To Do、Doing、Done三列，大家把自己負責的內容添加卡片，每一個卡片可以@其他項目成員以及加截止日期，每天坐會（晨會）的時候，我會拿著手機或ipad接上投影儀，然後把這些內容投影到屏幕上，大家來review，在會前我會要求大家已經把相關的項目更新好，這樣站會的效率會高很多。
作為一個輕量級的工具，Trello還是非常不錯的，特別是對複雜工具天生免疫的我來說，它有的功能和沒有的功能，都恰到好處。現在在用http://tower.im
推薦ScrumWorks，基本版免費使用，JIRA可以安裝Greenhopper插件，也能實現項目的敏捷管理。
Scrum在DevSuite中的應用的視頻介紹：
前提：典型的scrum推薦團隊size （6到9人），而且遠程，客戶和team沒法沒天都面對面在一起。我覺得Trello是非常好的工具。我們在多個項目里，和多個不同的團隊，都在使用。它本身的外在表象，本來就是board（牆）和card（卡片）。盡量簡單地去用Trello，不需要太多功能。
JIRA我覺得對這樣的團隊和項目，太大太重了查看我的文章：產品研發團隊基於Worktile的Scrum敏捷開發協作流程
現在就用在線的tfs吧
推薦leangoo http://www.leangoo.com 敏捷開發必備的，永久免費呢
推薦scrumworks
xplanner，bugfree，twikireview board
用過ScrumWorks Basic，功能方面嫩了些。於是團隊讓剛來的少年人練手，重新做了一套GScrum，挺方便的。
我們用微軟的TFS，不是很方便，但因為和代碼控制是成套的，所以就用著
拉塊白板放在團隊旁邊... 缺陷是不能同步PC, 如果可以接受照片就大家OK, 呵呵。
白板 + Excel + 郵件
————————————————————————————————————————既然敏捷，我的原則是盡量不折騰未知工具，簡單工具不能滿足的話，則計劃自己開發。推薦閱讀：