Agile thú vị hơn mình nghĩ
Bài đăng này đã không được cập nhật trong 3 năm
1. Lời mở đầu
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.
2. Agile là gì ?
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…)
3. Đánh giá về Agile
Chúng ta có một vài số liệu thống kê
như sau:
-
Về
lý do
nên sử dụng Agile: -
Về
lợi ích
của Agile: -
Về
cải tiến
thực tế khi áp dụng Agile: -
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
...
4. Waterfall
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.
5.Lịch sử Agile
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 đó.
6. Lộ trình học tập
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. Agile
7.1 Tổng quan về Agile
- 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.
-
Đặ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...
-
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ó được
public
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 địnhthươ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ủatechnology
sẽ giúp chúng ta lựa chọn quy trình phát triển phù hợp.
-
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 đếnthà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étchính xác
cũng như nhữngfeedback
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.
-
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).
- 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.
- 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.
- 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ò
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
All rights reserved