Lịch sử Trong giai đoạn trước 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. Lý do của việc này đó là phương pháp truyền thống ngày càng bộc lộ nhiều nhược điểm và tỉ lệ các dự án bị thất bại quá cao. 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 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. 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 đó.
1. Tổng quan về Agile: Agile thực chất là gì?
Định nghĩa: Khái niệm Agile (viết tắt của Agile Software Development) có nghĩa là phương thức phát triển phần mềm linh hoạt, được ứng dụng trong quy trình phát triển phần mềm với mục tiêu là đưa sản phẩm đến tay người dùng càng nhanh càng tốt. Rất nhiều nơi định nghĩa Agile như một phương pháp. Thực chất, Agile giống như một phương pháp luận, một triết lý dựa trên hơn nguyên tắc phân đoạn vòng lặp (iterative) và tăng trưởng (incremental).
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, dịch vụ, sales, marketing, giáo dục... và trở thành một phương thức quản lý dự án phổ biến nhất hiện nay với nhiều đại diện được gọi là các phương pháp “họ Agile”.
Các phương pháp Agile.
Agile không định nghĩa ra một phương pháp cụ thể nhưng lại có nhiều phương pháp khác nhau thỏa mãn và hướng theo các tiêu chí của nó.
Bảng thống kê dưới đây liệt kê 13 phương pháp họ Agile, nó cũng cho thấy phần lớn các công ty hiện nay đã sử dụng Scrum như một cách tiếp cận cơ bản. Bên cạnh đó, nhiều công ty đã kết hợp các phương pháp lại với nhau.
Một số mô hình tiêu biểu trong họ Agile mà mình đã tìm hiểu các bạn có thể tham khảo:
4 tôn chỉ cần tuân thủ trong phương pháp Agile
1. Cá nhân và sự tương hỗ quan trọng hơn quy trình và công cụ: Trọng tâm đặt lên con người, xây dựng tương tác và hỗ trợ giữa các thành viên trong nhóm. Những thành viên có năng lực, chịu tương trợ nhau trong công việc sẽ mang đến thành công cho dự án. Tuy nhiên, chỉ tăng tần suất phản hồi và giao tiếp là không đủ để loại bỏ các vấn đề về giao tiếp. Chu kỳ thanh tra và thích nghi hoạt động tốt chỉ khi các thành viên trong nhóm thể hiện những hành vi quan trọng sau:
• Tôn trọng giá trị của mỗi cá nhân
• Trung thực trong giao tiếp
• Minh bạch về dữ liệu, hoạt động, và quyết định
• Tin tưởng vào sự hỗ trợ của mỗi cá nhân với nhóm
• Cam kết với nhóm và các mục tiêu của nhóm
Ý cuối cùng ở trên nói về cam kết là đặc biệt quan trọng. Đó là khi mà các cá nhân và các nhóm được cam kết và cảm thấy có trách nhiệm với việc cung cấp các giá trị cao, đó là
điểm mấu chốt đối với các nhóm phát triển phần mềm. Các phương pháp linh hoạt tạo điều kiện cho việc cam kết bằng cách khuyến khích nhóm đưa ra một danh sách công việc được ưu tiên hóa, để họ tự quản lí công việc của mình, và tập trung vào cải tiến về cách thực hiện các công việc đó.
2. Sản phẩm dùng được tốt hơn tài liệu đầy đủ: Phần mềm chạy tốt là một trong những khác biệt lớn mà phát triển linh hoạt mang lại. Tất cả các phương pháp linh hoạt thể hiện Tuyên ngôn Agile bằng cách nhấn mạnh việc cung cấp một phần nhỏ của phần mềm chạy tốt tới khách hàng sau một khoảng thời gian nhất định. Tập trung thời gian để làm ra phần mềm hoàn chỉnh đáp ứng hoàn hảo yêu cầu khách hàng và có thể được được vận hành bởi người dùng cuối
3. Cộng tác với khách hàng quan trọng hơn đàm phán hợp đồng: Trong hai thập kỷ qua, tỉ lệ thành công của các dự án tăng hơn hai lần trên toàn thế giới. Điều này được cho là vì các dự án nhỏ hơn và mức độ chuyển giao thường xuyên đã cho phép khách hàng cung cấp các thông tin phản hồi về phần mềm hoạt động một cách đều đặn hơn. Hiểu được khách hàng cần gì để tư vấn và điều chỉnh sản phẩm thay vì chỉ dựa vào các điều khoản trong hợp đồng.
4. Phản hồi thay đổi hơn là bám sát kế hoạch: Phản hồi với thay đổi là điều cần thiết cho việc tạo ra một sản phẩm làm hài lòng khách hàng cũng như mang lại những giá trị kinh doanh. Dữ liệu ngành công nghiệp cho thấy hơn 60% các yêu cầu về sản phẩm hay dự án bị thay đổi suốt quá trình phát triển phần mềm. Ngay cả khi các dự án truyền thống kết thúc đúng thời gian, trong giới hạn kinh phí, với tất cả các tính năng theo kế hoạch, nhưng khách hàng thường không hài lòng vì những gì họ thấy không thật sự đúng như những gì họ muốn. Luật Humphrey nói rằng khách hàng không bao giờ biết những gì họ muốn cho đến khi họ thấy phần mềm hoạt động. Nếu khách hàng không nhìn thấy phần mềm hoạt động cho đến khi kết thúc dự án, sẽ là quá muộn cho việc kết hợp các thông tin phản hồi của họ ở thời điểm này. Vì thế Agile khuyến khích thích nghi với sự thay đổi, đó có thể là thay đổi về công nghệ, nhân sự, deadline,...
12 nguyên tắc quan trọng trong Agile
Đáp ứng toàn diện nhu cầu khách hàng thông qua việc giao hàng sớm và sản phẩm có giá trị. Dĩ nhiên mục đích của dự án phát triển phần mềm là phát triển phần mềm và làm khách hàng hài lòng và không có gì làm khách hàng hài lòng hơn việc cho khách hàng thấy được sản phẩm của mình thường xuyên và chạy được. Trong Agile, sản phẩm sẽ được demo cho khách hàng thường xuyên (thường là hàng tuần) để cho khách hàng thấy được sản phẩm của mình như thế nào. Nếu có chỗ nào không ổn hay cần cải tiến thì sẽ phản hồi với đội dự án ngay lập tức.
Thay đổi yêu cầu được chào đón, thậm chí là rất muộn trong quá trình phát triển. Nguyên tắc này là một sự thay đổi lớn cho những người đã quản lý hay làm việc với phương thức quản lý truyền thống. Khách hàng đã nhận được sản phẩm sớm, thường xuyên. Do đó mà họ có thể nhìn thấy được tiến triển cũng như những vấn đề trong dự án. Vì vậy mà những thay đổi của họ đa phần là đều có ý nghĩa. Thay vì kêu ca phàn nàn chúng ta hãy tìm hiểu, bàn luận với khách hàng để xử lý những yêu cầu thay đổi một cách trơn tru nhất
Giao phần mềm chạy được cho khách hàng một cách thường xuyên. Khi thường xuyên kiểm tra sản phẩm là chìa khoá để dự án được phát triển tốt nhất. Càng gửi sớm chúng ta càng có cái để thảo luận với khách hàng và đi đến những quyết định cho dự án.
Nhà kinh doanh và các kỹ sư phần mềm cần làm việc cùng nhau trong suốt dự án. “Nhà kinh doanh” ở đây được hiểu nôm na là khách hàng của dự án, những người tài trợ cho dự án. Đội phát triển phải làm việc thường xuyên và gần gũi với khách hàng để hiểu được nhu cầu của họ cũng như cho phép khách hàng hiểu về công việc của đội phát triển.
Xây dựng dự án xung quanh các cá nhân có động lực. Cung cấp sự hỗ trợ cần thiết, môi trường làm việc và niềm tin để hoàn thành công việc. Hãy tạo ra khoảng không trong dự án để các cá thể có thể phát triển, suy nghĩ, nâng cao tay nghề. Tin tưởng và tự tin vào các thành viên trong team tạo nên sức mạnh. Hãy support họ những gì họ cần và tin tưởng họ sẽ thành công. Support ở đây có thể là tool và resource, hay kiến thức dự phòng ... Nó không chỉ là việc bạn tin tưởng vào team mà hãy làm thế nào để tất cả các thành viên trong team đều có được sự tự tin, niềm tin khi mà họ đã có được đầy đủ nguồn lực, kiến thức cần thiết để hoàn thành dự án
Trao đổi trực tiếp là cách truyền đạt thông tin hiệu quả nhất. Sự giao tiếp trao đổi giữa những cá nhân là rất quan trọng và để giao tiếp hiệu quả thì không gì có thể hơn được trực tiếp trao đổi mặt-đối-mặt hay dùng những biểu tượng hình ảnh để chuyển tải thông tin. Bạn sẽ dễ bắt gặp một không khí nhộn nhịp hay những hình ảnh minh họa, biểu tượng, hình vẽ đầy màu sắc trong các dự án Agile vì những điều đó giúp trao đổi thông tin hiệu quả hơn.
Thước đo chính của tiến độ là phần mềm chạy tốt. Thông tin về tiến độ của dự án rất quan trọng, đặc biệt là đối với Ban quản lý hay các nhà đầu tư cho dự án vì những thông tin đó sẽ giúp họ có thể đưa ra những quyết định. Tuy nhiên, suy cho cùng điều mà họ quan tâm thực ra là sản phẩm đang phát triển có hoạt động tốt hay không. Bạn có thể báo tiến độ là “Đúng kế hoạch” nhưng khi được hỏi sản phẩm chạy được chưa thì câu trả lời là “sắp chạy được” hay “chưa chạy được” sẽ làm khách hàng hoang mang.
Phát triển liên tục và bền vững. Khi các dự án bắt đầu, chúng ta thường cảm thấy rất sung sức và tràn đầy năng lượng, và khao khát thể hiện thật tốt. Đặc biệt thường thấy ở những dự án mà cần độ cấp bách về tiến độ. Khi đó chúng ta sẽ đẩy áp lực làm việc mạnh lên để có được tiến độ dự án chạy một cách nhanh chóng. Nó có thể tạo ra những kết quả tốt ngắn hạn, nhưng sẽ phá hỏng kế hoạch dài hạn. Rõ ràng là không thực tế nếu kỳ vọng team sẽ làm việc với hiệu suất cao trong thời gian dài. Làm việc quá sức có thể tạo ra nhiều sai lầm và lỗi hơn. Khi con người làm việc quá tải và có ít thời gian để nghỉ ngơi, tập luyện thể dục hay hồi phục sức khỏe, môi trường làm việc sẽ trở nên xấu đi, thậm chí là độc hại. Khi đó từng cá nhân sẽ trở nên kém kiên nhẫn và xung đột lẫn nhau, chúng ta sẽ khó có thể quản lý và giải quyết được các vấn đề. Do đó, một môi trường làm việc cân bằng giữa công việc và cuộc sống cần được lưu ý. Cần nhận thấy rằng Agile projects không chỉ cho những khoảng ngắn hạn mà còn cần thiết để thành công trong dài hạn. Nên việc thiết lập và duy trì nhịp độ phát triển chính là những gì nguyên tắc này muốn nói đến.
Cải tiến sự linh hoạt bằng cách quan tâm đến kỹ thuật và thiết kế. Liên tục cải tiến các quy trình, phương pháp, công cụ để tăng mức độ linh hoạt trong dự án. Luôn nghĩ đến những phương pháp mới để code tốt hơn, kiểm thử tốt hơn
Nghệ thuật tối đa hóa lượng công việc chưa xong - Sự đơn giản là cần thiết. Agile có nghĩa là linh hoạt và để linh hoạt uyển chuyển thì bạn phải tối giản hóa các công việc mình làm. Những việc nào cần thiết và mang lại giá trị thì mọi người sẽ cùng làm. Tuy nhiên việc xác định việc nào mang lại giá trị nhiều khi không đơn giản. Do đó, để đơn giản thì việc có giá trị là việc mà cả nhóm thống nhất và sẽ cam kết thực hiện. Chẳng hạn cả nhóm có thể thống nhất không phải viết “Báo cáo tiến độ hàng ngày” nếu như mọi người đều biết tiến độ của nhau và sếp của bạn cũng không có nhu cầu đọc. Tương tự, bạn cũng không nhất thiết phải mô tả một con bug dài lê thê chỉ để theo đúng định dạng của hệ thống bug trong khi bạn đã báo và trao đổi với Dev về con bug đó và họ đã sửa nó. Tuy nhiên hãy cẩn thận. Không phải bạn bỏ đi là bạn linh hoạt và tối ưu hóa công việc. Vấn đề là bạn bỏ đi những thứ không mang lại giá trị.
Nhóm tự tổ chức. Đây là điểm khác biệt hoàn toàn với team trong quản lý dự án truyền thống. Trong quản lý dự án Agile, chúng ta làm việc với những member hiểu biết với trình độ và kinh nghiệm của họ, họ không cần chúng ta phải thúc ép hay chỉ dẫn nhỏ nhặt trong công việc. Những người làm việc hiểu biết hiện đại ngày nay, đặc biệt nếu là những người kinh nghiệm trong công việc sẽ đạt hiệu quả công việc tốt hơn nếu chúng ta tin tưởng trao cho họ quyền quyết định, sáng tạo. Các cá nhân vẫn cần người hướng dẫn, cần leader, nhưng lãnh đạo tốt nhất ở trong môi trường này đó là việc dẫn dắt bằng các ví dụ hay sự hướng dẫn trong quan hệ bình đẳng. Mà chúng ta có thể gọi là "lãnh đạo đầy tớ" (servant leadership). Việc cho phép team tự tổ chức, cho phép họ làm việc gần gũi với nhau hơn, họ sẽ hiểu được giá trị của việc làm việc gắn kết chặt chẽ và học hỏi từ nhau. Một team gắn kết xuyên suốt dự án sẽ tạo ra những bản thiết kế và xử lý chúng một cách dễ dàng hơn. Nếu có lỗi xảy ra, team tự quản lý cũng dễ nhận biết nó và tìm giải pháp khắc phục nhanh hơn. Dĩ nhiên “tự tổ chức” không phải là bạn tập hợp các thành viên và tuyên bố “nào, nhóm tự tổ chức nhé”. Do đó, ban đầu nhóm cũng phải được hướng dẫn, đào tạo để có thể “tự tổ chức”. Quá trình đó có thể gian nan và việc nhóm bạn “tự tổ chức” đến đâu còn tùy thuộc vào nhiều yếu tố như năng lực, nhận thức của thành viên, khả năng hướng dẫn của người hướng dẫn Agile, sự tin tưởng và tôn trọng của ban lãnh đạo
Thường xuyên nhìn nhận đánh giá từ đó thích ứng thường xuyên với những thay đổi. Tôi nghĩ rằng đây là điều mà chúng ta thường quên nhất. Chúng ta làm việc trong dự án, hoàn thành và chuyển sang dự án khác mà quên đánh giá mọi thứ đã đi như thế nào. Chúng ta có thể học được rất nhiều thứ khi chúng ta đánh giá những sai lầm và những thành công của chúng ta. Nhóm thường xuyên nhìn nhận đánh giá về tình hình dự án sản phẩm để có thể điều chỉnh và thích ứng. Ý tưởng là nhìn lại để tiến lên. Đó là những buổi họp tập trung vào những cái hay cái dở trong những việc mình đang làm để rút kinh nghiệm và học hỏi lẫn nhau. Những buổi họp dạng vậy thường là những câu hỏi và tự trả lời. Chẳng hạn như:
“Việc gì chúng ta làm chưa tốt”
“Chúng ta đã làm tốt những việc gì”
“Chúng ta đã học được bài học gì”
2. Đặc trưng của Agile
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 (Iteration hoặc Sprint), thường có khung thời gian ngắn (từ 1-4 tuần). Trong mỗi phân đoạn, 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ử để cho ra các phần nhỏ của sản phẩm.
Tính tăng trưởng và tiến hóa (Incremental & Evolutionary): Cuối các phân đoạn, nhóm cho ra các phần nhỏ của sản phẩm cuối cùng, 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. 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.
Tính 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.
Nhóm tự tổ chức và liên chức năng: Các cấu trúc nhóm này tự 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 hay làm việc dựa trên một sự phân cấp rõ ràng trong tổ chức. Nhóm tự tổ chức đã đủ các kĩ năng cần thiết để 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. Agile rút ngắn vòng đời phản hồi để dễ dàng thích nghi và gia tăng tính linh hoạt nhờ đó 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): Agile không phản đối 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ì thông qua giấy tờ. Agile khuyến khích nhóm phát triển trực tiếp nói chuyện để hiểu rõ hơn về cái khách hàng thực sự cần. Trong giao tiếp giữa nội bộ nhóm, Agile khuyến khích 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.
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à “sản phẩm chạy tốt chính là thước đo của tiến độ”. Nhóm Agile thường cộng tác trực tiếp và thường xuyên với khách hàng để 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.
3. Tại sao quản lý dự án theo nguyên tắc Agile lại hiệu quả hơn các phương pháp truyền thống?
Vì những ưu điểm của nó:
Agile ban đầu được tạo nên cho ngành công nghiệp phát triển phần mềm để giúp cho việc sắp xếp và cải tiến quá trình sản xuất. Qua đó, các nhà phát triển có thể nhận dạng, điều chỉnh các vấn đề và khiếm khuyết một cách nhanh chóng.
Là một phương pháp thay thế cho cách tiếp cận Waterfall truyền thống, Agile cung cấp phương pháp quản lý giúp các nhóm làm việc cho ra đời một sản phẩm tốt hơn, nhanh hơn thông qua các phiên ngắn và các phiên tương tác /các sprint. Với những kỳ vọng ngày càng gia tăng của khách hàng, việc cạnh tranh liên tục đòi hỏi phải tìm kiếm được những nhà lãnh đạo dự án có thể sử dụng phương pháp tiếp cận tốt nhất để thực hiện dự án.
Thực hiện thay đổi dễ dàng: Bởi vì dự án được chia thành các phần nhỏ, riêng biệt, không phụ thuộc lẫn nhau, nên những thay đổi được thực hiện rất dễ dàng, ở bất kỳ giai đoạn nào của dự án.
Không cần phải nắm mọi thông tin ngay từ đầu: Phù hợp với những dự án chưa xác định được mục tiêu cuối cùng rõ ràng, vì việc này không quá cần thiết trong giai đoạn đầu.
Bàn giao nhanh hơn: Việc chia nhỏ dự án cho phép đội ngũ có thể tiến hành kiểm tra theo từng phần, xác định và sửa chữa vấn đề nhanh hơn, nhờ đó việc bàn giao công việc sẽ nhất quán và thành công hơn.
Chú ý đến phản hồi của khách hàng và người dùng: Cả khách hàng và người dùng cuối đều có cơ hội để đóng góp các ý kiến và phản hồi, từ đó họ sẽ có ảnh hưởng một cách mạnh mẽ và tích cực tới sản phẩm cuối cùng.
Cải tiến liên tục: Agile khuyến khích thành viên trong đội ngũ làm việc và khách hàng cung cấp phản hồi của mình, khi đó các giai đoạn khác nhau của sản phẩm cuối có thể được kiểm tra và cải thiện lại nhiều lần nếu cần.
Tuy nhiên, Agile có một vài nhược điểm:
Khó lên kế hoạch dự án: Khá là khó để xác định rõ ràng thời gian bàn giao sản phẩm cuối cùng, vì dự án được chia nhỏ thành các phần khác nhau và mỗi phần lại có thời gian bàn giao riêng biệt.
Bắt buộc phải hướng dẫn và đào tạo chi tiết: Phương pháp Agile phức tạp hơn nhiều so với phương pháp truyền thống. Họ sẽ cần phải trải qua đào tạo, hướng dẫn thì mới có thể nắm được phương pháp một cách rõ ràng, đặc biệt là thời gian đầu.
Ít tài liệu hướng dẫn: Vì Agile thay đổi rất nhiều nên các tài liệu thích hợp cũng thường bị bỏ qua, vì không xác định rõ được kỳ vọng và thành phẩm ngay từ đầu. Mặc dù tài liệu không phải là yếu tố quan trọng nhất, nhưng chúng vẫn rất cần thiết.
Bắt buộc phải hợp tác để dự án thành công: Điều này đòi hỏi một sự cam kết về thời gian từ cả hai bên trong suốt thời gian của dự án mà các cấu trúc quản lý dự án khác không luôn yêu cầu. Phải có sự tham gia tích cực của người dùng và tiếp tục cộng tác để nó hoạt động.
Chi phí cao: Chi phí thực hiện theo phương pháp Agile thường hơn một chút so với các phương pháp phát triển khác.
4. Áp dụng Agile trong mô hình quản lý dự án như thế nào?
Các phương pháp truyền thống cồng kềnh như mô hình Waterfall thường yêu cầu các nhóm dự án phải đáp ứng và thảo luận các mục tiêu dự án đầy đủ trong suốt mỗi giai đoạn. Tuy nhiên, Agile sử dụng các nhóm nhỏ hơn tập trung để đạt những mục tiêu cụ thể hơn, giúp bạn dễ dàng thực hiện những thay đổi nhanh chóng theo yêu cầu. Điều này cho phép các nhóm hoạt động nhanh nhẹn, hiệu quả hơn và tăng khả năng đáp ứng thành công mục tiêu của khách hàng, đặc biệt khi nhu cầu của khách hàng thay đổi.
Một quy trình Agile hoàn chỉnh
Các giai đoạn phát triển của sản phẩm sẽ được chia nhỏ ra thành những phần tăng trưởng cụ thể mà người dùng có thể tương tác được. Nhờ đó sản phẩm sẽ có được phản hồi cần thiết để tránh khỏi những vấn đề nghiêm trọng và được cải tiến tốt hơn.
Thêm vào đó, quy trình quản lý sản phẩm có tính chất lặp lại này còn giúp cho cả nhóm có thể chuyển sang một phần tăng trưởng khác trong khi những vấn đề của phần tăng trưởng hiện tại đang được giải quyết.
5. Agile phù hợp với dự án như thế nào?
Agile phù hợp với các dự án đòi hỏi sự linh hoạt và có mức độ phức tạp hoặc không chắc chắn. Chẳng hạn, một sản phẩm hoặc dịch vụ chưa từng được nhóm xây dựng.
Tuy nhiên, không phải doanh nghiệp nào cũng phù hợp với mô hình Agile. Để áp dụng thành công mô hình này cần một số điều kiện tiên quyết trong tổ chức:
Thứ nhất, các thành viên phối hợp, giao tiếp hiệu quả trong nội bộ. Kỹ năng giao tiếp tốt giúp nhóm làm việc thấu hiểu khách hàng, hợp tác tốt với nhau đảm bảo chất lượng và tốc độ.
Thứ hai, tính tự chủ của mỗi thành viên phải được đảm bảo để các nhóm tự quản lý có thể vận hành một cách chủ động, trơn tru thay vì chỉ tuân thủ theo chỉ dẫn cấp trên như trong các mô hình truyền thống.
Thứ ba, các hoạt động được module hóa thông qua những nhóm liên chức năng. Những nhóm này có khả năng làm việc với tốc độ và chất lượng cao, với khách hàng là trung tâm
6. Thách thức khi áp dụng Agile
Thực tế có những doanh nghiệp đã áp dụng Agile từ 5-7 năm nhưng thực sự vẫn chưa đạt yêu cầu và nhìn chung phần lớn vẫn trong tình trạng “bình mới mà rượu cũ”. Các đội dự án vẫn muốn áp dụng Agile, tuy nhiên có nhiều đội chỉ áp dụng Agile để né tránh hệ thống quy trình phức tạp của doanh nghiệp hay khối lượng tài liệu (document) khổng lồ của dự án.
Điều này là không lạ, vì mặc dù Agile trông có vẻ đơn giản để hiểu, tuy nhiên rất khó để thành thạo, đặc biệt trong một doanh nghiệp lớn. Một lý do chính đó là Agile tập trung nhiều vào yếu tố con người bao gồm văn hóa, giao tiếp, hợp tác phối hợp giữa các bên liên quan, khả năng làm việc nhóm. Và thay đổi văn hóa, hành vi con người thì chuyện không bao giờ là dễ dàng.
Comments