EN |
VN
Nguyên tắc này bao gồm ba điểm chính. Đầu tiên là làm hài lòng khách hàng. Nếu chỉ tập trung vào việc lên kế hoạch thật chi tiết từ đầu và bám theo kế hoạch, hay việc cố gắng tuân thủ theo quy định của QA sẽ làm cho team khó có thể đáp ứng được với những thay đổi yêu cầu liên tục từ phía khách hàng, từ đó dẫn tới việc dự án có khả năng thất bại. Vì vậy, chúng ta nên đặt tiêu chí làm hài lòng khách hàng lên hàng đầu.
Điểm thứ hai là bàn giao giao phẩm sớm và liên tục. Ví dụ như việc phát triển 1 prototype (nguyên mẫu) cho phần mềm/sản phẩm và đưa nó tới tay khách hàng càng sớm càng tốt sẽ giúp team lấy được phản hồi sớm từ phía khách hàng. Và tiếp tục bàn giao, demo các phiên bản tiếp theo một cách liên tục, team càng ngày càng xây dựng nên một phần mềm/sản phẩm giải quyết được các yêu cầu, vấn đề quan trọng của khách hàng rất nhanh. Tránh được trường hợp sản phẩm làm ra khác xa những mong muốn của khách hàng.
Điểm cuối cùng là những phiên bản bàn giao của phần mềm/sản phẩm cần hoạt động được và đem lại giá trị cho khách hàng.
Thay đổi trong dự án là không thể tránh khỏi, tuy nhiên không phải thay đổi nào cũng xấu, mà ngược lại, những thay đổi là cần thiết để gia tăng tính cạnh tranh cho khách hàng. Ví dụ, khách hàng nhận thấy một cơ hội tốt để gia tăng lợi nhuận bằng cách xây dựng tính năng chăm sóc người dùng chuyên sâu thông qua chatbot của fanpage. Việc này đòi hỏi thay đổi về mặt tính năng so với kế hoạch ban đầu của phần mềm quản lý người dùng (không bao gồm chatbot). Sẵn sàng cho những thay đổi không có nghĩa là khách hàng yêu cầu gì mình cũng đồng ý làm theo, trách nhiệm của team Agile là sẵn sàng ứng phó với những yêu cầu này, tìm hiểu yêu cầu, tư vấn và đưa ra giải pháp hợp lý cho từng trường hợp cụ thể.
Bản chất con người là luôn muốn chuẩn bị công việc của mình hoàn hảo nhất có thể trước khi công bố/bàn giao, tuy nhiên sẽ phản tác dụng nếu những công việc đó bị ngâm quá lâu, vì khi ngâm công việc quá lâu thì kết quả của công việc đó có thể sẽ không còn phù hợp với nhu cầu khách hàng nữa. Để hạn chế điều này, việc lấy ý kiến phản hồi sớm và thường xuyên sẽ khiến khách hàng tiếp cận được phần mềm/sản phẩm nhanh chóng, tránh được trường hợp kết quả của công việc đi quá xa mong muốn khách hàng.
Việc bàn giao phần mềm/sản phẩm trong một khoảng thời gian ngắn còn có lợi ích gắn kết giữa team Agile và khách hàng, ví dụ thông qua các buổi demo, cả 2 bên sẽ có những ý tưởng mới, những yêu cầu mới, hoặc những thay đổi trong chiến lược kinh doanh giúp mang lại nhiều giá trị hơn cho khách hàng.
Các buổi demo sản phẩm như đã trình bày ở trên là một ví dụ cho việc người kinh doanh và đội ngũ phát triển làm việc cùng nhau trong suốt dự án (người kinh doanh ở đây có thể hiểu là khách hàng của dự án, hoặc sponsor). Thay vì trao đổi với nhau thông qua email, điện thoại thì việc gặp gỡ nhau trực tiếp (face-to-face) sẽ đem lại hiệu quả tốt nhất trong việc gắn kết cả 2 bên.
Khi gặp gỡ trực tiếp với tần suất cao như vậy (hàng ngày) thì team Agile có thể hiểu nhiều hơn về business, mong muốn, kỳ vọng của khách hàng. Từ đó đề xuất các giải pháp tốt hơn, sớm hơn để áp dụng vào phần mềm/sản phẩm của dự án. Về phía khách hàng, họ sẽ biết được nhiều giải pháp hơn để có thể cân nhắc lựa chọn về mức độ hiệu quả, chi phí, thời gian,… Điều này chắc chắn sẽ khó đạt được khi chỉ gặp gỡ khách hàng tại thời điểm đầu dự án để thu thập yêu cầu.
Tuy nhiên, không phải dễ dàng gì mà phía khách hàng và đội ngũ phát triển có thể tương tác hằng ngày với nhau. Nếu không thể làm được điều đó hằng ngày, team Agile sẽ cố gắng thực hiện thường xuyên nhất có thể, ví dụ như 2 ngày, 3 ngày,… 1 lần.
Nguyên tắc 5: Xây dựng dự án xung quanh những cá nhân có động lực. Cho họ môi trường làm việc thuận lợi và sự hỗ trợ cần thiết. Hãy có niềm tin rằng họ sẽ làm tốt công việc của mình.
Như chúng ta cũng đã biết, con người là nhân tố quan trọng của mọi vấn đề. Vì thế, một dự án có những thành viên giỏi sẽ đem lại khác biệt lớn so với việc chỉ có các quy trình hay công cụ tốt. Mặc dù không phải lúc nào trong team đều là những người giỏi, là một leader/project manager, cần tin tưởng, động viên, hỗ trợ, đãi ngộ và trao quyền cho các thành viên trong nhóm nếu có thể. Ngoài ra nguyên tắc này còn nhấn mạnh đến tầm quan trọng của việc tự tổ chức và quản lý công việc của từng cá nhân, đề cao sự hợp tác, làm việc nhóm, hỗ trợ lẫn nhau giữa các thành viên trong nhóm,… nhằm đem lại hiệu quả cao trong công việc.
Nguyên tắc 6: Đối thoại trực tiếp mặt đối mặt là phương pháp hữu hiệu nhất trong việc truyền đạt thông tin.
Ghi chép lại những quyết định, thảo luận,… dùng để đối chiếu về sau là điều nên làm, tuy nhiên sẽ rất tốn thời gian và công sức. Nên việc đối thoại trực tiếp mặt đối mặt sẽ giúp chúng ta trao đổi thông tin nhanh chóng, biểu đạt được đầy đủ ý nghĩa của thông điệp muốn truyền tải thông qua lời nói, biểu cảm, ngôn ngữ hình thể,… Tuy nhiên team Agile cũng cần cân nhắc sử dụng đối thoại trực tiếp mặt đối mặt trong từng trường hợp cụ thể, ví dụ như khi team quá lớn, sẽ rất khó để trao đổi theo kiểu mặt đối mặt với toàn bộ các thành viên trong nhóm cùng một lúc, thay vào đó có thể cân nhắc cử đại diện từng nhóm nhỏ, hoặc bắt buộc phải trao đổi thông tin dưới dạng viết như email, chat, tài liệu,…
Nguyên tắc 7: Phần mềm chạy được là thước đo chính của tiến độ dự án.
Khi làm dự án, chúng ta sẽ luôn gặp những câu hỏi như “Phần mềm/sản phẩm dùng được chưa?”, “Tính năng A đã có thể chạy được chưa?”, “Bản thiết kế đã xong chưa?”. Trong rất nhiều trường hợp câu trả lời nhận về là rất mơ hồ, ví dụ như “Sắp xong rồi”, “Gần chạy được”. Vậy bằng cách nào để đo lường được tiến độ dự án theo Agile? Bằng cách xác định rằng nếu một tính năng không thể đo lường hoặc kiểm thử thành công, hay nói cách khác là chưa hoạt động được thì tính năng đó chưa hoàn thành. Việc bàn giao phần mềm/sản phẩm hoạt động được, sẽ giúp cho khách hàng biết được chính xác phần mềm/sản phẩm mà họ mong muốn đang được phát triển tới đâu, hay tiến độ tới đâu.
Nguyên tắc 8: Phát triển bền vững và duy trì việc phát triển liên tục.
Trong lúc làm dự án, thỉnh thoảng cả team sẽ phải OT (over time – tăng ca) để cố gắng hoàn thành một bản demo giao cho khách hàng. Tuy nhiên nếu cứ kéo dài tình trạng OT này mãi thì chất lượng tạo ra càng ngày càng lao dốc, công việc càng ngày càng chậm trễ mà thôi. Agile nhận ra rằng việc duy trì tốc độ bền vững (làm việc 40 tiếng 1 tuần, hạn chế OT, không làm thêm cuối tuần) là cách tốt nhất để đạt được năng suất cao nhất, và giúp các thành viên trong nhóm duy trì sự cân bằng giữa công việc và cuộc sống. Việc này còn ảnh hưởng tới công ty, tổ chức, vì nếu một cá nhân cảm thấy chán nản, không hạnh phúc sau chuỗi ngày dài làm việc mệt mỏi, có thể họ sẽ nghỉ việc, công ty thất thoát nhân sự và lại tốn thêm chi phí tuyển/dạy/dùng.
Nguyên tắc 9: Liên tục quan tâm đến kỹ thuật và thiết kế để tăng cường tính linh hoạt.
Bên cạnh việc mong muốn đội ngũ phát triển làm việc siêng năng và tạo ra nhiều giá trị, chúng ta cần quan tâm đến việc giữ cho cấu trúc dự án, những bản thiết kế luôn ở mức độ gọn gàng, hiệu quả và dễ dàng để thay đổi. Sự cân bằng này mang lại hiệu quả lâu dài trong việc bảo trì, thay đổi, mở rộng phần mềm/sản phẩm của dự án, bởi vì có biện pháp “phòng bệnh” luôn tốt hơn “chữa bệnh”. Nhưng nếu dự án đã lỡ không “clean” thì nên cho team Agile có thời gian để tái cấu trúc, dọn dẹp lại, đơn giản hóa những bản thiết kế để thiết lập lại trạng thái ổn định và dễ dàng bảo trì trong thời gian dài về sau.
Nguyên tắc 10: Đơn giản – nghệ thuật tối đa hóa số lượng công việc không làm – là điều cần thiết.
Rất nhiều công ty có quy trình làm việc cồng kềnh và phức tạp, trong khi Agile thì cần linh hoạt và uyển chuyển. Hoặc những dự án phức tạp sẽ tốn nhiều thời gian để hoàn thành, có khả năng gia tăng rủi ro, chi phí. Agile sẽ tập trung vào việc đơn giản hóa mọi thứ từ những quy trình không cần thiết, ví dụ như tại sao phải báo cáo tiến độ hàng ngày theo mẫu bắt buộc của công ty trong khi cả team đều đã nắm được tiến độ của dự án, cho tới việc chia nhỏ những yêu cầu phức tạp thành những phần nhỏ hơn, đơn giản hóa trong cấu trúc phần mềm, thiết kế, code để dễ dàng xây dựng và bảo trì. Team Agile sẽ tìm kiếm những công việc không cần thiết phải làm và đề xuất giải pháp thay thế hoặc loại bỏ. Cách tiếp cận này không nhằm mục đích hạn chế việc mở rộng tính năng cho phần mềm/sản phẩm, mà thay vào đó, team Agile tập trung vào việc làm thế nào để mở rộng tính năng đó một cách đơn giản nhất.
Nguyên tắc 11: Các kiến trúc, yêu cầu và thiết kế tốt nhất được tạo nên từ các nhóm tự tổ chức.
Nguyên tắc này nghe có vẻ hơi lạ, nhưng về cơ bản thì nó có nghĩa là để gặt hái được những giá trị tốt nhất từ một team thì hãy để họ tự tổ chức, tự quyết định, tự chịu trách nhiệm về những gì họ làm. Agile nhấn mạnh vào tính chủ động của team. Khi đạt được tính chủ động, team Agile sẽ có cơ hội tìm ra nhiều ý tưởng tốt, nhiều phương pháp hay, kết quả là sẽ tạo ra công việc tốt hơn. Các kiến trúc, yêu cầu và thiết kế sẽ được vận hành tốt nhất khi chúng được thực hiện bởi những người tạo ra chúng. Khi đó, team sẽ là người tiếp xúc gần nhất với từng phần của dự án, hiểu sâu nhất về kiến trúc, yêu cầu, thiết kế của dự án, từ đó đưa ra những đề xuất cải tiến hiệu quả hơn. Tuy nhiên việc tự tổ chức này phải nằm trong khuôn khổ, phải được hướng dẫn, đào tạo; đạt hiệu quả tốt hay không còn phụ thuộc vào tư duy và năng lực của từng thành viên trong nhóm.
Nguyên tắc 12: Trong khoảng thời gian đều đặn, nhóm phản ánh về cách trở nên hiệu quả hơn, sau đó điều chỉnh cho phù hợp.
Bài học kinh nghiệm luôn có xuyên suốt quá trình làm dự án, nếu chỉ được thu thập vào thời điểm cuối của dự án thì quá trễ, không hiệu quả và không được áp dụng vào dự án hiện tại. Biết được điểm bất cập đó, team Agile thực hiện việc này thường xuyên hơn, sau mỗi vòng lặp dự án, được gọi là “Retrospective”. Tại đây, cả team cùng hồi tưởng lại những bài học kinh nghiệm nào đã gặp trong thời gian vừa qua, đã làm sai gì không, cái nào cần cải tiến, cái nào cần loại bỏ,… Vì được thực hiện thường xuyên như vậy nên cả team có cơ hội điều chỉnh rất sớm và thường xuyên, càng ngày team càng hoạt động hiệu quả tốt hơn, sản phẩm tạo ra tốt hơn, khách hàng hài lòng hơn.
Tổng kết
Với 4 giá trị cốt lõi, 12 nguyên tắc được đề cập trong Agile Manifesto, đã giúp chúng ta có cái nhìn liên hệ tốt hơn giữa Agile và công việc thực tế hàng ngày. Giúp hình thành được cách tư duy theo Agile – Being Agile. Nhưng làm sao để áp dụng Agile vào thực tế – Doing Agile? Trong phần tiếp theo, chúng ta sẽ cùng tìm hiểu xem áp dụng Agile vào thực tế như thế nào thông qua framework nổi tiếng của Agile, đó chính là SCRUM.
Masterskills (PMP, PMI-ATP Instructor)
References: PMI-ACP Exam Prep, Head First Agile
Agile Project Management – Đào tạo cho Doanh nghiệp
Quản lý dự án theo mô hình linh hoạt Agile Scrum
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ả
