TỔNG QUAN AGILE – PHẦN MỞ ĐẦU: ĐẶC TRƯNG - HanoiScrum

Một gợi ý quan trọng: Quý độc giả nên đọc thêm về những bài viết của GS John Vu về Agile & Scrum tại link cuối bài nhé!

________________________

 Phát triển phần mềm linh hoạt (agile software development – gọi tắt là Agile) là một triết lí cùng với nhóm các phương pháp và phương pháp luận phát triển phần mềm dựa trên các nguyên tắc phát triển phân đoạn lặp (iterative) và tăng trưởng (incremental), theo đó nhu cầu và giải pháp tiến hóa thông qua sự hợp tác giữa các nhóm tự quản và liên chức năng. Agile thường sử dụng cách lập kế hoạch thích ứng (adaptive planning), việc phát triển và chuyển giao theo hướng tiến hóa; sử dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển. Ngày nay, triết lí Agile đã vượt xa khỏi khu vực truyền thống của mình là phát triển phần mềm để đóng góp sự thay đổi trong cách thức làm việc, quản lí, sản xuất ở các ngành khác như sản xuất (manufacturing), dịch vụ, sales, marketing, giáo dục v.v.


Thuật ngữ "Agile" chính thức được sử dụng rộng rãi theo cách thống nhất kể từ khi “Tuyên ngôn Agile” được giới thiệu ra công chúng năm 2001. Nhờ tính linh hoạt, đa dạng và hiệu quả cao, các phương pháp Agile ngày càng trở thành sự lựa chọn hàng đầu của các khách hàng, nhà phát triển, các công ty phát triển phần mềm. Theo khảo sát của hãng nghiên cứu thị trường Forrester, mức độ phổ biến của Agile hiện đang ở mức cao nhất, và gấp nhiều lần so với các phương pháp truyền thống như thác nước hay CMMi (xem Hình 1). Hơn thế , một số phương pháp Agile có xuất xứ và được sử dụng hiệu quả ngoài phạm vi phát triển phần mềm.


Tuyên ngôn Agile (Agile Manifesto)
Vào tháng Hai năm 2001, mười bảy nhà phát triển phần mềm đã gặp gỡ nhau ở Snowbird, Utah Resort để thảo luận về các phương pháp phát triển phần mềm gọn nhẹ và linh hoạt. Họ đã cùng nhau công bố “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”) để định nghĩa cách hiểu về Phát triển phần mềm linh hoạt. Đây là cột mốc quan trọng của agile. Dù trước đó, các phương pháp agile như XP, Scrum, v.v. đã được sử dụng thành công ở rất nhiều nơi, nhưng phải tới khi có sự xuất hiện của “Tuyên ngôn Agile”, cùng với sự ra đời của các hiệp hội chuyên ngành agile như Agile Alliance hay Scrum Alliance, các phương pháp agile mới có một sự phát triển vượt bậc. Văn bản này rất ngắn, dễ hiểu, và rất quan trọng vì nó đưa ra các giá trị cốt lõi nhất mà toàn bộ các nhà lý thuyết cũng như những người thực hành Agile tuân thủ; mặc dù các phương pháp họ đề xuất hoặc sử dụng trong thực tiễn có thể rất khác nhau. Toàn văn Tuyên ngôn Agile như sau:
___________________________________________________
Tuyên ngôn Phát triển phần mềm linh hoạt
Chúng tôi đã phát hiện ra cách phát triển phần mềm tốt hơn bằng cách thực hiện nó và giúp đỡ người khác thực hiện.
Qua công việc này, chúng tôi đã đi đến việc đánh giá cao:
Cá nhân và sự tương táchơ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ácvới khách hàng hơn là đàm phán hợp đồng;
Phản hồi với các thay đổihơn là bám sát kế hoạch.
Mặc dù các điều bên phải vẫn còn giá trị, nhưng chúng tôi đánh giá cao hơn các mục ở bên trái.
___________________________________________________
Bên cạnh đó, các nhà phát triển còn nhấn mạnh mười hai nguyên lý phía sau Tuyên ngôn Agile để giúp các nhà phát triển có được gợi ý trong thực hành và vận dụng các phương pháp agile trong thực tiễn. Các nguyên lý được liệt kê sau đây:
Ưu tiên cao nhất của chúng tôi là thỏa 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ị.
Chào đón việc thay đổi yêu cầu, thậm chí rất muộn 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.
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 đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn.
Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án.
Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc.
Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực tiếp.
Phần mềm chạy tốt là thước đo chính của tiến độ.
Các quy trình linh hoạt thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát triển, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn.
Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt.
Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản.
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 sẽ được làm ra bởi các nhóm tự tổ chức.
Đội sản xuất 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 các hành vi của mình cho phù hợp.
Các nguyên lý này, cùng với năm điểm cốt lõi trong "Tuyên ngôn Agile" sẽ dẫn đường cho các nhà thực hành agile (agile practictioner) vận dụng tốt các phương pháp agile vào thực tiễn. Các nguyên lí này được Jeff Sutherland diễn giải chi tiết, xem tại đây.
Đặc trưng Agile
Có rất nhiều phương pháp agile với các hướng tiếp cận rất khác nhau. Bên cạnh các cách thức tổ chức công việc, thiết lập quy trình, các phương pháp agile còn nghiên cứu và đưa vào sử dụng các công cụ và kĩ thuật đặc thù như công cụ tích hợp liên tục (continuous integration), kiểm thử đơn vị, mẫu thiết kế, tái cấu trúc, phát triển hướng kiểm thử (TDD), phát triển hướng hành vi (BDD), hay lập trình theo cặp v.v. để đảm bảo và gia tăng tính linh hoạt. Tuy vậy các phương pháp này chia sẻ nhiều đặc trưng giống nhau cộng tác nhóm chặt chẽ, tổ chức các nhóm tự quản, liên chức năng, tính đáp ứng cao trong suốt vòng đời của dự án.
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. Các phân đoạn (được gọi là Iteration hoặc Sprint) này thường có khung thời gian ngắn (từ một đến bốn tuần). Trong mỗi phân đoạn này, 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ử (với các mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm. Các phương pháp agile thường phân rã mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và không thực hiện việc lập kế hoạch dài hạn. Có phương pháp như Scrum thậm chí sử dụng phương pháp lập kế hoạch just-in-time trong quá trình phát triển. Khi đó, thậm chí công việc lập kế hoạch, làm mịn kế hoạch được thực hiện liên tục trong suốt quá trình làm việc.


Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary)
Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng. Các phần nhỏ này 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 ngay (gọi là potentially shippable product increment of functionality). 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. Khác với mô hình phát triển Thác nước – vốn chỉ cho phép nhìn thấy toàn bộ các chức năng tại thời điểm kết thúc dự án, sản phẩm trong các dự án agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt được trạng thái đủ để phát hành.
Tính thích ứng (hay 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 . Ví dụ, trong Scrum – phương pháp phổ biến nhất hiện nay – trong khi nhóm phát triển sản xuất ra các gói phần mềm, khách hàng có thể đưa thêm các yêu cầu mới, chủ sản phẩm (Product Owner) có thể đánh giá các yêu cầu này và có thể đưa vào làm việc trong phân đoạn (được gọi là Sprint trong Scrum) tiếp theo. Theo đó, các quy trình agile thường thích ứng rất tốt với các thay đổi.
Nhóm tự tổ chức và liên chức năng
Cấu trúc nhóm agile thường là liên chức năng(cross-functionality) và tự tổ chức(self-organizing). Theo đó, các nhóm này tự thực hiện lấy việc 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 (title) hay làm việc dựa trên một sự phân cấp rõ ràng trong tổ chức. Các nhóm này cộng tác với nhau để ra quyết định, theo dõi tiến độ, giải quyết các vấn đề mà không chờ mệnh lệnh của các cấp quản lý. Họ không làm việc theo cơ chế “mệnh lệnh và kiểm soát” (command and control). Nhóm tự tổ chức có nghĩa là nó đã đủ các kĩ năng (competency) cần thiết cho việc phát triển phần mềm, do vậy nó 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 (prescription). Việc phân nhỏ dự án thành các phân đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển thu thập dữ kiện cho phép điều chỉnh các chiến lược phát triển của mình. Nói cách khác, Agile rút ngắn vòng đời phản hồi (short feedback life cycle) để dễ dàng thích nghi và gia tăng tính linh hoạt. Theo thời gian, các chiến lược này sẽ tiến gần đến trạng thái tối ưu, nhờ đó nhóm 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)
Một số mô hình phát triển phần mềm dựa rất nhiều vào công việc giấy tờ, từ việc thu thập yêu cầu người dùng, viết đặc tả hệ thống, các thiết kế hệ thống v.v. Agile không phản đối công dụng của công 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ì gián tiếp thông qua giấy tờ. Về yêu cầu của khách hàng, agile khuyến khích nhóm phát triển trực tiếp nói chuyện với khách hàng để hiểu rõ hơn về cái khách hàng thực sự cần, thay vì phụ thuộc nhiều vào các loại văn bản. Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình viên (thực hiện việc mã hóa) và một kĩ sư (thực hiện việc thiết kế) giao tiếp với nhau thông qua bản thiết kế, agile khuyến khích hai người này 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.
Bản thân các nhóm agile thường nhỏ (ít hơn mười hai người, một nhóm lớn thường được phân nhỏ với cơ chế hợp tác đặc thù để luôn luôn có thông lượng giao tiếp tối đa) để đơn giản hóa quá trình giao tiếp, thúc đẩy việc cộng tác hiệu quả. Các dự án lớn muốn dùng agile thường phải phân thành nhóm nhỏ đồng thời làm việc với nhau hướng đến một mục tiêu chung. Việc này có thể đòi hỏi một số nỗ lực đáng kể trong việc điều phối các mức ưu tiên giữa các nhóm.
Các nhóm phát triển thường tạo ra các thói quen và cơ chế trao đổi trực diện một cách thường xuyên. Một trong các cơ chế thường thấy là các cuộc họp tập trung hằng ngày (daily meeting, Daily Scrum, standup meeting). Tại đây, tất cả các thành viên được yêu cầu nói rõ cho nhóm của mình biết mình đã làm gì, đang làm gì, sắp làm gì và đang gặp phải khó khăn nào trong quá trình làm việc. Khi cơ chế này được thực hiện hiệu quả, nhóm luôn luôn nắm được tình hình công việc của mình, có các hành động thích hợp để vượt qua các trở lực để thực hiện thành công mục tiêu của dự án.
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à “phần mềm chạy tốt chính là thước đo của tiến độ”. Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm. Ví dụ, một nhóm thấy rằng có thể không cần phải viết ra tất cả các thiết kế của hệ thống, mà họ chỉ cần phác thảo các thiết kế này lên bảng, rồi cùng nhau triển khai các chức năng của hệ thống. Nhưng nếu như chủ sản phẩm quyết định rằng, khi chuyển giao sản phẩm, nhóm phát triển phải kèm theo thiết kế chi tiết của hệ thống vì chúng chiếm 20% giá trị của dự án theo yêu cầu của khách hàng, và vì khách hàng cần nó để chứng minh tính đúng đắn của các chức năng, và để phát triển tiếp các phân hệ tiếp theo của sản phẩm; thì nhóm phát triển sẽ phải thực hiện việc tài liệu hóa đầy đủ.
Để vận hành được cơ chế “làm việc dựa trên giá trị”, nhóm agile thường làm việc trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng), cộng tác trực tiếp với họ để 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. Nhờ đó các dự án agile thường giúp khách hàng tối ưu hóa được giá trị của dự án. Một cách gần như trực tiếp, agile gia tăng đáng kể độ hài lòng của khách hàng.
Nguồn: HainoiScrum.net
____________________

 Bài viết của GS John Vu về Agile & Scrum tại TẠI ĐÂY
________________________________________

ĐỌC THÊM

Giới thiệu Vietnam Carenet TẠI ĐÂY
Tủ Sách Vietnam Carenet  TẠI ĐÂY
Các bài viết về Khởi Nghiệp  TẠI ĐÂY
Các bài viết về Lập Kế Hoạch TẠI ĐÂY
Các bài viết về Lập  Dự Án TẠI ĐÂY
Các bài viết về Quản lý Dự Án TẠI ĐÂY
Các bài viết về Kỷ Nguyên 4.0 TẠI ĐÂY

Các bài viết về Agile & Scrum TẠI ĐÂY