Qui trình cho dự án phần mềm
Tuần trước, một người bạn có sở hữu một công ti phần mềm gọi điện thoại cho tôi: “Sau khi làm việc cho một công ti phần mềm trong sáu năm, tôi bắt đầu công ti riêng của tôi. Tôi tuyển những sinh viên tốt nghiệp hàng đầu và trả lương hậu cho họ, tôi có một số khách hàng và công ti của tôi phát triển nhanh chóng. Tuy nhiên, hiện thời chúng tôi có vấn đề với lỗi nhiều và trượt lịch biểu. Nếu những vấn đề này tiếp tục, công ti của tôi sẽ lâm vào rắc rối. Là người chủ, tôi thường dành hầu hết thời gian của mình với khách hàng để đưa vào việc kinh doanh mới cho nên làm sao tôi có thể sửa được những vấn đề này và tiếp tục phát triển công ti của tôi?”
Tôi nói với ông ấy: “Ông không thể bỏ qua các vấn đề bằng việc dành thời gian cho khách hàng và để mọi người làm việc mà không có giám sát nào. Việc sửa lỗi yêu cầu phần lớn thời gian của người phát triển và có lẽ nó là lí do chính cho việc trượt lịch biểu. Điều khẩn thiết cần làm bây giờ là hội tụ vào việc tìm và sửa lỗi. Tôi nghĩ ông cần tiến hành kiểm điểm thường xuyên hơn để nhận diện và sửa chúng sớm nhất có thể được. Trong các cuộc kiểm điểm này, ông phải để mọi người phát triển và người kiểm thử tới và biết cách lỗi đã bị phạm phải thế nào và làm sao sửa được chúng.”
Ông ta hỏi: “Sao lại mọi người? Tôi không để người không làm việc trong cùng dự án tham dự họp kiểm điểm được. Điều đó là phí thời gian.”
Tôi giải thích: “Về căn bản, những người phát triển trong dự án đều có kiểm điểm giữa họ để tìm và sửa lỗi. Đây là những lỗi ‘không biết” với người phát triển khác, người đã không tham dự buổi kiểm điểm và họ có thể phạm phải cùng sai lầm lần nữa. Lí do cho “kiểm điểm dành riêng” là người phát triển không muốn người khác tìm ra lỗi của họ. Tuy nhiên, là người chủ công ti, ông phải coi kiểm điểm như quá trình học tập cho nên mọi lỗi được tìm ra đều là cơ hội học tập. Người phát triển càng biết nhiều về nguyên nhân của lỗi, càng dễ tránh phạm phải chúng.
Ông ấy dường như thoả mãn: “Được, tôi có thể bắt đầu bằng kiểm điểm và để mọi người phát triển tới và học. Tôi có thể làm cái gì khác?”
Tôi tiếp tục: “Dự án phần mềm điển hình bắt đầu với ít người, rồi khi nó tiến triển, ông thêm người cho nó. Phần lớn các môn quản lí dự án bao giờ cũng dạy cách tiếp cận dần dần và nó có tác dụng tốt với doanh nghiệp xây dựng. Ông chỉ cần vài nhà kiến trúc lúc ban đầu nhưng khi các pha kiến trúc và thiết kế được thực hiện rồi, công ti đem nhiều công nhân vào xây dựng. Tuy nhiên, với dự án phần mềm cách tiếp cận này không có tác dụng tốt. Sẽ là tốt hơn nếu ông có thể bắt đầu với đầy đủ cán bộ từ đầu.”
Ông ấy ngạc nhiên: “Sao chúng tôi cần nhiều người hơn ngay từ những pha đầu? Điều đó sẽ tốn nhiều tiền hơn.”
Tôi giải thích: “Đó là lí do tại sao nhiều dự án phần mềm có vấn đề. Ông bắt đầu chỉ với ít người làm việc với yêu cầu của khách hàng và rồi họ hiểu điều gì phải làm. Rồi họ bắt đầu kiến trúc và thiết kế hệ thống. Vì họ làm việc trên dự án từ đầu, họ hoà hợp tốt. Khi ông thêm nhiều người vào dự án về sau, người mới không có thời gian để biết lẫn nhau hay hình thành cách làm việc tổ hiệu quả. Xung đột cá nhân có thể xảy ra trong thời gian này. Người mới không có thời gian hiểu yêu cầu nhưng họ phải thiết kế và viết mã ngay lập tức.”
“Họ có thể không biết cách tích hợp công việc của họ với kiến trúc hệ thống. Họ có thể không hiểu chức năng chi tiết của hệ thống nhưng họ phải làm cho việc của mình được thực hiện trong lịch biểu bị giới hạn. Đây là chỗ nhiều sai lầm bị phạm phải. Người mới được mong đợi hình dung ra mọi thứ theo cách riêng của họ trong thời gian rất ngắn. Tất nhiên, họ có những câu hỏi và họ phải hỏi người khác, nhưng người có đó từ lúc bắt đầu để giúp. Điều này có thể làm gián đoạn công việc dự án bởi vì thời gian để dạy người mới về dự án bao giờ cũng mất lâu hơn mong đợi, cho nên dự án có thể bị chậm. Do sức ép lịch biểu, mọi người phải vội vàng làm cho việc của mình được thực hiện và nhiều lỗi bị phạm phải.”
Ông ấy gật đầu: “Tôi chưa bao giờ nghĩ về điều đó, ông có thể đúng. Có những vấn đề giữa người mới và người cũ, họ tranh cãi mọi lúc. Tôi cần làm gì khác?”
Tôi bảo ông ấy: “Vòng đời phần mềm truyền thống là cách tiếp cận tuần tự giống như dây chuyên lắp ráp trong công nghiệp. Trước hết, kĩ sư yêu cầu làm việc với khách hàng để làm tài liệu cho tất cả các yêu cầu. Kiến trúc sư hệ thống sẽ hình dung ra cách hệ thống làm việc dựa trên các yêu cầu này. Thế rồi người phát triển sẽ thiết kế và rồi viết mã. Tiếp đó, người kiểm thử sẽ kiểm thử chúng. Sau khi tất cả kiểm thử đã được hoàn thành, sản phẩm phần mềm được đưa ra cho khách hàng. Chúng ta hãy nhìn lại cách tiếp cận này. Kĩ sư yêu cầu chỉ quan tâm tới điều khách hàng cần và hội tụ vào việc làm tài liệu cho chúng. Kiến trúc sư đặt mọi thứ dựa trên tài liệu yêu cầu và thiết kế hệ thống. Người phát triển hội tụ phần lớn vào viết mã dựa trên thiết kế. Người kiểm thử không chăm nom tới cách toàn thể hệ thống được thiết kế mà chỉ vào các trường hợp kiểm thử, nơi kiểm xem mã có qua được kiểm thử hay không. Điều gì sẽ xảy ra khi yêu cầu sai? Điều gì sẽ xảy ra nếu thiết kế bị thiếu chức năng nào đó? Điều gì sẽ xảy ra khi người kiểm thử kiểm vào các mã mà không được làm tài liệu trong tài liệu yêu cầu? Điều gì sẽ xảy ra nếu có những chức năng mới được thêm vào trong các phút cuối. Nếu người kiểm thử không biết về chức năng mới, họ không thể kiểm thử được nó. Đó là lí do cho cách tiếp cận kiểu dây chuyền lắp ráp này thực sự không có tác dụng tốt với phần mềm. Vòng đời thác đổ là tốt cho giảng dạy, nó dễ hiểu nhưng nó không có tác dụng tốt trong công nghiệp.
Bạn tôi ngần ngại một chốc: “Đó là điều chúng tôi vẫn làm sao? Ông gợi ý gì để chúng tôi làm khác đi?”
Tôi giải thích: “Đó là lí do tại sao đào tạo kĩ nghệ phần mềm yêu cầu rằng công ti phải xác định qui trình phát triển tích hợp đầy đủ mọi thành viên tổ sớm nhất có thể được. Qui trình được xác định không phải là một hoạt động theo chuỗi mà là tăng dần với mọi vai trò được tích hợp đầy đủ. Nó rất quan trọng để bắt đầu với đầy đủ cán bộ hay ít nhất với đa số người lúc ban đầu. Người quản lí dự án phải thảo luận về vai trò, trách nhiệm của từng thành viên tổ và điều từng người cần làm để thành công. Đào tạo làm việc theo tổ lúc bắt đầu sẽ tạo ra một số các thảo luận, nơi các thành viên tổ có thể nói về điều họ cần từ nhau. Rồi tổ trình bày nhu cầu của họ, quan điểm của họ với người quản lí dự án. Sau vài tuần đầu trong dự án, tổ có thể đi tới qui trình mà mọi người đều biết nhiệm vụ của họ là gì, và cách để làm việc với chúng. Thông tin này nên được làm tài liệu như một phần của qui trình tổ dự án nơi mọi người đều biết ưu tiên dự án là gì, và cách ra quyết định để thoả mãn nhu cầu dự án.
Bạn tôi hỏi: “Sao ông cần vài tuần đầu để xây dựng dự án? Có quá nhiều không?”
Tôi trả lời: “Làm việc theo tổ là hoạt động quan trọng nhất trong dự án phần mềm. Ông không thể mong đợi rằng những người không biết lẫn nhau sẽ hài hoà với nhau trong vài ngày. Họ cần thời gian để biết lẫn nhau và đi tới qui trình được xác định mà mọi người sẽ đồng ý tuân theo. Thay vì qui trình tuần tự, ông nên yêu cầu tổ phát triển một qui trình song hành để xây dựng phần mềm. Chẳng hạn, kiến trúc sư xác địnhg kiến trúc tổng thể của sản phẩm phần mềm, xác định các tính năng cho từng bản đưa ra và tiến hành kiểm điểm ban đầu nơi mọi thành viên tổ cần phải tham dự. Đây là lúc mọi người nên thực sự học về khía cạnh kĩ thuật và hỏi các câu hỏi nếu cần. Sau kiểm điểm ban đầu, nhóm những người phát triển sẽ bắt đầu thiết kế ngay lập tức khi nhóm khác làm việc trên kiểm thử hệ thống. Sau thiết kế, tổ phải tiến hành kiểm điểm thiết kế cùng với toàn tổ và nhóm kiểm thử phải chắc chắn rằng kiểm thử hệ thống của họ sẽ làm việc tốt với thiết kế này. Nếu mọi sự tốt lành, thì tổ có thể bắt đầu thiết kế chi tiết và thực hiện, đồng thời nhóm kiểm thử sẽ làm việc trên việc phát triển các kiểm thử chức năng. Mọi pha đều phải có kiểm điểm với sự tham dự của toàn tổ để chắc chắn họ phối hợp các hoạt động của mình và công việc của họ được tích hợp đầy đủ. Đến lúc mã được viết ra và kiểm thử (đơn vị được kiểm thử), mọi người sẽ sẵn sàng cho kiểm điểm mã. Mọi mã đều phải trải qua kiểm điểm trước khi được đưa vào hệ thống quản lí cấu hình. Sau khi mã được kiểm, người kiểm thử sẽ bắt đầu kiểm và bất kì lỗi nào được nhận diện đều phải được sửa theo qui trình thay đổi. Về căn bản, mọi thứ trong dự án đều phải tuân theo qui trình song hành được xác định tốt và người quản lí dự án phải dùng độ đo để trắc nghiệm mọi thứ. Lịch biểu dự án nên được dõi vết theo ước lượng gốc, mọi yêu cầu đều phải được quản lí, cũng như mọi lỗi. Bằng việc để mọi người tham gia sớm và giúp xác định qui trình, các thành viên tổ hiểu công việc của họ và những cột mốc chính. Họ biết điều họ cần làm từng tuần và trắc nghiệm công việc của họ lẫn nhau. Trong nỗ lực cộng tác này, các thành viên tổ có thể lưu ý khi vấn đề xuất hiện và có hành động sửa chữa thay vì chờ đợi cho tới pha sau. Nếu tổ tuân theo qui trình được xác định tốt, họ có thể cải tiến cách họ giải quyết các lỗi và việc trượt lịch, và cuối cùng mọi dự án sẽ được cải tiến.
Bạn tôi nói: “Vậy ông nghĩ làm việc tổ và qui trình là nhân tố mấu chốt cho cải tiến dự án à?”
Tôi bảo ông ấy: “Vâng, dứt khoát rồi. Qui trình phần mềm có thể có vẻ đơn giản nhưng chúng biểu thị cho thay đổi mạnh mẽ trong cách mọi người làm công việc của họ. Với làm việc theo tổ, mọi người nhận ra rằng công việc của họ là nỗ lực cộng tác nơi mọi thứ đều phải được tích hợp. Đây là chìa khoá cho thành công của mọi công việc phát triển, không ai làm việc một mình. Với kỉ luật kĩ nghệ phần mềm, họ sẽ biết phải làm gì và làm gì tiếp. Có kỉ luật là bước đầu tiên để phát triển công ti của ông. Bên cạnh những qui trình kĩ thuật này, ông có thể cải tiến qui trình quản lí của ông nữa. Chừng nào chưa có qui trình phát triển được được xác định tốt, sẽ khó mà biết ai đang làm gì hay ai là tốt và ai không tốt. Qui trình được xác định tốt cho phép người quản lí dự án hiểu công việc phát triển và vai trò, trách nhiệm của từng thành viên tổ. Điều này cho người quản lí cơ hội làm việc với những người có công việc không chấp chấp nhận được, và thưởng cho những người hoàn thành công việc xuất sắc.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
