Agile là gì scrum là gì

Agile là gì? Scrum là gì? Có rất nhiều phương thức phát triển phần mềm theo quy chuẩn, và một trong số đó là phương thức phát triển phần mềm theo mô hình Scrum. Bài viết này sẽ giải thích các khái niệm cơ bản nhất cũng như những giá trị cốt lõi về Agile để bạn có thể nắm chắc được.

Agile là gì?

Agile là một phương pháp phát triển phần mềm linh hoạt, là một hướng tiếp cận cụ thể cho việc quản lý dự án phần mềm. Nó gồm một quá trình làm việc tương tác và tích hợp để có thể đưa sản phẩm đến tay người dùng càng nhanh càng tốt.

Tuyên ngôn Agile được đưa ra bởi 17 nhà phát triển phần mềm, vào tháng 2/2001, tại Snowbird, Utah, Hoa Kỳ.

Nội dung tuyên ngôn Agile

Những phương pháp phát triển phần mềm theo cách truyền thống ngày càng bộc lộ nhiều nhược điểm và tỷ lệ các dự án thất bại cao trong thời kỳ bùng phát của ngành công nghệ. Nhận ra vấn đề đó, một số cá nhân và công ty riêng lẻ đã đưa ra các phương pháp phát triển phần mềm hiện đại hơn và khác nhau để thích ứng với tình hình mới.

Nguồn video: Học viện Agile

Những phương thức phát triển phần mềm này giúp phần nào giải quyết được một số vấn đề nhưng lại phát sinh vấn đề khác về sự cộng tác, kỹ thuật, công cụ, hướng phát triển, chia sẻ ….

Vào năm 2001, bản tuyên ngôn Agile [Agile Manifesto] đã được thống nhất và ra đời bởi một nhóm người có uy tính trong phát triển phần mềm:

• Individuals and interactions over processes and tools: Cá nhân và sự tương tác hơn là quy trình và công cụ.
• Working software over comprehensive documentation: Phần mềm chạy tốt hơn là tài liệu đầy đủ.
• Customer collaboration over contract negotiation: Cộng tác với khách hàng hơn là đàm phán hợp đồng.
• Responding to change over following a plan: Phản hồi với sự thay đổi hơn là bám theo kế hoạch.

Scrum là gì?

Scrum là một “bộ khung làm việc” cơ bản để tiếp cận những công việc phức tạp. Dựa trên bộ khung này, nhóm làm việc có thể áp dụng những quy trình, kỹ thuật khác nhau cho công việc của mình… Nó là một thành viên của họ Agile.

Scrum có ích gì cho phát triển phầm mềm hiện nay

Nó giúp loại bỏ những công đoạn phức tạp và chỉ tập trung vào những công đoạn cần thiết đáp ứng được nhu cầu của khác hàng đưa ra. Ba yếu tố nòng cốt tạo thành một mô hình quản lý tiến trình thực nghiệm gồm: sự minh bạch [transparency], thanh tra [inspection] và thích nghi [adaptation].

Ba giá trị cốt lõi của Scrum

1. Minh bạch

Muốn áp dụng thành công Scrum, các thông tin liên quan đến quá trình phải mình bạch và thông suốt. Các thông tin có thể là tầm nhìn của sản phẩm, yêu cầu của khách hàng, tiến độ công việc, các rào cản khác…

Từ đó mọi thành viên ở vai trò khác nhau có đầy đủ thông tin cần có để tiến hành quyết định trong việc nâng cao hiệu quả công việc.

2. Thanh tra

Phải thường xuyên thanh tra các hoạt động trong Scrum và tiến độ đến đích để phát hiện các bất thường không theo ý muốn. Tần suất thanh tra không nên quá dày để khỏi ảnh hưởng đến công việc. Công tác thanh tra khi được thực hiện bởi người có kĩ năng tại các điểm quan trọng của công việc sẽ giúp cải tiến liên tục trong Scrum.

3. Thích nghi

Scrum mang lợi thế là tính linh hoạt rất cao, nhờ đó mang lại tính thích nghi cao. Dựa vào thông tin liên tục và minh bạch từ quá trình thanh tra và làm việc, Scrum có thể cho lại các thay đổi tích cực, nhờ đó mang lại thành công cho dự án.

Lợi ích mà Scrum mang lại

Tính minh bạch, kiểm tra, và thích nghi là 3 nền tảng cơ bản của Scrum. Và dưới đây là những lý do tại sao nên dùng Scrum.

1. Cải thiện chất lượng phần mềm, dễ học và dễ sử dụng.
2. Rút ngắn thời gian phát hành phần mềm, cho phép khách hàng sử dụng sản phẩm sớm hơn.
3. Nâng cao tinh thần đồng đội, tối ưu hóa hiệu quả và nỗ lực của đội phát triển.
4. Gia tăng tỷ suất hoàn vốn đầu tư [ROI]
5. Tăng mức độ hài lòng của khách hàng
6. Kiểm soát dự án tốt, cải tiến liên tục
7. Giảm thiểu rủi ro khi xây dựng sản phẩm

Kết luận

Trên đây là một số kiến thức để bạn có thể biết được Agile là gì? Scrum là gì?

Chúc bạn học tốt~~~

Học Java Swing: //hocjava.com/java-swing-swing-trong-java/

Nguồn video: Học viện Agile

Hãy tham gia nhóm Học lập trình để thảo luận thêm về các vấn đề cùng quan tâm.

Agile software development đề cập đến các phương pháp luận phát triển phần mềm xoay quanh ý tưởng phát triển lặp đi lặp lại, trong đó các yêu cầu và giải pháp phát triển thông qua sự hợp tác giữa các nhóm chức năng chéo tự tổ chức. Giá trị cuối cùng trong phát triển Agile là cho phép các nhóm cung cấp giá trị nhanh hơn, với chất lượng và khả năng dự đoán cao hơn, cũng như khả năng phản ứng với sự thay đổi tốt hơn. Scrum và Kanban là hai trong số những phương pháp Agile được sử dụng rộng rãi nhất. Dưới đây là những câu hỏi thường gặp nhất xung quanh Agile và Scrum, do các chuyên gia của chúng tôi trả lời.

Agile software development đề cập đến một nhóm các phương pháp luận phát triển phần mềm dựa trên sự phát triển lặp đi lặp lại, trong đó các yêu cầu và giải pháp phát triển thông qua sự hợp tác giữa các nhóm chức năng chéo tự tổ chức. Các phương pháp Agile hay các quy trình Agile thường thúc đẩy quy trình quản lý dự án có kỷ luật, khuyến khích kiểm tra và thích ứng thường xuyên, triết lý lãnh đạo khuyến khích làm việc theo nhóm, tự tổ chức và có trách nhiệm giải trình, một tập hợp các phương pháp kỹ thuật tốt nhất nhằm bàn giao nhanh chóng sản phẩm với chất lượng cao, và một phương pháp kinh doanh gắn sự phát triển với nhu cầu của khách hàng và mục tiêu của công ty. 

Phát triển Agile đề cập đến bất kỳ quy trình phát triển nào phù hợp với các khái niệm của Tuyên ngôn Agile. Tuyên ngôn được phát triển bởi một nhóm gồm mười bốn nhân vật hàng đầu trong ngành công nghiệp phần mềm, phản ánh kinh nghiệm của họ về những cách tiếp cận phù hợp và không hiệu quả đối với sự phát triển phần mềm. Đọc thêm về Tuyên ngôn Agile. Bạn có biết rằng Agile cũng có thể được áp dụng cho các dự án phần cứng? Tìm hiểu về khung Agile for Hardware mang tính cách mạng của Cprime.

Còn Scrum thì sao?

Scrum là khung quy trình con của Agile. Đây là một khung quy trình "nhẹ" cho việc phát triển nhanh và được sử dụng rộng rãi nhất.

“Khung quy trình” là tập hợp các hoạt động thực tiễn cần được tuân theo để có quy trình nhất quán với khung. [Ví dụ: khung quy trình Scrum yêu cầu sử dụng các chu trình phát triển được gọi là Sprint, khung XP yêu cầu lập trình cặp, v.v.]

“Nhẹ” là tổng các bước của quy trình được tối giản nhất có thể, nhằm tối đa hóa lượng thời gian hiệu quả có sẵn để hoàn thành công việc hữu ích.

Quy trình Scrum được phân biệt với các quy trình khác bằng các khái niệm và thực tiễn cụ thể, được chia thành ba loại Roles, Artifacts, và Time Boxes. Các thuật ngữ này và các thuật ngữ khác được sử dụng trong Scrum được định nghĩa dưới đây. Scrum thường được sử dụng nhiều nhất để quản lý phát triển phần mềm và sản phẩm phức tạp, sử dụng các phương pháp lặp đi lặp lại và tăng dần. Scrum làm tăng đáng kể năng suất và giảm thời gian hoàn thành so với quy trình “Waterfall” cổ điển. Các quy trình Scrum cho phép các tổ chức điều chỉnh một cách trơn tru các yêu cầu thay đổi và sản xuất một sản phẩm đáp ứng các mục tiêu kinh doanh đang phát triển. Một quy trình Scrum nhanh mang lại lợi ích cho tổ chức bằng cách giúp tổ chức:

        Tăng chất lượng của các sản phẩm được bàn giao

        Đối phó tốt hơn với sự thay đổi [ngay cả những sự thay đổi không mong muốn]

        Cung cấp các ước tính tốt hơn trong khi tốn ít thời gian hơn để tạo chúng

        Kiểm soát tốt hơn lịch trình và trạng thái của dự án

Lợi ích Agile đem lại là gì?

Khách hàng nhận thấy rằng nhà cung cấp phản hồi nhanh hơn với các yêu cầu phát triển. Các tính năng có giá trị cao được phát triển và bàn giao nhanh chóng trong từng chu kỳ ngắn, so với chu kỳ dài hơi mà quy trình “Waterfall” cổ điển ưa chuộng.

Lợi ích cho nhà cung cấp

Nhà cung cấp giảm lãng phí bằng cách tập trung nỗ lực phát triển vào các tính năng có giá trị cao và giảm thời gian đưa ra thị trường so với quy trình “Waterfall” do giảm chi phí và tăng hiệu quả. Sự hài lòng của khách hàng được cải thiện đồng nghĩa với việc giữ chân khách hàng tốt hơn và nhiều lượt giới thiệu khách hàng tích cực hơn.

Lợi ích cho Nhóm phát triển

Các thành viên trong nhóm thích công việc phát triển do nhận thấy công việc của họ được sử dụng và đánh giá cao. Scrum mang lại lợi ích cho các thành viên trong Nhóm phát triển bằng cách giảm bớt công việc phi năng suất [ví dụ: viết thông số kỹ thuật hoặc các hiện vật khác mà không ai sử dụng] và cho họ nhiều thời gian hơn để làm công việc mà họ yêu thích. Các thành viên trong nhóm cũng biết công việc của họ được coi trọng, bởi vì các yêu cầu được lựa chọn để tối đa hóa giá trị cho khách hàng.

Lợi ích đối với người quản lý sản phẩm [Product Owner]

Quản lý sản phẩm, những người thường đảm nhiệm vai trò Chủ sở hữu sản phẩm, chịu trách nhiệm làm cho khách hàng hài lòng bằng cách đảm bảo rằng công việc phát triển phù hợp với nhu cầu của khách hàng. Scrum làm cho liên kết này trở nên dễ dàng hơn bằng cách cung cấp các cơ hội thường xuyên để sắp xếp lại thứ tự ưu tiên công việc, nhằm đảm bảo mang lại giá trị tối đa.

Lợi ích đối với người quản lý dự án [Project Manager]

Người quản lý dự án [và những người khác] đảm nhiệm vai trò ScrumMaster nhận thấy rằng việc lập kế hoạch, theo dõi dễ dàng hơn và cụ thể hơn so với quy trình “Waterfall”. Việc tập trung vào theo dõi cấp độ nhiệm vụ, sử dụng Biểu đồ Burndown để hiển thị tiến độ hàng ngày và các cuộc họp Scrum hằng ngày, tất cả đều mang lại cho Người quản lý dự án nhận thức sâu sắc về trạng thái của dự án mọi lúc. Nhận thức này là chìa khóa để giám sát dự án, đồng thời nắm bắt và giải quyết các vấn đề một cách nhanh chóng.

Lợi ích đối với PMO và Giám đốc điều hành cấp C

Scrum cung cấp khả năng hiển thị cao về trạng thái của một dự án phát triển hàng ngày. Các bên liên quan, chẳng hạn như giám đốc điều hành cấp C và nhân sự trong văn phòng quản lý dự án [PMO], có thể sử dụng khả năng hiển thị này để lập kế hoạch hiệu quả hơn và điều chỉnh chiến lược của họ dựa trên nhiều thông tin hơn và ít phải suy đoán hơn.

Scrum không chỉ định nghĩa các yêu cầu cần thực hiện mà còn có thể tập hợp các yêu cầu đó vào Product Backlog, và được gọi chung là “Product Backlog Items” hay viết tắt là “PBI”. Hầu hết các dự án Scrum đều mượn phương pháp “XP” [Lập trình cực đoan] để mô tả một yêu cầu tính năng dưới dạng “Câu chuyện của người dùng” - User Story, tuy nhiên vẫn có một số ít sử dụng khái niệm cũ hơn đó là “Trường hợp sử dụng” - Use Case. Trong bài viết này, chúng ta sẽ thảo luận với khái niệm User Story và mô tả ba tạo tác yêu cầu tiêu chuẩn được định nghĩa trong Product Backlogs.

User Story

Câu chuyện người dùng - User Story mô tả một tính năng mong muốn [yêu cầu chức năng] ở dạng tường thuật. Câu chuyện của người dùng thường do Product Owner viết và là trách nhiệm của Product Owner. Định dạng không được chuẩn hóa, nhưng thường có tên, mô tả, tham chiếu đến tài liệu bên ngoài [chẳng hạn như ảnh chụp màn hình] và thông tin về cách kiểm tra sản phẩm đạt tiêu chuẩn hay không. 

Ví dụ: một Câu chuyện có thể giống như sau:

Tên: Người lập kế hoạch nhập địa chỉ liên hệ mới vào sổ địa chỉ, để người khác có thể liên hệ với người đó sau này qua bưu điện hoặc thư điện tử

Mô tả: Người lên kế hoạch nhập thông tin liên hệ chuẩn [họ và tên, hai dòng địa chỉ đường phố, thành phố, tiểu bang, mã zip / mã bưu chính, quốc gia, v.v.] vào màn hình nhập liên hệ. Nhấn vào "Lưu" để lưu dữ liệu và "Hủy" để hủy dữ liệu và quay lại màn hình trước đó.

Cách kiểm tra: Tester nhập và lưu dữ liệu, tìm tên trong sổ địa chỉ và click vào đó. Nếu thấy màn hình nhập liên hệ hiển thị chế độ xem chỉ đọc, với tất cả dữ liệu đã được nhập trước đó thì là thành công.

Các yếu tố trong Câu chuyện người dùng - User Story này là:

Tên: Tên là một cụm từ hoặc câu mô tả. Ví dụ sử dụng cấu trúc cơ bản "Vai trò-Hành động-Lý do". Một cấu trúc khác, được phổ biến bởi Mike Cohn, tuân theo khuôn mẫu “Với tư cách là một , tôi muốn để .” Việc lựa chọn mẫu ít quan trọng hơn việc có một loại tiêu chuẩn khả thi nào đó.

Mô tả: Đây là mô tả mức độ cao [chi tiết thấp] về nhu cầu được đáp ứng. Đối với các yêu cầu về chức năng [hướng đến người dùng], mô tả được đặt ở dạng tường thuật. Đối với các yêu cầu phi chức năng, mô tả có thể được viết bằng bất kỳ hình thức nào dễ hiểu. Trong cả hai trường hợp, điểm mấu chốt là mức độ chi tiết vừa phải, bởi vì các chi tiết nhỏ được tính toán trong giai đoạn triển khai, trong các cuộc thảo luận giữa các thành viên trong nhóm, chủ sở hữu sản phẩm và bất kỳ ai khác có liên quan. [Đây là một trong những khái niệm cốt lõi của Scrum: Các yêu cầu được quy định ở mức cho phép ước tính sơ bộ công việc cần thiết để thực hiện chúng, không phải chi tiết.]

Màn hình và tài liệu bên ngoài: Nếu User Story yêu cầu thay đổi giao diện người dùng [đặc biệt là những thay đổi không nhỏ], thì User Story phải chứa hoặc liên kết đến một nguyên mẫu của những thay đổi. Bất kỳ tài liệu bên ngoài nào được yêu cầu để triển khai User Story cũng nên được liệt kê.

Cách kiểm tra: Việc triển khai một User Story được xác định là hoàn thành khi và chỉ khi, nó vượt qua tất cả các bài kiểm tra chấp nhận. Phần này cung cấp một mô tả ngắn gọn về cách User Story sẽ được kiểm tra. Đối với bản thân tính năng, tuy mô tả chi tiết sẽ được tiến hành trong quá trình test, nhưng chúng ta cần ít nhất một bản tóm tắt để hướng dẫn cách để tạo được kịch bản kiểm thử cho đội tester.

Có hai lý do để đưa thông tin về cách kiểm tra User Story. Lý do chính để hướng dẫn đội kiểm thử phát triển các kịch bản kiểm thử [kiểm thử chấp nhận] cho Story. Lý do lại, tuy không rõ ràng như cái trước, nhưng lại rất quan trọng. Với thông tin về cách kiểm tra User Story, nhóm phát triển sẽ ước tính lượng công việc cần thiết để thực hiện User Story đó [vì bản chất thiết kế và thực hiện thử nghiệm là một phần của toàn bộ quy trình phát triển].

Defect

Báo cáo lỗi [Defect Report / Bugs Report], là những mô tả về lỗi của sản phẩm khi hoạt động. Các bugs được lưu trữ trong một hệ thống theo dõi lỗi [bugs log system], hệ thống này có thể có hoặc có thể không thuộc cùng một hệ thống được sử dụng để lưu trữ Product Backlog. Trong trường hợp hệ thống log bugs và hệ thống lưu trữ Product Backlog không phải là một, thì cần một người [thường là Product Owner] nhập từng bug vào Product Backlog, để sắp xếp và lên lịch trình fix bugs.

Các vai trò trong Srum là?

Ba vai trò được xác định trong Scrum là ScrumMaster, Product Owner và Nhóm [bao gồm các thành viên trong Nhóm]. Những người hoàn thành các vai trò này làm việc cùng nhau chặt chẽ hàng ngày để đảm bảo luồng thông tin được thông suốt và giải quyết các vấn đề một cách nhanh chóng.

ScrumMaster

ScrumMaster [đôi khi được viết là “Scrum Master”, mặc dù thuật ngữ chính thức không có khoảng trắng sau “Scrum”] là người quản lý quy trình. ScrumMaster chịu trách nhiệm làm cho quy trình diễn ra suôn sẻ, loại bỏ các trở ngại ảnh hưởng đến năng suất và tổ chức và tạo điều kiện cho các cuộc họp quan trọng. Các trách nhiệm của ScrumMasters bao gồm:

        Hướng dẫn Product Owner cách tối đa hóa lợi tức đầu tư [ROI] và đáp ứng các mục tiêu của họ thông qua Scrum.

        Cải thiện cuộc sống của Nhóm phát triển bằng cách tạo điều kiện cho sự sáng tạo và trao quyền.

        Cải thiện năng suất của Nhóm phát triển theo bất kỳ cách nào có thể.

        Cải thiện các công cụ và thực hành kỹ thuật để cải thiện chức năng.

        Luôn cập nhật thông tin về tiến trình của Nhóm và báo cáo cho tất cả các bên.

Về mặt thực tế, ScrumMaster cần hiểu đủ về Scrum để đào tạo và cố vấn các vai trò khác, đồng thời giáo dục và hỗ trợ các bên liên quan khác tham gia vào quá trình này. ScrumMaster nên duy trì nhận thức thường xuyên về tình trạng của dự án [tiến độ của dự án cho đến nay] so với tiến độ dự kiến, điều tra và tạo điều kiện giải quyết mọi rào cản cản trở tiến độ và thường đủ linh hoạt để xác định và giải quyết bất kỳ vấn đề nào phát sinh, theo bất kỳ cách nào được yêu cầu. ScrumMaster phải bảo vệ Nhóm khỏi việc bị làm phiền từ những người khác bằng cách đóng vai trò là giao diện giữa các bên. ScrumMaster không phân công nhiệm vụ cho các thành viên trong Nhóm, vì việc phân công nhiệm vụ là trách nhiệm của Nhóm. Phương pháp chung của ScrumMaster đối với Nhóm là khuyến khích và tạo điều kiện cho khả năng ra quyết định và giải quyết vấn đề của họ, để họ có thể làm việc với hiệu quả ngày càng cao và giảm nhu cầu giám sát. Mục tiêu là có một nhóm không chỉ được trao quyền để đưa ra các quyết định quan trọng mà còn thực hiện rất tốt và thường xuyên.

Product Owner là người lưu giữ các yêu cầu. Product Owner cung cấp “nguồn sự thật duy nhất” cho Nhóm về các yêu cầu và trình tự thực hiện theo kế hoạch của họ. Trên thực tế, Product Owner là người giao tiếp giữa một bên là doanh nghiệp, khách hàng và các nhu cầu liên quan đến sản phẩm của họ và bên kia là Nhóm. Product Owner hỗ trợ Nhóm từ các yêu cầu sửa lỗi và tính năng đến từ nhiều nguồn và là đầu mối liên hệ duy nhất cho tất cả các câu hỏi về yêu cầu sản phẩm. Product Owner làm việc chặt chẽ với nhóm để xác định các yêu cầu kỹ thuật và hướng tới người dùng, ghi lại các yêu cầu khi cần thiết và xác định thứ tự thực hiện chúng. 

Product Owner duy trì Product Backlog [là kho lưu trữ tất cả thông tin này], giữ cho nó được cập nhật ở mức độ chi tiết và chất lượng mà Nhóm nghiên cứu yêu cầu. Product Owner cũng đặt lịch trình để release sản phẩm đã hoàn thành cho khách hàng và đưa ra những quyết định cuối cùng về việc liệu sản phẩm có đủ các tính năng và chất lượng cần thiết để release hay không.

Team - Nhóm phát triển sản phẩm

Nhóm phát triển sản phẩm là một nhóm tự tổ chức, gồm nhiều chức năng, những người thực hiện công việc phát triển và thử nghiệm sản phẩm. Vì Nhóm chịu trách nhiệm phát triển sản phẩm, nên Nhóm cũng phải có quyền đưa ra quyết định về cách thức thực hiện công việc. Do đó, Nhóm sẽ tự tổ chức: Các thành viên trong Nhóm quyết định cách chia công việc thành các nhiệm vụ và cách phân bổ nhiệm vụ cho các cá nhân trong suốt Sprint. Quy mô Nhóm nên được duy trì trong khoảng từ năm đến chín người, nếu có thể. [Số lượng lớn hơn làm cho việc giao tiếp trở nên khó khăn, trong khi số lượng nhỏ hơn dẫn đến năng suất thấp và dễ hỏng.] Lưu ý: Một thuật ngữ rất giống nhau, “Nhóm Scrum” - Scrum Team, dùng để chỉ Nhóm cộng với ScrumMaster và Product Owner.

Agile liên quan tới DevOps như nào?

Trong khi Agile và DevOps bắt đầu là các phong trào phương pháp luận độc lập, chúng có chung một số đặc điểm tập trung vào việc cải thiện hiệu quả và tốc độ của nhóm. Khi các tổ chức trở nên Nhanh nhẹn hơn và tinh chỉnh bộ kỹ năng quản lý dự án của họ, họ ngày càng phụ thuộc vào các đội kỹ thuật có thể theo kịp tốc độ và duy trì sự linh hoạt nhất định.

Đây là nơi DevOps xuất hiện với tư cách là “dương” đối với “âm” của Agile. Phương pháp DevOps giúp các nhóm phát triển sử dụng các công cụ mới, tự động hóa và các chiến lược văn hóa khác nhau để thay đổi không chỉ cách họ làm việc mà còn cả cách họ làm việc với những người khác. Nó trở thành một mối quan hệ cộng sinh nơi các nhóm sản phẩm làm việc song song với các nhà phát triển và người thử nghiệm và những thứ tương tự để đảm bảo mọi người có nhận thức về ngữ cảnh nhiều hơn. Điều này thúc đẩy chất lượng tổng thể tốt hơn của các sản phẩm được phân phối trong một khoảng thời gian ngắn hơn.

Tôi nên sử dụng Scum, Kanban, hay một khung quy trình nào khác của Agile?

Scrum là khung quy trình chủ đạo dựa trên các phương pháp luận của Agile được sử dụng ngày nay, nó đã hơn hai mươi năm tuổi và đã được kiểm tra theo thời gian. Còn đối với Kanban, người ta cho rằng nó có nguồn gốc từ sản xuất và Toyota đã áp dụng nó vào năm 1953, một cách tiếp cận lâu đời khác. Về sau này cùng với sự phát triển của quy mô tổ chức, đã xuất hiện thêm nhiều khung quy trình mở rộng để đáp ứng phù hợp cho từng công ty. Bởi vậy việc lựa chọn khung quy trình nào sẽ phải phụ thuộc vào hoàn cảnh của doanh nghiệp bạn đang làm việc. 

Những nhu cầu thương mại nào thách thức doanh nghiệp của bạn? Quy mô tổ chức của bạn là gì? Công ty của bạn được tổ chức như thế nào? Các nhóm sản phẩm cốt lõi của bạn có bị phân tán ở nhiều vị trí địa lý không? Do đó, các vấn đề thương mại thực tế mà doanh nghiệp của bạn phải đối mặt và cách bạn phản hồi với khách hàng là câu trả lời cho câu hỏi mà bạn đang băn khoăn.

Đặt câu hỏi, “Scrum, Kanban hoặc một thứ gì khác?” là bước đầu tiên và là nơi tuyệt vời để bắt đầu. Coi sự thay đổi theo hướng tiếp cận Agile là bước đầu tiên hướng tới sự bền vững. Như đã mô tả ở trên, Agile là một yêu cầu cho sự thành công trong tương lai, nó không phải là mới. Những tổ chức không áp dụng các hình thức Agile, không đáp ứng được nhu cầu của khách hàng và thị trường sẽ bị thiệt thòi đáng kể.