Chúng tôi làm việc theo phương pháp Agile. Bạn sẽ nghe câu nói này khá nhiều khi nói chuyện với các nhóm phát triển phần mềm. Và đó là sự thật, theo thống kê , khoảng 90% các nhà phát triển trên toàn thế giới đã sử dụng Agile vào năm 2018.

Tuy nhiên, Agile không đồng nhất. Là một cách tiếp cận chung để tổ chức một quy trình làm việc, phát triển phần mềm theo phương pháp Agile đặt ra các giá trị và nguyên tắc chung nhằm làm cho quá trình phát triển trở nên hợp lý, hiệu quả và đáp ứng thay đổi. Các giá trị và nguyên tắc này có thể được tìm thấy trong Tuyên ngôn Agile đưa ra các khuyến nghị chung về việc thiết lập dòng chảy phát triển.

Tuy nhiên, trong thực tế, các nguyên tắc Agile này đã tìm thấy một số triển khai thực tế được gọi là các khung phát triển phần mềm. Kanban và Scrum là một trong những quy trình phổ biến nhất và được sử dụng thường xuyên. Tuy nhiên, trong khi cả hai phương pháp đều có một mục tiêu chung là tạo ra một quy trình làm việc hiệu quả, có một số khác biệt nhất định mà chúng ta sẽ thảo luận hôm nay.

Hiểu hoạt động của Scrum và Kanban có thể giúp cả khách hàng và nhà phát triển hiểu được nhịp điệu làm việc của nhóm và lên kế hoạch cho các hoạt động của họ phù hợp.

Khái niệm cơ bản về Scrum và Kanban

Scrum là gì?

Scrum được tên của nó từ một thuật ngữ bóng bầu dục có nghĩa là một đội hình các cầu thủ làm việc cùng nhau để sở hữu bóng. Trong phát triển phần mềm , Scrum cũng đề cập đến phương pháp tổ chức làm việc nhóm để làm cho việc phát triển các sản phẩm phần mềm tinh vi hiệu quả hơn.

Triết lý Scrum dựa trên giả định - hay, chúng ta nên nói, thực tế? - rằng nhóm phát triển không biết kết quả của dự án ngay từ đầu và sẽ học hỏi và thích nghi khi công việc tiếp tục phát triển. Scrum được thiết kế để làm cho việc điều chỉnh đó dễ dàng hơn bằng cách đặt lại các ưu tiên ở đầu mỗi lần lặp, được gọi là cuộc chạy nước rút trong thuật ngữ Scrum.

Ở đây chúng ta đến với một trong những khái niệm trung tâm của Scrum - sprint, đó là khoảng thời gian từ 2 đến 4 tuần, trong đó một lượng công việc nhất định được thực hiện. Sprint giúp chia phạm vi dự án thành các nhiệm vụ được quản lý dễ dàng hơn và phân phối các thành phần phần mềm hoạt động thường xuyên hơn. Chúng tôi sẽ có thêm thông tin chi tiết về kế hoạch sprint, điều chỉnh và hoàn thành trong thời gian ngắn.

Làm việc với các sprint và tập trung vào các nhiệm vụ cần hoàn thành trong mỗi sprint cho phép chúng ta có thể linh hoạt trong việc lập kế hoạch. Nhóm bắt đầu mỗi sprint mới với một “clean slate” và lập kế hoạch cho các nhiệm vụ với tình hình hiện tại và bất kỳ thay đổi nào trong các yêu cầu dự án đã nhận được cho đến nay.

Kanban là gì?

Kanban lần đầu tiên được phát minh bởi Toyota trong nỗ lực tối ưu hóa hàng tồn kho của nhà máy. Trong tiếng Nhật, "kanban" có nghĩa là một bảng hoặc thẻ. Trong triển khai ban đầu, một bộ phận nhà máy đang thiếu một mặt hàng nào đó sẽ gửi một chiếc "kanban" đến kho yêu cầu nạp lại. Kho, đến lượt mình, kho gửi các "kanban" tới nhà cung cấp để đặt thêm hàng nhiều hơn nữa.

Từ ví dụ này, chúng ta có thể thấy rằng phương pháp Kanban tập trung vào năng lực hiện tại và đây là khái niệm chính mà nó đưa vào phát triển phần mềm. Không giống như Scrum, Kanban không có giới hạn thời gian; thay vào đó, nó giới hạn số lượng công việc có thể được thực hiện cùng một lúc.

Một trong những số liệu chính của Kanban là công việc trong tiến trình của mình - các nhiệm vụ hiện đang được thực hiện. Theo Kanban, để đạt được hiệu quả tối đa, công việc đang tiến hành nên được giới hạn tương ứng với năng lực của nhóm, do đó giảm rủi ro của bất kỳ tắc nghẽn nào.

Kanban cũng thích nghi tốt với sự thay đổi, điều này rất quan trọng vì những thay đổi có thể được thực hiện ở bất kỳ giai đoạn nào của dự án và được thêm vào nhóm nhiệm vụ sẽ được thực hiện.

Scrum vs Kanban - sự khác biệt chính

Nếu chúng ta muốn so sánh Scrum và Kanban, chúng ta cần xem xét cách cả hai khung tổ chức quy trình công việc và các thực thể và định nghĩa chính mà chúng sử dụng.

Vai trò

Sự phân công vai trò là sự khác biệt lớn đầu tiên giữa Scrum và Kanban. Trong Scrum, bạn luôn tìm thấy ba vai trò chính trong một nhóm:

- Chủ sở hữu sản phẩm , người phụ trách sản phẩm. Chủ sở hữu sản phẩm phân tích các yêu cầu của khách hàng về sản phẩm và chuyển chúng thành các nhiệm vụ cho nhóm. Chủ sở hữu sản phẩm cũng ưu tiên các nhiệm vụ và quyết định khi nào một thành phần chức năng cụ thể có thể được phát hành.
- Scrum Master , người phụ trách nhóm. Scrum Masters, trước hết, giới thiệu các nguyên tắc Scrum cho các thành viên trong nhóm của họ và hỗ trợ họ thực hiện. Ngoài ra, Scrum Masters quản lý việc phân phối nguồn nhân lực cần thiết để cung cấp một cuộc chạy nước rút cụ thể.
- Đội ngũ , người phụ trách công việc. Các thành viên trong nhóm thực sự hoàn thành công việc. Một nhóm scrum sở hữu nhiều kỹ năng, với một số kỹ năng thường được kết hợp trong một người. Nhóm làm việc theo nguyên tắc tự tổ chức, hỗ trợ lẫn nhau để hoàn thành công việc.

Kanban, đến lượt nó, không có yêu cầu nghiêm ngặt nào về vai trò của đội. Cũng có thể có Chủ sở hữu sản phẩm giám sát các nhiệm vụ trong dự án tồn đọng, nhưng nếu không, nhóm sẽ tự tổ chức.

Quy trình làm việc

Như chúng ta đã đề cập, quá trình phát triển Scrum tiến triển theo các lần lặp, xác định công việc sẽ được thực hiện trong mỗi lần lặp, trong khi Kanban nhằm mục đích giới hạn công việc hiện tại đang tiến hành không có giới hạn thời gian cụ thể. Chúng ta hãy xem hai cách tiếp cận này có ý nghĩa gì trong cuộc sống thực.

Scrum Flow

Lập kế hoạch dự án bắt đầu bằng việc xác định tồn đọng, nghĩa là danh sách các câu chuyện của người dùng nên được thực hiện để phân phối sản phẩm đã hoàn thành. Trong ngữ cảnh này, Scrum sử dụng các khái niệm chính sau đây sẽ giúp chúng tôi hiểu cách thức công việc được lên kế hoạch và phân phối:

Product backlog - đại diện chính cho "To Do" list của cả đội. Việc tồn đọng sản phẩm bao gồm tất cả các tính năng và sửa lỗi cần được thực hiện để dự án được coi là hoàn thành. Backlog được cập nhật liên tục với các yêu cầu mới hoặc các lỗi được phát hiện được lên lịch cho công việc. Product Owner chịu trách nhiệm tồn đọng, đưa nó đồng bộ với phản hồi và đề xuất của khách hàng và tiến độ công việc của nhóm. Một số mục của hồ sơ tồn đọng có thể được di chuyển lên hoặc xuống trong xếp hạng ưu tiên, một số mục có thể được thêm vào khi các yêu cầu thay đổi và những mục khác có thể được xóa hoàn toàn.

Sprint backlog - bao gồm các nhiệm vụ phải được thực hiện trong một sprint cụ thể. Các mục sprint tồn đọng được chọn để cung cấp một tính năng hoặc thành phần hoàn thành vào cuối sprint . Mặc dù sprint backlog cũng cho phép sự linh hoạt và sửa đổi nhất định, các mục tiêu của sprint nên không thay đổi và các thay đổi nên được giữ ở mức tối thiểu.

Sprint goal, hoặc Increment - là một sản phẩm có thể sử dụng như là kết quả của sprint Thông thường, một sprint kết thúc bằng một bản demo hiển thị các tính năng hoặc thành phần đã hoàn thành. Về mặt này, một khái niệm quan trọng là định nghĩa về việc thực hiện của Google đã đề cập đến từng câu chuyện của người dùng để xem xét nó hoàn chỉnh hay chưa. Định nghĩa của các lần thực hiện, có thể khác nhau tùy theo câu chuyện của người dùng: nó có thể bao gồm nhiều nhiệm vụ, chẳng hạn như phát triển, thử nghiệm, thiết kế, tài liệu và trình bày và nó cũng có thể liên quan đến các thành viên khác trong nhóm. Mỗi sprint bắt đầu với giai đoạn lập kế hoạch trong đó các nhiệm vụ cho sprint tiếp theo được chọn. Đối với kế hoạch, nhóm đầy đủ thường có mặt, bao gồm Product Owner và Scrum Master. Nhóm quyết định những gì họ có thể cung cấp vào cuối sprint và chọn những câu chuyện người dùng tương ứng từ hồ sơ product backlog. Bằng cách này, họ cùng nhau xử lý sprint backlog.

Trong suốt 1 sprint, nhóm gặp gỡ hàng ngày cho một "scrum daily" , nơi họ thảo luận về tiến trình của họ và bất kỳ khối nào họ có thể gặp phải. Mục đích của" scrum daily" là phát hiện sớm các vấn đề và tìm ra giải pháp nhanh chóng để không làm gián đoạn sprint.

Sau sprint, các tính năng hoàn thành được xem xét bởi các bên liên quan. Trong quá trình đánh giá sprint,, nhóm có cơ hội nhận được phản hồi về công việc của họ và các đề xuất thay đổi, nếu có.

Đồng thời, nhóm gặp gỡ cho "sprint retrospective" , nơi họ phân tích sprin mà họ vừa hoàn thành và tìm thấy những điều có thể được cải thiện. Sau đó, quy trình được đặt lại và sprint mới bắt đầu với giai đoạn lập kế hoạch.

Dòng chảy Kanban

Ở Kanban, không có khoảng thời gian nào trong đó một số lượng công việc nhất định phải được thực hiện. Thay vào đó, Kanban tập trung vào việc cân bằng năng lực của đội với công việc hiện đang được tiến hành.

Luồng dự án Kanban bắt đầu với tồn đọng chung bao gồm tất cả các nhiệm vụ nên được thực hiện. Mỗi thành viên trong nhóm chọn một nhiệm vụ cho mình từ hồ sơ tồn đọng và tập trung hoàn thành nó. Khi nhiệm vụ hoàn thành, thành viên sẽ chọn cái tiếp theo, và cứ thế cho đến khi hết hàng tồn đọng. Việc tồn đọng được ưu tiên với các nhiệm vụ khẩn cấp nhất được đặt lên hàng đầu để được nhóm chọn trước.

Ở Kanban, điều quan trọng là số lượng công việc đang tiến hành không vượt quá khả năng của nhóm bất cứ lúc nào trong dự án. Với mục đích đó, có khả năng đặt giới hạn cho bất kỳ loại công việc nào theo khả năng có sẵn.

Product Owner có thể đặt và thay đổi các ưu tiên trong hồ sơ tồn đọng bao nhiêu lần và bao nhiêu lần tùy thích, vì quản lý tồn đọng không ảnh hưởng đến hiệu suất của nhóm. Nhóm chỉ quan tâm đến công việc đang tiến hành, chỉ quay lại tồn đọng sau khi nhiệm vụ hiện tại hoàn thành.

Mỗi nhiệm vụ thực hiện To Do - Làm việc trong tiến trình trực tiếp - Cách thực hiện. Tất nhiên, Kanban cũng hỗ trợ khái niệm về các định nghĩa về việc thực hiện của Wap, đây là tiêu chí cho sự chấp nhận của mỗi nhiệm vụ.

Cuối cùng, các nhiệm vụ đã hoàn thành tạo thành các thành phần mà có thể đo thời gian cần thiết để phân phối chúng. Ở Kanban, nó được gọi là thời gian chu kỳ của người dùng , và phép đo thời gian theo chu kỳ có rất nhiều cơ hội tối ưu hóa. Tất nhiên, tất cả đội đều cố gắng cho thời gian chu kỳ ngắn hơn và tìm cách giải quyết các tắc nghẽn, nếu có.

Trong bối cảnh này, điều quan trọng là phải có các thành viên có nhiều kỹ năng trong nhóm. Nếu một kỹ năng nhất định chỉ được sở hữu bởi một người - ví dụ, nếu bạn chỉ có một người kiểm tra - đó là một nút cổ chai. Tất cả các nhiệm vụ thử nghiệm sẽ xếp hàng để xử lý sự chậm trễ trong phân phối sản phẩm.

Kanban vs. Scrum board

Bảng Scrum

Một bảng Scrum bao gồm tối thiểu ba cột được dán nhãn là “To Do”, “In Progress”, và “Done”.. Khi cần, bạn có thể thêm một cột “User Story”

Vào đầu mỗi sprint, tất cả các nhiệm vụ đều nằm trong cột đầu tiên và đến cuối sprint, tất cả chúng sẽ chuyển sang cột "done". Sau đó, bảng có thể được xóa và chuẩn bị cho sprint tiếp theo.

Một bảng Scrum luôn được sở hữu bởi một nhóm làm việc trên cùng một sản phẩm.

Bảng Kanban

Một bảng Kanban nhìn chung và hoạt động giống như Scrum với một điểm khác biệt chính - có một giới hạn được hiển thị trong cột Trong tiến trình. Số lượng nhiệm vụ trong tiến trình không được vượt quá số lượng đó.

Bảng Kanban tồn tại trong toàn bộ thời gian của quy trình làm việc. Không cần thiết lập lại chúng, vì chúng không bị ràng buộc với bất kỳ khoảng thời gian cụ thể nào.

Vì các bảng Kanban được dành cho một quy trình công việc cụ thể, chúng không thuộc sở hữu của bất kỳ nhóm cụ thể nào và có thể được chia sẻ. Trong Kanban, một bảng có thể được sử dụng cho một dòng công việc cụ thể, ví dụ như một bảng tiếp thị.

Lựa chọn nào - Scrum hay Kanban?

Nếu bạn đã chờ đợi câu trả lời kết luận cho câu hỏi này, chúng tôi có thể làm bạn thất vọng. Đến bây giờ, chúng tôi hy vọng chúng tôi đã quản lý để chỉ ra rằng cả hai phương pháp đều có lợi ích của chúng và cả hai đều có thể giúp thiết lập quy trình phát triển Agile. Tuy nhiên, chúng tôi cung cấp một vài hướng dẫn có thể giúp bạn chọn những gì phù hợp nhất với nhóm của bạn.

Sử dụng Scrum nếu:

Bạn có thể dễ dàng chia phạm vi của mình thành các khối logic có thể được hoàn thành trong khoảng thời gian hai tuần. Bạn cần một mức độ dự đoán cao cho toàn bộ dự án. Scrum tập trung vào việc giữ các thay đổi trong 1 sprint đến mức tối thiểu. Bạn có nhiều thành viên mới trong đội. Với Scrum, họ sẽ dễ dàng hơn để hiểu kỷ luật nhóm và cải thiện, nếu cần.

Sử dụng Kanban nếu:

Bạn mong đợi rất nhiều thay đổi thường xuyên trong dự án. Rất khó để cô lập các thành phần sản phẩm có thể được giao trong khoảng thời gian hai tuần. Nhóm của bạn có kỷ luật tốt và có thể được tin cậy để sắp xếp các hoạt động của họ mà không có thời hạn nghiêm ngặt.

Tuy nhiên, tin tốt là bạn luôn có thể kết hợp! Thậm chí còn có một phương pháp gọi là Scrumban có các phương pháp của cả Scrum và Kanban. Trong Scrumban, bạn làm việc trong các vòng lặp ngắn giữ cho công việc của bạn tiến triển trong một giới hạn nhất định. Lặp lại mới được kích hoạt bởi công việc đang tiến hành nằm dưới giới hạn.

Như bạn thấy, việc chọn một phương pháp quản lý dự án có thể linh hoạt và miễn phí như bạn muốn. Không có quy tắc nào được khắc trên đá, và bạn có thể điều chỉnh, trộn và kết hợp chúng khi bạn thấy tốt nhất cho dự án của mình. Thật vậy, tiêu chí chính trong quy trình lựa chọn này phải luôn là thành công dự án của bạn và sự hài lòng của nhóm với quy trình làm việc.