Những điều bạn nên và không nên làm khi áp dụng Agile at scale

Hầu hết mọi tổ chức trên thế giới đều đang đồng loạt chuyển mình: chuyển đổi số, chuyển đổi văn hóa và chuyển đổi Agile. Khách hàng (và những người không phải là khách hàng) đã đến với BiPlus để được tư vấn, đào tạo và định hướng các thay đổi này bởi họ cho rằng các cách thức truyền thống sẽ không còn cho thấy hiệu quả trong thời đại mới. Họ muốn những ví dụ thực tế về cách quản lý các tiến trình chuyển đổi. 

Đọc thêm: Hiểu Kanban trong 5 phút

Chúng ta đang làm việc trong một kỷ nguyên mới của doanh nghiệp thương mại, nơi các rào cản nhập cuộc ngày càng bé lại đồng nghĩa với sự cạnh tranh gần như vô hạn từ các doanh nghiệp truyền thống và phi truyền thống. Khách hàng đang trở nên khó tính hơn bao giờ hết và có sự cạnh tranh liên tục giữa các công ty để thuê nhân tài tốt nhất.

Bối cảnh này đòi hỏi sư chuyển dịch từ các mô hình cung cấp dịch vụ thông thường (waterfall) tới các hoạt động mang tính Agile hơn, chào đón sự thay đổi – về con người, thực tiễn và công cụ – và đổi mới. 

Nói một cách đơn giản, Agile at scale có nghĩa là chia nhỏ các dự án lớn thành nhiều phần nhỏ hơn, vì vậy bạn có thể đưa sản phẩm ra thị trường nhanh hơn, chạy thử nghiệm, lấy ý kiến ​​phản hồi của khách hàng và cuối cùng là phân phối sản phẩm đáp ứng đúng nhu cầu của thị trường thay vì phải chờ đợi và đưa ra một sản phẩm có rủi ro lớn.

Trong bài viết này, BiPlus sẽ chia sẻ những điều nên làm và không nên khi áp dụng Agile at scale và cách BiPlus có thể giúp các tổ chức phát triển Scale Agile theo cách riêng.

Vậy các doanh nghiệp đang mở rộng quy mô đã làm đúng và chưa đúng điều gì trong hành trình triển khai Agile của họ? Thực ra, có rất nhiều con đường dẫn đến thành công, nhưng chúng tôi có một số phương pháp hay nhất (và tệ nhất) thường áp dụng để chia sẻ.

3 điều nên làm khi áp dụng Agile at scale

1 – Agile at scale là một cuộc hành trình, không phải là một điểm đến.

Agile at scale không phải là một chứng chỉ để thi đỗ và để đó. Thực tế, Agile at scale không hề có vạch đích – mà chỉ có rất nhiều đột phá trên đường đi.

2 – Xác định xem bạn đang giải quyết vấn đề cho ai – lý tưởng nhất, đó sẽ là khách hàng.

Agile at scale là làm việc trong toàn tổ chức để làm hài lòng khách hàng của bạn (cho dù nội bộ hay bên ngoài), với đúng thứ vào đúng thời điểm, theo cách nhanh nhất có thể.

3 – Làm việc với các đội khác

Nếu tất cả những gì bạn làm là tối ưu hóa cách thức hoạt động của chỉ một mình team của bạn, thì bạn sẽ không thể thành công. Thực tế, bạn có thể phải thỏa hiệp và loại bỏ các “silos” để có lợi cho cả hệ thống và công ty. Hãy khuyến khích và tìm cách giúp các nhóm làm việc song song trong toàn tổ chức, cho mọi người nhìn cùng một mục tiêu chung, kết quả chung và cộng tác để hoàn thành công việc chung; tìm cách thử nghiệm và trải nghiệm cũng như thành công cùng nhau.

Tất cả những điểm này đều sôi sục để giải phóng các cách làm việc cũ. Hầu hết các tổ chức đều muốn bỏ tiền ra và triển khai “câu trả lời”, nhưng nếu họ không cho phép chính mình loại bỏ những thói quen và văn hóa cũ, họ sẽ không có thời gian hoặc tự do để thực hành những thói quen và thói quen mới. Toàn bộ cơ sở lý luận của agile at scale là chấp nhận sự không chắc chắn cố hữu và khai thác sự thay đổi để mang lại lợi ích cho khách hàng. Nếu bạn vốn có sự không chắc chắn về những gì bạn đang làm, cách bạn đang làm và bạn đang làm việc đó cho ai, thì Agile at scale cho phép bạn thử nghiệm và học hỏi nhanh hơn rất nhiều so với cách launching sản phẩm 1 lần theo kiểu truyền thống.

3 điều không nên khi áp dụng Agile at scale

1 – Chỉ một khóa đào tạo sẽ là không đủ.

Chúng ta đã nghe câu chuyện này quá thường xuyên: sếp gửi gửi 1.000 người đi học một khóa học Agile và sau đó chẳng có gì thay đổi. 

Hãy nhớ rằng con người và môi trường của tổ chức bạn cần phải hài hòa. Nếu bạn cử nhân viên tham gia một khóa đào tạo về cách trở nên Agile, nhưng không nuôi dưỡng một môi trường thúc đẩy tinh thần Agile, bạn thậm chí sẽ khiến nhân viên của mình mất hứng thú và khiến hành trình chuyển đổi Agile của doanh nghiệp trở nên khó khăn hơn.

2 – Nếu các leader nghĩ rằng Agile at scale là việc của người khác, thì họ đã sai.

Kết quả tốt nhất mà chúng tôi đã thấy là khi các leader trong tổ chức đi đầu và mô hình hóa tư duy Agile.

3 – Tránh áp dụng Agile at scale “ngay lập tức”

Đôi khi, khi các nhà lãnh đạo quyết định rằng Agile là câu trả lời, họ tạo ra một danh sách kiểm tra để “làm cho mọi người làm việc theo Agile” – họp đứng vào buổi sáng, thực hiện sprint – và mặc dù bề ngoài những hoạt động này có vẻ agile, nhưng chúng chẳng có ý nghĩa gì nếu nhân viên không thực sự hiểu tinh thần, triết lý và mục đích của Agile. Đừng đo lường Agile dựa trên thói quen, mà hãy dựa trên kết quả. Ví dụ: các nhóm có đang cung cấp các sản phẩm gia tăng tiềm năng có thể chuyển giao được trong mỗi sprint không? NPS (chỉ số đo lường mức độ khách hàng) có tăng lên như mong đợi sau khi bàn giao tính năng mới không? Vân vân…

Bạn sẽ gặp khó khăn nếu bạn nóng vội và muốn triển khai Agile at scale thành công trong thời gian ngắn. Một thất bại không có nghĩa là bạn nên dừng lại; nó có nghĩa là bạn nên tiếp tục. Cho mọi người thời gian và sự tự do để biến Agile at scale thành một lợi thế thực sự cho tổ chức và bạn sẽ thành công.

Giá trị nào mà BiPlus mang lại cho quá trình Chuyển đổi Agile của bạn?

Nói một cách đơn giản, chúng tôi đang thực hiện Agile at scale. Chúng tôi đang làm việc theo framework này mỗi ngày và chúng tôi rất vui được chia sẻ kinh nghiệm của mình về những hoạt động hiệu quả và những gì không hiệu quả. Chúng tôi cũng đang lắng nghe nhiều tổ chức trải qua trải nghiệm này ngay bây giờ và chia sẻ những gì đang hoạt động.

Tại BiPlus, chúng tôi không chỉ nghĩ về các công cụ của mình mà còn là cơ chế hoạt động hiệu quả cùng nhau. Chúng tôi cung cấp cho bạn phần mềm tốt nhất trong lớp để cho phép bạn suy nghĩ và triển khai Agile at scale, nhưng các công cụ sẽ chỉ đưa bạn đi xa. Chúng tôi cũng ở đây để truyền đạt những cách làm việc giữa con người với con người nhằm khuếch đại sức mạnh của những công cụ đó.

Và chúng tôi biết đó là một thách thức – nhưng hãy tin rằng nó xứng đáng. Mặc dù Agile at scale có thể cảm thấy như một thứ khá đáng sợ để nắm lấy, nhưng nó cực kỳ có giá trị khi bạn bắt đầu cuộc hành trình đó.

Product Backlog là gì? 4 đặc điểm của một backlog tốt

Product Backlog là gì?

Product Backlog là danh sách công việc đi từ Epic (những mảng việc lớn, có thể phải dành vài tháng để hoàn thiện) đến Features (các tính năng, các phần nhỏ hơn của mảng việc lớn, có thể làm theo vài tuần) đến User Stories (chi tiết hạng mục phát triển được quy về thời lượng vài ngày).

Không chỉ đội phát triển phần mềm mới sử dụng được Product backlog, tất cả các team đều sử dụng được Product Backlog như là một kho lưu trữ các hạng mục công việc. 

Đọc thêm: Jira là gì? Tất tần tật về Jira Software

Nếu như Product Backlog của team phát triển sản phẩm là danh sách các tính năng, thì Product Backlog của team Marketing là danh sách các sản phẩm hướng tới mục tiêu tạo lead như 1 tài liệu website, video, landing page giới thiệu sản phẩm.

product backlog

Tại sao cần Product backlog?

Product backlog là một danh sách có thứ tự các nhiệm vụ, tính năng hoặc các hạng mục cần hoàn thành trong một roadmap lớn.

Việc tạo ra sản phẩm bắt đầu từ một ý tưởng và cần một nhóm chuyên dụng để tạo ra một thứ gì đó đặc biệt. Đúng vậy, ngay cả iPhone cũng đã từng chỉ là một mẫu thử nghiệm đã trở nên phổ biến rộng rãi nhờ vào đội ngũ phù hợp. Khi quản lý một nhóm các nhà phát triển Scrum, việc duy trì tổ chức là yếu tố quan trọng để sản phẩm thành công.

Vậy làm thế nào để các nhóm phát triển luôn có tổ chức và đạt được mục tiêu của họ? Đó chính là to-do list phù hợp và đã được kiểm chứng. Một product backlog về cơ bản là một danh sách việc cần làm chuyên biệt. Nếu nhóm của bạn sử dụng phương pháp Agile, product backlog có thể giúp bạn chia nhỏ các dự án và xác định nhiệm vụ nào là quan trọng nhất.

Đôi khi, có nhiều product backlog với nhiều nhóm làm việc trên một sản phẩm lớn hơn. Ví dụ Adobe Creative Cloud. Creative Cloud là một “thương hiệu hình ô” (umbrella product), với các sản phẩm nhỏ hơn như Photoshop, Illustrator và After Effects bên trong nó. Mỗi sản phẩm nhỏ hơn này sẽ có product backlog riêng và các nhóm được chỉ định để phát triển.

Một product backlog bắt nguồn từ product roadmap, trong đó giải thích kế hoạch hành động để sản phẩm sẽ phát triển như thế nào. Các nhà phát triển sử dụng các nhiệm vụ trong product backlog để đạt được kết quả mong muốn nhanh nhất có thể.

Các nhóm Agile dành thời gian cho việc tạo ra sản phẩm và thực hiện các điều chỉnh khi dự án tiến triển. Do phương pháp Agile, các nhiệm vụ về product backlog không được thiết lập sẵn và không phải tất cả các mục trong product backlog đều sẽ được hoàn thành. Nhóm phát triển đều nên tinh chỉnh các product backlog khi họ ưu tiên các nhiệm vụ cần thiết.

Ai sở hữu Product Backlog?

Product Owner là người chịu trách nhiệm quản lý và bảo trì Product Backlog. Cụ thể họ sẽ:

  • Xác định các tính năng, hạng mục cần được phát triển.
  • Đánh giá độ ưu tiên của các hạng mục và sắp xếp chúng theo thứ tự ưu tiên từ cao đến thấp.
  • Làm mịn các hạng mục.
  • Làm rõ và đảm bảo các hạng mục này minh bạch tới tất cả các bên.

Có gì trong một product backlog?

Một product backlog thường bao gồm các tính năng (feature), bug fix, technical debt và Knowledge acquisition (thu thập kiến thức). Các hạng mục product backlog này là những phần công việc riêng biệt chưa được giao cho một sản phẩm.

Tính năng (user story)

Feature, còn được gọi là user story, là một chức năng của sản phẩm mà người dùng sản phẩm thấy có giá trị. Các tính năng có thể phức tạp – thường được gọi là epic – hoặc chúng có thể đơn giản. Tạo story map có thể giúp nhóm của bạn xác định những gì người dùng cần nhất.

Bug fix

Nhóm Scrum nên nhanh chóng giải quyết những bug này để duy trì tính toàn vẹn của sản phẩm. Một số bug có thể đủ quan trọng để làm gián đoạn sprint hiện tại của nhóm, trong khi những bug khác có thể đợi sprint tiếp theo để fix. Tuy nhiên, một quy tắc tổng thể đối với bug là giữ chúng ở đầu product backlog (ưu tiên) để nhóm của bạn không quên chúng.

Technical debt

Technical debt, giống như nợ tài chính sẽ “cộng dồn lãi suất” khi bị bỏ qua. Khi các nhà phát triển đẩy công việc kỹ thuật xuống đáy của product backlog, nó sẽ tích tụ và khó hoàn thành hơn. Nhóm của bạn có thể ngăn chặn tích tụ Technical debt bằng cách duy trì tổ chức và thực hiện công việc kỹ thuật với quy mô nhỏ hơn, hàng ngày.

Knowledge acquisition  

Knowledge acquisition  liên quan đến việc thu thập thông tin để hoàn thành các nhiệm vụ trong tương lai. Nếu nhóm của bạn có một tính năng mà họ không thể hoàn thành nếu không nghiên cứu thêm, thì bạn sẽ tạo một nhiệm vụ thu thập kiến ​​thức chẳng hạn như prototype, thử nghiệm hoặc POC (proof of concept) để có được thông tin cần thiết cho tính năng đó.

Các tồn đọng sản phẩm tốt có những đặc điểm tương tự, mà Mike Cohn và Roman Pichler đã nắm bắt được với từ viết tắt DEEP: Chi tiết phù hợp, Nổi bật, Ước tính, Ưu tiên. Chúng ta hãy xem xét kỹ hơn từng đặc điểm này.

Các đặc điểm của một backlog tốt

Detailed appropriately – Đủ chi tiết hợp lý

Các product backlog sẽ khác nhau về mức độ chi tiết của chúng. Những công việc mà chúng ta sẽ giải quyết sớm hơn, những công việc ở phần đầu của product backlog, sẽ chi tiết hơn. Những thứ mà chúng ta sẽ không giải quyết trong một thời gian sẽ ít chi tiết hơn. Chúng ta sẽ cần tinh chỉnh (thêm chi tiết vào) các mục tồn đọng khi chúng tăng mức độ ưu tiên, thêm chi tiết theo cách vừa đủ, đúng lúc.

Emergent – thay đổi liên tục

Như đã thảo luận trong các chương trước, product backlog là một tài liệu “sống”, liên tục thay đổi khi sản phẩm đang được phát triển hoặc bảo trì. Khi nhóm và Product owner tìm hiểu thêm về sản phẩm và thị trường, họ có thể thêm các mặt hàng mới, loại bỏ một số và thay đổi các mặt hàng khác. Bản chất nổi bật của product backlog không chỉ được mong đợi mà còn là dấu hiệu của việc tồn đọng sản phẩm đang hoạt động và lành mạnh.

Estimated – Ước lượng

Vào thời điểm thích hợp, mỗi product backlog cần có một ước tính kích thước tương ứng với nỗ lực cần thiết để phát triển mặt hàng đó. Chủ sở hữu sản phẩm sử dụng những ước tính này để giúp xác định mức độ ưu tiên của các item trong product backlog. Lý tưởng nhất là hầu hết các mục ở đầu product backlog sẽ có kích thước vừa với sprint, đủ nhỏ để có thể xử lý trong một lần sprint. Các mục lớn, có mức độ ưu tiên cao nên được chia thành các story nhỏ hơn trước khi start sprint.

Prioritized – Ưu tiên

Một product backlog phải là danh sách các PBI được ưu tiên, nhưng không phải mọi PBI đều cần được ưu tiên. Tôi khuyên bạn nên ưu tiên về giá trị phát hành của PBI. Ưu tiên vượt quá mức đó có thể là một sự lãng phí công sức, vì quá nhiều thứ có thể thay đổi vào thời điểm bản phát hành đầu tiên được phát hành. Thay vào đó, hãy ưu tiên các mặt hàng mới khi chúng xuất hiện và để dành các item chưa giải quyết được lùi lại sau.

Cách tạo product backlog

Một product backlog không chỉ là một danh sách việc cần làm đơn giản. Bạn có thể chia các nhiệm vụ phức tạp thành một loạt các bước và phân chia (assign) chúng cho các thành viên trong nhóm tương ứng. Dưới đây là các bước để phát triển một product backlog hiệu quả.

Product Roadmap

Product Roadmap là nền tảng cho việc product backlog. Nhóm của bạn nên tạo một roadmap trước khi tạo product backlog bởi vì roadmap là một kế hoạch hành động cho việc sản phẩm của bạn sẽ thay đổi như thế nào khi nó phát triển. Roadmap là tầm nhìn để phát triển sản phẩm dài hạn, nhưng nó cũng có thể phát triển.

Liệt kê các item trong product backlog 

Lưu ý đến product roadmap của bạn, nhóm của bạn có thể bắt đầu liệt kê các item trong backlog của sản phẩm. Những mục này có thể bao gồm những mục có mức độ ưu tiên cao và những ý tưởng trừu tượng hơn. Trong giai đoạn tạo product backlog này, bạn cũng cần giao tiếp với các bên liên quan và lắng nghe ý kiến ​​của họ để cải tiến sản phẩm. Bạn có thể tham khảo các mẫu product backlog ở Jira để bắt đầu dễ dàng hơn.

Thứ tự Ưu tiên 

Sau khi nhóm của bạn liệt kê tất cả các item trong product backlog đã đến lúc bạn phải sắp xếp chúng và ưu tiên những nhiệm vụ nào là quan trọng nhất. Bạn có thể xác định các item hàng đầu bằng cách đặt mình vào vị trí khách hàng và cân nhắc xem mặt hàng nào mang lại giá trị nhất cho họ.

Cập nhật thường xuyên

Khi nhóm của bạn làm việc thông qua product backlog, hãy nhớ rằng product backlog luôn luôn thay đổi. Bạn có thể liên tục thêm các mục vào product backlog và ưu tiên hoặc tinh chỉnh các mục khi bạn làm việc với chúng.

Cách ưu tiên các item trong Product backlog

Một thành phần thiết yếu của việc quản lý product backlog là ưu tiên các nhiệm vụ. Với tư cách là chuyên gia Scrum, bạn nên hiểu kỹ về những tính năng mới mà các bên liên quan muốn thấy trong sản phẩm. Dưới đây là một số chiến lược về cách ưu tiên các mục trong backlog.

Sắp xếp các công việc theo mức độ khẩn cấp và quan trọng

Khi tập trung vào việc sàng lọc product backlog, hãy thử sắp xếp các nhiệm vụ theo mức độ khẩn cấp và tầm quan trọng. Nhóm nên ưu tiên các item giúp cải thiện chức năng của sản phẩm cũng như trải nghiệm người dùng.

Giải quyết các nhiệm vụ phức tạp trước

Một số team có xu hướng hoàn thành các nhiệm vụ đơn giản trước để có thể kéo done và rút ngắn backlog, nhưng đây là hình thức quản lý dự án kém hiệu quả hơn. Việc product backlog sẽ tiếp tục phát triển, vì vậy việc giải quyết các nhiệm vụ phức tạp trước tiên có thể đem lại hiệu quả bất ngờ khi phát triển sản phẩm.

Hoàn thành nhiệm vụ trong khoảng thời gian tập trung

Các Agile team làm việc tập trung vào các sprint để hoàn thành công việc và phương pháp này mang lại hiệu quả cao về năng suất. Vào cuối mỗi sprint, Product Owner và bất kỳ bên liên quan nào có thể tham dự buổi sprint review và buổi sprint retrospective với nhóm phát triển để đảm bảo mọi thứ đều đi đúng hướng.

Giao tiếp với nhóm 

Giao tiếp giữa các thành viên trong nhóm là một phần quan trọng của việc ưu tiên product backlog. Để sắp xếp thành công product backlog và hoàn thành các hạng mục trong một khung thời gian hợp lý, bạn và nhóm của mình phải làm việc cùng nhau và tuân theo hướng dẫn Scrum.

Ví dụ về product backlog

Các product backlog của mỗi dự án sẽ khác nhau nhưng một số bắt đầu bằng một epic. Epic là một vấn đề bao trùm mà bạn đang cố gắng giải quyết cho khách hàng. Dưới đây là một ví dụ bên dưới:

Epic: Một giám đốc tiếp thị muốn có một hệ thống quản lý nội dung cho phép cung cấp nội dung chất lượng cho độc giả.

Epic này có thể dẫn đến nhiều tính năng sản phẩm khác nhau, từ cách người dùng tạo nội dung trong hệ thống mới đến cách họ chỉnh sửa và chia sẻ nội dung với các nhóm. Để tiếp tục ví dụ về việc product backlog, chúng ta có thể chia Epic thành các user story cụ thể hơn.

User story 1: Content creator muốn có một hệ thống quản lý nội dung cho phép họ tạo nội dung để có thể thông báo cho khách hàng về sản phẩm.

User story 2: Editor muốn có một hệ thống quản lý nội dung cho phép họ đánh giá nội dung trước khi xuất bản để họ có thể đảm bảo nội dung đó được viết tốt và được tối ưu hóa cho tìm kiếm.

Product Owner, Scrum master và nhóm phát triển sẽ xác định các tính năng mà sản phẩm nên bao gồm từ các user story và ưu tiên chúng dựa trên mức độ quan trọng.

Các tính năng mà sản phẩm nên bao gồm cho User story 1:

  • Đăng nhập vào hệ thống quản lý nội dung
  • Tạo nội dung
  • Chỉnh sửa một trang nội dung
  • Lưu thay đổi
  • Gửi nội dung cho editor để review
    Với tư cách là product manager, bạn sẽ sử dụng Epic để hướng dẫn product roadmap và các mục trong backlog. Như bạn có thể thấy với ví dụ này, một Epic có thể dẫn đến nhiều user story và tính năng sản phẩm.

Product backlog có thể giúp gì cho nhóm của bạn?

Việc product backlog giúp nhóm của bạn hoạt động trơn tru hơn nhiều bằng cách cải thiện khả năng tổ chức và cộng tác. Nó trở thành công cụ trung tâm để giao tiếp và giúp mọi người phù hợp với mục tiêu và kỳ vọng.

Do tất cả các công việc cho một sản phẩm đều qua backlog, product backlog sẽ cung cấp cơ sở cho việc lập kế hoạch lặp lại. Vì nhóm của bạn sắp xếp thứ tự ưu tiên các nhiệm vụ với sự hướng dẫn từ Product Owner, họ cũng sẽ xác định mức độ công việc mà họ có thể cam kết trong một khoảng thời gian cụ thể. Các khoảng thời gian này được gọi là vòng lặp (iterations) hoặc sprints.

Product backlog cũng thúc đẩy phát triển nhóm Agile bằng cách khuyến khích một môi trường làm việc linh hoạt nhưng hiệu quả. Các nhiệm vụ đối với product backlog không được thiết lập sẵn và nhóm sắp xếp chúng theo thứ tự quan trọng trước khi chọn nhiệm vụ nào cần giải quyết trước.

So sánh Sprint backlog vs Product backlog

Các sprint backlog và product backlog rất giống nhau về thành phần của chúng. Các sprint backlog là một tập hợp con của các product backlog, nhưng chúng được sử dụng đặc biệt trong các sprint.

Product Owner có quyền kiểm soát việc product backlog vì nó có toàn bộ sản phẩm từ đầu đến cuối. Nhóm phát triển sở hữu mỗi sprint backlog bởi vì những danh sách việc cần làm nhỏ hơn này được lấy từ product backlog có nghĩa là phải hoàn thành trong một khoảng thời gian được chỉ định.

Sprint backlog phụ thuộc vào product backlog, và nó kết thúc khi sprint kết thúc. Một sprint backlog cũng sẽ có mục tiêu sprint của riêng nó được phát triển trong phiên planning của sprint trong khi Product backlog tập trung vào toàn bộ mục tiêu của sản phẩm và các nhiệm vụ được ưu tiên dựa trên mục tiêu đó.

Công việc product backlog linh hoạt hơn công việc sprint backlog và rất đa tùy theo nhu cầu của khách hàng. Các product backlog sẽ luôn được cập nhật liên tục cho đến khi sản phẩm được hoàn thiện.

Nhìn lại ví dụ product backlog ở trên, chúng ta cũng có thể tạo một ví dụ sprint backlog. Khi phát triển một phụ kiện ô tô để giúp lái xe dễ dàng hơn, một nhiệm vụ của product backlog là tạo ra một prototype của phụ kiện đó. prototype này có thể trở thành sprint goal của một sprint vì nó có thể mất một tập hợp các nhiệm vụ để phát triển.

Các hạng mục sprint backlog cho prototype phụ kiện ô tô có thể bao gồm:

  • Tạo một bản phác thảo ý tưởng
  • Phát triển một nguyên mẫu ảo
  • Xây dựng một nguyên mẫu vật lý
  • Tìm nhà sản xuất để xây dựng nguyên mẫu
  • Các mục sprint backlog này cũng sẽ nằm trên product backlog, nhưng việc tách chúng thành sprint của riêng họ có thể giúp các lập trình viên thông qua quy trình Scrum khi họ hoàn thành các nhiệm vụ này và tạo prototype một cách nhanh chóng.

Những điều cần chú ý khi tạo product backlog


Chỉ dùng một trình theo dõi để quản lí

Bạn không nên sử dụng nhiều hệ thống để track bug, yêu cầu và các hạng mục công việc kỹ thuật. Nếu nó hoạt động cho nhóm phát triển, hãy giữ nó trong một backlog.

Xóa các issue không đụng tới


Một khi backlog phát triển vượt quá capacity trong dài hạn, bạn có thể close các issue mà nhóm sẽ không có thời gian để giải quyết. Gắn cờ các issue đó với một giải pháp cụ thể như “out of scope” trong trình theo dõi vấn đề của nhóm để sử dụng cho nghiên cứu sau này.

Product Owner quyết định mức độ ưu tiên

Product Owner quyết định mức độ ưu tiên của các hạng mục công việc trong backlog. Trong khi nhóm phát triển quyết định velocity thông qua backlog. Đây có thể là một mối quan hệ không mấy dễ dàng đối với các Product Owner mới, những người muốn “thúc đẩy” công việc cho nhóm.

Nếu các bạn có nhu cầu tư vấn đào tạo các công cụ Agile như Jira hãy liên hệ Biplus – Đối tác số 1 của Atlassian tại Việt Nam để được hỗ trợ tốt nhất.