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

2.2. Những chỉ trích CMM

Trong nghiên cứu được chính phủ Đan Mạch tài trợ, Rose và cộng sự nghiên cứu những chỉ trích về CMM [18]. Họ thấy rằng phần lớn chỉ trích không phải về quy trình CMM mà là về hệ quả của việc tập trung vào quy trình.
Trong khi hệ quả phụ của tập trung vào quy trình chỉ đơn giản khiến kết quả triển khai CMM yếu kém thì những tổ chức với những quy trình nặng nề thường có xu hướng thực thi kém.

Cũng như những mô hình khác, có nơi triển khai CMM tốt, có chỗ kém. Chúng tôi tin rằng những nơi triển khai kém là một trong các lý do chính gây ra các chỉ trích tiêu cực về CMM. Những triển khai này thường có các đặc điểm như trong bảng dưới đây, ngược lại nhiều triển khai CMM tốt không gặp hầu hết các chỉ trích.

Một cách để tăng tỉ lệ thành công khi triển khai CMM hay CMMI là dùng Scrum. Dùng Scrum và Tư duy linh hoạt (Lean thinking) khi triển khai CMMI sẽ bảo đảm việc thực hiện tốt.

Chúng tôi công nhận các chỉ trích về CMM ở bảng dưới là có thực, nhưng với hiểu biết về những trường hợp triển khai CMMI tốt chúng tôi nghĩ rằng các chỉ trích này không chính xác. Tuy nhiên, một triển khai CMMI kém có thể gặp phải những vấn đề phía dưới. Dù có thể triển khai tốt CMMI mà không cần các phương pháp Agile, bảng phía dưới cho thấy Scrum giúp giải quyết tốt các vấn đề của các triển khai CMMI “tệ”.

Ngược lại, có những trường hợp triển khai Agile nhưng không đạt được những yêu cầu cơ bản trong các quy tắc của Scrum. Họ không đạt được những phân đoạn cố định, tfkhông chuyển giao được phần mềm chạy tốt đã được kiểm thử đầy đủ cuối mỗi Sprint. Product Owner có thể không được định rõ hoặc không chuyên trách.

Không có duy nhất một Product Backlog được xếp ưu tiên theo giá trị kinh doanh của công ty dẫn đến xung đột độ ưu tiên và lộn xộn trong tổ chức. Product Backlog có thể không được ước tính bởi nhóm, làm cho dự án trở thành không lường được, không hoàn thành đúng kỳ hạn, và vượt ngân sách. Nhóm có thể không duy trì một biểu đồ Burndown và không biết được vận tốc phát triển qua các Sprint. Điều này khiến cho Product Owner không thể dự đoán được ngày phát hành để cho vào kế hoạch phát hành. Một triển khai CMMI tốt có thể giúp giải quyết tất cả những trở ngại thường gặp này.

3. Scrum kết hợp CMMI: một lọ thuốc thần

Systematic là một công ty tư nhân phát triển các hệ thống phần mềm có hơn 400 nhân viên với văn phòng ở Đan Mạch, Mỹ, Phần Lan và Vương quốc Anh. Họ phát triển những hệ thống lớn được dùng trong quốc phòng, chăm sóc sức khỏe, sản xuất, và các ngành dịch vụ. Vào tháng 11 năm 2005 họ thông qua đánh giá SCAMPISM2 đạt được CMMI cấp độ 5.

Tại Systematic, các Phương pháp thực thi của CMMI 5 đã giảm 42% lượng công việc phải làm lại, giữ mức chênh lệch so với ước tính thấp hơn 10%, và đảm bảo 92% các mốc thời gian được chuyển giao sớm hơn hoặc đúng kỳ hạn. Trong khi làm giảm đáng kể lượng công việc bị đội lên trong các dự án.

Quan trọng hơn, Systematic đã chuyển đổi hơn 20 năm kinh nghiệm thành một bộ thống nhất các quy trình để tất cả các dự án phần mềm sử dụng. Dữ liệu lịch sử được thu thập có hệ thống và phân tích để liên tục cung cấp thông tin về năng lực và hiệu suất của tổ chức.

Việc dùng chung một quy trình khiến mọi người dễ dàng chuyển từ dự án này sang dự án khác và chia sẻ kinh nghiệm cũng như những bài học qua mỗi dự án. Chúng tôi cũng so sánh năng suất của các quy trình mới với các quy trình cũ và tạo ra nền móng để cải tiến liên tục.

Tóm lại, Systematic có thể chuyển giao điều khách hàng yêu cầu theo đúng lịch, chi phí và chất lượng mà chỉ cần 69% nguồn lực so với một công ty CMMI cấp độ 1 [12,13]. Hình 2 phía trên cho thấy bằng việc thay thế một số quy trình lõi bằng Scrum giúp chi phí giảm thêm 34%, giảm riêng phần quy trình hơn 50% và giảm lỗi 40%.

CMMI 5 ngày càng được nhiều khách hàng yêu cầu và trở thành chìa khóa để nhận được những hợp đồng lớn, đặc biệt trong ngành quốc phòng và y tế. Khách hàng nhận thấy CMMI 5 mang lại sản phẩm được thiết kế kĩ thuật tốt hơn và dễ kiểm soát hơn cho việc mở rộng, bảo trì, thích nghi và ổn định.

CMMI cho ta biết cần những quy trình gì để duy trì một tổ chức trưởng thành có kỉ luật, có khả năng dự đoán và cải thiện năng lực của tổ chức và các dự án. Scrum đưa ra hướng dẫn để quản lý hiệu suất của các dự án theo cách rất mềm dẻo và có khả năng thích ứng cao. Khi kết hợp 2 phương pháp sẽ tạo thành một liều thuốc thần, trong đó tư duy của Scrum đảm bảo rằng các quy trình được triển khai hiệu quả trong khi chào đón các thay đổi, còn CMMI đảm bảo không bỏ sót bất kì quy trình cần thiết nào.

CMMI hay Scrum đều được công nhận có hiệu quả khi áp dụng nhưng cũng có những vấn đề tiềm ẩn. Một công ty Agile dù đã triển khai Scrum chuẩn nhưng vẫn thất bại không đạt được hiệu quả mong muốn do thiếu thể chế hóa hay do thiếu các quy trình quản lý, thiết kế. CMMI có thể giúp các công ty Agile thể chế hóa các phương pháp Agile dễ dàng hơn và chỉ ra quy trình nào cần cải thiện.

Với những công ty làm theo CMMI nhưng không đạt được hiệu quả tối ưu do không thực thi tốt quy trình, Scrum và các phương pháp Agile khác có thể giúp các công ty thực thi hiệu quả hơn các yêu cầu về quy trình của CMMI.

3.1. Kinh nghiệm “Tinh gọn” của Systematic

Systematic đã ra một quyết định chiến lược là dùng Lean(Tinh gọn) làm mô hình chủ chốt cho các cải tiến tương lai sau khi đạt được CMMI 5. Lean đã cho thấy những kết quả đáng chú ý qua nhiều năm trong những lĩnh vực như sản xuất ô tô, và đã tương thích với những lĩnh vực khác, gồm cả phát triển phần mềm và phát triển sản phẩm. Systematic thấy rằng Phát triển phần mềm tinh gọn [15] là phiên bản Lean thích hợp nhất cho Systematic.

Dùng Phát triển phần mềm tinh gọn làm trình điều khiển để cải tiến cho công ty có CMMI 5, áp dụng tư duy của Agile và Lean vào triển khai các quy trình CMMI, ngoài ra Systematic còn đặc biệt chú trọng triển khai chuyển đổi sang Lean theo tinh thần của tuyên ngôn Agile.

Năng lực thực thi Lean được hình thành thông qua việc đọc sách, đào tạo chính quy và phi chính quy, các hoạt động đi-và-nói. Các quản lý dự án được đào tạo về Phát triển phần mềm tinh gọn, Mary Poppendieck đã tới công ty Systematic trình bày một hội thảo về Phát triển phần mềm tinh gọn.

Hội thảo này đã củng cố hiểu biết về tư duy của Agile và Lean. Carsten Jakobsen – chuyên gia chuyển đổi Lean – đã phân tích các phụ thuộc nhân quả giữa các nguyên lý và công cụ trong Phát triển phần mềm tinh gọn và tạo ra mô hình như trong Bảng 1.

Mô hình này nhóm các công cụ tư duy từ Phát triển phần mềm tinh gọn thành các nhóm: Kỹ thuật, Quản lý và Con người. Hơn nữa các thành phần được sắp xếp theo các phụ thuộc nhân quả, các thành phần ở bên phải phụ thuộc vào một hoặc nhiều thành phần bên trái. Những phụ thuộc này được đơn giản hóa thành 4 pha: Giá trị, Luồng, Kéo và Hoàn hảo. Mô hình tạo ra một cách để xếp thứ tự những công cụ tư duy cần tập trung vào, giúp thấy những công cụ bắt đầu.

Tuy nhiên đầu vào quan trọng nhất là một phân tích chỉ ra các cơ hội cải tiến có tỉ lệ lợi nhuận – chi phí ước tính cao. Nghiên cứu nội bộ trong Systematic cho thấy chi phí sửa một lỗi tăng từ 1,6 tiếng khi phát hiện trong giai đoạn viết mã, lên đến 12 tiếng khi phát hiện trong giai đoạn kiểm thử và 23.7 tiếng khi phát hiện trong giai đoạn bảo trì. Cần ưu tiên cải tiến điều này bằng cách loại bỏ lỗi hoặc phát hiện lỗi sớm hơn. Chúng tôi cũng thấy rằng khi tập trung vào chất lượng dần dần làm thời gian kiểm thử tăng lên khiến cho thời gian hoàn thành có xu hướng tăng lên. Mà từ khía cạnh giá trị kinh doanh thì thời gian hoàn thành càng rút ngắn càng tốt.

3.2. Kinh nghiệm của Systematic từ những lần thử nghiệm

Sau khi phân tích các phương án cải tiến và các phụ thuộc nhân quả của Lean, Systematic quyết định cải tiến dựa vào các nguyên lý sau của Phát triển phần mềm tinh gọn: Build Integrity In, Amplify Learning và Deliver Fast.

Các công cụ tư duy tinh gọn thúc đẩy chúng tôi dùng Scrum và kiểm thử sớm. Trong khoảng 4 tháng, hai dự án nhỏ và hai dự án lớn đã thử áp dụng Scrum và kiểm thử sớm theo story.

3.2.1. Scrum

Dự án thử nghiệm đầu tiên, Systematic được truyền cảm hứng từ các nguyên lý của Lean, đưa ra một kế hoạch chuyển giao mỗi 2 tuần. Những dự tính cụ thể để phối hợp với khách hàng và nhận các phản hồi được đặt ra. Dự án có 4 thành viên và phát triển phần mềm cho một khách hàng thuộc chính phủ Đan Mạch.

Một trong những lý do chính giúp Systematic giành được hợp đồng là cam kết chuyển giao phần mềm chạy được mỗi 2 tuần và đưa ra một quy trình minh bạch cho khách hàng. Trong thời gian thực hiện dự án, một tần suất giao tiếp lớn được giữ giữa nhóm, khách hàng và người dùng cuối. Đây là một trong những lý do chính làm khách hàng hài lòng.

Kế hoạch chuyển giao liên tục và phối hợp với khách hàng đã giúp sớm phát hiện các vấn đề kĩ thuật. Nếu làm theo cách truyền thống thì những vấn đề này sẽ được phát hiện muộn hơn rất nhiều và ảnh hưởng xấu đến chi phí và thời hạn hoàn thành.

Năng suất của dự án nhỏ này đạt được tiêu chuẩn của công ty về năng suất của các dự án nhỏ. Một dự án nhỏ dùng Scrum khác với nhóm 5 thành viên làm việc cho một khách hàng bên quân sự cho thấy năng suất tương đương và cũng đạt được chất lượng cao và khách hàng hài lòng.

Tại Systematic, năng suất của một dự án được định nghĩa bằng cách chia tổng số dòng mã cho tổng số giờ của dự án. Dữ liệu được chuẩn hóa theo từng ngôn ngữ lập trình và loại mã: mã mới, dùng lại mã, hay mã kiểm thử.

Systematic duy trì một mốc năng suất (productivity performance baseline – PPB) từ dữ liệu thu thập từ các dự án đã hoàn thành [16] để phân loại cỡ dự án dựa trên thời gian hoàn thành tính theo giờ. Những dữ liệu này cho thấy năng suất ở các dự án nhỏ thì cao và giảm dần theo cỡ dự án. Mốc dự án ở systematic chia làm 2 nhóm: các dự án nhỏ ít hơn 4000 giờ và dự án lớn nhiều hơn 4000 giờ. Năng suất các dự án nhỏ bằng 181% năng suất các dự án lớn.

Khi so sánh các dự án dùng Scrum với mốc năng suất hiện tại, năng suất các dự án nhỏ không chênh lệch nhiều, nhưng năng suất của các dự án lớn tăng 201%, hoặc cao hơn một chút so với đường tăng trưởng. Như đã nói, những dự án lớn thực sự được cải tiến và không chỉ nhờ vào Scrum. Tuy nhiên những người tham gia đồng ý rằng Scrum đóng góp phần lớn trong sự cải tiến này.

Có thể thấy rõ rằng các dự án lớn ở Systematic mà dùng Scrum sẽ tăng gấp đôi năng suất so với dùng các quy trình trước đó. Còn các dự án nhỏ ở Systematic vốn đã có năng suất cao rồi. Chúng tôi tin rằng năng suất cao là do các dự án nhỏ này vốn được quản lý theo một cách tương tự như Scrum. Tuy nhiên chất lượng và độ hài lòng của khách hàng dường như cao hơn khi dùng Scrum. Chúng tôi tin rằng Scrum đã giúp mọi người hiểu rõ cách quản lý hiệu quả các dự án nhỏ.

3.2.2. Kiểm thử sớm

Một dự án lớn hơn với nhóm 10 thành viên phát triển một hệ thống nhắn tin quân sự. Dự án này lấy cảm hứng từ công cụ tư duy “Build Integrity In” trong Lean để nghiên cứu cách kiểm thử sớm, và họ đã tạo ra một phiên cản nâng cao của phương pháp Kiểm thử sớm theo story trong phát triển phần mềm. Cái tên Phát triển “Theo story” là từ XP, nhưng phương pháp của chúng tôi có những khía cạnh mới như: các phần tăng trưởng ngắn, thanh tra, và hướng tính năng.

Ý tưởng của Phát triển theo story là chia nhỏ các tính năng cần làm, thường chia các phần việc được ước tính mất hàng trăm tiếng thành các story nhỏ hơn khoảng 20-40 tiếng. Các story được phát triển theo phương thức mới, trong đó việc đầu tiên là quyết định cách để kiểm thử story trước khi bất đầu viết mã. Sau đó các kiểm thử này được dùng làm điều kiện hoàn thành cho story.

Phương thức này tạo ra các checkpoint mà tại đó sẽ có người thanh tra công việc đã làm xong và quyết định nhà phát triển có thể làm công việc tiếp theo hay không. Công việc thanh tra này rất nhẹ nhàng, và thường chỉ mất chưa đến 5 phút.

Rất nhiều lợi ích của Phát triển theo story ngay lập tức hiện rõ. Một định nghĩa hoàn thành tốt kết hợp với kiểm thử các tính năng sớm và liên tục đã đưa ra một bức tranh tổng thể chính xác về trạng thái và tiến độ cho nhóm và những bên liên quan khác.

Phát triển một loạt các story nhỏ thay vì từng phần của một tính năng lớn giúp tập trung hơn vào việc hoàn thiện tất cả điều kiện “hoàn thành” của một tính năng. Dự án này hoàn thành sớm và giảm 38% số lỗi trong lần kiểm thử cuối so với các quy trình trước kia.

Một dự án khác với nhóm 19 thành viên phát triển một môđun của một hệ thống bệnh án điện tử cũng làm theo cách kiểm thử sớm. Họ bảo đảm các công việc kiểm thử được tích hợp trong quá trình phát triển, tập trung vào việc “thấy được toàn cảnh” và hiểu rõ những điểm mà giải pháp của mình phù hợp với nghiệp vụ khách hàng. Mỗi tuần dự án đặt ra một mục tiêu cần đạt được. Dự án đảm bảo rằng kiểm thử viên và chuyên gia nghiệp vụ ngồi cùng chỗ với các lập trình viên. Điều này giúp các Kiểm thử viên, Lập trình viên, Kĩ sư trải nghiệm người dùng và các Kiến trúc sư phần mềm có thể thảo luận và trao đổi với nhau rất sớm hoặc trước khi phát triển một chức năng mới. Nhờ đó lượng lỗi trong lần kiểm thử cuối cùng đã giảm 42% so với các quy trình trước đó.

Dựa vào hai dự án này, Systematic kết luận rằng các hoạt động kiểm thử nên được tích hợp trong suốt quá trình phát triển các dự án. Scrum mặc định hỗ trợ điều này thông qua các nhóm liên chức năng và việc chuyển giao thường xuyên cho khách hàng. Sau đó, Systematic đã quyết định dùng phương pháp phát triển phần mềm theo story làm phương pháp khuyên dùng mặc định cho phát triển phần mềm trong các dự án của mình.

3.2.3. Nhu cầu thực sự

Trong một dự án khác, khách hàng đưa ra một tập hợp các yêu cầu. Khi trả lời khách hàng, chúng tôi đã trình bày rằng phạm vi và nội dung các yêu cầu e rằng vượt qua nhu cầu thực sự của họ.

Systematic quyết định chia sẻ cởi mở quá trình ước tính các yêu cầu với khách hàng để thu hẹp phạm vi bằng cách bỏ các yêu cầu không cần thiết hoặc quá đắt đỏ so với ngân sách khách hàng. Khách hàng đồng ý làm lại bản mô tả yêu cầu trong đó các yêu cầu và chi phí giảm đi một nửa.

Trải nghiệm này minh chứng cho kết quả trong nghiên cứu của Standish Group được Jim Johnson đưa ra tại XP2002 cho thấy 64% các tính năng trong một hợp đồng có chi phí cố định không bao giờ hoặc hiếm khi được dùng bởi người dùng cuối.

Chúng tôi tin rằng trải nghiệm này đã làm rõ tầm quan trọng của việc thảo luận cởi mở và thẳng thắn với khách hàng để tìm ra nhu cầu thực sự của họ. Thành công không đạt được bằng cách làm dự án lớn nhất mà bằng cách làm dự án tạo ra giá trị lớn nhất cho khách hàng, để những nhà phát triển phần mềm có thời gian làm việc với các khách hàng khác với những nhu cầu thực sự. Chiến lược này được Scrum hỗ trợ mạnh mẽ.

3.3. Áp dụng các phương pháp Agile

Các dự án thử nghiệm đạt được hai kết quả. Chúng xác nhận khả năng dùng tư duy tinh gọn để tìm ra các cải tiến. Thứ hai, chúng đưa ra 2 cải tiến cụ thể: Scrum và kiểm thử sớm theo story, chỉ ra cách áp dụng các phương pháp Agile trong khi vẫn tuân thủ CMMI. Một phát hiện quan trọng đối với Systematic là việc áp dụng các phương pháp Agile chỉ yêu cầu điều chỉnh rất ít các quy trình cũ.

Sau khi đánh giá kết quả của hai dự án thử nghiệm, công ty quyết định áp dụng Scrum và kiểm thử sớm theo story. Kiểm thử sớm theo story giúp mọi người chú trọng hơn vào việc liên tục tích hợp và tạo ra bản build của sản phẩm phần mềm. Vài dự án đặt ra mục tiêu tạo ra ít nhất một bản build mỗi ngày, và khoảng thời gian khi một bản build thất bại đến bản build thành công tiếp theo không được kéo dài quá một ngày làm việc. Công ty CMMI 5 có một hoạt động quan trọng là duy trì được kiểm soát thống kê các quy trình phụ để từ đó cải tiến quy trình phụ một cách định lượng. Trong ví dụ này, Systematic dùng thời gian sửa một bản build thất bại làm dữ liệu thống kê để cải tiến. Một hệ thống thu thập dữ liệu tự động từ server build của dự án và tạo ra các biểu đồ (Xem Hình 2). Điều này minh họa rõ ràng cách các quy tắc(disciplines) được thể chế hóa bằng CMMI và cách để áp dụng và thể chế hóa các kĩ thuật Agile. Những phương pháp này hiện nay đã trở thành lựa chọn mặc định cho các dự án mới và được đưa vào các mô tả quy trình tại Systematic.

4. Kết luận

Tài liệu này cho ta thấy CMMI và Scrum có thể kết hợp thành công. Sự kết hợp làm tăng năng suất rõ rệt so với chỉ dùng một mình CMMI hoặc Scrum trong khi vẫn tuân thủ CMMI cấp 5.

Những dự án thử nghiệm Scrum đạt được lợi ích lớn về năng suất và chất lượng so với các phương pháp truyền thống. Làm hài lòng cả người dùng lẫn người phát triển. Những kết quả này dẫn đến một quyết định dựa trên ROI được đưa ra: áp dụng rộng rãi Scrum và các phương pháp Agile khác tại Systematic. Hiện tại Scrum giúp giảm tất cả loại công việc (lỗi, làm lại, tổng khối lượng công việc, và rắc rối do quy trình) gần 50%

Với các công ty Agile, bài viết đã trình bày cách dùng các Phương pháp thực thi chung để thể chế hóa các kỹ thuật Agile và dùng Phát triển phần mềm tinh gọn [19] làm công cụ vận hành để tìm ra những phương án cải tiến trong một công ty CMMI 5.

Những công ty trong lĩnh vực quốc phòng, vũ trụ và những ngành khác yêu cầu các quy trình có độ trưởng thành cao nên cân nhắc kĩ càng việc áp dụng các kỹ thuật Agile và tất cả các công ty phần mềm nên cân nhắc áp dụng các kĩ thuật của CMMI.

Chúng tôi khuyến nghị cộng đồng Agile dùng các Phương pháp thực thi chung của CMMI từ cấp 3 trở lên để tăng cường lợi ích của các phương pháp Agile. Chúng tôi cũng khuyến nghị cộng đồng CMMI nên tích hợp các phương pháp Agile vào khung CMMI của mình. Tổ chức của bạn sẽ đạt được những cải tiến thú vị.

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

2.2. Những chỉ trích CMM

3. Scrum kết hợp CMMI: một lọ thuốc thần

3.1. Kinh nghiệm “Tinh gọn” của Systematic

3.2. Kinh nghiệm của Systematic từ những lần thử nghiệm

3.2.1. Scrum

3.2.2. Kiểm thử sớm

3.2.3. Nhu cầu thực sự

3.3. Áp dụng các phương pháp Agile

4. Kết luận

Bài viết mới

Tài nguyên

Cẩm nang Scrum

Tham Gia Cộng Đồng Quản Lý