SCRUM GUIDE - KEN SCHWABER VÀ JEFF SUTHERLAND

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 và Jeff Sutherland

Dịch: Dương Trọng Tấn

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ư duongtrongtan@gmail.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

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

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

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

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ả

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

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

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

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

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

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

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ăng trưởng khác nhau