Các vấn đề nhóm SCRUM phân tán: Môi trường làm việc

Một vấn đề thú vị xuất hiện cho tôi ngày hôm nay. Trong một nhóm SCRUM phân tán khi nào bạn bắt đầu thực thi một môi trường làm việc đơn nhất về định dạng mã, các plugin IDE (checkstyle & co), VCS, CI? Nhóm nghiên cứu đang trong giai đoạn thăm dò và thegoal không phải là mã chất lượng sản xuất mà là bằng chứng về khái niệm. Không phải là một chi phí chung để thực thi một số quy tắc mã hóa phổ biến "tiên nghiệm" - trước khi các thành viên trong nhóm quyết định cái nào thực sự phù hợp cho công việc tương lai của họ? Sử dụng loại công cụ này chắc chắn mang lại lợi ích rất lớn bởi vì chúng hoạt động như một công cụ tìm kiếm để giảm thiểu nợ kỹ thuật nhưng thực thi các quy tắc là "không có dấu vết" thực sự phá vỡ công trình Jenkins dường như là một sự quá mức cần thiết cho một giai đoạn nên tập trung hơn trên mỏ đá hơn là tạo mã sản xuất.

Đề cập 1: các nguyên mẫu tạo ra sẽ bị ném đi

Đề cập 2: mặc dù tôi ước rằng mọi thứ nên được thực hiện ngay từ đầu - tôi hoàn toàn ý thức được rằng nó không thể 100%.

Tôi nghĩ có 3 phần của vấn đề:

1. Bạn muốn tiết kiệm nợ kỹ thuật / đau đầu xuống đường bằng cách thực thi các quy tắc tốt ngay bây giờ.
2. Bạn không muốn giết vận tốc đội bằng cách làm cho mọi người sa lầy với những quy tắc không cần thiết.
3. Bạn không biết chính xác các quy tắc tốt nhất để thực hiện, vì dự án đang trong giai đoạn thăm dò.

Tôi đã thử cả hai thái cực (từ không có quy tắc, chỉ sử dụng cùng một điều khiển nguồn, đến hướng dẫn kiểu mã hóa 20 trang + nhiều quy trình khác)

Điều duy nhất hoạt động ổn định là nắm lấy mức tối thiểu tuyệt đối mà tôi biết tôi cần và có thể chứng minh tôi cần ngay bây giờ, và sửa đổi quy trình thường xuyên . (Mỗi lần chạy nước rút trong quá trình hồi cứu là thời điểm tốt để thực hiện) Điều này cũng bao gồm loại bỏ bất kỳ quy tắc di tích nào.

Tôi đoán điều này thực sự phụ thuộc vào các đội và bạn quan tâm đến checkstyle đến mức nào. Tôi đồng ý rằng chúng ta nên có một số loại quy tắc để ngăn chặn một số lỗi không cần thiết. Nhưng một số quy tắc là khá khó chịu hơn năng suất. Tôi đoán bạn phải đồng ý trong nhóm những quy tắc nào là cần thiết và không cần thiết.

Thiết lập các công việc Jenkins cho checkstyle hoặc fireorms cũng tốt, nhưng một lần nữa bạn phải đồng ý rằng bạn muốn nó nghiêm ngặt đến mức nào. Tôi đã ở trong một tình huống mà ai đó đã phá vỡ một số quy tắc kiểm tra và chúng tôi ngăn chặn bất cứ ai cam kết. Về lâu dài, nó sẽ chỉ làm phiền mọi người. Một lần nữa, nếu bạn nói mọi người không cần phải chú ý nhiều thì họ sẽ bắt đầu phớt lờ họ. Vì vậy, trong nhóm của tôi, chúng tôi đồng ý rằng miễn là công việc chất lượng không bị phá vỡ. Nó phải có màu xanh trước khi kết thúc nước rút.

Vì vậy, đề nghị của tôi sẽ là, timebox cuộc họp để bạn không dành nhiều thời gian vào việc tạo quy tắc và thảo luận về các quy tắc.

Một số suy nghĩ, IDE hiện đại có plugin checkstyle để cảnh báo mọi người khi một số quy tắc đã bị phá vỡ, nhóm có thể đồng ý chỉ kiểm tra trong quá trình xem xét mã trước khi họ cam kết. Điều đó cũng giúp cho đội của tôi.

• Bất kỳ IDE nào không làm cho bạn phát triển nhanh hơn không phải là một công cụ, đó là một chiếc thuyền neo. Ném nó quá mức và không bao giờ nhìn lại.
• Nếu bạn đã có cơ sở hạ tầng CI, hãy sử dụng nó từ ngày 1. Bạn sẽ cảm ơn chính mình sau này, ngay cả khi bạn thực sự thành công trong việc loại bỏ mã nguyên mẫu của mình.
• Ngược lại, đừng lãng phí thời gian để thiết lập hệ thống CI nếu bạn không có. Chi phí quá cao và bạn thực sự hy vọng sẽ bắt đầu lại từ đầu.
• Bắt đầu với một VCS vào ngày 1. Thời gian.

Tôi sẽ đề nghị bắt đầu thực hiện khái niệm về một môi trường làm việc đơn nhất một khi vận tốc của đội bắt đầu ổn định. Điều này có thể gây ra một số phòng kỹ thuật khi bắt đầu dự án, nhưng luôn có phòng kỹ thuật khi bắt đầu bất kỳ dự án nào. :)

Tôi thường thành công trong việc cho phép khía cạnh tự tổ chức của một nhóm đưa ra một cái gì đó phù hợp với họ và yêu cầu của họ. Về cơ bản trình bày nhóm với một mô tả về một vấn đề, như Jenkin Builds thất bại, và cung cấp cho họ cơ hội để 'khắc phục' nó.

Điều này thường dẫn đến việc thực hiện tối thiểu một giải pháp, giống như Zachary Yates đã đề cập trong câu trả lời của ông.

Tôi sẽ lưu ý rằng nó sẽ có lợi cho bạn nếu bạn có một người có trình độ / kỹ năng kỹ thuật cao cấp cung cấp một số hướng dẫn tinh tế, chỉ để giúp nhóm không trở nên kỳ lạ với những gì họ quyết định đi cùng. :)