Làm thế nào để các mốc thời gian chặt chẽ và áp lực lịch trình ảnh hưởng đến TCO và thời gian giao hàng?

Cha của một người bạn, một người quản lý kỹ thuật phần mềm, đã nói, một cách dứt khoát, "Nguyên nhân số một của việc vượt quá lịch trình là áp lực lên lịch trình."

Nghiên cứu đứng ở đâu? Là một áp lực lịch trình vừa phải tiếp thêm sinh lực, hay người quản lý mà tôi đã đề cập đúng hay sai, hay đó là vấn đề "bạn càng có nhiều áp lực lên lịch, thời gian giao hàng càng lâu và càng nhiều TCO?" Đây có phải là một trong những điều mà công nghệ phần mềm lý tưởng sẽ hoạt động mà không cần lập lịch áp lực nhưng thực tế chúng ta phải làm việc với các ràng buộc của các tình huống trong thế giới thực?

Bất kỳ liên kết đến tài liệu kỹ thuật phần mềm sẽ được đánh giá cao.

Nguyên nhân số một của việc vượt quá lịch trình là áp lực lập lịch.

Tôi không đồng ý. Nguyên nhân số một của việc vượt quá lịch trình là một lịch trình không phản ánh đúng thực tế và theo cách quá lạc quan. Bản chất con người ra lệnh rằng một số áp lực lập kế hoạch là một điều cần thiết tuyệt đối. Chỉ cần một vài vấn đề phát sinh mà không có một chút áp lực lên lịch trình là những vấn đề thú vị và "tốt nhất là kẻ thù của đủ tốt." Chúng tôi, những người kỹ thuật sẽ thích làm việc với những vấn đề mà chúng tôi quan tâm hơn là vấn đề cần được giải quyết để đưa sản phẩm ra khỏi cửa. Bỏ đi thời hạn (hay còn gọi là áp lực lịch trình) và chúng tôi sẽ giải quyết những vấn đề thú vị đó, gây bất lợi cho sản phẩm.

Một vấn đề khác là sản phẩm cần phải "đủ tốt". Nó không cần phải hoàn hảo. Các kỹ sư và nhà khoa học thấy các giả định đơn giản hóa không hoàn toàn hợp lệ trong một số trường hợp đặc biệt. Các nhà thiết kế đồ họa nhìn thấy các vấn đề răng cưa vô hình với mọi người khác. Các lập trình viên nhìn thấy mụn cóc trong các kiến ​​trúc của họ mà không ảnh hưởng đến hành vi của sản phẩm. "Tốt nhất là kẻ thù đủ tốt", điều đó có nghĩa là đôi khi chúng ta phải sống với những vấn đề không thực sự có vấn đề.

Thiếu áp lực lịch trình sẽ dẫn đến một sản phẩm có chi phí sở hữu rất cao. Những gì gây ra tràn ngập là lịch trình xấu. Điều này có thể đến trong một loạt các hình thức. Đánh giá thấp nỗ lực cần thiết, không tính đến sự phụ thuộc, thêm người vào một dự án đã muộn. Chỉ để một vài tên.

Thời gian, chất lượng, tài nguyên và số lượng tính năng đều được kết nối. Bạn có thể sửa bất kỳ ba trong số chúng, và lấy cái cuối cùng làm đầu ra của quá trình lập lịch trình của bạn.

Cách thức câu hỏi của bạn được ngụ ý rằng thời gian là biến của bạn và ba yếu tố khác (chất lượng, tài nguyên và số lượng tính năng) đều cố định. Câu hỏi có thể có lợi từ việc thay đổi quan điểm một chút bằng cách sửa thời gian ^* và để chất lượng nổi.

Bây giờ câu hỏi của bạn trở thành: "Hạn chế thời gian có ảnh hưởng tiêu cực đến chất lượng" không? Câu trả lời cho câu hỏi này là một câu "Có" vang dội: nghiên cứu xác nhận rằng mọi người làm tồi tệ hơn dưới áp lực đối với các vấn đề liên quan đến toán học ^** rằng họ đã không thực hành rộng rãi trước đó (ví dụ như đã cố gắng năm mươi lần trở lên), vì vậy cha của bạn của bạn là đúng.

^** Có một giả định ngầm ở đây rằng lập trình tương tự như làm toán; Tôi nghĩ giả định này là công bằng.

bạn càng có nhiều áp lực lên lịch, thời gian giao hàng càng dài và càng nhiều TCO?

Vâng, bất kỳ lịch trình được thực hiện bởi người quản lý mà không thảo luận với lãnh đạo kỹ thuật là dễ dàng đó. Một sự thật rất rõ ràng là Lập kế hoạch hoặc ước tính KHÔNG dựa trên thực tế là dễ bị thất bại .

Ngoài ra, các nhà quản lý tránh Lập kế hoạch dựa trên bằng chứng cũng đang chuyển sang thất bại tiếp theo của dự án của họ. Có một số nghiên cứu về chủ đề này và lập kế hoạch dựa trên số liệu là cách đúng đắn để làm theo.

Phải sang trái lập lịch.

Một người trong ban quản lý luôn nghĩ rằng họ là Steve Jobs với vùng méo mó thực tế nổi tiếng của ông. Cho đến khi ai đó phát triển sản phẩm giáo dục họ, các nhà quản lý phi kỹ thuật thường có thể có quan điểm về việc lên lịch trình phức tạp như bộ phim đầu tiên của Pháp "Le Voyage dans la lune" ("A Trip to the Moon") dành cho khoa học tên lửa.

Vấn đề đã được một thời gian. Fred Brooks nói về ước tính ít ruột trong Tháng huyền thoại . Barry Boehm nói về điều đó trong các đề xuất của ông về cách tiếp cận quản lý Theory-W . Gần đây, Steve McConnell (tác giả của Code Complete ) đưa khái niệm về vấn đề đàm phán nguyên tắc vào trọng tâm trong "Cách bảo vệ một lịch trình không phổ biến" .

Agile đẩy phạm vi của các dự án đến một nơi dễ thấy. Các Agile Manifesto kêu gọi "sự hợp tác của khách hàng qua đàm phán hợp đồng". Nó cũng, tôi hy vọng, trao quyền cho những người chịu trách nhiệm. Các trò chơi kế hoạch tránh các bên liên quan phi kỹ thuật ép buộc các nhà phát triển hứa hẹn họ đã làm từ lâu đã bị tràn ngập bởi những thay đổi trong các yêu cầu hoặc những khám phá mới.

Nếu tổ chức của bạn từ chối nhanh nhẹn, có những phương pháp tuyệt vời liên quan đến hiệu chuẩn các ước tính để sắp xếp lại lịch biểu dựa trên giá trị kiếm được . Tôi không nghĩ giá trị kiếm được là một công việc tuyệt vời với một số vấn đề thực sự với dự đoán, nhưng nó có thể giúp loại bỏ những ảo tưởng về vận tốc của các dự án và làm sai lệch các ước tính mà chúng ta có bằng cách nào đó là sự thật.

Có một câu nói rằng bạn bắt đầu viết mã càng sớm thì càng mất nhiều thời gian. Áp lực lịch trình có thể có tác động buộc thay đổi phương pháp. Đôi khi nó là từ thác nước đến "mã như địa ngục". Điều này có thể có tác động tiêu cực đến chất lượng, chưa kể đến tinh thần khi người lao động không thể làm hết sức mình và đồng nghiệp và người bảo trì trong tương lai thấy họ ở mức tồi tệ nhất, không phải là tốt nhất của họ. Trong một môi trường như thế này, một mức độ hỗn loạn nào đó có thể được kiểm soát bằng kiểm soát nguồn, xây dựng và kiểm tra hàng ngày (hoặc tích hợp liên tục và kiểm tra đơn vị), đánh giá mã, sử dụng một đội ngũ có kinh nghiệm và có kỹ năng cao, chống lại sự cám dỗ để thêm nhân viên vào cuối dự án, và chế độ chờ cũ, làm thêm giờ.

Những lần khác, sự thay đổi phương pháp có thể là từ thác nước tăng dần. Kinh nghiệm của tôi là quản lý đã chậm chạp trong việc nắm lấy Agile. Nhưng sau một thời gian, có sự quản lý mới hỗ trợ nhiều hơn cho Agile. Quyền anh thời gian có thể giống như lập ngân sách - nó có thể buộc chúng ta phải suy nghĩ về việc sử dụng tốt nhất một nguồn lực hạn chế. Scrum có hai hộp thời gian - một hộp là hàng ngày để phản hồi giữa các thành viên trong nhóm, hộp còn lại là hàng tháng để chạy nước rút thông qua danh sách ghi lại.

Giấy phép Creative Commons - xem http://en.wikipedia.org/wiki/File:Scrum_ process.svg

Bạn không cần tài liệu kỹ thuật phần mềm. Xác suất và thống kê khái niệm, từ sinh viên đại học, là tất cả những gì bạn cần.

Một ước tính chỉ là, một ước tính. Nó không chính xác, nó không được bảo đảm. Đối với bất kỳ ước tính nào, có một số xác suất mà bạn sẽ vượt qua nó, hoặc đánh vào mũi, và một số xác suất mà bạn sẽ vượt qua nó.

Xác suất 101: p (vượt hoặc đánh chính xác) + p (vượt mức) = 100%.

Một lịch trình dựa trên một ước tính có các đặc điểm chính xác giống nhau.

Bạn không thể loại bỏ hoàn toàn sự không chắc chắn. Sẽ luôn luôn có một số xác suất vượt qua. Nó có thể nhỏ, xác suất Iran bắt đầu xây dựng văn phòng của bạn, nhưng nó vẫn còn đó. Điều tốt nhất bạn có thể làm là nhìn vào MỌI THỨ, và giảm sự không chắc chắn hết mức có thể. Một khi bạn đã làm điều đó, bạn sẽ, nếu bạn may mắn, có một lịch trình với sự không chắc chắn nhỏ, và xác suất 50% cho mỗi bên.

Bây giờ, hãy nghĩ về nó: Nếu bạn kéo lịch trình vào, xác suất bạn sẽ vượt qua hoặc chính xác đạt được lịch trình giảm. Tổng số vẫn phải tổng hợp đến 100%. Xác suất đó đi đâu? Trả lời, nó đi vào xác suất vượt.

General Dynamics / Fort Worth Division đã học được điều này một cách khó khăn. Họ đã ước tính ban đầu để phát triển F-16C / D và gửi nó lên chuỗi thức ăn. Ai đó cao hơn tùy tiện cắt một năm ra khỏi nó, và gửi nó cho Không quân. Kết quả trực tiếp, GD / FW đã trễ một năm để thử nghiệm chuyến bay và Không quân KHÔNG hạnh phúc. (Lưu ý rằng "trễ một năm" là theo lịch trình sửa đổi, có nghĩa là lịch trình ban đầu là QUYỀN TRÊN MỤC TIÊU.)

Tôi nghĩ rằng một áp lực nhất định trong một dự án là ổn vì nó giúp duy trì sự tập trung.

Tuy nhiên, nếu áp lực là không thực tế, hoặc nếu giao tiếp giữa quản lý và người kỹ thuật không hoạt động đúng, vâng, có nguy cơ lên ​​lịch áp lực dẫn đến chất lượng kém và / hoặc giao hàng trễ.

Một nhà phát triển có kinh nghiệm sẽ biết rằng anh ấy / cô ấy không mong đợi tạo ra giải pháp hoàn hảo mà là một giải pháp đủ tốt . Vì vậy, ước tính được đưa ra bởi một nhà phát triển như vậy sẽ phản ánh sự hiểu biết của họ về những gì đủ tốt cho một dự án cụ thể.

Có nhiều yếu tố ảnh hưởng đến định nghĩa đủ tốt.

Ví dụ, dự án kéo dài bao nhiêu tháng? Nếu dự án kéo dài một năm, bạn có thể viết một nguyên mẫu của mô-đun đặc biệt khó khăn đó khá nhanh khi bắt đầu dự án và sau đó bạn có vài tháng để kiểm tra và gỡ lỗi nó như là một hoạt động phụ cho sự phát triển của các mô-đun thường quy khác. (Bạn có thể để mô-đun đó chín muồi trong vài tháng cho đến khi nó đủ tốt để bạn không cần phải thử và lấy nó ngay từ đầu.) Tôi thấy chiến lược này rất hiệu quả nhưng bạn cần một người quản lý tin tưởng bạn và sẽ cho phép bạn giữ một dự án mở trong nhiều tháng. Một người quản lý (không tin tưởng) khác có thể thúc đẩy bạn hoàn thành mô-đun đó càng sớm càng tốt (không có vấn đề gì nếu bạn phải sửa nó sau và nếu phương pháp này cuối cùng sẽ tốn nhiều thời gian hơn).

Một ví dụ khác: dự án dành cho một sản phẩm sẽ chỉ có một bản phát hành. Sau đó, bạn có thể cố gắng hoàn thành nhanh chóng và dựa vào các thử nghiệm rộng rãi để đảm bảo rằng sản phẩm hoạt động như mong đợi (nhanh và bẩn là đủ tốt ). Mặt khác, nếu sản phẩm sắp có hai hoặc ba bản phát hành, tốt hơn nên dành một chút thời gian để thiết kế nó, để tránh việc viết lại mã rộng rãi cho các bản phát hành sau. (Trong trường hợp này, nhanh và bẩn không đủ tốt vì tổng thời gian phát triển trong ba bản phát hành lớn hơn.)

Tóm lại, tôi nghĩ rằng giao tiếp xấu giữa quản lý và người kỹ thuật và thiếu hiểu biết chung về những gì đủ tốt cho dự án có thể dẫn đến áp lực lên lịch quá mức, dẫn đến chất lượng kém / giao hàng trễ.

Không bao giờ có đủ thời gian để làm điều đó đúng lần đầu tiên, nhưng luôn có đủ thời gian để sửa nó sau này.