Giới thiệu Agile Scrum

Agile là gì? Scrum là gì? Hẳn có rất nhiều bạn nghe đến khái niệm này. Liệu Agile và Scrum có phải là một? Bài viết sau sẽ đi vào tìm hiểu những khái niệm căn bản: Agile là gì, tuyên ngôn và triết lý Agile cũng như lý thuyết về Scrum.

Agile là gì?

Trong các dự án, đặc biệt là các dự án phần mềm chúng ta sẽ gặp rất nhiều khó khăn trong việc thu thập đầy đủ và chính xác các yêu cầu của sản phẩm để lập kế hoạch tốt ngay từ đầu. Có quá nhiều vấn đề gây ảnh hưởng đến việc phát triển phần mềm. Trong khi đó có quá nhiều vấn đề mà chúng ta không lường trước được. Những vấn đề này có thể đến từ những yếu tố như kinh doanh, kỹ thuật, con người ....

Trong giai đoạn những năm 1990 trên thế giới xảy ra cuộc khủng hoảng của quá trình phát triển phần mềm. Những phương pháp phát triển phần mềm theo cách truyền thống ngày càng bộc lộ nhiều nhược điểm và tỷ lệ các dự án thật bại cao. Từ đó các cá nhân và công ty riêng lẻ đã đưa ra các phương pháp phát triển phần mềm khác nhau để thích ứng với tình hình mới khiến cho phương pháp phát triển truyền thống đã không còn phù hợp

Những phương thức phát triển phần mềm này giúp phần nào giải quyết được một số vấn đề nhưng lại nảy sinh vấn đề khác về sự chia sẻ, cộng tác, kỹ thuật, công cụ, hướng phát triển .... Do vậy năm 2001, nhóm 17 người có uy tín trong nghề phát triển phần mềm thời điểm đó đã gặp nhau và đi đến thống nhất cho ra đời một bản tuyển ngôn Agile:

- “Cá nhân và sự tương tác hơn là quy trình và công cụ”

- “Phần mềm chạy tốt hơn là tài liệu đầy đủ”

- “Cộng tác với khách hàng hơn là đàm phán hợp đồng”

- “Phản hồi với sự thay đổi hơn là bám theo kế hoạch”

1. Cá nhân và sự tương tác hơn là quy trình và công cụ

Ý tưởng là đặt trọng tâm vào con người và sự tương hỗ giữa những thành viên trong nhóm. Cơ bản là nếu dự án có những thành viên có năng lực, chịu làm việc cùng nhau thì sẽ mang đến thành công cho dự án. Nếu dự án của bạn có quy trình làm việc tốt, được hỗ trợ những công cụ tốt nhất nhưng những thành viên không “cùng nhìn về một hướng” thì khả năng dự án thất bại là rất lớn. Nói điều này không có nghĩa là phủ nhận tầm quan trọng của quy trình và công cụ nhưng trong Agile nó được đặt sau yếu tố con người. Có một câu bằng tiếng Anh khá phổ biến nói về điều này là “a fool with a tool is just a fool”

2. Phần mềm chạy tốt hơn là tài liệu đầy đủ

Trong một số quy trình phát triển phần mềm, việc tạo ra và cập nhật các tài liệu về sản phẩm là bắt buộc. Nhóm Dev không thể hoặc không đồng ý tiến hành công việc nếu không có tài liệu đặc tả về yêu cầu, thiết kế hệ thống. Nhóm Test thì yêu cầu tài liệu về sản phẩm để có thể viết trường hợp kiểm thử và kiểm thử được. Nhóm QA đòi tất cả các tài liệu phải được viết trước khi sản phẩm được giao cho khách hàng nếu không thì không đủ điều kiện, chuẩn để giao sản phẩm cho khách hàng. Thực ra đứng với góc độ khách hàng thì khách hàng chỉ quan tâm đến sản phẩm có hoạt động được và tốt hay không. Trong khi việc tạo và cập nhật tài liệu mất nhiều thời gian và được cho là buồn tẻ. Vậy tại sao mình phải tập trung quá nhiều cho việc không cần thiết mà không dành thời gian đó để trao đổi để hiểu thêm về công việc phải làm. Mọi người đừng hiểu lầm là làm Agile là không viết tài liệu. Ý tưởng là chỉ viết những gì mà mọi người cần đọc.

3. Cộng tác với khách hàng hơn là đàm phán hợp đồng

“Khách hàng là thượng đế” hay “khách hàng luôn luôn đúng”. Tuy nhiên thì khách hàng có đủ loại khách hàng. Có khách hàng am hiểu về công nghệ, có người không. Có người suy nghĩ nhất quán có người thay đổi xoành xoạch, có người lạnh lùng có người cười nói suốt ngày, v.v và cách duy nhất để có thể làm việc tốt là phải cộng tác với khách hàng để hiểu được khách hàng muốn gì và cần gì để có thể tư vấn và điều chỉnh thay vì chỉ dựa vào những điều đã quy định trong hợp đồng.

4. Phản hồi với sự thay đổi hơn là bám theo kế hoạch

Có một điểm chung mà mình thấy trong hầu hết những dự án mình đã trải qua đó là không có dự án nào không có sự thay đổi điều chỉnh khi thực thi. Sự thay đổi đó có thể là thay đổi về yêu cầu, thay đổi công nghệ, thay đổi nhân sự, thay đổi deadline, thay đổi phương thức làm việc, v.v mặc dù kế hoạch đã được định ra rõ ràng từ đầu. Agile không khuyến khích cho sự thay đổi nhưng khuyến khích chúng ta tập thích nghi với thay đổi.

Có một điều thú vị là đa số trong chúng ta đều cơ bản đồng ý với 4 tuyên ngôn của Agile. Nhiều người hiểu tầm quan trọng của “cá nhân” hay “cá nhân là tài sản quý giá nhất công ty” nhưng sẵn sàng thay đổi nhân lực để tương thích với quy trình/công cụ hiện có. Nhiều người hiểu “khách hàng là thượng đế” và “phải thích nghi với sự thay đổi” nhưng sẵn sàng tuyên bố “Dẹp, không làm nữa” vì khách hàng thay đổi yêu cầu liên tục. Hay như “sản phẩm xài được là quan trọng “ nhưng vẫn cố gắng viết thêm tài liệu với ý nghĩ rằng “biết đâu/lỡ sau này có ai cần thì có cái mà cung cấp”.

4 tuyên ngôn của Agile nói dễ hơn làm nhưng khi bạn theo Agile thì bạn hãy chuẩn bị tinh thần để “làm” chứ không phải để “nói”.

Lưu ý: Mặc dù các điều bên phải vẫn có giá trị. Nhưng các mục ở bên trái luôn được đánh giá cao hơn:

Ví dụ: Cá nhân và sự tương tác hơn là quy trình và công cụ. Agile hướng sự tập trung vào Cá nhân và sự tương tác mà không hệ phủ nhận quy trình và công cụ cũng như các phương thức truyền thống. Đó là lý do tại sao sử dụng từ hơn là chứ không phải thay vì hay bất kỳ từ nào khác với mục đích phủ định, loại bỏ cái cũ. Cách hiểu này cũng áp dụng cho các tuyên ngôn còn lại.

Scrum là gì?

Lý thuyết: Là một thành viên của họ Agile. Scrum được xây dựng dựa trên lý thuyết quản lý tiến trình thực nghiệm (empirical process control), hay còn gọi là thực nghiệm luận (empiricism). Lý thuyết này chỉ ra rằng tri thức đến từ kinh nghiệm và việc ra quyết định được dựa trên những gì đã biết. Điều này sẽ giúp giảm thiểu rủi ro và tăng tính chính xác đặc biệt là trong môi trường phát triển phần mềm nhiều biến động.

Ví dụ đơn giản nhất cho khái niệm Scrum đó là những đàn chim di cư. Chúng không hề có kế hoạch chi tiết cho hành trình của mình. Nhưng vẫn vượt qua được hàng chục nghìn km mỗi năm qua những vùng đất xa lạ nhờ việc quan sát và thích nghi liên tục với điều kiện khí hậu thức ăn. Nơi trú ngụ của từng vùng ....

Ba yếu tố nòng cốt tạo thành một mô hình quản lý tiến trình thực nghiệm gồm: sự minh bạch (transparency), thanh tra (inspection) và thích nghi (adaptation).

1. Minh bạch

Các khía cạnh quan trọng của tiến trình phải được hiển thị rõ ràng cho những người có trách nhiệm với thành quả của tiến trình đó. Sự minh bạch yêu cầu các yếu tố này cần được định nghĩa theo một tiêu chuẩn để những người quan sát có thể hiểu những gì họ thấy theo cùng một cách.

2. Thanh tra

Người sử dụng Scrum phải thường xuyên thanh tra các tạo tác và tiến độ đến đích để phát hiện các bất thường không theo ý muốn. Tần suất thanh tra không nên quá dày để khỏi ảnh hưởng đến công việc. Công tác thanh tra có ích nhất khi được thực hiện bởi người có kĩ năng tại các điểm quan trọng của công việc.

3. Thích nghi

Nếu một người thanh tra xác định được rằng có vấn đề nào đó vượt quá giới hạn cho phép, và hậu quả của vấn đề đó đối với sản phẩm là không thể chấp nhận được, thì quy trình hoặc các vật liệu được xử lý (processed material) phải được điều chỉnh. Sự điều chỉnh phải được tiến hành càng sớm càng tốt để giảm thiểu các sai sót khác có thể xảy ra.

Để đảm bảo việc triển khai Scrum mang lại lợi ích cao nhất thì bạn phải đảm bảo cả ba trụ cột trên trong một thể thống nhất. Thiếu một trong số đó sẽ gây ra hậu quả nghiệm trọng và dễ dẫn đến thất bại.

Lợi ích mà Scrum mang lại

1. Cải thiện chất lượng phần mềm

Framewrok của Scrum giúp nhóm phát triển Scrum nhận phản hồi liên tục và nhanh chóng điều chỉnh để đảm bảo chất lượng phần mềm cao nhất, đồng thời đáp ứng đúng nhu cầu của thị trường luôn thay đổi. Bằng cách áp dụng các nguyên tắc nghiệm ngặt trong mô hình Scrum, nhóm phát triển Scrum có thể đưa ra thị trường các sản phẩm có chất lượng tốt nhất.

2. Rút ngắn thời gian phát hành phần mềm

Scrum đã được chứng minh là cung cấp sản phẩm đến tay khách hàng cuối cùng nhanh hơn 30%-40% so với phương pháp truyền thống. Vì mô hình Scrum làm việc với nguyên tắc chính là chia nhỏ phần mềm cần sản xuất ra thành các phần nhỏ để phát triển gọi là Sprint. Mỗi Sprint thường mất 2- 4 tuần để hoàn thành.

3. Nâng cao tinh thần đồng đội

Mô hình Scrum áp dụng cách thức tự quản và tự tổ chức (self-managing & self-organizing ), với mục đích các thành viên trong nhóm Scrum có thể vui vẻ làm việc cùng nhau, khơi dậy sự sáng tạo, chủ động trong họ. Cách thức tự quản lí cũng cho phép mọi thành viên trong nhóm Scrum đều có thể ra quyết định. Trong nhóm Scrum sẽ không có nhóm trưởng mà chỉ có Scrum Master, là người giúp nhóm vượt qua các trở ngại và che chắn cho nhóm khỏi những ảnh hưởng từ nội bộ hay bên ngoài.

4. Gia tăng tỷ suất hoàn vốn đầu tư (ROI)

Giảm thời gian sản xuất là lí do chính yếu nhất giúp các dự án Scrum đạt được ROI cao hơn. Bởi vì doanh thu và các mục tiêu khác đến sớm hơn, nên tổng lợi nhuận cao hơn theo thời gian. Đây là một nguyên lý cơ bản của giá trị hiện tại thuần (NPV)

5. Tăng mức độ hài lòng của khách hành

Nhóm Scrum cam kết sản xuất ra các sản phẩm hoặc dịch vụ có thể khiến khách hàng hài lòng. Sở dĩ như vậy vì nhóm Scrum xem khách hàng là đối tác và giữ khách hàng tham gia vào dự án; thành phần tham gia dự án Scrum còn có Product Owner là người hiểu rõ các yêu cầu (requirements) của dự án và nhu cầu của khách hàng; thời gian cung cấp sản phẩm nhanh hơn

6. Kiểm soát dự án tốt

Tất cả các thành viên của nhóm dự án Scrum, Product Ower, Scrum Master và các bên liên quan có rất nhiều cơ hội để kiểm tra và điều chỉnh sản phẩm trong suốt dự án và cuối cùng tạo ra sản phẩm tốt nhất. Vì các framework của mô hình Scrum cho phép nhận các phản hồi liên tục và qua đó có thể nhanh chóng điều chỉnh.

7. Giảm thiểu rủi ro

Mô hình Scrum giúp giảm thiểu rủi ro thất bại hoàn toàn khi mất một số tiền đầu tư khổng lồ và thời gian dài để triển khai dự án mà không thu lại được ROI. Vì như đã trình bày, Scrum làm việc theo từng giai đoạn, từng Sprint, nên nhóm dự án có thể thực hiện từng bước, sau đó rút kinh nghiệm hoặc tiếp tục phát huy các ưu điểm của Sprint trước để cải thiện hơn sản phẩm trong Sprint sau tránh gây thất thoát quá lớn trong suốt dự án.