Scrum và Fogbugz

Question

Bất cứ ai ngoài đó sử dụng Fogbugz và Scrum cùng nhau?

Chúng tôi sử dụng Fogbugz rộng rãi và tôi đang tìm ý tưởng từ bất kỳ ai có thể sử dụng nó như một phần của Scrum. Tôi đã tìm thấy hai mục này, nhưng chúng được lưu trữ và không có sẵn để thảo luận thêm. Tôi đặc biệt quan tâm đến các ý tưởng để ánh xạ các khái niệm Scrum vào Fogbugz.

Một số điều khá rõ ràng. Phát hành và chạy nước rút lập bản đồ tốt với nhau. Nhưng các phần khác của Scrum không thực sự phù hợp.

http://support.fogcreek.com/default.asp?fogbugz.4.12143.4
http://support.fogcreek.com/default.asp?fogbugz.4.19971.3

Tôi cũng đang nghĩ đến nó có thể không quá khó để tạo ra một số công cụ tùy chỉnh nhẹ để quấn quanh Fogbugz để chúng ta không cần phải từ bỏ một trong những công cụ yêu thích của chúng tôi để để cải thiện quá trình tích hợp quy trình phần mềm của chúng tôi.

Edit:

tôi thêm một số câu hỏi cụ thể hơn mà đã đưa ra. Mọi góp ý về các mặt hàng này sẽ rất hữu ích:

• Làm thế nào để chúng ta ưu tiên một tồn đọng lớn chỉ với những ưu tiên 7 mức cung cấp bởi Fogbugz? Chúng tôi có thể sửa đổi các bảng cơ sở dữ liệu để thêm cấp độ khác, nhưng đó có phải là thích hợp trong mô hình hiện tại/dự định Fogbugz không?
• Làm cách nào/nơi nào chúng tôi ghi lại mục tiêu chạy nước rút?
• Làm cách nào để ghi lại một lần chạy nước rút bị hủy?
• Làm cách nào để ghi lại đánh giá chạy nước rút?
• Làm cách nào để theo dõi hoàn thành hoặc hủy chạy nước rút?

Chỉnh sửa # 2: trả lời

Chris dưới đây nhắc nhở tôi rằng chúng tôi đã thực sự nâng cấp lên Fogbugz v7.Nó có nhiều tính năng tuyệt vời mà gắn kết chặt chẽ hơn với Agile, Scrum, và Lean bao gồm:

• Backlog dự án (thông qua plugin)
• Tuỳ chỉnh Workflow
• Burn Xuống Charts
• Kanban Board (qua Plugin)

Xem các liên kết sau đây để biết thêm:
http://www.fogcreek.com/FogBugz/WhatsNew.html
http://www.fogcreek.com/FogBugz/Plugins/default.aspx?ixCategory=-3

Chỉnh sửa # 3 Thêm liên kết Perhentian đề cập trong câu trả lời của mình cũng như khác tôi thấy:

http://www.danielroot.info/2009/08/how-to-apply-scrum-using-fogbugz-7.html
http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx

Answer 1

FogBugz bây giờ (như các phiên bản 7) hỗ trợ plugin, mà nên làm cho nó dễ dàng hơn để sử dụng với Scrum.

Tools for Agile/Scrum

Answer 2

Chúng tôi đang trong quá trình thử FogBugz trên SCRUM dựa trên dự án.

Chúng tôi vẫn đang tìm kiếm rất nhiều chân với SCRUM (và FogBugz) vì vậy những gì chúng tôi đang thực hiện có thể không phải là SCRUM thuần túy.

Trước hết, chúng tôi đang sử dụng Excel cho bản phát hành tồn đọng, ví dụ: những gì chúng tôi sẽ phân phối trong phiên bản x.xx

Tôi đã thực sự viết một blog post về cách sử dụng FogBugz làm việc tồn đọng nhưng kết thúc bằng Excel như những gì tôi đã đề xuất hơi phức tạp khi nhìn lại và tôi không nghĩ Tôi đã thực sự đạt được bất cứ điều gì.

Trong bảng tính tồn đọng chúng tôi giữ nguyên tên của mục log lại, một ước tính kích thước, vì vậy chúng tôi có thể tính toán vận tốc, và một số thông tin khác như mà chạy nước rút, chúng tôi sẽ cung cấp mỗi mục trong.

Chúng tôi tiếp tục của chúng tôi thông số kỹ thuật của sản phẩm trong wiki FogBugz và thêm các liên kết này từ mỗi mục trong phần tồn đọng.

Trong Fogbugz, chúng tôi ánh xạ các bản phát hành để chạy nước rút và sử dụng các mục lịch biểu để theo dõi nhiệm vụ của chúng tôi cho từng mục tồn đọng.

Trước khi bắt đầu chạy nước rút, chúng tôi chọn mục backlog mà chúng tôi sẽ cung cấp trong lần chạy nước rút này. Trong FogBugz tôi tạo một bản phát hành mới và đặt ngày kết thúc thành hai tuần xuống dòng. Sau đó, chúng tôi chia nhỏ các mục đã tồn đọng đã chọn thành công việc và thêm chúng vào bản phát hành dưới dạng 'mục lịch'.

Mọi người đều ước tính nhiệm vụ của chính họ và theo dõi thời gian chống lại họ bằng cách sử dụng trình đơn 'làm việc trên' như bình thường. Mỗi ngày các thành viên trong nhóm sửa đổi các ước tính của họ và sau đó chúng tôi có thể sử dụng các báo cáo khác nhau để xem mọi thứ đang tiến triển như thế nào. Biểu đồ độ tin cậy ngày của tàu cho bạn một loại tóm tắt ngược lại.

Mỗi thành viên trong nhóm cũng có mục lịch 'trạng thái' mà họ chỉnh sửa hàng ngày để ghi lại báo cáo trạng thái cho cuộc họp đứng hàng ngày, ví dụ: hôm qua tôi đã làm gì? Tôi đang làm gì hôm nay? Những trở ngại nào theo cách của tôi?

Như bạn có thể thấy chúng tôi thực sự chỉ sử dụng FogBugz để quản lý tác vụ.

Chúng tôi đã chọn nó nhiều hơn cho EBS và Wiki.

Cho đến nay nó hoạt động khá tốt nhưng dự án tôi đang sử dụng nó là một dự án 3 tuần 6 người.

Hy vọng một số điều này sẽ hữu ích. Hãy cho tôi biết nếu bạn cần làm rõ.

Chỉnh sửa: Tôi cũng không cố gắng để có được hệ thống hoàn hảo và chạy lần đầu tiên. Tôi rất lấy cách tiếp cận của cố gắng một cái gì đó ra và nếu nó không làm việc ra, sau đó thay đổi nó. Cho đến nay rất tốt với FogBugz mặc dù.

Answer 3

Sau khi sử dụng FOGBUGZ và JIRA cho nhanh, tôi đã quyết định rằng cả hai công cụ đều không thực sự lý tưởng để hỗ trợ mô hình. Bạn có thể làm việc hay không. Vâng. JIRA thực sự tốt hơn một chút vì khả năng tùy chỉnh nhiều hơn (Tạo câu chuyện của người dùng, v.v) Nhưng nếu bạn thực sự muốn nhóm của mình ở chế độ SCRUM, bạn cần phải có mọi người nhìn vào biểu đồ burndown và mọi người nhìn vào một backlog và tôi nghĩ bạn nên xem xét các công cụ như SCRUMWORKS. Phiên bản cơ bản là miễn phí và nó sẽ cung cấp cho bạn những gì bạn muốn. Sử dụng JIRA và Fogbugz cho những gì họ đã có nghĩa là để làm, theo dõi các lỗi và yêu cầu nhưng không phải là một công cụ quản lý SCRUM đầy đủ. '

Cập nhật: Bạn có thể sử dụng plugin Greenhopper cho JIRA tốt hơn một chút để hỗ trợ các dự án nhanh nhẹn.

Answer 4

Chúng tôi sử dụng Scrumworks và JIRA.

SCRUM không thực sự đề cập đến cách bạn triển khai thủ tục QA/QC, một phần của nhanh nhẹn là có thể xác định, cải tiến, lặp lại quy trình.

Answer 5

Tại icanhascheezburger.com, chúng tôi sử dụng FogBugz và chúng tôi nhận thấy rằng FogBugz rất tuyệt vời ở rất nhiều thứ, nhưng nó không hoạt động tốt cho sự phát triển nhanh của hộp. Dưới đây là hai điều chúng tôi làm:

Chúng tôi sử dụng các bảng thảo luận cho các báo cáo scrum hàng ngày, mặc dù trang wiki có thể phù hợp hơn vì bạn có thể đăng ký nó.

Chúng tôi cũng sử dụng ưu tiên 7 cho việc tồn đọng. Để tìm tất cả các trường hợp tồn đọng chỉ cần tìm kiếm:

priority:7 project:"project name" 

API sẽ làm cho một khách hàng nhỏ nhắn viết một cách dễ dàng.

Kanban plugin for FogBugz

Answer 6

ý kiến ​​tốt cho đến nay. Tôi sẽ xem xét Scrumworks. Chúng tôi thực sự thích Fogbugz và đội bóng cảm thấy thoải mái với nó, vì vậy đó là lý do tại sao tôi đang cố gắng để xem nếu nó hoàn toàn khả thi.

@Stefan, một trong những đề xuất cho việc tồn đọng sản phẩm trong các bài viết được liên kết là dự án tồn đọng có thể được thực hiện trong Fogbugz bằng cách tạo bản phát hành có thể gán cùng tên không có ngày, một ngày vào cuối hợp đồng chính thức, hoặc một ngày xa trong tương lai. Bạn đã thử hoặc có bất kỳ suy nghĩ về lý do tại sao phương pháp của bạn có thể tốt hơn?

Answer 7

Chúng tôi sử dụng FogBugz cho scrum bằng cách sử dụng "bản phát hành" cho dự án tồn đọng và sau đó tạo bản phát hành cho chạy nước rút, di chuyển các mục từ bản phát hành dự án vào bản phát hành chạy nước rút hiện tại. Mỗi mục đều có ước tính và từ đó chúng tôi có thể xây dựng biểu đồ burndown, như minh họa trong this earlier SO question.

Không, nó không lý tưởng nhưng nó hoạt động đủ tốt.

Answer 8

FogBugz & Scrum làm việc cùng nhau đầy đủ.Tôi nghĩ rằng bạn là những câu hỏi hay, vì vậy tôi sẽ gắn bó với việc trả lời thosse ...

Làm cách nào để ưu tiên một backlog lớn chỉ với 7 mức độ ưu tiên do Fogbugz cung cấp? Chúng ta có thể sửa đổi các bảng cơ sở dữ liệu để thêm nhiều cấp độ hơn, nhưng liệu có thích hợp trong mô hình Fogbugz hiện tại/dự định không?

IMHO 7 là quá nhiều để quản lý, tôi thấy rằng top 3-4 có thể quản lý và vượt ra ngoài mà tôi cũng có thể gộp tất cả mọi thứ thành một backlog "sau" duy nhất. Tuy nhiên, tài liệu FogBugz hoặc bài viết KB thỉnh thoảng đưa ra hướng dẫn cho những người đã thêm các mức độ ưu tiên bổ sung, vì vậy nếu FogBugz không có ý định sử dụng nó thì họ dường như nhận thức rõ về nó và về cơ bản hỗ trợ mọi người làm điều đó.

Chúng tôi ghi lại mục tiêu chạy nước rút ở đâu? Chúng tôi có trang "đánh giá chạy nước rút" trên wiki cho từng dự án. Chúng tôi ghi lại lần chạy nước rút mới nhất ở trên cùng và biến nó thành một trang lớn (mặc dù tôi tưởng tượng chúng tôi sẽ chỉ giữ lại năm gần đây nhất hoặc một cái gì đó, vì những trang đó đang trở nên LỚN). Đánh giá chạy nước rút mà chúng tôi sử dụng rất đơn giản và có một nhóm các trường phải được hoàn thành bởi nhóm và PM. Trước khi chạy nước rút, chúng tôi ghi lại mục tiêu và SBL, sau khi chúng tôi thêm các trường để xem xét.

Làm cách nào để ghi lại một lần chạy nước rút bị hủy?

Trong trang đánh giá chạy nước rút đã đề cập ở trên.

Làm cách nào để ghi lại đánh giá chạy nước rút? Làm thế nào để chúng tôi theo dõi chạy nước rút đã hoàn thành hoặc hủy bỏ?

Tôi tưởng tượng bạn có thể đoán thế nào chúng ta đối phó với hai bây giờ :)

Tôi hy vọng đó là hữu ích cho bạn và những người khác đọc. Chúng tôi có một vài cuộc tấn công của fogbugz liên quan đến FB ước tính rằng tôi đã không đi vào đây, nhưng nếu bạn muốn thảo luận nữa, tôi sẽ rất vui khi làm điều đó. Có lẽ bạn có một số kinh nghiệm để chia sẻ mà tôi có thể học hỏi từ?

-scott

Answer 9

Các mở công cụ nguồn trac có FogBugz integration, và cho phần Scrum bạn có thể sử dụng Agilo for Scrum, mà là dựa trên trac và hỗ trợ Scrum một cách toàn diện.

Answer 10

Kiểm tra phiên bản mới của FogBugz. Có một bài viết blog ở đây tóm tắt những cải tiến để hỗ trợ Scrum. Chúng tôi sử dụng nó và nó hoạt động tốt cho chúng tôi.

http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx

Answer 11

Chúng tôi đã sử dụng FB một thời gian dài thời gian , nhưng vừa mới bắt đầu chính thức hóa sử dụng của chúng ta về Scrum.

Tìm thấy những điều sau đây PRETTY hữu ích:

1. sử dụng một thẻ cho mỗi nước rút Scrum.
2. Thẻ sprint được nhập vào mỗi trường hợp FB trong lần chạy nước rút đó.
3. Chúng tôi có một Wiki gọi là "Báo cáo Sprint Sprint"
4. Trong Wiki đó, chúng tôi thêm một bài viết cho mỗi lần chạy nước rút mới (chúng tôi có chúng theo tuần). Bài viết đó có cùng một thẻ giống như của sprint.

Sau đó, những điều sau đây giúp:

Thứ nhất, nếu bạn chỉ đơn giản là tìm kiếm theo thẻ, bạn sẽ tìm thấy: tất cả các trường hợp và các bài viết Wiki cụ thể (mà ngay cả trong tiêu đề xem sẽ cho bạn thấy những mục tiêu) Thứ hai, chúng tôi tạo hai bộ lọc: một bộ lọc để hiển thị các trường hợp của scrum đó trong chế độ xem danh sách và bộ lọc thứ hai hiển thị các trường hợp mở/đóng trong biểu đồ hình tròn. Khi bạn trải qua tuần, bạn hy vọng sẽ ăn nhiều hơn chiếc bánh.

Điều duy nhất mà tôi không thích về điều này là tôi phải sửa đổi hai bộ lọc của tôi mỗi thứ Sáu, nhưng ít nhất là TGIF.

---

PS: Chỉ cần cảm thấy đề cập đến FB Wiki Editor tốt hơn một trong 7.0, nhưng thực sự nên được phiên bản 0.8. Đó là ít nhất 2 phiên bản từ một cái gì đó ổn định.