Trong những năm 1990, khi công nghệ thông tin bùng nổ, cũng là lúc ngành công nghệ phần mềm có những bước phát triển vượt bậc. Tuy nhiên, các nhóm phát triển phần mềm thời bấy giờ đã dần trở nên mệt mỏi, và dường như bị mắc kẹt với cách xây dựng phần mềm theo cách truyền thống – mô hình “Waterfall” (mô hình thác nước). Nói một chút về Waterfall, tất cả yêu cầu của dự án luôn được xác định từ giai đoạn đầu, sau đó đưa ra một thiết kế hoàn chỉnh, và xây dựng toàn bộ phần mềm dựa trên kế hoạch đã định trước từ đầu dự án. Điều này khiến cho các dự án được xây dựng theo mô hình Waterfall trở nên nặng nề, kém linh hoạt.
Năm 2001, một nhóm mười bảy người (có cả những người sáng lập ra Scrum và XP) cùng nhau tham dự một cuộc họp đặc biệt tại khu trượt tuyết Snowbird, ngoại ô thành phố Salt Lake, bang Utah, Mỹ. Tất cả không chắc chắn chính xác những gì sẽ được kết luận trong cuộc họp, nhưng đều có 1 sự tin tưởng mạnh mẽ rằng những phương pháp xây dựng và phát triển phần mềm mới cần phải gọn nhẹ và bớt nặng nề hơn so với cách làm truyền thống. Họ tin rằng những phương pháp mới này sẽ có những điểm chung với nhau. Từ cuộc họp đặc biệt đó, các thành viên tham dự đã không mất nhiều thời gian để đưa ra “4 values” – 4 điểm chung mà các phương pháp mới cùng có. “4 values” này, chính là Agile Manifesto – bản tuyên ngôn của Agile.
Agile thường được sử dụng trong phát triển phần mềm, tuy nhiên những ngành khác cũng có thể áp dụng Agile, vậy nên thuật ngữ software cũng có thể hiểu là system, product,… cho các ngành khác.
Câu hỏi đặt ra là tại sao không thống nhất về một phương pháp tốt nhất để làm? Tại sao chỉ dừng lại ở “4 values”?
Một trong những điều cơ bản trong công nghệ phần mềm là không có một cách tốt nhất để xây dựng một phần mềm. Tuyên ngôn Agile chỉ đưa ra các giá trị giúp cho các nhóm phát triển dự án tuân theo để đạt được tư duy Agile (Agile mindset). Khi mỗi người áp dụng được tuy duy Agile vào trong lối suy nghĩ, vào trong công việc của mình, Agile thực sự sẽ giúp ích trong việc xây dựng phần mềm/hệ thống/sản phẩm tốt hơn.
Như chúng ta có thể thấy trong hình trên, Agile Manifesto có 4 câu, trình bày theo mẫu “X over Y” thể hiện 4 values của Agile. Chúng ta sẽ cùng tìm hiểu sâu hơn về 4 values này.
over processes and tools
Các team Agile vẫn công nhận là các quy trình và công cụ rất quan trọng. Những công cụ và quy trình mà team Agile thường sử dụng có thể kể đến như: daily standups, user stories, task boards, burndown charts, refactoring, retrospectives,… (chúng ta sẽ tìm hiểu trong những bài viết sau). Những công cụ này thật sự rất hiệu quả nếu hiểu được và áp dụng đúng cách. Nhưng các team Agile vẫn đánh giá cao cá nhân và sự tương tác giữa các cá nhân hơn là quy trình và công cụ, bởi vì con người luôn là yếu tố hạt nhân trong mọi vấn đề.
Một công cụ hay quy trình có thể hiệu quả với team này nhưng có thể là vấn đề nghiêm trọng với team khác nếu họ không cảm thấy công cụ hay quy trình đó đem lại lợi ích trong công việc. Chính vì thế, khi một công cụ hay quy trình được giới thiệu, người triển khai cần hiểu được ý kiến của các thành viên trong nhóm, và cần đảm bảo rằng công cụ hay quy trình đó gia tăng được khả năng tương tác giữa các thành viên trong nhóm và giữa nhóm với các bên liên quan khác.
over comprehensive documentation
Working software nghĩa là gì? Làm thế nào để biết phần mềm/hệ thống/sản phẩm của mình hoạt động được? Thực ra đây là một câu hỏi tưởng dễ nhưng không phải dễ. Khi một team dự án làm theo mô hình Waterfall, thì tài liệu, yêu cầu dự án được xây dựng hết sức chi tiết từ lúc đầu, xác định chính xác những gì nhóm sẽ làm ra, những tài liệu này được khách hàng và các bên liên quan duyệt, sau đó sử dụng để bắt đầu xây dựng đúng theo kế hoạch. Hầu hết các team dù chuyên nghiệp đến đâu cũng đã trải qua những cuộc họp khủng khiếp, nơi mà team thì hào hứng trình bày sản phẩm mà mình làm ra, còn người dùng/khách hàng thì phàn nàn rằng phần mềm/sản phẩm thiếu một số tính năng quan trọng, hoặc không hoạt động chính xác. Những cuộc họp như thế thường kết thúc bằng một cuộc tranh cãi nảy lửa. Thông thường thì team sẽ kết luận rằng đó không phải là lỗi, đó chỉ là tính năng chưa được ghi chép lại thì team không có nhiệm vụ phải làm !?
Rất nhiều team cố gắng giải quyết những vấn đề này bằng việc chuẩn bị những bản yêu cầu hết sức chi tiết, những bản kế hoạch tỉ mỉ. Nhưng thực tế chứng minh điều này chỉ làm cho tình hình thêm tệ hơn mà thôi, bởi vì tất cả mọi người đều có thể đọc cùng một trang yêu cầu/1 bản kế hoạch nhưng cách họ hiểu về nó có thể hoàn toàn khác nhau. Cách tốt nhất – đôi khi là duy nhất – để biết phần mềm/sản phẩm có hoạt động được hay không chính là để cho khách hàng/người dùng sử dụng nó. Nếu họ có thể sử dụng phần mềm/sản phẩm để làm thứ họ muốn làm, thì có nghĩa là phần mềm/sản phẩm đó sử dụng được – Working software/Working product. Các team Agile vẫn đánh giá cao tầm quan trọng việc sử dụng các tài liệu yêu cầu, kế hoạch toàn diện, tuy nhiên phần mềm/sản phẩm đáp ứng được nhu cầu của khách hàng/người dùng mới là quan trọng hơn.
over contract negotiation
Cần lưu ý là “contract” ở đây không phải là khái niệm về hợp đồng. Khi team Agile nói về “contract negotiation”, thì có nghĩa đó là thái độ, cách suy nghĩ, cách hành động,… mà mọi người đối với khách hàng, hoặc thành viên của team khác. Khi mọi người trong team có lối tư duy “contract negotiation”, họ luôn cảm thấy họ phải có một thỏa thuận chặt chẽ về những gì họ sẽ làm hay sẽ xây dựng trước khi bắt tay vào thực hiện công việc. Nhiều công ty khuyến khích lối tư duy này, yêu cầu các thành viên phải cam kết, thỏa thuận một cách rõ ràng về những gì họ có thể làm được và khi nào làm xong (thường sẽ được ghi chép một cách chính thức và tuân thủ các quy trình kiểm soát thay đổi nghiêm ngặt). “Contract negotiation” nên sử dụng trong trường hợp khách hàng không muốn hợp tác!
Các team Agile luôn ý thức được rằng việc thay đổi trong dự án luôn luôn xảy ra, chúng ta không bao giờ có đầy đủ thông tin tại thời điểm bắt đầu dự án. Thay vì cố gắng chốt chính xác những gì sẽ làm ngay từ đầu dự án, thì hãy hợp tác chặt chẽ với người dùng/khách hàng để đạt được kết quả tốt nhất (hiểu được mong muốn, cập nhật thông tin,… càng sớm càng tốt).
over following a plan
Một số project manager có nói: “Plan the work, work the plan” – “Lập kế hoạch cho công việc – làm việc theo kế hoạch”. Team Agile cho rằng việc lập kế hoạch hết sức quan trọng, nhưng nếu khăng khăng làm việc theo kế hoạch, sẽ có một số vấn đề phát sinh. Những team dự án theo mô hình Waterfall có quy trình kiểm soát thay đổi nghiêm ngặt và tốn thời gian, và cho rằng thay đổi trong dự án là không theo kế hoạch, là ngoại lệ.
Vấn đề của việc lên kế hoạch đó là nó được xây dựng chi tiết từ khi bắt đầu dự án, khi mà team có rất ít thông tin về sản phẩm sẽ làm. Vì vậy các team Agile nhận thức được rằng kế hoạch sẽ luôn thay đổi, team sẽ thường xuyên sử dụng các phương pháp, công cụ để giúp tìm ra các thay đổi và đưa ra biện pháp phù hợp. Một công cụ mà team Agile thường dùng đó là Daily Standup Meeting, mọi người có thể xem xét lại kế hoạch mỗi ngày và cùng phối hợp làm việc với nhau để ứng phó với các thay đổi, từ đó kế hoạch của dự án sẽ được cập nhật sớm nhất có thể.
Khi các team Agile đánh giá cao việc đáp ứng thay đổi hơn là tuân theo kế hoạch, điều đó không có nghĩa là team không lập kế hoạch cụ thể, mà là ngược lại! Team hoàn toàn coi trọng việc tuân thủ kế hoạch, chỉ là việc đáp ứng thay đổi được đánh giá cao hơn mà thôi.
Không có một công thức hoàn hảo cho việc xây dựng một phần mềm/sản phẩm. Một số team đạt được rất nhiều thành công và thấy được những cải tiến vượt bậc sau khi áp dụng Agile, trong khi một số team khác thì lại gặp vấn đề. Điểm khác nhau lớn nhất có thể kể đến đó chính là hệ tư duy của các thành viên trong nhóm, họ có tư duy Agile hay không. Vậy bạn sẽ làm gì để đạt được những kết quả tuyệt vời đó cho team của mình? Làm thế nào để chắc chắn rằng team mình có tư duy đúng về Agile? Đó chính là lý do bạn cần phải hiểu được Agile Manifesto. Khi bạn và team bạn hiểu được các giá trị và nguyên tắc của Agile, dự án của bạn sẽ trở nên hiệu quả hơn rất nhiều.
Kiến thức tổng hợp bởi Masterskills (PMP, PMI-ATP Instructor)
References: Head First Agile
Product Backlog là gì? Có quan hệ như thế nào với WBS
Bản tuyên ngôn Agile – lịch sử hình thành Agile
12 nguyên tắc của Agile
Trong dự án Agile, công việc ước tính có thật sự cần thiết?
Quản lý dự án với Scrum
Scrum of Scrums
User stories – Công cụ lên kế hoạch của Agile
Story points – Công cụ ước lượng của Agile
Velocity là gì – Công cụ đo lường tốc độ hoàn thành công việc của nhóm Agile
Story Map – Lập kế hoạch tổng quát trong Agile
Agile Retrospectives – Nhìn lại và cải tiến hiệu quả công việc dự án
Kanban – phương pháp giúp cải tiến quy trình làm việc của dự án
PDCA – Chu trình cải tiến liên tục
Personas – Công cụ xây dựng hình tượng khách hàng trong Agile
Lean – Tinh gọn hóa quy trình một cách hiệu quả
Hướng Dẫn Scrum – The Scrum Guide
Bóng đá có 3-5-2, Scrum có 3-5-3
Bắt đầu với Scrum từ đâu đây ta?
Một số cách chạy Daily scrum hiệu quả
