Trong môi trường kinh doanh mà mức độ cạnh tranh thì liên tục tăng và thời gian phát triển sản phẩm thì liên tục rút ngắn, nhiều doanh nghiệp đang áp dụng phương pháp Agile để nhanh chóng thích ứng với hoàn cảnh liên tục biến đổi. Nếu bạn quan tâm tới lĩnh vực công nghệ thông tin, có thể bạn đã nghe về Agile, Lean, Scrum, Kanban…
Agile hứa hẹn là một mô hình đem lại nhiều lợi ích cho cả công ty phát triển phần mềm và người dùng. Tuy vậy, nhiều công ty đã gặp không ít vấn đề khi áp dụng mô hình này vào thực tiễn công ty họ. Vậy Agile là gì, có cần thiết không, và làm thế nào để trở nên Agile?
Agile là một triết lý thiết kế công việc linh hoạt nhằm thích ứng nhanh chóng với các thay đổi. Agile thể hiện qua:
Agile nhấn mạnh việc xây dựng các nhóm làm việc tự quản (self-organization) và liên chức năng (cross-function). Agile chú trọng con người, sự hợp tác, và tạo dựng một môi trường làm việc tốt. Triết lý này cho rằng chính sự cộng tác giữa công ty và khách hàng/người dùng sẽ đưa ra được yêu cầu và giải pháp đúng đắn.
Agile ảnh hưởng đến mọi hoạt động trong doanh nghiệp của bạn, từ cách các đồng nghiệp làm việc đến cách các lãnh đạo quản lý và xây dựng chiến lược. Ngày nay, Agile đã trở thành một triết lý phổ biến và có ảnh hưởng sâu rộng, được áp dụng trong nhiều lĩnh vực từ phát triển phần mềm đến marketing, sales, HR… nhằm nâng cao sức cạnh tranh và phát triển bền vững.
Khi nói đến lịch sử Agile, nhiều người sẽ nghĩ rằng tư tưởng này bắt đầu từ cuộc gặp mặt của 17 chuyên gia phát triển phần mềm tại một khu trượt tuyết ở Utah vào 2001.
Đúng là trong cuộc họp này họ đã quyết định chọn từ “agile” (linh hoạt) làm cái tên cho tư tưởng này. Tuy nhiên, cốt lõi của Agile - việc thích ứng với thay đổi - cùng với các công cụ làm tiền đề cho Agile đã được nghiên cứu từ thế kỉ trước đó.
W. Edwards Deming giới thiệu mô hình cải thiện chất lượng PDSA (Plan-Do-Study-Act) cho các công ty lớn tại Nhật Bản. Theo ông, cải thiện chất lượng là cải tiến liên tục và không ngừng nghỉ. Toyota đã thuê Deming đào tạo các nhà quản lý và phát triển hệ thống sản xuất nổi tiếng của họ, cũng chính là nền tảng cho Tư duy tinh gọn (Lean thinking). Từ những thập niên 80s, mô hình của Toyota đã được nhiều công ty khác nghiên cứu và áp dụng.
Kanban: Toyota bắt đầu sử dụng các thẻ giấy để trực quan hóa quy trình sản xuất và cải tiến hiệu suất công việc.
Winston W. Royce viết “Quản lý phát triển các hệ thống phần mềm lớn” (Managing the Development of Large Software Systems: Concepts and Techniques). Trong bài ông đã khái quát trình tự phát triển một phần mềm máy tính lớn đến tay người dùng. Đây chính là nền tảng của mô hình Waterfall (Thác nước). Ông cũng nói rằng mô hình này có thể được thay thế bởi mô hình lặp.
Hirotaka Takeuchi và Ikujiro Nonaka viết “Trò chơi phát triển sản phẩm mới” (The New New Product Development Game) trên tạp chí Harvard Business Review. Thay vì để một nhóm hoàn thành công việc của mình và chuyển sang cho nhóm khác, bài báo đề cập đến việc tất cả các nhóm cùng tham gia vào công việc, ở các giai đoạn khác nhau của phát triển sản phẩm. Họ so sánh phần mềm với quả bóng bầu dục, được chuyền qua lại giữa các thành viên cho đến vạch cuối sân. Trong bài viết sử dụng từ Scrum, một thuật ngữ trong bóng bầu dục.
Dựa trên bài viết của Hirotaka và Ikujiro, Jeff Sutherland và Ken Schwaber bắt đầu phát triển khái niệm Scrum. Tuy nhiên, phải đến 1995 Scrum mới được Sutherland hệ thống hóa và giới thiệu tại một hội thảo tại Austin, Texas, Hoa Kỳ.
Kent Beck khởi xướng Lập trình cực độ (Extreme Programming - XP). Ông được mời tư vấn, và sau đó bổ nhiệm làm người đứng đầu một dự án thử nghiệm tại Chrysler (Chrysler Payroll Project). Mục tiêu của Beck là nâng cao chất lượng phần mềm bằng cách đưa các hoạt động lập trình lên mức cao nhất có thể. Kent Beck xuất bản sách Extreme Programming Explained vào năm 1999.
Tuyên ngôn Agile (Manifesto for Agile Software Development - The Agile Manifesto). Vào tháng 2 năm 2001, 17 chuyên gia từ các phương pháp Extreme Programming, Scrum, DSDM, Adaptive Software Development… đã họp mặt tại khu nghỉ dưỡng trượt tuyết Snowbird, Utah, để chia sẻ các ý tưởng về phát triển phần mềm “gọn nhẹ” (Light). Tuy nhiên, cuối cùng họ chọn cái tên Agile để nói về cách thích nghi mới trong tình hình thị trường luôn biến đổi. Họ đã đưa ra Bản Tuyên ngôn Phát triển Phần Mềm Agile - thường gọi là Bản tuyên ngôn Agile. Bản Tuyên ngôn nhanh chóng lan rộng, và đến 2016 đã có hơn 20,000 người ký vào bản Tuyên ngôn.
Cũng trong năm 2001, Kent Beck và Mike Beedle đã xuất bản cuốn “Phát triển phần mềm Agile với Scrum”, chỉ ra vai trò của triết lý Agile, phương pháp Scrum, và cách áp dụng chúng trong các doanh nghiệp.
Hai tổ chức về Agile (Agile Alliance) và Scrum (Scrum Alliance) cũng được thành lập trong năm này.
Tom và Mary Poppendieck xuất bản cuốn “Phát triển Phần mềm Tinh gọn: Công cụ Agile” (Lean Software Development: An Agile Toolkit). Dựa trên quá trình Sản xuất Tinh gọn (Lean Manufacturing), Poppendieck đã đưa ra bảy nguyên lý của sự Tinh gọn (Lean thinking) và cách áp dụng nguyên lý vào phát triển phần mềm tinh gọn (Lean Software Development). Trong những cuốn sách sau đó, họ cũng giới thiệu về cách áp dụng Kanban trong Agile.
Từ đó đến nay, Agile đã trở thành sự tổng hợp của nhiều tư tưởng và mô hình áp dụng và vẫn không ngừng phát triển.
Như bạn có thể thấy, Agile là một tập hợp nhiều tư tưởng và cách ứng dụng khác nhau. Tuy 17 nhà lập trình đến từ những trường phái khác nhau, họ chia sẻ nhiều giá trị liên quan đến sự tất yếu của thay đổi, sự cần thích ứng với môi trường, và vai trò của cá nhân cũng như môi trường làm việc. Bốn giá trị của triết lý Agile đã được đúc kết trong Bản Tuyên ngôn Agile, và sau đó các giá trị này được làm rõ thông qua 12 nguyên tắc hoạt động.
Những người đi theo tuyên ngôn Agile đánh giá:
Agile đặt trọng tâm vào con người và sự cộng tác. Dự án của bạn, cho dù có quy trình và công cụ đúng và hiện đại nhất, cũng sẽ không thể thành công nếu thiếu đi những cá nhân chủ động và sẵn sàng hợp tác để đạt được mục tiêu.
Đối với khách hàng thì điều quan trọng và có giá trị nhất là sản phẩm phần mềm giải quyết được vấn đề của họ. Tài liệu giúp cho họ có thể sử dụng phần mềm một cách dễ dàng và hiệu quả nhưng nếu chúng ta tạo ra một phần mềm không hữu ích thì tài liệu cũng không có ý nghĩa gì.
Đối với người làm sản phẩm, không phải mọi thứ chúng ta tạo ra đều có giá trị. Có những chức năng chúng ta tạo ra xuất phát từ việc không nghiên cứu yêu cầu khách hàng, không xuất phát từ vấn đề thực tế cần giải quyết thì chức năng đó dù có chạy tốt cũng vẫn là thứ không có giá trị.
Mỗi khách hàng có một nhu cầu khác nhau và có thể thay đổi theo thời gian. Nếu chúng ta chỉ quan tâm tới việc hợp đồng viết gì và miễn cưỡng làm theo, chúng ta chưa chắc đã tạo ra được sản phẩm khách hàng thật sự cần. Hãy cộng tác và tham vấn khách hàng, để họ được tham gia trong quá trình làm sản phẩm cho phù hợp với họ.
Nói về giá trị của việc cộng tác mật thiết với khách hàng, anh Steve, CEO của Magestore cũng chia sẻ: “Sự cộng tác chặt chẽ với khách hàng có ý nghĩa vô cùng quan trọng trong quá trình làm phần mềm và là tác nhân quan trọng giúp cho dự án hoặc phần mềm thành công.
Cộng tác với khách hàng giúp chúng ta hiểu rõ mong muốn của họ hơn từ đó giúp tạo ra phần mềm có giá trị.
Cộng tác với khách hàng và bàn giao những gì ta làm được cho khách hàng sử dụng sớm sẽ giúp họ đưa ra những feedback để tránh được những hiểu lầm về yêu cầu sớm.”
Dự án phần mềm là một loại dự án vô cùng phức tạp và khó thể lập một plan chi tiết ngay từ đầu, nhất là đối với các sản phẩm mới hoặc các công ty startup. Sự linh hoạt là đặc điểm quan trọng nhất tư duy Agile. Những người tham gia vào dự án luôn luôn phải hiệu chỉnh kế hoạch của mình để thích nghi với những thay đổi và điều kiện mới.
Bốn giá trị này được làm rõ hơn thông qua 12 nguyên tắc hoạt động:
Ưu tiên hàng đầu của chúng ta là sự hài lòng của khách hàng, thông qua việc chuyển giao sản phẩm có giá trị, nhanh chóng, và liên tục.
Nguyên tắc đầu tiên nhấn mạnh vào các cụm từ:
Chấp nhận thay đổi yêu cầu, cho dù là ở các giai đoạn cuối của quy trình. Quá trình Agile tận dụng thay đổi để đem lợi thế cạnh tranh tới cho khách hàng.
Ở đây ta cần chú ý đến các từ khóa để hiểu hơn về nguyên tắc này
Chuyển giao sản phẩm thường xuyên, trong vài tuần hoặc vài tháng, với mục tiêu trong thời gian càng ngắn càng tốt.
Để hiểu được nguyên tắc số 3, bạn cần chú trọng vào các cụm từ:
Nguyên tắc này nhấn mạnh vào sự chuyển giao sản phẩm có giá trị và dùng được tới khách hàng. Để sản phẩm dùng được nghĩa là phải tuân theo các định nghĩa hoàn thành, điều kiện chấp nhận mà 2 bên đã thỏa thuận trong thời gian cộng tác.
Ví dụ về việc chuyển giao sản phẩm tại Magestore, hiện tất cả các team không chỉ là các team tech, mà cả các team Sales, Marketing cũng thực hiện các Sprint 1 tuần, chuyển giao giá trị, sản phẩm tới khách hàng theo từng tuần.
Thậm chí cả các em sinh viên thực tập ngành công nghệ thông tin, ngay khi mới vào Magestore, đã được rèn luyện thói quen chuyển giao sản phẩm thường xuyên, liên tục.
Các em làm thực tập đồ án dưới sự hướng dẫn của các anh chị senior tại Magestore. Sản phẩm cuối cùng là 1 bài luận văn, đồ án. Nhưng hàng tuần, các em sẽ có những phần tăng trưởng sản phẩm (increment), chuyển giao tới team làm việc, tới các anh chị làm cùng hoặc toàn công ty. Đó có thể là
Các nội dung, sản phẩm từng phần nhỏ như vậy sẽ giúp các em nhìn thấy được tiến bộ của bản thân. Đó cũng là các sản phẩm đóng góp vào 1 sản phẩm to cuối cùng, đó là luận văn/đồ án của các em.
Như vậy tư duy Agile, cụ thể là chuyển giao sản phẩm liên tục sẽ giúp các em liên tục có sự học tập, phát triển, thậm chí nhiều ý tưởng cải tiến (từ chính các góp ý của các anh chị tại Magestore) để ra được sản phẩm cuối cùng mang lại giá trị cho chính các em và người hưởng lợi (doanh nghiệp, team làm việc).
Người kinh doanh và các nhà kỹ sư phần mềm cần làm việc với nhau hàng ngày.
Hiểu về nguyên tắc thứ 4 của agile như thế nào?
- Business people - Hiểu là Product Owner hoặc bất cứ ai là người cầu nối giữa khách hàng và đội phát triển.
- Must work together - Nhấn mạnh vào trách nhiệm chung được chia sẻ bởi cả business people và development team.
Ở Magestore chúng mình đều ở trong các development team cross-functional. Các team này đều có người đứng ở view nhìn khách hàng là Product Owner, Business Analyst, Project Manager. Các thành viên này sẽ cộng tác sâu sát với các Developer để cùng nhau triển khai giải pháp cho khách hàng được thành công. Việc cộng tác mật thiết này thể hiện ở qua các cuộc họp hàng ngày Daily stand up meeting, các cuộc họp lên giải pháp, các tương tác 1-1 trực tiếp (gặp mặt hoặc call video) để làm rõ vấn đề. Việc nói chuyện và bày tỏ những khúc mắc với nhau hàng ngày giúp cho đội phát triển nhanh chóng bàn bạc, dùng trí tuệ tập thể để tìm ra phương án xử lý được các nút thắt cổ chai trong các dự án.
Xây dựng dự án với những cá nhân có động lực. Tạo môi trường và hỗ trợ họ nếu cần, và đặt niềm tin vào họ để hoàn thành công việc được giao.
Nguyên tắc này nhấn mạnh vào motivated individuals - các cá nhân có động lực. Để có được các thành viên giàu động lực và tinh thần làm việc hăng hái thì cần tạo ra môi trường an toàn để họ chủ động cam kết và hành động, triển khai phương án họ nghĩ ra. Loại bỏ các rào cản ngáng chân họ đồng thời tin tưởng rằng họ sẽ hoàn thành công việc họ đã cam kết.
Cách tối ưu và hiệu quả nhất để truyền đạt thông tin trong một nhóm phát triển là trực tiếp nói chuyện.
Nguyên tắc này nhấn mạnh vào sự hiệu quả của các phương thức giao tiếp truyền đat. Nói chuyện trực tiếp là tốt hơn cả. Nếu không gặp mặt được trực tiếp thì dùng video call. Tham gia vào các cuộc họp daily meeting hàng ngày, Sprint Planning, Review, Retrospective.
Ưu tiên các cách trực diện sẽ giúp team bạn không bị mất thời gian trong việc giao tiếp và trao đổi thông tin.
Sản phẩm cuối cùng chạy tốt chính là thước đo tiến độ.
Các sản phẩm dùng được, mang lại giá trị cho khách hàng chính là thước đo cho sự tiến bộ của đội phát triển trong doanh nghiệp. Kết quả theo sau một sản phẩm tốt là sự hài lòng của khách hàng và nguồn doanh thu từ sản phẩm làm ra.
Các quá trình Agile thúc đẩy sự phát triển bền vững. Người tài trợ, phát triển, và người dùng có thể duy trì nhịp độ ổn định và không ngừng.
Để hiểu về nguyên tắc thứ 8, cần chú ý đến cụm từ sustainable development - sự phát triển bền vững và constant pace - nhịp độ ổn định. Các đội phát triển cần giữ vững nhịp độ chuyển giao sản phẩm theo các phân đoạn (iteration - Sprint), giữ vững các nhịp độ làm việc, các sự kiện trong team như daily meeting, Sprint Planning, Review, và Retrospective.
Suy ngẫm về nguyên tắc thứ 8 của Agile, đã có lần anh Steve, CEO của Magestore chia sẻ về chủ đề thế nào là chuyển giao giá trị một cách đều đặn và bền vững?
Mỗi một team chọn một khoảng thời gian nhất định: 1 tuần, 2 tuần, 3 tuần hoặc 4 tuần để coi là độ dài của Sprint. Cứ sau mỗi khoảng thời gian đó, team sẽ bàn giao kết quả công việc của mình cho khách hàng. Kết quả này cần phải có đạt được các nguyên tắc sau:
Cần làm gì để có thể chuyển giao một cách đều đặn?
Chuyển giao sản phẩm/giá trị công việc một cách đều đặn đòi hỏi người thực hiện cần có các kỹ năng sau:
Sự để ý đến chất lượng kỹ thuật và thiết kế tốt sẽ tăng tính linh hoạt.
Cần chú ý vào cụm từ technical excellence - chất lượng kỹ thuật và good design- thiết kế tốt. Nhiều doanh nghiệp thường ưu tiên tốc độ đưa ra thị trường hơn là một thiết kế tốt.
Có thể người dùng cuối của bạn không quan tâm đến vấn đề kỹ thuật ngay từ đầu nhưng nếu team của bạn lờ đi việc thiết kế cấu trúc kỹ thuật quá lâu thì tốc độ ra thị trường của bạn cũng sẽ chậm lại. Khả năng thay đổi sản phẩm so với tốc độ thay đổi của thị trường sẽ giảm dần. Bạn sẽ mất đi tính linh hoạt.
Trên thực tế, nhiều quản lý và developers không chú trọng nguyên tắc này. Trong các dự án nhỏ thì không cần phải quan tâm nhiều đến thiết kế, vì bạn muốn đi nhanh. Nhưng nếu các dự án to thì cần chú trọng đến chất lượng kỹ thuật.
Sự đơn giản - nghệ thuật sắp xếp tối đa hóa lượng công việc chưa hoàn thành - là cần thiết.
Sự đơn giản, bắt đầu không phải là phát hiện lượng việc quan trọng để làm mà lại là ở chỗ phát hiện các công việc không quan trọng, nhằm loại bỏ chúng đi.
Tiếp tục là chia sẻ từ anh Steve về nguyên tắc thứ 10 về nghệ thuật của sự đơn giản hóa:
“Tại tối đa khối lượng những việc chưa hoàn thành lại là điều cần thiết?
Có phải là nguyên tắc này khuyên bạn làm ít đi hay không?
Nếu đúng thì tại sao làm ít đi lại là một điều quan trọng?
Để trả lời được những câu hỏi này thì bạn cần nhớ lại một triết lý rất cốt lõi của tư tưởng Agile là mọi việc mà bạn làm thì cần phải deliver giá trị cho khách hàng. Nếu một việc mà không deliver được giá trị cho khách hàng thì đó là một việc cần xem xét có nên làm hay không.
Ngoài ra Agile cũng nhấn mạnh đến tầm quan trọng của sự đơn giản hóa từ việc lập kế hoạch, các quy trình tổ chức thực hiện đến bản thân sản phẩm. Tất cả đều phải thực sự đơn giản, dễ hiểu và có giá trị đối với người sử dụng.
Quay trở lại nguyên tắc số 10 này, nếu bạn biết cách lựa chọn những điều quan trọng để làm, biết cách từ chối làm nhưng điều không đem lại giá trị. Thì quá trình đó chẳng phải là quá trình làm cho khối lượng những việc chưa hoàn thành hoặc chưa làm tăng lên hay sao?
Cụ thể hơn, để thực hành nguyên tắc này, bạn có thể:
Các cấu trúc, yêu cầu, và thiết kế tốt nhất đều xuất phát từ những nhóm có khả năng tự tổ chức.
Để hiểu được nguyên tắc này cần chú trọng đến cụm self-organizing team - team tự chủ, tự tổ chức.
Các team này sẽ hoạt động theo hình thức tự sắp xếp, lên kế hoạch triển khai công việc, được tự lựa chọn cách để giải quyết các bài toán được đưa ra bởi khách hàng. Chính các cá nhân giàu động lực trong một team làm việc tự chủ chính là những người có thể định nghĩa và chuyển giao được cấu trúc, yêu cầu và thiết kế tốt nhất tới khách hàng.
Đều đặn nhìn lại, phản tư, reflect để có thể tăng hiệu quả, và thay đổi hành vi cho phù hợp.
Ứng dụng các hoạt động như Retrospective, các hoạt động self-reflection vào trong công việc của cá nhân và đội nhóm, sẽ giúp team nhanh chóng tìm ra các điểm có thể sửa chữa, cải tiến.
Từ đó thay đổi hành động của mình trong các Sprint tiếp theo.
Trong Agile, quy trình phát triển sản phẩm được chia thành nhiều phân đoạn. Các phân đoạn trên tập trung vào giải quyết một yêu cầu duy nhất và lặp đi lặp lại. Các nhóm sẽ lên kế hoạch, phân tích yêu cầu, thiết kế, triển khai, và kiểm thử để cho ra các phần nhỏ của sản phẩm cuối cùng.
Mỗi phần nhỏ của sản phẩm được phát triển song song, tại những thời điểm cũng như tiến độ khác nhau. Mỗi phần nhỏ được kiểm thử độc lập và được tích hợp vào sản phẩm khi chúng chạy tốt. Các phần nhỏ sẽ được tích lũy dần dần cho đến khi đáp ứng được nhu cầu của khách hàng. Điều này giúp bạn dễ dàng theo dõi tiến độ phát triển sản phẩm, và giúp sản phẩm không ngừng tiến hóa cho phù hợp với điều khách hàng cần.
Trong quá trình thực hiện chúng ta có thể gặp thay đổi trong yêu cầu, công nghệ, nhân sự… Quy trình Agile có thể thay đổi để đáp ứng các điều kiện mới. Chúng ta có thể thêm các bước trong một phân đoạn, hoặc thêm các yêu cầu của khách hàng vào phân đoạn sau để xử lý.
Agile đặt con người lên trên công cụ và quy trình. Khác với cơ chế mệnh lệnh và kiểm soát thường gặp, các nhóm làm việc trong một tổ chức Agile chủ động đưa ra quyết định và giải quyết vấn đề mà không cần chờ lệnh từ cấp quản lý. Họ chủ động nhận các đầu việc theo phân công công việc, chứ không chỉ dựa trên chức vụ hay phân cấp trong tổ chức. Các nhóm này được trao quyền để tự ra quyết định và tổ chức công việc để đạt được hiệu quả cao nhất.
Trong một tổ chức Agile, bạn đưa ra quyết định dựa trên các số liệu thực tiễn thay vì lý thuyết và các giả định. Quản lý đánh giá các phân đoạn dựa trên bằng chứng sẽ giúp bạn có được phản hồi kịp thời, xác định các yếu tố đang hoạt động hiệu quả, và đưa ra phương hướng tiếp theo một cách nhanh chóng.
Agile nhấn mạnh tầm quan trọng của làm việc nhóm và cộng tác. Giữa công ty và khách hàng, thay vì sử dụng giấy tờ, Agile khuyến khích công ty nói chuyện trực diện với khách hàng để hiểu đúng yêu cầu của họ. Trong nội bộ công ty, Agile khuyến khích các thành viên trong nhóm trực tiếp trao đổi với nhau để đưa ra kế hoạch triển khai. Để thực hiện được điều này, các tổ chức Agile thường xây dựng các nhóm nhỏ (không quá 12 người) và có các cuộc họp tập trung hàng ngày.
Kết quả cuối cùng của phát triển phần mềm là một chương trình chạy tốt và mang lại giá trị cho khách hàng. Cách tốt nhất để tạo ra giá trị là thường xuyên trao đổi với khách hàng. Điều này sẽ giúp bạn xác định được các yêu cầu, cũng như tầm quan trọng của các yêu cầu này với khách hàng. Thông qua việc đánh giá độ ưu tiên, bạn có thể loại bỏ các phần thừa không đem lại giá trị cho sản phẩm và chuyển giao sản phẩm nhanh chóng, thường xuyên hơn.
Cuộc sống ngày nay thật bấp bênh và tương lai thì vô cùng mờ mịt. Hãy hình dung vụ thiên thạch va chạm trái đất cách đây 65 triệu năm đã chấm dứt sự thống trị của những con khủng long to xác nặng nề, chỉ những loài nhỏ bé như kiến mới có khả năng thích ứng cao và linh hoạt để có thể tồn tại và tiếp tục phát triển với số lượng lớn đến tận ngày nay.Mặc dù nhìn chung thế giới đang hòa bình và ổn định chính trị, nhưng sự phát triển nhanh chóng về công nghệ khiến cho môi trường kinh doanh sớm bị thay đổi. Điều này làm một doanh nghiệp dễ dàng lâm vào khủng hoảng hơn bao giờ hếMặc dù nhìn chung thế giới đang hòa bình và ổn định chính trị, nhưng sự phát triển nhanh chóng về công nghệ khiến cho môi trường kinh doanh sớm bị thay đổi. Điều này làm một doanh nghiệp dễ dàng lâm vào khủng hoảng hơn bao giờ hếtNgành phát triển phần mềm vốn không có rào cản cạnh tranh, mỗi năm có hàng triệu công ty ra đời trên thế giới và cũng chừng đó công ty phá sản. Các thị trường béo bở cũng nhanh chóng bị xâu xé hoặc bị biến đổi, giống như cơn bão Smartphone tràn qua đã nhấn chìm hãng Nokia chỉ trong vòng ba năm.
Mặc dù nhìn chung thế giới đang hòa bình và ổn định chính trị, nhưng sự phát triển nhanh chóng về công nghệ khiến cho môi trường kinh doanh sớm bị thay đổi. Điều này làm một doanh nghiệp dễ dàng lâm vào khủng hoảng hơn bao giờ hết.
Ngành phát triển phần mềm vốn không có rào cản cạnh tranh, mỗi năm có hàng triệu công ty ra đời trên thế giới và cũng chừng đó công ty phá sản. Các thị trường béo bở cũng nhanh chóng bị xâu xé hoặc bị biến đổi, giống như cơn bão Smartphone tràn qua đã nhấn chìm hãng Nokia chỉ trong vòng ba năm.
Trong hoàn cảnh đó, các khách hàng sử dụng phần mềm, đặc biệt là phần mềm dành cho doanh nghiệp; bản thân họ cũng là một doanh nghiệp, họ cũng đòi hỏi sự linh hoạt và tinh gọn để có thể tồn tại và phát triển trong thế giới kinh doanh khắc nghiệt. Càng ngày, họ đòi hỏi thời gian triển khai sử dụng một phần mềm phải càng ngắn. Không chỉ như vậy, sản phẩm phải phù hợp với mong muốn mục đích của họ, cũng như đáp ứng với sự thay đổi kinh doanh thường xuyên của họ. Đây là thách thức lớn đối với các cách tiếp cận truyền thống khi một phần mềm phải triển khai tính theo năm và chỉ đáp ứng nửa vời yêu cầu của khách hàng. Cộng thêm vào đó là tư tưởng coi khách hàng là một chiến tuyến đối nghịch khi xử lý các thay đổi yêu cầu liên tục diễn ra trong quá trình làm phần mềm.
Với mục đích nhắm đến sự linh hoạt và tinh gọn, Agile tỏ ra là một cách tiếp cận phù hợp để giải quyết vấn đề nan giải trên bằng cách khuyến khích việc cộng tác chặt chẽ với khách hàng, bàn giao sớm và thường xuyên các gói phần mềm dùng được luôn đến khách hàng. Bên cạnh đó, Agile cũng khuyến khích thấu hiểu rằng việc thay đổi yêu cầu của khách hàng là cần thiết và phải được tôn trọng và đáp ứng.
Ngoài ra về mặt quản trị nội bộ, Agile yêu cầu sự tự chủ của nhân viên trong hành động và xử lý tình huống vốn biến động không ngừng hàng ngày. Bằng cách đó Agile tháo gỡ lãnh đạo khỏi sự quan tâm và ràng buộc quá chi tiết vào công việc của nhân viên, để họ tập trung vào công việc làm chiến lược và đường lối, mục tiêu.
Và hơn tất cả, Agile khuyến khích niềm tin giữa các đồng đội trong công ty, đề cao sự tin tưởng qua lại giữa lãnh đạo và nhân viên, từ đó tạo ra sự gắn kết toàn công ty hướng tới một mục tiêu chung.
.jpg)
.jpg)
