Agile là gì? Scrum là gì?

Có rất nhiều phương thức phát triển phần mềm, và một trong số đó là phương thức phát triển phần mềm theo mô hình Scrum. Bài viết này sẽ giải thích các khái niệm cơ bản cũng như những giá trị cốt lõi về Agile – 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:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

• “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.

Quy trình là à các thủ tục cần thiết để phát triển dự án như thiết kế, sau đó đến coding, rồi test. Hay để xuất bản một chức năng nào đó cần phải có sự đồng ý của bộ phận đảm bảo chất lượng …. Quy trình này do mỗi công ty quy định và bắt  buộc các nhân viên khi tham gia vào dự án phải tuân thủ.
Công cụ là phần mềm được sử dụng trong dự án như : Phần mềm quản lý công việc, phần mềm quản lý bug, phần mềm quản lý source code, phần mềm quản lý thời gian làm việc, phần mềm quản lý mail …. Có rất nhiều công cụ được sử dụng để một tổ chức vận hành đúng theo mục tiêu của công ty đặt ra.

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.

Nhóm Dev là những lập trình viên có nhiệm vụ viết mã code cho sản phẩm.
Nhóm Test là người thực hiện kiểm tra (test) các sản phẩm do các bạn Dev viết ra.
Nhóm QA là người chịu trách nhiệm đảm bảo chất lượng sản phẩm (Quality Assurance).

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.

Ví dụ về cộng tác là: Trao đổi và thảo luận với khách hàng về sự cần thiết có hay không của một chức năng trong sản phẩm, từ đó quyết định là có nên làm hay không.
Ví dụ về đàm phán là: Nêu lý do đây là điều khoản đã được kí kết trong hợp đồng nên cần phải làm, mặc dù việc làm đó không mang lại giá trị cho người dù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.

Câu hỏi thường thấy là: Khách hàng thay đổi thoải mái, mô hình đáp ứng tối ưu…Nhưng sự thay đổi đó có được thảo luận giữa hai bên hay là do khách hàng ép? Khách hàng có chịu phí phát sinh cho các thay đổi thêm vào sản phẩm hay không? Đội dự án có dũng cảm và có quyền thảo luận với khách hàng về sự thay đổi hay không?

Scrum là gì?

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.

Ví dụ về minh bạch là: Yêu cầu của khách hàng, thời gian thực hiện, phương pháp thực hiện được truyền đạt một cách rõ ràng và thông suốt từ khách hàng đến mỗi thành viên trong đội dự án. Các thành viên trọng đội dự án nắm rõ tiến độ công việc và khó khăn của nhau trong suốt quá trình phát triển sản phẩm.
Ví dụ về không mình bạch là: Yêu cầu của khách hàng truyền cho bạn A, bạn A truyền đạt lại cho đội dự án dẫn đến hiểu sai, hiểu sót yêu cầu. Các thành viên trong đội dự án việc ai nấy làm, không biết tình trạng của các thành viên còn lại. Thời gian thực hiện một chức năng vì nhiều lý do mà cấp trên thường rút ngắn và ép buộc đội dự án thực hiện một cách “mù quáng”.

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.

Ví dụ về thanh tra trong Scrum là buổi Stand-up daily meeting. Ở đây các thành viên trả lời các câu hỏi về tiến độ, vấn đề khó khăn của dự án hằng ngày. Thông qua hoạt động này, dự án đã dược “thanh tra” một cách thường xuyên.

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.

Hy vọng bài viết trên có thể giúp các bạn hiểu hơn về Agile – Scrum.

Techtalk Via Devlog