Hiện nay, các công ty phần mềm thường áp dụng mô hình phát triển phần mềm Scrum. Vậy Scrum là gì ?. Scrum là một bộ khung với các công cụ, vai trò và qui trình rõ ràng dựa trên các nguyên lý Agile. Chính vì thế để tìm hiểu kĩ về scrum trước tiên chúng ta cần lắm rõ thứ mà Scrum dựa vào đó là nguyên lý Agile. Và nội dung của phần 1 trong serial bài viết là tìm hiểu về nguyên lý Agile.

Những vấn đề phổ biến trong phát triển sản phẩm và quản trị dự án phần mềm

Ngành phát triển phần mềm đã có hơn nửa thế kỉ hình thành và phát triển, qui trình phát triển phần mềm truyền thống hay còn gọi là water fall được mô tả như sau: Đây là quá trình được thực hiện tuần tự từ đầu tới cuối. Tuy nhiên, rất nhiều những vấn đề cứ không ngừng lặp lại, làm đau đầu đội ngũ phát triển và nhà quản trị. Dưới đây là một số vấn đề tiêu biểu:

• Theo cách thức phát triển cũ, dự án được lập kế hoạch cẩn thẩn và được tiến hành với nhiều khâu, trong thời gian đó khách hàng sẽ ngồi chờ. Các bên chỉ nhận được các báo cáo chứ không được phần mềm để dùng. THông tin về sản phẩm rất mù mờ, không minh bạch trong tiến độ với khách hàng. Điều này gây làm cho bên lo lắng và không cách nào cung cấp các phản hồi có ý nghĩa, khó hợp tác với đội phát triển cho ra sản phẩm tốt nhất.
• Kế hoạch đã định, nhưng nhiều rủi ro xuất hiện: lỗi xuất hiện ngày càng nhiều, hiểu sai yêu cầu, khó khăn về mặt công nghệ, không làm việc như kỳ vọng
• Sản phẩm thiếu ổn định do không kiểm soát được chất lượng. Nhiều dự án, mọi công việc hoàn thành nhưng giai đoạn tích hợp và ổn định hệ thống thật là thảm hoạ không bao giờ kết thức.
• Kế hoạch tuy được lên sẵn, nhưng không có nghĩa là không sai sót. Điều này làm ra tốn thời gian hơn cho việc lập kế hoạch.
• Khi mọi thứ đã được chuẩn bị xong, khách hàng bỗng cao hứng đổi yêu cầu, điều này làm nhóm khó xử bởi họ không biết làm thế nào do việc thay đổi rất khó.
• Sản phẩm bất ôn định do mã nguồn càng nhiều sau một khoảng thời gian phát triển. Kế hoạch bị phá vỡ, chất lượng ngày một giảm, tất cả mọi người phải chịu thêm các áp lức khiến cho các lập trình viên không vui vẻ gì.

Agile ra đời

Tại thập kỉ 80 của thế kỉ XX, chứng kiến một thời kì khủng khoảng phương pháp luận phát triển phần mềm, do tỉ lệ thất bại của các dự án phần mềm quá cao. Rất nhiều các phương pháp phát triển phần mềm với truy trình nhẹ và linh hoạt hơn ra đời. Vào tháng 2/2001, 17 nhà phát minh và thực hạnh đã họp nhau tại Hoa kì để thoải luận và đi tới thống nhất cho ra đời Agile, đánh dấu một xu thế mới cho phát triển phần mềm. Sau một khoảng thời gian dài ra mắt, Agile đã cải thiện dáng kể khả năng thành công của các dự áo.'. Minh chứng cho điều đó thì theo báo cáo năm 2015 của Standish Group đã cho thấy dự án Agile có tỉ lệ thành công cao hơn gấp 3 lần so với dự án truyền thống. Vậy Agile có những gì, Agile đưa ra các tuyên ngôn phát triển phần mềm linh hoạt như sau:

• Cá nhân và tương tác hơn là quy trình và công cụ
• Phần mềm có thể chạy được 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 thay đổi hơn là bám sát kế hoạch

Bên cạnh đó Agile còn đi kèm 12 nguyên lý như sau:

1. Ưu tiên cao nhất của chúng ta là thoả mãn khách hàng thông qua việc chuyển giao sớm và liên túc các phần mềm có giá trị
2. Chào đón việc thay đổi yêu cầu, thậm chí rất muonj trong quá trình phát triển. Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng
3. Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần tới vài tháng ưu tiên cho các khoảng thời gian ngắn
4. Bên kinh doanh và nhà phát triển làm việc cùng nhau hàng ngày trong suốt dự án
5. Xây dựng các dự án xung quanh những các nhân có động lực. Cúng cấp cho họ môi trường và sự hỗ trợ cần thiết , và tin tưởng học để hoàn thành công việc
6. Phương pháp hiệu quả nhất để truyền đạt là đối thoại trực tiếp
7. Phần mềm chạy tốt là thước đó chính của tiến độ
8. Quy trình linh thoạt thức đẩy phát triển bền vứng.
9. Liên tục quan tâm đến các kĩ thuật và thiế kế tố để gia tăng sự linh hoạt
10. Sự đơn giản là cần thiết
11. Kiến trúc tốt nhất, yêu cầu tốt nhất và thiết kế tốt nhất sẽ được làm bởi các nhóm tự tổ chức
12. Nhóm phát triển sẽ thương xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn sau đó họ sẽ điều chỉnh và thay đổi hành vi của mình cho phù hợp.

Những giá trị trên không chỉ là thứ mà nhóm tác giả của Agile dự định cung cấp ra để phục vụ cho tuyên ngôn mà rồi sau đó đi vào dĩ vãng. CHúng là các giá trị căn cứ vào để làm việc. Bản thân mỗi phương phát linh hoạt đều tiếp cận các trị trên theo các cách thức khác nhau, nhưng tất cả các phương pháp này đề có tiến trình biện pháp thực hành cụ thể để nuôi dưỡng một hoặc nhiều trong số các giá trị đó.

Cá nhân và tương tác

Các nhân và tương tác giưã họ là cốt yếu để nhóm đạt được hiệu suất cao. Các nghiên cứu về sự bão hoà giao tiếp trong dự án cho thấy rằng, khi không có vấn đề giao tiếp, nhóm có thể thực hiện công việc tốt hơn 50 lần so với mức trung bình trong lĩnh vực của mình. Để tạo điều kiện cho giao tiếp các phương pháp linh hoạt thường xuyên sử dụng chu trình thanh tra và thích nghi. Chu trình này diễn ra hằng ngày với lập trình cặp (pair- programing), hàng giờ và tích hợp liên tực qua các buổi sơ kết và cải tiến. Tuy vậy, tăng tần suất phản hồi và giao tiếp là không đủ để loại bỏ các vấn đề giao tiếp. Chu kỳ thanh tra và thích nghi hoạt đông tốt chỉ khi các thành viên trong nhóm thể hiện những hành vi quan trong sau:

• Tôn trọng giá trị của mỗi cá nhân
• Trung thực trong giao tiếp
• Minh bạch về dữ liệu, hoạt động và quyết định
• Tin tưởng vào sự hỗ trợ của mỗi cá nhân với nhóm
• Cam kết với nhóm các mục tiêu của nhóm Để thức đẩy các hành vi này, nhà quản trị linh hoạt phải cung cấp môi trường hỗ trợ và tạo điện kiện thuận lợi để các thanh viên trong nhóm thể hiện mình. Chỉ khi đó nhóm mới có thể phát huye hết tiềm năng của mình. Tuy vậy, hầu hết các nhóm tránh né sự thật, sự minh bạch và tin tưởng vào chuẩn mực văn hoá hoặc những kinh nghiệm tiêu cực từ các xung đột xuất phát từ truyền thống trước đây. Để chống lại những khuynh hướng này, người lánh đảo và thành viên phải tạo điều kiện cho những xung đốt tích cực. Làm vậy không chỉ giúp tạo ra hành vi sinh lời mà ocn đem lại lợi ích khác nhau.
• Cải tiến quy trình thuộc vào nhóm trong việc tạo ra danh sách trở ngại hoặc vấn đề trong tổ chức, đối mặt với chúng một cách trung thực, sau đó loại bỏ chúng khỏi hệ thống
• Đổi mới chỉ xay ra với việc tự dao trao đổi các ý tưởng mâu thuẫn nhau.
• Hướng các nhóm tới mực tiêu chung đòi hỏi nhóm phải đối mặt và giải quyết các vấn đề xung đột
• Cam kết làm việc cùng nhau chỉ xảy ra khi mọi người đồng ý với mực tiêu chung và sau đó đấu tranh cho sự tiến bộ của bản thân.

Phần mềm chạy tốt

Phần mềm chạy tốt là một trong những khác biệt lớn mà phát triển linh hoạt mang lại. Tất cả các phương pháp linh hoạt thể hiện ở Agile bằng cách nhận mạnh việc cung cấp một phần nhỏ của phần mềm chạy tốt tới khách hàng sau một khoảng thời gian nhất định, Tất cả các nhóm Agile phải xác lập những già họ muốn nói là phần mềm chạy tốt, thường được biết như "Định nghĩa của hoàn thành" ( Define of Done). Ở mức độ cao, một phần của chức năng hoàn thành chỉ khi các tính năng của chúng vượt qua tất cả các kiểm thức và có thể vận hành bởi người dùng cuối. Ở mức thấp hơn, các nhóm phải vượt qua những kiểm thự đơn vị (unit test) và kiểm thử hệ thống. Các nhóm tốt nhất còn bao gồm việc kiểm thử tích hợp, kiểm thư hiệu năng và kiểm thử chấp nhận của khách hàng trong Define of Done đối với một chức năng.

Cộng tác với khách hàng

Trong thập kỷ qua, tỉ lệ thành công của các dự án tăng hơn 2 lần trên toàn thế giới. Điều nay được cho là vì các dự án nhỏ hơn và mức đổ chuyển giao thường xuyên đã cho pháp khách hàng cung cấp các thông tin phản hồi về phần mềm hoát động một cách đều đặn hơn. Các tác giả của Agile đã làm sáng tỏ điều này khi họ nhấn mạnh rằng việc khách hàng tham gia vào quá trình phát triển phần mềm là hết sức cần thiết cho sự thành công của dự án. Ví dụ, mỗi nhóm Scrum đầu tiên có hàng ngàn khách hàng. Sẽ là không khả thi nếu cho phép tất cả khahcs hàng tham giao vào quá trình phát triển phần mềm, vì vậy họ chọn ra một đại sứ khách hàng được gọi là PO (Product Owner) để đại diện cho không chỉ tất cả khách hàng trong trường hợp này mà có bao gồm các nhàn quản lý, dịch vụ khách hàng và các bên liên khách khác. PO có trách nhiệm cập nhập danh sách yêu cầu về sản phẩm sau mỗi thời điểm mà nhóm Scrum phát hành phiên bản sản phẩm chạy tốt, có tính đến yếu tố thực thế cùng phản hồi của khách hàng và các bên liên quan. Điều này cho phép khách hàng có thể định hình sản phẩm phần mềm đang tạo ra.

Phản hồi với thay đổi

Phản hồi với thay đổi là cần thiết cho việc tạo ra một sản phẩm làm hài lòng khách hàng cũng như mang lại những giá trị kinh doanh. Dữ liệu ngành công nghiệp cho thấy hơn 60% các yêu cầu về sản phẩm hay dự án bị thay đổi suốt qua trình phát triển phần mềm. Ngay cả những dự án truyền thống kết thúc đúng thời gian, trong giới hạn kinh phí, tính năng theo kế hoạch nhưng khách hàng thường không hài lòng vì những gì họ thấy không đúng như những gì họ muốn. Luật Humphrey nói rằng khách hàng không bao giờ biết những gì họ muốn cho đến khi họ thấy phần mềm hoạt động Nếu khách hàng không thấy phần mềm hoạt động cho đến khí kết thúc dự án, sẽ là quá muộn cho việc kết hợp các thông tin phản hồi của họ ở thời điểm này. Phương pháp phát triển linh hoạt tìm kiếm sự phản hồi của khách hàng trong suốt dự án để có thể kết hợp thông tin phản hồi và thông tin mới ngay khi sản phẩm đang được phát triển.

Tổng kết

Agile không phải là một qui trình hoàn thiện mà chỉ là tập hợp các nguyên lý chung mà chúng ta nên tuân theo để phát triển phần mềm một cách uyển chuyển tinh gọn. Dựa theo nguyên lý của agile người ta đã đề ra những khung qui trình phát triển phần mềm mà phổ biến nhất là Scrum. Vậy Scrum có gì mời các bạn đợi tới phần 2 : Scum Cơ Bản. Ở phần 2 các bạn sẽ cùng giải đáp các câu hỏi như Scrum là gì ? Lợi ích của Scrum ? Nó diễn ra như thế nào v.v.... Vậy các bạn hãy chờ đợi phần 2 nhé !

Tham khảo: Sách Scrum Cơ bản - NXB Thế Giới