Scrum có tạo thêm chi phí cho các dự án khi yêu cầu không thay đổi không?

Tôi đang đọc Scrum - Hướng dẫn bỏ túi của Gunther Verheyen và nó nói:

Báo cáo Chaos năm 2011 của Nhóm Standish đánh dấu một bước ngoặt. Nghiên cứu mở rộng đã được thực hiện trong việc so sánh các dự án truyền thống với các dự án sử dụng phương pháp Agile. Báo cáo cho thấy một cách tiếp cận Agile để phát triển phần mềm mang lại hiệu quả cao hơn nhiều, thậm chí trái với những kỳ vọng cũ rằng phần mềm phải được giao đúng thời hạn, theo ngân sách và với tất cả phạm vi đã hứa. Báo cáo cho thấy các dự án Agile đã thành công gấp ba lần và có các dự án Agile thất bại ít hơn ba lần so với các dự án truyền thống.

Vì vậy, tôi đã tranh luận với một trong những đồng nghiệp của mình, người nói rằng đối với một số dự án (như y học / quân sự nơi các yêu cầu không thay đổi), Agile (và đặc biệt là Scrum) là chi phí cho tất cả các cuộc họp, v.v. để sử dụng thác nước, ví dụ.

Quan điểm của tôi là Scrum nên được áp dụng trong các dự án như vậy bởi vì nó sẽ làm cho quy trình trở nên minh bạch hơn và tăng năng suất của một nhóm. Tôi cũng nghĩ rằng các sự kiện Scrum sẽ không mất nhiều thời gian nếu không cần thiết vì chúng ta không cần phải ngồi cả 8 giờ trong Lập kế hoạch Sprint cho nước rút 1 tháng. Chúng tôi có thể dành 5 phút chỉ để chắc chắn rằng tất cả chúng ta đều ở trên cùng một trang và bắt đầu làm việc.

Vì vậy, Scrum sẽ tạo thêm chi phí cho dự án khi yêu cầu không thay đổi?

Tôi tin rằng đó là một giả định sai lầm khi nói rằng có những dự án mà các yêu cầu không thay đổi. Đã làm việc trong cả ngành công nghiệp quốc phòng và ngành sản xuất phần mềm dược phẩm, tôi có thể nói với bạn rằng một khi phần mềm kết thúc trong tay các chuyên gia về chủ đề (cả nội bộ hoặc bên ngoài), đều có phản hồi. Đôi khi, phản hồi này là về cách yêu cầu được thỏa mãn và trong các trường hợp khác, thực tế là bản thân các yêu cầu bị sai hoặc không đầy đủ.

Agility là về việc giảm chu kỳ phản hồi đó và đưa phần mềm hoạt động vào tay ai đó nhanh hơn, nhận phản hồi đó và quyết định bước tiếp theo sẽ là gì để đảm bảo rằng những gì được cung cấp sẽ tăng giá trị khi khách hàng quyết định chấp nhận phần mềm. Ngay cả trong các lĩnh vực như hệ thống nhúng với phần cứng tùy chỉnh (như bạn có thể tìm thấy trong các lĩnh vực như hàng không vũ trụ, ô tô hoặc thiết bị y tế), việc cung cấp các lát mỏng chức năng nhanh chóng để tích hợp và tạo nguyên mẫu có thể giúp đảm bảo rằng hệ thống phần mềm và phần cứng sẽ làm việc như dự định và theo cách sẽ giúp người dùng cuối.

Việc giảm độ dài của chu kỳ phản hồi là một yếu tố rất lớn trong việc giảm rủi ro. Từ góc độ quản lý dự án, nếu bạn tài trợ cho một dự án trong 2-4 tuần và có được tầm nhìn thường xuyên về tiến độ, điều đó đảm bảo với bạn rằng bạn đang đi đúng hướng. Bằng cách có thể cung cấp các lát chức năng mỏng, bạn tăng dần về trạng thái mục tiêu và có thể bắt đầu dự báo khi nào bạn sẽ đến đó. Nếu thời gian trở thành một ràng buộc, bạn có thể bỏ qua các hàm giá trị thấp hơn vì công việc được thực hiện trước tiên phải là hàm giá trị cao hoặc hàm tạo cho hàm giá trị cao. Tại bất kỳ thời điểm nào, bạn có thể quyết định xem có đáng để tiếp tục tài trợ cho nỗ lực đó hay đi theo một hướng khác và dừng dự án trước khi quá muộn.

Câu trả lời rất ngắn gọn là có, Scrum bằng cách thiết kế một cách tiếp cận đắt tiền hơn, nhưng nếu bạn gọi nó là một dự án, điều đó gần như chắc chắn không thành vấn đề và cuối cùng gần như chắc chắn sẽ luôn mang lại ROI tốt hơn.

Câu trả lời đầy đủ hơn là đây:

Nói chung, có ba hình thức kiểm soát quy trình: Kiểm soát quy trình được xác định, Kiểm soát quy trình thống kê và Kiểm soát quy trình. Điều khiển quá trình xác định là rẻ nhất. Điều này là có thể với công việc thường xuyên lặp lại đã được tinh chỉnh theo thời gian để tìm ra cách "tốt nhất" để thực hiện công việc. CI / CD trong phát triển phần mềm thuộc loại này. Bạn không muốn biến thể trong quy trình xây dựng của mình để bạn chuẩn hóa quy trình, điều chỉnh cho đến khi bạn hài lòng với nó, sau đó tự động hóa nó. Quá trình tự động đó rõ ràng là ít tốn kém hơn nhiều so với chiến đấu thủ công thông qua triển khai.

Kiểm soát quá trình thống kê là ít tốn kém nhất tiếp theo, nhưng nó chiếm các biến thể trong một quy trình đã biết. Các thủ tục y tế đi theo kế hoạch thuộc loại này. Tôi không muốn phát minh lại một cuộc phẫu thuật bỏ qua mỗi lần. Tôi làm theo quy trình cơ bản và điều chỉnh cho sự thay đổi. Điều này có tải nhận thức tương đối thấp và tỷ lệ thành công khá cao.

Tiếp theo là Kiểm soát quá trình theo kinh nghiệm, tốn kém nhất vì bạn phải khám phá quy trình khi bạn đi. Học tập là vô cùng cao, nhưng với giá của năng suất và hiệu quả. Tuy nhiên, gần như tất cả các công việc dự án đòi hỏi điều này bởi vì rất ít dự án đã được thực hiện trước đó. Tất nhiên có sự ngoại lệ. Thiết lập một môi trường thư mục hoạt động lớn mang tính Thống kê hơn vì bạn làm việc từ một số hướng dẫn đã thử và đúng mà bạn đi chệch khỏi một chút khi hoàn cảnh yêu cầu. Nhưng trừ khi dự án của bạn là thực hiện công việc chính xác đã được thực hiện trước đó, thì gần như chắc chắn cần phải có Kiểm soát quá trình Emperical.

Để đưa nó trở lại Scrum, Scrum được thiết kế để giải quyết các vấn đề với điều khiển Emperical Process. Do đó, vâng, nó có nhiều chi phí hơn các phương pháp khác. Tuy nhiên, vì hầu hết các dự án đều yêu cầu phương pháp này, đó là một cuộc tranh luận.

Đối với các dự án về y học và quân sự, nó có vẻ như logic thiếu sót. Nếu bạn đang thực hiện một đơn đặt hàng cho 500 máy bay, thì đúng vậy, bạn đang tạo lại một cái gì đó chính xác và Scrum có lẽ không có lợi. Nếu bạn đang chế tạo một chiếc máy bay mới và yêu cầu của bạn không bao giờ thay đổi, tôi sẽ không lái chiếc máy bay đó.

Chắc chắn, nếu bạn có một dự án mà bạn có những yêu cầu rõ ràng ở phía trước, thì bạn có thể bỏ rơi chúng trước các nhà phát triển và quay lại hai năm sau để đáp ứng phần mềm trong mơ của bạn.

Nhưng phần lớn các dự án phần mềm không như thế này.

Thông thường, khách hàng không biết họ cần gì. Họ không thể cung cấp các yêu cầu đầy đủ và cụ thể. Phương pháp lặp lại giúp đỡ ở đây: xây dựng một điều nhỏ, sau đó yêu cầu khách hàng phản hồi. Vâng, điều này "lãng phí" thời gian cho các bản demo và lập kế hoạch cho lần lặp tiếp theo. Nhưng xây dựng điều sai cho một lần chạy nước rút và sau đó nhanh chóng sửa các yêu cầu tốt hơn rất nhiều so với việc xây dựng điều sai cho toàn bộ dự án. Tức là trong khi các yêu cầu lên phía trước có thể cho phép phát triển hiệu quả hơn , các phương pháp lặp sẽ hiệu quả hơn .

Các nhà phát triển phải hiểu chính xác các yêu cầu nếu họ muốn xây dựng phần mềm hữu ích. Một cách tốt để khám phá những hiểu lầm trước khi quá muộn là gì? Một lần nữa, phương pháp lặp có thể giúp đỡ. Nhưng điều quan trọng là các nhà phát triển phải cộng tác với khách hàng thay vì chỉ nhận thông tin được lọc thông qua một tác giả tài liệu yêu cầu.

Cuối cùng, thế giới không đứng yên trong suốt dự án. Hệ thống bên ngoài thay đổi, ưu tiên thay đổi, con người thay đổi. Giả vờ rằng các yêu cầu của một dự án phần mềm sẽ không thay đổi là một ý tưởng tồi, ngoại trừ các dự án ngắn.

Tất cả những lợi ích ở cấp độ quy trình này đều bỏ lỡ lợi thế lớn trong ngày của các phương pháp nhanh: nếu được thực hiện đúng cách, nhanh nhẹn sẽ khiến mọi người hạnh phúc hơn. Một trong những lớn nhất là các kỹ thuật nhanh nhẹn tập trung vào việc cung cấp giá trị thực trong các khung thời gian ngắn. Điều đó mang lại khả năng hiển thị trong quá trình phát triển, mang lại cho các bên liên quan mức độ kiểm soát hợp lý đối với dự án và có động lực hơn nhiều so với làm việc hướng tới một mục tiêu xa vời. Liên quan đến điều này là ý tưởng rằng các đội nhanh nhẹn sẽ chủ yếu tự tổ chức. Cảm giác kiểm soát công việc hàng ngày của họ khiến mọi người cảm thấy có giá trị, và do đó nhiều khả năng sẽ cống hiến hết mình.

Đồng nghiệp của bạn không sai khi các dự án theo phong cách thác nước có thể có vị trí của họ. Và bạn không sai khi một số thực hành nhanh nhẹn có thể là những nghi thức lãng phí thời gian. Nhưng nó hoàn toàn ngu ngốc khi bỏ qua những lợi ích của phương pháp nhanh và lặp, đặc biệt là quản lý rủi ro tốt hơn và tôn trọng cá nhân. Đây là những điều bạn muốn trong mỗi dự án. Nếu cần thiết, một nhóm có thể cố gắng thực hiện một số điều này trong nội bộ, nhưng các quy trình hoạt động tốt hơn khi mọi người đều ở trên tàu.

Tôi nghĩ rằng điều này cũng có thể diễn giải những gì @Cort Ammon đang nói, nhưng đây là ý kiến ​​của tôi:

Các yêu cầu bên ngoài (mô tả "các sản phẩm giao") không phải là các yêu cầu duy nhất trong một dự án. Ngay cả khi các yêu cầu bên ngoài không thay đổi, các yêu cầu "nội bộ" sẽ thay đổi hoặc cần được phép thay đổi khi bạn làm việc. Các nhà phát triển sẽ khám phá những trở ngại hoặc vấn đề với cách tiếp cận và điều này sẽ ảnh hưởng đến công việc của những người khác trong nhóm. Việc đứng lên hàng ngày sẽ giúp mọi người luôn cập nhật những thay đổi nội bộ này.

Xem xét điều đó:

• Ngay cả với các yêu cầu chức năng cố định, bạn cần phải đặt chúng vào các yêu cầu kỹ thuật. Và điều này có thể được thực hiện tốt hơn bởi các lần lặp. Bạn có thể khám phá những cách tốt hơn để giải quyết vấn đề ở giữa dự án.

• Một số yêu cầu có thể quá chung chung hoặc mơ hồ: "dễ sử dụng", "an toàn". Thật khó để phân tích anh ấy bảo mật hoặc khả năng sử dụng của một hệ thống mà nó chưa hoàn thành. Một số có thể có ẩn ý hoặc có thể không được hiểu rõ.

• Một số yêu cầu có thể được cải thiện. Đáp ứng trong 200ms có thể tốt nhưng 100 có thể tốt hơn. Bạn có thể nhắm mục tiêu kết quả tốt nhất có thể nhưng hy sinh nó nếu cần trong suốt dự án.

• Bạn có thể phát hiện ra một số yêu cầu ẩn không được ghi trong hợp đồng nhưng có thể thay đổi dự án từ thất bại thành thành công. Ngay cả khi bạn giao dự án, khách hàng có thể không hài lòng. Có thể họ thậm chí cần thay đổi hợp đồng để thêm (và tính phí) cho các tính năng mới mà bạn có thể thiết kế trong dự án rẻ hơn trong giai đoạn đầu.

• Bạn có thể khám phá ra rằng bạn không thể đáp ứng đầy đủ các yêu cầu của bạn trong thời gian nhất định. Không phải là nếu các dự án phần mềm không bao giờ bị trễ. Vì vậy, việc cung cấp giá trị tốt nhất sẽ cho phép bạn đàm phán lại những tính năng cần bỏ.

• Cung cấp một cái gì đó sớm hơn sẽ giúp tích hợp và sẽ cho thấy rằng dự án này có thể cung cấp kết quả.

Người ta có thể đưa ra lập luận rằng nếu tất cả các yêu cầu được đặt ra một cách hoàn hảo, thì tồn tại một cách tiếp cận từ trên xuống để đạt được các yêu cầu đó càng nhanh càng tốt. Tuy nhiên, nếu đây là những yêu cầu tốt, họ sẽ cho bạn biết phải làm gì chứ không phải làm thế nào. Nếu họ cho bạn biết cách tạo ra nó, tôi sẽ chọn gọi nó là "hướng dẫn công việc" thay vì "yêu cầu" và chúng tôi sẽ thảo luận về một loại vấn đề khác.

Theo đó, luôn có một quá trình phát triển "cách thức" nội bộ cho công ty hoặc nhóm thực hiện các yêu cầu. Nói một cách thực nghiệm, chúng tôi dựa rất nhiều vào cách tiếp cận phân cấp trong đó một nhóm các nhà thiết kế thiết kế hệ thống cấp cao để đáp ứng các yêu cầu đó, và sau đó sử dụng các chi tiết cụ thể của hệ thống cấp cao đó để cung cấp "yêu cầu" cho các nhóm nhỏ hơn để xác định chi tiết của chúng tôi.

Trong quá trình thác nước, điều này có thể được nhìn thấy trong mũi tên một chiều giữa thiết kế và thực hiện. Tuy nhiên, những yêu cầu này không được đặt ra, giống như những yêu cầu của khách hàng. Đây là những định nghĩa bên trong và có chỗ cho quá trình lặp lại. Trong thực tế, chúng tôi thấy các nhà thiết kế hoặc đặt biên độ đáng kể trong quy trình để giải thích cho việc thiếu lặp này hoặc tìm kiếm một quy trình lặp.

SCRUM và nhiều phương thức nhanh khác có liên quan, chỉ cần cung cấp một khung nghiêm ngặt để thực hiện quy trình lặp này. Một nhãn hiệu của các phương pháp nhanh là họ coi việc tối ưu hóa mẫu lặp này là cốt lõi của quy trình, thay vì tập trung vào lớp ngoài của các yêu cầu cứng. Như những người khác đã đề cập, các yêu cầu cố định thực tế rất hiếm, nhưng ngay cả khi có mặt, SCRUM sử dụng phương pháp lặp như một phương pháp để kiểm soát phương pháp hợp đồng mà nó phù hợp với bên trong.

Cho dù nó thành công trong việc này là một vấn đề tranh luận mở. Những người khác đã cung cấp nhiều số liệu cho kết thúc này. Tôi sẽ chỉ lưu ý rằng tùy thuộc vào sức mạnh của lãnh đạo để đảm bảo các lần lặp lại xảy ra bên dưới chúng phù hợp chính xác với hệ thống hợp đồng ở trên. Điều này đúng với bất kỳ cách tiếp cận nào để phát triển, nhưng nó dễ thấy hơn trong các cách tiếp cận nhanh vì chúng tôi đã được nêu ra để cho rằng cách tiếp cận từ trên xuống là "bình thường" và các nhà lãnh đạo được đào tạo như vậy.