Phạm vi cố định + thời hạn cố định + hợp đồng giá cố định có thể được thực hiện để làm việc với siêu nhanh không?

Một số dự án chúng tôi chạy nội bộ sử dụng là Scrum, trong khi vẫn "cố định mọi thứ" cho khách hàng. Chúng tôi đang trải qua thành công hỗn hợp từ phía chúng tôi (khách hàng thích khả năng hiển thị của biểu đồ phát sinh). Các loại dự án chúng ta làm việc có thể được thực hiện thành công bằng các phương thức nhanh không?

Chà, tôi đã làm việc chủ yếu trong môi trường "nhanh nhẹn" (mặc dù chúng tôi không sử dụng biệt ngữ) và tôi đã làm những việc có chi phí cố định. Nói chung, số tiền phải trả là cộng với chi phí, vì không có công ty nào có thể đủ khả năng để làm mọi thứ miễn phí, và các yêu cầu thay đổi và phát triển khi khách hàng hiểu rõ hơn những gì họ muốn.

Các yêu cầu ban đầu cho phần chi phí cố định phải được thực hiện cẩn thận hơn nhiều so với chúng được thực hiện trong một môi trường lặp điển hình, làm cho quá trình có phần ít lặp đi lặp lại. Phần "cộng" của hợp đồng có thể lặp đi lặp lại nhiều hơn, miễn là chúng tôi đã hoàn thành phần chi phí cố định ít nhiều thỏa đáng cho khách hàng.

Tôi muốn đặt ra một câu hỏi ngược lại:

Phạm vi cố định + thời hạn cố định + hợp đồng giá cố định bao giờ được thực hiện để làm việc, thời gian ?

Câu nói "tốt / nhanh / rẻ - chọn hai" không chỉ là một trò đùa kỹ thuật ngớ ngẩn. Mọi người quản lý dự án đáng muối của mình đều biết về Tam giác quản lý dự án :

Bạn đang nói với chúng tôi rằng chi phí, phạm vi và lịch trình đều cố định. Điều đó không có chỗ cho khả năng cơ động hoặc lỗi. Không có . Bạn có thể chọn xem "Chất lượng" là một thuộc tính, nhưng nó không phải là thuộc tính "thực", nó giống như một thuộc tính meta có nguồn gốc từ các thuộc tính khác (chi phí / phạm vi / lịch biểu).

Vấn đề là điều này không bao giờ xảy ra trong thực tế miễn là dự án của bạn đang được con người lên kế hoạch và thực hiện.

• Các yêu cầu và thông số kỹ thuật không bao giờ bao gồm mọi trường hợp cạnh trừ khi chúng được các kiến ​​trúc sư và nhà thiết kế có trình độ chi tiết bao quát, trong trường hợp đó, dự án đã hoàn thành một nửa; và thậm chí sau đó vẫn có khả năng xảy ra lỗi.

• Chi phí bất ngờ sẽ bật lên dẫn đến bội chi ngân sách. Một thuê bao đã hết hạn. Một nhà sản xuất đã ngừng hỗ trợ cho sản phẩm bạn đang sử dụng và bạn phải tìm một sản phẩm mới. Một nhà thầu hàng giờ tăng tỷ lệ của mình dưới mối đe dọa khởi hành. Toàn bộ đội của bạn vừa đình công, yêu cầu tăng 10% và thêm một tuần nghỉ phép.

• Lịch trình trượt. Vấn đề không lường trước được vụ mùa lên; thành phần biểu đồ mà bạn đã sử dụng trong 5 năm liền không tương thích với Windows 95 mà khách hàng của bạn vẫn đang sử dụng. Một lỗi khó hiểu trong Windows 64 bit gây ra sự cố nghiêm trọng về giao diện người dùng và bạn mất gần một tuần để theo dõi và phát triển một cách giải quyết (điều này thực sự đã xảy ra với tôi). Nhà phát triển cấp cao của bạn đã bị xe buýt đâm và bạn phải đi tuyển dụng và đào tạo một cái mới. Ngày giao hàng ước tính của bạn luôn luôn sai. Luôn luôn.

  Xem Luật của Hofstadter :

  Luật của Hofstadter: Luôn mất nhiều thời gian hơn bạn mong đợi, ngay cả khi bạn tính đến Luật của Hofstadter.

Các phương pháp Agile là tất cả về việc tung hứng xung quanh chi phí, lịch trình và phạm vi. Hầu hết thời gian, họ đặc biệt nói về việc tung hứng trong phạm vi và đôi khi là lịch trình , đó là lý do tại sao bạn bắt đầu với những câu chuyện người dùng mơ hồ và lên kế hoạch sửa đổi thay vì phiên bản đầy đủ. Các phương pháp khác nhau sử dụng thuật ngữ khác nhau nhưng tất cả đều là tiền đề cơ bản giống nhau: Phát hành thường xuyên và cân bằng lại lịch trình và phạm vi với mỗi bản phát hành.

Điều này làm cho không có ý nghĩa với một dự án mà là (hoặc khiếu nại để được) hoặc phạm vi cố định hoặc lịch trình cố định.

Nếu một thuộc tính dự án (chi phí / phạm vi / lịch biểu) được cố định, tôi sẽ nói với bạn rằng nó có thể không phù hợp với các phương pháp nhanh.

Nếu hai thuộc tính dự án là cố định, thì dự án của bạn chắc chắn không phù hợp với các phương pháp nhanh.

Nếu cả ba thuộc tính đều cố định, thì dự án của bạn có thể sẽ thất bại. Nếu nó thực sự xuất xưởng, thì lịch trình ban đầu đã bị sai lệch một cách ồ ạt, hoặc khách hàng đã tự ảo tưởng rằng bạn thực sự đã giao những gì đã hứa.

Nếu hợp đồng này vẫn còn trên bàn, tôi mong bạn từ chối nó. Và nếu bạn đã chấp nhận nó, xin Chúa thương xót tâm hồn bạn.

Tôi thích trích dẫn này:

Scrum Scrum là tuyệt vời cho cả phạm vi biến ngày cố định hoặc "phạm vi cố định" (luôn luôn phát triển) ngày biến. Nếu bạn đang thực hiện phạm vi cố định vào ngày cố định, tôi khuyên bạn nên dùng thác nước hoặc RUP, họ sẽ mua cho bạn một vài tháng để tìm kiếm một công việc mới.

Chắc chắn, miễn là thanh chất lượng của bạn được giữ ở mức thấp đáng kể. Tôi là một tín đồ của tam giác sắt cũ về "thời gian giao hàng / chất lượng / giá cả" nơi bạn có thể chọn hai, nhưng sau đó một cái khác trôi nổi. Có vẻ như bạn đã cố định thời gian giao hàng và giá cả (và cả các tính năng) vì vậy thực sự điều duy nhất có thể cung cấp là chất lượng.

Điều đó nói rằng, nếu bạn đang sử dụng biểu đồ phát sinh và bạn có các mục ưu tiên cao nhất được thực hiện trước tiên thì có thể chấp nhận được một số các mục quan trọng nhất được thực hiện trong khung thời gian đã chỉ định cho số tiền tệ được chỉ định. Ít nhất thì khách hàng của bạn sẽ thấy rằng bạn đang kiểm soát quá trình phần nào, với khả năng cung cấp vào cuối mỗi lần lặp và họ có khả năng nói điều gì là quan trọng nhất.

Mặt khác, tôi nghĩ rằng việc cam kết trong một thời gian cố định, bộ tính năng và giá cả là điên rồ và sẽ dẫn đến những nỗ lực anh hùng dẫn đến chất lượng thấp hơn và mã ít bảo trì hơn. Agile không phải là hạt bụi thần tiên.

Giá cố định / thời hạn cố định / phạm vi cố định có thể được thực hiện ít nhất là nhanh nhẹn như nó có thể ở trong thác nước.

Trong thác nước, ước tính thời gian là không chính xác và chi tiết cuối cùng được thực hiện khác với thông số kỹ thuật ban đầu. Nói cách khác, thời hạn / phạm vi không thể được biết chính xác trước.

Trong nhanh nhẹn, bạn có thể chạy nước rút số 0 để tạo một hồ sơ tồn đọng các câu chuyện của người dùng và đưa ra một số ước tính. Sau đó đồng ý đáp ứng các câu chuyện giá trị với một mức giá cố định, theo thời hạn cố định. Phạm vi được cố định theo các câu chuyện giá trị mà bạn dự định thực hiện và không có lời hứa nào được thực hiện về các câu chuyện của người dùng.

Nói cách khác, bạn hứa sẽ cung cấp những gì quan trọng và tránh đưa ra những lời hứa về các quyết định thiết kế cụ thể không liên quan đến doanh thu / tiết kiệm / vv. rằng dự án sẽ được giao.

Tôi đồng ý với Bruce ở một mức độ nhất định. Mặc dù tôi không quá quen thuộc với thác nước hoặc RUP, và do đó không thể nhận xét về điều đó.

Những gì tôi đọc gần đây, và tôi nghĩ rằng đã thực sự nói tốt, đó là ngay cả trong Agile, chúng tôi bỏ bê kế hoạch. Một phiên lập kế hoạch kỹ lưỡng một lần lặp lại là tuyệt vời - không cần thiết - nhưng kế hoạch cũng không phải là lặp đi lặp lại.

Tôi làm việc trong ngành giải trí, nơi mọi thứ liên tục thay đổi. Nhóm cần một số mức độ khoan hồng / linh hoạt sẽ cho phép họ "lập kế hoạch lại" các câu chuyện giữa nước rút để phù hợp với các mục tiêu mới hoặc các mục tiêu được sửa đổi.

Tôi thích ý tưởng lập kế hoạch liên tục, vì thường thì các nhà phát triển sẽ bảo chủ sở hữu sản phẩm biến mất khi họ đang làm việc trên những câu chuyện giữa nước rút. Điều này thật tuyệt vời nếu nhóm của bạn làm việc trên những câu chuyện vẫn còn hiệu lực và chủ sở hữu sản phẩm của bạn chỉ là một mối phiền toái. Nhưng trong một số trường hợp, các câu chuyện trở nên dư thừa DURING chạy nước rút, và bắt buộc chủ sở hữu sản phẩm phải phát hiện ra điều này và để nhóm sắp xếp lại các mục tiêu / câu chuyện đã thay đổi - đó không phải là điều nhanh nhẹn?