Agile thú vị hơn mình nghĩ

Trước đây mình cũng đã từng biết tới khái niệm Agile, và cũng đã từng làm việc với quy trình này. Nhưng chỉ dừng lại ở áp dụng suông và cũng như chưa có sự so sánh giữa Agile và các quy trình phát triển phần mềm khác.

Gần đây mình có tham gia một khóa học cơ bản về Agile, xin nhắc lại là cơ bản về Agile, trước khi tham gia mình đã nghĩ tới những giờ học lý thuyết nhàm chán, mài đi mài lại với 4 tuyên ngôn và 12 nguyên lý ba la gì đó.

Nhưng không, trước hết mình xin được gửi lời cảm ơn tới anh Hoàng Nhạc Trung (Framgia Education) về những giờ học rất thú vị và bổ ích, những trò chơi khá hấp dẫn giúp học viên hứng thú và cảm nhận được nhiều điều sâu sắc.

Sau đây, mình sẽ viết về Agile, những gì mình học được từ khóa học và từ cả những tài liệu mình tham khảo trên Internet.

Nói đơn giản 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). Trong đó khuyến khích việc lập kế hoạch thích ứng, phát triển tăng dần, chuyển giao sớm, và cải tiến liên tục.

Agile cũng chủ trương phản hồi nhanh chóng với các thay đổi, nó sẽ gắn kết khách hàng vào quy trình phát triển của sản phẩ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 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…)

Chúng ta có một vài số liệu thống kê như sau:

1. Về lý do nên sử dụng Agile:

2. Về lợi ích của Agile:

3. Về cải tiến thực tế khi áp dụng Agile:

4. Về rào cản khi áp dụng Agile:

Ở Việt Nam, Agile đã và đang được ứng dụng vào chu trình phát triển phần mềm một cách rộng rãi ở các doanh nghiệp. Điển hình nhất là các doanh nghiệp hoạt động trong lĩnh vực sản xuất phần mềm, gia công phần mềm (software outsourcing), các startup về công nghệ, các ngân hàng và công ty bảo hiểm.

Quy trình này đã giúp nhiều doanh nghiệp mang lại giá trị nhất định giúp cho đội dự án chuyển giao phần mềm nhanh hơn, sản phẩm phần mềm chất lượng hơn, đội ngũ trưởng thành nhanh hơn và ít rủi ro hơn so với cách quản trị dự án truyền thống. Điều mà các tập đoàn hàng đầu trên thế giới đã thực hành và khai thác tính nhanh nhẹn của Agile gần 20 năm qua.

Với những giá trị ấy mà nhiều doanh nghiệp phần mềm Việt, hoặc bộ phân CNTT của các doanh nghiệp đua nhau triển khai Agile. Các nhà tuyển dụng trên thị trường Việt và khu vực ưu tiên tuyển những ứng viên có kiến thức và kinh nghiệm về Agile Scrum.

Tuy nhiên, từ những số liệu trên bạn cũng sẽ thấy rằng Agile không phải là tuyệt hảo, không phải cứ áp dụng Agile là mọi thứ ngon nghẻ và cũng không phải dự án nào cũng nên áp dụng nó. Sau đây chúng ra sẽ tìm hiểu dần dần nhé !

Trước hết, hãy tìm hiểu một mô hình truyền thống- Waterfall (mô hình thác nước) chẳng hạn. Ngoài mô hình thác nước còn một số mô hình cổ điển khác như mô hình xoắn ốc hoặc mô hình phát triển lặp ...

Waterfall là một mô hình của quy trình phát triển phần mềm, trong đó quy trình phát triển trông giống như một dòng chảy, với các pha được thực hiện theo trật tự nghiêm ngặt và không có sự quay lui hay nhảy vượt pha, cụ thể:

Như vậy, waterfall (mô hình thác nước) ngụ ý rằng, việc chuyển từ pha phát triển này sang pha khác sẽ diễn ra chỉ sau khi các pha trước đó đã kết thúc hoàn toàn thành công, và không thể quay lui về pha trước đó hay nhảy vượt pha.

Ta thấy mô hình này khá đơn giản, từ đó dẫn đến dễ hiểu, ngoài ra nó khá ổn định (một khi đã quyết định specs của sản phẩm thì hầu như sẽ không thay đổi nữa), chất lượng cao (ưu tiên cho chất lượng sản phẩm chứ không phải thời gian).

Thế nhưng cũng như cái tên thác nước vậy, nếu như công đoạn ở trên gặp lỗi thì toàn bộ công đoạn phía dưới sẽ gặp lỗi theo, tính linh hoạt là khá thấp, trước khi bắt tay vào công việc phải nghiên cứu thật kỹ các chú ý phát triển hay yêu cầu thiết kế ...

Do vậy, Waterfall phù hợp với những dự án có yêu cầu đơn giản, rõ ràng ngay từ đầu.

Thế đối với những dự án phức tạp, đòi hỏi công nghệ cao hoặc yêu cầu không rõ ràng, đôi khi chỉ là một idea thì sao ? Đất dụng võ cho Agile đây rồi.

Trong giai đoạn những năm 90 của thế kỷ 20, trên thế giới đã xảy ra cuộc khủng hoảng về phương pháp phát triển phần mềm. Do phương pháp truyền thống ngày càng bộc lộ nhiều nhược điểm và tỉ tệ các dự án bị thất bại quá cao, những yếu tố môi trường kinh doanh và công nghệ thay đổi nhanh chóng, khiến cho phương pháp phát triển truyền thống không còn phù hợp.

Để thích nghi, tồn tại và phát triển, có rất nhiều các cá nhân và công ty riêng lẻ đã tự tìm tòi và phát triển những phương pháp khác nhau để thích ứng với tình hình mới. Những phương pháp riêng lẻ này phần nào giải quyết được một số vấn đề, nhưng lại nảy sinh những vấn đề khác về sự chia sẻ, cộng tác, các kỹ thuật, công cụ, sự mở rộng, hướng phát triển,…

Do đó, tháng 2 năm 2001, 17 lập trình viên là đại diện cho những phương pháp phát triển mới này đã gặp nhau tại Utah. Họ đã đi đến thống nhất về quan điểm chung giữa các phương pháp và cho ra đời một tài liệu được gọi là: Tuyên ngôn Phát triển Phần mềm Linh hoạt kèm với 12 nguyên lý phía sau. Đây chính là thời điểm mà thuật ngữ Agile được sử dụng hiện nay ra đời, mặc dù các phương pháp riêng lẻ thì đã có trước đó.

Các bạn có thể tham khảo trên đây là lộ trình học tập để trở thành Master Agile (từ trái qua phải). Nó là một quá trình rất dài về lý thuyết và cả thực tiễn, có nội dung Agile dành riêng cho Dev, dành riêng cho Test và cả Leadership nữa.

Sai lầm mà nhiều doanh nghiệp mắc phải khi chuyển sang áp dụng Agile là cử một vài cá nhân (thường là team lead hoặc tester) tham gia một khóa học ngắn hạn về Agile và trở về áp dụng nó cho vào thực tiễn.

Nếu bạn chỉ đang làm việc trong một dự án với quy trình Agile thì khả năng cao bạn đang ở mức Doing Aglie. Còn để Being Agile thực sự thì đó là một chặng đường khá dài.

7.1 Tổng quan về Agile

1. Nhắc đến Agile thì không nên thiếu sót 4 tuyên ngôn và 12 nguyên lý.

Nhưng mình sẽ không đi chi tiết ở đây, bởi vì nó khá là dài.

Và các bạn search google một chút có rất rất (thêm phát nữa) rất nhiều tài liệu nói về những điều này.

Bài này sẽ focus về những điều khác xung quanh Agile.

1. Đặc trưng của Agile là có thể tùy biến, linh động, là phương thức phát triển sáng tạo vì vừa có thể thay đổi vừa có tính tương tác.

   Cứ theo chu kỳ 1 tuần hoặc 2 tuần (sprint), có thể bổ sung hoặc thay đổi phương hướng của project.

   Có lẽ Agile cũng là phương thức phát triển có thể tạo ra sản phẩm demo nhanh nhất. Nhờ đó mà việc đánh giá và test cũng sẽ được tiến hành sớm hơn...

1. Một nhóm sinh viên khi lên trường nạp baì tập nhận ra rằng mình đã không mang USB chứa dữ liệu theo và họ suy nghĩ tại sao không tạo một kho lưu trữ dữ liệu trên mây, chỉ cần có kết nối internet và tải dữ liệu về.

   Do vậy họ đã xây dựng một sản phẩm với tính năng như vậy, nó đượcpublic dần và càng ngày nhận được càng nhiều sự quan tâm. Sau đó, ngày càng cải tiến và xây dựng thêm các chức năng, sau khi đạt được thành tựu nhất định, họ quyết định thương mại hóa nó, Dropbox đã ra đời như vậy.

   Đó là một ví dụ về một dự án chỉ đơn thuần là một idea, ít hữu hình, thế giới công nghệ ngày càng hiện đại và chúng ta không thể bao quát hết mọi thứ từ đầu.

   Phụ thuộc vào mức độ rõ ràng của requirements và độ khó của technology sẽ giúp chúng ta lựa chọn quy trình phát triển phù hợp.

1. Với waterfall, mọi thứ là tuần tự nhưng đối với Agile: Short feedback time, Hight value feedback first

   Mình đã được nghe một câu chuyện thế này: Có một team xây dựng sản phẩm quản lý địa điểm du lịch trên google map theo quy trình Agile, khi đó khách hàng yêu cầu demo sớm chức năng hiển thị địa điểm trên google map (hiển thị ra sao, bài trí, phân bổ, dẫn đường như thế nào ... )

   Và dev đã phàn nàn rằng chưa có dữ liệu, chưa kịp liên kết API, login, logout... mà khách hàng đã yêu cầu demo chức năng lớn, khó để chuẩn bị đầy đủ, quá gấp gáp. Khi đó Agile Master đã can thiệp và giải thích rằng:

   Đứng ở khía cạnh khách hàng, chức năng này mới là điều quan trọng nhất và cũng có độ khó cao nhất (hight value), ảnh hưởng đến thành công của toàn bộ dự án. Khi nó được demo sớm thì khách hàng sẽ đánh giá được mức độ khả thi, có nhận xét chính xác cũng như những feedback quan trọng.

   Từ đó team sẽ có những bước đi, xác định công nghệ cho dự án, chuẩn bị thời gian học hỏi,... còn login/logout,... là những chức năng có giá trị thấp (low value), có thể xây dựng về sau, tỉ lệ thành công cao.

   Càng demo sớm sẽ có feedback sớm và càng chủ động giải quyết, giảm thiểu chi phí phát sinh.

   Short feedback time. Hight value feedback first là vậy.

1. Agile không fix cứng.

   Giả sử bạn đang thực hiện dự án muốn xây dựng tòa nhà cao 73 tầng tại Hà Nội, vượt qua toà nhà KeangNam LandMark 72, trở thành tòa nhà cao nhất Việt Nam. Hight value ở đây rõ ràng nằm ở tầng thứ 73.

   Vậy bạn sẽ xây dựng tầng 73 trước và bỏ qua hoặc làm sơ sài phần móng và các tầng bên dưới ư.

   Ồ không, Agile không khuôn dập như vậy. Trong dự án thực tế sẽ có những trường hợp khó để phát hiện hơn, đó cũng là một trong những lý do tại sao không nên để một member đi học một khóa Agile ngắn hạn về rồi triển khai Agile cho toàn bộ công ty.

   Có lẽ bạn cũng đã biết tới quy tắc này rồi chứ (Chưa biết thì Google nhé)

   

7.2 Các phương pháp Agile

Ta có thể hiểu Agile là một tập rule, không định nghĩa một phương pháp cụ thể để đạt được những điều này, nhưng lại có nhiều phương pháp phát triển phần mềm khác nhau thỏa mãn và hướng theo các tiêu chí đó.

Scrum là phương pháp được áp dụng nhiều nhất, sau đó tới Scrum/XP và Kanban. Trong bài này mình sẽ nói về Scrum va Kanban.

7.3 Scrum

7.3.1 Sơ lược về Scrum

Thuật ngữ Scrum xuất hiện từ một bài viết trên tạp chí Harvard Business Review của Hirotaka Takeuchi và Ikujiro Nonaka năm 1986 khi mô tả một cách tiếp cận toàn diện trong việc phát triển sản phẩm mới, trong đó nhóm dự án được tạo thành từ những nhóm nhỏ liên chức năng làm việc hướng tới một mục tiêu chung.

Những nhóm này được so sánh tới sự hình thành Scrum trong môn bóng bầu dục – một cơ chế để đưa “bóng chết” vào cuộc chơi (Scrum có nghĩa là chen lấn, hàm ý sự hỗn độn, liên chức năng và tự quản cao độ trong các tình huống thực tiễn).

Khái niệm Scrum tiếp tục được phát triển qua nhiều năm gắn với cá nhu cầu phát triển ứng dụng nhanh, cải tiến năng suất, xây dựng qui trình thực nghiệm liên tục yêu cầu sự thanh tra và thích nghi. Sau đó, nó được Jeff Sutherland và Ken Schwaber tóm tắt lại và tạo ra một phương pháp luận mới đặt tên là Scrum, đẩy Scrum trở thành một trong những qui trình Agile có những giá trị và nguyên lý như mô tả trong Tuyên ngôn Agile.

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.

Dự án được cắt nhỏ thành các vòng lặp nhỏ được gọi là Sprints. Mỗi Sprint thường kéo dài từ 2-4 tuần.

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

7.3.2 Ba giá trị cốt lõi

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.

1. 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.

1. 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.

7.3.3 Ba vai trò

1. Vai trò Scrum Master(SM) Là một trong ba vai trò được định nghĩa trong Scrum framework. Trách nhiệm chính của Scrum Master là đảm bảo Product Owner và Development team hiểu Scrum framework, ứng dụng được lý thuyết Scrum, thực hành thành thạo, và tuân thủ các quy tắc Scrum. Được biết đến như một lãnh đạo phục vụ, không có quyền lực. Mọi người sẽ thấy SM quan trọng như thế nào cho đến khi vị trí này bỏ đi.

2. Vai trò Product Owner (PO) Là một trong ba vai trò được định nghĩa trong Agile Scrum. Trách nhiệm chính của Product Owner là làm sao để tối ưu hoá giá trị của sản phẩm thông qua việc quản lý product backlog.

3. Vai trò Development Team (T) Đội phát triển (Development team) là một trong ba vai trò trong dự án Agile Scrum. Đội phát triển bao gồm các thành viên chuyên nghiệp làm việc cùng nhau để tạo ra sản phẩm có khả năng phát hành ở cuối mỗi sprint. Và giúp khách hàng và người dùng đạt giá trị thông qua phần mềm sớm hơn.

7.3.4 Bốn cuộc họp

1. Sprint planning 1/2: Diễn ra vào đầu Sprint, nhóm nghiên cứu gặp gỡ và chuẩn bị công việc cho Sprint sắp tới.

2. Dayily Metting: Cuộc họp này diễn ra hàng ngày, khuyến khích mọi người đứng cùng nhau để tham gia.

3. Review: Nó diễn ra vào cuối Sprint, nội dung xoay quanh một bài đánh giá về công việc đã diễn ra.

4. Retrospective: Cuộc họp này diễn ra nhằm rút kinh nghiệm về những gì đã làm tốt / những gì đã sai sót để cải thiện.