Scrum kết hợp CMMI 5: Liều thuốc thần cho các chiến binh phần mềm

Các dự án kết hợp phương pháp Agile với CMMI thành công hơn trong việc tạo ra phần mềm chất lượng cao hơn, đáp ứng nhu cầu khách hàng tốt hơn với tốc độ nhanh hơn. Công ty Systematic Software Engineering đã đạt được CMMI cấp độ 5 và dùng Phát triển phần mềm tinh gọn làm phương pháp tối ưu hóa quy trình phần mềm. Những dự án thử nghiệm ban đầu cho thấy năng suất của các nhóm Scrum cao gấp đôi so với các nhóm truyền thống. Những dự án làm theo phương pháp kiểm thử theo Story giảm 40% số lỗi trong lần kiểm thử cuối cùng.

Chúng tôi khẳng định Scrum kết hợp với CMMI tạo thành một tổ hợp với khả năng dự đoán và thích ứng mạnh mẽ hơn từng quy trình riêng lẻ và đưa ra cách giúp các công ty kết hợp chúng như dưới đây.

Scrum kết hợp CMMI 5 – Phần 2

1. Giới thiệu

Việc phát triển phần mềm thành công đòi hỏi phải có khả năng quản lý được: sự phức tạp, việc đổi mới công nghệ, và những thay đổi yêu cầu. Hai phương pháp Agile và CMMI đều đề cập đến những đòi hỏi này nhưng có những góc nhìn và cách tiếp cận rất khác biệt.

Quản lý sự phức tạp yêu cầu kỉ luật trong quy trình, trong khi quản lý thay đổi thì yêu cầu khả năng thích ứng. CMMI cung cấp kỷ luật trong quy trình, còn Scrum nâng cao khả năng thích ứng. Tài liệu này phân tích hiệu quả của việc đưa các kỹ thuật (practice) Agile vào một công ty có CMMI cấp độ 5.

1.1. CMMI

Mô hình năng lực trưởng thành(CMM – Capability Maturity Model) đã tồn tại từ năm 1991, là một mô hình dựa trên những kỹ thuật thực hành tốt nhất (best practices) trong phát triển phần mềm. CMM đưa ra một phương pháp cách mạng để cải tiến một tổ chức từ lúc chưa trưởng thành và không có quy trình trở thành tổ chức trưởng thành và kỷ luật [1]. CMM được phát triển bởi Học viện Kỹ Nghệ Phần Mềm tại ĐH Carnegie Mellon của Mỹ và đã được công nhận trên toàn thế giới.

Năm 2002, một phiên bản mở rộng đáng kể có tên CMMI được công bố, với chữ ‘I’ là viết tắt của ‘‘Integration”(Tích hợp). Năm 2006, phiên bản 1.2 của mô hình CMMI được công bố [2]. Mô hình này tích hợp các quy tắc của kỹ nghệ phần mềm, kỹ nghệ hệ thống, và các kỹ thuật trong thu mua phần mềm vào một mô hình trưởng thành. CMMI định nghĩa 25 vùng quy trình cần triển khai. Mỗi loại cần định nghĩa ra các mục tiêu, các Phương pháp thực thi nên có, và các Phương pháp thực thi phụ khuyên dùng. Thêm vào đó, tất cả các quy trình đều tuân theo một bộ Phương pháp thực thi chung (Generic Practices).

Thực tế đã cho thấy một công ty có CMM hoặc CMMI cấp cao hơn thì có khả năng cao hơn trong việc chuyển giao đúng lịch, đúng chi phí và đạt chất lượng đúng thỏa thuận. Càng ngày, ngành phần mềm càng yêu cầu các công ty phải có CMM/CMMI cấp 3 hoặc cao hơn. Một số tổ chức chính phủ trên thế giới đã chính thức đưa ra yêu cầu về cấp độ CMMI. Ví dụ, Bộ Khoa học Đan Mạch mới đây đưa ra quy định các tổ chức công phải yêu cầu các công ty cung ứng đưa ra tài liệu về cấp độ CMMI [4].

🔰Khai Giảng Khoá Đào Tạo ScrumMaster Chứng Chỉ CSM

1.2. Scrum

Các nhóm phát triển phần mềm bắt đầu dùng Scrum tại công ty Easel năm 1993 [5] và Scrum trở thành một phương pháp chính thức tại OOPSLA năm 1995 [6]. Nhu cầu về một quy trình phát triển giúp một nhóm phát triển lập tức tạo ra chức năng chạy được từ bản thiết kế trực quan và những vấn đề cố hữu căn bản của phát triển phần mềm đã thúc đẩy sự ra đời của Scrum:

Sự thay đổi là cố hữu và luôn xảy ra trong các quy trình phát triển phần mềm và các sản phẩm – Nguyên lý bất định của Ziv [7]
Với một hệ thống phần mềm mới, các yêu cầu sẽ không hoàn toàn được xác định rõ cho đến sau khi người dùng sử dụng nó. – Nguyên lý yêu cầu bất định của Humphrey [8]
Không thể hoàn toàn định rõ các chi tiết của một hệ thống tương tác – Bổ đề Wegner [9]
Những yêu cầu hay thay đổi và không rõ ràng kết hợp với các công nghệ và công cụ liên tục tiến hóa khiến ta không thể dự đoán được các chiến lược để triển khai.

Các mô hình phát triển phần mềm kiểu “Tất-cả-cùng-một-lúc” đặc biệt phù hợp với cách làm phần mềm hướng đối tượng và giúp giải quyết những thách thức trên. Chúng giả định việc làm phần mềm cần thực hiện cùng lúc các giai đoạn lấy yêu cầu, phân tích, thiết kế,viết mã, và kiểm thử, sau đó chuyển giao toàn bộ hệ thống cùng lúc [10].

Sutherland và Schwaber, đồng tác giả Scrum đã kết hợp cùng tác giả các quy trình Agile khác để viết bản tuyên ngôn Agile vào năm 2001 [11]. Cùng đồng thuận tập trung vào: phần mềm chạy tốt, tương tác nhóm, hợp tác với khách hàng và thích ứng với thay đổi như là các nguyên lý trung tâm cần thiết để tối ưu hóa chất lượng và năng suất phần mềm.

2. Hướng dẫn kết hợp CMMI và Agile

2.1. CMMI có thể cải thiện Agile như thế nào

Chúng tôi chú ý vào việc dùng CMMI để giúp một tổ chức thể chế hóa các phương pháp Agile. Việc áp dụng các phương pháp Agile có thể dần suy biến thành các hoạt động mẹo mực vô kỷ luật. Chúng tôi tin rằng chỉ có thể đạt được giá trị thực sự từ các phương pháp Agile thông qua kỷ luật. CMMI có một khái niệm về Thể chế hóa có thể giúp tạo ra kỷ luật cần thiết này.

Thể chế hóa được định nghĩa trong CMMI như: “cách làm việc mặc định mà công ty làm theo đều đặn và trở thành văn hóa công ty.” Thể chế hóa cũng có thể được miêu tả đơn giản kiểu “đây là cách chúng tôi làm việc ở đây”. Chú ý rằng thể chế hóa là một khái niệm ở cấp độ tổ chức dành cho nhiều dự án.

CMMI hỗ trợ thể chế hóa thông qua các Phương pháp thực thi chung (Generic Practices – GP ) liên quan đến tất cả các vùng quy trình. Để thảo luận, chúng ta sẽ xem xét 12 Phương pháp thực thi chung của CMMI cấp độ 2 và 3[14] và cách chúng giúp một tổ chức sử dụng các phương pháp Agile. Chúng tôi sẽ diễn giải các Phương pháp thực thi chung (chữ in đậm) ứng với cách chúng tôi khuyên dùng các phương pháp Agile. Theo quy định của CMMI, những dự án của một tổ chức phải có các hoạt động để đáp ứng các Phương pháp thực thi chung này. Chúng tôi dùng Scrum như một phương pháp Agile mẫu để miêu tả các hoạt động liên quan đến những Phương pháp thực thi này.

2.1.1. Thiết lập và duy trì chính sách cho việc lên kế hoạch và triển khai các phương pháp Agile (GP 2.1).

Bước đầu tiên tiến tới thể chế hóa các phương pháp Agile là thiết lập thời điểm và cách mà chúng được dùng trong tổ chức. Một tổ chức có thể quyết định rằng các phương pháp Agile sẽ được dùng trong tất cả các dự án hoặc vài phần nhỏ của dự án tùy theo kích cỡ, loại sản phẩm, công nghệ hay các yếu tố khác. Chính sách này là một cách để nêu rõ ý định của tổ chức đối với các phương pháp Agile. Để đáp ứng nguyên lý Agile về yêu cầu mặt đối mặt, chính sách có thể được giới thiệu tại một cuộc họp đầy đủ hoặc khi một quản lý cấp cao tham gia cuộc họp khởi động một dự án mới.

2.1.2. Thiết lập và duy trì kế hoạch triển khai các phương pháp Agile (GP2.2).

Phương pháp thực thi này có thể giúp đảm bảo các phương pháp Agile không bị suy biến thành các mẹo mực vô kỷ luật. Giúp các phương pháp Agile được lên kế hoạch, tạo ra một quy trình và quy trình đó được tuân theo. Quy trình này nên có các bước miêu tả về điều mà dự án thực sự làm bằng lượng thông tin tối thiểu. Kế hoạch cũng nên miêu tả những vấn đề thiết yếu về cách triển khai 10 Phương pháp thực thi chung còn lại trong dự án. Trong Scrum, vài phần trong kế hoạch này được miêu tả trong Product backlog và/hoặc trong Sprint backlog, thường để trong một công cụ chứ không phải trong một tài liệu.

2.1.3. Cung cấp đầy đủ nguồn lực để triển khai các phương pháp Agile (GP 2.3).

Mọi dự án đều muốn, cần và kỳ vọng có những chuyên viên lành nghề, đầy đủ ngân sách, và những công cụ, phương tiện thích hợp. Việc dành riêng một hoạt động để quản lý rõ ràng những nhu cầu và mong muốn này đã được chứng minh là hữu ích. Ví dụ, trong Scrum, những nhu cầu này có thể được xem xét và chỉ ra tại buổi họp Lập kế hoạch Sprint và Sơ kết Sprint, và được xem xét lại nếu có những thay đổi lớn.

🔰 DevOps Professional – Nâng cao hiệu suất rút ngắn thời gian phát triển

2.1.4. Phân công trách nhiệm và quyền hạn triển khai các phương pháp Agile (GP 2.4).

Muốn dự án thành công, cần định nghĩa các quyền hạn và trách nhiệm một cách rõ ràng. Điều này thường gồm giao việc kết hợp với miêu tả vai trò. Với mỗi vai trò chỉ rõ mức quyền hạn và trách nhiệm. Ví dụ, một dự án Scrum nên gán một người/nhóm người làm vai trò của Product Owner, ScrumMaster và Nhóm phát triển. Chuyên môn trong nhóm thường gồm các: Chuyên gia nghiệp vụ, Kỹ sư nghệ thống, Kỹ sư phần mềm, Kiến trúc sư, Lập trình viên, Nhà phân tích, Chuyên gia QA, Kiểm thử viên, Nhà thiết kế giao diện, v.v. Scrum gán cho toàn bộ nhóm trách nhiệm chuyển giao phần mềm chạy tốt. Product Owner có trách nhiệm chỉ rõ và xếp ưu tiên các công việc. ScrumMaster có trách nhiệm đảm bảo quy trình Scrum được tuân thủ. Quản lý có trách nhiệm cung cấp đầy đủ chuyên gia cho nhóm.

2.1.5. Đào tạo những người triển khai các phương pháp Agile (GP 2.5).

Đào tạo chính xác có thể tăng năng suất của những chuyên gia lành nghề và giúp ích cho việc áp dụng phương pháp mới vào tổ chức. Thể chế hóa phương pháp Agile yêu cầu một quá trình đào tạo. Phương thức thực thi này bao gồm quyết định những người cần đào tạo, xác định chính xác nhu cầu đào tạo và triển khai đào tạo cho nhu cầu đó. Đào tạo có thể được cung cấp bằng nhiều cách, gồm những hướng dẫn được lập trình sẵn, đào tạo trong công việc chính thức, cố vấn, đào tạo chính quy theo trường lớp. Một lưu ý quan trọng là cần phải định rõ cơ chế để đảm bảo việc đào tạo thực sự diễn ra và có ích.

2.1.6. Xếp các sản phẩm công việc(work product) vào cấp độ quản lý cấu hình tương ứng (GP 2.6).

Mục đích của mỗi dự án là tạo ra (những) sản phẩm chuyển giao được. Sản phẩm này thường là tập hợp của các sản phẩm công việc hỗ trợ hoặc trung gian (mã, sách hướng dẫn, hệ thống phần mềm, build file, v.v.). Mỗi sản phẩm công việc này có giá trị nhất định và thường trải qua nhiều bước để tăng giá trị của mình. Khái niệm quản lý cấu hình được dùng để bảo vệ giá trị của những sản phẩm công việc này bằng cách định ra cấp độ quản lý, ví dụ: quản lý phiên bản, quản lý baseline hoặc quản lý baseline đa mức để dùng trong dự án.

2.1.7. Xác định và phối hợp với các bên liên quan theo kế hoạch (GP 2.7).

Đòi hỏi khách hàng trở thành một bên liên quan là thế mạnh của các phương pháp Agile. Phương pháp thực thi này xác định chính xác hơn đòi hỏi này để đảm bảo các bên liên quan phối hợp đầy đủ như mong đợi. Ví dụ, nếu dự án phụ thuộc vào phản hồi của khách hàng về từng phân đoạn, bản build, hay Sprint và khách hàng phối hợp chưa đủ, thì ta cần giao tiếp trong mức độ thích hợp (cá nhân hay nhóm trong tổ chức) để đảm bảo những công việc sửa sai được thực hiện, mà những việc sửa sai này có thể vượt quá phạm vi của nhóm dự án. Trước khi triển khai Scrum, điều này có thể được chính thức hóa như là một MetaScrum [17] nơi mà các bên liên quan đóng vai trò hội đồng quản trị cho Product Owner.

2.1.8. Giám sát và kiểm soát các phương pháp Agile theo đúng kế hoạch và thực hiện công việc sửa sai thích hợp (GP 2.8).

Phương pháp thực thi này liên quan đến việc đo lường năng suất thực tế để so sánh với kế hoạch dự án và thực hiện hoạt động sửa chữa. Giám sát trực tiếp mỗi ngày là thế mạnh của cuộc họp Scrum Hằng ngày, biểu đồ Burndown phát hành cho thấy còn lại bao nhiêu phần công việc khi bắt đầu mỗi Sprint, và biểu đồ Burndown Sprint cho thấy tổng số giờ làm việc còn lại mỗi ngày. Scrum giúp tăng hiệu quả của kế hoạch bằng cách cho phép Product Owner thanh tra và thích nghi để tối đa ROI, chứ không chỉ đảm bảo kế hoạch chính xác.

2.1.9. Đánh giá khách quan mức tuân thủ các phương pháp Agile và chỉ ra các sai phạm (GP 2.9).

Phương pháp thực thi này dựa trên cơ sở có một người không chịu trách nhiệm quản lý trực tiếp nhóm và không tham gia dự án đánh giá các hoạt động thực tế của dự án. Vài tổ chức triển khai Phương pháp thực thi này bằng cả hoạt động bảo đảm chất lượng và hoạt động huấn luyện. Khái niệm huấn luyện khớp với rất nhiều phương pháp Agile. ScrumMaster có trách nhiệm chính trong việc đảm bảo tuân theo các quy tắc Scrum, theo dõi tiến độ, loại bỏ các trở ngại, giải quyết các vấn đề cá nhân và thường không tham gia làm các tác vụ của dự án. Product Owner có trách nhiệm chính đảm bảo phần mềm đáp ứng đúng yêu cầu và có chất lượng cao.

2.1.10. Xem lại các hoạt động, trạng thái và kết quả triển khai các phương pháp Agile cùng ban quản lý cấp cao và giải quyết các vấn đề (GP 2.10).

Mục đích của phương pháp thực thi này là để đảm bảo quản lý cấp cao thấy rõ các công việc của dự án. Mỗi quản lý thì cần những thông tin khác nhau. Các phương pháp Agile có độ tương tác cao, ví dụ: Scrum có một cuộc họp Lên kế hoạch Sprint, các cuộc họp Scrum Hằng ngày, họp Sơ kết Sprint, và họp Cải tiến Sprint. Quản lý thấy được các thông tin cần thiết nhờ sự minh bạch của các dữ liệu được cập nhật trên biểu đồ Burndown Scrum cùng các dữ liệu về lỗi. Ban quản lý có trách nhiệm (1) đưa ra tầm nhìn chiến lược, chiến lược kinh doanh, và các nguồn lực, (2) loại bỏ các trở ngại nhóm Scrum không thể tự vượt qua,(3) đảm bảo sự phát triển và con đường phát triển sự nghiệp của nhân viên, và (4) thách thức nhóm Scrum vượt qua mức tầm thường. Danh sách các trở ngại của nhóm Scrum được minh bạch cho quản lý và trách nhiệm của họ là xóa bỏ chúng để nâng cao năng lực của tổ chức.

2.1.11. Thiết lập và duy trì mô tả về các phương pháp Agile (GP 3.1).

Phương pháp thực thi này là một phiên bản tinh chế của phương pháp thực thi GP 2.2 phía trên. Điều khác biệt duy nhất là mô tả các phương pháp Agile này nên phổ biến trong toàn bộ tổ chức chứ không chỉ ở trong một dự án. Việc này sẽ giúp giảm phân mảnh trong các phương pháp Agile được triển khai trong toàn tổ chức; nhờ đó sẽ dễ dàng chuyển đổi người, công cụ, thông tin và sản phẩm giữa các dự án.

2.1.12. Thu thập các kết quả thu được khi dùng các phương pháp Agile để hỗ trợ cho việc sử dụng sau này và cải thiện cách áp dụng các phương pháp Agile vào tổ chức (GP 3.2).

Phương pháp thực thi này hỗ trợ cho mục tiêu học hỏi từ nhiều dự án bằng cách thu thập kết quả từng dự án. Có thể dùng buổi họp Cải tiến Sprint của Scrum làm cơ chế thực hiện hoạt động này.
Tất cả các Phương pháp thực thi chung trên đều hữu ích khi tổ chức triển khai các qui trình khác. Chúng tôi thấy rằng một số Phương pháp thực thi chung hỗ trợ một phần cho Scrum hay các phương pháp Agile khác. Chúng tôi tin rằng thực hiện các Phương pháp thực thi này có thể giúp thiết lập kỷ luật cần thiết cho bất kì phương pháp Agile nào.

Scrum kết hợp CMMI 5: Liều thuốc thần cho các chiến binh phần mềm – P1