Xác định lại các phương pháp hay nhất [đã đóng]

Bạn sử dụng những mẹo và "tiêu chuẩn" nào trong quy trình quản lý dự án Redmine của mình?

Bạn có một mẫu chèn wiki tiêu chuẩn mà bạn có thể chia sẻ hoặc một cách tiêu chuẩn để làm việc với một dự án bằng cách sử dụng các nhiệm vụ tính năng lỗi và các vấn đề hỗ trợ không?

Bạn có để cho các vấn đề và cập nhật được gửi qua email cho Redmine không? Bạn có sử dụng các diễn đàn? Bạn có sử dụng kho SVN không? Bạn có sử dụng Mylyn trong nhật thực để làm việc với danh sách nhiệm vụ không?

Tôi đang cố kéo nợ của chúng ta. vào một số PM dựa trên web thay vì tài liệu Word được gửi qua email về các yêu cầu mơ hồ, tiếp theo là tài liệu Word giải thích cách QA và Triển khai khiến tất cả bị lạc trong một đống các bản cập nhật và dự án cạnh tranh để đến lúc tôi phải sửa một cái gì đó, không ai có thể tìm thấy bất kỳ tài liệu nào về cách nó hoạt động.

Tôi phát triển và duy trì các ứng dụng nội bộ cho một nhóm công ty sản xuất. Tính đến thời điểm nhận xét này, tôi là nhà phát triển / nhà phân tích duy nhất trong nhóm CNTT. Trong thời kỳ tồi tệ nhất của cuộc suy thoái, nhu cầu dự án của tôi bùng nổ. Vì vậy, dự án VÀ vấn đề tồn đọng của tôi khá khó sử dụng. Hiện chúng tôi đang trong quá trình tái cấu trúc để mở rộng đội ngũ.

Dưới đây là cách tôi sử dụng Redmine để giữ cho đầu của tôi luôn thẳng (trong phạm vi có thể), người dùng của tôi không bị ảnh hưởng và hy vọng ngăn chặn quá nhiều sự nắm tay của nhân viên mới trong tương lai.

• Tôi sử dụng Subversion để kiểm soát nguồn, với TortoiseSVN và plugin được đặt tên phù hợp là Tortoise-Redmine . Làm mới Kho lưu trữ trên dự án Redmine sau khi cam kết liên kết vấn đề, hiển thị bản sửa đổi về vấn đề và cập nhật các bên liên quan của tôi qua thông báo qua email.
• Tôi coi mô tả dự án như một phương tiện truyền đạt mục đích, phạm vi và giai đoạn vòng đời của dự án cho những người không tham gia. Bằng cách đó, người dùng của tôi biết những gì tôi có trên đĩa của mình và những gì vẫn còn trong bữa ăn tự chọn mà tôi đang nhìn từ xa.
• Tôi sử dụng các tên vai trò cụ thể cho các tập hợp quyền của mình để chỉ ra nhiều hơn một tập hợp các quyền - một lần nữa, như một phương tiện tài liệu. Các vai trò của tôi bao gồm những người sau: Quản lý dự án, Thành viên nhóm dự án, Chủ sở hữu, Người dùng chính, Người dùng phụ, Người quan sát, Overlord (đối với các sếp của tôi ... vui và không thể phủ nhận là đúng).
• Tôi sử dụng Wiki và Tài liệu để làm tài liệu, tùy theo tài liệu mà tôi cảm thấy phù hợp.
• Các phiên bản khá vô dụng đối với tôi, vì vậy thay vì sử dụng nó cho các bản phát hành theo kế hoạch, tôi sử dụng nó để nhóm các vấn đề liên quan thành nước rút.
• Tôi sử dụng plugin Stuff-To-Do tuyệt vời của Eric Davis để tổ chức / sắp xếp lại các lần chạy nước rút nói trên trước khi chỉnh sửa hàng loạt Phiên bản mục tiêu về các vấn đề của tôi. Điều này cũng cho phép các bên liên quan của tôi biết tôi đang làm gì và tôi ưu tiên lợi ích của họ như thế nào (tốt hơn hay tệ hơn).
• Để khuyến khích người dùng tương tác, tôi đã thêm các liên kết đến dự án Redmine vào menu Trợ giúp của ứng dụng của mình. Hộp "Giới thiệu" cũng chứa liên kết đến dự án Redmine.

Các kế hoạch trong tương lai

• Tôi hy vọng một lúc nào đó sẽ hoàn thành phần mở rộng Visual Studio của mình để tích hợp Redmine.
• Xây dựng thư viện mã để kết hợp lỏng lẻo ứng dụng của tôi với dự án Redmine của nó: tự động gửi lỗi, cảnh báo các bên liên quan đăng ký từ khay hệ thống, menu Trợ giúp tương tác có thể tái sử dụng được điều khiển bởi API REST của Redmine, v.v. (Có thể tự động hóa các phần tài liệu với Wiki?)

Tôi là nhà phát triển web Ruby và Redmine làm việc tự do, người điều hành công việc kinh doanh phát triển của một (tôi). Vì vậy, Redmine của tôi được thiết lập để khá nhẹ và tập trung vào khách hàng. Redmine của tôi cũng có nhiệm vụ kép trong việc lưu trữ các dự án Nguồn mở của tôi.

Tôi cho phép các vấn đề và bản cập nhật mới được gửi qua email và nó hoạt động hiệu quả đối với những người dùng được kết nối email (hoặc những người luôn sử dụng iPhone của họ).

Tôi đã sử dụng chế độ xem kho lưu trữ với kho lưu trữ git và nó hoạt động rất tốt. Với mỗi lần đăng ký, tôi tham chiếu vấn đề với #nnn, vì vậy trang vấn đề thực tế sẽ hiển thị tất cả các cam kết để triển khai tính năng.

Tôi thấy các diễn đàn được sử dụng không đúng cách. Tôi nghĩ nếu có một số tích hợp email, chúng sẽ hữu ích hơn.

Chúng tôi thấy hữu ích với các phương pháp sau:

1) Ẩn trình theo dõi "Sự cố" và "Hỗ trợ" và lưu mọi thứ dưới dạng lỗi :

• tiết kiệm thời gian cho nhà phát triển, người kiểm tra, quản lý;
• nếu một số hoạt động được tính là "bổ sung" hoặc "tính năng mới" hoặc bất cứ điều gì khác, các cuộc họp nhanh sẽ được sắp xếp để đánh giá chúng.

2) Các mốc và phiên bản Tôi thích điều này, bạn có thể dễ dàng theo dõi trạng thái của mỗi bản phát hành và bất kỳ lúc nào bạn có thể tải xuống gói cũ hơn, tức là để kiểm tra lỗi do khách hàng gửi.

3) Chức năng "lưu" trên tab "sự cố": một trình tiết kiệm thời gian lớn khác, tôi có các truy vấn khác nhau được lưu cho nhiều nhiệm vụ báo cáo hàng ngày và đó là tất cả những gì tôi cần.

4) tích hợp phiên bản, tức là sử dụng "# 123" trong nhận xét tạo ra một liên kết đến vấn đề tương ứng: đơn giản là thông minh!

Chúng tôi sử dụng Redmine rộng rãi trên hệ thống của mình. Chúng tôi thậm chí đã thiết lập một dự án "Bán hàng" cho nhóm bán hàng của chúng tôi để sử dụng làm CRM. Chúng tôi có một đống các trường tùy chỉnh trong dự án này và nó thay thế SugarCRM mà chúng tôi đã sử dụng trước đây.

Trong hệ thống của chúng tôi, chúng tôi có các dự án cho phần mềm Máy chủ và Máy khách. Dự án máy chủ được chia thành các mô-đun con, dựa trên cách tôi đã cấu trúc hệ thống và các kho phụ, vì Redmine thích một kho riêng cho mỗi dự án.

Như những người khác lưu ý, chúng tôi sử dụng mã #nnn trong tin nhắn cam kết để làm vé tham chiếu. Điều thú vị là nó không cần phải là một tấm vé trong cùng một dự án. Do đó, phiếu bán hàng có thể bị chặn do lỗi hoặc yêu cầu hỗ trợ.

Chúng tôi vừa bắt đầu sử dụng Tài liệu cho chương trình làm việc / biên bản cuộc họp. Chúng tôi sử dụng các Phiên bản để nhóm thành các bản phát hành, trên cả máy khách và máy chủ.

Để cố gắng sử dụng plugin Redmine Time Tracker để theo dõi thời gian, nhưng tôi luôn quên nhấp vào bắt đầu hoặc kết thúc. Chúng tôi nhận được email hàng ngày về các vấn đề chưa được giải quyết trong một thời gian (Tôi nghĩ là Redmine Whining) và có ngày đến hạn trong quá khứ hoặc tương lai gần (Nhắc nhở nâng cao).

Email hỗ trợ đi thẳng vào dự án Hỗ trợ của chúng tôi và nếu việc nhập email mạnh hơn một chút (đôi khi nó không tạo vé mới đúng cách nếu dòng Dự án: được bao gồm trong email), chúng tôi sẽ có các câu hỏi trên trang web tự động tạo Phiếu bán hàng . Vì hiện tại, chúng tôi chỉ cần theo dõi các phiếu Hỗ ​​trợ và chuyển chúng sang Bán hàng nếu có.

Những điều tôi muốn có thể làm:

• Có mối quan hệ giữa hệ thống của chúng tôi và redmine, để vé có thể được liên kết với người dùng hoặc công ty trong hệ thống của chúng tôi. Ngoài ra, để chúng tôi có thể tạo một công ty mới từ Phiếu bán hàng tại điểm có liên quan. Điều này chỉ yêu cầu tôi làm một số công việc.
• Có mối quan hệ giữa phần mềm theo dõi lỗi của chúng tôi (sentry) và redmine, do đó lỗi máy chủ tạo ra redmine. Một lần nữa, có thể giải quyết được với công nghệ hiện tại.
• Có một máy tính để bàn khách hàng để xác định lại. Máy chủ nằm trong mạng LAN của chúng tôi, nhưng có thể có một cách linh hoạt hơn để truy cập dữ liệu khác ngoài trang web sẽ rất tuyệt. Nó không phải là có bất cứ điều gì tôi có thể không thực sự làm trong giao diện web redmine, nhưng cái gì đó như Things.app là rất nhiều đẹp hơn để làm việc trong.
• Có tất cả tài liệu hỗ trợ của chúng tôi trong redmine, và sau đó được tạo ra trên một máy chủ công khai. Bằng cách đó, nhân viên hỗ trợ của chúng tôi có thể duy trì tài liệu, chỉnh sửa theo cách tốt đẹp và triển khai các thay đổi ra doc-server.

Redmine đã rất tuyệt vời đối với chúng tôi cho đến nay. Chúng tôi sử dụng nó như một hàng đợi đặt vé / ưu tiên nhanh cho nhiều người thuê và cũng đã gắn nó với SVN. Đặc biệt:

• Cài đặt / bảo trì qua SVN thật dễ dàng (tôi đã chuyển chúng tôi từ 1.1 sang 1.2 sang 1.3 sang 1.4 thông qua việc sử dụng các svn switch https//.../branches/1.3-stable .lệnh theo sau là các rake migratelệnh chỉ đôi khi cần cài đặt đá quý ở giữa).
• Sao lưu cơ sở dữ liệu và các tệp được lưu trữ là một quá trình thực thi tập lệnh một dòng
• Chúng tôi yêu thích các plugin Theo dõi thời gian và Đã dành thời gian . Tôi sẽ giết đối với một ứng dụng khách béo theo dõi thời gian Mac OS X cho một số người dùng văn phòng của chúng tôi, nhưng điều đó không quan trọng :)
• Chúng tôi không sử dụng Diễn đàn nhiều, nhưng sử dụng nhiều Hoạt động và Lộ trình. Ràng buộc các vấn đề với các phiên bản cụ thể là một ơn trời.
• Chúng tôi cũng có sự khác biệt giữa Máy khách / Máy chủ, nhưng sử dụng phiên bản đích để ràng buộc các vé để chỉ định cái nào sẽ đi đến đâu (và đã mở KẾT THÚC BẢN TIN KHÁCH HÀNG TIẾP THEO / GIAI ĐOẠN TIẾP THEO) để phân biệt giữa khi đang làm việc.
• Chúng tôi kết hợp các phép ẩn dụ cho các trạng thái - chúng tôi sử dụng danh sách của mình được nhóm theo các trạng thái này trước tiên ("Ngay lập tức", "Bị từ chối", "Bị chặn", "Đang hoạt động", "Trên sàn" "Danh sách", "Đang chờ xây dựng", "Đã phát hành để thử nghiệm "," Đã xác minh "," Đã phát hành để sản xuất "," Đã đóng "," Đã hủy).
• Sau đó, trong mỗi nhóm ở trên, chúng ta có danh sách các Ưu tiên được sắp xếp sau: ("Ngay lập tức", "Ưu tiên cho Tôi", "Thiết kế và Kích thước cho Tôi", "P1"… "P5", "Danh sách P-Watch"). Điều này cộng với những điều trên cho phép quy trình làm việc dễ dàng tất cả từ khu vực vấn đề.
• Đối với danh sách các vấn đề cơ bản, chúng tôi sắp xếp theo "Mức độ ưu tiên", "Nhiệm vụ chính", sau đó là "Ngày cập nhật" - cần cái ở giữa đó để Redmine thụt lề độc đáo nếu có một nhiệm vụ con trong cùng một nhóm.
• Chúng tôi sử dụng cam kết đăng ký để gắn cam kết với các vấn đề (tức là svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") - và chuyển vấn đề đó thành "Đang chờ xây dựng" (Điều đó từng là "Đã giải quyết", nhưng tôi đã mệt mỏi khi giải thích rằng "Đã giải quyết" không có nghĩa là ai đó có thể mong đợi để xem nó được phát hành chưa).

Tôi nghĩ rằng tôi sẽ phải điều tra plugin Redmine-thứ-việc-cần-làm. +1 Câu hỏi.

Công ty của tôi làm việc với các nhà phát triển phần mềm và phần cứng có nguồn gốc quốc tế. Trước khi tôi gia nhập công ty, email đã được sử dụng với các tài liệu MS Word để chuyển tiếp các vấn đề và lỗi của chúng tôi với phần mềm hoặc phần cứng để yêu cầu sửa chữa. Quá trình này không thể theo dõi và duy trì bất kỳ loại quy trình nào. Tôi đã triển khai RedMine như một phương tiện để theo dõi các lỗi phần mềm và phần cứng và nó hoạt động rất tốt kể từ đó. Có một rào cản ngôn ngữ lớn với hoàn cảnh của tôi. Rất may, RedMine có thể hiển thị bằng ngôn ngữ Trung Quốc Sipmlified và phản hồi cho thấy rằng điều này là ổn từ các nhà phát triển của tôi.

Trạng thái - Khi tôi tìm thấy sự cố phần mềm hoặc phần cứng, Trạng thái là "Mới" - Khi các nhà phát triển phần mềm / phần cứng của tôi gặp sự cố này và họ đang giải quyết vấn đề đó, họ sẽ thay đổi trạng thái thành "Đang xử lý". Họ có thể sử dụng% hoàn thành nếu họ muốn từ 0 - 50. Tôi yêu cầu họ đặt% Hoàn thành thành 50 khi họ cảm thấy đã giải quyết được vấn đề. - Tôi xác định xem sự cố đã được khắc phục chưa và tôi thay đổi Trạng thái thành "Đã giải quyết" và% hoàn thành thành 100%. Điều này cho phép tôi lọc ra các vấn đề <hoặc bằng 50% để tìm các vấn đề vẫn còn mở.

Ưu tiên - Thấp, Bình thường, Cao, Khẩn cấp, Ngay lập tức đều dịch tốt sang tiếng Trung.

Ngày đến hạn - Tôi sử dụng thông tin này để cho tôi biết khi nào bản sửa lỗi được các nhà phát triển phần mềm của tôi tải lên ban đầu. Tôi có thể mất 4-6 ngày để kiểm tra nội dung nào đó và đóng vấn đề. Tôi thích biểu đồ Gannt của mình phản ánh khả năng đáp ứng của nhóm phần mềm của tôi, không phải mất bao lâu để tôi phê duyệt bản sửa lỗi.

Danh mục - Điều này luôn phản ánh phiên bản phần mềm hoặc phần cứng mà tôi tìm thấy sự cố. Tôi sử dụng công cụ này để xem phiên bản phần mềm nào có nhiều lỗi nhất và để đảm bảo các phiên bản phần mềm mới hơn không bị thoái triển.

Tôi đã đưa mọi người vào danh sách theo dõi RedMine để tìm tất cả các lỗi. Email có dạng (Mới), (Đã giải quyết) hoặc (Đang xử lý) nên những người giám sát của tôi cũng như các giám sát viên và kỹ sư trưởng của các nhóm liên quan đều có thể xem email và nhanh chóng đọc được tiến độ hiện đang được thực hiện. Hầu hết những người khác có liên quan không bao giờ đăng nhập vào RedMine, tôi thường là người duy nhất. Các email này phục vụ hoàn hảo để cung cấp thông tin cập nhật tức thì cho tất cả những người có mối quan tâm duy nhất là có tiến bộ hay không.

Như bạn đã đề cập đến việc gửi các tài liệu Word qua lại và chuyển tiếp với QA của bạn - Tôi biết cảm giác này, đã ở đó, đã làm điều đó. Vấn đề chính đối với tôi là: Những người QA không thích thêm các vấn đề vào bất kỳ trình theo dõi lỗi nào, họ ghi lại chúng trong một trình chỉnh sửa bên cạnh trong quá trình thử nghiệm.

Hiện chúng tôi đang sử dụng Redmine với một addon tuyệt vời - Usersnap (Tuyên bố từ chối trách nhiệm: Chúng tôi đã xây dựng công cụ để giải quyết vấn đề này cho chính mình.

Usersnap rất tuyệt vời cho các nhà phát triển web - thêm nó vào dự án web của bạn và bạn sẽ nhận được ảnh chụp màn hình trực tiếp đính kèm với vé Redmine - bao gồm thông tin meta về trình duyệt đã sử dụng, hệ điều hành, v.v.

Các QAs / khách hàng của chúng tôi có thể nhập lỗi ngay bây giờ trực tiếp trong ứng dụng web và các nhà phát triển sẽ dễ dàng tạo lại các báo cáo lỗi vào Redmine hơn.

Chúng tôi đang sử dụng phần Lộ trình như một cách rõ ràng để hiển thị:

• lỗi
• các tính năng (đó sẽ là tham chiếu đến tài liệu word của bạn hoặc liên kết đến các trang yêu cầu html)
• đối chiếu (sự khác biệt giữa giá trị sản xuất và giá trị thử nghiệm)
• và như thế...

Đó là điểm hợp nhất chính đối với chúng tôi. Phần còn lại được sử dụng liên quan đến điều đó (ví dụ: phần 'thông báo' được sử dụng để xác định mốc / ngày phát hành chính được sử dụng trong lộ trình)

Ngoài các nhận xét khác, tôi khuyên bạn nên sử dụng -Plugin "Công việc cần làm" (Tôi nghĩ là do Eric Davis viết :) Sử dụng plugin đó cho phép bạn kéo và thả sắp xếp thứ tự các vấn đề trên nhiều dự án.

https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do

Chúng tôi sử dụng các Phiên bản như một cách để xác định nước rút, vì vậy mỗi Phiên bản là một nước rút với chế độ xem Lộ trình đưa ra minh họa rõ ràng về tiến trình. Các vấn đề trong nước rút được đánh dấu là 'sẵn sàng để xem xét' khi hoàn thành và sau đó được đóng lại khi QA đã xác minh.

Chúng tôi sử dụng Phiên bản làm hồ sơ tồn đọng cho bất kỳ vấn đề nào nằm ngoài phạm vi hoặc mất quyền ưu tiên của chúng, v.v.

Chúng tôi đã sử dụng Redmine khoảng một năm nay và nó đã tự phát triển theo nhiều cách. Chúng tôi sử dụng các phiên bản để nhóm các vấn đề lại với nhau cho một bản phát hành và các danh mục để nhóm các vấn đề theo kỷ luật.

Mỗi vấn đề trải qua một quy trình làm việc mới> đang xử lý> đã được giải quyết. Sau đó, người kiểm tra sẽ đóng vấn đề khi hài lòng.

Chúng tôi rất muốn cập nhật cách chúng tôi sử dụng Redmine, có vẻ như có rất nhiều plugin tuyệt vời, nhưng chúng tôi thấy rất nhiều plugin bị hỏng hoặc không cài đặt được.

Chúng tôi sử dụng wiki một cách toàn diện cho tài liệu dành cho nhà phát triển.