Làm thế nào Scrum có thể thích nghi với môi trường Tình nguyện?

Gần đây tôi đã tham gia một không gian tin tặc trẻ vẫn đang trong quá trình thiết lập. Chúng tôi may mắn vì không gian có một vài dự án nội bộ cần thực hiện và không thiếu tình nguyện viên để làm việc với chúng.

Đã có một số cuộc thảo luận về cách tổ chức các dự án này. Kinh nghiệm chuyên môn gần đây nhất của tôi là với Scrum vì vậy tôi đang xem xét đưa ra cách tiếp cận Scrum cho các dự án phần mềm của chúng tôi, nhưng tôi không chắc nó sẽ phù hợp.

Mặc dù tôi đã thấy Scrum hoạt động tốt cho các nhóm toàn thời gian nhỏ, nhưng bản chất của tổ chức này là khác nhau:

• Các thành viên là tình nguyện viên . Một số là sinh viên toàn thời gian. Những người khác làm việc toàn thời gian. Chúng tôi không thể mong đợi một mức độ đóng góp liên tục từ bất cứ ai vì cuộc sống thực của họ được ưu tiên.
• Mặc dù khá nhiều người có nhiều năm kinh nghiệm viết phần mềm, nhưng không nhiều thành viên đã làm như vậy một cách chuyên nghiệp hoặc theo nhóm.
• Không có Chủ sở hữu sản phẩm . Các yêu cầu cho các dự án này được xác định bởi một ủy ban. Các thành viên của ủy ban này cũng sẽ làm việc để thực hiện. Điều này có nghĩa là chúng tôi sẽ không có Chủ sở hữu sản phẩm duy nhất, dành riêng.
• Chúng tôi không có thời hạn (mềm hay cứng). Các dự án sẽ được thực hiện khi chúng được thực hiện.

Đây là những khác biệt khá đáng kể, nhưng tôi không tin rằng họ sẽ chặn các ứng dụng Scrum. Tôi nghĩ rằng một số điều chỉnh nhỏ có thể giúp chúng tôi vượt qua rào cản này:

• Nếu chúng tôi thay đổi Sprint để có kích thước điểm câu chuyện cố định, nhưng thời lượng (thời gian) trôi chảy , chúng tôi vẫn có thể hưởng lợi từ các phiên bản lặp mà không gây áp lực giao hàng không thực tế cho các nhà phát triển tình nguyện.
• Chúng ta có thể bỏ các biểu đồ đầu vào và tính toán vận tốc . Nếu tôi hiểu chính xác, đây là những công cụ và số liệu hoạt động như một cầu nối giữa nhóm nhà phát triển và Quản lý. Chúng phục vụ để báo cáo tiến độ trong một hình thức có ý nghĩa đối với cả các nhà phát triển và các bên liên quan. Xem xét chúng tôi không có ai để báo cáo (không có Quản lý dự án, không có Chủ sở hữu sản phẩm và không có các bên liên quan bên ngoài) Tôi tin rằng chúng tôi có thể bỏ hoàn toàn việc này.

Những điều tôi nghĩ rằng chúng ta có thể hưởng lợi từ đó sẽ không yêu cầu điều chỉnh:

• Các cuộc họp Tập hợp các yêu cầu . Nơi mọi người ngồi quanh một cái bàn và thảo luận về Câu chuyện của người dùng, phác thảo các giả lập UI và xây dựng một Product Backlog.
• Hồi tưởng nước rút . Đây sẽ là một cách thú vị để chúng tôi hội tụ về một quá trình phát triển phù hợp với chúng tôi như một nhóm tình nguyện viên.

Những điều tôi không chắc chắn về:

• Nên điều trị Stand-up hàng ngày như thế nào ? Tôi tự hỏi nếu họ sẽ có nhiều giá trị trong thiết lập của chúng tôi. Sự hiểu biết của tôi về nghi thức đứng lên là nó giúp giao tiếp bằng cách phổ biến thông tin một cách tự nhiên trong toàn đội. Xem xét thực tế rằng Sprint của chúng tôi có thể sẽ cung cấp ít phức tạp hơn nhiều so với một Sprint trung bình, có lẽ sẽ không cần phải theo kịp tất cả các tiến trình / phát triển của các thành viên khác trong nhóm.
• Tôi có nên thúc đẩy XP những thứ như Tích hợp liên tục, Đánh giá mã và TDD không? Tôi lo ngại điều này sẽ được yêu cầu rất nhiều. Tôi muốn được đưa các khái niệm này vào các dự án trong tương lai một khi mọi người quen thuộc hơn với Scrum và làm việc theo nhóm.

Những câu hỏi của tôi:

Scrum có thể thích nghi với môi trường dựa trên tình nguyện viên không?
Và, cách tiếp cận theo kế hoạch của tôi cho đến nay đi đúng hướng?

Nhìn vào Kanban. Nó phù hợp hơn SCRUM cho các ràng buộc của bạn.

Chỉnh sửa: SCRUM (rất đại khái) là một hồ sơ tồn đọng có trật tự với nước rút và nghi lễ để đảm bảo rằng khối lượng công việc 'đang tiến hành' vẫn nằm trong tầm kiểm soát và có một cái gì đó vững chắc ở cuối mỗi lần chạy nước rút. Nếu bạn bỏ qua các nghi lễ và chạy nước rút, bạn sẽ kết thúc với Kanban: tồn đọng theo lệnh và nhấn mạnh vào việc hạn chế công việc 'trong tiến trình' và bằng cách đảm bảo mọi thứ được đánh dấu 'hoàn thành' thay vì áp dụng sự ổn định vào cuối mỗi lần chạy nước rút.

Bạn vẫn nhận được các lợi ích nhanh: phát hành bất cứ lúc nào, linh hoạt, một số biện pháp dự đoán - mặc dù SCRUM có thể giúp bạn tiến xa hơn một chút về khía cạnh đó - và không có các nghi thức hoặc khía cạnh của SCRUM không phù hợp với một nhóm phân tán, lỏng lẻo không có cam kết . Cuộc đuổi bắt? Việc bỏ các nghi lễ đòi hỏi nhiều kỷ luật hơn, vì vậy bạn THỰC SỰ cần chú ý đến các bài kiểm tra, chất lượng mã, công việc hiện tại đang diễn ra và đảm bảo phần đầu của hồ sơ tồn đọng (công cụ sẵn sàng để mọi người chọn) được xây dựng đầy đủ.

Bạn có thể có một phiếu tồn đọng dựa trên phiếu bầu, mặc dù trong một tình nguyện viên, một số người chỉ làm việc theo bất cứ điều gì họ muốn.

(Và vâng, tất cả các ý tưởng TDD, CI, đánh giá và lập trình ngang hàng đều là những ý tưởng hay).

Để giải quyết sự khác biệt bạn lưu ý đầu tiên:

• Việc các thành viên của bạn là tình nguyện viên không có nghĩa là bạn không thể yêu cầu họ cam kết. Đặc biệt với thời gian chạy nước rút tương đối ngắn trong Scrum, mỗi thành viên phải có thể biết họ có thể cam kết bao nhiêu thời gian cho dự án trong vài tuần tới. Việc các thành viên trong nhóm có sẵn trong một khoảng thời gian khác nhau mỗi lần chạy nước rút sẽ khiến việc lập kế hoạch khó khăn hơn một chút, bởi vì khó xác định có bao nhiêu điểm cốt truyện là thực tế, nhưng điều đó không làm cho Scrum trở nên không khả thi.
• Chủ sở hữu sản phẩm chịu trách nhiệm củng cố và truyền đạt tầm nhìn (và các yêu cầu) mà các bên liên quan dành cho sản phẩm cho nhóm phát triển. Phần hợp nhất có lẽ đã được bao phủ bởi ủy ban 'chỉ đạo'. Về phần truyền thông, họ chỉ có thể ủy thác một trong những thành viên của mình làm người phát ngôn chính. Điều đó sau đó cho tất cả các mục đích thực tế là chủ sở hữu sản phẩm.
• Không có thời hạn bên ngoài không thực sự là vấn đề đối với Scrum. Nó chỉ đi xuống nhiều hơn vào niềm tự hào của đội trong sản phẩm để hoàn thành nó. Scrum có thời hạn tự nhiên cho mỗi lần chạy nước rút.

Về các điều chỉnh được đề xuất của bạn, đặc biệt là khi làm việc với các tình nguyện viên, tôi thực sự khuyên bạn nên duy trì độ dài nước rút cố định. Bằng cách đó, các tình nguyện viên biết chắc chắn họ đang thực hiện cam kết trong khoảng thời gian nào.

Tôi cũng sẽ không bỏ bảng xếp hạng ngay lập tức. Chúng cũng có thể hữu ích cho chính nhóm để xem họ đang làm như thế nào theo cam kết của họ. Tôi sẽ để nó cho đội quyết định giữ hoặc bỏ chúng. Các tính toán vận tốc cũng vậy. đặc biệt với sự khác biệt lớn về số lần truy cập có sẵn trong mỗi lần chạy nước rút, chúng có thể chứng minh rất hữu ích (đặc biệt nếu bạn tính số điểm hoàn thành trên mỗi lần chạy) trong việc ước tính các lần chạy nước rút trong tương lai.

Về phần nổi bật hàng ngày, chúng vẫn sẽ hữu ích trong cài đặt của bạn, nếu chỉ để cho mọi người biết những gì mọi người đang làm hoặc có vấn đề với (và điều đó không phụ thuộc vào sự phức tạp). Nhưng có thể khó hơn để nhận ra một standup hàng ngày, vì vậy bạn có thể cần phải thỏa hiệp ở đó.

Các thực hành XP mà bạn đề cập có thể được giới thiệu hoặc không độc lập với việc sử dụng Scrum và cũng có thể được đề xuất trong quá trình hồi cứu.

Nó làm tôi ngạc nhiên khi không ai chỉ ra điều đó, nhưng dự án của bạn có vẻ giống như hầu hết các dự án nguồn mở. Nếu bạn kiểm tra một số dự án nguồn mở phổ biến hơn, bạn có thể tìm thấy một số nguồn cảm hứng. Và tôi nghĩ bạn nên quên đi SCRUM và nghĩ về điều này từ quan điểm của sự nhanh nhẹn nói chung.

Agile là tất cả về giao tiếp và hợp tác. Có lý do tại sao có 2 điểm trong 4 trong Agif Manifesto nói về nó.

Các cá nhân và tương tác qua các quy trình và công cụ

Hợp tác khách hàng qua đàm phán hợp đồng

Và cách bạn mô tả dự án của bạn, sẽ rất khó để có giao tiếp mặt đối mặt với mọi người làm việc trong dự án, điều mà cả Agile và SCRUM đều khuyến khích. Vì vậy, điều đầu tiên tôi sẽ tập trung vào là thiết lập các kênh truyền thông cho toàn đội (cả tình nguyện viên và ủy ban sản phẩm). Những thứ như wiki, diễn đàn, hội nghị truyền hình và hệ thống theo dõi tồn đọng, nhiệm vụ và theo dõi lỗi thích hợp là những cách tuyệt vời để đảm bảo mọi người đều biết những gì đang xảy ra và những gì cần phải làm.

Điều thứ hai tôi sẽ lưu ý là không chỉ chải xung quanh các bộ phận công nghệ của agile. Nhiều người tin rằng (bao gồm cả bản thân tôi) rằng họ là những người làm cho công việc nhanh nhẹn, không phải là khía cạnh quá trình của mọi thứ. Đánh giá mã là công việc quan trọng và hầu hết nguồn mở bằng cách có người biết dự án xem xét các cam kết / thúc đẩy để đảm bảo chất lượng đủ cao được duy trì. TDD thực tế được đưa ra cho bất kỳ dự án nhanh. Nó đảm bảo mọi thay đổi đối với mã không phá vỡ chức năng trước đó, điều này thậm chí còn quan trọng hơn trong trường hợp của bạn khi tình nguyện viên không thể bị làm phiền để sửa lỗi và lỗi của người khác. Nó cũng làm cho việc xem lại mã dễ dàng hơn bởi vì người đánh giá có thể thấy trong các thử nghiệm chức năng nào đã được thêm vào và bằng cách chạy chúng, anh ta đảm bảo chức năng thực sự hoạt động như dự định. Tích hợp liên tục giống như TDD.

Điều cuối cùng là tôi tin rằng bạn nên có ít nhất vài người làm việc trong dự án toàn thời gian. Những người đó nên có vai trò cụ thể:

• Chủ sở hữu sản phẩm : Mặc dù thật tuyệt khi bạn có cả một ủy ban dành riêng cho việc này, nên có một người chịu trách nhiệm diễn giải các từ của ủy ban này thành đặc tả hoặc câu chuyện của người dùng và đảm bảo chúng được thực hiện đúng.
• Điều phối viên & Scrum Master : Người này phải chịu trách nhiệm cho toàn bộ quá trình và đảm bảo rằng mọi người đều biết về những điều quan trọng xảy ra trong dự án. Ngoài ra, anh ta duy trì wiki và các công cụ theo dõi lỗi và nhiệm vụ. Nếu ai đó có câu hỏi về dự án, đây là người đầu tiên họ nên hỏi.
• Nhà phát triển & kiến ​​trúc sư chính : Người hiểu mã tốt nhất. Anh ta thực hiện đánh giá mã và đảm bảo chất lượng mã đủ tốt để phát triển nhanh.

Bạn không thể điều chỉnh nó theo cách bạn đang mô tả và vẫn gọi nó là SCRUM. nhưng theo tôi, bạn có thể sử dụng Scrum như sau cho thiết lập mà bạn đã mô tả.

1. Đã lặp lại cố định. Để bạn có thể đo lường sự tiến bộ của bạn. Điều này không chỉ dành cho quản lý mà còn cho đội ngũ để biết về cách thức hoạt động của họ.
2. Yêu cầu các tình nguyện viên chia sẻ năng lực khi bắt đầu lặp lại. Tất cả các đội cần những gì các thành viên đang cam kết nếu không một số thành viên nhất định có thể rời khỏi nhóm để làm việc chuyên nghiệp hơn.
3. Không có thời hạn là tốt. Scrum không ép buộc rằng tuy nhiên những gì bạn làm vào cuối mỗi lần lặp sẽ có khả năng chuyển đổi được. Điều này sẽ cho phép bạn quyết định những việc cần làm tiếp theo dựa trên những gì bạn đã làm cho đến lúc đó (đang hoạt động).
4. Không có chủ sở hữu sản phẩm cũng có thể hoạt động tốt .. Bạn có thể có một số loại hệ thống bỏ phiếu để xếp chồng tồn đọng xếp hạng và chấp nhận / từ chối công việc được thực hiện.
5. Thu thập yêu cầu không phải là một phần của Scrum. Bạn có thể làm điều đó dù sao bạn muốn nó. Nhưng không bao gồm đó là một phần của phạm vi lặp. Có năng lực riêng cho việc đó. Vì vậy, đối với một lần lặp, chỉ lập kế hoạch cho công việc có yêu cầu rõ ràng, ví dụ như nhóm biết các tiêu chí chấp nhận.
6. Hồi tưởng là tốt. Vì vậy, hãy khởi động Scrum như vậy nhưng sau đó sử dụng hồi cứu xem cái gì đang hoạt động và cái gì không, ví dụ bạn có thể cần thay đổi kích thước lặp, bạn có thể cần phải loại bỏ một số tình nguyện viên đang kéo mọi người khác ..
7. Tình trạng hàng ngày là phải. Điều đó mang lại cơ hội để nhóm đồng bộ hóa với nhau, tức là họ sẽ sắp xếp các nỗ lực của mình để không có nhiệm vụ nào bị chặn một cách không cần thiết do không có khả năng giao của thành viên khác.
8. XP là tốt. Có một định nghĩa nghiêm ngặt về việc thực hiện dựa trên XP, ví dụ như không có mã nào được đưa vào trừ khi được xem xét. Làm ít hơn để làm nhiều hơn ..

Tôi có thể đề xuất một cách tiếp cận khác. Vì bạn đang làm việc với các tình nguyện viên, bạn có một vài điều cần xem xét. Nhóm của bạn có thể sẽ có doanh thu cao, cuộc sống sẽ trở nên khó khăn và mọi người sẽ bị phân tâm. Trong số những người còn lại sẽ đóng góp một cách nhất quán nhưng không nhiều lắm, cuối cùng, bạn sẽ có một nhóm khó tính thực sự chìm đắm vào dự án. Tôi đang đưa ra rất nhiều giả định về lực lượng lao động của bạn ở đây và nếu bạn cảm thấy rằng đánh giá của tôi không phản ánh những người bạn đang làm việc thoải mái bỏ qua phần còn lại của điều này.

Bây giờ bạn cần một chiến lược cho phép những người không làm nhiều việc có thể làm việc khá tự chủ, họ chỉ có quá nhiều thời gian để dành cho việc này và bạn không muốn họ dành phần lớn cho việc đó trong giao tiếp. Những người có liên quan nhiều hơn nên có trách nhiệm hội nhập và đưa ra một số ý tưởng phức tạp hơn.

Điều này khiến tôi nghĩ về một quá trình phát triển tập trung hơn vào khung dây và nguyên mẫu.

Bạn có thể có sẵn một nhóm các mục công việc và khuyến khích mọi người viết khung dây cho những mục đó. Bạn có thể sử dụng chúng như Tracer Bullets (thuật ngữ mượn từ lập trình viên thực dụng) để trau dồi ý tưởng và cung cấp nguồn cảm hứng cho mọi người để xây dựng. Từ đó bạn có thể chuyển các ý tưởng thành công thành các nguyên mẫu, một lần nữa đây là những dự án rất nhỏ được thiết kế để giúp mọi người tìm hiểu thêm về các dự án. Sau đó, bây giờ bạn có một phần nhỏ hơn các ý tưởng vững chắc đã được xây dựng bởi vô số người mà bạn có thể giao cho một số nhóm hoạt động hơn một chút và họ có thể làm việc để tích hợp những ý tưởng đó vào hệ thống của bạn.

Tôi nghĩ Kanban sẽ phù hợp hơn cho tình huống này.

Scrum có một vài điều không phù hợp. Các phép đo thời gian hoặc phạm vi là không cần thiết và everoyone phát triển có cùng tầm nhìn sản phẩm từ các cuộc họp. Trách nhiệm và tuân theo một kế hoạch ngắn với tính nhất quán là mục tiêu kinh doanh.

Kanban cung cấp khá nhiều ưu điểm giống như Scrum mà không có nhược điểm. Nó có thể cung cấp cho bạn tạo mẫu nhanh chóng. Các protypes có thể được chạy trước các cuộc họp. Nó cũng cung cấp TDD cho các bài kiểm tra mã và hồi quy có thể thay đổi. Lập trình cặp có thể dễ dàng cho người mới và người không quy định vào cơ sở mã bằng cách chuyển giao kiến ​​thức.

Kanban cũng có những lợi thế độc đáo. Nếu tầm nhìn về những gì người dùng làm được phát triển song song, Kanban hoạt động tốt. Bằng chứng đó là thành công cho các chương trình kinh doanh nhỏ. Ngoài ra, trong những ngày có ít người tình nguyện như ba người, Kanban vẫn hoạt động tốt. Scrum, mặc dù là nhẹ sẽ là quá nhiều băng màu vàng.