Hướng dẫn ngắn gọn Lý thuyết Thực hành Scrum Phiên 2.0 Pete Deemer Gabrielle Benefield Craig Larman GoodAgile Evolve www.goodagile.com www.evolvebeyond.com www.craiglarman.com Bas Vodde Odd-e www.odd-e.com Biên dịch: Nguyễn Khắc Nhật | Biên tập: Nguyễn Việt Khoa | Hiệu đính: Dương Trọng Tấn HỌC VIỆN AGILE www.hocvienagile.com Nhắn gửi bạn đọc: Có nhiều tài liệu mô tả ngắn gọn Scrum trực tuyến, sách hướng tới việc cung cấp mức độ chi tiết kỹ thuật Scrum Nó không dự định trở thành bước cuối trình đào tạo Scrum; nhóm dự định áp dụng Scrum khuyến cáo nên tự trang bị cho kiến thức việc đọc kĩ Agile Project Management with Scrum (Quản lý Dự án Linh hoạt với Scrum) Ken Schwaber Succeeding with Agile (Thành công với Agile) Mike Cohn tận dụng ưu nhiều khóa đào tạo huấn luyện Scrum có; chi tiết đầy đủ có ScrumAlliance.org Chúng xin gửi lời cảm ơn tới Ken Schwaber, Tiến sĩ Jeff Sutherland Mike Cohn đóng góp quý giá Phiên Scrum Primer tìm tại: http://www.infoq.com/minibooks/Scrum_Primer Các dịch tìm tại: http://www.scrumprimer.org/ © 2012 Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde Phương pháp Phát triển Truyền thống Phương pháp phát triển truyền thống với nhóm đơn-chức-năng, vòng phản hồi chậm thưa, lập kế hoạch chi tiết theo lối ước đoán, luồng từ phân tích kiểm thử không thành công cho giới nhiều biến động ngày Phương pháp gây chậm trễ phản hồi, học tập thu lại lợi nhuận đầu tư (ROI) thiếu vắng phần mềm chạy tốt thực giai đoạn cuối chu trình Điều dẫn đến thiếu minh bạch, thiếu khả cải tiến, giảm linh hoạt tăng rủi ro hoạt động kinh doanh kỹ thuật Một giải pháp thay bao gồm nhóm liên-chức-năng sử dụng mô hình phát triển lặp tồn nhiều thập kỷ không sử dụng rộng rãi mô hình truyền thống Scrum kết hợp khái niệm phát triển-sản phẩm thừa nhận vào khung làm việc đơn giản, bao gồm: đội nhóm thực sự, nhóm liên chức năng, nhóm tự quản, chu trình phản hồi ngắn khép kín, giảm thiểu chi phí thay đổi Các khái niệm làm tăng tính linh hoạt (agility) phản hồi, cho phép thu lại lợi nhuận đầu tư sớm hơn, giảm thiểu rủi ro Tổng quan Scrum khung phát triển nhóm liên-chức phát triển sản phẩm dự án theo hình thức lặp tăng trưởng Scrum tổ chức trình phát triển thành chu trình làm việc gọi Sprint Mỗi chu trình không kéo dài bốn tuần (phổ biến hai tuần) diễn liên tiếp mà không bị gián đoạn Các Sprint đóng khung thời gian, tức chúng kết thúc vào ngày định cho dù công việc hoàn thành hết hay chưa không phép kéo dài thêm Thông thường Nhóm Scrum1 chọn độ dài Sprint sử dụng họ cải tiến sử dụng chu trình ngắn Bắt đầu Sprint, Nhóm liên-chức gọi Nhóm Phát triển2 (Development Team, bao gồm khoảng bảy người3) lựa chọn hạng mục (yêu cầu khách hàng) từ danh sách ưu tiên Nhóm Phát triển thống mục tiêu chung mà họ tin chuyển giao vào cuối Sprint, thứ phải thấy thực “hoàn thành” Trong suốt Sprint, hạng mục thêm vào; Scrum để dành thay đổi cho Sprint tiếp theo, Sprint ngắn cố gắng tập trung vào mục tiêu nhỏ, rõ ràng tương đối ổn định Hằng ngày Nhóm Phát triển họp với khoảng thời gian ngắn nhằm tra tiến độ điều chỉnh bước cần thiết Nhóm Scrum: nhóm liên chức gồm toàn Product Owner, Scrum Master Nhóm Phát triển Xem chi tiết phần “Các vai trò Scrum” tài liệu [Chú tích người dịch - ND] Tài liệu Scrum Primer gốc chọn dùng từ Team để Development Team Người dịch chọn cách dùng “Nhóm Phát triển” cho rõ nghĩa, thống với cách dùng thuật ngữ tác giả Scrum Scrum Guide [ND] Về độ lớn Nhóm Scrum, tài liệu khác sử dụng số khác nhau, ví dụ ScrumGuide hai tác giả Scrum lưu ý số thành viên đội phát triển nên nằm khoảng 3-9 Nhiều chuyên gia Scrum khác đồng tình với cách lựa chọn kích thước nhóm tài liệu này: 7, cộng trừ [ND] để hoàn thành công việc lại Vào cuối Sprint, Nhóm Phát triển rà soát Sprint với bên liên quan trình bày phần xây dựng Mọi người nhận phản hồi đưa vào Sprint Scrum nhấn mạnh vào sản phẩm chạy tốt cuối Sprint mà thực “hoàn thành”; trường hợp phần mềm, điều có nghĩa hệ thống tích hợp, thực kiểm thử đầy đủ, viết tài liệu cho người dùng cuối, có khả chuyển giao Các vai trò, tạo tác kiện tóm lược Hình Hình 1: Tổng quan Scrum Một nội dung chủ đạo Scrum “thanh tra thích nghi” Do trình phát triển chắn liên quan đến việc học tập, sáng tạo bất ngờ, Scrum nhấn mạnh vào việc sử dụng bước phát triển ngắn, tra sản phẩm đạt hiệu kỹ thuật tại, sau điều chỉnh mục tiêu sản phẩm kỹ thuật quy trình Và lặp lại Các Vai trò Scrum Trong Scrum, có ba vai trò: Product Owner, Nhóm Phát triển, ScrumMaster Tất hợp thành Nhóm Scrum Product Owner chịu trách nhiệm tối ưu hóa lợi nhuận đầu tư (ROI - Return On Investment) thông qua việc xác định tính sản phẩm, chuyển thành danh sách ưu tiên, định hạng mục nằm phía danh sách để đưa vào Sprint tiếp theo, liên tục tái-sắp xếp làm mịn danh sách Nếu sản phẩm thương mại, Product Owner chịu trách nhiệm lợi nhuận tổn thất sản phẩm Trong trường hợp ứng dụng nội bộ, Product Owner không chịu trách nhiệm ROI theo nghĩa sản phẩm thương mại (sẽ tạo thu nhập), mà chịu trách nhiệm tối ưu hóa ROI theo nghĩa lựa chọn hạng mục có giá trị cao cho Sprint Trong thực tế, “giá trị” khái niệm mập mờ việc đánh giá độ ưu tiên bị ảnh hưởng mong muốn làm hài lòng khách hàng chủ chốt, gắn với mục tiêu chiến lược, hạn chế rủi ro, cải tiến hay yếu tố khác Trong số trường hợp, Product Owner khách hàng; điều thường xảy sản phẩm nội Trong số trường hợp khác, khách hàng hàng triệu người với đa dạng nhu cầu, vai trò Product Owner tương tự vị trí Product Manager (Giám đốc Sản phẩm) Product Marketing Manager (Giám đốc Tiếp thị Sản phẩm) nhiều tổ chức phát triển sản phẩm Tuy nhiên, Product Owner thường khác với Giám đốc Sản phẩm truyền thống chỗ họ chủ động thường xuyên trao đổi với Nhóm, ưu tiên làm việc với tất bên liên quan rà soát kết Sprint thay ủy quyền định phát triển cho quản lý dự án Một lưu ý quan trọng Scrum có người phục vụ với tư cách Product Owner có thẩm quyền tối cao vai trò này, người chịu trách nhiệm giá trị công việc, không thiết phải làm việc Nhóm Phát triển (cách gọi khác: Đội Phát triển) xây dựng sản phẩm mà Product Owner yêu cầu, chẳng hạn ứng dụng trang web Nhóm Phát triển Scrum “liên-chức năng”, có nghĩa bao gồm tất chuyên môn cần thiết để tạo sản phẩm chuyển giao sau Sprint Nhóm Phát triển “tự-tổ chức” (tự-quản lý) với mức độ tự chủ tính trách nhiệm cao Nhóm Phát triển định số lượng hạng mục (từ tập hợp Product Owner đưa ra) để xây dựng Sprint cách tốt để đạt mục tiêu Mỗi thành viên Nhóm Phát triển đơn giản gọi thành viên nhóm Chú ý chức danh chuyên môn cố định nhóm triển khai Scrum; chuyên gia phân tích nghiệp vụ, chuyên gia DBA, chuyên gia kiến trúc, trưởng nhóm, chuyên gia thiết kế tương tác/UX, lập trình viên Họ làm việc Sprint cách phù hợp để đạt mục tiêu mà họ đưa Do có thành viên nhóm, Nhóm Phát triển không liên-chức mà thể việc học tập lẫn nhau: người sở hữu mạnh riêng, tiếp tục học chuyên môn khác Mỗi người có kỹ chính, kỹ phụ thứ hai chí thứ ba Điều có nghĩa họ “đi đến đâu có công việc”; cá nhân nhận lấy nhiệm vụ không quen thuộc để giúp hoàn thành hạng mục yêu cầu Ví dụ, người với kỹ thiết kế tương tác có kỹ phụ kiểm thử tự động; người với kỹ viết tài liệu kỹ thuật trợ giúp với phân tích lập trình Nhóm Phát triển Scrum có (cộng trừ 2) người, sản phẩm phần mềm Nhóm Phát triển bao gồm cá nhân với kỹ phân tích, phát triển, kiểm thử, thiết kế giao diện, thiết kế sở liệu, thiết kế kiến trúc, viết tài liệu, kỹ khác Nhóm phát triển sản phẩm đồng thời cung cấp ý tưởng cho Product Owner cách để tạo sản phẩm tốt Trong Scrum, Nhóm Phát triển trở nên suất hiệu thành viên dành toàn 100% để làm việc cho sản phẩm suốt Sprint; Nhóm Phát triển tránh làm việc đa nhiệm nhiều sản phẩm dự án để loại bỏ thất thoát tốn phân tâm chuyển đổi bối cảnh Các nhóm ổn định thường có với suất cao hơn, nên tránh thay đổi thành viên Nhóm Phát triển Các nhóm phát triển sản phẩm với nhiều người tổ chức thành nhiều Nhóm Phát triển, nhóm tập trung vào số tính sản phẩm, với phối hợp nỗ lực chặt chẽ nhóm Do nhóm thường làm tất việc (lập kế hoạch, phân tích, lập trình, kiểm thử) cho tính hoàn chỉnh với khách hàng trọng tâm (customercentric) nên Nhóm Phát triển gọi Nhóm tính (feature team) ScrumMaster giúp nhóm học áp dụng Scrum để đạt giá trị thương mại ScrumMaster làm tất thẩm quyền để giúp Nhóm Phát triển, Product Owner tổ chức trở nên thành công ScrumMaster người quản lý thành viên Nhóm Phát triển, quản lý dự án, trưởng nhóm, hay đại diện nhóm Thay vào đó, ScrumMaster phục vụ Nhóm Phát triển; người giúp loại bỏ trở ngại, bảo vệ Nhóm Phát triển khỏi tác động từ bên ngoài, trợ giúp Nhóm Phát triển ứng dụng kỹ thuật phát triển đại ScrumMaster dạy, huấn luyện hướng dẫn Product Owner, Nhóm Phát triển phần lại tổ chức việc áp dụng thành thạo Scrum ScrumMaster huấn luận viên giáo viên ScrumMaster đảm bảo tất người (bao gồm Product Owner người ban quản trị) hiểu nguyên lý kỹ thuật Scrum, họ hỗ trợ dẫn dắt tổ chức vượt qua thay đổi thường khó khăn cần thiết để đạt thành công với phát triển linh hoạt Do Scrum giúp phát nhiều trở ngại nguy ảnh hưởng đến hiệu Nhóm Phát triển Product Owner, điều quan trọng phải có ScrumMaster làm việc hăng hái để giúp giải vấn đè đó, không Nhóm Phát triển Product Owner khó mà thành công Cần phải có ScrumMaster làm việc toàn thời gian, Nhóm Phát triển nhỏ cử thành viên đảm nhận vai trò (khi đảm nhiệm công việc thường ngày hơn) Một ScrumMaster giỏi xuất thân từ tảng chuyên môn nào: Kỹ thuật, Thiết kế, Kiểm thử, Giám đốc Sản phẩm, Quản lý Dự án, Quản lý Chất lượng ScrumMaster Product Owner người trọng tâm công việc họ khác việc kết hợp chúng lại thường dẫn đến nhầm lẫn xung đột Một kết không may mắn thường xảy kết hợp hai vai trò Product Owner có phong cách quản lý vặt (micro-managing), trái ngược với nhóm tự-quản lý mà Scrum yêu cầu Không giống với quản lý truyền thống, ScrumMaster không cho người phải làm gì, gán công việc, mà tạo điều kiện cho quy trình, hỗ trợ Nhóm Phát triển để họ tự tổ chức tự quản lý Nếu trước ScrumMaster làm vị trí quản lý Nhóm Phát triển cần phải thay đổi đáng kể tư phong cách tương tác để Nhóm Phát triển thành công với Scrum Lưu ý: không tồn vai trò quản lý dự án Scrum Bởi không cần thiết; nhiệm vụ truyền thống quản lý dự án phân chia cho ba vai trò khác Scrum Phần lớn trách nhiệm chuyển cho Nhóm Phát triển Product Owner cho ScrumMaster Triển khai Scrum kèm với quản lý dự án biểu việc hiểu sai Scrum thường dẫn đến xung đột trách nhiệm, không rõ ràng quyền hạn, kết tối ưu Đôi quản lý dự án (hoặc cựu quản lý dự án) chuyển sang vai trò ScrumMaster, thành công việc phụ thuộc lớn vào cá nhân hiểu biết người khác hai vai trò này, nhiệm vụ ngày tư cần thiết để thành công Một cách tốt để hiểu thông suốt vai trò ScrumMaster bắt đầu phát triển kỹ cốt lõi để thành công tham gia khóa đào tạo ScrumMaster ScrumAlliance Ngoài ba vai trò kể trên, có bên liên quan khác đóng góp vào thành công sản phẩm, bao gồm nhà quản lý, khách hàng người dùng cuối Một vài người liên quan chẳng hạn người quản lý chức (ví dụ, người quản lý kỹ thuật) thấy vai trò họ giá trị thay đổi áp dụng Scrum Ví dụ:  họ hỗ trợ Nhóm Phát triển cách tôn trọng quy tắc tinh thần Scrum  họ giúp loại bỏ trở ngại mà Nhóm Phát triển Product Owner  họ sẵn sàng đóng góp chuyên môn kinh nghiệm Trong Scrum, cá nhân thay thời gian đóng vai trò “bảo mẫu” trước (gán công việc, ghi nhận báo cáo tiến độ, hình thức quản lý vặt khác) thời gian với vai trò “quân sư” “người phục vụ” Nhóm Phát triển (hướng dẫn, huấn luyện, trợ giúp loại bỏ trở ngại, trợ giúp giải vấn đề, cung cấp đóng góp mang tính sáng tạo, hướng dẫn phát triển kỹ thành viên Nhóm Phát triển) Trong việc dịch chuyển này, nhà quản lý cần phải thay đổi phong cách quản trị; chẳng hạn, sử dụng cách hỏi Socratic để giúp Nhóm Phát triển tìm giải pháp vấn đề, thay đơn giản định giải pháp gán cho Nhóm Phát triển Product Backlog Khi nhóm dự định chuyển sang Scrum trước bắt đầu Sprint họ cần có Product Backlog Đây danh sách ưu tiên (được xếp 1, 2, 3, ) tính hướng-khách hàng (customer-centric) Product Backlog tồn (và tiến hóa) suốt vòng đời sản phẩm; lộ trình sản phẩm (Hình 3) Tại thời điểm nào, Product Backlog góc nhìn mang tính định “tất thứ Nhóm Phát triển hoàn thành theo thứ tự ưu tiên” Chỉ tồn Product Backlog cho sản phẩm; có nghĩa Product Owner cần phải đưa định đánh giá ưu tiên xuyên suốt toàn phạm vi, đại diện cho quyền lợi bên liên quan (bao gồm Nhóm Phát triển) Ước lượng công việc Sprint… Độ ưu tiên Hạng mục Chi tiết (Wiki URL) Là khách hàng, muốn đưa … sách vào giỏ hàng (xem phác thảo giao diện trang wiki) Kích thước Ước tính Ban đầu Là khách hàng, muốn xóa … sách khỏi giỏ hàng Cải thiện hiệu xử lý giao dịch (xem … thông số hiệu mong muốn wiki) 13 Nghiên cứu giải pháp để tăng tốc việc xác … nhận thẻ tín dụng (xem thông số hiệu mong muốn wiki) 20 Cập nhật tất máy dịch vụ lên Apache … 2.2.3 13 Chẩn đoán sửa lỗi đoạn mã xử lý hóa … đơn (bugzilla ID 14823) Là người mua hàng, muốn tạo lưu … lại danh sách yêu thích 40 Là người mua hàng, muốn thêm … xóa hạng mục danh sách yêu thích 20 Hình Product Backlog Hình Quản lý trực quan: Các hạng mục Product Backlog tường Product Backlog bao gồm nhiều hạng mục khác nhau, chủ yếu tính cho khách hàng (“cho phép tất người dùng thêm sách vào giỏ hàng”), có mục tiêu cải tiến kỹ thuật trọng yếu (ví dụ, “viết lại hệ thống từ C++ sang Java”), mục tiêu cải tiến (ví dụ, “tăng tốc độ kiểm thử”), công việc nghiên cứu (“nghiên cứu giải pháp để tăng tốc độ xác nhận thẻ tín dụng”), lỗi phát (“chẩn đoán sửa lỗi của đoạn mã xử lý hóa đơn”) có lỗi (Một hệ thống với nhiều lỗi thường có hệ thống theo dõi lỗi riêng biệt.) Các hạng mục Product Backlog mô tả theo cách miễn đảm bảo rõ ràng quán Trái ngược với hiểu nhầm phổ biến, Product Backlog không chứa “user story”; đơn giản chứa hạng mục Các hạng mục thể dạng user story, user case, hình thức ghi nhận yêu cầu mà nhóm thấy phù hợp Nhưng cho dù sử dụng hình thức lượng lớn hạng mục phải tập trung vào chuyển giao giá trị cho khách hàng Một Product Backlog tốt cần đạt tiêu chí DEEP… Detailed appropriately (Chi tiết hợp lý) Các hạng mục với độ ưu tiên cao cần làm mịn chi tiết so với hạng mục với độ ưu tiên thấp, chúng lựa chọn để thực trước Ví dụ, 10% Backlog bao gồm hạng mục nhỏ phân tích kỹ, 90% lại chi tiết Estimated (Được ước lượng) Các hạng mục dành cho phát hành cần phải ước lượng, cần phải xem xét tái-ước lượng Sprint mà người học có xuất thêm thông tin Nhóm Phát triển cung cấp cho Product Owner khối lượng công việc ước tính hạng mục Product Backlog, bao gồm ước tính rủi ro kỹ thuật Product Owner bên liên quan nghiệp vụ khác cung cấp thông tin giá trị yêu cầu sản phẩm, bao gồm lợi nhuận thu được, chi phí giảm thiểu, rủi ro kinh doanh, tầm quan trọng số bên liên quan, nhiều thứ khác Emergent (Tiến hóa) Đáp lại việc học tập biến đổi, Product Backlog thường xuyên làm mịn Trong Sprint, hạng mục thêm vào, xóa đi, thay đổi, chia nhỏ thay đổi độ ưu tiên Do vậy, Product Backlog liên tục cập nhật Product Owner để thể thay đổi nhu cầu khách hàng, ý tưởng hiểu biết mới, động thái đối thủ cạnh tranh, rào cản kỹ thuật vừa xuất hiện, v.v… Prioritized (Sắp xếp theo độ ưu tiên) Các hạng mục phía Product Backlog đánh độ ưu tiên xếp theo trật tự 1-N Nhìn chung, hạng mục có độ ưu tiên cao cần phải chuyển giao phần lớn lợi ích tương xứng với đồng tiền mà bạn bỏ (bang for your buck): nhiều lợi ích (giá trị thương mại) với tiền (chi phí) Một lí khác dẫn đến tăng độ ưu tiên hạng mục nhằm giải sớm rủi ro lớn trước chúng công bạn Phương pháp phát triển truyền thống thường không nhấn mạnh vào việc chuyển giao lợi ích cao tương xứng với đồng tiền bỏ ra, lại nội dung chủ đạo Scrum, Product Owner cần phải học cách để định giá phần lợi ích “giá trị thương mại” Đây thứ mà ScrumMaster giúp Product Owner học Vậy “giá trị thương mại” có nghĩa gì? Một số nhóm phát triển sản phẩm sử dụng đơn vị đơn giản ước tính điểm-giá trị tương đối cho hạng mục Product Backlog Đơn vị tổng hợp “phỏng đoán” nhiều yếu tố bao gồm mức tăng doanh thu, mức giảm chi phí, ý muốn bên liên quan, tạo khác biệt thị trường, v.v Một vài nhóm lại đầu tư cho hạng mục cụ thể nhiều khách hàng trả tiền cho việc phát triển sau sử dụng doanh thu xác (trong ngắn hạn) hạng mục đại diện giá trị Đối với số nhóm khác việc ước tính dựa giá trị hạng mục-cụ thể chi tiết không tập trung; họ sử dụng phương pháp rộng dựa-trên-kết-quả-kinh-doanh (“tăng lượng đăng ký thêm 10% ngày tháng 9”) giá trị chuyển giao nhiều hạng mục có-đóng-góp-cho-kết-quả chuyển giao Trong trường hợp này, Product Owner cần phải xác định phần tăng trưởng Sản phẩm Hữu dụng Tối thiểu (Minimum Viable Product) Để ước tính khối lượng công việc, kỹ thuật phổ biến ước tính theo kích thước tương đối (hệ số nỗ lực, độ phức tạp, tính bất định) sử dụng đơn vị “story point” đơn giản “point” Đây gợi ý; Scrum không quy định kỹ thuật để mô tả đánh độ ưu tiên hạng mục Product Backlog không quy định kỹ thuật hay đơn vị ước tính Một kỹ thuật sử dụng phổ biến trung Scrum theo dõi lượng công việc hoàn thành Sprint; ví dụ, trung bình hoàn thành 26 point Sprint Với thông tin này, giá trị trung bình giữ nguyên khác thay đổi, người ta trù liệu ngày phát hành mà tất tính hoàn thành, tính xem tính hoàn thành vào ngày xác định Giá trị trung bình gọi “tốc độ” (velocity) Tốc độ biểu diễn đơn vị với ước tính kích thước hạng mục Product Backlog Các hạng mục Product Backlog dao động đáng kể kích thước hay khối lượng công việc Các hạng mục lớn chia thành hạng mục nhỏ phiên Làm mịn Product Backlog (Product Backlog Refinement) buổi Lập kế hoạch Sprint (Sprint Planning Meeting) Các hạng mục nhỏ hợp lại với Các hạng mục Product Backlog dành cho vài Sprint cần phải làm mịn đủ nhỏ để Nhóm hiểu giúp dự báo đưa buổi Lập kế hoạch Sprint trở nên có nghĩa; kích thước nhỏ xem “có thể thực được” Những cải tiến kỹ thuật lớn mà tiêu tốn nhiều thời gian tiền bạc cần phải đưa vào Product Backlog chúng khoản đầu tư phát sinh kinh doanh mà cuối người Product Owner có-định-hướng-thương-mại phải bỏ Chú ý Scrum Nhóm Phát triển có quyền độc lập việc định số lượng hạng mục Product Backlog đưa vào Sprint, họ hoàn toàn tự việc chọn lấy hạng mục cải tiến kỹ thuật nhỏ chúng xem phần chi phí thông thường kinh doanh việc cần thiết để nhà phát triển làm tốt công việc Điều có nghĩa là, 10 thay đổi mà cần chờ đến bắt đầu Sprint Nếu yếu tố từ bên xuất dẫn đến thay đổi đáng kể độ ưu tiên, Nhóm lãng phí thời gian họ tiếp tục làm việc Product Owner Nhóm kết thúc Sprint Nhóm ngừng làm việc buổi Lập kế hoạch Sprint triển khai để bắt đầu Sprint Sự gián đoạn gây việc thường lớn, đủ để khiến Product Owner Nhóm Phát triển phải cân nhắc kỹ trước đến định gay cấn Có tác động mạnh mẽ tích cực xuất phát từ việc Nhóm Phát triển bảo vệ khỏi thay đổi mục tiêu suốt Sprint Thứ nhất, Nhóm bắt đầu làm việc biết chắn tuyệt đối mục tiêu họ không thay đổi, điều giúp Nhóm Phát triển tập trung vào việc hoàn thành nhiệm vụ Thứ hai, buộc Product Owner phải suy nghĩ thật kỹ hạng mục đánh giá ưu tiên Product Backlog chuyển cho Nhóm thực Sprint Khi tuân thủ quy tắc Scrum Product Owner hưởng lợi hai điểm Thứ nhất, tin tưởng Nhóm Phát triển cam kết làm việc để hoàn thành tập công việc thực tế rõ ràng mà họ chọn Theo thời gian, Nhóm Phát triển trở nên thành thạo việc lựa chọn chuyển giao dự báo thực tế Thứ hai, Product Owner thực thay đổi muốn với Product Backlog trước bắt đầu Sprint Ở thời điểm đó, bổ sung, loại bỏ, sửa đổi, tái-đánh-giá-ưu-tiên thực chấp nhận Trong Product Owner không phép thay đổi hạng mục triển khai Sprint phải chờ đợi khoảng thời gian Sprint để đưa vào thay đổi mà muốn Có nhiều dấu hiệu dẫn đến thay đổi - thay đổi hướng phát triển, thay đổi yêu cầu, hay đơn giản thay đổi suy nghĩ lí khiến Product Owner thường say mê Scrum khác Scrum Hằng ngày Tóm lược: Cập nhật phối hợp thành viên Nhóm Phát triển Thành phần tham dự: Nhóm Phát triển bắt buộc có mặt; Product Owner không bắt buộc ScrumMaster thường có mặt để đảm bảo Nhóm Phát triển tiến hành tốt kiện Thời gian: Tối đa 15 phút Một Sprint bắt đầu, Nhóm Phát triển thực kỹ thuật cốt lõi khác Scrum là: Scrum Hằng ngày Đây buổi trao đổi ngắn (15 phút hơn) diễn ngày vào thời gian ấn định sẵn Tất thành viên Nhóm Phát triển tham dự Để đảm bảo ngắn gọn, tất người nên đứng Đây hội để Nhóm đồng công việc thông báo cho biết trở ngại gặp phải Trong buổi Scrum Hằng ngày, thành viên trình bày với người ba thứ: (1) Mình làm kể từ buổi gặp mặt trước?; (2) Mình làm từ đến buổi gặp mặt tiếp theo?; (3) Mình gặp phải trở ngại gì? Lưu ý buổi Scrum Hằng ngày buổi báo cáo tiến độ cho người quản lý; mà lúc để thành viên Nhóm Phát triển tự-tổ chức chia sẻ với tình hình công việc, giúp họ phối hợp tốt Một thành viên ghi lại khó khăn, sau 16 ScrumMaster chịu trách nhiệm giúp thành viên Nhóm giải chúng Không nên có có nên hạn chế thảo luận chi tiết suốt buổi Scrum Hằng ngày Nội dung buổi trao đổi trình bày câu trả lời cho ba câu hỏi Nếu cần thiết phải thảo luận nên tổ chức sau kết thúc buổi Scrum Hằng ngày, chia thành nhiều nhóm thảo luận lúc, nhiên, Scrum bắt buộc tham gia họp Các thảo luận để vài thành viên toàn Nhóm thích nghi với thông tin nhận buổi Scrum Hằng ngày: nói cách khác, chu trình tra thích nghi Scrum Đối với Nhóm Phát triển sử dụng Scrum, không nên để người quản lý hay người vị trí có quyền lực tham dự buổi Scrum Hằng ngày Nó làm cho Nhóm Phát triển cảm thấy “bị giám sát” - tạo áp lực để báo cáo tiến độ tốt ngày (đây kỳ vọng không thực tế) ngại đưa vấn đề - gây nguy hại đến tính tự quản Nhóm Phát triển, dẫn đến tình trạng quản lý vặt (micro-management) Sẽ có ích bên liên quan đến gặp Nhóm Phát triển sau buổi trao đổi cung cấp giúp đỡ cần thiết để loại bỏ trở ngại làm chậm tiến độ Nhóm Phát triển Theo dõi tiến độ suốt Sprint Nhóm Scrum hoạt động theo chế tự quản, để đảm bảo thành công họ cần phải nắm tình hình công việc Hằng ngày, thành viên Nhóm Phát triển cập nhật ước tính khối lượng công việc lại để hoàn tất công việc làm Sprint Backlog (Hình 6) Ai cộng toàn lượng công việc lại cho nhóm vẽ lên Biểu đồ Sprint Burndown (Hình Hình 8) Biểu đồ thể số ước tính cập nhật ngày khối lượng công việc lại Nhóm hoàn tất toàn Trong trường hợp lý tưởng, đồ thị xuống theo quỹ đạo đạt tới “công việc lại 0” vào ngày cuối Sprint Chính điều nên gọi biểu đồ burndown Đôi nhìn ổn, thường không vậy; thực tế việc phát triển sản phẩm Điều quan trọng cho Nhóm biết tiến độ hướng đến mục tiêu chung, tổng số bỏ khứ (một thông số ý nghĩa xét mặt tiến độ) mà tổng số lại cần phải làm tương lai - khoảng cách mà Nhóm Phát triển cần phải vượt qua để đến đích Nếu đường đồ thị không xuống hướng đến điểm hoàn thành gần cuối Sprint Nhóm Phát triển cần phải điều chỉnh, chẳng hạn thu nhỏ phạm vi công việc tìm cách để làm việc hiệu giữ nhịp độ ổn định Mặc dù biểu đồ Sprint Burndown tạo hiển thị bảng tính điện tử, có nhiều Nhóm cảm thấy hiệu vẽ tờ giấy dán tường nơi làm việc cập nhật bút viết; giải pháp “công nghệ-thấp/tiếp xúc-cao” (low-tech/high-touch) nhanh, đơn giản thường trực quan so với biểu đồ máy tính 17 Ước tính Khối lượng công việc Còn lại vào cuối Ngày… Người thực Ước tính khối lượng công việc ban đầu Chỉnh sửa sở liệu Sanjay 0 Tạo trang web (UI) Jing 3 Tạo trang web (nghiệp vụ Javascript) Tracy & Sam 2 2 Viết kiểm thử chấp nhận tự động Sarah 5 5 Cập nhật trang trợ giúp khách hàng Sanjay & Jing 3 3 Hợp mã DCP hoàn thành kiểm thử mức tầng 5 5 5 Hoàn thành máy đặt hàng cho pRank 3 8 8 Thay đổi DCP đọc để sử dụng API http pRank 5 5 5 Hạng mục Product Backlog Là khách hàng, muốn thêm sách vào giỏ hàng Công việc Sprint … Cải thiện hiệu suất xử lý giao dịch Hình Cập nhật Hằng ngày lượng công việc lại Sprint Backlog 18 Hình Biểu đồ Sprint Burndown Hình Quản lý Trực quan: Biểu đồ Sprint Burndown vẽ tay 19 Làm mịn Product Backlog Tóm lược: Chia nhỏ hạng mục lớn, phân tích hạng mục, tái-ước lượng, tái-đánh giá độ ưu tiên hạng mục dành cho Sprint tới Thành phần tham dự: Nhóm Phát triển; Product Owner tham dự toàn hoạt động chuyên gia trợ giúp Nhóm việc làm mịn chi tiết, không cần tham dự lúc để định hướng giúp tái-đánh giá độ ưu tiên; người am hiểu yêu cầu trợ giúp Nhóm Phát triển; ScrumMaster tham dự phiên để huấn luyện cho nhóm cách làm việc hiệu quả, lại không cần thiết phải tham dự Thời gian: Thông thường không kéo dài 10% thời gian Nhóm Phát triển dành cho Sprint, cần nhiều hạng mục “khủng” Ví dụ, Sprint hai tuần dành ngày để làm mịn Một khuyến nghị giá trị biết đến Scrum nên dành phần thời gian Sprint cho việc làm mịn (hay “chải chuốt”) Product Backlog nhằm phục vụ cho Sprint tới Việc bao gồm phân tích chi tiết yêu cầu, phân tách hạng mục lớn thành hạng mục nhỏ hơn, ước tính hạng mục mới, ước tính lại hạng mục có Scrum không đề cập đến cách để thực việc này, kỹ thuật thường xuyên sử dụng tổ chức phiên làm việc tập trung giai đoạn cuối Sprint, giúp cho Nhóm Phát triển Product Owner bên liên quan khác tham dự mà không bị gián đoạn công việc Hoạt động làm mịn dành cho hạng mục lựa chọn cho Sprint tại; mà dành cho hạng mục dùng tương lai, thường hay hai Sprint Khi áp dụng kỹ thuật này, buổi Lập kế hoạch Sprint trở nên tương đối đơn giản Product Owner Nhóm Scrum bắt đầu lập kế hoạch với tập hạng mục rõ ràng, phân tích kỹ ước tính cẩn thận Một dấu hiệu cho thấy phiên làm mịn không thực (hoặc không thực tốt) buổi Lập kế hoạch Sprint có tương đối nhiều câu hỏi, khám phá, nhầm lẫn có cảm giác chưa đầy đủ; buổi lập kế hoạch công việc thường lấn sang thời gian Sprint, hệ không mong muốn Sơ kết Sprint Tóm lược: Thanh tra thích nghi liên quan đến phần tăng trưởng chức sản phẩm Thành phần tham dự: Nhóm Phát triển, Product Owner, ScrumMaster Các bên liên quan khác Product Owner mời phù hợp Thời gian: Đóng khung vòng tương ứng với tuần làm việc Sprint Sau Sprint kết thúc diễn buổi Sơ kết Sprint (Sprint Review), nơi mà người rà soát lại kết Sprint Những người có mặt kiện Product Owner, thành viên Nhóm, ScrumMaster, có thêm khách hàng, người dùng, bên liên quan, chuyên 20 gia, lãnh đạo, quan tâm Đối với Sprint hai tuần thời gian tối đa hai đồng hồ Bất có mặt tự đưa câu hỏi đóng góp ý kiến Buổi Sơ kết Sprint thường bị gọi sai buổi “demo”, không bao hàm ý nghĩa thực sự kiện Một ý tưởng chủ đạo Scrum tra thích nghi Nó nhằm xem xét học từ xảy cải tiến dựa phản hồi, chu trình lặp lặp lại Sơ kết Sprint hoạt động tra thích nghi cho sản phẩm Đây lúc mà Product Owner tìm hiểu để nắm tình hình sản phẩm Nhóm Phát triển (đúng vậy, buổi sơ kết Sprint); Nhóm họ tìm hiểu để nắm tình hình Product Owner thị trường Theo đó, thành tố quan trọng buổi Sơ kết Sprint trao đổi Nhóm Phát triển Product Owner để tìm hiểu tình hình, ghi nhận khuyến nghị, v.v Hoạt động Sơ kết Sprint chắn chắn phải bao gồm việc trực tiếp sử dụng phần mềm mà nhóm xây dựng suốt Sprint, tập trung nhiều vào phần mềm mà trao đổi dẫn đến cân Thời gian dành cho “trực tiếp sử dụng phần mềm” buổi Sơ kết Sprint “buổi trình diễn” Nhóm - thiết bị trình chiếu Nó có nghĩa buổi kiểm tra phần mềm thực tế chạy trực tiếp, ví dụ môi trường phát triển cách ly Có máy tính nhiều nơi diễn buổi Sơ kết Sprint để người trực tiếp kiểm tra sử dụng phần mềm Sẽ tốt có phiên để người dùng thực Product Owner chủ động tương tác với phần mềm, thay chờ xem phiên trình diễn từ Nhóm Cố gắng dành không 30 phút chuẩn bị cho buổi Sơ kết Sprint, không có nghĩa có điều không ổn Cải tiến Sprint Tóm lược: Thanh tra thích nghi liên quan đến quy trình môi trường Thành phần tham dự: Nhóm Phát triển, ScrumMaster, Product Owner (không bắt buộc) Các bên liên quan khác Nhóm Phát triển mời, không không phép tham dự Thời gian: Đóng khung 45 phút tương ứng với tuần làm việc Sprint Buổi Sơ kết Sprint để thực tra thích nghi liên quan đến sản phẩm Buổi Cải tiến Sprint diễn sau Sơ kết Sprint để thực tra thích nghi liên quan đến quy trình môi trường Đây hội để Nhóm Phát triển thảo luận thứ làm tốt thứ không làm tốt, từ thống thay đổi cần thực Đôi ScrumMaster đóng vai trò người hỗ trợ hiệu cho buổi Cải tiến, tốt tìm người khác từ bên để hỗ trợ hoạt động này; cách làm tốt hay đượng dùng ScrumMaster Nhóm Phát triển hỗ trợ buổi cải tiến cho nhóm khác, điều giúp tạo trao-đổi-chéo Nhóm Phát triển Có nhiều kỹ thuật để tiến hành buổi Cải tiến Sprint, sách Agile Retrospectives (do Derby Larsen viết năm 2006) có cung cấp danh sách hữu ích kỹ thuật 21 Nhiều nhóm cố giữ cho buổi cải tiến tập trung vào vấn đề, việc không tốt Nó dẫn đến việc người nghĩ buổi cải tiến kiện chán nản tiêu cực Thay vào đó, đảm bảo tất buổi Cải tiến có tập trung vào điểm mạnh tích cực; có vài sách khai thác điểm mạnh (Appreciative Inquiry) cung cấp mẹo chi tiết việc Nếu buổi cải tiến sử dụng kỹ thuật dẫn đến buồn chán, nên sử dụng vài kỹ thuật để thay đổi theo thời gian Bắt đầu Sprint Ngay sau buổi Sơ kết Sprint, Product Owner cập nhật Product Backlog với thông tin - thêm hạng mục mới, loại bỏ hạng mục không phù hợp, chỉnh sửa hạng mục có Product Owner chịu trách nhiệm đảm bảo thay đổi thể Product Backlog Xem Hình để tham khảo ví dụ việc cập nhật Product Backlog Ước lượng công việc Sprint… Độ ưu tiên Hạng mục Chi tiết (Wiki URL) Kích thướ c Ước tính Ban đầu 0 Là khách hàng, muốn đưa … sách vào giỏ hàng (xem phác thảo giao diện trang wiki) Là khách hàng, muốn xóa … sách khỏi giỏ hàng 0 Cải thiện hiệu xử lý giao dịch (xem … thông số hiệu mong muốn wiki) 13 13 0 Nghiên cứu giải pháp để tăng tốc việc xác … nhận thẻ tín dụng (xem thông số hiệu mong muốn wiki) 20 20 20 Cập nhật tất máy dịch vụ lên Apache … 2.2.3 13 13 13 13 Chẩn đoán sửa lỗi đoạn mã xử lý hóa … đơn (bugzilla ID 14823) 3 3 Là người mua hàng, muốn tạo lưu … lại danh sách yêu thích 40 40 40 40 22 Là người mua hàng, muốn thêm … xóa hạng mục danh sách yêu thích 20 20 … … … 537 580 20 20 570 500 Hình Cập nhật Product Backlog Không có thời gian nghỉ Sprint - Nhóm Phát triển thường chuyển từ buổi Cải tiến Sprint chiều hôm trước sang buổi Lập kế hoạch Sprint sáng hôm say (hoặc tuần) Một nguyên lý phát triển linh hoạt “nhịp độ ổn định”, để đảm bảo chu trình tiếp tục có cách Nhóm dành thời gian làm việc mức độ hợp lý Năng suất tăng theo thời gian việc cải tiến kỹ thuật làm việc Nhóm Phát triển, loại bỏ trở ngại ảnh hưởng đến suất, cách làm việc sức hay thỏa hiệp chất lượng Các Sprint tiếp tục Product Owner định sản phẩm sẵn sàng để phát hành Tầm nhìn hoàn hảo Scrum sản phẩm chuyển giao vào cuối Sprint, điều có nghĩa không cần làm công việc để tổng kết, chẳng hạn kiểm thử viết tài liệu Nó hàm ý tất thứ hoàn thiện toàn Sprint; thực tế bạn chuyển giao triển khai sản phẩm sau buổi Sơ kết Sprint Tuy nhiên, nhiều tổ chức sở hữu kỹ thuật phát triển, công cụ sở hạ tầng kém, dẫn đến việc không đạt tầm nhìn hoàn hảo cần đến “Sprint Phát hành” để giải công việc tồn đọng Nếu phải nhờ đến “Sprint Phát hành” cần xem thảm họa nhiệm vụ tổ chức phải cải thiện kỹ thuật để điều không xảy Quản lý Phát hành Một câu hỏi đưa làm để lập kế hoạch phát hành dài hạn sử dụng mô hình phát triển lặp Có hai trường hợp cần xem xét: (1) sản phẩm với phát hành đầu tiên, (2) sản phẩm tồn với phát hành Trong trường hợp sản phẩm mới, sản phẩm tồn vừa áp dụng Scrum, cần phải tiến hành làm mịn Product Backlog ban đầu trước khởi động Sprint đầu tiên, lúc để Product Owner Nhóm Phát triển định hình Product Backlog phù hợp Việc vài ngày tuần, bao gồm phiên làm việc (đôi gọi buổi Xây dựng Product Backlog Ban đầu Lập kế hoạch Phát hành), số phân tích chi tiết yêu cầu, ước tính tất hạng mục xác định cho lần phát hành Một điều ngạc nhiên Scrum, sản phẩm tồn có Product Backlog không cần tới kiện lớn đặc biệt để lập kế hoạch phát hành cho lần phát hành Tại sao? Tại Product Owner Nhóm Phát triển triển khai làm mịn Product Backlog Sprint (năm mười phần trăm thời gian Sprint), liên tục chuẩn bị cho tương 23 lai Hình thức phát triển sản phẩm liên tục tránh cần thiết giai đoạn rời rạc chuẩn bị-thực thi-kết thúc nhìn thấy vòng đời phương pháp phát triển truyền thống Trong phiên làm mịn Product Backlog ban đầu buổi làm mịn Product Backlog Sprint, Nhóm Phát triển Product Owner tiến hành lập kế hoạch phát hành, làm mịn ước tính độ ưu tiên nội dung khác mà họ học thứ Một số phát hành định hướng theo ngày; ví dụ: “Chúng ta phát hành phiên 2.0 dự án hội chợ thương mại vào ngày 10 tháng 11” Trong tình này, Nhóm Phát triển cố gắng hoàn thành nhiều Sprint (và xây dựng nhiều tính năng) tốt khoảng thời gian có Một vài sản phẩm khác lại yêu cầu số tính định phải xây dựng xong trước coi hoàn thành sản phẩm không tung yêu cầu thỏa mãn, cho dù có phải chờ đợi lâu Bởi Scrum nhấn mạnh vào việc làm mã có khả chuyển giao Sprint, Product Owner lựa chọn đưa phát hành tạm thời để giúp khách hàng sớm hưởng lợi từ công việc hoàn tất Bởi khách hàng khả biết trước thứ, nên hướng tập trung vào việc tạo tinh chỉnh kế hoạch cho phép hướng phát hành rộng hơn, nói rõ hướng để đưa định lựa chọn tương lai (ví dụ, quy mô so với lịch trình) Hãy coi lộ trình giúp bạn định hướng phía đến đích cuối cùng; đường xác mà bạn định mà bạn đưa xác định dọc theo hành trình Đích đến quan trọng hành trình Phần lớn Product Owner lựa chọn hình thức phát hành cụ thể Chẳng hạn, họ xác định ngày phát hành, sau trao đổi với Nhóm Phát triển để ước tính số hạng mục Product Backlog hoàn thành vào ngày Các hạng mục dự kiến có mặt phát hành gọi hạng mục phát hành Trong trường hợp đòi hỏi cam kết “giá cố định / ngày cố định / sản phẩm cố định” - ví dụ, phát triển theo hợp đồng - tham số phải để phần dự trữ dành cho bất ổn thay đổi; mặt Scrum không khác so với phương pháp khác Tập trung vào Ứng dụng Sản phẩm Đối với sản phẩm ứng dụng - kể thương mại lẫn sử dụng nội tổ chức Scrum chuyển từ mô hình cũ hướng-dự án sang mô hình phát triển ứng dụng/sản phẩm liên tục Không dự án với giai đoạn bắt đầu, giữa, kết thúc Do đó, không vai trò quản lý dự án truyền thống Thay vào đó, cần Product Owner ổn định Nhóm tự-quản bền vững, hợp tác với chuỗi “vô hạn” Sprint với độ dài cố định sản phẩm ứng dụng ngừng hỗ trợ Tất công việc cần thiết liên quan đến quản lý “dự án” xử lý Nhóm Phát triển Product Owner - người vai trò khách hàng nội đến từ phân Quản lý Sản phẩm Nó không quản lý quản lý Công nghệ Thông tin đến từ Phòng Quản lý Dự án 24 Scrum dùng cho dự án thực thuộc dạng giải pháp dùng lần (thay làm việc để tạo hay cải tiến ứng dụng lâu dài); trường hợp vậy, Nhóm Phát triển Product Owner đảm nhiệm công việc quản lý dự án Điều xảy đủ lượng công việc từ nhiều ứng dụng có để đảm bảo tồn bền vững Nhóm cho ứng dụng? Trong trường hợp này, Nhóm bền vững ổn định lấy hạng mục từ ứng dụng cho Sprint, sau lấy hạng mục từ ứng dụng khác cho Sprint tiếp theo; tình Sprint thường ngắn, chẳng hạn tuần Đôi khi, đủ công việc cho giải pháp trên, Nhóm lấy hạng mục từ vài ứng dụng cho Sprint; nhiên, thận trọng với cách làm dẫn đến suất thấp làm việc đa nhiệm nhiều ứng dụng Một nội dung để đảm bảo suất Scrum Nhóm tập trung vào sản phẩm ứng dụng Sprint Các thử thách Thường gặp Scrum không tập hợp cụ thể kỹ thuật - mà quan trọng hơn, khung làm việc thúc đẩy tính minh bạch, chế cho phép “thanh tra thích nghi” Scrum hoạt động dựa việc làm rõ bất ổn trở ngại gây ảnh hưởng đến hiệu Product Owner Nhóm, nhờ mà chúng xử lý tốt Ví dụ, Product Owner không hiểu rõ thị trường, tính năng, cách ước tính giá trị thương mại tương đối tính Hoặc Nhóm Phát triển không nắm rõ kỹ để ước tính khối lượng công việc tiến hành phát triển Khung làm việc Scrum giúp nhanh chóng phát yếu điểm Scrum không giải vấn đề việc phát triển; mà giúp chúng lên cách nhức nhối, cung cấp tảng để người tìm cách giải vấn đề chu trình ngắn với thử nghiệm cải tiến nhỏ Giả sử Nhóm Phát triển thất bại việc chuyển giao mà họ dự báo Sprint yếu kỹ phân tích ước lượng công việc Họ cảm thấy thất bại Nhưng thực tế, kinh nghiệm bước khởi đầu cần thiết để giúp họ trở nên thực thận trọng dự báo Việc Scrum giúp làm rõ bất ổn, cho phép Nhóm tìm cách giải chúng chế tạo nên lợi ích to lớn mà Nhóm sử dụng Scrum trải qua Một lỗi hay mắc phải gặp phải khó khăn với kỹ thuật Scrum lại cố gắng chỉnh sửa Scrum Ví dụ, Các nhóm gặp khó khăn việc chuyển giao sản phẩm định cho phép kéo dài thời gian Sprint để không bị thiếu thời gian - trình dẫn đến việc họ học cách ước lượng quản lý thời gian tốt Bằng cách này, huấn luyện hỗ trợ ScrumMaster có kinh nghiệm, tổ chức biến đổi Scrum thành yếu điểm bất ổn họ, phá hủy 25 lợi ích thực mà Scrum mang lại là: Làm rõ mặt tốt mặt xấu, trao cho tổ chức hội để nâng họ lên tầm cao Một lỗi hay mắc phải cho kỹ thuật không khuyến khích cấm sử dụng Scrum không yêu cầu cách cụ thể Ví dụ, Scrum không yêu cầu Product Owner phải đưa chiến lược dài hạn cho sản phẩm mình; không yêu cầu kỹ sư phải tham khảo ý kiến kỹ sư giàu kinh nghiệm đối mặt với vấn đề kỹ thuật phức tạp Scrum dành quyền định việc cho cá nhân liên quan; phần lớn trường hợp hai kỹ thuật (cùng với nhiều kỹ thuật khác) thực tốt Một điều cần phải thận trọng người quản lý áp đặt Scrum lên Nhóm mình; Scrum hướng đến việc trao cho Nhóm không gian công cụ để họ tự quản lý, việc ép buộc từ bên xuống công thức cho thành công Một cách tốt bắt đầu cho Nhóm học Scrum từ đồng nghiệp người quản lý, họ đào tạo chuyên môn đầy đủ, sau đến định với tư cách Nhóm để tuân thủ chặt chẽ kỹ thuật dạy khoảng thời gian định; kết thúc giai đoạn này, Nhóm đánh giá trải nghiệm định liệu có tiếp tục hay không Một tin tốt Sprint thường khó khăn Nhóm, lợi ích Scrum bộc lộ sau làm cho nhiều Nhóm Scrum phải lên: “Scrum khó thật, chắn tốt nhiều so với thứ mà làm trước đó!” 26 Phụ lục A: Tham khảo Thêm Có nhiều tài liệu Scrum Trong phần tham khảo này, muốn liệt kê vài tài liệu trực tuyến số sách Tài liệu trực tuyến:  The Lean Primer - An introduction to Lean Thinking, an important influence to Scrum http://www.leanprimer.com  The Distributed Scrum Primer - Additional tips for teams who aren’t co-located http://www.goodagile.com/distributedscrumprimer/  The ScrumMaster Checklist - A list of question that good ScrumMasters use http://www.scrummasterchecklist.org/  Feature Team Primer - Scaling Scrum with Feature Teams, http://www.featureteams.org  The Agile Atlas - Core Scrum ScrumAlliance description of Scrum http://agileatlas.org/atlas/scrum  Scrum Guide - Scrum.org description of Scrum http://www.scrum.org/Scrum-Guides  Agile Contracts Primer - How to make Scrum-friendly contracts http://www.agilecontracts.org/ Sách:      Leading Teams - Richard Hackman Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum - Craig Larman, Bas Vodde Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum - Craig Larman, Bas Vodde Agile Project Management with Scrum - Ken Schwaber Succeeding with Agile: Software Development using Scrum - Mike Cohn 27 Phụ lục B: Thuật ngữ Burn Down Xu hướng công việc lại xuyên suốt thời gian Sprint, Bản phát hành, Sản phẩm Nguồn liệu thô lấy từ Sprint Backlog Product Backlog, khối lượng công việc lại thể trục dọc (trục tung) thời gian (các ngày Sprint, Sprint) thể trục ngang (trục hoành) Daily Scrum - Scrum Hằng ngày Một buổi trao đổi ngắn Nhóm diễn ngày để thành viên Nhóm tra công việc mình, đồng công việc tiến độ, trình bày trở ngại gặp phải để ScrumMaster loại bỏ chúng Có thể diễn thảo luận sau để thích nghi phần công việc nhằm tối ưu hóa Sprint Development Team - Nhóm Phát triển Một ba vai trò Nhóm Scrum gồm ScrumMaster, ProductOwner Development Team Done - Hoàn thành Khái niệm hoàn thành thống tất bên tuân thủ tiêu chuẩn, quy ước, dẫn tổ chức Khi thứ coi “hoàn thành” buổi Sơ kết Sprint phải tuân thủ định nghĩa thống Estimated Work Remaining (Sprint Backlog items) - Công việc Còn lại Được ước lượng (các hạng mục Sprint Backlog) Số lại mà thành viên Nhóm ước tính dành để làm việc hạng mục Ước tính cập nhật vào cuối ngày hạng mục triển khai Con số tổng lượng công việc lại ước tính không phụ thuộc vào số người tham gia làm việc Increment - Phần tăng trưởng Tính sản phẩm Nhóm xây dựng Sprint có khả chuyển giao sử dụng bên liên quan Product Owner Increment of Potentially Shippable Product Functionality - Phần tăng trưởng Tính Sản phẩm Có khả Chuyển giao Một lát cắt hoàn chỉnh tổng thể sản phẩm hệ thống mà Product Owner bên liên quan sử dụng họ muốn triển khai Sprint Một phân đoạn, chu trình lặp với công việc giống để sản xuất phần tăng trưởng sản phẩm hệ thống Nó không phép kéo dài tháng thường dài tuần Độ dài Sprint cố định suốt trình phát triển, tất nhóm 28 tham gia làm việc sản phẩm hệ thống sử dụng chung chu trình có độ dài Product Backlog Một danh sách ưu tiên chứa yêu cầu với thời gian ước tính cần thiết để phát triển thành tính sản phẩm Các hạng mục phía Product Backlog có độ ưu tiên cao ước tính xác Danh sách tiến hóa thay đổi điều kiện kinh doanh công nghệ thay đổi Product Backlog Item - Hạng mục Product Backlog Các yêu cầu chức năng, phi chức năng, vấn đề đánh giá độ ưu tiên theo mức độ quan trọng nghiệp vụ kinh doanh phụ thuộc lẫn nhau, chúng ước lượng Độ xác việc ước tính phụ thuộc vào độ ưu tiên mức chi tiết hạng mục Product Backlog, hạng mục có độ ưu tiên cao lựa chọn cho Sprint chi tiết xác Product Owner Là người chịu trách nhiệm quản lý Product Backlog với mục tiêu tối ưu hóa giá trị sản phẩm Product Owner người đại diện cho quyền lợi tất có liên quan đến dự án sản phẩm tạo Scrum Không phải từ viết tắt mà chế trò chơi bóng bầu dục nhằm đưa bóng quay trở lại sân ScrumMaster Là người chịu trách nhiệm quy trình Scrum, đảm bảo triển khai tối ưu hóa lợi ích mà mang lại Sprint Backlog Danh sách công việc Nhóm Sprint Nó thường phân tách thành tập nhiệm vụ chi tiết Danh sách tiến hóa suốt buổi Lập kế hoạch Sprint Nhóm cập nhật suốt Sprint thông qua việc loại bỏ số hạng mục thêm công việc cần thiết Từng hạng mục công việc Sprint Backlog theo dõi suốt Sprint hiển thị khối lượng công việc ước tính lại Sprint Backlog Task - Công việc Sprint Backlog Là số công việc mà Nhóm thành viên Nhóm xác định cần phải thực để biến hạng mục Product Backlog thành chức hệ thống Sprint Planning - Lập kế hoạch Sprint 29 Một kiện đóng khung bốn đồng hồ (đối với Sprint hai tuần) để khởi động Sprint Sự kiện chia làm hai phần, phần kéo dài hai đóng khung Trong phần đầu tiên, Product Owner trình bày với Nhóm hạng mục Product Backlog có độ ưu tiên cao Nhóm Phát triển Product Owner hợp tác để giúp Nhóm Phát triển xác định số lượng hạng mục Product Backlog mà họ chuyển thành tính sản phẩm Sprint diễn Trong phần thứ hai, Nhóm Phát triển lên kế hoạch để thực nhiệm vụ chọn thông qua việc thiết kế phân tách công việc nhằm biết cách để đạt Mục tiêu Sprint Sprint Retrospective - Cải tiến Sprint Một kiện hỗ trợ ScrumMaster để toàn Nhóm Phát triển thảo luận Sprint vừa kết thúc nhằm tìm thay đổi để làm cho Sprint trở nên thú vị suất Sprint Review - Sơ kết Sprint Một kiện đóng khung hai đồng hồ (đối với Sprint hai tuần) diễn cuối Sprint để Nhóm Phát triển phối hợp với Product Owner bên liên quan nhằm tra kết Sprint Nó thường bắt đầu việc rà soát lại hạng mục Product Backlog hoàn thành, phiên thảo luận hội, hạn chế rủi ro, phiên thảo luận thứ tốt mà nên làm (dẫn đến thay đổi Product Backlog) Chỉ tính sản phẩm hoàn thành trình diễn Stakeholder - Bên liên quan Những người có quyền lợi kết dự án, họ đầu tư cho nó, dùng nó, ảnh hưởng đến họ Team – Nhóm (cách gọi tắt Development Team tài liệu Scrum Primer) Một đội liên-chức bao gồm người chịu trách nhiệm tự quản lý để phát triển phần tăng trưởng sản phẩm Sprint Time box - Khung thời gian Một khoảng thời gian không phép kéo dài thêm để thực kiện hoạt động Ví dụ, buổi Scrum Hằng ngày đóng khung mười lăm phút bắt buộc kết thúc sau mười lăm phút kết Đối với kiện, ngắn Còn Sprint chúng phải có độ dài xác 30