10 lí do làm chậm tiến độ của những dự án phần mềm

Linh Le

Bất chấp những nỗ lực để tái thiết kế quy trình phát triển phần mềm với các phương pháp và công cụ mới, các dự án vẫn không tuân theo kế hoạch do cách làm việc quan liêu, nhu cầu mới luôn xuất hiện và bản chất của code.

10 reasons software projects are slower than we expect

Douglas Hofstadter, một lập trình viên máy tính lâu năm đồng thời là tác giả của cuốn “Gödel, Escher, Bach” đã đúc kết kinh nghiệm của mình trong ngành máy tính với quy tắc mang tên mình như sau: Mọi thứ luôn luôn lâu hơn bạn nghĩ, thậm chí ngay cả khi bạn dùng tới định luật Hofstadter.

Tuy nhiên, các tổ chức, những thành phần liên đới và các nhà quản lý dự án trên thế giới vẫn đặt ra các mốc thời gian cho các dự án phần mềm. Ngay cả chính các lập trình viên cũng tự làm thế. Có phải định luật Hofstadter quá hiển nhiên với các lập trình viên, những người phải vật lộn với những kiến thức máy móc phức tạp, hay với các nhà quản lý dự án, nhựng người phải cố gắng dẫn dắt mọi người qua giai đoạn khó khăn? Các nhà quản lý dự án dựa vào API để tiết kiệm hai tháng làm việc, nhưng các lập trình viên mới chính là người phát hiện ra rằng API có 129 tùy chọn – ngoài những tùy chọn mà công ty cần. Để code hoạt động đã khó, nhưng việc quản lý tám lập trình viên, những người phải vật lộn với các lỗi khác nhau khiến code không hoạt động được cũng khó khăn không kém.

Đứng ngoài nhìn thì các nhà tài trợ vào dự án chỉ biết nhịp tay cảm thấy sốt ruột. Trong khi đó, những người đứng đầu và các nhà quản lý dự án nhận thấy các lập trình viên đang điên cuồng chèo lái con thuyền và chẳng đi đến đâu cả, còn các lập trình viên chỉ thấy những người giao nhiệm vụ không hiểu được dòng nước đang chảy mạnh như thế nào.

Từ lâu đã có người cố gắng tìm ra phương án mang tính khoa học để đo lường năng suất và đếm số dòng code. Fredrick Brooks đã xé bỏ lý thuyết đó vào năm 1975 với cuốn The Mythical Man-Month, một cuốn sách cho thấy rõ rằng tất cả những mô hình toán học và giả định về quá trình tuyến tính không thể áp dụng được.

Kể từ đó, những bụi gai trải dài trên con đường hoàn thành dự án ngày càng dày hơn. Những ý tưởng thông minh về mô hình nhanh nhẹn này cũng như việc xây dựng liên tục có thể hiệu quả tạm thời với một vấn đề cục bộ, nhưng chúng khiến cho mọi thứ phức tạp hơn và sự phức tạp lại là vấn đề khó khăn nhất. Khách hàng, các bên liên quan và những người nắm giữ cổ phiếu ngày càng đòi hỏi nhiều hơn, nhưng như thế cũng có nghĩa là sẽ mất nhiều thời gian hơn.

Dưới đây là 10 lý do tại sao các dự án phần mềm tốn nhiều thời gian hơn dự kiến mặc dù đã có các công cụ và kỹ thuật mới giúp tăng tốc độ xây dựng phần mềm. Các lí do này có thể không giải thích được từng tình huống tốc độ bị chậm, nhưng chúng có thể giúp các nhà quản lý hiểu được tất cả quá trình code sẽ dẫn đến điều gì.

Vượt phạm vi dự án (Scope creep)

Bạn có thể sử dụng cùng tên cho dự án mà team phần mềm đã ra mắt cách đây vài tháng, nhưng phạm vi và sản phẩm đã thay đổi rất nhiều đến mức nên gọi nó với cái tên nào đó khác đi. Mục tiêu tổng quát có thể vẫn giữ nguyên, nhưng đã có người thay đổi kiến trúc đủ nhiều để bạn phải làm lại từ đầu mọi thứ.

Có lẽ không công bằng khi xem vấn đề trên như một dự án tốn nhiều thời gian hơn dự kiến – thực tế đó là dự án đầu tiên đã kết thúc một thời gian trước và một dự án hoàn toàn mới đã được tiến hành, dưới cùng một cái tên và không được quảng bá rầm rộ. Trên thực tế, có thể có một vài dự án khác được hoàn thành trong vài tháng giữa chu trình, và do đó, nếu tính toán chính xác thì sẽ không ai nói rằng MỘT dự án của bạn đã mất nhiều tháng hơn dự kiến ban đầu, mà là lập trình viên đã tốn hiều thời gian hơn với nhiều dự án có cùng tên.

Những cuộc bàn cãi

Mặc dù các lập trình viên rất hay cằn nhằn về chuyện văn phòng mở và muốn có không gian tách biệt và những chiếc tai nghe khổng lồ để tập trung viết code, nhưng với lý do nào đó mà vẫn không có đủ thời gian trong ngày cho tất cả các cuộc bàn luận cần thiết dành cho việc thiết kế phần mềm. Nó gần như thể chúng ta thấy việc tranh luận về phương án lại hứng thú hơn là hoàn thành công việc.

Tất nhiên, chúng ta có thể cười cợt về lượng thời gian chúng ta dành cho các cuộc họp chỉ để nói về cách tốt nhất để cấu trúc một số menu hoặc thiết kế một số lược đồ, nhưng sự thật là ngay cả dự án đơn giản nhất cũng yêu cầu xây dựng một cái gì đó mới mẻ một chút. Viết code không giống như xây dựng một con đường, công việc còn lâu đời hơn cả Đế chế La Mã nữa. Sẽ mất nhiều thời gian hơn để tối ưu hóa phần mềm bởi vì nó chưa được thực hiện nhiều lần trước đây – và chắc chắn không phải là các thông số kỹ thuật trên các hệ thống này khi ta nhắm tới mục đích kinh doanh.

Agile có những giới hạn

Đối với nhóm quản lý thì quy trình là tất cả. Vì vậy, khi nói đến việc duy trì tốc độ thì framework và phương pháp chính là những giải pháp hàng đầu của các nhà quản lý. Các nhà quản lý dự án phần mềm thường thích tranh luận về phương pháp phát triển tốt nhất, nhưng tất cả đều có những hạn chế. Các framework, xét cho cùng chỉ là các hướng dẫn, và thực tế thường khác với lý thuyết, dẫn đến các ngoại lệ phải được điều hướng, ngay cả các mốc thời gian trong kế hoạch của dự án đã được đánh dấu.

Đối với các lập trình viên, chúng ta có xu hướng dùng Agile vì nó giúp ta có nhiều lựa chọn nhất và chọn giai đoạn mình có thể thực hiện, nhưng nó có thể dẫn đến sự hỗn loạn nếu không có người chỉ dẫn. Một người quản lý chu trình nói với tôi rằng đừng lo lắng liệu code có đúng không bởi vì chúng ta luôn có thể tạo một ra một chu trình Agile mới để sửa nó. Vậy đấy! Chúng tôi được tín nhiệm gấp đôi khi giải quyết gấp đôi số lượng công việc. Nó gần như là chúng tôi đã mang lại kết quả gấp đôi.

Không ai có thể nhìn thấy trước mọi thứ

Isaac Newton, người được gọi là nhà phát minh ra giải tích, đã từng nói: “Nếu tôi nhìn xa hơn những người khác, đó là vì tôi đứng trên vai những gã khổng lồ.” Giải tích có thể là đỉnh cao của toán học trung học và nền tảng cho nhiều ngành khoa học, nhưng nó chỉ gồm vài phép toán cơ bản. Nó không giống như một hệ thống bảng lương phải hoạt động trên 50 tiểu bang khác nhau, không kể đến Đặc khu Columbia và Puerto Rico.

Vấn đề là chúng tôi, các lập trình viên phần mềm được yêu cầu xây dựng các hệ thống hợp nhất không phải hàng trăm thì cũng là hàng chục cộng đồng, và việc nhớ hết tất cả các nhu cầu của họ trong đầu là điều gần như không thể. Tình hình còn tồi tệ hơn khi mà không có đôi vai của gã khổng lồ nào để mà đứng lên, vì hệ thống mới gần như sẽ phá vỡ hoàn toàn mọi thứ có từ trước đó trong khi vẫn phải mang lại cảm giác thật chất cho người dùng. Vì vậy, chúng tôi đành liều đánh cược vào một số thứ trừu tượng cơ bản, cố gắng sửa các chi tiết khi chúng tôi lặp lại, và sau đó hy vọng điều tốt nhất sẽ đến. Sửa tất cả các mục tiêu sẽ mất thời gian vì có rất nhiều chi tiết.

Các bên liên quan thay đổi suy nghĩ của họ

Bạn có thể nghĩ rằng các lập trình viên phần mềm kiểm soát tốc độ công việc của họ, nhưng sự thật là, chúng tôi thường làm việc với các mục tiêu di động. Thật không công bằng khi đổ lỗi cho team phần mềm về những thay đổi đến từ phía khách hàng và các bên liên quan khác trong tổ chức. Họ liên tục đưa ra các yêu cầu mới cho chúng tôi sửa đổi và cải tiến. Đôi khi chỉ là thêm một chi tiết nhỏ rất dễ dàng, nhưng đôi khi có thể rất khó và phá hủy phần lớn những gì đã hoàn thành trước đó.

Cấu trúc dữ liệu cứng nhắc

Dữ liệu là một con thú khó thuần hóa và phần lớn công việc phát triển phần mềm chính là đưa các bit dữ liệu vào đúng vị trí. Một trong những căng thẳng lớn là xây dựng các mô hình dữ liệu và đảm bảo rằng các cơ sở dữ liệu sẽ lưu trữ thông tin chính xác và đầy đủ. Một mặt, chúng tôi muốn các mô hình dữ liệu phải nghiêm ngặt để có thể tin rằng sẽ chỉ có các mã bưu chính chín chữ số trong trường Zip code mà thôi. Mặt khác, chúng tôi muốn các mô hình linh hoạt để chúng tôi có thể phù phép cho ai đó đăng ký từ Canada, nơi mã bưu chính là một hỗn hợp gồm chữ và số, nhưng theo một khuôn mẫu rất nghiêm ngặt. Việc lặp đi lặp lại trên các mô hình này sẽ mất thời gian.

Chúng tôi cần cấu trúc để chúng hoạt động – nhưng những thay đổi có thể làm mất hiệu lực của cấu trúc. Nó là một trận chiến không hồi kết. Sức mạnh là có một mục nhập tên cho mỗi người. Nhưng một khi bạn thừa nhận rằng bạn muốn theo dõi một người khi người đó thay đổi tên, thì lại thành ra có hai mục nhập. Và sau đó ta thấy điều này vừa thừa thãi vừa thiếu sót cùng lúc.

Các sai lầm phát sinh

Một số lập trình viên muốn lập danh mục các câu lệnh đơn giản có vẻ đúng cho đến khi cố gắng đưa chúng vào code. Những sai lầm này bao gồm các câu như, “Có 24 giờ trong một ngày.” Điều đó có vẻ hiển nhiên, ngoại trừ những ngày thuộc Qui ước giờ mùa hè. Những ngày đó thay đổi mỗi năm và hoàn toàn khác nhau ở châu Âu. Nói cách khác, một ngày có thể có 24 giờ trên lục địa này nhưng lại là 25 giờ trên lục địa khác.

Bạn gần như sẽ luôn khám phá ra một số sai lầm mới để thêm ghi chú lại qua từng dự án. Chúng tôi chỉ có thể hy vọng rằng những lỗi mới sẽ dễ dàng xử lý và người dùng không quá tức giận khi họ gập phải một trong những mâu thuẫn đó.

Sự phức tạp làm hỏng mọi thứ

Các lập trình viên muốn tinh giản các hệ thống mà họ làm việc nhưng người dùng và các bên liên quan muốn “cải thiện” hệ thống bằng cách thêm các case và các tính năng bổ sung để chạy theo giá trị kinh doanh. Có thêm tính năng thì tốt, nhưng thêm các tính năng thông minh và tốt hơn có nghĩa là phải tăng thêm tính logic, và đôi khi sự phức tạp của logic sẽ bùng nổ theo cấp số nhân.

Một số tính năng rất dễ bổ sung nhưng một số tính năng đi cùng những hậu quả không lường trước được, chúng có thể châm ngòi cho những bất ngờ kỳ lạ dẫn đến các cuộc họp không báo trước để đưa ra các quyết định mà bạn không bao giờ tưởng tượng là mình sẽ nghĩ tới. Nếu bạn không cẩn thận về việc thêm một lớp khác vào code của bạn hoặc một cột bổ sung khác vào cơ sở dữ liệu, bạn có thể sẽ ngạc nhiên khi sự phức tạp của dự án bùng nổ và bạn sẽ cách xa vạch đích hơn cả ngày hôm qua nữa.

Đánh giá thiết kế dẫn tới những tính năng kì quặc

Đánh giá thiết kế là một phần thiết yếu của quy trình phát triển, mọi người đều muốn phần mềm của họ làm được nhiều thứ hơn và do đó họ thích thêm các yêu cầu tính năng vào các cuộc họp với mục đích đánh giá thiết kế. Đôi khi có thể từ chối các yêu cầu rõ ràng nằm ngoài phạm vi của dự án hiện tại, nhưng thật không may, có rất nhiều yêu cầu dường như vô hại nhưng đòi hỏi phải viết lại rất nhiều code. Đôi khi có thể mất vài giờ xem xét lại code chỉ để tìm hiểu xem nó có phải là một trong những case dễ hay là một trong những case khó.

Nhưng chúng ta có thể tránh việc xem xét thiết kế với những thành viên liên quan. Nó là một phần của quy trình phát triển tốt. Vì vậy, chúng tôi bị quy chụp là dây dưa với code để cố gắng quyết định những gì chúng tôi có thể thêm và những gì chúng tôi sẽ chừa lại cho phiên bản 2.0 hoặc có thể là phiên bản 5.0.

Chậm hơn mà chắc

Mặc dù bạn có thể tức giận khi tiến độ dự án chậm, nhưng bản chất chậm chạp của việc phát triển phần mềm không phải là lỗi – đó là một tính năng. Vội vã thông qua những việc quan trọng chính là một cách đảm bảo rằng công việc đó sẽ bị thiếu sót và mắc lỗi. Khi các lập trình viên có thời gian, chúng tôi đảm bảo rằng nền tảng sẽ vững chắc và tính logic sẽ được xem xét kỹ lưỡng và thấu đáo. Phàn nàn về tốc độ chỉ làm chúng tôi mất tập trung vào công việc đã được chỉ định, đưa thêm rủi ro vào dự án mà thôi. Hãy để chúng tôi tập trung vào công việc.

Chia sẻ bài viết ngay

Nguồn bài viết : https://www.cio.com