Tôi muốn giải thích tại sao đặc điểm kỹ thuật không được thay đổi trong giai đoạn phát triển

Tôi muốn giải thích tại sao đặc điểm kỹ thuật không được thay đổi trong giai đoạn phát triển cho nhân viên phòng kế hoạch mới.

Một đặc tả gần như luôn luôn thay đổi trong quá trình phát triển cho bất kỳ dự án nào đơn giản nhất.

Những lý do là:

• Phát triển hoặc nhiều khả năng thử nghiệm tích hợp của dự án sẽ phát hiện ra những điều không được chú ý khi thông số ban đầu được thực hiện - từ các trường hợp cạnh đến các khía cạnh chính. Ví dụ: nhà phát triển thông báo rằng xác nhận tin nhắn không theo thứ tự có thể đến.

• Điều kiện thế giới thực xác định thông số kỹ thuật không bị đóng băng. Ví dụ: một sản phẩm tài chính mới được tạo ra cần được thêm vào thông số xử lý thông suốt.

• Áp lực thời hạn dẫn đến việc cắt tỉa các tính năng.

• Các bên liên quan bổ sung cho dự án được phát hiện (ví dụ giữa dự án, một dự án tương tự được phát hiện ở một khu vực khác và các hệ thống con chung cần được tập trung / chia sẻ - điều này xảy ra với tôi giữa dự án kéo dài 2 năm dẫn đến việc tái lập dự án lớn kéo dài 2 năm kiến trúc).

• Các nhà tài trợ bổ sung của dự án có các yêu cầu thông số kỹ thuật mới (một trong những ví dụ nổi tiếng nhất là lịch sử phát triển của Xe chiến đấu Bradley).

Về lý do tại sao các thay đổi thông số kỹ thuật có tác động bất lợi (bạn không thể nói "không được xảy ra" vì bạn có thể thấy có rất nhiều lý do họ làm, gần như ngoài tầm kiểm soát của bạn và nhiều lý do chính đáng) -

• Thay đổi thông số dẫn đến thay đổi mã, khiến bạn mất tập trung vào việc hoàn thành các phần dự án chưa được viết (như chúng ta đều biết và được truyền bá bởi Joel Spolsky, các thay đổi tập trung rất tệ cho các nhà phát triển)

• Một số thay đổi thông số kỹ thuật (đôi khi có vẻ RẤT nhỏ) có thể dẫn đến nhu cầu phải hoàn toàn tái thiết kế / tái kiến ​​trúc hệ thống do sự lựa chọn giữa 2 kiến ​​trúc được đưa ra dựa trên giả định được lấy từ thông số kỹ thuật .

• Trong trường hợp TDD, một khối lượng lớn công việc đưa vào các bài kiểm tra có thể bị hủy.

• Nếu các thay đổi thông số kỹ thuật đến từ các bên liên quan bổ sung như đã nêu ở trên, chúng có thể mâu thuẫn với thông số kỹ thuật hiện có, dẫn đến chất lượng sản phẩm giảm đáng kể (xem Chiến đấu xe, Bradley).

• Thay đổi thông số kỹ thuật có thể vi phạm một số yêu cầu kinh doanh hiện tại mà người thay đổi / người yêu cầu có thể không nhận thức được hoặc quan tâm (điều này thực sự giống như điểm đạn cuối cùng).

Tất cả số tiền này tất nhiên là ngày giao hàng kéo dài (đôi khi đáng kể) của dự án và có khả năng tăng khả năng bị lỗi.

Ví dụ tốt nhất về cách một thay đổi nhỏ trong thông số kỹ thuật có thể tạo ra các vấn đề cực đoan, tôi có 3 chữ cái cho bạn:

Y2K .

Tất cả những gì họ làm là thay đổi thông số kỹ thuật để nói " phải hoạt động sau năm 2000 ".

Ngoài ra, trong một số trường hợp, thực tế là thông số kỹ thuật PHẢI không thay đổi (trái ngược với "không nên thay đổi mà không có lý do chính đáng"):

• Một phần của thông số kỹ thuật là (hoặc phụ thuộc vào) một đặc điểm kỹ thuật của một hệ thống bên ngoài phải có giao diện.

• Một phần của thông số kỹ thuật là (hoặc phụ thuộc vào) một phần cứng mà hệ thống được triển khai.

• Yêu cầu hợp đồng với khách hàng (mặc dù giới hạn nói đúng về việc thay đổi thông số kỹ thuật mà không thực hiện các thay đổi với khách hàng trước và thay đổi hợp đồng, trái ngược với thực tế của thay đổi)

• Một hệ thống có thể cần phải đáp ứng các yêu cầu pháp lý hoặc quy định cụ thể bất kể sở thích của khách hàng. Ví dụ: mã hóa thẻ tín dụng, bảo vệ dữ liệu thuế.

Cấm thay đổi thông số kỹ thuật trong quá trình phát triển là lý tưởng cho lập trình viên, nhưng nó không thực tế trong môi trường thực tế. Mọi người sẽ luôn muốn thực hiện các thay đổi, ngay cả khi điều đó được vận chuyển ra khỏi cửa. Nó không bao giờ dừng lại. Và một số trong những người đó có thể đang ký vào bảng lương của bạn. Họ càng quan tâm, họ càng nghĩ về nó, và do đó họ càng muốn sửa đổi thiết kế thường xuyên hơn. Bạn phải có khả năng chịu đựng thay đổi thiết kế trước khi hoàn thành, ngay cả khi nó có nghĩa là bắt đầu lại.

Điều quan trọng là truyền đạt rõ ràng hậu quả của những thay đổi để mọi người có những kỳ vọng thực tế về quy trình thiết kế.

Các thay đổi phải được thảo luận chính xác và người chịu trách nhiệm về vấn đề này cần phải hiểu rõ về tác động của những thay đổi sẽ có trong ngày giao hàng. Để có được điều đó, anh ta phải nói chuyện với nhà phát triển. Tuy nhiên, vì một cuộc thảo luận liên tục về các thay đổi sẽ tràn ngập nhà phát triển và giữ cho bất kỳ công việc thực tế nào xảy ra, các thay đổi phải được xếp hàng và thảo luận theo các khoảng thời gian dự kiến, không thường xuyên. Đó là những gì bạn hy vọng, tất nhiên.

Lý tưởng nhất, bạn hướng dẫn mọi người ghi chú về những thay đổi họ muốn thực hiện và yêu cầu họ đưa ra trong cuộc họp phối hợp hàng tuần / hai tuần / tháng / bất cứ điều gì. Trong cuộc họp, mỗi yêu cầu thay đổi sẽ được thảo luận, bao gồm thảo luận về các sửa đổi cơ bản sẽ được thực hiện để thực hiện tính năng được yêu cầu và do đó có hiệu lực vào ngày hoàn thành. Khi "chi phí" của thay đổi được thiết lập, sau đó họ có thể xác định có bao gồm hay không.

Điều quan trọng mà quá trình này đưa ra là khái niệm rằng mỗi thay đổi có chi phí liên quan và chi phí thường cao hơn khi tiến triển dự án hơn nữa, do nhiều công việc phải được nhân đôi. Những người không làm việc trong sự phát triển thường không biết chi phí thay đổi sẽ là bao nhiêu; cách duy nhất để họ nói là đề xuất và đánh giá phản ứng của bạn. Tạo một quy trình xem xét thay đổi được xác định rõ ràng sẽ giúp cả họ và bạn.

Lưu ý rằng các lập trình viên có xu hướng cực kỳ lạc quan về việc thay đổi dễ dàng như thế nào, hoặc cực kỳ bi quan về việc sẽ không thể thực hiện được. Cố gắng tìm ra bạn là gì bằng cách so sánh các ước tính ban đầu của bạn với kết quả và điều chỉnh cho phù hợp.

Có lẽ sẽ tốt hơn khi nói rằng đặc tả kỹ thuật không được thay đổi nếu không có yêu cầu và quy trình thay đổi hợp lệ. Yêu cầu thay đổi thông số kỹ thuật có ảnh hưởng đến lịch trình và chi phí, vì vậy những điều này phải được đưa vào phê duyệt.

Cho rằng có một quy trình quản lý thay đổi phù hợp, không có gì "sai" về việc thay đổi thông số kỹ thuật, nhưng nó có thể rất tốn kém, vì vậy khách hàng của bạn có thể không quá vui mừng. Bạn có thể bảo vệ chúng khỏi bản thân bằng cách cố gắng đưa ra một số yêu cầu tốt và thông số kỹ thuật trước, để có ít thay đổi hơn.

Sự tương tự tốt nhất tôi có là so sánh nó với việc xây dựng một ngôi nhà. Kiến trúc sư đưa ra các kế hoạch, và sau đó đưa ra một ước tính, sau đó khách hàng đồng ý (hoặc không) với kế hoạch. Nếu khách hàng muốn có thêm một phòng tắm thì công việc dừng lại, kế hoạch phải thay đổi, một ước tính mới được thực hiện và khách hàng đồng ý (hoặc không).

Viết phần mềm cũng không khác. một khi thỏa thuận đã được thực hiện (sau khi thiết kế và ước tính) thì nếu có bất kỳ thay đổi nào cần thực hiện thì công việc cần phải dừng lại để có thể lập kế hoạch mới, ước tính mới sau đó được phê duyệt (hoặc không) và sau đó công việc sẽ tiếp tục.

bất cứ nơi nào tôi nói hay không có nghĩa là dự án sẽ tiếp tục mà không có những thay đổi mới. Tất nhiên luôn có thời gian và vật liệu để đưa ra các kế hoạch và ước tính mới.