Bạn đã ký hợp đồng với dự án Agile bằng cách nào? (không phải cách bạn nghĩ bạn sẽ làm như thế nào, bạn đã làm thế nào)

Question

Để thực hiện dự án Agile trước tiên bạn cần một hợp đồng. Không có hợp đồng - không có dự án! Không có dự án - không có Agile, SCRUM hoặc bất cứ điều gì!

Hợp đồng, nếu chúng ta đang nói về các dự án từ trung đến lớn, phải có các yếu tố kích hoạt an toàn được xác định rõ. I E. khách hàng muốn chắc chắn rằng nếu chúng tôi đồng ý kết thúc dự án theo thời gian = T, ngân sách = B và phạm vi = S, chúng tôi không kết thúc với thời gian = T × 2, ngân sách = B × 3 hoặc phạm vi = S/2.

Mặt khác, với tư cách là một công ty cung cấp sản phẩm, không muốn dự án kết thúc bất ngờ. I E. nếu sau khi một số khách hàng lặp lại nói "Bây giờ tôi thấy rằng đây thực sự là tất cả những gì chúng tôi cần. Chúng tôi dừng lại ngay bây giờ." và dự án được lên kế hoạch thêm 2 tháng nữa, hơn là chúng tôi có những người không có kế hoạch làm việc. Nếu 3-6 người không phải là vấn đề lớn, 15–25 có thể là một vấn đề thực sự!

Tuy nhiên, tôi không tìm thấy bất kỳ ví dụ thực tế nào về hợp đồng có tính năng an toàn trong đó cho phép dự án được thực thi theo cách đầy đủ Agile (đã nêu hoặc không được nêu với khách hàng như vậy). Tiêu chuẩn nói rằng tôi tìm thấy trên nhiều diễn đàn - nói chuyện với khách hàng, giải thích cho anh ta rằng đây là cách hiệu quả hơn nhiều về công việc vv không thuyết phục cả tôi và quản lý của tôi. Không phải là chúng tôi không tin vào Agile thực sự là một cách tốt hơn để làm điều đó. Nó chỉ là khoảng trống trong gây nên an toàn là rất rõ ràng rằng không có khách hàng của chúng tôi mua nó và chúng tôi không thích chúng (khoảng trống, không phải khách hàng;)) hoặc.

XIN VUI LÒNG không "nó có thể hoạt động theo cách này ..." - Tôi đã đọc hàng tấn điều đó. Chỉ quan tâm đến "Đối với chúng tôi, nó hoạt động theo cách này". Không có nghi ngờ, bỏ qua tất cả các thông tin tự tin trong đó.

P.S. Theo như tôi có thể nói, cách tiếp cận tiêu chuẩn, tính năng theo tiêu chuẩn cho thấy khách hàng thanh toán sau mỗi lần lặp (số lần lặp) và có thể ngăn dự án cả khách hàng và người thực hiện dự án sau bất kỳ lần lặp nào mà không nói nhiều về hậu quả, thay vì nói "nó sẽ thất bại anyway, vì vậy trước đó - tốt hơn" (đó là chính xác, nhưng không phải là rất hữu ích khi ký hợp đồng).

Answer 1

Tôi làm việc trong chính phủ.

Gần đây, chúng tôi đã chạy quy trình mua sắm phát triển phần mềm và chọn ba nhà cung cấp để làm việc trên một dự án Agile. Một số lưu ý:

1. Chúng tôi đã 75% chắc chắn chúng tôi muốn chạy một dự án Agile vì chúng tôi biết yêu cầu của chúng tôi đã mơ hồ và bởi vì nó là một dự án web công cộng phải đối mặt với một yếu tố thiết kế đáng kể. Vì vậy, tôi muốn nói rằng nó sẽ giúp rất nhiều nếu khách hàng của bạn biết về Agile và mua ngay từ đầu, ngay cả khi họ không thực sự thực hành nó trong nhà. Lưu ý rằng việc chấp nhận Agile đang gia tăng trong một số vòng tròn của chính phủ, vì vậy điều này có thể dễ dàng hơn.

2. Một biện pháp bảo vệ mà chúng tôi đã sử dụng là ký hợp đồng với SCRUM (rất độc lập) để làm việc cho chúng tôi và xử lý các nhiệm vụ quản lý dự án phần mềm thay mặt cho đội ngũ kiến ​​trúc/kiến ​​trúc sư/khả năng sử dụng của chúng tôi. Chúng tôi đã dành rất nhiều thời gian để tìm người này và chọn họ từ ba ứng viên tuyệt vời. Đây là tốn kém nhưng đáng giá.

3. Khi chúng tôi đã chọn nhà cung cấp và đồng ý rộng rãi vai trò của mình (thiết kế, front-end, back-end), chúng tôi tập hợp lại một cách nhanh chóng để phác thảo ý định của chúng tôi. của nhóm từ mỗi nhà cung cấp, cam kết có một hợp đồng đầy đủ được ký vào cuối tháng và thời gian thỏa thuận & tài liệu trong thời gian đó.

4. Sau đó, chúng tôi đã bắt đầu với một phiên kế hoạch/định cỡ kỹ thuật và nhận được khía cạnh đó. Không có công việc hay thiết kế nào đã được thực hiện trong thời gian này, nhưng chúng tôi đã thực hiện rất nhiều kích thước và ước tính mức cao.

5. Đến cuối tháng, chúng tôi sẽ ký hợp đồng cho từng nhà cung cấp (một đã trễ, nhưng điều đó là ok). Một nhà cung cấp đưa ra các hợp đồng mẫu mà chúng tôi có thể sử dụng, một hợp đồng dựa trên thanh toán bằng phần ba của dự án; khác khi hoàn thành chạy nước rút. Tôi nghĩ cuối cùng, chúng tôi đã hoàn thành chạy nước rút (lập hoá đơn hàng tháng), sử dụng một số ngôn ngữ do nhà cung cấp đề xuất trong phần thanh toán của mẫu hợp đồng tiêu chuẩn của chúng tôi.

Nhìn chung, chúng tôi chấp nhận phương pháp này (mặc dù thừa nhận rủi ro) vì chúng tôi cho rằng không có nhiều rủi ro kỹ thuật thực tế trong dự án và vì chúng tôi rất tự tin vào quy trình mua sắm và trong các nhà cung cấp mà chúng tôi đã chọn.

Cuối cùng, đây là một dự án rất thành công, và chúng tôi đã bắt đầu sử dụng SCRUM trong nhà cho các dự án khác. Tôi nghĩ rằng có một đội ngũ tuyệt vời là chìa khóa. Chúng tôi tin tưởng vào các nhà cung cấp - không chỉ là họ có thể thực hiện công việc mà còn phù hợp với thái độ của họ khi làm việc như một nhóm và về vai trò được xác định rõ ràng cho mỗi nhóm (nghĩa là họ sẽ không cạnh tranh với cùng một số tiền).

Nếu nhà cung cấp của chúng tôi không được tốt, chúng tôi sẽ có thêm một số đặt phòng về hợp đồng như thế này, nhưng việc mua sắm gần như là một nghệ thuật như khoa học, và chúng tôi biết chúng tôi đã chọn nhóm phù hợp nhất với thái độ của một nhóm người trả lời chất lượng cao khác.

Kể từ đó, chúng tôi đã thực hiện cả ba hợp đồng cho năm thứ hai phát triển, mặc dù tôi cho rằng nó sẽ không diễn ra suôn sẻ trong thời gian này (thành phần nhóm SCRUM mới). tham gia.

Bạn cũng có thể thấy điều này thú vị: Outsourcing Agile.

Answer 2

Vì tôi làm việc chủ yếu trên các ứng dụng mạng nội bộ, điều này không quá khó khăn với tôi. Tuy nhiên, tôi thường làm các ứng dụng cho các phòng ban khác và đôi khi, đặc biệt khi dự án lớn, chúng tôi ký biên bản ghi nhớ (MOU) liên quan đến phạm vi dự án, thời gian dự kiến ​​và chi phí. Vì tôi làm việc một cách nhanh nhẹn, không có thứ gì trong số đó được sửa chữa, thường khó giải thích cho các phòng ban khác chưa từng làm việc theo cách này trước đây. Thông thường tôi sẽ bao gồm một mô tả về quy trình - một vài đoạn văn - giải thích cách dự án là một liên doanh hợp tác giữa chúng và tôi, cùng nhau chúng ta xác định khi nào chúng ta hoàn thành.

Vào thời điểm MOU thực sự được viết, tôi đã đầu tư một số giờ trong dự án phát hiện yêu cầu là gì (chúng được xử lý theo tốc độ theo giờ chuẩn). Dựa trên kết hợp với ước tính tốc độ và sự tương đồng của các dự án trước, tôi đưa ra ước tính rộng về lượng thời gian và chi phí cho các tính năng cần thiết - một lần nữa giải thích, rằng chi phí thực được xác định bởi các tính năng mà chúng tôi thực sự triển khai bao lâu nó thực sự mất. Điều này có một số lượng tin cậy hợp lý, nhưng vì chúng tôi đã làm việc cùng nhau để phát triển các yêu cầu tôi thường có với các cá nhân mà tôi đang xử lý trực tiếp. Tôi thường cố gắng để lại ước tính thực tế của MOU, nhưng sẽ bao gồm nó nếu người quản lý của họ nhấn mạnh. Tôi cố gắng cung cấp cho họ một số ngân sách.

Trải nghiệm của tôi là khi dự án bắt đầu và bạn bắt đầu phân phối giá trị cho khách hàng, họ hiếm khi không hài lòng. Thông thường, họ yêu cầu (và trả tiền) nhiều hơn phạm vi dự án ban đầu. Thông thường, cả hai chúng tôi đều đồng ý rằng một số tính năng ban đầu không bắt buộc, nhưng tôi luôn mong đợi điều đó.Sau khi tất cả, họ thực sự không có cách nào để biết chắc chắn cho đến khi họ thực sự nhìn thấy mọi thứ trong hoạt động những gì nó là họ thực sự cần. Thường xuyên hơn không, chúng tôi thả một số tính năng và thêm các tính năng khác dựa trên sự phát triển thực tế. Tôi cho rằng nếu chúng tôi không ở đó sẽ không có bất kỳ điểm nào để sử dụng các phương pháp nhanh nhẹn.

Tôi nghĩ vấn đề chính là sự tin tưởng. Tôi muốn đề nghị làm việc với một khách hàng mới về các dự án nhỏ hơn hoặc phá vỡ một dự án lớn thành các dự án nhỏ hơn để phát triển lòng tin. Một khi họ và bạn biết rằng bạn có thể tin tưởng lẫn nhau để xây dựng đúng sản phẩm với các tính năng phù hợp, tôi nghĩ rủi ro - và luôn luôn có một - của khách hàng rút ra đột ngột được giảm thiểu.

Answer 3

Thực tiễn PM của chúng tôi vẫn bắt kịp cách tiếp cận nhanh nhẹn của phần mềm phân phối. Hầu hết thời gian, sai lầm về mặt thận trọng, hợp đồng ban đầu xác định các mục tiêu cấp cao nhưng gắn các ràng buộc về chức năng với các thách thức kỹ thuật có thể dự đoán trước được. Một số mốc giao hàng chính, tức là alpha, beta, final, được định nghĩa và định giá. Phạm vi bổ sung được định nghĩa là yêu cầu thay đổi bổ sung hợp đồng gốc. Đó là một trải nghiệm học tập khi chúng tôi rời khỏi các phương pháp thác nước truyền thống; vấn đề lớn nhất tôi đã thấy là một số thứ như triển khai thường xuyên rất khó để định giá bởi vì bạn không bao giờ biết bao nhiêu thời gian giải quyết "phản hồi" từ một lần lặp lại sẽ mất. Chúng tôi đã có "điều này là tuyệt vời, chúng tôi đang di chuyển cùng tốt!" và chúng tôi đã có "đây là danh sách 200 lỗi"; có một mức độ hiểu biết khác nhau về mục đích phát hành thường xuyên là giữa các khách hàng.

Answer 4

Các dự án nhanh nhẹn duy nhất mà tôi từng làm là các dự án Trong nhà, Thời gian và Vật liệu (T & M) hoặc Trả tiền theo chu kỳ.

Vấn đề là, như bạn đã chỉ ra, rằng có nguy cơ một dự án bị lỗi/kết thúc sớm. Tuy nhiên, không phải là giống như bất kỳ dự án? Nếu bạn đi T & M bạn có tất cả các rủi ro, nếu bạn đi Giá cố định, khách hàng sẽ chịu mọi rủi ro. Bằng cách sử dụng Pay Per Cycle, bạn sẽ tận dụng tối đa rủi ro, nhưng sẽ chuyển từng phần nhỏ vào chu kỳ khách hàng một lần. Vì điều đó xảy ra, cả bạn và khách hàng đều không chịu bất kỳ rủi ro nào, đó là lý do tại sao bạn đã đăng câu hỏi này.

Rắc rối đang nhận rủi ro là những gì doanh nghiệp là tất cả về, càng có nhiều rủi ro bạn có lợi nhuận lớn hơn khi nó đi ra, nhưng cũng lớn hơn sự mất mát nếu nó không. Nếu rủi ro quá lớn đối với bạn để xử lý giải pháp duy nhất là tìm người khác có thể mạo hiểm khỏi tay bạn, nhưng bạn sẽ phải trả tiền cho họ. Nếu cả bạn và khách hàng đều không chuẩn bị để nhận nó thì có thể chỉ có hai câu trả lời:

1. Kiếm một số kẻ lừa giàu để bảo hiểm rủi ro (nghĩa là nhận bảo hiểm).
2. Lây lan rủi ro cho một số người cho đến khi rủi ro mà mỗi người nhận được là quá nhỏ đến mức có thể chấp nhận được.

Tôi nghĩ tùy chọn thứ hai này là điều làm cho Contactors trở nên phổ biến. Bởi vì họ rất dễ dàng để thoát khỏi, họ kết thúc với nguy cơ chấm dứt dự án sớm. Vì rủi ro sẽ lan truyền giữa một số người, nguy cơ sẽ lan đến mức chấp nhận được. Họ sẽ tính phí bạn nhiều hơn một nhân viên vì có thêm rủi ro, nhưng đó là những gì bạn nhận được để cố gắng tránh rủi ro cho mình.

Answer 5

Hợp đồng của chúng tôi đã không thay đổi kể từ khi chúng tôi chuyển sang nhanh nhẹn, khách hàng vẫn muốn nhận xây dựng tại mốc quan trọng và quá xa để được tham gia trực tiếp vào mỗi lần chạy nước rút. Chủ sở hữu sản phẩm không phải là người ở đầu kia của hợp đồng, nó có thể là người quản lý điều hành. Chủ sở hữu sản phẩm liên lạc thường xuyên với nhu cầu của khách hàng thực, anh ta đánh giá nhu cầu hiển thị nó cho khách hàng. Tuy nhiên, người đó sẽ dễ dàng hơn nhiều trong việc liên lạc với khách hàng nếu anh ấy phát hành thường xuyên.

Answer 6

Điều cuối cùng bạn muốn trong một dự án nhanh là phạm vi cố định (thường là những gì được chứa trong hợp đồng trong dự án thác nước truyền thống). Những gì bạn muốn là một thỏa thuận với một lịch trình cố định với một nhóm kích thước cố định làm việc chống lại một tồn đọng sản phẩm ưu tiên.

Nếu bạn buộc đối tác kinh doanh xác định phạm vi cố định trong khi bắt đầu, họ sẽ làm mọi thứ họ có thể nghĩ đến trong hợp đồng. Không phải vì nó có giá trị, nhưng bởi vì sẽ rất khó để thay đổi sau này và họ có thể cần nó.

Người ta có thể cung cấp ước tính mức cao cho một tập hợp các tính năng được yêu cầu bởi đối tác kinh doanh. Tuy nhiên, nhóm nghiên cứu, bao gồm CNTT và chủ sở hữu sản phẩm chấp nhận phạm vi và mức độ ưu tiên đó và có thể dễ dàng thay đổi trong quá trình triển khai các tính năng. Bằng cách tập trung vào việc làm việc trên các tính năng quan trọng nhất đầu tiên, nhóm nghiên cứu trở thành giá trị không được định hướng theo kế hoạch. Nếu bất cứ điều gì rơi ra khỏi danh sách nó có giá trị thấp hơn và đã được di dời bởi một cái gì đó nhóm nghiên cứu đã học được quan trọng hơn.

Hợp đồng cho phạm vi cố định khóa nhóm đưa ra quyết định phạm vi khi họ biết ít nhất về các tính năng. Tập trung vào ưu tiên và cho phép mức độ ưu tiên và phạm vi để chuyển đổi giữa các lần lặp đảm bảo những gì được phân phối có giá trị.

Thay vì ký hợp đồng với phạm vi cố định với doanh nghiệp, hãy tham dự một chương trình đào tạo nhanh với đối tác kinh doanh của bạn. Lớp học nên phác thảo quy trình nhanh và vai trò của chủ sở hữu sản phẩm. Nếu doanh nghiệp chấp nhận cách tiếp cận nhanh nhẹn bạn đã sẵn sàng để bắt đầu phát triển. Xây dựng cho bạn sản phẩm tồn đọng, ưu tiên nó, cung cấp ước tính mức cao, xây dựng kế hoạch phát hành và lặp lại và bắt đầu phân phối giá trị.

Cách chúng tôi thực hiện mối quan hệ là trước tiên gửi đối tác kinh doanh đến trại khởi động nhanh. Sau đó, chúng tôi đã đào tạo đối tác kinh doanh làm chủ sở hữu sản phẩm. Sau đó, chúng tôi xây dựng backlog, cung cấp một ước tính mức cao và cố định kích thước của đội và thời gian đóng hộp phát triển. Trong vòng hai tuần, phần mềm làm việc đầu tiên được giới thiệu. Từ thời điểm đó đối tác kinh doanh đã ở trong và hiểu được giá trị của việc thay đổi khi họ học được nhiều hơn. Bất kỳ cuộc thảo luận về một hợp đồng phạm vi cố định đã sớm bị lãng quên.

Answer 7

Cách chúng tôi xử lý việc này khá hiệu quả.

Khách hàng của chúng tôi về cơ bản mua lặp lại. Khách hàng đăng xuất trên một hợp đồng nói "X 2 tuần lặp". Có một quá trình giáo dục khách hàng (như chung với tất cả các dự án nhanh nhẹn mà tôi đã làm) để giúp khách hàng tăng tốc với quy trình lập kế hoạch và ý tưởng rằng những gì họ thực sự đạt được vào cuối quá trình phát triển không phải là cụ thể sự bắt đầu của dự án NHƯNG rằng họ kiểm soát kết quả cuối cùng sẽ là gì.

Nhóm của chúng tôi đã làm việc cùng nhau trong gần sáu tháng, chúng tôi có cơ sở công nghệ vững chắc mà chúng tôi đã phát triển để giảm thiểu rủi ro. Chúng tôi có một nắm bắt khá vững chắc về năng lực liên tục của chúng tôi về vận tốc - điều này giúp chúng tôi đưa ra dự đoán về số lần lặp cần thiết để đáp ứng kết quả mong muốn của khách hàng.