Agile101: Thay đổi để phát triển

#AGILE101

Thay đổi để phát triển

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.

Vậy Agile là gì, có cần thiết không, và làm thế nào để trở nên Agile?

01.Agile là gì?

Định nghĩa 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:


  • Lập kế hoạch thích ứng (adaptive planning);
  • Phát triển lặp (iterative), gia tăng (incremental), và tiến hóa (evolutionary);
  • Chuyển giao sớm (early delivery); và
  • Không ngừng cải tiến (continual improvement).

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.

Lịch sử Agile

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 đó.

  1. 1950

    Nền tảng của Lean thinking

    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.

  2. February 28th, 1953

    Nền tảng của 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.

  3. 1970

    Nền tảng của mô hình Waterfall

    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.

  4. 1986

    Phát triển phần mềm và bóng bầu dục

    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.

  5. 1993

    Scrum

    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ỳ.

  6. 1996

    Extreme Programming

    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.

  7. 2001

    TUYÊN NGÔN AGILE

    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.

  8. 2003

    Lean Software Development

    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.

Tuyên ngôn Agile

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á:

04Giá trị

1. Cá nhân và sự tương tác hơn là quy trình và công cụ:

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.


2. Phần mềm chạy tốt hơn là tài liệu đầy đủ:

Điều người dùng quan tâm nhất là sản phẩm của họ hoạt động trơn tru. Việc tạo tài liệu hướng dẫn là cần thiết, nhưng việc tạo sản phẩm tốt quan trọng hơn trong Agile.


3. Cộng tác với khách hàng hơn là đàm phán hợp đồng:

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ọ.


4. Phản hồi dựa trên thay đổi hơn là bám theo kế hoạch

Dự án của chúng ta khi trên giấy và khi triển khai chắc chắn sẽ khác nhau, dù nhiều hay ít. Sự thay đổi có thể về mặt yêu cầu, về công nghệ, nhân sự… và đội ngũ công ty cần tập thích nghi với sự thay đổi.

Bốn giá trị này được làm rõ hơn
thông qua 12 nguyên tắc hoạt động:

12Nguyên Tắc
  • 1. Ưu tiên hàng đầu 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.
  • 2. 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.
  • 3. 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.
  • 4. 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.
  • 5. 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.
  • 6. 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.
  • 7. Sản phẩm cuối cùng chạy tốt chính là thước đo tiến độ.
  • 8. 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ì tiến độ ổn định và không ngừng.
  • 9. Sự để ý đến chất lượng kỹ thuật và thiết kế tốt sẽ tăng tính linh hoạt.
  • 10. 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.
  • 11. 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.
  • 12. Đều đặn đánh giá để có thể tăng hiệu quả, và thay đổi hành vi cho phù hợp.

7 đặc điểm của phương pháp Agile

1Tính module và lặp lại (modularity & iterative): 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.


2Gia tăng và tiến hóa (incremental and revolutionary): 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.


3 Thích ứng (adaptive): 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ý.


4 Nhóm tự tổ chức và liên chức năng (self-organizing & cross- function team): 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.


5 Quy trình thực nghiệm (empirical process): 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.


6 Giao tiếp trực diện (face-to-face communication): 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.


7 Phát triển dựa trên giá trị (value-based development): 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.

02.Tại sao cần Agile?

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ế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.

03.Làm thế nào để trở thành
doanh nghiệp Agile?

Agile bắt đầu từ mindset của bạn

Rất nhiều doanh nghiệp đang sử dụng Scrum, Kanban, hay Lean Programming. Tuy nhiên, họ không thật sự thành công trong việc thuyết phục nhân viên của mình về bản chất cũng như sự cần thiết của Agile. Việc áp dụng Agile cần bắt đầu từ việc thay đổi tư tưởng (mindset) của lãnh đạo cũng như nhân viên. Việc rèn luyện để có được Agile mindset sẽ giúp mọi người trong công ty bạn hướng tới các mục đích và giá trị chung, kể cả khi họ chưa thuộc lòng những khái niệm hay công cụ thường gặp trong Agile.

Không có một checklist cụ thể cho việc thế nào là có tư tưởng Agile, vì mỗi công ty sẽ có cách áp dụng của riêng họ tùy theo điều kiện. Tuy vậy, một tổ chức Agile thường có các đặc điểm sau:

  • Cởi mở chấp nhận các quan điểm khác nhau và đa dạng;
  • Có thái độ tích cực và vui vẻ;
  • Chấp nhận thay đổi và thích ứng nhanh;
  • Muốn cộng tác;
  • Chủ động chia sẻ và học tập;
  • Không ngừng cải tiến;
  • Coi thất bại là một cơ hội học hỏi;
  • Minh bạch và có trách nhiệm trong công việc.

Có nhiều khung quản lý và phương pháp Agile như Scrum

Agile là một triết lý với nhiều cách tiếp cận khác nhau, và bạn có nhiều lựa chọn để biến 4 triết lý và 12 nguyên tắc trên thành hiện thực. Có nhiều khung quản lý/phương pháp Agile như: Scrum, Kanban, Lean, Mô hình phát triển hệ thống năng động (DSDM), Extreme Programming, Mô hình Pha lê... Bài viết này sẽ giới thiệu về một trong số những phương pháp phổ biến nhất: Scrum.

Scrum là một khung làm việc có tính lặp và gia tăng dành cho các dự án. Scrum chia công việc phát triển phần mềm thành các chu trình làm việc gọi là Sprint. Mỗi Sprint có một khung thời gian xác định và kéo dài không quá một tháng. Sản phẩm cuối cùng của một Scrum là những phần nhỏ của sản phẩm đã hoàn thành. Trong phát triển phần mềm, “hoàn thành” thường là mã nguồn hoàn chỉnh, được kiểm thử đầy đủ, và có thể được chuyển giao.


Mọi thiết kế, quy tắc, hoạt động của Scrum đều xoay quanh 3 giá trị cốt lõi:

  • Minh bạch và thông suốt (transparency): Một công ty muốn có hiệu quả và phát triển bền vững cần minh bạch và thông suốt. Minh bạch không chỉ dừng ở mặt tài chính, mà cần thể hiện cả trong chiến lược, quy trình, đánh giá, cũng như vấn đề. Những yếu tố này cần được cả công ty chứ không chỉ lãnh đạo nắm rõ, để có thể đưa ra được quyết định đúng đắn nhất.
  • Thanh tra (inspection): Các thành viên chịu trách nhiệm cho công việc của mình và luôn chủ động đảm bảo chất lượng. Trong các Sprint cần có sự kiểm tra đánh giá liên tục để xác định vấn đề cũng như giải pháp.
  • Thích nghi (adaptation): Dựa trên sự minh bạch và liên tục kiểm tra, các nhóm có thể nhận phản hồi và chủ động đưa ra quyết định nhanh chóng. Điều này sẽ giúp cho nhóm thích nghi với các thay đổi về yêu cầu cũng như công việc.

Có 3 vai trò chính trong 1 scrum team:


Product owner - Chủ sản phẩm

Người chịu trách nhiệm về sự thành công của sản phẩm đang xây dựng. Có trách nhiệm đại diện cho lợi ích của các bên liên quan mật thiết. Có nhiệm vụ tối ưu hóa giá trị của sản phẩm thông qua việc quản lý thật tốt Product Backlog.

Scrum master

Người chịu trách nhiệm cho quy trình Scrum, đảm bảo nhóm hoạt động đúng quy tắc và tối đa hóa lợi ích từ Scrum.

Nhóm phát triển

Nhóm chịu trách nhiệm phát triển sản phẩm của Scrum. Nhóm có đặc điểm liên chức năng và tự tổ chức.


Trong một sprint có các sự kiện chính:



  • Lập kế hoạch: Diễn ra đầu mỗi Sprint để lên công việc cho toàn bộ Sprint. Trả lời 2 câu hỏi chính: Làm gì và Làm như thế nào.
  • Họp Scrum hàng ngày (Daily Scrum): Nhóm Phát triển thực hiện các buổi trao đổi ngắn hàng ngày để cập nhật tình hình công việc.
  • Sơ kết Sprint (Spring Review): Sự kiện cuối Sprint để kiểm tra và cập nhật sản phẩm đang được xây dựng. Gồm 2 hoạt động chính: Dùng thử sản phẩm và hướng đi tiếp theo.
  • Cải tiến Sprint (Sprint Retrospective): Diễn ra sau buổi Sơ kết Sprint, nhằm thanh tra và thay đổi quy trình làm việc cho thích ứng.

Ai đang thực hiện Agile?

Với những lợi ích Agile có thể đem lại, triết lý này đã lan rộng và được nhiều công ty không chỉ trong lĩnh vực phần mềm áp dụng. Agile không chỉ được cân nhắc bởi các CEO hay quản lý cấp cao, mà cũng thu hút sự chú ý của các developer, designer, marketer… Dưới đây là một số nghiên cứu về xu hướng sử dụng Agile trong doanh nghiệp.


Khảo sát Developers 2018 của Stack Overflow

85% số devs tham gia khảo sát sử dụng Agile trong việc. 63% cũng sử dụng Scrum.

Báo cáo State of Agile Marketing 2018 của AgileSherpas

37% marketers ở các vị trí khác nhau trong công ty sử dụng Agile để quản lý công việc. 80% số marketers hài lòng với cách tổ chức công việc của công ty mình là từ các nhóm Agile.


Khảo sát Pulse of the Profession 2018 của Project Management Institute

46% các tổ chức được khảo sát đã sử dụng Agile hoặc một phương pháp Agile hỗn hợp (Hybrid) trong vòng 12 tháng trước. Gần ⅓ số lượng project được hoàn thành của các tổ chức có áp dụng Agile


Báo cáo 12th Annual State of Agile Report của Version One Inc.

Theo báo cáo này, các lý do chính khiến các công ty áp dụng Agile bao gồm:

  • Rút ngắn thời gian chuyển giao sản phẩm;
  • Thay đổi mức độ ưu tiên linh hoạt;
  • Tăng hiệu quả làm việc;
  • Thống nhất định hướng kinh doanh/IT;
  • Cải thiện chất lượng phần mềm.

3 lĩnh vực đang áp dụng Agile nhiều nhất là Công nghệ thông tin, Dịch vụ tài chính, và Dịch vụ nghề nghiệp. Phương pháp/khung quản lý thường được sử dụng nhiều nhất là Scrum. Báo cáo này cũng cho thấy hầu hết các tổ chức áp dụng Agile đang thành công ở quy mô các project. Tuy nhiên, số lượng tổ chức đạt được thành công trong việc áp dụng Agile trên quy mô toàn công ty còn thấp.


Trên đây là những số liệu chung nhất về sự phổ biến của Agile không chỉ là trong lĩnh vực phát triển phần mềm. Bây giờ chúng ta sẽ đi sâu vào nghiên cứu cách một công ty áp dụng Agile: Spotify.

Spotify đã áp dụng Agile như thế nào?


Spotify là một dịch vụ nhạc số có trụ sở tại Stockholm, Thụy Điển. Được thành lập từ 2006, đến nay Spotify đã có trên 180 triệu người dùng, trong số đó có 83 triệu người sử dụng các gói trả phí. Công ty không ngừng nghiên cứu và giới thiệu các tính năng mới để người dùng có được trải nghiệm âm nhạc tốt nhất. Spotify là một công ty 100%-Agile, và đã thay đổi khung quản lý Scrum để thích ứng với điều kiện công ty.


Cấu trúc tổ chức tại Spotify:


Spotify tổ chức Scrum Team dưới tên gọi là Squad: một đội nhỏ, liên chức năng và tự tổ với ít hơn tám thành viên. Các thành viên trong nhóm có trách nhiệm từ đầu đến cuối, và họ làm việc cùng nhau hướng tới sứ mệnh lâu dài của họ.

Nhiều Squad làm trong cùng 1 mảng tạo thành các tribe (bộ lạc), họ có các tribe làm về front end và các tribe làm về backend và cũng có những tribe làm về operations.

Những người có cùng lĩnh vực kiến thức chuyên môn được tạo thành 1 chapter (nhóm liên kết) nhằm trợ giúp nhau về đào tạo kiến thức chuyên môn, tư vấn cách giải quyết vấn đề liên quan chuyên môn.

Bên cạnh đó, Spotify còn có Guide (hội), những cộng đồng tinh gọn có cùng sở thích giống như một câu lạc bộ với các chủ đề và kiến thức tại nhiều lĩnh vực khác nhau.


Quyền tự chủ:


Mỗi đội của Spotify có quyền tự chủ để quyết định xây dựng gì, làm thế nào để xây dựng nó, và làm thế nào để làm việc cùng nhau trong khi xây dựng.

Mọi người làm việc với quyền tự chủ là động cơ thúc đẩy xây dựng sản phẩm tốt hơn và nhanh hơn. Tự chủ làm cho chúng ta nhanh hơn khi các quyết định được thực hiện cục bộ ngay lập tức thay vì bởi các nhà quản lý và ủy ban.

Để giúp các đội đạt mức tự chủ cao, các quản lý phải đặt niềm tin vào Squad lên trên hết, lớn hơn cả tham vọng kiểm soát hoạt động theo cách thức quản lý truyền thống. Tuy nhiên, các đội vẫn cần phải được duy trì liên kết với nhiệm vụ chiến lược của sản phẩm và các mục tiêu ngắn hạn khác.


Vai trò của leader thể hiện trong Spotify như thế nào:

Với tổ chức như trên, leader tại Spotify không còn là một chức danh với quyền lực cụ thể, họ trở thành người có chuyên môn tốt và hướng tới việc giao tiếp với các thành viên khác trong công ty nhằm xác định vấn đề phải giải quyết và tại sao phải giải quyết. Họ hướng tới mục tiêu và mục đích, còn giải pháp để giải quyết vấn đề sẽ được giao cho các thành viên Squad cộng tác cùng thực hiện giải quyết.


Vấn đề release và tích hợp tại Spotify:

Thay vì tạo ra các quy tắc và quy trình rườm rà để quản lý các bản phát hành và tích hợp của họ, Spotify đã đơn giản hóa quy trình để khuyến khích các bản phát hành nhỏ và thường xuyên. Họ đã thay đổi kiến ​​trúc để cho phép các phiên bản được tách rời bằng cách sử dụng khung nhúng được mã hóa ngay trên giao diện. Mỗi phần của trình duyệt web giống như một khung của một trang web nơi mỗi Squad có thể phát hành trực tiếp nội dung của riêng họ.


Tại Spotify, họ thường xuyên phát hành các bản cập nhật dễ dàng và đều đặn giống như tàu khởi hành theo lịch trình thông thường của nó. Các chuyến tàu khởi hành thường xuyên với độ tin cậy cao mà không cần phải lập kế hoạch trước quá nhiều. Điều thú vị là Spotify phát hành các tính năng ẩn trên mỗi chuyến tàu, ví dụ: nếu chuyến tàu tiếp theo rời đi với một chức năng không hoàn thành 100%, họ sẽ vẫn phát hành tính năng này nhưng ẩn nó đi. Điều này giúp phát hiện sớm các vấn đề tích hợp và giảm thiểu nhu cầu phân nhánh mã.

Tại sao Agile thất bại trong thực tiễn? Những nguyên nhân thường gặp


Spotify thành công một phần không nhỏ là nhờ vào việc tổ chức công việc cũng như nhân sự một cách thông minh và linh hoạt. Tuy nhiên, nhiều công ty khi áp dụng Agile lại gặp không ít khó khăn. Dưới đây là một số nguyên nhân thường gặp khiến cho việc áp dụng Agile trong thực tiễn thất bại:


Sự tin tưởng:

Lãnh đạo và nhân viên chưa tin tưởng vào các giá trị và nguyên tắc của Agile, nhiều khi đối ngược lại với các nguyên tắc thông thường đã ăn sâu vào suy nghĩ. Chính tâm lý còn nghi ngờ nhưng đã vội vã áp dụng Agile khiến cho việc áp dụng Agile chỉ là phần vỏ, là bề nổi mà không thực sự giúp giải quyết được vấn đề của doanh nghiệp. Nói cách khác, áp dụng Agile thất bại cuối cùng vẫn là nguyên nhân con người.


Áp dụng nửa vời:

Khi năng lực quản lý có hạn và khả năng học tập chưa cao, nhiều nơi đã vội vã áp dụng Agile. Việc thực hành cũng không diễn ra thường xuyên, thiếu đúc rút kinh nghiệm, dẫn đến việc áp dụng Agile một cách nửa vời và không thể thành công. Lúc này, sự thất bại do bản thân lãnh đạo yếu kém trong kỹ năng quản lý và học tập.


Văn hóa không cởi mở:

Nhiều công ty, đặc biệt các công ty Châu Á, có văn hóa ít cởi mở, chia sẻ cũng như tự chủ và phối hợp làm việc nhóm. Trong văn hóa đó, mỗi nhân viên thường ngần ngại nói ra ý kiến của mình, mặc định coi rằng ý kiến của lãnh đạo là đúng đắn mà từ bỏ phản biện, hoặc cho rằng vì họ là lãnh đạo nên dù không phục vẫn phải làm. Bản thân lãnh đạo cũng thừa hưởng văn hóa đó nên khi truyền đạt có xu hướng ép buộc thực hiện dù vô tình hay cố ý.

04.Kết luận


Agile là một triết lý được nhiều công ty áp dụng để thích ứng nhanh với môi trường luôn luôn thay đổi. Các tổ chức Agile hướng tới lợi thế cạnh tranh và phát triển bền vững với con người và sự cộng tác là trung tâm. Agile bắt đầu từ việc thay đổi tư tưởng của mỗi cá nhân trong công ty, và sau đó áp dụng những phương pháp quản lý công việc như Scrum.

Để áp dụng một triết lý mới, chúng ta nên bắt đầu từ việc hiểu thật rõ nền tảng cũng như các giá trị của tư tưởng này. Hãy chia sẻ các kiến thức về Agile cho không chỉ các lãnh đạo mà toàn bộ nhân viên trong công ty bạn nhé.