Kỹ Thuật - Công Nghệ - Báo cáo khoa học, luận văn tiến sĩ, luận văn thạc sĩ, nghiên cứu - Kinh Doanh - Business Scrum Guide Tác giả: Ken Schwaber và Jeff Sutherland Dịch: Dương Trọng Tấn 2 Scrum Guide – Ken Schwaber và Jeff Sutherland Bản Việt hóa này đang ở trạng thái beta Lời nói đầu (cho bản dịch ) Với yêu cầu về mặt phương pháp phát triển phần mềm phải đảm bảo sự gọn nhẹ, linh hoạt nhưng hiệ u quả, từ đầu những năm 1990, hàng loạt các phương pháp phát triển phần mềm linh hoạ t (agile software development, còn gọi tắt là Agile) ra đời nhằm đáp ứng yêu cầu ngày càng đa dạng và phức tạp của thự c tiễn phát triển phần mềm trên thế giới. Scrum được phát triển tương đối sớm bởi hai tác giả củ a nó là Ken Schwaber và Jeff Sutherland, và sớm trở thành một trong các phương pháp thành công nhất trong các phương pháp phát triển linh hoạt do sự đơn giản, hiệu quả và thú vị mà nó mang lại. Ngườ i dùng Scrum không chỉ ấn tượng với năng suất cực cao mà còn cảm nhận rõ ràng sự thay đổi trong cách làm việ c: trách nhiệm hơn, hiệu quả hơn, và thú vị hơn. Vài năm trở lại đây Scrum đã được du nhập vào Việt Nam, trước hết thông qua các công ty có yếu tố nước ngoài, sau đó đã xuất hiện chủ động ngày càng nhiều ở các công ty làm phần mềm suốt từ Nam chí Bắ c. Nhu cầu về công việc và học tập Scrum vì thế tăng lên đáng kể trong một hai năm gần đây. Tuy vậy, chưa có tổ chức giáo dục đào tạo nào đưa Scrum vào đào tạo chính quy, cũng như chưa có tài liệ u chính quy nào bằng tiếng Việt được cung cấp cho người dùng và người học Scrum để rút ngắn thời gian tiếp cận với phương pháp làm việc vô cùng hiệu quả và hấp dẫn này. Trước tình hình đó, một nhóm những người thực hành Scrum đã tập hợp lại dưới hình thức nhóm những người sử dụng Agile và Scrum để cùng chia sẻ kinh nghiệm tại Hà Nội (www.HanoiScrum.net ) và Thành phố Hồ Chí Minh (www.AgileVietnam.org ). Cùng chung nỗ lực với cộng đồng, người dịch tài liệu này mong muốn kiến thức về Scrum được giới thiệu tới người quan tâm đến Scrum bằng chính ngôn ngữ mẹ đẻ - tiếng Việt hòng giúp cho việc học tập và sử dụ ng Scrum trở nên hệ thống và có bài bản hơn. Đây là tài liệu dịch từ bản Scrum Guide xuất bản năm 2010 củ a chính Ken Schwaber và Jeff Sutherland, công bố trên Scrum.org; và nó sẽ được cập nhật khi bản gốc có sự chỉnh sửa. Do đây là một trong số những tài liệu căn bản đầu tiên bằng tiếng Việt về Scrum nên có nhiều thuật ngữ vẫn chưa được Việt hóa tốt, và vì vậy bạn đọc có thể thấy nhiều chỗ người dịch để cả thuật ngữ tiế ng Anh bên cạnh tiếng Việt. Trong quá trình dịch, người dịch cố gắng bám sát ý nghĩa và văn phong của tác giả. Đồng thời, để cung cấp thêm thông tin cho người mới tiếp cận Scrum lần đầu, người dịch có chú giả i thêm một số thuật ngữ, và cung cấp phần phụ lục “Thuật ngữ Scrum” để bạn đọc tiện tra cứu. Sử dụng triết lý tăng trưởng và tiến hóa của Scrum, các thuật ngữ này sẽ sớm được cập nhật dựa theo thực tiễn và sự chấp nhận rộng rãi của cộng đồng sử dụng Scrum. Tài liệu tuy ngắn nhưng do khách quan hoặc trình độ của người dịch, bản dịch có thể còn nhiều lỗi hoặc nhiều chỗ có thể cải tiến cho tốt hơn; mọi đóng góp quý báu về tài liệu này, xin vui lòng gửi về hộp thư duongtrongtangmail.com để người dịch có cơ hội cải tiế n bản dịch ngày càng hoàn thiện hơn, cung cấp thêm giá trị cho người học và sử dụng Scrum. Cuối cùng, người dịch xin trân trọng cảm ơn hai bạn đồng nghiệp, cũng là hai người thự c hành Scrum, Nguyễn Việt Khoa và Nguyễn Ngọc Tú đã bỏ công đọc và cung cấp nhiều góp ý quan trọng cho tài liệu này. 3 Scrum Guide – Ken Schwaber và Jeff Sutherland Bản Việt hóa này đang ở trạng thái beta Mục lục Lời nói đầu .............................................................................................................................................. 2 Giới thiệu ................................................................................................................................................ 4 Tổng quan ........................................................................................................................................... 4 Con người ........................................................................................................................................... 4 Lược sử ............................................................................................................................................... 4 Mục đích ............................................................................................................................................. 4 Lý thuyết Scrum...................................................................................................................................... 5 Tính minh bạch ................................................................................................................................... 5 Việc thanh tra...................................................................................................................................... 5 Sự thích nghi ....................................................................................................................................... 5 Nội dung Scrum ...................................................................................................................................... 6 Vai trò trong Nhóm Scrum .................................................................................................................. 7 ScrumMaster ...................................................................................................................................... 8 Product Owner - Chủ Sản phẩm .......................................................................................................... 9 Đội sản xuất - Team ............................................................................................................................ 9 Các Hộp Thời gian (Time-Box) .......................................................................................................... 10 Họp Kế hoạch phát hành - Release Planning Meeting ....................................................................... 10 Sprint – Phân đoạn nước rút ............................................................................................................. 12 Họp Kế hoạch Sprint - Sprint Planning Meeting ................................................................................ 13 Họp Sơ kết Sprint - Sprint Review ..................................................................................................... 15 Họp Cải tiến Sprint - Sprint Retrospective ......................................................................................... 15 Họp Scrum hằng ngày - Daily Scrum ................................................................................................. 16 Đồ nghề Scrum (Scrum Artifacts)...........................................................................................................17 Product Backlog và Release Burndown ..............................................................................................17 Sprint Backlog và Sprint Burndown ................................................................................................... 19 Hoàn thành (hay Xong - Done) .......................................................................................................... 20 Lời cuối ................................................................................................................................................. 21 Phụ lục – Thuật ngữ Scrum ................................................................................................................... 23 4 Scrum Guide – Ken Schwaber và Jeff Sutherland Bản Việt hóa này đang ở trạng thái beta Giới thiệu Tổng quan Scrum được xây dựng trên các phương pháp thực hành đã được chấp nhận rộ ng rãi qua hàng thập kỉ qua. Sau đó nó được coi như là lý thuyết quản lý thự c nghiệm (empirical process theory). Jim Coplien có lần đã nhấn mạnh với Jeff “tấ t cả mọi người sẽ thích Scrum; nó thực sự là những gì mà chúng ta sẽ làm khi bị dồn đến chân tường”. Con người Hàng nghìn người đã góp công xây dựng Scrum, chúng tôi chỉ là những ngườ i thử nghiệm nó trong khoảng mươi năm đầu. Những người có thể kể đến gồ m Jeff Sutherland, cùng vời Jeff McKenna, Ken Schwaber cùng vớ i Mike Smith và Chris Martin. Scrum lần đầu được trình bày chính thức tạ i OOPSLA 1995. Trong khoảng năm năm tiếp theo, Mike Beedle và Martine Devos đã có thêm nhiều đóng góp quan trọng. Và sau đó, rất nhiều người khác đã cùng nhau cải tiến để Scrum hoàn thiện như hôm nay chúng ta thấy. Lược sử Scrum có một lịch sử tương đối dài trong thế giới phần mềm. Những nơi đầ u tiên áp dụng Scrum có thể kể đế n Individual, Inc., Fidelity Investments, và IDX (bây giờ là GE Medical). Mục đích Ngay từ những năm 1990, Scrum đã được dùng để phát triển các sản phẩm phứ c tạp. Tài liệu này mô tả cách sử dụng Scrum để làm ra các sản phẩm phần mề m. Scrum không phải là một quy trình hay một kĩ thuật để làm ra sản phẩ m, mà là một khung làm việc (framework) bao gồm nhiều quy trình và kĩ thuậ t khác. Scrum có khả năng phát lộ tính hiệu quả của các hoạt động phát triển phần mềm để từ đó bạn có thể cải tiến chúng trong khi cung cấp một khung làm việc để phát triển các sản phẩm phức tạp. 5 Scrum Guide – Ken Schwaber và Jeff Sutherland Bản Việt hóa này đang ở trạng thái beta Lý thuyết Scrum Scrum là một lý thuyết kiểm soát tiến trình thực nghiệ m (emprical process control), sử dụng cách tiếp cận lặp (iterative) và tăng trưởng (incremental) để tối ưu hóa khả năng dự báo (predictability) và kiểm soát rủi ro. Ba giá trị cố t lõi (còn gọi là Ba chân của Scrum) làm nên quá trình kiểm soát tiến trình thực nghiệ m bao gồm: tính minh bạch, việc thanh tra và sự thích nghi. Tính minh bạch Sự minh bạch đảm bảo tất cả các yếu tố của quá trình có ảnh hưởng đến kết quả được công khai cho tất cả những người có trách nhiệm với dự án. Không chỉ các yếu tố đó được công khai, mà tất cả những gì đang được quan sát cũng phả i thông suốt tới các bên. Điều đó có nghĩa là khi một người khảo sát mộ t quy trình tin rằng có việc gì đó được hoàn thành, thì nó phải thỏa mãn tất cả các yêu cầu trong định nghĩa thế nào là hoàn thành (“Definition of done”). Việc thanh tra Rất nhiều yếu tố trong quy trình cần phải được thanh tra thường xuyên để đả m bảo tất cả các sai sót trong quy trình sớm được phát hiện. Tần suất thanh tra được xác định sao cho các yếu tố của quy trình phát triển có thể thay đổi đượ c sau khi thanh tra, từ đó mở đường cho khả năng thích nghi của quy trình. Có vẻ như càng thanh tra nhiều thì vấn đề càng phát sinh lắm. Nhưng may thay, điều đó không đúng trong việc phát triển phần mềm. Chất lượ ng thanh tra không hoàn toàn do tần suất thanh tra quyết định, mà còn do các yếu tố khác n ữa, như kĩ năng thanh tra hay mức độ cần cù và tỉ mỉ của người thực hiệ n công tác thanh tra. Sự thích nghi Nếu người thực hiện công tác thanh tra thấy rằng một vài chỗ trong quy trình là bất thường, và hậu quả của nó có thể là không thể chập nhận đượ c, thì quy trình hoặc các yếu tố liên quan cần phải được điều chỉnh cho phù hợp. Việc điều chỉ nh phải kịp thời để giảm thiểu các lệch lạc khác có thể xảy ra. Trong Scrum có ba thời điểm quan trọng cho việc thanh tra và thích nghi. Thứ nhất là cuộc họp Daily Scrum, được dùng để rà soát tiến độ công việc trong một 6 Scrum Guide – Ken Schwaber và Jeff Sutherland Bản Việt hóa này đang ở trạng thái beta Sprint, đồng thời có các hành động thích nghi để tối ưu hóa giá trị củ a các ngày là việc tiếp theo. Thứ hai, buổi Họp Sơ kết Sprint (Sprint Review) và Họp kế hoạ ch Sprint (Sprint Planning) được dùng để thanh tra tiến trình hướng đến Mụ c tiêu Phát hành (Realease Goal) và có các hành động thích ứng để tối ưu hóa Sprint tiếp theo. Cuối cùng, Buổi họp Cải tiến (Sprint Retrospective) được dùng để khảo sát kĩ càng Sprint vừa diễn ra và xác định các biện pháp thích ứng cho Sprint kế tiếp thêm năng suất, hoàn thiện và thú vị. Nội dung Scrum Khung làm việc Scrum bao gồm Nhóm Scrum (Scrum Team) với các vai trò được định nghĩa rõ ràng; các Hộp thời gian (Time-Box), Đồ nghề (Artifact), và các Quy tắc. Nhóm Scrum được thiết kế để tối ưu hóa tính linh hoạt và năng suất lao động. Để làm được điều đó, Nhóm Scrum thực hiện cơ chế tự quản, cơ cấu liên chức năng (cross-functional) và làm việc tập trung trong các phân đoạn (iteration) lặp đi lặp lại trong suốt dự án. Mỗi Nhóm Scrum có ba vai trò: một là ScrumMaster – người chịu trách nhiệm cho các quy trình của dự án, hai là Product Owner (chủ sản phẩm) – người chịu trách nhiệm cho giá trị của công việ c mà Nhóm Scrum làm, và ba là Đội sản xuất (Team) gồm những người trực tiếp làm ra phần mềm. Đội sản xuất bao gồm các nhà phát triển (developer) với tất cả các kĩ năng cầ n thiết để chuyển đổi yêu cầu của Product Owner thành các gói phần mề m hoàn chỉnh ở cuối mỗi Sprint. Scrum sử dụng khái niệm Hộp thời gian (Time-Box) để thiết lập quy tắ c cho nhóm. Trong Scrum, các thành tố được đóng hộp (timeboxed) bao gồm buổi Họ p kế hoạch Phát hành (Release Planning Meeting), Họp Kế hoạch Sprint (Sprint Planning Meeting), Sprint, Họp Scrum hằng ngày (Daily Scrum), Họp Sơ kế t Sprint (Sprint Review) và Họp Cải tiến Sprint (Sprint Retrospective). Trái tim củ a Scrum chính là Sprint – một phân đoạn phát triển diễn ra trong phạm vi ít hơn một tháng. Tất cả các Sprint trong cùng một dự án sử dụng cùng mộ t khung làm việc Scrum, Sprint nọ tiếp nối ngay sau Sprint kia và mỗi Sprint đều có kết quả 7 Scrum Guide – Ken Schwaber và Jeff Sutherland Bản Việt hóa này đang ở trạng thái beta cuối cùng là các gói phần mềm hoàn chỉnh chuyển giao được ( potentially shippable product increment). Scrum sử dụng bốn “đồ nghề” (artifact) cơ bản bao gồ m Product Backlog, Sprint Backlog, Release Burndown và Sprint Burndown. Product Backlog chứa danh sách ưu tiên các yêu cầu của dự án. Sprint Backlog là danh sách công việc cần làm để biến Product Backlog trong mỗi Sprint thành mộ t gói phần mềm hoàn chỉnh có thể chuyển giao ngay. Release Burndown đo phần hạng mục còn lạ i trong Product Backlog trong một Kế hoạch Phát hành. Còn Sprint Burndown đo các thời gian (ướ c tính) cần thiết còn lại để hoàn tấ t các tác vụ trong một Sprint. Các quy tắc của Scrum gắn kết các yếu tố Hộp thời gian, Vai trò và Đồ nghề (artifact) lại với nhau để Scrum phát huy tác dụng. Chúng ta sẽ dần tìm hiể u các quy tắc của Scrum trong suốt tài liệu này. Ví dụ, Scrum có đặt ra quy tắc là chỉ thành viên của Đội sản xuất – tức người có trách nhiệm với việc biến từng hạ ng mục trong Product Backlog thành mỗi gói phần mềm (increment) – có thể nói trong Daily Scrum. Trong tài liệu này, có nhiều gợi ý hữu ích cho việc triển khai Scrum nhưng không phải là quy tắc của Scrum; chúng được mô tả trong các hộp văn bản với các tiêu đề “Mẹo”. Vai trò trong Nhóm Scrum Nhóm Scrum bao gồm ScrumMaster, Product Owner và Đội sản xuấ t. Các thành viên Nhóm Scrum được gọi là các chú “lợn”. Chủ Sản phẩm (Product Owner) là “lợn” của Product Backlog. Đội sản xuất là “lợn” của các công việ c trong Sprint. ScrumMaster là “lợn” của tiến trình Scrum. Những người khác nế u có tham gia vào dự án thì đều là “gà”. Gà không thể chỉ cho lợn biết phải làm việ c ra sao. Hai vai trò “lợn” và “gà” ở đây thực ra có xuất xứ từ một câu chuyện vui như sau: Mẹo Nếu không tìm thấy hướng dẫn từ các quy tắc Scrum, bạn phải tự xác định mình sẽ phải làm những gì để công việc tiến triển. Do điều kiện thực tiễn luôn thay đổi khôn lường, nên bạn đừng cố gắng tìm kiếm một giải pháp hoàn hảo. Thay vì đó, hãy thử một phương án và xem nó làm việc ra sao. Hãy để cơ chế thanh tra – thích nghi (inspect-adapt) trong Scrum hướng dẫn bạn đi tiếp như thế nào. 8 Scrum Guide – Ken Schwaber và Jeff Sutherland Bản Việt hóa này đang ở trạng thái beta “Một chị gà mái và một chú lợn cùng ở với nhau khi chú gà gợi ý: “Ta cùng mở một nhà hàng nhé”. Chú lợn nghĩ một lúc và nói: “Ta sẽ gọ i tên nhà hàng này là gì nhỉ?” Chị gà đáp lại: “Nhà hàng Thịt lợ n và Trứng gà” Chú lợn kêu lên: “Ồ không, tôi thì bị thịt còn chị thì chỉ tham gia có thế thôi ư?”. ScrumMaster ScrumMaster chịu trách nhiệm đả m bảo toàn bộ Nhóm Scrum tuân thủ và được hưởng lợi từ các giá trị của Scrum, các kĩ thuật cũng như các quy tắc của Scrum. ScrumMaster giúp đỡ Nhóm Scrum cũng như một tổ chứ c áp dụng được Scrum vào trong công việc của họ. ScrumMaster dạ y cho Nhóm Scrum bằng cách huấn luyện và dẫn dắt Nhóm để đạt được năng suấ t cao và làm ra sản phẩm có chất lượng tốt. ScrumMaster giúp đỡ Nhóm Scrum hiểu và sử dụng cơ chế tự tổ chức (self-organization) cũng như cơ cấu liên chức năng (cross- functional) trong nhóm. ScrumMaster cũng giúp đỡ Nhóm Scrum phát huy tối đa khả năng trong môi trường chưa được tổ chức tốt để vẫn có thể hiệu quả trong các dự án phức tạp. Các công việc trợ giúp của ScrumMaster có đặc trưng cơ bả n là “loại bỏ trở lực” (removing impediment). ScrumMaster vừa là người lãnh đạ o vừa là đầy tớ của Nhóm Scrum. Mẹo Một thành viên, có thể là một lập trình viên, trong Đội sản xuất có thể giữ vai trò ScrumMaster. Tuy nhiên, điều này thường dẫn đến một số xung đột khi ScrumMaster phải lựa chọn giữa việc “loại bỏ trở lực” hay thực thi nhiệm vụ đã chọn trong Sprint. ScrumMaster không được phép làm Product Owner. Mẹo ScrumMaster làm việc với khách hàng và bộ phận quản lý để thiết lập một Chủ sản phẩm (Product Owner). ScrumMaster sẽ dạy cho Product Owner cách làm việc trong nhóm. Product Owner sẽ học được cách quản lý và tối ưu hóa giá trị khi dùng Scrum. Nếu Product Owner không làm được việc của mình, ScrumMaster sẽ là người chịu trách nhiệm. 9 Scrum Guide – Ken Schwaber và Jeff Sutherland Bản Việt hóa này đang ở trạng thái beta Product Owner - Chủ Sản phẩm Product Owner là người duy nhất chịu trách nhiệm cho việc quản lý Product Backlog và đảm bảo các giá trị cho Đội sản xuất làm việc. Product Owner duy trì Product Backlog và đảm bảo Product Backlog được hiển thị cho tất cả mọi ngườ i. Mọi người cần phải biết đâu là phần có độ ưu tiên cao hơn, để biết cần phả i làm việc với cái gì. Chủ Sản phẩm là cá nhân, không phải là một ủy ban. Một ủy ban nào đó có thể được thành lập để gợi ý hoặc tạo ảnh hưởng tới Product Owner, nhưng quyết định cuối cùng liên quan đến việc thay đổi Product backlog là củ a Product Owner. Các công ty sử dụng Scrum có thể có các cách thức khác nhau để thiết lập các độ ưu tiên và yêu cầu theo thời gian. Để đảm bảo thành công cho Product Owner, mọi người trong tổ chức cần phả i tôn trọng quyết định của người đảm nhiệm vai trò này. Không ai khác đượ c quyền áp đặt cách làm việc cho Đội sản xuất thông qua các bộ ưu tiên khác, và Đội sản xuất bắt buộc phải lờ đi các áp đặt kiểu như vậy. Quyết định củ a Product Owner luôn luôn minh bạch trong nội dung cũng như trong các mức độ ưu tiên. Sự minh bạch này đòi hỏi Product Owner phải nỗ lực tối đa, và điều đó khiế n cho vai trò Product Owner vừa là yêu cầu, nhưng cũng là phần thưởng cho ngườ i nắm giữ nó. Đội sản xuất - Team Đây là nhóm các nhà phát triển với mục tiêu chuyển đổi các yêu cầ u trong Product Backlog thành các gói sản phẩm sẵn sàng chuyển giao ở cuối mỗ i Sprint. Giống như Nhóm Scrum, Đội sản xuất cũng liên chức năng; các thành viên phải có đầy đủ các kĩ năng cần thiết để hoàn thành các công việc phát triển. Thành viên Đội sản xuất thườ ng có một số kĩ năng chuyên biệt như lậ p trình, quản lý chất lượ ng, phân tích nghiệp vụ, thiết kế, làm giao diệ n, hoặc thiết kế cơ sở dữ liệu. Tuy Mẹo Product Owner có thể là một trong số các thành viên đội phát triển. Trách nhiệm này có thể làm giảm khả năng làm việc với các bên liên quan. Product Owner không thể làm ScrumMaster. 10 Scrum Guide – Ken Schwaber và Jeff Sutherland Bản Việt hóa này đang ở trạng thái beta nhiên, bộ kĩ năng mà thành viên Đội sản xuất chia sẻ (đó là cách để hiểu yêu cầ u khách hàng và tiến hành chuyển đổi chúng thành sản phảm dùng được) sẽ trở nên quan trọng hơn các kĩ năng còn lại. Trong Đội sản xuất, kiến trúc sư phầ n mềm phải viết code. Không còn các chức danh trong Đội sản xuất, chỉ có nhà phát triển – developer, không có ngoại lệ. Một Đội sản xu ất cũng không có các phân đội chuyên biệt kiểu như đội kiểm thử hay đội phân tích thiết kế, chỉ có một đội duy nhất – Đội sản xuất. Đội sản xuất tự tổ chức lấy các hoạt động của mình. Không một ai, kể cả ScrumMaster – phải chỉ cho nhóm biết phải làm gì để chuyển đổi yêu cầ u thành sản phẩm dùng được. Nhóm sẽ phải tự chịu trách nhiệm tìm ra giải pháp để làm việc đó. Mỗi thành viên của nhóm sẽ phải áp dụng các chuyên môn của mình để giải quyết tất cả các vấn đề gặp phải. Sự hợp lực (synergy) sẽ mang lại kết quả cuối cùng cũng như tăng độ hiệu quả của nhóm. Độ lớn tối ưu cho một Đội sản xuất là bảy người, cộng trừ hai. Khi có ít hơn năm người trong nhóm, sẽ có ít tương tác hơn và đem lại năng suất thấp hơn. Nếu lớn hơn, nhóm sẽ gặp nhiều trở lực hơn trong Sprint và giảm khả năng hoàn thành công việc đúng hẹn trong mỗi Sprint. Nếu nhóm có nhiều hơn chín ngườ i, quá trình hợp nhất rất khó khăn, và cần nhiều nỗ lực hơn để quản lý công việ c. Tuy nhiên, trong thực tiễn vẫn có các nhóm lớn mà hiệu quả. Lưu ý là trong khi tính số lượng thành viên của Đội sản xuấ t, ta không tính Product Owner và ScrumMaster trừ khi bản thân họ tham gia Đội sản xuất , tức họ có tham gia vào quá trình thự c hiện các nhiệm vụ trong Sprint Backlog bên cạnh việc giữ các vai trò như Product Owner hay ScrumMaster. Cấu trúc nhóm có thể thay đổi khi Sprint kết thúc. Khi đó, mối quan hệ trong nhóm thay đổi, và năng suất từ quá trình tự tổ chức có thể giảm xuống. Hãy cẩ n thận với các thay đổi kiểu này. Các Hộp Thời gian (Time-Box) Họp Kế hoạch phát hành - Release Planning Meeting 11 Scrum Guide – Ken Schwaber và Jeff Sutherland Bản Việt hóa này đang ở trạng thái beta Mục đích của buổi họp lập kế hoạch cho phiên bản là tạo ra mục đích cũng như một bản kế hoạch để cả Nhóm Scrum (bao gồm Product Owner, ScrumMaster và Đội sản xuất) và phần còn lại của tổ chức có thể hiểu và giao tiếp vớ i nhau. Công tác lập kế hoạch bao gồm việc trả lời một số câu hỏi căn bản như “Làm sao để biến tầm nhìn (vision) về sản phẩm thành sản phẩm thực sự theo cách khả thi nhất?”, “Làm sao để đạt được hoặc làm tốt hơn sự mong đợi và thỏa mãn của khách hàng cũng như về mặt hiệu quả đầu tư (ROI – Return on Investment)?” . Bản Kế hoạch phát hành xác lập mục tiêu cho bản phát hành (release), độ ưu tiên cao nhất cho Product Backlog, các rủi ro căn bản, và các tính năng mà phiên bả n phần mềm sẽ có. Bản kế hoạch đó còn chứa ngày dự định phát hành, chi phí đầu tư nếu không có gì thay đổi. Tổ chức có thể khảo sát tiến trình phát triển và thay đổi bản kế hoạch này giữa các Sprint. Việc lập Kế hoạch phát hành là không bắt buộc. Nếu Nhóm Scrum bắt đầ u công việc mà không họp lập kế hoạch phát hành, thì sự thiếu vắng kế hoạch đó có thể coi như một trở ngại cần được loại bỏ (bằng cách nào đó) trong quá trình triể n khai Sprint sắp tới. Các sản phẩm được xây dựng theo từng phân đoạn trong Scrum, ở đó mỗ i Sprint tạo ra một phần tăng trưởng cho sản phẩm, bắt đầu từ các phần có giá trị cao nhất và ít rủi ro nhất. Cứ sau mỗi Sprint, sản phẩm sẽ lớn dần lên. Và các phần tăng trưởng đóp góp cho sự hoàn thiện của sản phẩm đó phải luôn luôn ở trạ ng thái có thể chuyển giao được khi Sprint kết thúc. Khi nào có đủ các ph ần tăng trưởng cần thiết, và đáp ứng được yêu cầu của các nhà đầu tư thì sản phẩm sẽ được phát hành (released) tới người dùng. Hầu hết các tổ chức hiện nay đều có quy trình lập kế hoạch phát hành sản phẩ m của mình, mà trong hầu hết các quy trình này thì phần lập kế hoạch hoàn tất trước khi bắt đầu quy trình sản xuất và không thay đổi gì sau đó. Trong Scrum, buổi Họp kế hoạch Phát hành xác lập mục tiêu căn bản và đầu ra khả thi cho quy trình. Phần này thường chỉ chiếm khoảng 15-20 thời gian so với thờ i gian mà một tổ chức dành ra để lập kế hoạch theo kiểu truyền thống. Scrum thực hiện cơ chế lập kế hoạch thời gian thực (just-in-time planning) thông qua các hộp thời 12 Scrum Guide – Ken Schwaber và Jeff Sutherland Bản Việt hóa này đang ở trạng thái beta gian khác như Họp Sơ kết Sprint (Sprint Review), Họp Kế hoạ ch Sprint (Sprint Planning), hay việc lập các kế hoạch chi tiết trong các buổi họp Daily Scrum. Về tổng thể, Scrum có thể mất nhiều thì giờ hơn để lập kế hoạch phát hành so với phương pháp truyền thống. Việc lập kế hoạch này bao gồm cả việc ước lượ ng và sắp thứ tự ưu tiên cho các hạng mục trong Product Backlog cho bả n phát hành sắp tới. Có nhiều kĩ thuật để thực hiệ n việc ước lượng này, Scrum không loạ i trừ bất kì phương pháp nào mà bạn biế t, miễn là nó hữu ích cho dự án. Sprint – Phân đoạn nước rút Mỗi Sprint là một phân đoạ n (iteration) trong quá trình phát triển phần mề m. Các Sprint được đóng hộp thờ i gian. Trong suốt Sprint, ScrumMaster cần đảm bảo không có sự thay đổi nào ảnh hưởng đến mục tiêu của Sprint. Cả cấu trúc của Đội sản xuất và tiêu chuẩn về chất lượng cũng không được thay đổi trong suốt Sprint. Sprint bao gồm buổ i Họp lập kế hoạch, Các công việc được thực hiện trong Sprint, Họp Sơ kế t Sprint và Họp Cải tiến Sprint (Sprint Retrospective). Các Sprint nối tiế p nhau, không có thời gian ngừng nghỉ. Một dự án thường có một mục đích xác định; trong việc phát triển phần mề m, mục đích là tạo nên một sản phẩm hay một hệ thống. Mọi dự án đều xác đị nh rõ những thứ phải làm ra, kế hoạch để làm chúng, các công việc phải làm theo kế hoạch đã vạch ra, và sản phẩm cuối cùng. Mỗi dự án đều có một tầm nhìn để tạ o một khung thời gian cho dự án. Nếu tầm nhìn quá xa, các mục tiêu có thể thay đổi, và rất nhiều yếu tố gây nhiễu khác có thể khiến rủi ro có thể trở nên không thể kiểm soát nổi. Scrum là một khung làm việc cho một án có tầm nhìn không dài hơn một tháng, vì nếu kéo dài hơn một tháng, độ phức tạp và rủi ro sẽ tăng lên. Khả năng dự tính của dự án cần được kiểm soát ít nhất mỗi lần trong tháng để tránh khả năng các yếu tố rủi ro có thể vượt khỏi tầm kiểm soát. Mẹo Nếu Đội sản xuất cảm thấy quá tải, có thể gặp Product Owner để giảm bớt số yêu cầu cần triển khai. Nếu nhóm thấy mình còn dư thời gian, có thể trao đổi với Product Owner để chọn thêm hạng mục trong Product Backlog để triển khai tiếp trong Sprint. 13 Scrum Guide – Ken Schwaber và Jeff Sutherland Bản Việt hóa này đang ở trạng thái beta Sprint có thể bị hủy bỏ trước khi vượt khỏi hộp thời gian của Sprint. Chỉ có Product Owner mới có đủ thẩm quyền để hủy bỏ một Sprint, mặc dù người đó không chịu sức ép của bất kì ai như các bên liên quan, Đội sản xuất, hoặ c ScrumMaster. Câu hỏi đặt ra là: trong tình cảnh nào thì Sprint cần phải bị hủy bỏ ? Có thể là khi các hoàn cảnh về thị trường hay công nghệ thay đổi, khiến cho Mụ c tiêu Sprint trở nên lỗi thời. Nói chung, Sprint nên bị hủy n ếu như nó không có ý nghĩa gì trong hoàn cảnh đó. Tuy nhiên, do mỗi Sprint chỉ diễn ra trong thờ i gian ngắn nên ít khi ta phải làm như vậy. Khi một Sprint bị hủy, các hạng mục đã hoàn tất được xem xét lại. Chúng sẽ đượ c chấp nhận nếu như chúng là một gói tăng trưởng có thể chuyển giao được. Tấ t cả các hạng mục trong Product Backlog khác được đặt ngược trở lạ i trong Product Backlog với ước lượng ban đầu của chúng. Các phần công việc hoàn tất liên quan đến các hạng mục này coi như mất. Tài nguyên sẽ bị lãng phí khi Sprint bị dừng, và mọi người phải họp lại để lập kế hoạch và bắt đầu một Sprint mớ i. Việc hủy Sprint thường khiến Đội sả n xuất bị sốc, nhưng rất ít khi nhóm phả i trải nghiệm điều này. Họp Kế hoạ ch Sprint - Sprint Planning Meeting Các cuộc họp Kế hoạch Sprint xả y ra khi ta lập kế hoạch cho một phân đoạn. Đó là thời gian đóng hộp đến tám giờ cho một Sprint một tháng. Với các Sprint ngắn hơn, phân bổ thời gian ít hơn cho việc lập kế hoạch Sprint (ví dụ, Sprint hai tuầ n chỉ cần bốn giờ cho họp lập kế hoạch Sprint). Họp kế hoạch Sprint bao gồ m hai phần. Phần đầu tiên để lựa chọn các hạng mục cần hoàn thành trong Sprint. Phầ n thứ hai (kéo dài bốn giờ cho một Sprint một tháng) xác định các hành động cầ n thiết trong Sprint để xây dựng các phần tăng trưởng cho sản phẩm. Có thể phân cuộc Họp kế hoạch Sprint thành hai phần đặc trưng: phần “Cái gì” và phần “Thế nào”. Một số Nhóm Scrum gộp hai phần này làm một. Ở phần đầ u tiên, Nhóm Scrum trả lời cho câu hỏi “Cái gì?”. Ở đây, Product Owner trình bày Mẹo Khi bắt đầu với Scrum, Đội sản xuất có thể chọn Sprint hai tuần để giảm bớt khả năng sa lầy vào sự bất định. Sprint kiểu này có thể được đồng bộ hóa với các nhóm khác để cùng làm ra hai gói t...
Scrum Guide Tác giả: Ken Schwaber Jeff Sutherland Dịch: Dương Trọng Tấn Lời nói đầu (cho dịch ) Với yêu cầu mặt phương pháp phát triển phần mềm phải đảm bảo gọn nhẹ, linh hoạt hiệu quả, từ đầu năm 1990, hàng loạt phương pháp phát triển phần mềm linh hoạt (agile software development, gọi tắt Agile) đời nhằm đáp ứng yêu cầu ngày đa dạng phức tạp thực tiễn phát triển phần mềm giới Scrum phát triển tương đối sớm hai tác giả Ken Schwaber Jeff Sutherland, sớm trở thành phương pháp thành công phương pháp phát triển linh hoạt đơn giản, hiệu thú vị mà mang lại Người dùng Scrum không ấn tượng với suất cực cao mà cảm nhận rõ ràng thay đổi cách làm việc: trách nhiệm hơn, hiệu hơn, thú vị Vài năm trở lại Scrum du nhập vào Việt Nam, trước hết thơng qua cơng ty có yếu tố nước ngồi, sau xuất chủ động ngày nhiều công ty làm phần mềm suốt từ Nam chí Bắc Nhu cầu cơng việc học tập Scrum tăng lên đáng kể hai năm gần Tuy vậy, chưa có tổ chức giáo dục đào tạo đưa Scrum vào đào tạo quy, chưa có tài liệu quy tiếng Việt cung cấp cho người dùng người học Scrum để rút ngắn thời gian tiếp cận với phương pháp làm việc vô hiệu hấp dẫn Trước tình hình đó, nhóm người thực hành Scrum tập hợp lại hình thức nhóm người sử dụng Agile Scrum để chia sẻ kinh nghiệm Hà Nội (www.HanoiScrum.net ) Thành phố Hồ Chí Minh (www.AgileVietnam.org) Cùng chung nỗ lực với cộng đồng, người dịch tài liệu mong muốn kiến thức Scrum giới thiệu tới người quan tâm đến Scrum ngơn ngữ mẹ đẻ - tiếng Việt hòng giúp cho việc học tập sử dụng Scrum trở nên hệ thống có Đây tài liệu dịch từ Scrum Guide xuất năm 2010 Ken Schwaber Jeff Sutherland, cơng bố Scrum.org; cập nhật gốc có chỉnh sửa Do số tài liệu tiếng Việt Scrum nên có nhiều thuật ngữ chưa Việt hóa tốt, bạn đọc thấy nhiều chỗ người dịch để thuật ngữ tiếng Anh bên cạnh tiếng Việt Trong trình dịch, người dịch cố gắng bám sát ý nghĩa văn phong tác giả Đồng thời, để cung cấp thêm thông tin cho người tiếp cận Scrum lần đầu, người dịch có giải thêm số thuật ngữ, cung cấp phần phụ lục “Thuật ngữ Scrum” để bạn đọc tiện tra cứu Sử dụng triết lý tăng trưởng tiến hóa Scrum, thuật ngữ sớm cập nhật dựa theo thực tiễn chấp nhận rộng rãi cộng đồng sử dụng Scrum Tài liệu ngắn khách quan trình độ người dịch, dịch cịn nhiều lỗi nhiều chỗ cải tiến cho tốt hơn; đóng góp q báu tài liệu này, xin vui lịng gửi hộp thư duongtrongtan@gmail.com để người dịch có hội cải tiến dịch ngày hoàn thiện hơn, cung cấp thêm giá trị cho người học sử dụng Scrum Cuối cùng, người dịch xin trân trọng cảm ơn hai bạn đồng nghiệp, hai người thực hành Scrum, Nguyễn Việt Khoa Nguyễn Ngọc Tú bỏ cơng đọc cung cấp nhiều góp ý quan trọng cho tài liệu Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta Mục lục Lời nói đầu Giới thiệu Tổng quan Con người Lược sử Mục đích Lý thuyết Scrum Tính minh bạch Việc tra Sự thích nghi Nội dung Scrum Vai trò Nhóm Scrum ScrumMaster Product Owner - Chủ Sản phẩm Đội sản xuất - Team Các Hộp Thời gian (Time-Box) 10 Họp Kế hoạch phát hành - Release Planning Meeting 10 Sprint – Phân đoạn nước rút 12 Họp Kế hoạch Sprint - Sprint Planning Meeting 13 Họp Sơ kết Sprint - Sprint Review 15 Họp Cải tiến Sprint - Sprint Retrospective 15 Họp Scrum ngày - Daily Scrum 16 Đồ nghề Scrum (Scrum Artifacts) 17 Product Backlog Release Burndown 17 Sprint Backlog Sprint Burndown 19 Hoàn thành (hay Xong - Done) 20 Lời cuối 21 Phụ lục – Thuật ngữ Scrum 23 Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta Giới thiệu Tổng quan Scrum xây dựng phương pháp thực hành chấp nhận rộng rãi qua hàng thập kỉ qua Sau coi lý thuyết quản lý thực nghiệm (empirical process theory) Jim Coplien có lần nhấn mạnh với Jeff “tất người thích Scrum; thực mà làm bị dồn đến chân tường” Con người Hàng nghìn người góp cơng xây dựng Scrum, chúng tơi người thử nghiệm khoảng mươi năm đầu Những người kể đến gồm Jeff Sutherland, vời Jeff McKenna, Ken Schwaber với Mike Smith Chris Martin Scrum lần đầu trình bày thức OOPSLA 1995 Trong khoảng năm năm tiếp theo, Mike Beedle Martine Devos có thêm nhiều đóng góp quan trọng Và sau đó, nhiều người khác cải tiến để Scrum hồn thiện hơm thấy Lược sử Scrum có lịch sử tương đối dài giới phần mềm Những nơi áp dụng Scrum kể đến Individual, Inc., Fidelity Investments, IDX (bây GE Medical) Mục đích Ngay từ năm 1990, Scrum dùng để phát triển sản phẩm phức tạp Tài liệu mô tả cách sử dụng Scrum để làm sản phẩm phần mềm Scrum khơng phải quy trình hay kĩ thuật để làm sản phẩm, mà khung làm việc (framework) bao gồm nhiều quy trình kĩ thuật khác Scrum có khả phát lộ tính hiệu hoạt động phát triển phần mềm để từ bạn cải tiến chúng cung cấp khung làm việc để phát triển sản phẩm phức tạp Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta Lý thuyết Scrum Scrum lý thuyết kiểm sốt tiến trình thực nghiệm (emprical process control), sử dụng cách tiếp cận lặp (iterative) tăng trưởng (incremental) để tối ưu hóa khả dự báo (predictability) kiểm soát rủi ro Ba giá trị cốt lõi (còn gọi Ba chân Scrum) làm nên q trình kiểm sốt tiến trình thực nghiệm bao gồm: tính minh bạch, việc tra thích nghi Tính minh bạch Sự minh bạch đảm bảo tất yếu tố q trình có ảnh hưởng đến kết công khai cho tất người có trách nhiệm với dự án Khơng yếu tố cơng khai, mà tất quan sát phải thông suốt tới bên Điều có nghĩa người khảo sát quy trình tin có việc hồn thành, phải thỏa mãn tất yêu cầu định nghĩa hoàn thành (“Definition of done”) Việc tra Rất nhiều yếu tố quy trình cần phải tra thường xuyên để đảm bảo tất sai sót quy trình sớm phát Tần suất tra xác định cho yếu tố quy trình phát triển thay đổi sau tra, từ mở đường cho khả thích nghi quy trình Có vẻ tra nhiều vấn đề phát sinh Nhưng may thay, điều khơng việc phát triển phần mềm Chất lượng tra khơng hồn tồn tần suất tra định, mà yếu tố khác nữa, kĩ tra hay mức độ cần cù tỉ mỉ người thực cơng tác tra Sự thích nghi Nếu người thực công tác tra thấy vài chỗ quy trình bất thường, hậu khơng thể chập nhận được, quy trình yếu tố liên quan cần phải điều chỉnh cho phù hợp Việc điều chỉnh phải kịp thời để giảm thiểu lệch lạc khác xảy Trong Scrum có ba thời điểm quan trọng cho việc tra thích nghi Thứ họp Daily Scrum, dùng để rà soát tiến độ công việc Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta Sprint, đồng thời có hành động thích nghi để tối ưu hóa giá trị ngày việc Thứ hai, buổi Họp Sơ kết Sprint (Sprint Review) Họp kế hoạch Sprint (Sprint Planning) dùng để tra tiến trình hướng đến Mục tiêu Phát hành (Realease Goal) có hành động thích ứng để tối ưu hóa Sprint Cuối cùng, Buổi họp Cải tiến (Sprint Retrospective) dùng để khảo sát kĩ Sprint vừa diễn xác định biện pháp thích ứng cho Sprint thêm suất, hoàn thiện thú vị Nội dung Scrum Khung làm việc Scrum bao gồm Nhóm Scrum (Scrum Team) với vai trị định nghĩa rõ ràng; Hộp thời gian (Time-Box), Đồ nghề (Artifact), Quy tắc Nhóm Scrum thiết kế để tối ưu hóa tính linh hoạt suất lao động Để làm điều đó, Nhóm Scrum thực chế tự quản, cấu liên chức (cross-functional) làm việc tập trung phân đoạn (iteration) lặp lặp lại suốt dự án Mỗi Nhóm Scrum có ba vai trị: ScrumMaster – người chịu trách nhiệm cho quy trình dự án, hai Product Owner (chủ sản phẩm) – người chịu trách nhiệm cho giá trị công việc mà Nhóm Scrum làm, ba Đội sản xuất (Team) gồm người trực tiếp làm phần mềm Đội sản xuất bao gồm nhà phát triển (developer) với tất kĩ cần thiết để chuyển đổi yêu cầu Product Owner thành gói phần mềm hoàn chỉnh cuối Sprint Scrum sử dụng khái niệm Hộp thời gian (Time-Box) để thiết lập quy tắc cho nhóm Trong Scrum, thành tố đóng hộp (timeboxed) bao gồm buổi Họp kế hoạch Phát hành (Release Planning Meeting), Họp Kế hoạch Sprint (Sprint Planning Meeting), Sprint, Họp Scrum ngày (Daily Scrum), Họp Sơ kết Sprint (Sprint Review) Họp Cải tiến Sprint (Sprint Retrospective) Trái tim Scrum Sprint – phân đoạn phát triển diễn phạm vi tháng Tất Sprint dự án sử dụng khung làm việc Scrum, Sprint tiếp nối sau Sprint Sprint có kết Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta cuối gói phần mềm hồn chỉnh chuyển giao (potentially shippable product increment) Scrum sử dụng bốn “đồ nghề” (artifact) bao gồm Product Backlog, Sprint Backlog, Release Burndown Sprint Burndown Product Backlog chứa danh sách ưu tiên yêu cầu dự án Sprint Backlog danh sách công Mẹo việc cần làm để biến Product Nếu khơng tìm thấy hướng dẫn từ quy tắc Backlog Sprint thành Scrum, bạn phải tự xác định phải làm gói phần mềm hồn chỉnh để cơng việc tiến triển Do điều kiện chuyển giao Release thực tiễn thay đổi khôn lường, nên bạn Burndown đo phần hạng mục lại đừng cố gắng tìm kiếm giải pháp hồn hảo Product Backlog Kế Thay đó, thử phương án xem hoạch Phát hành Cịn Sprint làm việc Hãy để chế tra – thích nghi (inspect-adapt) Scrum hướng dẫn bạn Burndown đo thời gian (ước tiếp tính) cần thiết cịn lại để hồn tất tác vụ Sprint Các quy tắc Scrum gắn kết yếu tố Hộp thời gian, Vai trò Đồ nghề (artifact) lại với để Scrum phát huy tác dụng Chúng ta dần tìm hiểu quy tắc Scrum suốt tài liệu Ví dụ, Scrum có đặt quy tắc thành viên Đội sản xuất – tức người có trách nhiệm với việc biến hạng mục Product Backlog thành gói phần mềm (increment) – nói Daily Scrum Trong tài liệu này, có nhiều gợi ý hữu ích cho việc triển khai Scrum quy tắc Scrum; chúng mô tả hộp văn với tiêu đề “Mẹo” Vai trị Nhóm Scrum Nhóm Scrum bao gồm ScrumMaster, Product Owner Đội sản xuất Các thành viên Nhóm Scrum gọi “lợn” Chủ Sản phẩm (Product Owner) “lợn” Product Backlog Đội sản xuất “lợn” công việc Sprint ScrumMaster “lợn” tiến trình Scrum Những người khác có tham gia vào dự án “gà” Gà cho lợn biết phải làm việc Hai vai trò “lợn” “gà” thực có xuất xứ từ câu chuyện vui sau: Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta “Một chị gà mái lợn Mẹo với gà gợi ý: “Ta mở nhà hàng nhé!” ScrumMaster làm việc với khách hàng phận quản lý để thiết lập Chủ sản phẩm (Product Chú lợn nghĩ lúc nói: “Ta gọi Owner) ScrumMaster dạy cho Product Owner tên nhà hàng nhỉ?” cách làm việc nhóm Product Owner học cách quản lý tối ưu hóa giá trị dùng Chị gà đáp lại: “Nhà hàng Thịt lợn Scrum Nếu Product Owner không làm việc Trứng gà!” mình, ScrumMaster người chịu trách nhiệm Chú lợn kêu lên: “Ồ khơng, tơi bị thịt cịn chị tham gia thơi ư?” Mẹo ScrumMaster Một thành viên, lập trình viên, ScrumMaster chịu trách nhiệm đảm Đội sản xuất giữ vai trị bảo tồn Nhóm Scrum tn thủ ScrumMaster Tuy nhiên, điều thường dẫn hưởng lợi từ giá trị đến số xung đột ScrumMaster phải lựa Scrum, kĩ thuật quy chọn việc “loại bỏ trở lực” hay thực thi tắc Scrum ScrumMaster giúp đỡ nhiệm vụ chọn Sprint ScrumMaster khơng phép làm Product Owner Nhóm Scrum tổ chức áp dụng Scrum vào cơng việc họ ScrumMaster dạy cho Nhóm Scrum cách huấn luyện dẫn dắt Nhóm để đạt suất cao làm sản phẩm có chất lượng tốt ScrumMaster giúp đỡ Nhóm Scrum hiểu sử dụng chế tự tổ chức (self-organization) cấu liên chức (cross- functional) nhóm ScrumMaster giúp đỡ Nhóm Scrum phát huy tối đa khả môi trường chưa tổ chức tốt để hiệu dự án phức tạp Các cơng việc trợ giúp ScrumMaster có đặc trưng “loại bỏ trở lực” (removing impediment) ScrumMaster vừa người lãnh đạo vừa đầy tớ Nhóm Scrum Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta Product Owner - Chủ Sản phẩm Product Owner người chịu trách nhiệm cho việc quản lý Product Backlog đảm bảo giá trị cho Đội sản xuất làm việc Product Owner trì Product Backlog đảm bảo Product Backlog hiển thị cho tất người Mọi người cần phải phần có độ ưu tiên cao hơn, để biết cần phải làm việc với Chủ Sản phẩm cá nhân, ủy ban Một ủy ban thành lập để gợi ý tạo ảnh hưởng tới Product Owner, định cuối liên quan đến việc thay đổi Product backlog Product Owner Các công ty sử dụng Scrum có cách thức khác để thiết lập độ ưu tiên yêu cầu theo thời gian Để đảm bảo thành công cho Product Owner, người tổ chức cần phải tôn trọng định người đảm nhiệm vai trò Không khác quyền áp đặt cách làm việc cho Đội sản xuất thông qua ưu tiên khác, Đội sản xuất bắt buộc phải lờ áp đặt kiểu Quyết định Product Owner luôn minh bạch nội dung mức độ ưu tiên Sự minh bạch đòi hỏi Product Owner phải nỗ lực tối đa, điều khiến cho vai trị Product Owner vừa yêu cầu, phần thưởng cho người nắm giữ Đội sản xuất - Team Đây nhóm nhà phát triển với mục tiêu chuyển đổi yêu cầu Product Backlog thành gói sản phẩm sẵn sàng chuyển giao cuối Sprint Giống Nhóm Scrum, Đội sản xuất liên chức năng; thành viên phải có đầy đủ kĩ cần thiết để hồn thành cơng việc phát triển Mẹo Thành viên Đội sản xuất thường có Product Owner số thành số kĩ chuyên biệt lập viên đội phát triển Trách nhiệm làm trình, quản lý chất lượng, phân tích giảm khả làm việc với bên liên quan nghiệp vụ, thiết kế, làm giao diện, Product Owner làm ScrumMaster thiết kế sở liệu Tuy Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta nhiên, kĩ mà thành viên Đội sản xuất chia sẻ (đó cách để hiểu yêu cầu khách hàng tiến hành chuyển đổi chúng thành sản phảm dùng được) trở nên quan trọng kĩ lại Trong Đội sản xuất, kiến trúc sư phần mềm phải viết code Khơng cịn chức danh Đội sản xuất, có nhà phát triển – developer, khơng có ngoại lệ Một Đội sản xuất khơng có phân đội chun biệt kiểu đội kiểm thử hay đội phân tích thiết kế, có đội – Đội sản xuất Đội sản xuất tự tổ chức lấy hoạt động Khơng ai, kể ScrumMaster – phải cho nhóm biết phải làm để chuyển đổi yêu cầu thành sản phẩm dùng Nhóm phải tự chịu trách nhiệm tìm giải pháp để làm việc Mỗi thành viên nhóm phải áp dụng chun mơn để giải tất vấn đề gặp phải Sự hợp lực (synergy) mang lại kết cuối tăng độ hiệu nhóm Độ lớn tối ưu cho Đội sản xuất bảy người, cộng trừ hai Khi có năm người nhóm, có tương tác đem lại suất thấp Nếu lớn hơn, nhóm gặp nhiều trở lực Sprint giảm khả hoàn thành cơng việc hẹn Sprint Nếu nhóm có nhiều chín người, q trình hợp khó khăn, cần nhiều nỗ lực để quản lý cơng việc Tuy nhiên, thực tiễn có nhóm lớn mà hiệu Lưu ý tính số lượng thành viên Đội sản xuất, ta khơng tính Product Owner ScrumMaster trừ thân họ tham gia Đội sản xuất , tức họ có tham gia vào trình thực nhiệm vụ Sprint Backlog bên cạnh việc giữ vai trò Product Owner hay ScrumMaster Cấu trúc nhóm thay đổi Sprint kết thúc Khi đó, mối quan hệ nhóm thay đổi, suất từ trình tự tổ chức giảm xuống Hãy cẩn thận với thay đổi kiểu Các Hộp Thời gian (Time-Box) Họp Kế hoạch phát hành - Release Planning Meeting 10 Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta Sprint bị hủy bỏ trước vượt khỏi hộp thời gian Sprint Chỉ có Product Owner có đủ thẩm quyền để hủy bỏ Sprint, người khơng chịu sức ép bên liên quan, Đội sản xuất, ScrumMaster Câu hỏi đặt là: tình cảnh Sprint cần phải bị hủy bỏ? Có thể hồn cảnh thị trường hay cơng nghệ thay đổi, khiến cho Mục tiêu Sprint trở nên lỗi thời Nói chung, Sprint nên bị hủy khơng có ý nghĩa hồn cảnh Tuy nhiên, Sprint diễn thời gian ngắn nên ta phải làm Khi Sprint bị hủy, hạng mục hoàn tất xem xét lại Chúng chấp nhận chúng gói tăng trưởng chuyển giao Tất hạng mục Product Backlog khác đặt ngược trở lại Product Backlog với ước lượng ban đầu chúng Các phần công việc hoàn tất liên quan đến hạng mục coi Tài nguyên bị lãng phí Sprint bị dừng, người phải họp lại để lập kế hoạch bắt đầu Sprint Việc hủy Sprint thường khiến Đội sản xuất bị sốc, nhóm phải Mẹo trải nghiệm điều Khi bắt đầu với Scrum, Đội sản xuất Họp Kế hoạch Sprint - Sprint chọn Sprint hai tuần để giảm bớt khả sa Planning Meeting lầy vào bất định Sprint kiểu đồng hóa với nhóm khác để Các họp Kế hoạch Sprint xảy làm hai gói tăng trưởng khác ta lập kế hoạch cho phân đoạn Đó thời gian đóng hộp đến tám cho Sprint tháng Với Sprint ngắn hơn, phân bổ thời gian cho việc lập kế hoạch Sprint (ví dụ, Sprint hai tuần cần bốn cho họp lập kế hoạch Sprint) Họp kế hoạch Sprint bao gồm hai phần Phần để lựa chọn hạng mục cần hoàn thành Sprint Phần thứ hai (kéo dài bốn cho Sprint tháng) xác định hành động cần thiết Sprint để xây dựng phần tăng trưởng cho sản phẩm Có thể phân Họp kế hoạch Sprint thành hai phần đặc trưng: phần “Cái gì” phần “Thế nào” Một số Nhóm Scrum gộp hai phần làm Ở phần đầu tiên, Nhóm Scrum trả lời cho câu hỏi “Cái gì?” Ở đây, Product Owner trình bày 13 Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta phần ưu tiên Product Backlog cho Đội sản xuất hiểu Họ hợp tác để xác định chức cần phải phát triển Sprint tới Đầu vào cho họp Product Backlog lực có Đội sản xuất Lượng Product Backlog mà Đội sản xuất lựa chọn hồn tồn phụ thuộc vào nhóm với lực xác định Chỉ Đội sản xuất xác định có khả làm Sprint tới Sau lựa chọn hạng mục Product Backlog, Mục tiêu Sprint (Sprint Goal) hình thành Mục tiêu đóng vai trị kim nam để Đội sản xuất làm gói tăng trưởng cho dự án Mục tiêu Sprint phần Mục tiêu Phát hành (Release Goal) Ví dụ mục tiêu cho Sprint phát biểu như:” Tự động hóa việc chỉnh sửa tài khoản khách hàng thơng qua middleware với khả giao dịch an toàn” Khi làm việc, Đội sản xuất cần ghi nhớ mục tiêu thực công việc kĩ thuật cần thiết để đạt Nếu cơng việc khó khăn nhóm dự tính, Nhóm cần hợp tác với Product Owner để phát triển phần mục tiêu Trong phần hai Họp kế hoạch Sprint, nhóm trả lời câu hỏi “Thế nào?” Nhóm phải để biến hạng mục lựa chọn từ Product Backlog phần trước Họp kế hoạch Sprint thành phần tăng trưởng dự án Đội phát triển thường bắt đầu với việc thiết kế công việc phải làm Khi thiết kế, Đội phát triển nhận biết tác vụ phải thực suốt Sprint Các tác vụ cơng việc cụ thể cần thiết để biến Product Backlog thành phần mềm chạy Tác vụ cần đủ nhỏ để chúng hồn tất vịng ngày Danh sách cơng việc gọi Sprint Backlog Nhóm tự tổ chức để thực công việc Sprint Backlog, họp kế hoạch Sprint làm việc Sprint Product Owner phải diện phần hai Họp kế hoạch Sprint để làm rõ Product Backlog giúp đỡ Đội phát triển đưa định tối ưu Nếu Nhóm phát triển phát có q hay q nhiều cơng việc, nhóm thương thảo lại với Product Owner Product Backlog Đội sản xuất mời số người khác tham gia để cung cấp trợ giúp chuyên môn hay công 14 Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta nghệ thấy cần thiết Một nhóm thường nhận thấy họ bơi hay chết chìm buổi họp Nhóm sớm nhận họ phải tự lực cánh sinh Và biết điều đó, nhóm bắt đầu tự tổ chức với đặc thù hành động nhóm hiệu thực Họp Sơ kết Sprint - Sprint Review Nhóm tổ chức buổi họp Sơ kết Sprint (Sprint Review) Đây buổi họp đóng hộp bốn tiếng Sprint tháng Với Sprint ngắn hơn, thời gian cho Sơ kết rút ngắn lại (ví dụ, với Sprint hai tuần, ta cần khung thời gian hai đủ) Khi Sơ kết, Nhóm Scrum người có liên quan trao đổi thứ vừa hoàn thành Sprint vừa Dựa sở đó, với thay đổi Product Backlog Sprint diễn ra, họ hợp tác để xác định thứ cần phải hoàn tất Sprint Đây buổi họp không trang trọng, nên việc thuyết trình chức vừa hoàn tất để phục vụ cho việc bàn bạc làm Sprint tới khơng phải để báo cáo buổi tổng kết thường thấy Cuộc họp cần phải có yếu tố sau để đảm bảo thành công Product Owner nhận biết hồn thành, chưa Đội sản xuất thảo luận thành cơng Sprint có vấn đề phát sinh, để giải vấn đề Đội sản xuất trình diễn cơng việc họ hoàn tất trả lời câu hỏi từ người tham dự họp Product Owner sau thảo luận Product Backlog, ngày dự kiến hoàn thành với nhiều giả định tốc độ phát triển dự án Tồn nhóm hợp tác để thấy trạng dự án xác định công việc cần phải làm Sprint tới Sprint Review cung cấp liệu đầu vào vô quan trọng cho buổi Họp kế hoạch Sprint (Sprint Planning) Họp Cải tiến Sprint - Sprint Retrospective Ngay sau Sơ kết Sprint, trước buổi Họp kế hoạch cho Sprint tiếp theo, Nhóm Scrum họp Sprint Retrospective Buổi họp đóng hộp khoảng thời gian ba đồng hồ cho Sprint tháng (phân bổ thời gian hợp lý cho Sprint ngắn hơn) Trong họp này, ScrumMaster khuyến khích Nhóm 15 Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta Scrum chỉnh sửa lại quy trình khn khổ khung làm việc Scrum nhằm cải tiến quy trình, khiến cho quy trình trở nên hiệu thú vị vào Sprint sau Bạn tham khảo nhiều tài liệu sách xuất đề cập đến kĩ thuật hữu ích để thực cơng tác Retrospective Mục đích Retrospective để khảo sát kĩ lưỡng tất yếu tố tham gia vào quy trình Sprint vừa qua, bao gồm người, mối quan hệ, quy trình cơng cụ Q trình khảo sát cần phải nhận ưu tiên hóa điểm tốt thứ tốt Các thứ cần cải tiến gồm cấu trúc Nhóm Scrum, việc họp hành, cơng cụ, định nghĩa “hoàn thành”, cách thức giao tiếp, quy trình phát triển để chuyển đổi Product Backlog thành cơng việc đánh dấu “hồn thành” Kết thúc buổi Sprint Retrospective, Nhóm Scrum phải xác định hành động cải tiến lượng hóa để tiến hành Sprint sau Những thay đổi trở thành thích nghi cho q trình khảo sát thực nghiệm (empirical inspection) vừa hoàn tất Họp Scrum ngày - Daily Scrum Đội sản xuất Họp Scrum ngày (Daily Scrum) vòng mười lăm phút ngày để triển khai kĩ thuật tra-thích nghi cho cơng việc ngày Daily Scrum diễn nơi nhóm làm việc ngày với ba câu hỏi cho thành viên nhóm: Bạn làm kể từ buổi họp trước đến giờ; Bạn làm trước buổi họp tới đây; Bạn gặp phải trở ngại làm việc Daily Scrum cải thiện giao tiếp, giảm thiểu thời gian họp hành khác không cần thiết, nhận biết loại bỏ rắc rối trình phát tiển, nhấn mạnh khuyến khích định nhanh chóng, tăng mức độ hiểu biết tất người dự án ScrumMaster tạo điều kiện để Đội sản xuất họp Daily Scrum thật hiệu Còn Đội sản xuất phải chịu trách nhiệm Daily Scrum ScrumMaster phải dạy cho Đội sản xuất giữ nhanh gọn Daily Scrum quy tắc cần thiết 16 Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta đảm bảo người nói vắn tắt đủ hiểu ScrumMaster phải áp dụng quy tắc cho “các gà” để đảm bảo chúng không kêu quang quác khiến họp bị gián đoạn (Quy tắc: “gà không kêu”) Daily Scrum buổi họp báo cáo trạng thái cơng việc Nó khơng dành cho khác ngồi người chịu trách nhiệm việc biến đổi Product Backlog thành gói phần mềm dùng (tức Đội sản xuất) Đội sản xuất cần phải Mẹo bám sát Mục tiêu Sprint (Sprint Goal) Các Nhóm Scrum thường bỏ 10% thời gian Product Backlog để làm việc Daily Sprint cho việc làm mịn Product Backlog Scrum phần tra (inspection) để đạt tiêu chuẩn Product Backlog tiến trình tiến tới Mục tiêu Sprint Mục tốt Khi làm mịn, hạng mục Product Backlog đích để tận dụng khả thuộc phần (có độ ưu tiên cao nhất, có mà Đội sản xuất đạt mục giá trị nhất) tách để thực tiêu Đây chìa khóa buổi họp phạm vi Sprint Chúng tra-thích nghi (tức Daily Scrum) phân tích kĩ q trình làm mịn Cho tới họp Kế hoạch Sprint, hạng quy trình thực nghiệm (empirical mục ưu tiên đủ rõ ràng dễ dàng process) Scrum lựa chọn để đưa vào phát triển Đồ nghề Scrum (Scrum Mẹo Artifacts) Trong số tổ chức, có nhiều phần việc Các đồ nghề (artifacts) dùng thêm vào backlog phần việc Scrum gồm có Product Backlog, hồn thành Điều dẫn đến Release Burndown, Sprint Backlog đường biểu diễn xu hướng Burndown Sprint Burndown lên thay xuống thường thấy Để giải trường hợp để đảm bảo tính Product Backlog Release minh bạch, sàn (floor) thiết lập Burndown thêm bớt công việc phải làm Sàn Yêu cầu khách hàng liệt kê cần phải thêm vào bớt thay Product Backlog Product Owner đổi quan trọng, cần tài liệu hóa cẩn chịu trách nhiệm tạo lập, quản lý ưu thận để tất người nắm tiên hóa (prioritization) cho hạng 17 Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta mục Product Backlog Product Backlog không đầy đủ Theo đó, lát cắt ban đầu đem phát triển thường phần rõ ràng Product Backlog tiến hóa trình phát triển sản phẩm theo kịp Mẹo thay đổi tình hình thực tiễn Product Backlog thực thể động, Kiểm thử chấp nhận (Acceptance Test) biến đổi liên tục để thể cho thường số thuộc tính quan điều thực cần thiết, phù trọng mơ tả hạng mục hợp, có tính cạnh tranh hữu ích Product Backlog Chúng cho biết chi tiết Product Backlog tồn chừng việc sản phẩm phải đạt tiêu chí để sản phẩm tồn người dùng chấp nhận chức (hay sản phẩm) hoàn tất Product Backlog chứa tất thứ cần thiết phải phát triển tạo thành sản phẩm thành cơng Nó chứa danh sách tất tính năng, chức năng, cơng nghệ, cải tiến, sửa lỗi cần phải thực để làm thành sản phẩm lần phát hành (release) tới Các hạng mục (Product Backlog item) Product Backlog thường viết với thuộc tính như: mơ tả, độ ưu tiên ước lượng Độ ưu tiên xác định dựa yếu tố rủi ro, giá trị, mức độ cần thiết yêu cầu Ta dùng nhiều kĩ thuật để đánh giá thuộc tính Product Backlog xếp dựa mức ưu tiên (priority) Phần ưu tiên cao Product Backlog trực tiếp đưa vào trình phát triển Càng có độ ưu tiên cao mức độ quan tâm tới phần Product Backlog phải khẩn trương kĩ hơn; độ trí giá trị phần cao Các hạng mục có độ ưu tiên cao rõ ràng mô tả chi tiết so với mục có độ ưu tiên thấp Khi đó, việc ước lượng hạng mục xác Đối với hạng mục ưu tiên thấp, thơng tin hơn, bạn bỏ cơng tìm hiểu kĩ chúng Khi sản phẩm đem sử dụng, giá trị tăng lên, thị trường có phản hồi sản phẩm, hạng mục Product Backlog tăng dần u cầu khơng ngừng thay đổi Product Backlog tài liệu sống liên tục cập nhật để phản ánh thay đổi yêu cầu nghiệp vụ, điều kiện thị trường, công nghệ hay thay đổi nhân dự án Để giảm thiểu việc phải làm lại thứ cơng tạo ra, mục có độ ưu tiên cao 18 Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta đem phân tích kĩ Cịn lại, hạng mục mà ta dự định triển khai Sprint sau phân tách kĩ cho hạng mục hồn thành phạm vi Sprint Nhóm Scrum thường làm việc sản phẩm Mỗi Product Backlog dùng để mô tả công việc tới cho sản phẩm Căn tính chất hạng mục Product Backlog mà ta nhóm chúng lại với Việc phân loại theo tập tính năng, cơng nghệ, kiến trúc Đó cách mà Nhóm Scrum dùng để tổ chức cơng việc Biểu đồ Release Burndown ghi lại tổng số nỗ lực (effort) ước tính cho hạng mục lại Product Backlog qua thời gian Các nỗ lực ước lượng đo nhiều loại đơn vị khác tùy định Nhóm Scrum tổ chức Đơn vị thời gian thường dùng cho Sprint Ước tính (estimate) cho hạng mục Product Backlog tính toán lần đầu Release Planning (Họp kế hoạch Phát hành) Product Backlog tạo Sau đó, mục thường xuyên đánh giá lại (thao tác gọi Product Backlog grooming – làm mịn Product Backlog) Do đó, ước lượng thường xuyên cập nhật dự án Đội sản xuất chịu trách nhiệm cho việc thực ước tính cho tất hạng mục trình làm việc Product Owner gây ảnh hưởng lên nhóm cách giúp họ hiểu thêm lựa chọn phương án tối ưu phù hợp với thực tiễn, định cuối giá trị ước lượng hoàn toàn phụ thuộc vào Đội sản xuất Product Owner Mẹo cần phải đảm bảo cho chi tiết việc cập nhật Product Backlog hay Release Đường vẽ xu hướng không đáng tin Backlog Burndown luôn công cậy hai Sprint đầu tiên, trừ khai thời điểm Một đồ thị biểu Nhóm làm việc với từ trước, hiểu diễn xu hướng dự án dựa biết tốt sản phẩm tường tận công nghệ thay đổi lượng công việc lại phải sử dụng làm vẽ để người tiện theo dõi tiến độ dự án Sprint Backlog Sprint Burndown 19 Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta Sprint Backlog chứa danh sách công việc mà Đội sản xuất cần thực để chuyển đổi hạng mục Product Backlog thành phần tăng trưởng xác nhận “hồn thành” Rất nhiều tác vụ thiết lập buổi Họp kế hoạch Sprint Sprint Backlog tất cơng việc mà Đội sản xuất phải làm việc suốt Sprint để đạt đến Mục tiêu Sprint Công việc liệt kê Sprint Backlog phải tách nhỏ để tiện theo dõi thay đổi q trình làm việc (ví dụ để báo cáo theo dõi Daily Scrum) Cơng việc sau phân tách nên có ước lượng không nên dài ngày Đội sản xuất chỉnh sửa Sprint Backlog suốt Sprint Khi thành viên Đội sản xuất lựa chọn nhiệm vụ để thực hiện, thành viên nhận thấy phải làm nhiều tác vụ khác, thời gian cần thiết nhiều dự tính ban đầu Khi có tác vụ mới, nhóm thêm vào Product Backlog Khi có chọn việc để làm, trạng thái (đang làm hay hồn tất) thời gian ước tính cịn lại (estimated remaining work) phải cập nhật liên tục Khi có tác vụ khơng cần thiết nữa, Nhóm loại bỏ khỏi danh sách cơng việc Chỉ có Đội sản xuất có quyền chỉnh sửa Sprint Backlog Sprint diễn Chỉ có họ đủ quyền để cập nhật ước lượng Sprint Backlog cần phải cơng khai Nó kế hoạch thời gian thực cơng việc mà nhóm làm việc Sprint, thuộc Đội sản xuất Sprint Burndown biểu đồ thể lượng công việc lại Sprint qua thời gian Để tạo biểu đồ này, ta tính tổng ước lượng cho công việc ngày Sprint Các số liệu ước lượng lấy từ Sprint Backlog Hằng ngày ta tính lại số liệu cập nhật lại đồ thị để thấy lượng cơng việc cịn lại qua thời gian Dựa vào đó, ta quản lý tiến độ công việc Sprint Trong Scrum, thời gian bỏ làm việc không quan tâm.Thay đó, Scrum để ý tới lượng cơng việc cịn lại ngày cịn lại để làm việc Một quy tắc để đảm phải mục đích Sprint việc tuân thủ Định nghĩa “Hoàn thành” Tất mục đánh dấu “hoàn thành” phải phù hợp tiêu chuẩn định nghĩa từ trước Hoàn thành (hay Xong - Done) Scrum yêu cầu nhóm phải làm phần tăng trưởng (increment) hoàn chỉnh sản phẩm cuối Sprint Đây gói chuyển giao (shippable) cho Chủ sản phẩm (Product Owner) Muốn vậy, phần phải thực phần sản phẩm cuối Chúng phải thỏa mãn định nghĩa 20 Scrum Guide – Ken Schwaber Jeff Sutherland Bản Việt hóa trạng thái beta