AGILE LÀ GÌ? AGILE SCRUM LÀ GÌ? TÌM HIỂU TẤT CẢ TRONG BÀI VIẾT NÀY
Agile là gì? Scrum là gì? Tại sao hai từ này hay được nhắc chung với nhau. Bài viết này sẽ giúp startups tìm hiểu tổng quan về hai thuật ngữ này, cũng như mang đến những thông tin giá trị dành cho doanh nghiệp có nhu cầu phát triển phần mềm. Chúng ta sẽ cùng đi sâu vào chi tiết.
Agile là gì?
Agile là một phương thức phát triển phần mềm linh hoạt, với tiêu chí là đưa sản phẩm đến tay người dùng nhanh nhất có thể.
Rất nhiều người định nghĩa Agile là một phương pháp. Đúng hơn, Agile giống như một phương pháp luận, một triết lý dựa trên nguyên tắc phân đoạn vòng lặp (iterative) và tăng trưởng (incremental). Chúng ta sẽ nói phần này sau!
Hiện nay, triết lý Agile không còn gói gọn trong phát triển phần mềm, mà còn được áp dụng rộng rãi và góp công vào sự thay đổi trong cách thức làm việc, quản lý, sản xuất,… trở thành một phương thức quản lý dự án phổ biến nhất hiện nay.
Tuyên ngôn Agile(Agile Manifesto)
Tuyên ngôn Phát triển phần mềm linh hoạt (Manifesto for Agile Software Development – gọi tắt là Tuyên ngôn Agile) đã đưa ra các tôn chỉ mà các nhà lý thuyết cũng như các nhà thực hành đều phải tuân thủ. 4 tôn chỉ đó là:
- CÁ NHÂN VÀ SỰ TƯƠNG TÁC hơn QUY TRÌNH VÀ CÔNG CỤ: Đặt trọng tâm vào yếu tố con người, xây dựng tính tương tác, tương trợ giữa các thành viên trong nhóm. Sự kết hợp giữa những con người giỏi sẽ mang về thành công cho dự án.
- PHẦN MỀM CHẠY TỐT hơn TÀI LIỆU ĐẦY ĐỦ: Tập trung thời gian để phát triển sản phẩm phần mềm đáp ứng tốt nhu cầu của khách hàng.
- CỘNG TÁC VỚI KHÁCH HÀNG hơn ĐÀM PHÁN HỢP ĐỒNG: Thấu hiểu nhu cầu của khách hàng để tư vấn và cung cấp sản phẩm phù hợp thay vì chỉ dựa theo các điều khoản trong hợp đồng.
- PHẢN HỒI VỀ SỰ THAY ĐỔI hơn BÁM SÁT KẾ HOẠCH: Thích nghi với sự thay đổi thay vì chỉ làm theo kế hoạch ban đầu. Những thay đổi có thể là công nghệ, nhân sự, yêu cầu…
12 nguyên tắc phía sau tuyên ngôn Agile
Tuyên ngôn Agile giúp các nhà phát triển rút ra được các nguyên lý để thực hành và vận dụng phương thức Agile trong thực tiễn phát triển dự án. 12 nguyên lý đó sẽ được liệt kê ngay:
- Đáp ứng tốt nhất nhu cầu của khách hàng thông qua chất lượng sản phẩm cao cùng thời gian bàn giao sớm.
- Ủng hộ việc thay đổi yêu cầu từ phía khách hàng, thậm chí là yêu cầu muộn trong quá trình phát triển. Các quy trình linh hoạt luôn phải thay đổi để giúp khách hàng chiếm lợi thế cạnh tranh.
- Giao phần mềm chạy được cho khách hàng một cách thường xuyên nhất có thể.
- Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau trong suốt dự án.
- Xây dựng dự án xung quanh những cá nhân có động lực. Cung cấp sự hỗ trợ cần thiết, tạo môi trường và niềm tin để họ hoàn thành công việc.
- Trao đổi trực tiếp là phương pháp truyền đạt thông tin hiệu quả nhất.
- Phần mềm chạy tốt là thước đo chính của tiến độ.
- Phát triển liên tục và bền vững. Các nhà tài trợ, nhà kinh doanh và nhà phát triển cần duy trì nhịp độ liên tục.
- Cải tiến sự linh hoạt bằng cách chú trọng đến kỹ thuật và thiết kế.
- Sự đơn giản là căn bản của nghệ thuật tối đa hóa lượng công việc chưa xong.
- Nhóm tự tổ chức luôn tạo ra được các kiến trúc tốt nhất, yêu cầu tốt nhất và thiết kế tốt nhất.
- Thường xuyên tìm cách để trở nên hiệu quả hơn và thích ứng với sự thay đổi.
Những đặc trưng của Agile
- Tính lặp (Iterative): Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại (Iteration hoặc Sprint), thường có khung thời gian ngắn (từ 1-4 tuần). Trong mỗi phân đoạn, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử để cho ra các phần nhỏ của sản phẩm.
- Tính tăng trưởng và tiến hóa (Incremental & Evolutionary): Cuối các phân đoạn, nhóm cho ra các phần nhỏ của sản phẩm cuối cùng, thường là đầy đủ, có khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử dụng. Theo thời gian, phân đoạn này tiếp nối phân đoạn kia, các phần chạy được này sẽ được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn.
- Tính thích nghi (adaptive): Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn và việc lập kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu v.v.) đều có thể được đáp ứng theo cách thích hợp.
- Nhóm tự tổ chức và liên chức năng: Các cấu trúc nhóm này tự phân công công việc mà không dựa trên các mô tả cứng về chức danh hay làm việc dựa trên một sự phân cấp rõ ràng trong tổ chức. Nhóm tự tổ chức đã đủ các kỹ năng cần thiết để có thể được trao quyền tự ra quyết định, tự quản lý và tổ chức lấy công việc của chính mình để đạt được hiệu quả cao nhất.
- Quản lý tiến trình thực nghiệm (Empirical Process Control): Các nhóm Agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì tính toán lý thuyết hay các tiền giả định. Agile rút ngắn vòng đời phản hồi để dễ dàng thích nghi và gia tăng tính linh hoạt nhờ đó có thể kiểm soát được tiến trình, và nâng cao năng suất lao động.
- Giao tiếp trực diện (face-to-face communication): Agile không phản đối việc tài liệu hóa, nhưng đánh giá cao hơn việc giao tiếp trực diện thay vì thông qua giấy tờ. Agile khuyến khích nhóm phát triển trực tiếp nói chuyện để hiểu rõ hơn về cái khách hàng thực sự cần. Trong giao tiếp giữa nội bộ nhóm, Agile khuyến khích trực tiếp trao đổi và thống nhất với nhau về thiết kế của hệ thống và cùng nhau triển khai thành các chức năng theo yêu cầu.
- Phát triển dựa trên giá trị (value-based development): Một trong các nguyên tắc cơ bản của agile là “sản phẩm chạy tốt chính là thước đo của tiến độ”. Nhóm Agile thường cộng tác trực tiếp và thường xuyên với khách hàng để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn sớm nhất có thể cho dự án.
Các phương pháp Agile
Chúng ta sẽ cùng điểm qua một số phương pháp Agile phổ biến:
- Scrum: theo Tài liệu Hướng dẫn Scrum (The Scrum Guide) được 2 nhà đồng sáng lập Ken Schwaber and Jeff Sutherland định nghĩa, là một khung làm việc (framework) để phát triển bền vững các sản phẩm phức tạp. Có thể nói Scrum là một trong những phương pháp Agile quan trọng nhất sử dụng cơ chế lặp (iterative) và tăng trưởng (Incremental) để tối ưu hóa hiệu quả cũng như kiểm soát rủi ro.
- Kanban: là một phương pháp Agile dựa trên Phương thức Sản xuất Toyota với bốn nguyên lý: Trực quan hóa công việc, giới hạn công việc đang làm, tập trung vào luồng làm việc, cải tiến liên tục. Mô hình Kanban phù hợp cho việc hỗ trợ sản xuất trong quá trình làm việc.
- Scrumban: là một phương pháp được Corey Ladas giới thiệu vào năm 2009 trong cuốn sách với tựa đề “Scrumban – Essays on Kanban Systems for Lean Software Development”. Scrumban kết hợp được những ưu điểm của Scrum và Kanban để cho phép nhóm liên tục cải tiến quy trình và khả năng xử lý công việc.
- Lean Software Development (LSD): hay Phát triển phần mềm tinh gọn là hình thức áp dụng Tư duy tinh gọn (Lean Thinking) và các nguyên lý đặc trưng của Tinh gọn (xuất phát từ ngành sản xuất ô tô – Lean Manufacturing) cho lĩnh vực phát triển phần mềm. Thuật ngữ Lean Software Development có nguồn gốc từ một cuốn sách cùng tên của Mary Poppendieck và Tom Poppendieck. Trong đó, bảy nguyên lý diễn giải tư duy Tinh gọn bao gồm: Loại bỏ lãng phí, Khuếch trương việc học, Quyết định càng muộn càng tốt, Chuyển giao càng nhanh càng tốt, Trao quyền cho nhóm, Tạo ra tính toàn vẹn tự thân, Thấy toàn cảnh là linh hồn cho quá trình phát triển phần mềm tinh gọn.
- XP (Extreme Programming) – Hay lập trình cực hạn là một phương pháp phát triển phần mềm thuộc họ Agile được phát minh bởi Ken Beck – một kỹ sư phần mềm người Mỹ. XP hướng đến việc nâng cao chất lượng phần mềm và khả năng đáp ứng với thay đổi yêu cầu người dùng. XP chủ trương đưa ra các bản phát hành thường xuyên thông qua các chu trình phát triển ngắn. Một số các thực hành của XP như: Lập trình cặp (Pair programming), Tái cấu trúc mã nguồn (Refactoring), Kiểm thử đơn vị (Unit Testing), Tích hợp liên tục (Continuous Integration), Các bản phát hành nhỏ (Small Release).
Lợi ích khi áp dụng Agile
Agile được tạo ra cho ngành công nghiệp phát triển phần mềm để hỗ trợ cho việc sắp xếp và cải tiến quá trình sản xuất. Là một phương pháp thay thế cho phương pháp Thác nước (Waterfall) truyền thống, Agile mang đến cách quản lý giúp nhóm làm việc hiệu quả hơn, cho ra đời sản phẩm tốt hơn và nhanh hơn thông qua các phiên ngắn và các phiên tương tác/ các sprint. Một số lợi thế khi áp dụng Agile có thể kể đến như:
- Thay đổi dễ dàng: Lý do bởi dự án được chia thành các phần nhỏ, riêng biệt và không phụ thuộc lẫn nhau, nên những thay đổi ở bất kỳ giai đoạn nào của dự án đều được thực hiện rất dễ dàng.
- Không cần phải nắm tất cả thông tin ngay từ đầu: Phù hợp với những dự án chưa xác định được mục tiêu cuối cùng, việc này cũng không quá cần thiết trong giai đoạn đầu.
- Bàn giao nhanh hơn: Việc chia nhỏ dự án cho phép đội ngũ phát triển có thể kiểm tra từng phần, xác định và sửa lỗi nhanh hơn, bàn giao công việc nhất quán và hoàn thành nhanh hơn.
- Chú ý đến phản hồi khách hàng và người dùng: Cả khách hàng và người dùng cuối đều có thể đóng góp ý kiến và phản hồi, điều đó có ảnh hưởng tích cực tới sản phẩm cuối cùng.
- Cải tiến liên tục: Agile khuyến khích các thành viên làm việc và thúc đẩy khách hàng phản hồi, điều đó giúp các giai đoạn được kiểm tra liên tục và cải thiện lại nếu cần.
Một vài nhược điểm của Agile
- Khó lên kế hoạch dự án: Việc xác định chính xác thời gian bàn giao sản phẩm cuối cùng là rất khó, bởi dự án được chia nhỏ thành nhiều phần, và mỗi phần lại có thời hạn bàn giao riêng biệt.
- Bắt buộc phải hướng dẫn và đào tạo chi tiết: Phương pháp Agile phức tạp hơn nhiều so với phương pháp truyền thống. Nhà phát triển hay nhà kinh doanh sẽ cần phải trải qua đào tạo, hướng dẫn thì mới có thể nắm được một cách rõ ràng, đặc biệt là thời gian đầu.
- Ít tài liệu hướng dẫn: Vì Agile thay đổi rất linh hoạt nên các tài liệu cũng thường bị bỏ qua, vì không xác định rõ được kỳ vọng và thành phẩm ngay từ đầu. Mặc dù tài liệu không phải là yếu tố quan trọng nhất, nhưng chúng vẫn rất cần thiết.
- Bắt buộc phải có sự hợp tác: Điều này đòi hỏi một sự cam kết về thời gian từ cả hai bên trong suốt thời gian của dự án. Phải có sự tham gia tích cực của người dùng và liên tục cộng tác để nó hoạt động.
- Chi phí cao: Chi phí thực hiện theo phương pháp Agile thường cao hơn một chút so với các phương pháp phát triển khác.
Scrum là gì?
Scrum như đã nói ở trên là một “bộ khung làm việc” để tiếp cận những công việc phức tạp. Dựa trên bộ khung này, nhóm làm việc có thể áp dụng những quy trình, kỹ thuật… khác nhau để hoàn thành công việc. Scrum là một thành viên của “họ Agile”.
Ba điểm cốt lõi của scrum
-
Minh bạch
Muốn áp dụng thành công Scrum, các thông tin liên quan đến quá trình phải mình bạch và thông suốt. Các thông tin có thể là mục tiêu của sản phẩm, yêu cầu của khách hàng, tiến độ công việc,… Từ đó mọi thành viên ở vai trò khác nhau có đầy đủ thông tin cần thiết để đưa ra quyết định trong việc nâng cao hiệu quả công việc.
-
Thanh tra
Phải thường xuyên thanh tra các hoạt động trong Scrum và tiến độ thực hiện để xác định các điểm bất thường. Tần suất thanh tra không nên quá dày để không ảnh hưởng đến công việc. Công tác thanh tra 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, giúp cải tiến liên tục trong Scrum.
-
Thích nghi
Scrum mang lợi thế là tính linh hoạt rất cao và dễ dàng thích nghi. Dựa vào thông tin liên tục và minh bạch từ quá trình thanh tra và làm việc, Scrum có thể mang lại các thay đổi tích cực, nhờ đó mang lại thành công cho dự án.
Lợi ích của Scrum trong phát triển phần mềm
Chúng ta sẽ đến với những lợi ích khi áp dụng Scrum trong phát triển phần mềm:
- Cải thiện chất lượng sản phẩm, dễ học và dễ sử dụng.
- Bàn giao nhanh, cho phép khách hàng sử dụng sản phẩm sớm hơn.
- Nâng cao tinh thần đồng đội, tối ưu hóa hiệu quả và nỗ lực của đội phát triển.
- Gia tăng tỷ suất hoàn vốn đầu tư (ROI).
- Gia tăng mức độ hài lòng của khách hàng.
- Quản lý dự án tốt, cải tiến liên tục.
- Giảm thiểu rủi ro khi xây dựng sản phẩm.
Các vai trò và chức năng trong Scrum
Trong Scrum, đội ngũ tham gia phát triển phần mềm được phân chia ra ba vai trò với trách nhiệm rõ ràng nhằm đảm bảo tối ưu hóa các công việc đặc thù như sau:
- Product Owner (chủ sản phẩm): Là người chịu trách nhiệm về sự thành công của dự án, người định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm.
- Scrum Master: Là người có hiểu biết sâu sắc về Scrum và đảm bảo nhóm có thể làm việc hiệu quả với Scrum.
- Development Team (Đội sản xuất, hay Nhóm phát triển): Một nhóm liên chức năng (cross-functional) tự quản lý để tiến hành chuyển đổi các yêu cầu được tổ chức trong Product Backlog thành chức năng của hệ thống.
Các công cụ (artifacts) Scrum
Product backlog
Đây là danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án. Có thể hiểu như là danh sách yêu cầu (requirement) của dự án.
Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product Backlog Item) trong Product Backlog dựa trên các giá trị do Product Owner định nghĩa (thường là giá trị thương mại – business value).
Sprint backlog
Đây là bản kế hoạch cho một Sprint; là kết quả của buổi họp lập kế hoạch (Sprint Planning).
Với sự kết hợp của Product Owner, nhóm sẽ phân tích các yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng danh sách công việc (TODO list).
Burndown Chart
Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết còn lại để hoàn tất công việc.
Burndown Chart có thể được dùng để theo dõi tiến độ của Sprint (được gọi là Sprint Burndown Chart) hoặc của cả dự án (Project Burndown Chart).
Biểu đồ burndown không phải là một thành tố tiêu chuẩn của Scrum theo định nghĩa mới, nhưng vẫn được sử dụng rộng rãi do tính hữu ích của nó.
Quy trình vận hành của Scrum
- Product Owner tạo ra Product Backlog chứa các yêu cầu của dự án với các hạng mục được sắp theo thứ tự ưu tiên.
- Đội sản xuất sẽ thực hiện việc hiện thực hóa dần các yêu cầu của Product Owner với sự lặp đi lặp lại các giai đoạn nước rút từ 1 đến 4 tuần làm việc (gọi là Sprint). Đầu vào là các hạng mục trong Product Backlog, đầu ra là các gói phần mềm hoàn chỉnh có thể chuyển giao được (Potentially Shippable Product Increment).
- Trước khi cả nhóm cùng đua nước rút trong Sprint, đội sản xuất cùng họp với Product Owner để lập kế hoạch cho từng Sprint. Kết quả của buổi lập kế hoạch (theo cách làm của Scrum) là Sprint Backlog chứa các công việc cần làm trong suốt một Sprint.
- Trong suốt quá trình phát triển, nhóm sẽ phải cập nhật Sprint Backlog và thực hiện công việc họp hằng ngày (Daily Scrum) để chia sẻ tiến độ công việc cũng như các vướng mắc trong quá trình làm việc cùng nhau. Nhóm được trao quyền để tự quản lý và tổ chức lấy công việc của mình để hoàn thành công việc trong Sprint.
- Khi kết thúc Sprint, nhóm tạo ra các gói phần mềm có chức năng hoàn chỉnh, sẵn sàng chuyển giao (shippable) cho khách hàng. Buổi họp Sơ kết Sprint (Sprint Review) ở cuối Sprint sẽ giúp khách hàng thấy được nhóm đã có thể chuyển giao những gì, còn những gì phải làm hoặc còn gì phải thay đổi hay cải tiến.
- Sau khi kết thúc việc đánh giá Sprint, Scrum Master và nhóm cùng tổ chức họp Cải tiến Sprint (Sprint Retrospective) để tìm kiếm các cải tiến trước khi Sprint tiếp theo bắt đầu, điều này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua từng Sprint.
- Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong Product Backlog đều được hoàn tất hoặc khi Product Owner quyết định có thể dừng dự án căn cứ tình hình thực tế.
Sử dụng chiến thuật “có giá trị hơn làm trước” nên các hạng mục mang lại nhiều giá trị hơn cho chủ dự án luôn được hoàn tất trước. Do đó Scrum luôn mang lại giá trị cao nhất cho người đầu tư cho dự án. Do quy trình luôn luôn được cải tiến, nhóm Scrum thường có năng suất lao động rất cao. Đây là hai lợi ích to lớn mà Scrum mang lại cho tổ chức.
Hy vọng rằng những thông tin trên sẽ giúp ích được cho startups và enterprise.
Nếu bạn đang tìm kiếm một đối tác phát triển phần mềm tùy chỉnh, cung cấp cho bạn giải pháp phù hợp với tốc độ thực hiện dự án nhanh, chi phí hợp lý và đáng tin cậy. Tech Town rất vui lòng được trợ giúp bạn.
Liên hệ với chúng tôi để thảo luận về ý tưởng của bạn.