Hướng dẫn về Scrum - Trong hướng dẫn này, chúng tôi sẽ cung cấp cho bạn các hướng dẫn chi tiết cách vận hành một dự án Scrum, lập kế hoạch cho Sprint, các cuộc họp quan trọng của Scrum và hơn thế nữa, tất cả trong Jira Software.
SCRUM LÀ GÌ? Scrum là một quy trình phát triển phần mềm lặp đi lặp lại. Trong hướng dẫn này, bạn sẽ lấy công việc được ưu tiên từ backlog đưa vào sprint, và một bảng với một quy trình làm việc đơn giản.
Bước 1: Tạo một dự án scrum
Khi bạn bắt đầu đăng nhập với một tài khoản của Jira Software (điều kiện tiên quyết), bạn sẽ có tùy chọn để tạo một dự án. Khi bạn được nhắc để chọn kiểu dự án, phải đảm bảo rằng bạn chọn Scrum development software.
Một bảng Scrum được tự động tạo ra với một dự án phát triển phần mềm Scrum. Một khi bạn đã tạo ra dự án của bạn, bạn sẽ được đưa đến trang backlog trống của bảng Scrum. Bây giờ là lúc bạn để bắt đầu đưa vào backlog các user story hoặc các tác vụ bạn phải có để hoàn thành dự án, tính năng hoặc sản phẩm của bạn.
Bước 2: Tạo các user story hoặc tác vụ trong backlog
Trong Jira Software, chúng tôi gọi user story, nhiệm vụ và lỗi là "issues". Nhanh chóng tạo ra một vài user story với tùy chọn tạo nhanh trên backlog. Nếu bạn không có dự án hoặc tính năng nào đó trong tâm trí, chỉ cần tạo các user story mẫu để bắt đầu và xem nó hoạt động như thế nào.
USER STORY LÀ GÌ?
Trong phương pháp agile, các user story là những đơn vị nhỏ nhất của công việc. Là một {loại người dùng}, tôi muốn {mục tiêu} để tôi {nhận được lợi ích}.
Hãy sử dụng trang web làm ví dụ đơn giản để tạo một user story.
Là một khách hàng, tôi muốn tạo tài khoản để tôi có thể thấy những khoản mua hàng mà tôi đã thực hiện trong năm qua nhằm giúp tôi thanh toán cho năm tới.
Các user story được product owner phác thảo và sau đó toàn bộ nhóm sản phẩm cùng xác định các yêu cầu chi tiết. Đây là những phần công việc giúp xác định các mục cần triển khai cho story và sprint sắp tới.
Sau khi bạn đã tạo ra 6 hoặc nhiều hơn user story, bạn có thể bắt đầu sắp xếp mức độ ưu tiên của các story trong backlog. Trong Jira Software, bạn xếp hạng ưu tiên các story của mình bằng cách kéo và thả chúng vào backlog, theo thứ tự mức độ quan trọng phù hợp với nhóm của bạn.
Bước 3: Ước tính các story của bạn
Trước khi bắt đầu sprint đầu tiên, điều quan trọng là ước tính các story trong backlog để bạn có thể xác định khối lượng công việc sẽ mất bao lâu để hoàn thành.
Các nhóm phần mềm truyền thống đưa ra ước tính theo định dạng thời gian: ngày, tuần, tháng. Tuy nhiên, có nhiều nhóm agile đã chuyển sang các story points. Các story points đánh giá nỗ lực tương đối của công việc ở dạng Fibonacci như: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Có vẻ như không trực quan, nhưng thực sự hữu ích bởi vì nó thúc đẩy nhóm đưa ra những quyết định mạnh mẽ hơn khi gặp công việc khó khăn.
Ước tính cũng sẽ giúp bạn đánh giá số lượng công việc bạn nên thêm vào sprint tiếp theo dựa trên số lượng thành viên trong đội bạn. Sau một vài sprint, nhóm của bạn sẽ hiểu rõ hơn về việc họ có thể làm được bao nhiêu công việc cho mỗi sprint, điều này sẽ giúp tránh việc cam kết quá mức.
Trong Jira Software, bạn có thể ước tính các công việc bằng cách truy cập vào backlog và nhập một số vào trường Estimate cho mỗi issue.
Bước 4: Tạo một sprint
Tạo sprint đầu tiên của bạn trong backlog để bạn có thể bắt đầu tổ chức các công việc trong sprint.
SPRINT LÀ GÌ?
Trong Scrum, các đội dự kiến sẽ hoàn thành một tập hợp các user story trong khoảng thời gian cố định, được gọi là sprint. Nói chung, khoảng thời gian của sprint là một, hai hoặc bốn tuần. Điều này tùy thuộc vào nhóm để xác định độ dài của sprint - chúng tôi khuyên bạn nên bắt đầu với hai tuần. Đủ dài để có thể hoàn thành, nhưng không quá lâu tới mức không nhận được phản hồi thường xuyên. Một khi sprint được xác định, nhóm luôn hoạt động với nhịp độ đó. Cố định chiều dài của sprint tăng cường kỹ năng ước lượng và dự đoán được tốc độ làm việc trong tương lai cho nhóm khi họ làm việc thông qua backlog.
Bước 5: Tổ chức cuộc họp lập kế hoạch sprint
Trước khi bắt đầu sprint, bạn nên tổ chức cuộc họp lập kế hoạch sprint với mọi người trong đội của bạn. Trong cuộc họp này, bạn sẽ ước tính bất kỳ story nào chưa được ước tính nào từ backlog, nhận được cam kết từ nhóm về những gì họ có thể hoàn thành và cuối cùng là xây dựng sprint đầu tiên.
Bạn cũng nên xem xét toàn bộ thời gian sắp tới của nhóm, những ngày lễ, kế hoạch gặp trở ngại - cũng như các công việc khác có thể ảnh hưởng đến việc hoàn thành các nhiệm vụ trong sprint.
Ngoài ra, lưu ý rằng trong bước 3, nhóm của bạn nên ước tính các story trong các story points, theo thứ tự ưu tiên của chúng. Trong quá trình lập kế hoạch sprint, bạn chỉ cần ước tính những story chưa được ước tính - có lẽ do thiếu sự rõ ràng vào thời điểm ước tính story.
NHƯ THẾ NÀO LÀ CUỘC HỌP LẬP KẾ HOẠCH SPRINT?
Người tham dự: Yêu cầu: development team, scrum master, product owner.
Khi nào: Khi bắt đầu sprint.
Thời lượng: Thường là một giờ cho mỗi tuần- ví dụ: một sprint kéo dài hai tuần bắt đầu với một cuộc họp lập kế hoạch trong vòng 2 tiếng đồng hồ
Mục đích: Lập kế hoạch Sprint với sự tham gia của toàn bộ nhóm. Tham gia cuộc họp, product owner sẽ đưa ra các ưu tiên trong backlog. Họ thảo luận từng mục với nhóm phát triển, và nhóm cùng ước lượng các nỗ lực liên quan. Nhóm phát triển sau đó sẽ đưa ra một dự báo sprint cho thấy số lượng công việc mà nhóm có thể hoàn thành từ backlog. Kết quả là chúng ta có được sprint backlog.
Bước 6: Kéo và thả issues trong sprint
Backlog là nơi bạn có thể phân quyền ưu tiên cho các user story. Trong cuộc họp lên kế hoạch cho sprint, bạn có thể quyết định những công việc mà bạn muốn thực hiện trong sprint đầu tiên. Xác định bao nhiêu công việc nhóm của bạn sẵn sàng cam kết, và những gì bạn muốn đạt được trong sprint.
Khi bạn đã sẵn sàng, thả các story vào trong sprint mà bạn vừa tạo.
Bước 7: Bắt đầu sprint đầu tiên
Đặt tên cho sprint. Một số đội đặt tên sprint dựa trên mục tiêu của họ. Nếu có sự tương đồng giữa các công việc trong sprint, hãy đặt tên cho sprint xung quanh chủ đề đó. Nếu không, bạn có thể đặt cho sprint bất cứ tên gì bạn thích. Thêm ngày bắt đầu và ngày kết thúc cho sprint. Ngày bắt đầu và ngày kết thúc phải phù hợp với lịch biểu của nhóm bạn. Ví dụ, một vài đội bắt đầu sprint từ thứ hai và kết thúc vào sáng thứ 6 tuần sau. Đội khác thì quyết định bắt đầu và kết thúc vào giữa tuần. Tùy lựa chọn của bạn! Nếu bạn không chắc bao lâu cho một sprint, chúng tôi khuyến cáo là 2 tuần.
Khi bạn bắt đầu sprint, bạn sẽ được đến tab Active sprints trong dự án.
Đây là nơi nhóm của bạn sẽ chọn các công việc cần làm trong cột to-do, và di chuyển chúng đến cột in-progress và thậm chi là done!
Bước 8: Tiếp tục với các cuộc họp hằng ngày
Sau khi sprint được bắt đầu, đội cần các cuộc họp hằng ngày vào mỗi sáng để xem lại các công việc của thành viên ngày hôm qua. Mục đích của việc này là để xem liệu có ai trong nhóm của bạn đang gặp bất kỳ khó khăn nào đối với việc hoàn thành nhiệm vụ trong sprint.
HỌP STANDUP NHƯ THẾ NÀO?
Người tham dự: đội development, scrum master, product owner Tùy chọn: các đội có liên quan
Khi nào: vào sáng mỗi ngày
Thời lượng: Không quá 15 phút.
Mục đích: Các cuộc họp standup hằng ngày được thiết kế để thông báo cho tất cả mọi người một cách nhanh chóng về những gì đang thực hiện trong toàn đội. Yêu cầu mỗi thành viên của nhóm trả lời các câu hỏi sau:
- Những gì tôi đã hoàn thành ngày hôm qua?
- Tôi sẽ làm gì vào hôm nay?
- Tôi đang gặp khó khăn gì?
BIỂU ĐỒ BURNDOWN
Kiểm tra biểu đồ Burndown trong thời gian sprint thực sự là một ý tưởng tốt. Trong Jira Software, biểu đồ Burndown cho thấy số lượng công việc thực tế và số lượng ước tính sẽ được thực hiện trong một sprint. Để xem biểu đồ này, hãy nhấp vào Reports từ sidebar và sau đó chọn Biểu đồ Burndown từ trình đơn thả xuống.
Một biểu đồ Burndown cho thấy số lượng thực tế và ước tính của công việc phải được thực hiện trong một sprint. Trục ngang trong một Biểu đồ Burndown chỉ thời gian, trong khi trục dọc cho biết các công việc.
Sử dụng Biểu đồ Burndown để theo dõi tổng số công việc còn lại cho một sprint và để dự đoán khả năng đạt được mục tiêu sprint. Bằng cách theo dõi công việc còn lại trong suốt sprint, có thể biết sự tiến bộ của nhóm và đáp ứng phù hợp.
Các đội Scrum tổ chức phát triển các sprint theo thời gian. Ngay từ khi bắt đầu sprint, nhóm dự báo họ sẽ hoàn thành bao nhiêu công việc trong sprint. Biểu đồ Burndown sau đó theo dõi việc hoàn thành công việc trong suốt sprint. Trục x đại diện cho thời gian, và trục y đề cập đến số lượng công việc còn lại để hoàn thành, được đo bằng story point hoặc giờ. Các đội Scrum sau đó sử dụng Biểu đồ Burndown để theo dõi xem các thành viên trong nhóm có thể hoàn thành công việc dự kiến khi kết thúc sprint.
Một nhóm luôn tuân thủ dự báo của mình là một quảng cáo hấp dẫn cho sự nhanh nhẹn trong tổ chức của họ. Nhưng đừng để điều đó cám dỗ bạn bằng cách tuyên bố đã hoàn thành một mục trước khi điều đó xảy ra. Nó có vẻ tốt trong ngắn hạn, nhưng về lâu dài, điều này chỉ cản trở việc học tập và cải tiến. Trong trường hợp này, một đội sử dụng Biểu đồ Burndown có nhiều cơ hội hơn để thực hiện các hành động cần thiết để có thể theo kịp, và cuối cùng đạt mục tiêu sprint.
Sai lầm không nên mắc phải - nhóm hoàn thành sớm sprint vì họ không cam kết làm việc đủ. Nhóm không thể hoàn thành sprint vì họ cam kết làm việc quá nhiều.Không chia công việc ra thành từng phần nhỏ. Product owner thêm hoặc thay đổi yêu cầu khi đang chạy sprint.
Bước 9: Hoàn thành sprint
Vào cuối mỗi sprint, bạn phải hoàn thành nó.
Khi bạn đã hoàn thành sprint, bạn sẽ thấy được Sprint Report.
Sprint Report sẽ liệt kê các công việc đã hoàn thành, chưa hoàn thành và bất kỳ công việc nào được thêm vào sau khi sprint đã bắt đầu.
Câu hỏi: Đội có đáp ứng dự báo của sprint không? Có công việc nào được thêm vào hoặc gỡ bỏ giữa sprint? Có công việc nào chưa được hoàn thành trong sprint? Nếu có, tại sao?
Mục tiêu: Hiểu được cách dự đoán sprint và thực tế sẽ đạt được.
Bước 10: Các cuộc họp sprint retrospective
Sau khi bạn đã hoàn thành sprint, đội cần tổ chức họp retrospective.
Người tham dự: development team, scrum master, product owner.
Khi nào: vào cuối mỗi sprint.
Thời lượng: 60 phút.
Mục đích: Nhận được phản hồi nhanh chóng để làm cho sản phẩm và văn hóa phát triển tốt hơn. Retrospective giúp đội hiểu được những gì làm việc tốt và những gì không.
Retrospective không chỉ dành thời gian cho các khiếu nại mà không có hành động. Retrospective tìm hiểu những gì đang làm tốt để nhóm có thể tiếp tục tập trung vào các lĩnh vực đó. Ngoài ra, hãy tìm hiểu những gì không hiệu quả và sử dụng thời gian để tìm ra các giải pháp sáng tạo và phát triển một kế hoạch hành động. Cải tiến liên tục là những gì cần duy trì và thúc đẩy phát triển trong đội ngũ, và retrospective là một phần quan trọng của điều đó.
Câu hỏi: Chúng ta đã làm tốt những gì trong sprint? Chúng ta có thể làm gì tốt hơn? Chúng ta có thể làm gì tốt hơn cho lần kế tiếp?
Bước 11: Lặp lại bước 4
Tại thời điểm này, bạn đã có những kiến thức cơ bản về việc xây dựng backlog của bạn với các user story, tập hợp các story trong sprint, bắt đầu sprint và tổ chức các cuộc họp quan trọng. Bạn có thể quyết định có sử dụng nó cho nhóm của bạn hay không nếu bạn muốn tiến lên một số chủ đề nâng cao hơn.