Phương pháp Agile và Quy Trình Scrum đang là xu hướng của các công ty phần mềm hiện nay, bạn nên tìm hiểu và biết về chúng

Phương pháp Agile là gì?

Có rất nhiều định nghĩa về Agile. Nhưng theo mình đơn giản thì agile là mô hình phát triển linh hoạt,  dựa trên phương thức lặp (iterative) và tăng trưởng (incremental). Nó sẽ gắn kết khách hàng vào quy trình phát triển của phần mềm, mọi người cố gắng cho ra sản phẩm càng nhanh càng tốt. Sau đó đưa cho khách hàng dùng thử và phản hồi lại, đội ngũ phát triển sẽ tiếp tục phát triển các giai đoạn tiếp theo. Tùy vào dự án mà thời gian release ra sản phẩm dài hay ngắn (có thể 2 tuần, cũng có thể 1 tháng…)

Tuyên ngôn Agile

Cái tuyên ngôn này ra đời năm 2001, khi mà 17 kỹ sư phần mềm cùng tụ họp tại resort Snowbird, bang Utah miền Tây nước Mỹ để tìm kiếm một giải pháp phát triển gọn nhẹ và linh hoạt. Tuyên ngôn thì chỉ có vài dòng nhưng để hiểu được nó và vận hành không phải là chuyện đơn giản:

• “Cá nhân hóa và sự tương tác: tự tổ chức và động lực phát triển rất quan trọng, tương tác với nhau giữa các lập trình viên”. Điều này có nghĩa là mỗi lập trình viên nên tự vận động hơn là dựa vào quy trình nhiều, và nên có sự tương tác với nhau để cùng nhau phát triển, điển hình là mô hình lập trình cặp (pair-programming).
• “Thà làm ra phần mềm chạy tốt còn hơn là cung cấp đầy đủ tài liệu phần mềm cho khách hàng trong các cuộc họp”. Tức là nên đảm bảo ưu tiên phần mềm làm ra thật hoàn hảo trước, còn vấn đề tài liệu hướng dẫn sử dụng,….. thì không nên quá chú tâm, điều đó có thể thực hiện sau cùng.
• “Sự cộng tác với khách hàng”. Nên đưa khách hàng vào quy trình phát triển chung của dự án, hãy hợp tác với khách hàng để sản phẩm được hoàn hảo và phù hợp với nhu cầu của họ. Không nên chỉ chú trọng vào việc đàm phán hợp đồng.
• “Phản hồi với các thay đổi”. Tuyên ngôn này chú trọng vào việc thích ứng với các thay đổi của khách hàng hơn là bám sát vào kế hoạch đã vạch sẵn. Tức là trong một dự án thì đôi khi khách hàng muốn thay đổi kế hoạch, thay đổi kết cấu của phần mềm, thay đổi chức năng ….. nên đội ngũ phát triển cũng phải sẵn sàng thích ứng với sự thay đổi đó. Sự tương tác giữa khách hàng và nhà phát triển sẽ tăng lên rất nhiều khiến cho sản phẩm làm ra khiến khách hàng hài lòng hơn vì chính họ đã đưa ra yêu cầu chỉnh sửa mà. Dễ hiểu chưa.

Ngoài ra còn một danh sách 12 nguyên lý nữa nhưng thôi mình không kể ở đây, vì dài dòng lắm. Nếu bạn nào quan tâm có thể google search với từ khóa “agile principles”. Mục tiêu của bài viết này là bằng cách đơn giản nhất giúp mọi người có cái nhìn tổng quát và có thể hiểu hết các kiến thức chứ không nêu lý thuyết thuần. Vả lại, đứng trên phương diện là một developer, cái bạn cần quan tâm là hiểu được cách mà agile hoạt động, việc còn lại sẽ do project manager hoặc team leader triển khai và mình đi theo thôi.

Phát triển chức năng — Test — Release sản phẩm cho khách hàng — Khách hàng phản hồi lại — Thay đổi và test lại — Release sản phẩm. Và cái vòng xoay cứ tiếp tục xuyên suốt quá trình sản xuất ra sản phẩm đến khi nào hoàn thành thì thôi.

Các phương pháp Agile

Agile chỉ là một mô hình trên lý thuyết, để triển khai nó thì cần phải phân tích ra cụ thể, sau một thời gian dài, danh sách các phương pháp tăng lên và phát huy hiệu quả rõ rệt.

Thông thường mô hình waterfall truyền thống để phát triển phần mềm gồm một số giai đoạn tách biệt: Phân tích Nhu cầu > Kiến trúc và Thiết kế > Xây dựng > Kiểm thử > Chuyển giao và Phản hồi.

• Phân tích Nhu cầu: trong bước này, toàn bộ nhu cầu phần mềm được nhận biết, phạm vi được xác định. Trong các quy trình chặt chẽ, những yêu cầu đó được thể hiện chi tiết, văn bản hóa, theo tiêu chuẩn hoặc không, cần người có trách nhiệm phê chuẩn (approve) trước khi được tiến hành bước tiếp theo, và khi đã sang bước tiếp theo, hạn chế sự thay đổi.
• Kiến trúc và Thiết kế: Trước khi bước sang giai đoạn mã hóa, toàn bộ giải pháp của hệ thống cũng như kiến trúc của nó cần được xác định, văn bản hóa và được phê chuẩn bởi người có trách nhiệm.
• Xây dựng (Development, hay còn gọi là Triển khai-Implementation, hoặc Mã hóa-Coding): đây là giai đoạn hiện thực hóa giải pháp đã được đưa ra (từ bước 2) thành ra các mã nguồn và những chương trình thực thi được.
• Kiểm thử: Trước khi phần mềm được chuyển giao tới khách hàng hay người dùng cuối, nó cần được kiểm thử để bảo đảm về chất lượng. Các lỗi tìm được và những đoạn mã nguồn không đạt chuẩn được đưa trở lại các lập trình viên xử lí (bước 4) cho tới khi nào “hết lỗi”.
• Chuyển giao và phản hồi: khi chất lượng phần mềm được “bảo đảm”, toàn bộ phần mềm được chuyển giao tới người dùng. Có thể có hoặc không các công đoạn tiếp theo để nhận phản hồi như lỗi, hỗ trợ kĩ thuật, các việc “vá lỗi”, bảo trì v.v.

Theo khảo sát mới đây (2011) của Forrester Research, các cách tiếp cận phổ biến trong phát triển phần mềm có thể kể đến gồm Scrum, Iterative (Iterative Development – phát triển lặp), Waterfall, TDD, Kanban, XP.

Trong đó, phương pháp Scrum là phổ biến nhất hiện nay, nhiều công ty tại Việt Nam cũng đang thử nghiệm mô hình này.

Quy Trình Scrum là gì?

SCRUM là một phương pháp phát triển với nguyên tắc là chia phần mềm cần sản xuất ra thành các phần nhỏ (các phần nhỏ này phải độc lập và release được), lấy ý kiến khách hàng và thay đổi cho phù hợp ngay trong quá trình phát triển để đảm bảo sản phẩm release đáp ứng những gì khách hàng mong muốn. Đơn giản hơn chút thì SCRUM là một nền tảng đơn giản để phát triển phần mềm, trong đó nó quy định một số quy luật cơ bản nhằm đảm bảo tạo ra cấu trúc của nhóm dự án, giữ cho nó phát triển, sáng tạo và tạo ra sự hấp dẫn đối với những người tham gia. Nó thực hiện dựa trên đặc tính tự nhiên của người phát triển nên rất dễ hiểu, dễ áp dụng, tạo nên tính tương tác cao giữa các lập trình viên trong nhóm. Giúp họ cùng nhau tạo ra những sản phẩm tốt. Thay vì chịu sự áp đặt, áp lực từ bên ngoài.

Scrum có các tính chất:

• Nhẹ nhàng
• Dễ hiểu
• Rất khó để tinh thông

Scrum là khung làm việc đã được sử dụng để quản lý quá trình phát triển các sản phẩm phức tạp từ đầu những năm 1990. Scrum không phải là một quy trình hay một kĩ thuật cụ thể để xây dựng sản phẩm hơn thế, nó là một khung làm việc cho phép bạn sử dụng nhiều quy trình và kĩ thuật khác nhau. Scrum làm sáng rõ mức độ hiệu quả tương đối của công tác quản lý và phát triển sản phẩm, từ đó cho phép bạn cải tiến nó.

Khung làm việc Scrum bao gồm một Nhóm Scrum với các vai trò được phân định rõ ràng, các sự kiện, các tạo tác 1 (artifact) và các quy tắc. Mỗi thành phần trong khung làm việc phục vụ một mục đích rõ ràng và nòng cốt trong việc sử dụng và thành công của Scrum.

Họp Scrum hằng ngày

Cuộc họp Scrum Hằng ngày (Daily Scrum) được đóng khung trong 15 phút để Nhóm Phát triển đồng bộ hóa các hoạt động của thành viên và tạo lập kế hoạch cho 24 giờ tiếp theo. Điều này có được nhờ việc thanh tra các công việc kể từ cuộc họp Scrum Hằng ngày trước và dự báo những công việc sẽ được hoàn thành trước buổi họp lần sau.

Cuộc họp Scrum Hằng ngày được tổ chức tại cùng một địa điểm để giảm thiểu sự phức tạp không cần thiết. Trong suốt cuộc họp, mỗi thành viên Nhóm Phát triển giải thích rõ:

1. Tôi đã làm những gì kể từ hôm qua để giúp Nhóm Phát triển đạt được Mục tiêu Sprint?
2. Tôi sẽ làm những gì hôm nay để giúp Nhóm Phát triển đạt được Mục tiêu Sprint?
3. Tôi có nhìn thấy vấn đề gì cản trở Nhóm Phát triển đạt được Mục tiêu Sprint?

Nhóm Phát triển sử dụng cuộc họp Scrum Hằng ngày để đánh giá tiến độ công việc hướng tới Mục tiêu Sprint và đánh giá xu hướng tiến triển của công việc trong Sprint Backlog. Cuộc họp Scrum Hằng ngày tối ưu hóa khả năng để Nhóm Phát triển có thể đạt được Mục tiêu Sprint.

Hằng ngày, Nhóm Phát triển có thể giải thích cho Product Owner và Scrum Master biết họ định làm gì với tư cách là một nhóm tự quản để hoàn thành mục tiêu và tạo ra các phần tăng trưởng cần thiết trong Sprint.

Scrum Master đảm bảo cho Nhóm Phát triển tham gia họp, nhưng chính Nhóm Phát triển mới có trách nhiệm chính trong cuộc họp Scrum Hằng ngày. Scrum Master phải hướng dẫn cho Nhóm Phát triển biết cách giữ cuộc họp ngắn gọn trong phạm vi khung thời gian 15 phút.

Scrum Master phải áp đặt quy tắc về việc chỉ có Nhóm Phát triển mới được tham gia cuộc họp Scrum Hằng ngày.

Họp Scrum Hằng ngày sẽ cải tiến quá trình giao tiếp, lược bỏ các buổi họp hành không cần thiết, nhận biết và loại bỏ các trở lực trong quá trình phát triển, nhấn mạnh và phát huy các quyết định nhanh chóng và nâng cao mức độ hiểu biết của Nhóm Phát triển về dự án. Cuộc họp này là chìa khóa của cơ chế thanh tra và thích nghi trong Scrum.

(Tham khảo vi.wikipedia.org)