Tôi đã được một tổ chức công cộng yêu cầu tổ chức một hội thảo không chính thức về 101 phát triển nhanh để giải thích các thuật ngữ và khái niệm về Scrum, Kanban và những thứ tương tự. Tôi đã làm việc trong môi trường nhanh nhẹn khoảng năm năm nay, nhưng tôi không nghĩ tôi là một nhà truyền giáo Scrum.

Sau hội thảo họ thích ý tưởng. Tuy nhiên, họ giải thích rằng cách tiếp cận có thể sẽ không áp dụng cho họ vì họ cần ủy quyền cho các công ty phần mềm bên ngoài phát triển phần mềm cho họ (họ chỉ có vài nhà phát triển). Hoạt động này cần được thực hiện trong một quy trình đấu thầu công khai mô tả kết quả, giá cả và khung thời gian. Đây là một yêu cầu pháp lý để áp dụng ngân sách cho tổ chức này (một viện nghiên cứu công cộng).

Những ràng buộc này có vẻ hơi mâu thuẫn với các nguyên tắc cơ bản của phát triển nhanh, phải không?

Có phải Scrum không tương thích trong một môi trường như vậy?

Bạn muốn giới thiệu gì cho tổ chức này?

Scrum có lẽ không thích hợp cho tổ chức này.

Từ Hướng dẫn Scrum, "Scrum là một khuôn khổ để phát triển, phân phối và duy trì các sản phẩm phức tạp." Nó cũng được thiết kế cho một nhóm gồm 3-9 thành viên của Nhóm phát triển làm việc về sản phẩm, Chủ sở hữu sản phẩm và Scrum Master (người có thể hoặc không thuộc Nhóm phát triển) với tổng số 4-11 người.

Đối với phát triển nội bộ, bạn đề cập rằng họ chỉ có một vài nhà phát triển. Nếu không có một nhóm đủ lớn để tạo thành Nhóm Scrum, thì việc sử dụng tất cả Scrum là vô nghĩa. Tuy nhiên, một số thực hành Scrum có thể hữu ích cho tổ chức.

Đối với sự phát triển theo hợp đồng, một trong các bên ngoài có thể sử dụng Scrum. Trong trường hợp này, rất hữu ích cho viện nghiên cứu để biết về thực tiễn Scrum và hiểu vai trò cũng như cách thức hoạt động của nó. Họ có thể vẫn cần hiểu chi tiết cụ thể về cách tổ chức phát triển bên ngoài sử dụng các thực tiễn Scrum cũng như các thực tiễn khác, nhưng nó có thể giúp họ hiểu cách thức hoạt động của nó. Ví dụ: hiểu được sự cần thiết phải tham gia vào Đánh giá của Sprint hoặc làm việc với tổ chức (có thể là Chủ sở hữu sản phẩm của họ) khi đặt hàng Sản phẩm tồn đọng.

18F, một cơ quan dịch vụ kỹ thuật số thuộc chính phủ Hoa Kỳ, đã thực hiện rất nhiều công việc về cách chính phủ có thể viết hợp đồng để cho phép sử dụng các phương pháp nhanh theo cách phù hợp với luật pháp, chỉ định kết quả chung thay vì yêu cầu chi tiết về cách thức hoạt động sẽ được thực hiện. Một số tài nguyên của họ bao gồm:

• Cải thiện kết quả của chính phủ thông qua một hình thức hợp đồng nhanh nhẹn
• Hợp đồng mua chăn Agile
• Hợp đồng mô đun (chia các dự án lớn thành các mô đun nhỏ hơn với sự phát triển nhanh)
• Dự án của bạn có sử dụng hay không.

Một lợi thế của phương pháp làm việc nhanh là họ tập trung vào việc khám phá giải pháp cho một vấn đề sau khi hợp đồng được trao, nghĩa là trong quá trình thực hiện sau giải thưởng, thay vì chỉ định giải pháp chi tiết trước như Phần 15. Một hợp đồng nhanh nhẹn cố gắng chỉ định các vấn đề yêu cầu giải pháp chi tiết, thường là các Mục tồn đọng sản phẩm mô tả các khu vực phân phối hợp đồng cấp cao.

Hiểu được vấn đề này, Văn phòng Quản lý và Ngân sách và Văn phòng Chính sách Mua sắm Liên bang đã chỉ đạo các cơ quan ngừng sử dụng SOW và chuyển sang sử dụng Tuyên bố Công việc Hiệu suất (PWS) để có được các dịch vụ. Một PWS nên đưa ra các yêu cầu chung về những gì (kết quả) sẽ được thực hiện, thay vì cách thức (phương pháp) được thực hiện. Các nhân viên hợp đồng tốt khuyên các cơ quan rằng bằng cách mua dịch vụ chuyên gia, điều đó có nghĩa là bạn không hiểu biết nhất trong cách thức làm việc của người Viking được thực hiện. Với tư cách là chủ sở hữu nhiệm vụ, bạn là chuyên gia về những gì, phải hoàn thành, nhưng việc kết hợp cả hai lại khiến nhiệm vụ của bạn gặp rủi ro và khiến hợp đồng cung cấp giá trị khó hơn.

Về cơ bản, cách tiếp cận giống như thuê một nhà cung cấp dịch vụ làm việc với bạn để thiết kế một giải pháp, thay vì liệt kê các trang có thông số kỹ thuật chi tiết trước. Tổ chức sẽ không thuê một kiến ​​trúc sư để thiết kế một tòa nhà mới bằng cách liệt kê ra "thiết kế phải có bốn tầng, với một mái nhà 37 độ. Tầng thứ ba phải có một nhà bếp rộng 237 m2 chứa bốn đèn chiếu sáng huỳnh quang, được điều khiển bởi một chuyển động công tắc đèn nhạy cảm, ở trần thả. " Thay vào đó, họ sẽ có một hợp đồng để kiến ​​trúc sư cung cấp dịch vụ thiết kế với sự tư vấn của khách hàng, và dựa vào nhà cung cấp của họ, một chuyên gia trong lĩnh vực này, để sản xuất các sản phẩm giao kết quả.

Mặc dù các chi tiết sẽ phụ thuộc vào tổ chức và các chính sách và luật mua sắm được áp dụng, nhưng nó cho thấy rằng, trong tất cả các thất bại của các dự án CNTT của chính phủ lớn, có các nhóm làm việc để chuyển các xu hướng công khai để phát triển phần mềm sang các phương pháp nhanh nhẹn hiện đại hơn, đưa ra đủ ý chí chính trị và các đối tác phát triển đáng tin cậy. Nó có một sự thay đổi lớn trong cách các dự án như vậy được hình thành và quản lý (bao gồm rất nhiều thời gian liên tục cung cấp phản hồi của người dùng trong suốt quá trình), mà tổ chức có thể có hoặc không có hứng thú theo đuổi.

Nó có âm thanh điển hình. Khi hồ sơ dự thầu đã được viết, các đề nghị được đưa ra và một trong những ứng cử viên đã được cấp hợp đồng ... theo như các đại diện của tổ chức công cộng có liên quan, dự án đã được thực hiện.

Đây là lý do tại sao rất nhiều các dự án này thất bại. Sau khi họ đi quá ngân sách.

Điểm họ thiếu (hoặc ít nhất là không cảm thấy bất kỳ mối quan tâm nào của họ) là họ là các bên liên quan nên tham dự các cuộc họp và bản demo.

Vì vậy, không có xung đột với Agile hoặc Scrum. Đó là mọi người không chọn vai trò của họ. Đó là cách chính phủ làm việc gây ra điều này.

Nó không giống như "chúng tôi muốn có hệ thống này và chúng tôi sẵn sàng nỗ lực trong đó và xem chúng tôi có thể đi được bao xa".

Không. Giống như "nền dân chủ của chúng ta đã quyết định chúng ta S have có hệ thống này, sau đó". Không có chỗ giữa thành công 100% một mặt và mặt khác 100% thất bại. Doom từ đầu.

Nó cũng là một lời mời đến thị trường để yêu cầu tỷ lệ vô lý. Không làm dự án vì nó quá đắt không phải là một lựa chọn, quyết định thực hiện nó đã được đưa ra trước khi đấu thầu được viết.

Đủ công bằng, ngay cả khi các bên liên quan sẽ nhận vai trò của họ, họ sẽ hoàn toàn bất lực. Không ai trong số họ sẽ có một cây gậy đáng tin cậy để đưa đến những bản demo đó vì lý do tương tự.

Không, SCRUM không tương thích với đấu thầu công khai. Bạn cần nói rõ những gì bạn đang mua trong một cuộc đấu thầu công khai.

"Người mua đang tìm cách mua 10 lần chạy nước rút trong 2 tuần, từ một nhóm SCRUM có kinh nghiệm chứa 5 nhà phát triển và một bậc thầy SCRUM được chứng nhận (người mua sẽ điền vào vai trò của SH). Sprints sẽ hoạt động từ tháng 3 năm 2018 đến tháng 7 năm 2018" bắt đầu đấu thầu. Tất nhiên, bạn sẽ cần liệt kê các kỹ năng cần thiết của nhóm và đưa ra ý tưởng về dự án mà họ sẽ thực hiện, nhưng việc đấu thầu để thuê một nhóm là hoàn toàn chấp nhận được.

Tất nhiên, bạn đang từ bỏ "phạm vi cố định" ở đây. Đó là điển hình cho SCRUM, sau tất cả. Với một chút từ ngữ trong đấu thầu (nhưng chúng tôi đang ở trong lãnh thổ hợp pháp ở đây), bạn có thể cho phép mở rộng phạm vi nhỏ, tức là một số lượng nhỏ nước rút bổ sung. Nhưng nếu bạn quyết định bạn muốn có thêm 10 lần chạy nước rút sau 10 lần chạy nước rút ban đầu, có lẽ bạn sẽ cần đấu thầu lại.

Thật khó

Bạn rõ ràng không thể đấu thầu công việc với ngân sách kết thúc mở. Vì vậy, bạn phải xem xét những gì sẽ cần phải được thực hiện và cần bao nhiêu nỗ lực để làm điều này.

Bây giờ lý do mà nhiều dự án phần mềm thất bại là do việc sửa chữa, thời gian, công sức và phạm vi lên phía trước rất dễ bị lỗi. Ví dụ, một đặc điểm kỹ thuật như được đưa ra trong đấu thầu hầu như sẽ luôn có một sự mơ hồ.

Vì vậy, có một vấn đề cơ bản không chỉ với nhanh nhẹn, mà với khái niệm đấu thầu mở để phát triển phần mềm. Cơ hội để ai đó ra đi và tạo ra chính xác những gì bạn muốn, trong thời gian bạn chỉ định, là thấp.

Nếu bạn cho phép một số linh hoạt, bạn có thể cải thiện điều này.

Nghe có vẻ như quá trình đưa công việc ra đấu thầu công khai không linh hoạt. Tuy nhiên, một khi hợp đồng giành được, bạn có thể thấy có phòng luồn lách. Ví dụ, bạn có thể cho phép làm việc nhanh nhẹn nhưng bạn sẽ phải chấp nhận (và nhận được giải phóng mặt bằng pháp lý) rằng điều này có thể ảnh hưởng đến phạm vi.

Bây giờ tôi tin rằng điều này sẽ dẫn đến một sản phẩm tốt hơn vì bạn sẽ thấy những gì đang xảy ra sớm và thay đổi trước khi chúng được đưa vào sản phẩm. Các vòng phản hồi chặt chẽ và phát triển lặp có thể làm cho các sản phẩm phù hợp hơn với các yêu cầu thực tế (có thể hoặc không thể là những gì được đưa ra đấu thầu).

Nó phụ thuộc, nhưng có lẽ là có.

Tôi sẵn sàng đặt cược tiền mà mọi người từng làm việc với bất kỳ chính phủ nào trong bất kỳ dự án nào liên quan đến CNTT sẽ biết rằng trên thực tế, 'giới hạn cứng' được mô tả trong hồ sơ dự thầu không bao giờ được đáp ứng. Mọi thứ có xu hướng vượt quá ngân sách, bị trì hoãn và / hoặc phạm vi được thay đổi. Thường là nhiều trong số đó. Nếu các chính phủ sẵn sàng thừa nhận rằng đây là sự thật và sẵn sàng đối xử với họ như hướng dẫn của họ, thì scrum có thể hoạt động thực sự tốt.

Từ kinh nghiệm cá nhân (cả của tôi và trong mạng lưới chuyên nghiệp của tôi) tôi biết rằng các yêu cầu thay đổi thường xuyên trong phần lớn các dự án của chính phủ. Các ủy ban có trách nhiệm cũng có xu hướng có nhiều phản hồi khi cuối cùng họ tham gia vào cuối dự án. Đây là những vấn đề mà Scrum rất phù hợp.

Tuy nhiên, điều này sẽ đòi hỏi một sự thay đổi cơ bản trong tư duy về phía chính phủ và các cơ quan của họ. Ở hầu hết các quốc gia, rất khó có thể thay đổi này sẽ diễn ra. Cho đến thời điểm đó, đấu thầu công khai sẽ tiếp tục không tương thích với làm việc với Scrum. (Đối với vấn đề đó, theo quan điểm cá nhân của tôi, đấu thầu công khai sẽ tiếp tục không tương thích với bất kỳ thực tiễn phát triển phần mềm bền vững nào , nhưng đó là vấn đề khác trong một thời điểm khác ...)

Bạn muốn giới thiệu gì cho tổ chức này?

Tại thời điểm này không có gì.

Điều còn thiếu ở đây là câu chuyện về những vấn đề mà quá trình hiện tại của họ đang gây ra cho họ. Scrum không phải là thứ để giới thiệu một cách mù quáng. Nó có một điểm. Nó không phải là một kích thước phù hợp với tất cả.

Hỏi họ những vấn đề mà quá trình hiện tại của họ đã gây ra cho họ. Nghe. Chỉ đề xuất phương pháp giải quyết các vấn đề thực sự của họ. Họ sẽ được thiên vị cho quá trình hiện tại của họ. Tinder có vẻ như họ ra lệnh cho một quá trình phát triển nhưng họ thì không. Họ ra lệnh cho một quá trình giao hàng. Nhưng đó là một sự khác biệt mà nhóm này có thể chưa bao giờ phải thực hiện trước đây.

Agile hoạt động tốt nhất khi các yêu cầu thay đổi hơn 3% trong vòng đời của dự án. Nếu không thì thác vẫn rất hiệu quả. Nó vẫn còn được sử dụng ở nhiều nơi ngày nay. Và tất nhiên, nhiều nhà phát triển thành công không bao giờ chính thức hóa quy trình của họ. Không chính thức hoạt động tốt khi các vấn đề khó khăn là kỹ thuật, không phải về người dân.

Vì vậy, nói chuyện với họ về quá trình hiện tại của họ và những vấn đề nó có. Nói với họ về những gì các phương pháp này giúp với. Nhưng nếu nó không bị hỏng thì đừng sửa nó.