Ưu điểm của Scrum cho chính các nhà phát triển? [đóng cửa]

Scrum là một phương pháp quản lý dự án, bạn sẽ 'bán' nó cho các nhà phát triển trong một nhóm hài lòng như thế nào với tình hình hiện tại của nó?

Tôi có thể dễ dàng giải thích với Giám đốc sản phẩm của chúng tôi về cách Scrum sẽ cho phép anh ta nhận được các bản phát hành thường xuyên, sửa đổi các yêu cầu và khiến nhóm tập trung vào các câu chuyện ưu tiên cao trước tiên. Tôi thấy thật dễ dàng để giải thích những gì TDD hoặc Tích hợp liên tục mang lại trong cuộc sống hàng ngày của nhà phát triển.

Nhưng làm thế nào các nhà phát triển có thể bị thuyết phục để nắm lấy Scrum? Scrum sẽ làm cho cuộc sống của họ dễ dàng hơn như thế nào?

Scrum sẽ cung cấp nhiều khả năng hiển thị hơn về những gì đang diễn ra . Quản lý tồi, thay đổi vào phút cuối, áp lực và tất cả các loại công cụ mà nhà phát triển thường phải đối mặt.

Tuy nhiên, nó cũng sẽ mang lại nhiều khả năng hiển thị cho những người trì hoãn, những nhà phát triển đức tin xấu, những người theo chủ nghĩa cá nhân điên rồ, ... nói cách khác, những nhà phát triển tồi.

Scrum là con dao hai lưỡi

Scrum sẽ mang đến cho bạn cơ hội để giải quyết những vấn đề đó. Đó là lý do tại sao nó rất mạnh mẽ.

Chia mục tiêu lớn ("hoàn thành phần mềm") thành những phần nhỏ hơn - những câu chuyện - và quyết định chúng sẽ làm gì trong giai đoạn nước rút hiện tại giúp cải thiện năng suất và giảm căng thẳng. Khi bạn biết cụ thể những gì bạn phải làm bây giờ , sẽ có chút căng thẳng và bạn có thể tập trung vào việc thực hiện phần nhỏ thay vì cảm thấy bị choáng ngợp bởi tổng thể lớn.

Xếp hạng xếp chồng / Backlog giữ cho cột mốc kết thúc không phải là cuộc diễu hành tử thần

Là một nhà phát triển, 'mô hình phá hoại' tôi thấy nhiều nhất trong phát triển phần mềm là khi một số 'bộ điều khiển bên ngoài' (ví dụ: quản lý dự án, quản lý điều hành) rất phấn khích vì thực tế là 'tính năng yêu thích' sẽ không được kích hoạt ' ngày dương lịch 'và ra lệnh diễu hành tử thần.

Scrum, vì nó xếp hạng 'các tính năng quan trọng' cao trong danh sách tồn đọng giúp các nhà phát triển quản lý căng thẳng này một cách chủ động theo hai cách. Đầu tiên, bạn có thể xếp hạng 'tính năng yêu thích' cao trong hồ sơ tồn đọng để anh ấy có thể hạnh phúc nhất. Thứ hai, nó đưa ra một câu trả lời rất trực quan và cụ thể cho "kể từ khi chúng tôi chuyển 'các vật dụng nhấp nháy' lên hạng 1, rất có khả năng chúng tôi sẽ không nhận được 'những chú thỏ' trong lần chạy nước rút này vì bây giờ nó đã xếp hạng 7. bạn có thoải mái với sự đánh đổi này không? "

Tôi cũng thấy rằng với những lần chạy nước rút ngắn, 'bộ điều khiển bên ngoài' sẽ bớt khó chịu hơn về việc trì hoãn công việc. Nếu 'các vật dụng nhấp nháy' không biến nó thành 'cột mốc 1' và 'cột mốc 2' sẽ không kết thúc cho đến 9 tháng kể từ bây giờ, nhà tài trợ của 'vật dụng nhấp nháy' sẽ rất khó chịu. Nhưng nếu 'các vật dụng nhấp nháy' là ngăn xếp xếp hạng 7 thay vì 1 vì thực sự có 6 điều quan trọng hơn phải hoàn thành trước, điều này có nghĩa là chúng ta có thể sẽ đạt được nó trong lần chạy nước rút + 1 hoặc ở giai đoạn nước rút tồi tệ nhất + 2 nó sẽ hiển thị 12 hoặc 18 tuần kể từ bây giờ (sử dụng nước rút 6 tuần). Theo kinh nghiệm của tôi, chờ đợi 3 tháng là 'chấp nhận được' đối với người thiếu kiên nhẫn - bên cạnh đó, trở lại mô hình 'thác nước' của hơn 3 tháng,

Cuối cùng, nếu chúng ta sắp hết thời gian chạy nước rút và mọi thứ mất nhiều thời gian hơn dự kiến, thật tuyệt khi có thể đẩy các mục tồn đọng 5-6-7 sang lần chạy nước rút tiếp theo và đảm bảo chúng ta đã hoàn thành 1-2-3 -4 với chất lượng cao và không có 70 giờ tuần. Sau tất cả, chúng tôi chắc chắn sẽ đạt được 5-6-7 lần chạy nước rút tiếp theo. Một lần nữa, với các khung thời gian ngắn hơn liên quan đến việc hoãn lại, 'bộ điều khiển bên ngoài' thường thoải mái hơn với điều này và không khăng khăng rằng chúng tôi trượt cột mốc hai tuần và yêu cầu bữa tối mỗi đêm 'để vượt qua nó'.

Những người trong nhóm Scrum tự quyết định nhiều thứ: những gì sẽ được thực hiện trong lần chạy nước rút tiếp theo, làm thế nào để chúng ta phá vỡ câu chuyện này trong các nhiệm vụ, những người làm việc trên cái gì, v.v. Điều này trao quyền cho họ, và gần như hoàn toàn trái ngược với vi mô -sự quản lý.

Thực tế là các yêu cầu sẽ thay đổi được tính đến ngay từ đầu. Các nhà phát triển không cần tạo ra các thông số kỹ thuật chi tiết với các ước tính chính xác và sau đó dành hàng tuần để phát triển một tính năng chỉ để nhận ra rằng khách hàng thay đổi suy nghĩ ngay khi nhìn thấy kết quả ...

Đối với tôi, bạn có thể tự giao nhiệm vụ từ backlog là điểm bán hàng lớn nhất theo quan điểm của nhà phát triển. Ngoài ra, sự thân mật với khách hàng / chủ sở hữu sản phẩm giúp hiểu sơ đồ lớn hơn của mọi thứ.

Đôi điều:

• Dựa trên quan điểm của Xavier về các yêu cầu thay đổi ngay từ đầu - bầu không khí chính trị ít phát triển hơn khi mọi người chấp nhận ngay từ đầu rằng một số điều sẽ không như khách hàng mong đợi. Giao hàng nhanh và xem xét sẽ có nghĩa là chi phí truyền thông sai là thấp và thay vì chơi trò chơi đổ lỗi, các nhà phát triển chỉ có thể thay đổi mọi thứ để họ làm việc như khách hàng mong đợi.

• Câu chuyện điểm! Nhà phát triển nào không thích nhận điểm khi làm công cụ !!?! Nghiêm túc mà nói, tốt hơn là lấy huy hiệu trong SC2 hoặc Stack Overflow.

Có một số điều mà tôi là một nhà phát triển thích về scrum.

Các nhà phát triển có xu hướng được cung cấp thêm thông tin trả trước. Chủ sở hữu sản phẩm cần giải thích tất cả các công việc sẽ được thực hiện trong lần chạy nước rút tiếp theo một cách chi tiết để cho phép ước tính tốt.

Chỉ trong thời gian ước tính có nghĩa là ước tính đó là chính xác hợp lý. Mọi người thường có một ý tưởng hợp lý tốt về những gì sẽ được hoàn thành trong một lần chạy nước rút. Điều này cung cấp cho các lập trình viên và người quản lý dự án các công cụ để đẩy lùi các yêu cầu vô lý.

Thật tốt khi lùi lại ba đến bốn tuần một lần và hít một hơi và ít nhất là có một sự thay đổi tốc độ.

Các nhóm tự tổ chức, dường như cho một chút đa dạng hơn trong công việc.

Về lý thuyết ít nhất, trong giai đoạn nước rút, có ít sự gián đoạn và 'trường hợp khẩn cấp' hơn.

Cuộc họp đứng lên hàng ngày buộc các lập trình viên phải nói vài từ mỗi ngày.

Sẽ dễ dàng hơn để thấy tiến trình đang được thực hiện khi các câu chuyện được hoàn thành rõ ràng và được xem xét vào cuối mỗi lần chạy nước rút.

Các biểu đồ ghi xuống là một phương tiện trọng lượng nhẹ khá hiệu quả để theo dõi tiến trình.

Lợi thế cho nhà phát triển là phản hồi sớm (từ khách hàng, người thử nghiệm, chủ sở hữu sản phẩm, v.v.).

Cũng là một nhà phát triển, tôi luôn thích làm mọi thứ từng bước một mà không bị phân tâm. Scrum cung cấp điều này.

PS: scrum không phải là một phương pháp mà nó là một khung.