Làm cách nào để Scrum hoạt động cho một nhóm có vai trò xác định?

Một số thông tin cơ bản

Tôi là thành viên của nhóm phát triển phần mềm nội bộ. Nó bao gồm

• 5 nhà phát triển (có kinh nghiệm từ 2 đến 5 năm, tôi là một trong số họ)
• 3 nhân viên triển khai (họ thực hiện triển khai và đào tạo phần mềm)
• và 1 quản lý dự án.

Chúng tôi phát triển nhiều dự án vừa và nhỏ, và các mốc thời gian của chúng thường chồng chéo lên nhau. Sự phát triển diễn ra như sau:

1. "Khách hàng" cung cấp cho chúng tôi một loạt các yêu cầu ban đầu
2. Chúng tôi phát triển hệ thống để nói đặc điểm kỹ thuật
3. Hiện tại hệ thống cho "khách hàng"
4. "Khách hàng" cung cấp cho chúng tôi các yêu cầu bổ sung dựa trên bản trình bày đã nói
5. Lặp lại 2-4 cho đến khi "máy khách" hết yêu cầu mới hoặc ngày mục tiêu triển khai đã hết
6. Thiết lập và triển khai hệ thống

Điều này, cùng với thực tế là "khách hàng" xử lý thời hạn hầu hết thời gian (là cờ đỏ, từ những gì tôi thấy ở đây trong Lập trình viên và PM.SE) và chúng tôi không tuân theo một phương pháp phát triển nhất định đến mã hóa cao bồi, mã đêm không thể nhầm lẫn và các lỗi xảy ra trong quá trình sản xuất, trong số những thứ khác. Đó là lý do tại sao chúng tôi chọn áp dụng phương pháp dựa trên Agile như Scrum.

Tại sao Scrum?

Đó là sáng kiến ​​của người quản lý của chúng tôi và mọi người dường như đồng ý với nó, với tình hình hiện tại của chúng tôi.

Vấn đề với Scrum

Một số yếu tố của Scrum có xung đột với thiết lập hiện tại của chúng tôi mà chúng tôi không thể dễ dàng giải quyết, đặc biệt là bản chất "jack-of-all-giao dịch" của các nhà phát triển Agile. Nhóm triển khai không biết cách lập trình và các nhà phát triển có các kỹ năng giao tiếp và đào tạo dưới mức trung bình. Và đội hình này sẽ không thực sự thay đổi bất cứ lúc nào sớm.

Câu hỏi

Nó sẽ ảnh hưởng đến hiệu quả của Scrum như một phương pháp? Những thay đổi khác cần phải được thực hiện để bù đắp? Hay sẽ tốt hơn nếu từ bỏ suy nghĩ hoàn toàn và suy nghĩ về một phương pháp khác?

Trên thực tế, cách làm việc hiện tại của bạn không bị loại bỏ khỏi Scrum như bạn nghĩ.

Trong Scrum, bạn cũng nhận được một bộ yêu cầu ban đầu, thực hiện những yêu cầu đó và chứng minh kết quả, và dựa trên trình diễn, các yêu cầu mới có thể được cung cấp cho bạn hoặc các bên liên quan có thể quyết định rằng sản phẩm đủ tốt để không cần phát triển thêm.
Trong tình huống của bạn, "khách hàng" mà bạn đã nói đến có thể được giao vai trò Chủ sở hữu sản phẩm trong Scrum (họ dường như đã hoàn thành vai trò đó bằng cách đặt các ưu tiên trong một dự án và quyết định khi nào nó sẵn sàng được triển khai).
Một thay đổi lớn có thể là độ dài của một lần lặp. Trong Scrum, một lần lặp sẽ kéo dài ở đâu đó trong khoảng từ 1 đến 4 tuần.

Đối với thành phần nhóm và ngụy biện jack-of-all-giao dịch: Scrum không yêu cầu tất cả mọi người phải là một jack-of-all-giao dịch. Scrum chỉ yêu cầu toàn bộ nhóm có tất cả các năng lực cần thiết để đưa sản phẩm từ danh sách các yêu cầu đến một thứ gì đó đã / có thể được triển khai.
Trong tình huống của bạn, tôi có thể dễ dàng thấy một nhóm cho mỗi dự án bao gồm một hoặc nhiều nhà phát triển (chủ yếu thực hiện công việc triển khai và thử nghiệm) và một thành viên của "nhân viên triển khai", người tập trung chủ yếu vào việc tạo hướng dẫn và tài liệu đào tạo cho các tính năng mà Các nhà phát triển hiện đang thực hiện.

Sau khi khách hàng / Chủ sở hữu sản phẩm bật đèn xanh để triển khai, công việc cho nhóm scrum sẽ được thực hiện hầu hết, vì vậy các nhà phát triển có thể đi đến một dự án khác (và chỉ có sẵn theo yêu cầu để khắc phục các sự cố sau triển khai) và việc triển khai nhân viên có thể chuyển sang thực hiện đào tạo và hỗ trợ triển khai.

Thực tế là có thời hạn không phải là một vấn đề thực sự, miễn là có đủ sự linh hoạt trong chức năng cần có trong bản phát hành đó.

Bạn yêu cầu các lựa chọn thay thế vì vậy tôi sẽ nói Lập trình eXtreme (XP). Cụ thể tôi nghĩ rằng lập trình cặp có thể giúp bạn ở đây.

Bằng cách ghép những người có các kỹ năng khác nhau lại với nhau, không có vấn đề gì về kỹ năng: pha cà phê, thử nghiệm, đào tạo, v.v. bạn có thể truyền bá các kỹ năng xung quanh nhóm.

Nhưng thành thật mà nói, nó không có vẻ như SCRUM là quá xa đối với bạn. Một phần của SCRUM là linh hoạt và tìm kiếm những gì tốt nhất cho nhóm của bạn. Một phần của XP là tôn trọng nhóm của bạn và thích nghi. Có thể trong 100 năm nữa chúng ta có thể có một nghề phát triển đầy đủ hơn với các quy tắc cứng và nhanh (mặc dù tôi nghi ngờ điều đó) nhưng bây giờ, làm những gì hiệu quả cho bạn là tất cả những gì chúng ta có. Điều quan trọng là có các vòng phản hồi. Nếu một cái gì đó không hoạt động, sau đó nhóm cần thảo luận về điều đó và thử những điều mới cho đến khi họ tìm thấy một cái gì đó hoạt động.

Làm cách nào để Scrum hoạt động cho một nhóm có vai trò xác định?

Cứ làm đi. Theo hướng dẫn scrum mọi người đều là nhà phát triển nhưng trở lại đây trên hành tinh trái đất, những người khác nhau sẽ mang những thứ khác nhau lên bàn. Tôi gần như bị thất vọng khi tôi đề nghị một số người thực sự là người thử nghiệm trong khi những người khác viết phần mềm.

Một số điều bạn có thể muốn giải quyết:

Nước rút

Có vẻ như bạn có một giai đoạn phát triển ban đầu theo sau là một loạt các lần chạy nước rút. Hãy xem xét việc phá vỡ điều này. Không chỉ khách hàng sẽ nhìn thấy một cái gì đó sớm, bạn sẽ có cảm giác tốt hơn cho các mốc phát triển khi chúng xảy ra.

Thời hạn đã sửa

Điều này mọc lên hết lần này đến lần khác và thực sự là một cái gai dai dẳng ở phía các nhà phát triển nơi tôi hiện đang làm việc. Scrum đặt ước tính cho lần chạy nước rút - không có gì hơn. Có, bạn có thể đạt được mục tiêu sau một loạt các lần chạy nước rút nhưng một khi khách hàng đã để mắt đến các phiên bản đầu tiên thì phạm vi có thể sẽ tăng lên đáng kể. Bản thân đây không phải là vấn đề, nhưng khách hàng nên được biết rằng công việc tiếp theo sẽ diễn ra trong những lần chạy nước rút sau và vượt qua các yêu cầu đã biết.

Tình huống của bạn có thể phù hợp hơn với Kanban, vì bạn có thể bắt đầu với bạn có và lặp lại từ đó. Điều này có nghĩa là bạn sẽ không có phần giới thiệu lớn gây gián đoạn cho các dự án hiện tại của bạn - chỉ cần bắt đầu bằng cách hình dung các nhiệm vụ trên bảng và áp dụng một số thực tiễn như hồi tưởng và họp hàng ngày.

Bạn phải cẩn thận hơn một chút so với Scrum vì nó không quá nguyên tắc: vì vậy nó có xu hướng quay trở lại bất cứ điều gì đã đi trước thay vì khắc sâu một tư duy nhanh nhẹn đúng đắn.

Scrum không hoạt động tốt với các dự án riêng biệt chồng chéo, vì bạn không có một nhóm người ổn định làm việc trong một dự án để chạy nước rút hoàn chỉnh. Do đó các khái niệm như tính dài dòng vv có thể chỉ làm bạn chán nản.

Nhưng trước tiên, lấy câu chuyện mang lại chi phí / lợi ích tốt nhất cho khách hàng và thực hiện nó bao gồm thử nghiệm hoàn toàn tự động, với chất lượng đủ tốt để triển khai, trước khi thực hiện câu chuyện tiếp theo là một khái niệm hữu ích. Tương tự như vậy, yêu cầu tất cả các mã được viết cho một câu chuyện phải được xem xét bởi một nhà phát triển khác trước khi câu chuyện được coi là đã thực hiện.

Tôi giả sử nhân viên thực hiện của bạn phải viết tài liệu đào tạo và tài liệu tham khảo, chúng có thể được viết (bản nháp đầu tiên) cho mỗi câu chuyện trước khi mã được viết, do đó trở thành các bài kiểm tra chấp nhận.

Tôi hy vọng bạn sẽ thấy rằng khi bắt đầu mỗi dự án, nơi đầu vào của nhân viên triển khai sẽ giúp ích nhiều nhất cho các nhà phát triển, họ cam kết 100% cho việc triển khai dự án trước đó. Do đó, hãy xem xét nếu nhân viên triển khai có thể làm việc để viết các câu chuyện và tài liệu người dùng cho dự án tiếp theo, trong khi các nhà phát triển đang viết mã cho dự án hiện tại.

Hành vi hướng đến sự phát triển của thành phố với các nhân viên triển khai viết ví dụ được sử dụng trong các bài kiểm tra có thể hoạt động.

Vì vậy, có một chút Scrum sẽ giúp bạn, nhưng hãy cố gắng dựa vào Scrum thay vì sử dụng Scrum.