Tôi là người học theo hướng thưởng thức, tôi sẽ nỗ lực trình diễn một cách dễ hiểu những thông minh độc đáo và tri thức và kỹ năng tôi học được qua thứ tự thưởng thức và khám phá về backlog .Scrum là một methodology hoặc framework để quản trị dự án Bất Động Sản Agile. Nó được sử dụng hơn 70 % những team tăng trưởng ứng dụng sử dụng .
Methodology: a system of ways of doing, teaching, or studying something — cambridge.org
Scrum sở hữu 2 loại backlogs: product backlog và sprint backlog.
Product backlog và Sprint backlog trong Scrum
Product backlog là những list thứ tự ưu tiên về những tính năng, tính năng được lấy người tậu làm TT. Nó được chia ra từ tầm nhìn tổng quán thành những phần sở hữu quản lý sự tăng trưởng của việc làm, nó được gọi là Product Backlog Items ( PBIs ). PBIs thường được bộc lộ bằng User story .
Còn, sprint backlog là danh sách những feature, task sẽ được thực hiện trong sprint bởi develop team. Tất nhiên, những feature và task này cũng sẽ sở hữu những thứ tự ưu tiên.
Sự khác nhau giữa product backlog và sprint backlog là gì ?
Product backlog được dựa trên những tính năng yêu cầu của khách hàng, người đưa ra, tổng hợp những feature naỳ đa phần tới từ Product Owner.Product backlog liên tục cập nhật và làm rõ ràng. Những feature sở hữu thể kéo(pull) từ Product backlog sang Sprint backlog và thường tuân thủ 1 số nguyên tắc do team Scrum đề ra như CUTFIT( Consistent — Unambiguous — Testable- Independent — Traceable),…Những sprint được tiếp nối nhau liên tục. Trong lúc team develop đang phát triển sprint này thì Product Owner, Scrum master phải chuẩn bị sprint backlog cho sprint tiếp theo. Và thường trước lúc kết thúc sprint hiện tại, team scrum team sẽ sở hữu buổi họp Product Backlog Grooming(Backlog Refinement Meeting) để chuẩn bị backlog sprint tiếp theo.Sprint backlog là những feature sẽ triển khai trong sprint còn product backlog sở hữu thể sẽ sở hữu feature sở hữu ưu tiếp thấp hoặc ko sở hữu trị giá sẽ bị loại bỏ.
Và, điểm giống nhau giữa chúng :
Cả product backlog và sprint backlog đều là hệ thống kéo (pull), ko phải hệ thống đẩy(push). Đây cũng là sai trái khá phổ biển thường gặp phải của những team ứng dụng scrum. Tôi xin tương đối dông dài giảng giải ý kiến trên. Tư tưởng Agile là linh hoạt- và theo tôi, linh hoạt là tốc độ thích ứng chứ ko phải véc tơ vận tốc tức thời. Điều đó sở hữu tức thị bạn phải làm ra sản phẩm sở hữu chất lượng chứ ko phải nỗ lực chạy thật nhanh. Bạn phải cải tiến liên tục và điều đó chỉ tới lúc bạn dành thời kì cho việc cải tiến liên tục, dành thời kì thử những mẫu mới, thử những điều mà team bạn tin rằng làm nó sẽ mang lại hiệu quả tốt hơn. Tôi ko thể đoan bạn thứ mẫu mới sẽ mang lại hiệu quả ngay, sở hữu thể bạn và team bạn cần một vài lần thử và sai để tới trạng thái thuần thục mang lại trị giá nhiều hơn. Do vây, bạn phải để Developer thấy đã Done feature, sở hữu thể chịu trách nhiệm cho feature đó, sau đó họ cần kéo feature mới để tiếp tục develop feature khác. Tuy nhiên, bạn ko push việc/ task, giúp team Scrum luôn sở hữu thời kì thực hiện những công việc cải tiến, thử nghiệm những mẫu mới. Ngoài ra, điểm cần chú ý là việc kéo(pull) những feature từ product backlog sang sprint backlog sẽ được thực hiện lúc feature đó đủ những tiêu chỉ như rõ ràng, ko mơ hồ, sở hữu ước tính, thứ tự ưu tiên cao,…Tư tưởng của Agile hướng tới con người, nhóm tự trị, tự tổ chức hoạt động, hạn chế phân cấp bậc sẽ cần nhiều tính chủ động và đóng góp cho mục tiêu chung nên dù product backlog hay sprint goal vẫn cần team scrum đóng góp.
Việc quản trị tốt product backlog và sprint backlog là điều rất quan yếu trong việc vận dụng Scrum, điều này dẫn tới thành công xuất sắc hay thất bại của những sprint và việc vận dụng scrum .