🔙 Quay lại trang tải sách pdf ebook Cẩm Nang Scrum Cho Người Mới Bắt Đầu Ebooks Nhóm Zalo Mục lục 1. Lời nói đầu 2. Lời cảm ơn 3. Cùng bạn dùng sách 4. 1. Tổng quan Agile 5. 2. Khái lược Scrum 6. 3. Nhóm Scrum 7. 4. Các sự kiện Scrum 8. 5. Các tạo tác và công cụ 9. 6. Scrum trong tổ chức 10. 7. Kĩ thuật Agile 11. 8. Scrum phân tán 12. 9. Scrum với quy mô lớn 13. Tài liệu tham khảo và đọc thêm 14. Phụ lục 1: Thuật ngữ 15. Phụ lục 2: Danh mục kiểm tra 16. Bảng chỉ mục Lời nói đầu Bạn đang cầm trên tay cuốn sách về Scrum đầu tiên do người Việt biên soạn. Sau nhiều năm hoà nhập cùng cộng đồng Agile thế giới trong việc học hỏi, ứng dụng, và xây dựng cộng đồng Agile tại Việt Nam, cuốn sách này đánh dấu một bước tiến mới trong việc phát triển một hệ sinh thái Agile mạnh tại Việt Nam. Kể từ hội nghị tại Utah, Hoa Kì, năm 2001, khai sinh ra đường lối Phát triển Phần mềm Linh hoạt (Agile Software Development) mà chúng ta gọi tắt là Agile, chúng ta đã chứng kiến những thay đổi lớn lao của thế giới phần mềm nói riêng, và thế giới công nghệ nói chung. Đó là thời gian đủ để những Google, iPhone, iPad, Android, Facebook, Twitter… ra đời và đảo lộn trật tự thế giới. Agile, từ chỗ là một trào lưu phản kháng trong đợt khủng hoảng các phương pháp phát triển phần mềm, đã trở thành “tiêu chuẩn hờ” cho việc phát triển phần mềm, lan sang phát triển sản phẩm công nghệ nói chung, và tiện thể loang cả sang những địa hạt mà những người kí vào bản Tuyên ngôn Agile năm 2001 không thể ngờ tới: Marketing, giáo dục, quản trị, trong gia đình, nông nghiệp hay thậm chí cả trong... nhà thờ. Nhóm tác giả Học viện Agile hân hạnh đồng hành cùng các bạn học Agile, thực hành Agile để kiến tạo những giá trị mới, tạo những đổi thay tích cực. Thông qua việc biên soạn tài liệu này, chúng tôi mong muốn mang đến cho bạn cơ hội học hỏi, thực hành Agile với chất lượng cao và hiệu quả tốt. Dù rất nỗ lực, cuốn sách chắc chắn không khỏi mắc phạm phải những thiếu sót. Chúng tôi luôn mong chờ những phản hồi của bạn để cải tiến liên tục tài liệu này tại thư điện tử [email protected]. Học viện Agile Lời cảm ơn Cuốn sách này được viết dựa trên một tài liệu giảng dạy Scrum do chúng tôi khởi thảo từ cuối 2011, và liên tục cải tiến để giúp cho việc học Scrum ngày càng dễ dàng hơn. Phần nhiều những cải tiến đó đến từ người học, mà chúng tôi gọi là những “đối tác phát triển” – những người giúp nhau cùng tiến bộ. Chúng tôi vô cùng biết ơn những “đồng tác giả” vô danh này. Trong khi tổ chức lại thành một cuốn cẩm nang có chất lượng cao như phiên bản bạn cầm trên tay, rất nhiều người đã góp ý trực tiếp về nội dung, bố cục cũng như cách thức trình bày hiệu quả. Chúng tôi xin chân thành cảm ơn bạn bè khắp nơi đã cung cấp những lời khuyên quý báu. Trong đó xin đặc biệt cảm ơn chị Nguyễn Phương Anh – Giám đốc Khối đào tạo liên kết quốc tế thuộc Đại học FPT, anh Nguyễn Tuân – Giám đốc đào tạo FPT Aptech Hà Nội, anh Phạm Mạnh Lân – Co-founder NAL Group, anh Hán Văn Thắng – CEO DEHA, anh Nguyễn Ngọc Tú và Nguyễn Minh Tâm từ NAL Vietnam, anh Nguyễn Văn Hiển từ Agile Vietnam, anh Tô Hải Sơn – Giám đốc vận hành NTQ Solution, và những người bạn khác nữa chưa kịp kể tên. Xin cảm ơn anh Đoàn Xuân Trường đã thiết kế bìa; xin cảm ơn chị Nguyễn Thị Phương – đồng nghiệp đã lao tâm khổ tứ để cuốn sách này đến được với bạn đọc. Cảm ơn Kim Cúc đã hiện thực hoá những ý tưởng trình bày khác thường của nhóm tác giả. Cuối cùng, chúng tôi xin vô cùng cảm ơn bạn – người đang đọc cuốn sách này, vì chính bạn là người cùng chúng tôi tạo ra giá trị cho cuốn sách và lan toả những giá trị Scrum. Cùng bạn dùng sách Cuốn sách này được viết ra để cho những nhà phát triển và quản lí bước đầu sử dụng Scrum. Vì thế nó được thiết kế tối ưu cho việc học và tra cứu. Chúng tôi nghĩ rằng 80% giá trị của cuốn sách nằm ở cách bạn đọc vận dụng nó. Do đó, chúng tôi mong muốn thảo luận đôi chút về cấu trúc của cuốn sách cũng như cách đọc, cách dùng cuốn sách này. Chương đầu tiên rất lí thuyết nhưng là nền tảng. Có thể là chương khó đọc nhất, nhưng lại quan trọng nhất vì nó giải thích cặn kẽ triết lí đứng đằng sau Scrum. Bạn không thể thực hành tốt Scrum mà không nắm rõ những nguyên lí Agile có tính dẫn đường. Do vậy hãy đọc qua Chương 1 trước khi đọc các chương tiếp theo, và thỉnh thoảng đọc lại chương này để suy ngẫm thêm. Nếu bạn nóng ruột muốn tìm hiểu Scrum thì có thể chỉ cần lướt qua Chương 1, nhưng hãy quay trở lại sau khi đã đọc xong cả cuốn sách. Chương 2, 3, 4, 5 mô tả chi tiết khung Scrum và cách vận hành trong thực tiễn. Cuốn sách này hướng đến việc thực hành “đúng” Scrum. Vì thế hãy đọc kĩ, và tự trả lời các câu hỏi cuối chương. Việc trả lời các câu hỏi này giúp bạn đưa kiến thức vào thực tiễn, bối cảnh đặc thù của bạn. Ngoài ra, việc trả lời các câu hỏi này giúp cho bạn bổ khuyết được một khía cạnh không được đề cập trong khuôn khổ một cuốn cẩm nang ngắn gọn: vận dụng Scrum “hợp lí”. Chương 6 thảo luận về các tình huống sử dụng Scrum và những điều ghi nhớ khi lần đầu tiên đưa Scrum vào tổ chức. Bạn có thể nhảy cóc đến chương này nếu tò mò về các bước cụ thể áp dụng Scrum. Các chương 7, 8, 9 có thể coi là phần mở rộng của cuốn sách nhằm cung cấp một bức tranh lớn hơn khi vận dụng Scrum. Người mới bắt đầu với Scrum, đối tượng chính của cuốn sách này, có vẻ ít khi vận dụng những nội dung ở các chương này, nhưng bạn cần nắm được một bức tranh lớn để hình dung ra một lộ trình dài hơi cho việc biến Scrum thành một đường lối làm việc nhất quán, cải tiến liên tục, hiệu quả và thành công bền vững. Riêng Chương 7 có đề cập nhiều kĩ thuật đặc thù Agile mà nhiều lập trình viên thấy lạ lẫm và rất thích thú. Bạn hãy lướt qua, tìm hiểu kĩ thêm (tham khảo danh mục đọc thêm ở cuối sách) nếu muốn đi xa hơn. Nếu bạn để ý, đây là cuốn sách kĩ thuật bằng tiếng Việt hiếm hoi có Bảng chỉ mục. Hãy tận dụng nó cho việc học và tra cứu. Hãy dùng Bảng chỉ mục (Index) ở cuối sách, Mục lục chi tiết, và phần Phụ lục 1 (Thuật ngữ Scrum) để tra cứu, chuyển qua chuyển lại các phần của cuốn sách, hoặc để tra cứu thêm thông tin trên Internet về một khái niệm được đề cập trong sách. Trong sách, thỉnh thoảng có những ô “Dừng và nghĩ” với một số câu hỏi hướng dẫn, như những nốt lặng trong các bản nhạc. Bạn hãy dừng lại một chút, động não trong phút chốc để tiêu hoá nội dung của cuốn sách. Ngoài ra, các Danh mục Kiểm tra được đặt vào một số phần quan trọng cũng có thể giúp bạn trong việc tự đánh giá được mức độ đúng đắn và thành thục trong việc vận dụng Scrum trong nhóm của mình. Một số tài nguyên và đọc thêm cho cuốn sách được chúng tôi cập nhật tại www.hocvienagile.com/cam-nang-scrum. Chúc bạn dùng sách thật hiệu quả! 1 1TỔNG QUAN AGILE Trong chương này... • Những vấn đề nổi cộm trong phát triển sản phẩm • Sự ra đời của Agile • Tuyên ngôn Phát triển Phần mềm Linh hoạt • Cách tiếp cận lặp tăng trưởng và truyền thống • Khi nào Agile, khi nào không? Các phương pháp Agile tối ưu các tri thức ẩn trong đội ngũ phát triển, thay vì lệ thuộc vào những thông tin được viết ra dưới dạng kế hoạch hay tài liệu. Barry Boehm NHỮNG VẤN ĐỀ PHỔ BIẾN TRONG PHÁT TRIỂN SẢN PHẨM VÀ QUẢN TRỊ DỰ ÁN PHẦN MỀM Ngành phát triển phần mềm đã có hơn nửa thế kỉ hình thành và phát triển, tuy nhiên việc phát triển phần mềm và quản trị các dự án phần mềm chưa bao giờ hết thử thách. Rất nhiều những vấn đề cứ không ngừng lặp đi lặp lại, làm đau đầu đội ngũ phát triển và các nhà quản trị. Dưới đây là một số vấn đề tiêu biểu. Theo cách thức phát triển truyền thống, dự án được lập kế hoạch cẩn thận, được tiến hành với rất nhiều khâu trung gian, và khách hàng ngồi chờ. Các bên liên quan hầu như chỉ nhận được báo cáo, tài liệu chứ không nhận được phần mềm để dùng. Thông tin về phần mềm rất mù mờ. Lâu tới ngày phát hành và không minh bạch về tiến độ khiến khách hàng và các bên liên quan sốt ruột, lo lắng và không làm cách nào để cung cấp các phản hồi có ý nghĩa, khó hợp tác với đội phát triển cho ra sản phẩm tốt nhất. Kế hoạch đã định, nhưng nhiều rủi ro xuất hiện: lỗi xuất hiện ngày càng nhiều, hiểu sai yêu cầu, những khó khăn về mặt công nghệ, một vài thành viên có vấn đề và không làm việc như kỳ vọng và sản phẩm chậm ngày phát hành. Mọi thứ đã được tích hợp, nhưng sản phẩm thiếu ổn định do không kiểm soát được chất lượng. Ở rất nhiều dự án, mọi công việc đã hoàn thành nhưng giai đoạn tích hợp và ổn định hệ thống thật là thảm họa, không biết khi nào kết thúc. Kế hoạch thường xuyên sai sót nên chúng ta phải đầu tư nhiều thời gian hơn vào xây dựng kế hoạch. Nhưng dù cố gắng đến mấy thì kế hoạch vẫn không đâu vào đâu và chúng ta lại bị phàn nàn là làm kế hoạch chưa kӻ. Lập kế hoạch thật là một ác mộng, nhiệm vụ không thể hoàn thành. Khi đã thực hiện xong phân tích yêu cầu, thiết kế và bắt đầu lập trình, khách hàng đổi yêu cầu. Vì đó là yêu cầu rất quan trọng, bạn không thể từ chối. Nhóm rất khó xử. Họ không biết làm thế nào bởi việc thay đổi rất khó. Ban đầu sản phẩm còn chạy tốt, nhưng lượng mã nguồn ngày một tăng lên, áp lực thời gian, v.v. nên chất lượng sản phẩm cứ giảm sút. Kế hoạch đã bị vỡ, chất lượng ngày một giảm, tất cả mọi người phải làm thêm giờ với áp lực rất cao, thành viên không hạnh phúc. ⇒ Dừng và Nghĩ Bạn và nhóm của mình đang gặp phải những vấn đề nổi cộm nào? KHỦNG HOẢNG PHƯƠNG PHÁP LUẬN, VÀ SỰ RA ĐỜI CỦA AGILE Thập kỉ 80 của thế kỉ XX chứng kiến một thời kì khủng hoảng phương pháp luận phát triển phần mềm, do tỉ lệ thất bại của các dự án phần mềm quá cao. Hàng loạt nỗ lực của các nhà thực hành cũng như giới hàn lâm đã cố gắng tìm ra phương pháp hữu hiệu để đảm bảo tính hiệu quả trong phát triển phần mềm. Thập kỉ 90, nhiều phương pháp phát triển phần mềm với quy trình nhẹ (light weight) và linh hoạt ra đời, như XP, Scrum, FDD, Crystal, ... và nhanh chóng được lan rộng. 2 Từ 11 - 13 tháng 2 năm 2001, 17 nhà phát minh và nhà thực hành đã họp nhau tại bang Utah, Hoa Kì, để thảo luận về hướng đi mới trong phương pháp luận phát triển phần mềm. Họ đã đi đến thống nhất và cho ra đời bản Tuyên ngôn Agile (The Manifesto for Agile Software Development) và đánh dấu một xu thế mới trong phát triển phần mềm. Ngày nay chúng ta gọi Agile, tức là chỉ chung một họ phương pháp phát triển phần mềm có chung sự chia sẻ các giá trị và nguyên tắc được phát biểu trong Tuyên ngôn Agile. Biện pháp thực hành có thể rất khác nhau, nhưng triết lí chung thì giống nhau. img298 Sự ra đời Tuyên ngôn Agile. Ảnh: agilemanifesto.org Sau một thập kỉ rưỡi ra đời. Agile đã cải thiện đáng kể khả năng thành công của các dự án. Báo cáo CHAOS của Standish Group năm 2015 cho thấy, các dự án Agile có tỉ lệ thành công cao hơn 3 lần so với dự án truyền thống. 3 Dự án thành công: đúng thời gian, đúng ngân sách với mọi tính năng và kết quả thoả mãn. Dự án thử thách: hoàn thành nhưng không đạt một trong các tiêu chí đúng ngân sách, đúng thời gian, hoặc kết quả không thỏa mãn Dự án thất bại: dự án bị cắt ở một thời điểm nào đó trong quá trình phát triển 4 Những nghiên cứu chi tiết hơn định lượng được tác động của những phương pháp Agile lên năng suất lao động. Như trong nghiên cứu của Sutherland và đồng nghiệp năm 2008, năng suất của nhóm Scrum cao hơn tới gần 9 lần so với nhóm sử dụng phương pháp truyền thống. Trong nghiên cứu này, kích thước phần mềm được đo bằng hai thước đo phổ biến trong phát triển phần mềm là số dòng mã và điểm chức năng (function point). Năng suất tính theo điểm chức năng của nhóm Scrum cao hơn nhóm truyền thống 15,3/1,7 = 8,88 lần. 5 * So sánh với phương pháp truyền thống waterfall ** KLOC: 1000 dòng mã ⇒ Theo Sutherland, J., Schoonheim, G., Rusten- burg, E., & Rijk, M. (2008, August). Fully distributed scrum: The secret sauce for hyperproductive offshored development TUYÊN NGÔN PHÁT TRIỂN PHẦN MỀM LINH HOẠT Chúng tôi đã tìm ra cách tốt hơn để phát triển phần mềm thông qua việc thực hành và giúp đỡ người khác thực hiện. Qua đó, chúng tôi đánh giá cao: 6 Mặc dù các thứ bên phải vẫn còn giá trị, chúng tôi đánh giá cao hơn các mục ở bên trái. 12 NGUYÊN LÍ PHÍA SAU TUYÊN NGÔN AGILE 1. Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc chuyển giao sớm và liên tục các phần mềm có giá trị. 2. Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển. Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng. 3. Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn. 4. Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hằng ngày trong suốt dự án. 5. Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc. 6. Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực tiếp. 7. Phần mềm chạy tốt là thước đo chính của tiến độ. 8. Các quy trình linh hoạt thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát triển, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn. 9. Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt. 10. Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản. 11. Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức. 12. Nhóm phát triển sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp. Theo AgileManifesto.org Ý NGHĨA CỦA TUYÊN NGÔN AGILE theo Jeff Sutherland* Những giá trị đó không chỉ là thứ mà các tác giả của Tuyên ngôn Agile dự định cung cấp ra để phục vụ cho tuyên ngôn và rồi sau đó đi vào quên lãng. Chúng là các giá trị căn cứ vào để làm việc. Bản thân mỗi phương pháp linh hoạt đều tiếp cận các giá trị trên theo các cách thức khác nhau, nhưng tất cả các phương pháp này đều có tiến trình và biện pháp thực hành cụ thể để nuôi dưỡng một hoặc nhiều trong số các giá trị đó. 7 Cá nhân và tương tác Cá nhân và sự tương tác giữa họ là cốt yếu để nhóm đạt được hiệu suất cao. Các nghiên cứu về sự “bão hòa giao tiếp” (communication saturation) trong dự án cho thấy rằng, khi không có vấn đề trong giao tiếp, nhóm có thể thực hiện công việc tốt hơn 50 lần so với mức trung bình trong lĩnh vực của mình. Để tạo điều kiện cho giao tiếp, các phương pháp linh hoạt thường xuyên sử dụng chu trình thanh- tra-và-thích-nghi. Chu trình này có thể diễn ra hằng phút với lập trình cặp (pair-programming), hằng giờ với tích hợp liên tục (contin- uous integration), hằng ngày với standup meeting (họp đứng), hằng phân đoạn với các buổi họp sơ kết và cải tiến. Tuy nhiên, chỉ tăng tần suất phản hồi và giao tiếp là không đủ để loại bỏ các vấn đề về giao tiếp. Chu kỳ thanh-tra-và-thích-nghi hoạt động tốt chỉ khi các thành viên trong nhóm thể hiện những hành vi quan trọng sau: • Tôn trọng giá trị của mỗi cá nhân • Trung thực trong giao tiếp • Minh bạch về dữ liệu, hoạt động, và quyết định • Tin tưởng vào sự hỗ trợ của mỗi cá nhân với nhóm • Cam kết với nhóm và các mục tiêu của nhóm 8 Để thúc đẩy các hành vi này, nhà quản lí linh hoạt phải cung cấp một môi trường hỗ trợ, các nhà huấn luyện phải tạo điều kiện thuận lợi, và các thành viên của nhóm phải thể hiện chúng. Chỉ khi đó nhóm mới có thể phát huy được hết tiềm năng của mình. Đạt tới các hành vi đó khó khăn hơn rất nhiều so với việc hình thành chúng. Hầu hết các nhóm tránh né sự thật, sự minh bạch, và tin tưởng vào các chuẩn mực văn hóa hoặc có những kinh nghiệm tiêu cực từ các xung đột xuất phát từ truyền thống trước đây. Để chống lại những khuynh hướng này, ban lãnh đạo và thành viên nhóm phải tạo điều kiện cho những xung đột tích cực. Làm như vậy không chỉ giúp tạo ra hành vi sinh lợi mà còn đem lại các lợi ích khác: 9 • Cải tiến quy trình phụ thuộc vào nhóm trong việc tạo ra danh sách các trở ngại hoặc vấn đề trong tổ chức, đối mặt với chúng một cách trung thực, và sau đó loại bỏ chúng một cách có hệ thống tùy theo độ ưu tiên. • Đổi mới chỉ xảy ra với việc tự do trao đổi các ý tưởng mâu thuẫn nhau, như Takeuchi và Nonaka đã từng nghiên cứu và chỉ ra. • Việc hướng các nhóm tới mục tiêu chung đòi hỏi nhóm phải đối mặt và giải quyết các vấn đề về xung đột. • Cam kết làm việc cùng nhau sẽ xảy ra chỉ khi mọi người đồng ý với mục tiêu chung và sau đó đấu tranh cho sự tiến bộ của bản thân cũng như của nhóm. Ý cuối cùng ở trên nói về cam kết là đặc biệt quan trọng. Đó là khi mà các cá nhân và các nhóm được cam kết và cảm thấy có trách nhiệm với việc cung cấp các giá trị cao, đó là điểm mấu chốt đối với các nhóm phát triển phần mềm. Các phương pháp linh hoạt tạo điều kiện cho việc cam kết bằng cách khuyến khích nhóm đưa ra một danh sách công việc được ưu tiên hóa, để họ tự quản lí công việc của mình, và tập trung vào cải tiến về cách thực hiện các công việc đó. Phần mềm chạy tốt Phần mềm chạy tốt là một trong những khác biệt lớn mà phát triển linh hoạt mang lại. Tất cả các phương pháp linh hoạt thể hiện Tuyên ngôn Agile bằng cách nhấn mạnh việc cung cấp một phần nhỏ của phần mềm chạy tốt tới khách hàng sau một khoảng thời gian nhất định. Tất cả các nhóm Agile phải xác lập những gì họ muốn nói là “phần mềm chạy tốt”, cái thường được biết như là Định nghĩa Hoàn thành. Ở mức độ cao, một phần của chức năng hoàn thành chỉ khi các tính năng của chúng vượt qua tất cả các kiểm thử và có thể được vận hành bởi người dùng cuối. Ở mức thấp nhất, các nhóm phải vượt qua được kiểm thử đơn vị (unit test) và kiểm thử hệ thống. Các nhóm tốt nhất còn bao gồm việc kiểm thử tích hợp, kiểm thử hiệu năng, và kiểm thử chấp nhận của khách hàng trong định nghĩa hoàn thành đối với một phần chức năng. Thông qua nguồn dữ liệu phong phú từ các dự án, một công ty CMMI cấp độ 5 cho thấy việc xác định kiểm thử chấp nhận cùng với các tính năng, triển khai một loạt các tính năng và theo độ ưu tiên, ngay lập tức chạy các kiểm thử chấp nhận với mỗi tính năng, và sửa bất cứ một lỗi nào có độ ưu tiên cao nhất sẽ tăng gấp đôi tốc độ sản xuất và giảm các sai sót đến 40%. Điều này có được từ một công ty có tỉ lệ sai sót thấp nhất thế giới. Tuyên ngôn Agile khuyến nghị các nhóm cung cấp phần mềm chạy tốt sau một khoảng thời gian nhất định. Đồng thuận với Định nghĩa Hoàn thành là một trong những cách thực tế để nhóm Agile mang lại hiệu suất và chất lượng cao, cái cần thiết để hoàn thành mục tiêu này. 10 Cộng tác với khách hàng Trong hai thập kӹ qua, tỉ lệ thành công của các dự án tăng hơn hai lần trên toàn thế giới. Điều này được cho là vì các dự án nhỏ hơn và mức độ chuyển giao thường xuyên đã cho phép khách hàng cung cấp các thông tin phản hồi về phần mềm hoạt động một cách đều đặn hơn. Các tác giả của bản Tuyên ngôn Agile đã làm sáng tỏ điều này khi họ nhấn mạnh rằng việc khách hàng tham gia vào quá trình phát triển phần mềm là hết sức cần thiết để dẫn tới thành công. Các phương pháp phát triển linh hoạt đã thúc đẩy giá trị này bằng cách đưa vào một đồng minh tích cực của khách hàng làm việc sát cánh với đội phát triển. Ví dụ, một nhóm Scrum đầu tiên có hàng ngàn khách hàng. Sẽ là không khả thi nếu cho phép tất cả khách hàng tham gia vào quá trình phát triển sản phẩm, vì vậy họ chọn ra một vị đại sứ của khách hàng, được gọi là Product Owner (chủ sản phẩm), để đại diện cho không chỉ tất cả khách hàng trong trường hợp này mà còn bao gồm cả quản lí, dịch vụ khách hàng, và các bên liên quan khác. Product Owner có trách nhiệm cập nhật danh sách yêu cầu về sản phẩm sau mỗi bốn tuần thời điểm mà nhóm Scrum phát hành phiên bản sản phẩm chạy tốt, có tính đến yếu tố thực tế cùng phản hồi của khách hàng và các bên liên quan. Điều này cho phép khách hàng có thể định hình sản phẩm phần mềm đang được tạo ra. Một nhóm XP đầu tiên đã bắt đầu với một dự án CNTT nội bộ. Họ có thể có sẵn người sử dụng đầu cuối của công ty trong nhóm làm việc với họ hằng ngày. Sử dụng khoảng 10% thời gian, các tư vấn viên và nhóm nội bộ có thể tìm được một người dùng cuối có thể làm việc với nhóm từng ngày. 90% thời gian còn lại, họ phải cử ra người đại diện cho khách hàng. Người này, được nhóm XP gọi là Customer (khách hàng), làm việc trực tiếp với người dùng cuối để cung cấp một danh sách các tính năng rõ ràng cùng độ ưu tiên cho phép đội phát triển có thể thực hiện. Cộng tác với khách hàng (hoặc đại diện của khách hàng) trên cơ sở hằng ngày là một trong những lý do lý giải tại sao các dữ liệu trong ngành công nghiệp cho thấy rằng các dự án linh hoạt có tỉ lệ thành công cao hơn gấp đôi so với các dự án truyền thống tính trung bình trên toàn thế giới. Các phương pháp phát triển linh hoạt đã nhận ra điều đó, và do vậy, chúng đã tạo ra một vị trí đặc biệt trong đội hình phát triển dành riêng cho vị khách hàng đại diện này. Phản hồi với thay đổi Phản hồi với thay đổi là điều cần thiết cho việc tạo ra một sản phẩm làm hài lòng khách hàng cũng như mang lại những giá trị kinh doanh. Dữ liệu ngành công nghiệp cho thấy hơn 60% các yêu cầu về sản phẩm hay dự án bị thay đổi suốt quá trình phát triển phần mềm. Ngay cả khi các dự án truyền thống kết thúc đúng thời gian, trong giới hạn kinh phí, với tất cả các tính năng theo kế hoạch, nhưng khách hàng thường không hài lòng vì những gì họ thấy không thật sự đúng như những gì họ muốn. Luật Humphrey nói rằng khách hàng không bao giờ biết những gì họ muốn cho đến khi họ thấy phần mềm hoạt động. Nếu khách hàng không nhìn thấy phần mềm hoạt động cho đến khi kết thúc dự án, sẽ là quá muộn cho việc kết hợp các thông tin phản hồi của họ ở thời điểm này. Các phương pháp phát triển linh hoạt tìm kiếm sự phản hồi của khách hàng trong suốt dự án để có thể kết hợp thông tin phản hồi và thông tin mới ngay khi sản phẩm đang được phát triển. 11 Tất cả các phương pháp phát triển linh hoạt đều được tích hợp sẵn những tiến trình thay đổi các kế hoạch trong một khoảng thời gian đều đặn dựa trên những thông tin phản hồi từ phía khách hàng cũng như bên đại diện của khách hàng. Các kế hoạch được thiết kế để sao cho luôn cung cấp giá trị kinh doanh cao nhất trước hết. Bởi vì 80% giá trị nằm trong 20% các tính năng, một dự án phát triển linh hoạt chạy tốt có xu hướng kết thúc sớm, trong khi hầu hết các dự án truyền thống thường kết thúc trễ. Kết quả là, khách hàng thì vui vẻ hơn, và các nhà phát triển thì thích thú với công việc của họ hơn. Các phương pháp phát triển linh hoạt dựa trên những hiểu biết đó, để thành công hơn chúng phải có kế hoạch để thay đổi. Đó là lý do tại sao chúng thiết lập các quy trình, chẳng hạn như Sơ kết và Cải tiến, được thiết kế đặc biệt để thay đổi các ưu tiên thường xuyên dựa trên thông tin phản hồi của khách hàng và giá trị kinh doanh. 12 ⇒ Dừng và Nghĩ Bạn có đồng tình với các điểm chính của Tuyên ngôn Agile không? Bạn có muốn bổ sung gì thêm không? 13 Agile chỉ là tập hợp những giá trị được nêu trong Tuyên ngôn Phát triển Phần mềm Linh hoạt (gọi tắt là Tuyên ngôn Agile). Có rất nhiều phương pháp chia sẻ những giá trị của Tuyên ngôn Agile, chúng đều được gọi là phương pháp Agile Scrum là một trong số các phương pháp Agile phổ biến. Các phương pháp Agile và mức độ phổ biến Có rất nhiều phương pháp Agile khác nhau và những biến thể từ sự kết hợp giữa các phương pháp Agile ban đầu. Theo khảo sát của VersionOne năm 2015, Scrum là phương pháp phổ biến nhất. Scrum và các phương pháp lai với Scrum như Scrumban, Scrum và XP chiếm gần ¾ mức độ phổ biến. 15 Đặc trưng quan trọng của Agile: Tiếp cận tăng trưởng lặp Nhóm Phát triển sẽ hoàn thành một tập những tính năng ở phần trên của Product Backlog trong một khoảng thời gian đóng khung (Sprint) tạo ra một phần tăng trưởng cho khách hàng. Khách hàng sẽ nhận được phần tăng trưởng cuối mỗi Sprint. Sản phẩm sẽ tăng trưởng dần cùng với thời gian, tuy nhiên tại bất cứ thời điểm nào họ cũng có phần mềm chạy tốt. 16 Yêu cầu sản phẩm được sắp xếp theo đội ưu tiên. Những hạng mục đem lại nhiều giá trị trên vốn đầu tư (ROI) sẽ ở trên. Product Backlog chứa các yêu cầu về sản phẩm được cập nhật liên tục để thích ứng với những phản hồi với những thay đổi cần thiết. Cách tiếp cận này, cùng với bộ nguyên lí Agile có thể giúp đội phát triển và nhà quản trị dự án vượt qua được hầu hết những vấn đề được nhắc tới trong phần đầu của chương này. Trước Agile, phần mềm cơ bản được phát triển theo mô hình thác nước (Waterfall), hoặc dựa theo kế hoạch (plan-driven) 17 Các công việc được làm một cách tuần tự phụ thuộc rất nhiều vào những điều đã được tiên lượng trước đó. Mô hình này sẽ phát huy tác dụng nếu như chúng ta có thể xác định được chính xác yêu cầu khác hàng ngay từ đầu, có khả năng tiên lượng được công việc tương lai và không có thay đổi nào về công nghệ, môi trường kinh doanh, con người, v.v., điều rất hiếm gặp trong thế giới công nghệ ngày nay. À À Ô KHI NÀO AGILE, KHI NÀO KHÔNG Các dự án có quy mô, đặc thù và độ phức tạp không giống nhau, do vậy chúng ta cần phải có những phương pháp phát triển phù hợp. Để xác định được khi nào thì ra quyết định kiểu gì, làm việc như thế nào, chúng ta có thể sử dụng Mô hình Cynefin cho việc phân loại tình huống và dự án, rồi ra các quyết định quan trọng. Theo đó có các vùng chính mô tả các đặc trưng khác nhau bao gồm Hiển nhiên, Rắm rối, Phức hợp, Hỗn độn. Bảng sau đây liệt kê các đặc tính từng vùng và vai trò của người ra quyết định. img360 Mô hình Cynefin cho việc ra quyết định chiến lược Đối với các dự án phát triển sản phẩm mới, thông thường chúng rơi vào vùng Phức hợp. Đó là khu vực mà phương pháp truyền thống sẽ gặp khó khăn, và cách tiếp cận Agile sẽ phù hợp hơn. 18 NHỮNG CÂU HỎI THƯỜNG GẶP Agile là gì? Phát triển Linh hoạt (Agile Development, gọi tắt là Agile) là một thuật ngữ có nguồn gốc từ Tuyên Ngôn Phát triển Phần mềm Linh hoạt (The Manifesto for Agile Software Development). Tuyên ngôn này được soạn thảo năm 2001 bởi một nhóm các tác giả, chuyên gia của các phương pháp phát triển phần mềm Scrum, Extreme Programming (XP), DSDM (Dynamic Systems Development Method), Crystal, FDD (Feature-Driven Development), và một vài nhà lãnh đạo khác. Tuyên ngôn Agile đã tổng kết ra một số giá trị và nguyên tắc chung, phổ quát cho tất cả các phương pháp luận về linh hoạt đang tồn tại độc lập tại thời điểm đó. Khi dùng chữ “agile” với tư cách là một tính từ, thì nó mang nghĩa là “linh hoạt”. Nhưng khi ta dùng chữ Agile (A viết hoa), tức là chỉ triết lí và tất cả những phương pháp phát triển phần mềm, phát triển sản phẩm và quản lí dựa trên triết lí được mô tả trong Tuyên ngôn Agile. Agile là triết lí đã làm thay đổi diện mạo nền công nghệ thế giới trong những thập kỉ đầu thế kỉ XXI. Các phương pháp Agile đã được thực tế chứng minh là công cụ mạnh của các cá nhân, tổ chức trong việc đổi mới, sáng tạo, làm nên những sản phẩm chất lượng cao, đột phá, cũng như gia tăng hiệu quả hoạt động và năng lực cạnh tranh, phát triển văn hóa tổ chức. Những nghiên cứu thực nghiệm và thống kê từ ngành công nghiệp phần mềm cho thấy Agile có thể giúp cho các doanh nghiệp gia tăng năng suất và hiệu quả lên gấp nhiều lần, nâng tỉ lệ thành công của dự án lên gấp đôi và gia tăng năng lực cạnh tranh bền vững cho các doanh nghiệp. Cùng với Tư duy Tinh gọn (Lean Thinking), Khởi nghiệp Tinh gọn (Lean Startup), và Tư duy Thiết kế (Design Thinking), Agile vẫn đang tiếp tục tạo nên những làn sóng đổi thay lớn trên thế giới. Scrum có phải là Agile không? Scrum là một phương pháp Agile (phổ biến nhất) nhưng không phải là Agile. Agile định nghĩa các giá trị cốt lõi và nguyên tắc định hướng, còn Scrum là một phương pháp cụ thể chia sẻ các nguyên tắc đó. Vậy Scrum là gì? Tài liệu Hướng dẫn Scrum định nghĩa “Scrum là một khung làm việc để phát triển bền vững các sản phẩm phức tạp”. Có thể hiểu đây là khung tổ chức công việc tổng quát hướng đến phát triển các sản phẩm phức tạp, chủ yếu là phần mềm. Ngày nay Scrum có thể được dùng như là nền tảng tổ chức các công việc khác nhau, từ quản trị dự án linh hoạt nói chung, đến phát triển sản phẩm, thực hiện các chiến dịch marketing, tổ chức dạy học, sản xuất ô tô module hóa hoặc những công việc cá nhân khác. Dựa trên lý thuyết quản lí thực nghiệm (empirical process control), Scrum sử dụng cơ chế lặp (iterative) và tăng trưởng (incremental) để tối ưu hóa tính hiệu quả và kiểm soát rủi ro. Scrum rất đơn giản, dễ học và có khả năng ứng dụng rất rộng. Để có thể dùng Scrum, chúng ta cần hiểu rõ và vận dụng đúng các thành tố tạo nên Scrum bao gồm các giá trị cốt lõi (còn gọi là “ba chân”, hay ba trụ cột của Scrum), các vai trò, các sự kiện, các tạo tác (artifact) và những quy tắc đặc thù của Scrum. Hiện nay, định nghĩa Scrum là gì được ghi trong tài liệu Scrum Guide (Hướng dẫn Scrum) và được cập nhật thường xuyên bởi chính các tác giả tại http://scrumguides.org. Toàn bộ cuốn sách này sẽ là về Scrum. Hãy đọc tiếp các chương sau. Tại sao chọn Agile? Trong nền kinh tế sáng tạo đầy biến động hiện nay, yêu cầu cấp thiết đối với các cá nhân hay tổ chức là phải đạt được năng lực linh hoạt (Agility) cao độ để thích ứng và dẫn đầu trong các cuộc cạnh tranh. Agile là nền tảng để đạt được Agility và duy trì lợi thế cạnh tranh bền vững. Triết lí Agile cùng với các framework, phương pháp cũng như các công cụ đặc thù có thể giúp các cá nhân, đội nhóm và doanh nghiệp trở nên hiệu quả hơn, năng suất hơn và đổi mới-sáng tạo tốt hơn. Muốn triển khai Agile thì bắt đầu từ đâu? Các cá nhân có thể bắt đầu với việc áp dụng những kĩ thuật cơ bản của Personal Kanban cùng với tư duy Agile để nâng cao năng suất cá nhân, làm việc hiệu quả, kiểm soát tốt stress. Các lập trình viên có thể bắt tay với những kĩ thuật lập trình Agile cơ bản như TDD, Pair-Programming để nâng cao chất lượng phần mềm trước khi đi xa hơn với đầy đủ bộ kĩ năng để trở thành Nghệ nhân Phần mềm (Software Craftsman) đích thực. Các nhóm có thể ứng dụng Scrum để tổ chức lại công việc, nâng cao hiệu quả giao tiếp và hiệu suất nhóm. Các công ty có thể bắt đầu với việc tái tổ chức công việc và quy trình nghiệp vụ với Scrum, Lean để giảm thiểu lãng phí, nâng cao hiệu quả hoạt động, tối ưu hóa nguồn lực và gia tăng năng lực cạnh tranh bền vững. Triển khai Agile có tốn kém không? Có đòi hỏi điều kiện gì đặc biệt về trình độ không? Phụ thuộc vào nguồn lực chúng ta có, việc thực hành Agile có thể đơn giản là sắp xếp lại công việc mà không cần thêm chi phí. Đối với các chương trình chuyển đổi căn bản và toàn diện, sự đầu tư có thể sẽ phải tương xứng với mục tiêu do tổ chức đề ra. Có bộ công cụ hay phần mềm nào để thực hành Agile? Agile quy trình tư duy, trong khi phương pháp sẽ định hình cách triển khai cụ thể, và các công cụ sẽ trợ giúp một phần nào đó. Công cụ và quy trình cần được lựa chọn kĩ để phục vụ các cá nhân làm việc hiệu quả và tương tác nhóm tốt hơn, không nên là lựa chọn để “đánh dấu” rằng “tôi đã sử dụng Agile”. Các nhóm Scrum nhỏ, làm việc tập trung có thể chỉ cần các đồ chi phí thấp để có thể vận hành tốt Scrum: bảng trắng, giấy dán, bút viết bảng. Chúng ta cũng có thể sử dụng hàng loạt các hệ thống phần mềm, cloud hỗ trợ tương tác nhóm theo triết lí Agile như Trello, Asana, Jira, TFS. Chúng có thể miễn phí hoặc tính phí tùy nhu cầu sử dụng của mỗi nhóm và tổ chức. Đối với các tổ chức lớn, việc đầu tư cho các công cụ để gia tăng hiệu quả tổng thể luôn là một trong những ưu tiên trong danh mục đầu tư cho công nghệ để phát triển. CÂU HỎI ỨNG DỤNG 1. Tuyên ngôn Agile giúp bạn nhận ra giá trị gì cho mình? 2. Có người diễn dịch ý thứ hai trong Tuyên ngôn Agile là “phần mềm chạy tốt thay vì tài liệu đầy đủ”, theo bạn diễn dịch như vậy có gì không đúng? Tại sao? 3. Nhiều người cho rằng Tuyên ngôn Agile có 5 điều, theo bạn điều thứ 5 của bản tuyên ngôn này là gì? 4. Căn cứ vào đâu để nói rằng một phương pháp phát triển phần mềm là Agile? 5. Bạn nhận định xem những lý do nào khiến các phương pháp phát triển phần mềm truyền thống không còn phù hợp với thực tế? 6. Phân loại dự án của bạn theo mô hình Cynefin? 7. Tại sao cách thức phát triển lặp (iterative) và tăng trưởng (incremental) lại giúp các phương pháp Agile thích ứng với những thay đổi từ khách hàng, môi trường kinh doanh, công nghệ, v.v.? 8. Bạn sẽ giải thích như thế nào với đồng nghiệp cho rằng làm Agile là không cần có kế hoạch? 9. Khi thực hiện một dự án cụ thể của bạn thì cần tạo bao nhiêu tài liệu là đủ? 10. Hãy phân tích những yếu tố công cụ, quy trình nào đang cản trở động lực làm việc của cá nhân và sự cộng tác trong nhóm/tổ chức của bạn? 2KHÁI LƯỢC SCRUM Trong chương này... • Định nghĩa Scrum • Lịch sử Scrum • Tổng quan khung làm việc Scrum • Các ứng dụng của Scrum • Tại sao dùng Scrum? • Sprint • Gói tăng trưởng Năng suất không phải là tất cả, nhưng về lâu dài thì nó hầu như là tất cả. Paul Krugman - Nobel kinh tế 2008 SCRUM LÀ GÌ ? Đôi khi được gọi là một phương pháp Agile, Scrum là khung làm việc linh hoạt được sử dụng phổ biến nhất đến nỗi nhiều người lầm tưởng Agile chính là Scrum hay Scrum chính là Agile. Nhưng Scrum chỉ là một trong số hơn chục phương pháp cụ thể chia sẻ các giá trị được phát biểu trong Tuyên ngôn Agile. Theo tài liệu Hướng dẫn Scrum, Scrum là khung làm việc (frame work) để phát triển sản phẩm hoặc quản lí các dự án phức tạp theo cách thức lặp (iterative) và tăng trưởng (incremental). Quá trình phát triển được thực hiện thông qua các phân đoạn nối tiếp nhau. Khung làm việc Scrum bao gồm các giá trị cốt lõi, vai trò, sự kiện, tạo tác và các quy tắc để gắn kết tất cả thành một thể thống nhất. Scrum là khung làm việc linh hoạt, “dễ hiểu nhưng khó tinh thông”. Một số hiểu lầm Scrum là một bộ công cụ hay biện pháp thực hành nên cho rằng mình cứ có Sprint Backlog hay thực hiện Scrum Hằng ngày thì gọi là Scrum. Một hiểu lầm khác, Scrum là phép thần để giải quyết tất cả các vấn đề của tổ chức hay dự án. Để sử dụng Scrum cần sự thay đổi sâu sắc trong cách nghĩ, cách làm chứ không dừng lại ở việc có một số công cụ hay thực hiện một số sự kiện. Chương này sẽ tìm hiểu toàn cảnh khung làm việc Scrum. Riêng chương 6 sẽ thảo luận cách đưa Scrum vào tổ chức. img377 Scrum – một cách diễn giải khác Trong một bài viết năm 2011, Denning tóm tắt 10 đặc điểm của Scrum: 1. Tổ chức công việc theo các chu trình ngắn (gọi là phân đoạn) 2. Khi nhóm làm việc trong các chu trình ngắn này, cấp quản lí không can thiệp (tức nhóm được trao quyền tối đa) 3. Nhóm báo cáo trực tiếp cho khách hàng, không phải cho nhà quản lí 4. Nhóm ước tính thời gian để hoàn thành công việc 5. Nhóm quyết định khối lượng công việc để làm trong phân đoạn 6. Nhóm quyết định cách hoàn thành công việc trong phân đoạn 7. Nhóm tự đánh giá hiệu suất của mình 8. Xác định mục đích của phân đoạn trước khi bắt đầu 9. Xác định mục tiêu thông qua các câu chuyện người dùng (user stories) 10. Loại bỏ các trở ngại cho công việc một cách có hệ thống Theo: Steve Denning (2011). Scrum is a major manage- ment discovery, Forbes. Lịch sử Scrum Takeuchi và Nonaka là những người có ảnh hưởng rất lớn tới sự ra đời của Scrum với bài viết “The New New Product De- velopment Game” trên Harvard Business Review năm 1986. Jeff Sutherland lần đầu giới thiệu Scrum tại công ty Easel vào năm 1993. Ken Schwaber cùng Jeff Sutherland thuyết trình về Scrum tại sự kiện OOPSLA năm 1995. Năm 2001: Tuyên ngôn Phát triển Phần mềm Linh hoạt và Liên minh Agile (Agile Alliance) ra đời. Năm 2002: Liên minh Scrum (Scrum Alliance) được thành lập. Ken Schwaber và Jeff Sutherland cùng xây dựng định nghĩa Scrum tại ScrumGuides.org với phiên bản đầu năm 2010. img382 img383 Scrum được dùng để làm gì? Nhiều báo cáo cho thấy Scrum được sử dụng rộng rãi, không chỉ trong lĩnh vực phát triển phần mềm, mà còn loang ra cả những dự án sản xuất phần cứng, các đội nhóm marketing hay giáo dục. • Phát triển phần mềm thương mại • Phát triển ứng dụng nội bộ • Phát triển theo đơn đặt hàng • Các dự án mà giá đã được chốt • Các ứng dụng tài chính • Các ứng dụng tuân thủ chuẩn ISO 9001 • Các hệ thống nhúng • Các hệ thống hoạt động 24x7 với yêu cầu 99,999% thời gian hoạt động. • Hệ thống điều khiển máy bay Joint Strike Fighter • Phát triển video game • Phần mềm Điều khiển-Vệ tinh • Làm ra các Website • Phần mềm cho thiết bị cầm tay • Điện thoại di động • Các ứng dụng chuyển mạng • Các dự án học tập • Các chiến dịch marketing • Quản lí các sự kiện công nghệ • Sản xuất ô tô • Quản lí lớp học hiện đại (eduScrum) • Và nhiều nữa img385 Một cuộc họp DailyScrum ở Microsoft, <ảnh Wikipedia> img389 Đội wikispeed sử dụng Scrum để cộng tác và sản xuất ô tô. <ảnh: wikispeed> img387 Một lớp học dùng eduScrum ở Hà Lan, <ảnh eduScrum.nl> LỢI ÍCH KHI DÙNG SCRUM 19 Với phương pháp truyền thống, phải đến giai đoạn cuối mới thấy được sản phẩm, còn trước đó không có sản phẩm thật. Từ khi bắt đầu phát triển tính trực quan ngày càng giảm. Với Scrum, ngay từ đầu chúng ta đã chuyển giao những phần tăng trưởng hoạt động tốt của sản phẩm và việc chuyển giao là liên tục và đều đặn, độ trực quan được duy trì ở mức cao. Với phương pháp truyền thống, khách hàng phải đợi đến cuối để bắt đầu nhận được giá trị từ sản phẩm bởi việc dành nhiều thời gian để lập kế hoạch và thi công dự án mà không đưa ra được một sản phẩm thực sự. Do đó giá trị họ nhận được ban đầu là rất thấp. Ngược lại, Scrum tập trung chuyển giao các tính năng hoàn chỉnh của sản phẩm ngay từ đầu. Do đó, ngay trong giai đoạn sản xuất, khách hàng đã nhận được các giá trị. Những giá trị này ngày càng được tích lũy và lớn dần lên theo tiến độ dự án. Ở phương pháp quản lí truyền thống, chúng ta đặt cược vào độ chính xác của kế hoạch ban đầu mặc dù khi đó chúng ta có nhiều giả định như con người, công nghệ, môi trường kinh doanh không thay đổi hoặc chúng ta biết đủ những yếu tố này, do đó rủi ro là rất cao cho tới khi kết thúc. Đối với Scrum, mức độ rủi ro giảm rất nhanh theo cấp số mũ. Chìa khóa ở đây chính là làm việc lặp và tăng trưởng cùng với sự thanh tra và thích nghi liên tục. Những yếu tố tiềm ẩn rủi ro liên quan đến sản phẩm, công nghệ, con người, v.v., đều được phát hiện và điều chỉnh từ sớm. 20 Các phương pháp truyền thống không sẵn sàng cho việc thay đổi bởi, chúng ta phải chuẩn bị một kế hoạch chi tiết và cụ thể từ giai đoạn đầu, sau đó phải bám sát từng kế hoạch. Chi phí cho sự thay đổi là rất lớn, đặc biệt ở giai đoạn sau. Ngược lại, Scrum luôn chủ động đón nhận thay đổi. Chúng ta không dành nhiều công sức để lập kế hoạch cho những giả định mà luôn chuẩn bị cho mọi sự phía trước, do đó chi phí cho thay đổi thấp hơn. Những lợi ích khác... Mọi hoạt động đều hướng giá trị (Value-Oriented) do đó Scrum giúp chúng ta tối ưu hóa giá trị trên vốn đầu tư (ROI). Định hướng khách hàng (Customer-Centric): tăng độ hài lòng của khách hàng bởi tất cả những gì chúng ta làm là để phục vụ khách hàng. Giảm thiểu các “nợ kĩ thuật” bởi cách làm là luôn hoàn thành mọi thứ với chất lượng đảm bảo và linh hoạt cao để chấp nhận sự thay đổi. Bởi thế khi phát triển, các lập trình viên cần sử dụng các phương pháp để tăng khả năng linh hoạt như mã sạch, v.v.. Chất lượng sản phẩm cao. Nhóm luôn bàn giao sản phẩm hoàn thành và thực hiện việc thanh tra, nên nếu có những vấn đề chất lượng thì nó sẽ được phát hiện và nhóm sẽ thích nghi để đưa mọi thứ trở về tiêu chuẩn. Giảm thiểu rủi ro khi ứng dụng gặp vấn đề. Việc bàn giao sản phẩm sớm, khách hàng có thể xem và sử dụng sản phẩm, nên việc phát hiện các rủi ro sớm hơn. Thậm chí khi ứng dụng gặp vấn đề thì nhóm nhanh chóng có thể thích nghi. Tăng năng suất và hiệu quả lao động. Scrum giúp nhóm liên tục phát hiện ra những tính năng đem lại giá trị trên vốn đầu tư cao, hoàn thành những tính năng có chất lượng và tốc độ cao hơn như trình bày ở Chương 1. Phát triển bền vững cá nhân và đội nhóm. Việc nhóm được tự tổ chức giúp họ có cơ hội làm việc cùng với nhau, qua đó mỗi cá nhân trưởng thành hơn ở rất nhiều yếu tố như tính chủ động hơn, cam kết hơn, động lực, tri thức và kĩ năng phát triển sản phẩm. Tri thức trong nhóm được lan tỏa giữa các thành viên, do đó bản thân nhóm cũng phát triển. KHUNG LÀM VIỆC SCRUM Khung làm việc Scrum gồm các vai trò của Nhóm Scrum, các Tạo tác (Artifact) được làm ra, các Sự kiện Scrum, cùng với các quy tắc ràng buộc cách thức làm việc. Tất cả chúng được xây dựng dựa trên một hệ giá trị nhất quán với các giá trị Agile và các giá trị cốt lõi của Scrum. Vai trò Định ra trách nhiệm của từng thành viên trong nhóm Scrum tự tổ chức • Product Owner • ScrumMaster • Nhóm Phát triển Tạo tác Các công cụ hoặc sản phẩm do nhóm Scrum làm ra • Gói tăng trưởng • Product Backlog • Sprint Backlog Sự kiện Các cuộc họp và cơ chế cộng tác có cấu trúc để cộng tác hiệu quả hướng đến mục tiêu chung • Sprint • Lập kế hoạch Sprint • Scrum Hằng ngày • Sơ kết Sprint • Cải tiến Sprint Ba trụ cột: Thanh tra – Minh bạch - Thích nghi Năm giá trị: Dũng cảm, Tập trung, Cam kết, Cởi mở, Tôn trọng SCRUM - Một mô tả tổng quát Giả sử bạn đang là thành viên của một nhóm Scrum. Sáng thứ Hai, bạn sẽ cùng nhóm làm việc ngồi với nhau, họp lập kế hoạch để quyết định cả đội sẽ làm gì trong tuần và làm như thế nào. Sau đó các công việc được chia nhỏ ra thành công việc cụ thể mà ai cũng hiểu được, dán lên bảng công việc chung. Hằng ngày từ thứ Ba đến thứ Năm, bạn sẽ tự lựa chọn việc làm phù hợp rồi bắt tay thực hiện. Vào đầu giờ sáng, trước khi làm việc, bạn cùng cả nhóm đứng trước bảng công việc chung, rà soát lại tiến độ của từng người, thông báo về một số khó khăn gặp phải trong khi làm việc. Cuộc họp đứng đó diễn ra hằng ngày, trong vòng 15 phút. Cuối mỗi ngày, bạn cố gắng hoàn thành thật tốt những việc đã lựa chọn. Vào chiều thứ 6, cả đội ngồi rà soát lại công việc xem kế hoạch đề ra từ đầu tuần có được hoàn tất không. Ngay sau đó, cả đội ngồi với nhau để đề ra cải tiến cách làm việc cho tuần sau để hiệu quả và vui vẻ hơn. Tuần sau cả nhóm lặp lại nhịp làm việc như vậy, nhưng với lưu ý về một số cải tiến sẽ được mọi người tuân thủ. Đó là hình dung đơn giản về một nhịp làm việc của một nhóm Scrum nhỏ suốt một tuần. Trong mô tả trên, Nhóm Scrum đóng khung hoạt động của mình trong vòng 1 tuần, Scrum gọi khung thời gian này là Sprint. Buổi họp kế hoạch đầu tuần được gọi là buổi Lập kế hoạch Sprint. Buổi rà soát thành quả công việc vào thứ Sáu gọi là hoạt động Sơ kết Sprint. Hoạt động họp để tìm kiếm cách làm việc tốt hơn được gọi là họp Cải tiến Sprint. Buổi họp đứng kéo dài 15 phút mỗi ngày được gọi là Scrum Hằng ngày. Bảng công việc chứa những việc cần làm cho một tuần đó được gọi là Sprint Backlog. Trong Nhóm Scrum kia còn có các thành viên giữ các vai trò khác nhau: một Product Owner chịu trách nhiệm quản lí danh sách những yêu cầu công việc (được gọi là Product Backlog), một ScrumMaster chịu trách nhiệm tổ chức cách thức làm việc theo Scrum cho cả nhóm, và một Nhóm Phát triển gồm những người có đủ chuyên môn để hoàn thành mục tiêu mà cả nhóm đề ra. Trên đây là cách chúng ta hình dung đơn giản hoá về một nhóm làm việc theo Scrum trong vòng một tuần. Ở mức độ tổng quan, chúng ta thấy nhịp làm việc này rất gần gũi với cách làm việc của những nhóm làm việc gắn kết và chuyên nghiệp. Nói theo cách của Scrum, chúng ta sẽ có một mô tả khác về cách một nhóm Scrum làm việc như dưới đây. Product Owner tạo ra Product Backlog chứa các yêu cầu của dự án với các hạng mục được sắp theo thứ tự ưu tiên. Đội sản xuất sẽ hiện thực hóa dần các yêu cầu của Product Owner với sự lặp đi lặp lại các giai đoạn nước rút từ 1 đến 4 tuần làm việc (gọi là Sprint) với đầu vào là các hạng mục trong Product Backlog, đầu ra là các gói phần mềm hoàn chỉnh có thể chuyển giao được (Potentially Shippable Product Increment). Trước khi cả nhóm cùng đua nước rút trong Sprint, đội sản xuất cùng họp với Product Owner để lập kế hoạch cho từng Sprint. Kết quả của buổi lập kế hoạch (theo cách làm của Scrum) là Sprint Backlog chứa các công việc cần làm trong suốt một Sprint. Trong quá trình phát triển, nhóm sẽ phải cập nhật Sprint Backlog và họp hằng ngày (Daily Scrum) để chia sẻ tiến độ công việc, tái lập kế hoạch cũng như các vướng mắc trong quá trình làm việc cùng nhau. Nhóm được trao quyền tự quản lí và tổ chức lấy công việc của mình để hoàn thành công việc trong Sprint. Khi kết thúc Sprint, nhóm tạo ra gói phần mềm có chức năng hoàn chỉnh, sẵn sàng chuyển giao (shippable) cho khách hàng. Buổi họp Sơ kết Sprint (Sprint Review) ở cuối Sprint sẽ giúp khách hàng thấy được nhóm đã có thể chuyển giao những gì, còn những gì phải làm hoặc còn gì phải thay đổi hay cải tiến. Sau khi kết thúc việc đánh giá Sprint, ScrumMaster và Nhóm Phát triển cùng tổ chức họp Cải tiến Sprint (Sprint Retro- spective) để tìm kiếm các cải tiến trước khi Sprint tiếp theo bắt đầu. Điều này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua từng Sprint. Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong Product Backlog đều được hoàn tất hoặc khi Product Owner quyết định có thể dừng dự án căn cứ tình hình thực tế. Do sử dụng chiến thuật “có giá trị hơn làm trước” nên các hạng mục mang lại nhiều giá trị hơn cho chủ dự án luôn được hoàn tất trước. Vì vậy Scrum luôn mang lại giá trị cao nhất cho người đầu tư cho dự án. Do quy trình luôn luôn được cải tiến, nhóm Scrum thường có năng suất lao động rất cao. Đây là hai lợi ích to lớn mà Scrum mang lại cho tổ chức. 21 BA TRỤ CỘT CỦA SCRUM Minh bạch (transparency) Muốn thành công với Scrum, thông tin liên quan tới quá trình phát triển phải minh bạch và thông suốt. Các thông tin đó có thể là: tầm nhìn (vision) về sản phẩm, yêu cầu khách hàng, tiến độ công việc, các khúc mắc và rào cản v.v.. Từ đó mọi người ở các vai trò khác nhau có đủ thông tin cần thiết để tiến hành các quyết định có giá trị để nâng cao hiệu quả công việc. Các công cụ và cuộc họp trong Scrum luôn đảm bảo thông tin được minh bạch cho các bên. Thanh tra (inspection) Công tác thanh tra liên tục các hoạt động trong Scrum đảm bảo cho việc phát lộ các vấn đề cũng như giải pháp để thông tin đa dạng và hữu ích đến được với các bên tham gia dự án. Truy xét kĩ càng và liên tục là cơ chế khởi đầu cho việc thích nghi và các cải tiến liên tục trong Scrum. Thích nghi (adaptation) Dựa trên các thông tin minh bạch hóa từ các quá trình thanh tra và làm việc, Scrum có thể phản hồi các thay đổi một cách tích cực, nhờ đó mang lại thành công cho dự án. Các nỗ lực minh bạch và thanh tra đều để hướng tới hành động thích ứng nhanh chóng, hiệu quả. NĂM GIÁ TRỊ CỦA SCRUM GIÁ TRỊ SCRUM Dũng cảm ⇒ Để một người dám nói vấn đề của mình và chấp nhận rất nhiều loại rủi ro khi thay đổi, cam kết, họ cần là người dũng cảm. Về cơ bản, những giá trị khác không thể có nếu bạn không có sự dũng cảm. Tập trung ⇒ Mọi người tập trung vào công việc trong Sprint & Mục tiêu Sprint của Nhóm. Khi nhóm Phát triển đã cam kết với những việc trong Sprint, họ cần phải tập trung để hoàn thành những gì mà mình đã cam kết. Cam kết ⇒ Mỗi thành viên cam kết với các thành viên khác về những điều mình làm ông việc đã được chọn ở buổi Lập kế hoạch Sprint. Ngoài ra, chúng ta liên tục cải tiến tức là thay đổi để trở thành một cá nhân tốt hơn, nhóm tốt hơn và tổ chức tốt hơn. Chúng ta luôn phải thay để giữ vững lợi thế cạnh tranh và phục vụ khách hàng. Thực hiện thay bao giờ cũng rất khó khăn, do đó chỉ với sự cam kết chúng ta mới có làm được. Cởi mở ⇒ Mọi thư cần phải rõ ràng, minh bạch để mọi người có thể làm việc hiệu quả. Phát mềm rất phức tạp, một người không thể nhìn và hiểu được hết tất cả mọi vấn đề. Do đó nếu mọi người không cởi mở với nhau, thông tin bị che giấu rất ệu quả công việc khó lòng có thể nâng cao. Tôn trọng ⇒ Khi thiếu tôn trọng, mọi người khó thành thật trong chia sẻ. Ví dụ, khi một người không biết một điều gì đó và đi hỏi người khác. Người trả lời thay vì mong muốn giúp đỡ để người hỏi trở nên tốt hơn, độc lập hơn lại phàn nàn, đánh giá người hỏi thì lần sau người hỏi sẽ khó mà cởi mở và nói sự thật được. Không có tôn trọng, khó có sự cởi mở. Những công ty có văn hóa đổ lỗi khó có sự cởi mở. SPRINT - TRÁI TIM CỦA SCRUM Sprint là phân đoạn ngắn để tạo ra phần chức năng và tính năng hoàn chỉnh. Các Sprint diễn ra nối tiếp nhau. Độ dài của Sprint từ một đến bốn tuần. Giữ độ dài Sprint không đổi để tạo nhịp cho nhóm. Sprint càng ngắn, chi phí quản lí càng lớn. Sprint càng dài càng khó giữ sự tập trung của nhóm cũng như giảm khả năng linh hoạt với sự thay đổi. Mỗi Sprint đều có Mục tiêu Sprint (Sprint Goal) tổng hợp những chức năng và tính năng nhóm cam kết hoàn thành trong Sprint. Sản phẩm được thiết kế, lập trình và kiểm thử trong Sprint. Cùng công việc nhưng được tổ chức khác và với ít yêu cầu hơn. Những lãng phí lớn sẽ bị phát lộ và có thể được xóa bỏ một cách hệ thống. 22 Theo tài liệu thuyết trình “Scrum for Vietnam” của Ken Schwaber, 2012. Các loại phát triển tuần tự và chồng lấp Có nhiều loại phát triển chồng lấp: - Loại A: Các giai đoạn tách biệt. - Loại B: Các giai đoạn có sự chồng lấp nhau, nhưng không hoàn toàn - Loại C: Các giai đoạn hoàn toàn chồng lấp. Mọi việc đều được làm trong một khoảng thời gian ngắn img412 Các loại phát triển tuần tự & chồng lấp ⇒ Dừng và Nghĩ Nhóm của bạn có thể làm việc theo kiểu chồng lấp loại C không? Thử hình dung ai làm gì, như thế nào. Ví dụ về chồng lấp Tất cả thành viên ở các vùng kĩ năng khác nhau đồng thời tham gia vào việc phát triển. img415 Mọi công việc để hoàn thành sản phẩm từ phân tích yêu cầu, viết kiểm thử, thiết kế, lập trình, kiểm thử đơn vị, dựng sản phẩm được thực hiện đồng thời. Đóng khung thời gian cho Sprint Không thay đổi yêu cầu sản phẩm trong trong suốt Sprint nhưng nếu Nhóm Phát triển phát hiện thiếu một công việc để hoàn thành mục tiêu (ví dụ phát sinh bug) thì có thể thêm vào. Nếu một ai đó (ví dụ Product Owner) yêu cầu thay đổi yêu cầu thì Nhóm Phát triển có thể từ chối, ScrumMaster đảm bảo Product Owner không được yêu cầu việc đó với Nhóm Phát triển. Cần tạo không gian tự chủ cho nhóm. Nhóm được quyết định cách làm để hoàn thành công việc. Không ai được yêu cầu Nhóm Phát triển cách làm việc kể cả Scrum- Master. Tránh quản lí vặt (micro-manage). Không trực tiếp giao việc cho thành viên nhóm. Hãy để họ tự quyết định. Nếu khả năng quyết định của họ chưa thực sự tốt, hãy giúp đỡ họ bằng các đưa ra các quy tắc hoặc đào tạo họ. ScrumMaster – “chó chăn cừu”: tức là đảm bảo Nhóm Phát triển tập trung làm việc mà không bị làm phiền. Tránh thay đổi Mục tiêu Sprint, thành viên Nhóm Phát triển, chất lượng mục tiêu, phạm vi của tính năng. Khi có thay đổi rất hệ trọng hoặc bất khả kháng thì có thể hủy Sprint hoặc đàm phán với Product Owner và Nhóm Phát triển. Tuy nhiên nếu việc đó diễn ra liên tục thì vấn đề lớn đang xảy ra. Nhóm Phát triển không thể tập trung để làm việc hiệu quả nhất. Kết quả cuối mỗi Sprint: Gói tăng trưởng Gói tăng trưởng (Increment) là cách gọi tắt của thuật ngữ “gói tăng trưởng có khả năng chuyển giao được”, là tổng tất cả những hạng mục đã hoàn thành của Product Backlog của Sprint và các Sprint trước. Tăng trưởng này phải “hoàn thành” có thể chuyển giao được và thỏa mãn Định nghĩa Hoàn thành mà nhóm Scrum đã thống nhất trước đó. Gói tăng trưởng này phải có khả năng sử dụng được bởi khách hàng chứ không phải là sản phẩm alpha hay bản mẫu. Tuy nhiên việc có chuyển giao cho khách hàng hay không tùy thuộc vào nhiều yếu tố như chiến lược phát hành, kế hoạch kinh doanh, v.v.. Gói tăng trưởng phải được trình diễn ở Sơ kết Sprint. 23 Những lợi ích từ gói tăng trưởng Việc có một phần tăng trưởng chuyển giao được sau một khoảng thời gian ngắn sẽ giúp nhanh chóng có được phản hồi từ người dùng hay khách hàng. Các phản hồi này sẽ được ghi nhận để đưa ra những điều chỉnh cho sản phẩm nếu cần thiết. Ví dụ một ứng dụng dành cho các thiết bị di động, sau một khoảng thời gian ngắn với một lượng tính năng đủ dùng ban đầu thì chúng ta có thể phát hành tới một lượng người dùng nhất định. Sau đó, chúng ta sẽ lần lượt tích hợp thêm những tính năng khác hoặc có những điều chỉnh hợp lý dựa trên phản hồi của người dùng. Những phản hồi này thực sự giá trị bởi vì chúng xuất phát từ người dùng thật và dựa trên sản phẩm thật. Việc chuyển giao được những phần sản phẩm nhanh chóng sẽ giúp chúng ta sớm thu được giá trị từ sản phẩm. Ví dụ với một ứng dụng dành cho thiết bị di động như đã nói ở trên, việc sớm mang đến tay người dùng sẽ giúp đẩy nhanh việc phát triển khách hàng lên song song với phát triển sản phẩm. Điều này có nghĩa là chúng ta cũng sớm thấy được giá trị của sản phẩm và giá trị này cũng đến tay người dùng sớm hơn. Phần tăng trưởng chuyển giao được sẽ gia tăng tính minh bạch trong quá trình sản xuất. Sau những khoảng thời gian ngắn, chúng ta đã có được những phần sản phẩm thực sự “hoàn thành” mà tất cả mọi người đều có thể nhìn thấy được, tương tác được, thay vì chỉ là những báo cáo, những thiết kế hay bản mẫu vốn tiềm ẩn nhiều rủi ro. Phần tăng trưởng giúp giảm thiểu rủi ro, xét về cả mặt kinh doanh lẫn kĩ thuật. Về mặt kinh doanh, chúng ta sớm biết được thực sự tính năng đó có mang lại giá trị hay không. Chẳng hạn, chúng ta muốn phát triển một phiên bản của hệ thống hiện tại dành riêng cho các thiết bị di động, nhưng không biết được phản ứng của thị trường. Do vậy, việc chúng ta nhanh chóng đưa ra được một phiên bản dùng được của sản phẩm sẽ giúp thăm dò thị trường và đưa ra các quyết định điều chỉnh hợp lý. Về mặt kĩ thuật, chúng ta sớm phát hiện được những khó khăn và đưa ra những giải pháp điều chỉnh trước khi quá muộn. Chẳng hạn, bạn muốn sử dụng một công nghệ mới vào trong hệ thống của mình, việc sớm có được tính năng thật sẽ giúp kiểm chứng được liệu công nghệ đó có hỗ trợ tốt cho nhu cầu của mình hay không. ⇒ Dừng và Nghĩ Hãy nghĩ làm cách nào để nhóm của bạn luôn chuyển giao giá trị cho người dùng trong vòng 30 ngày. CÂU HỎI ỨNG DỤNG 1. Hai trụ cột Thanh tra và Thích nghi của quá trình bạch lý thực nghiệm bị ảnh hưởng như thế nào nếu trụ cột Minh bạch không đảm bảo? 2. Mô tả mối quan hệ giữa ba trụ cột của quá trình quản lí thực nghiệm. 3. Phân tích ưu và nhược điểm của việc Nhóm Phát triển tự xác định cách hoàn thành công việc trong phân đoạn thay vì một người thực hiện và truyền đạt lại. 4. Bạn có thể áp dụng Scrum để quản lí những công việc nào của mình? 5. Nhóm Scrum quản lí thay đổi như thế nào? 6. Mô tả lợi ích của bên liên quan (ví dụ: khách hàng, nhà phát triển, quản lí, v.v.) từ việc áp dụng Scrum? 7. Nếu áp dụng Scrum vào một dự án/công việc của bạn thì thành viên ở những chuyên môn khác nhau (kiểm thử, thiết kế, v.v.) sẽ tham gia theo trình tự như thế nào trong một Sprint? 8. Những lợi ích khi Nhóm Phát triển được làm việc trong một Sprint đóng khung? 9. Những khó khăn khi đóng khung một Sprint ở dự án/công việc của bạn? Cách vượt qua? 3NHÓM SCRUM Trong chương này... • Nhóm liên chức năng và tự tổ chức • Các giai đoạn phát triển của nhóm làm việc • Nhóm Scrum • ScrumMaster • Product Owner • Nhóm Phát triển • Các nghề nghiệp đặc thù Scrum Nếu tất cả mọi người cùng nhau tiến về phía trước, thì thành công sẽ tự nó đến. Henry Ford NHÓM TỰ TỔ CHỨC LIÊN CHỨC NĂNG 24 Tuyên ngôn Agile ghi rõ “Cá nhân và tương tác hơn là quy trình và công cụ”. Bí quyết thành công của Scrum nằm ở các cá nhân và sự tương tác qua lại giữa các cá nhân trong nhóm Scrum. Nhóm Scrum bao gồm Product Owner, Nhóm Phát triển, và Scrum Master. Nhóm Scrum là nhóm tự tổ chức (self-organizing) và liên chức năng (cross-functional). Nhóm tự tổ chức tự mình chọn cách thức tốt nhất để hoàn thành công việc chứ không bị chỉ đạo bởi ai đó bên ngoài nhóm. Nhóm liên chức năng có đủ kĩ năng cần thiết để hoàn thành công việc mà không phụ thuộc vào bất kì người ngoài nào khác ngoài nhóm. Mô hình nhóm trong Scrum được thiết kế để tối ưu hóa sự linh hoạt, sáng tạo và năng suất. Nhóm Scrum chuyển giao sản phẩm theo phân đoạn lặp đi lặp lại và tăng dần, tối đa hóa cơ hội cho các phản hồi. Việc chuyển giao tăng dần (incremental) các gói sản phẩm đạt tiêu chuẩn “Hoàn thành” đảm bảo một phiên bản có thể sử dụng được của sản phẩm. Nhóm Scrum có hai đặc điểm quan trọng là: tự tổ chức (self organiz- ing) và liên chức năng (cross-functional). Tự tổ chức có nghĩa là nhóm cùng ra quyết định, cùng tổ chức công việc thông qua bàn bạc, phân công ngang hàng hướng đến mục tiêu chung. Trong nhóm tự tổ chức, không ai giao việc cho ai, mà chủ động lập kế hoạch, phân chia công việc hợp lí dựa trên các vai trò được định nghĩa rõ ràng từ trước. Các vai trò này được trao quyền để hoàn thành công việc. Liên chức năng là một cơ cấu nhóm không quá mới mẻ, và không phải Scrum phát minh ra. Đó là một nhóm bao gồm nhiều cá nhân với các chuyên môn khác nhau đủ năng lực được kết hợp lại cùng làm việc hướng tới một mục tiêu chung. Trong đội dự án, các cá nhân có thể đến từ nhiều phòng ban chức năng khác nhau, cũng có thể xuất phát từ bên ngoài (khách hàng, các cá nhân có liên quan, chuyên gia tư vấn, v.v.). Nhưng khi đã thành một đội (team), thì các cá nhân làm việc tập trung cho đội như là một đơn vị (unit) để hoàn tất mục tiêu chung. Bên trong nhóm liên chức năng không có các nhóm nhỏ khác. Ví dụ: một Nhóm Scrum “Alpha” được thành lập với 1 Product Owner, 1 Scrum- Master, 2 Tester, 5 Programer, 1 Architect, 1 UX Designer sẽ không phân chia chức năng thành các nhóm nhỏ khác như nhóm Testing (2 người), nhóm Development (5 người) … nữa, mà chỉ có một nhóm duy nhất “Alpha” với các cá nhân có chuyên môn khác nhau, hợp thành một đội thống nhất để làm việc hướng tới sản phẩm cần phát triển. Trong cách nói của các tác giả Scrum, tester hay analyst … đều là devel- oper, họ là nhà phát triển nhưng có chuyên môn đặc thù là kiểm thử hay phân tích; developer trong trường hợp này không có ý nghĩa là coder/programer. Việc xóa nhòa các định danh công việc (Job Title) này có mục đích là để hướng mọi người vào một mục tiêu chung, không phân biệt “nhãn mác” (title): phát triển phần mềm. Khác với nhóm liên chức năng, nhóm chức năng (func- tional team) thường chỉ phụ trách một loại công việc đặc thù. Ví dụ, phòng thiết kế thì không lập trình, phòng test thì không có ai thiết kế. Công việc của nhóm chức năng thường có tính cô lập cao. Có nhiều hiểu lầm phổ biến đối với người mới nghe tới Agile lần đầu, đơn cử: “Cá nhân trong nhóm liên chức năng biết làm tất cả mọi việc, trong nhóm Scrum không có ai là tester hết, không cần designer trong nhóm Scrum nữa, chỉ có developer thôi”. Thực chất là mỗi người mỗi việc. Hay “Nhóm liên chức năng có nghĩa là ai cũng có thể làm được việc thay thế người khác, không cần phân vai rõ ràng, một người có vấn đề sẽ không ảnh hưởng đến cả nhóm”. Thực ra đây chỉ là trạng thái lí tưởng, không phải là cái bắt buộc ở một nhóm liên chức năng. Hay “Cứ liên chức năng thì siêu năng suất ”. Không hẳn, năng suất còn do cách thức phối hợp trong nhóm để đạt được mục tiêu chứ không đơn giản là chuyện cấu hình. Các giai đoạn phát triển nhóm img431 Một nhóm cộng tác trải qua những giai đoạn khác nhau từ khi được bắt đầu thành lập cho đến khi hoạt động ổn định theo thời gian. Việc nhận diện các giai đoạn của nhóm là quan trọng để đưa ra các quyết định chính xác nhằm đảm bảo nhóm đạt được hiệu quả tốt nhất. Tuckman (một nhà tâm lý học người Mӻ) đã đưa ra một mô hình để giải thích các giai đoạn này. Mô hình Tuckman chia chặng đường của một nhóm thành 4 giai đoạn: Forming (Hình thành), Storming (Sóng gió), Norming (Ổn định) và Performing (Hiệu suất cao). Sau này, Tuckman đã thêm vào một giai đoạn thứ 5 đó là Adjourning (Thoái trào). ScrumMaster có vai trò rất quan trọng đối với việc xây dựng và phát triển nhóm. Nhiệm vụ của vai trò này là quan sát để biết nhóm của mình đang ở giai đoạn nào để có những hành động hỗ trợ cần thiết nhằm đẩy nhanh sự phát triển hoặc duy trì sự ổn định của nhóm. Tìm các giải pháp tháo gỡ những trở ngại đối với nhóm trong quá trình phát triển. SCRUMMASTER 25 ScrumMaster là một vai trò then chốt trong Nhóm Scrum có trách nhiệm đảm bảo Scrum được vận hành đúng bằng việc tuân thủ nguyên lí, các kĩ thuật và quy tắc Scrum nhằm hướng đến kết quả tốt nhất. ScrumMaster là người tháo gỡ khó khăn và tạo điều kiện cho nhóm làm việc tốt nhất có thể, huấn luyện đội nhóm thành thục Scrum và hưởng lợi ích từ Scrum. ScrumMaster không trực tiếp tham gia vào công việc làm ra sản phẩm, nhưng là chất kết dính để các bên phối hợp với nhau tạo ra sản phẩm tốt. ScrumMaster không phải là quản lí của Nhóm mà là một lãnh đạo theo phong cách phục vụ (Servant Leader). Với vai trò là lãnh đạo phục vụ, ScrumMaster cung cấp các dịch vụ cho Product Owner, Nhóm Phát triển và Tổ chức. Trích Hướng dẫn Scrum Với Nhóm Phát triển, ScrumMaster phục vụ theo nhiều cách như sau: Đào tạo căn bản Scrum trong trường hợp các thành viên chưa biết về khung làm việc này. Đảm bảo Nhóm Phát triển thực hiện tốt các sự kiện trong Scrum, bao gồm việc tuân thủ khung thời gian, đúng mục đích và nội dung của từng sự kiện. Hỗ trợ Nhóm Phát triển tìm kiếm và sử dụng hiệu quả các công cụ bổ trợ phát triển, chẳng hạn công cụ để quản lí Sprint Backlog, duy trì biểu đồ Sprint Burndown, các hệ thống quản lí mã nguồn, kiểm thử tự động, tích hợp liên tục cũng như các công cụ để giao tiếp trong Nhóm Phát triển như email hay hệ thống trao đổi và chia sẻ trực tuyến, v.v.. Bảo vệ Nhóm Phát triển trước những can thiệp bên ngoài trong quá trình triển khai một Sprint. Ví dụ, ScrumMaster cần giải thích rõ cho Product Owner những tác hại mà việc này gây ra cho Nhóm Phát triển và sản phẩm khi Product Owner muốn thay đổi các hạng mục Product Backlog đã lựa chọn của một Sprint đang diễn ra, đồng thời hướng dẫn Product Owner đưa các thay đổi này vào Sprint tiếp theo, v.v.. Đảm bảo thông tin được minh bạch và thông suốt trong Nhóm Phát triển, chẳng hạn như thông qua việc nhắc nhở nhóm luôn cập nhật Sprint Backlog và biểu đồ Sprint Burndown, đảm bảo Nhóm Phát triển thực hiện đúng sự kiện Scrum Hằng ngày, v.v.. Đảm bảo Nhóm Phát triển có đầy đủ các tài nguyên cần thiết phục vụ sản xuất. Ví dụ như không gian làm việc, các công cụ hỗ trợ và những tài nguyên khác khi có nhu cầu, v.v.. Trong trường hợp Nhóm Phát triển gặp khó khăn với một vấn đề kĩ thuật nhất định, nghĩa là Nhóm Phát triển gặp trở ngại, ScrumMas ter có thể giải quyết bằng cách tìm kiếm sự trợ giúp từ các chuyên gia bên ngoài nhóm. Trích Hướng dẫn Scrum ổ ể ScrumMaster phục vụ tổ chức bằng nhiều cách, cụ thể như: Giúp nâng cao năng lực Agile\Scrum ở tổ chức, chẳng hạn thông qua việc đào tạo Scrum cho các cấp quản lí và các phòng ban khác nhau, thành lập các nhóm học tập Scrum trong tổ chức. Làm việc với các ScrumMaster khác để lập kế hoạch triển khai Scrum trong phạm vi tổ chức, gia tăng hiệu quả của việc áp dụng Scrum trong tổ chức của mình. Giúp đỡ nhân viên và các bên hữu quan hiểu và sử dụng được Scrum cũng như quy trình phát triển sản phẩm thực nghiệm (emprical product development). Tạo ra sự thay đổi làm tăng năng suất của Nhóm Scrum. ScrumMaster phục vụ các đối tượng khác nhau với các công việc khác nhau, các công việc này thay đổi theo các giai đoạn của quá trình phát triển. Đầu tiên, ScrumMaster làm việc với Tổ chức để chuẩn bị và có thể bắt đầu áp dụng Scrum. Đồng thời, ScrumMaster tập trung vào việc xây dựng Nhóm Phát triển cùng với huấn luyện, giúp đỡ Product Owner để đưa nhóm đi vào hoạt động. Ở giai đoạn này, các công việc liên quan đến kĩ thuật phát triển chỉ dừng lại ở mức tối thiểu, đảm bảo vẫn hoàn thành được công việc. Sau đó, ScrumMaster có thể tạm thời gác lại các công việc liên quan đến tổ chức để tập trung vào việc giúp Nhóm làm việc ổn định hơn, từng bước nâng cao các kĩ năng của từng cá nhân và của cả Nhóm. Dần dần ScrumMaster có thể giới thiệu và hỗ trợ nhóm áp dụng các kĩ thuật phát triển để nâng cao năng suất, chất lượng sản phẩm. Khi Nhóm Scrum đã thực sự ổn định và vận hành tốt, ScrumMaster có thể toàn tâm toàn ý để tập trung vào việc tìm kiếm, giới thiệu và hỗ trợ nhóm áp dụng các kĩ thuật phát triển tốt hơn. Cùng với đó là hoạt động để mở rộng Scrum ra tổ chức, giao tiếp và trao đổi giữa các nhóm, hướng đến việc phát triển Scrum bền vững. Trích Hướng dẫn Scrum ScrumMaster phục vụ Product Owner theo nhiều cách như sau: Tìm kiếm các kĩ thuật để quản lí hiệu quả Product Backlog; Giao tiếp tích cực với Nhóm Phát triển về tầm nhìn, mục đích, và các hạng mục của Product Backlog; Dạy cho Nhóm Phát triển biết cách tạo ra các hạng mục Product Back- log thật rõ ràng và đơn giản; Hiểu rõ việc lập kế hoạch dài hạn sản phẩm trong một môi trường thực nghiệm; Hiểu rõ và thực hành sự linh hoạt (agility); và, Thúc đẩy các sự kiện Scrum theo yêu cầu hoặc khi cần thiết. Trích Hướng dẫn Scrum 26 ⇒ Dừng và Nghĩ Bạn có thể viết lại mô tả công việc của ScrumMaster không? Công việc của ScrumMaster 1.Tổ chức các cuộc họp Công việc của ScrumMaster gắn liền với nhiều cuộc họp chính thức và không chính thức như họp Lập kế hoạch, họp Sơ kết Sprint, họp Cải tiến Sprint, họp viết Yêu cầu, họp Scrum Hằng ngày, và nhiều buổi họp đột xuất khác. 2. Thanh tra, thu thập và bạch hoá thông tin Để “quan sát” ScrumMaster có thể bắt đầu với hàng loạt câu hỏi: Mình có nhìn thấy bảng công việc không? Khách hàng có biết việc gì đang diễn tra trên bảng không? Có gì được cập nhật từ hôm qua đến nay không? Có nhìn thấy burndown\burnup không? Có điểm nào bất thường trên Biểu đồ Burndown không? Để điều tra, “đào bới” thêm, ta có thể dùng các câu hỏi Socratic: Tôi nhận thấy , chúng ta sẽ làm gì? Tôi quan sát thấy , nó có quan trọng không? Tôi thấy , bạn có thấy điều đó? Chúng ta sẽ cố tìm lý do của ? Bạn nghĩ chúng ta cần làm gì? Ai có ý tưởng gì về ? Điều này có hiệu quả không? Bạn đã quyết định điều gì? Bạn nên làm gì [với tình huống\vấn đề này]? Để điều tra nguyên nhân của vấn đề, Scrum- Master còn phải thành thạo và liên tục sử dụng 5WHYs (Hỏi 5 lần tại sao) để tìm ra cách thúc đẩy nhóm tiến lên. Các thông tin quan sát được, điều tra được cần lưu trữ và tổ chức khoa học để tiện bề truy xuất (cá nhân và đội nhóm) 3. Loại bỏ trở ngại Sử dụng 5WHYS để tìm những phương án cho những tình huống khó khăn. Ngoài ra, ScrumMaster có thể duy trì một danh sách trở ngại (Impediment Backlog) và cùng với các bên để tháo gỡ dần dần. 4. Tìm kiếm cải tiến Product Owner của tôi làm việc thế nào? Nhóm Phát triển đang làm việc thế nào? Các kĩ thuật đang được dùng thế nào? Tổ chức đang làm việc ra sao? Ai cần được huấn luyện về cái gì? Quy trình có dư thừa cái gì không? Có thể mua sắm hay làm mới công cụ gì để tăng năng suất và gia tăng không khí vui vẻ không? 5. Huấn luyện (Coaching) Scrum cho nhóm Thông qua seminar, workshop, coaching bằng hội thoại hoặc làm mẫu, v.v. để giúp thành viên thành thục Scrum và cách thức giải quyết vấn đề. Lưu ý: ScrumMaster là: • Lãnh đạo Phục vụ • Cố vấn • Nhân tố thay đổi • Người giải quyết vấn đề • “Chó chăn cừu” • Người làm việc toàn thời gian …không là: • Quản lí Dự án • Nắm quyền đối với nhóm • Kiến trúc sư trưởng • Ai kiêm nhiệm cũng được Quản lí Dự án (PM) và ScrumMaster img460 Danh mục kiểm tra của ScrumMaster Công việc hằng ngày □ Nhóm của bạn có ở trạng thái tốt không? • Mục tiêu rõ ràng (những kỳ vọng và quy định phải rõ ràng, và mục tiêu có thể đạt được, phù hợp với kĩ năng và khả năng của mỗi người). • Tập trung và có trọng điểm, tập trung cao độ vào một lĩnh vực nhất định cần được chú ý. • Không có cảm giác tự ti, đề cao hành động và nhận thức. • Phản hồi trực tiếp và ngay lập tức (nhanh chóng nhìn thấy các thành công và thất bại của một chuỗi hoạt động, nhờ thế có thể điều chỉnh hành vi nếu cần thiết). • Cân bằng giữa cấp độ khả năng và thử thách (hoạt động đưa ra không quá khó cũng không quá dễ). • Mỗi người đều có khả năng tự kiểm soát trong mỗi tình huống hay hoạt động. • Mỗi hoạt động đều hiển nhiên đem lại kết quả, vì thế không cần quá nhiều cố gắng trong hành động. □ Các thành viên có thích nhau không, có thư giãn cùng nhau không, và có vui mừng trước thành công của những thành viên khác không? □ Các thành viên nhóm có cùng nhau giữ cho mỗi người đều phải đạt được những tiêu chuẩn cao, và thúc đẩy mỗi người đều phát triển? □ Có vấn đề hoặc cơ hội nào mà nhóm đang không thảo luận cùng nhau vì những vấn đề hoặc cơ hội đó có thể gây ra tình trạng quá khó chịu trong nhóm không? □ Nhóm có tập trung liên tục vào các mục tiêu Sprint không? Có thể bạn nên thực hiện một bước kiểm tra giữa Sprint để có thể tái rà soát các tiêu chuẩn chấp thuận của các hạng mục trong Product Backlog đã cam kết hoàn thành trong Sprint hiện tại. □ Bảng phân công nhiệm vụ của Sprint có phản ánh đúng những công việc mà nhóm đang thực sự làm không? Cần nhận thức rõ “vấn đề tiềm ẩn” của những công việc không được nêu ra và những nhiệm vụ có thể tốn hơn một ngày mới có thể hoàn thành. Những công việc không liên quan đến những cam kết trong Sprint sẽ là những trở ngại cho việc hoàn thành các cam kết đó. □ Bảng phân công nhiệm vụ của nhóm bạn có cập nhật không? □ Các thành viên nhóm có biết về các công cụ tự quản lí của nhóm không, các công cụ đó có tiện dụng không? □ Những công cụ quản lí có được những người ngoài nhóm tôn trọng đúng mức không? Sự giám sát quá mức đối với các hoạt động thường nhật của những người bên ngoài nhóm có thể hủy hoại sự minh bạch và cơ chế tự quản lí trong nhóm. □ Các thành viên nhóm có tự nguyện nhận nhiệm vụ không? □ Sự cần thiết của việc hoàn trả nợ kĩ thuật, việc dần dần sẽ giúp cho việc lập trình trở nên dễ chịu hơn, đã được ghi nhận rõ ràng trong khái niệm hoàn thành chưa? □ Các thành viên nhóm có đang cùng nhau chịu trách nhiệm về mọi khía cạnh của sản phẩm chung (kiểm thử, tài liệu cho người dùng, v.v.) mà không quan tâm đến chức danh của mỗi người không? Công việc theo Sprint □ Product Backlog có được sắp xếp theo hiểu biết mới nhất của nhóm không? □ Các yêu cầu và mong muốn từ tất cả các bên liên quan có được ghi nhận trong Product Backlog không? Ghi nhớ: backlog là quan trọng. □ Khối lượng của Product Backlog có thể quản lí được không? Để duy trì số lượng hạng mục trong giới hạn có thể quản lí được, hãy giữ những hạng mục chi tiết ở trên cùng, còn các hạng mục trừu tượng nói chung ở dưới. Sẽ phản tác dụng nếu chúng ta phân tích quá sâu vào những hạng mục ở phía dưới của Product Backlog. Những yêu cầu đặt ra sẽ thay đổi trong những cuộc trao đổi liên tục giữa sản phẩm đang phát triển và các bên liên quan hoặc khách hàng. □ Có yêu cầu nào (đặc biệt là những yêu cầu ở phía trên cùng của Product Backlog) có thể được thể hiện tốt hơn bằng những user story độc lập, có thể thương lượng được, có thể đánh giá được, có thể ước lượng được, nhỏ, và có thể kiểm thử được? □ Bạn đã giải thích cho Product Owner của bạn về nợ kĩ thuật và cách để tránh nó chưa? Một trong những giải pháp có thể là thêm việc viết kiểm thử tự động và tái cấu trúc vào định nghĩa ‘hoàn thành” cho mỗi hạng mục. □ Backlog có phải là một biểu đồ thông tin, mà các bên liên quan có thể lập tức nhận thấy được không? □ Nếu bạn đang sử dụng một công cụ tự động trong quản lí backlog, mọi người có biết cách để sử dụng nó dễ dàng không? Các công cụ quản lí tự động cũng dẫn tới nguy cơ trở thành sự tắc nghẽn thông tin nếu thiếu đi sự truyền tải thông tin chủ động từ ScrumMaster. □ Bạn có thể giúp truyền tải thông tin bằng các bản in cho mỗi người không? □ Bạn có thể giúp truyền tải thông tin bằng cách tạo ra các biểu đồ to và rõ ràng không? □ Bạn đã giúp Product Owner sắp xếp các hạng mục backlog vào các thời điểm phát hành thích hợp hoặc trong những nhóm ưu tiên chưa? □ Có phải mỗi người trong nhóm đều nhận thức được liệu kế hoạch phát hành còn phù hợp với thực tế không? Bạn có thể thử cho mọi người xem Biểu đồ tương quan sản phẩm/phát hành với thời gian thực hiện sau khi các hạng mục đã được xác nhận “hoàn thành” trong mỗi cuộc họp Sơ kết Sprint. Biểu đồ thể hiện tỉ lệ các hạng mục Product Backlog đã được hoàn thành và những hạng mục mới được thêm vào để cho phép phát hiện sớm những biến động trong quy mô hoặc kế hoạch thực hiện. □ Product Owner của bạn đã điều chỉnh kế hoạch phát hành sau buổi họp Sơ kết Sprint gần nhất chưa? Chỉ có số ít Product Owner đã bàn giao sản phẩm được kiểm thử đầy đủ đúng hạn sắp xếp lại kế hoạch phát hành mỗi Sprint. Điều này có thể sẽ khiến cho một vài sản phẩm cần được phát hành sau vì có những việc quan trọng hơn được phát hiện ra. □ Bạn đã từng thử nhiều cách thức và địa điểm cho các buổi họp Cải tiến Sprint chưa? PRODUCT OWNER Product Owner là một trong ba vai trò Scrum. Vai trò này chịu trách nhiệm định hướng sản phẩm trong suốt quá trình sản xuất. Nhiệm vụ của Product Owner là tối ưu hóa giá trị của sản phẩm thông qua việc tận dụng tốt nhất khả năng sản xuất của Nhóm Phát triển. Để đảm đương tốt vai trò này, Product Owner cần là người có hiểu biết về tầm nhìn của sản phẩm. Có thể Product Owner chưa biết cụ thể là sẽ làm những gì, nhưng có hiểu biết sâu sắc tại sao lại xây dựng sản phẩm này. Product Owner là một người duy nhất, không phải là một nhóm người. Điều này không có nghĩa là một mình Product Owner phải làm mọi việc, mà có thể trao đổi, nhận sự hỗ trợ từ những người khác. Tuy nhiên, Product Owner vẫn là người đại diện duy nhất và chịu trách nhiệm về sản phẩm đang xây dựng. Cụ thể, Product Owner là người duy nhất chịu trách nhiệm quản lí Product Backlog - nơi lưu trữ các hạng mục cần phát triển của sản phẩm. Cách thức quản lí Product Backlog được bàn kĩ trong Chương 5 và một phần trong Chương 7 (về sử dụng User Story và ước tính linh hoạt). Ngoài việc quản lí Product Backlog, Product Owner còn phải tích cực tham gia vào các cuộc họp của nhóm để cung cấp các thông tin cần thiết, chủ động quản lí một Kế hoạch Phát hành cho sản phẩm. Sáu nhiệm vụ chính của một Product Owner 1. Công việc đầu tiên của Product Owner là tìm hiểu và phân tích kӻ về sản phẩm dự định phát triển, lên danh sách các tính năng mong muốn bằng việc liệt kê chúng trong một Product Backlog. Đây là danh sách các hạng mục mà Nhóm Phát triển dựa vào để làm việc và chuyển thành các tính năng của sản phẩm thật. Danh sách này không phải là cố định mà được điều chỉnh trong suốt quá trình phát triển của sản phẩm sao cho phù hợp nhất. 2. Các hạng mục trong Product Backlog, sẽ được Product Owner đánh giá giá trị và sắp xếp. Hạng mục nào có giá trị cao hơn sẽ được đưa lên trên để đưa vào sản xuất sớm nhất. Khái niệm ‘giá trị’ ở đây phụ thuộc vào rất nhiều yếu tố, ví dụ như lợi nhuận thu về, mong muốn của khách hàng, các mục tiêu chiến lược, sự phụ thuộc vào các hạng mục khác, rủi ro và nhiều yếu tố khác nữa. Nếu không có được một giá trị cụ thể bằng con số, nhưng Product Owner có thể so sánh dựa theo giá trị tương đối để thực hiện việc sắp xếp. Điều này cũng tương tự như việc, chúng ta không biết chính xác kích thước của quả bưởi, nhưng biết chắc chắn là nó to hơn quả cam. 3. Nhiệm vụ thứ ba của Product Owner là tối ưu hóa lợi nhuận trên vốn đầu tư (ROI). Trong khi, khả năng sản xuất của Nhóm Phát triển thường có một giới hạn nhất định, Product Owner là người luôn phải tìm cách để sử dụng tốt nhất khả năng này. Vì vậy, ngoài việc sắp xếp các hạng mục trong Product Backlog thì Product Owner cũng cần phải biết nói “không” để loại bỏ những hạng mục không cần thiết. 4. Product Backlog là một tạo tác (artifact) quan trọng. Product Owner phải giữ cho nó luôn được minh bạch và rõ ràng đối với tất cả mọi người. Nói cách khác Product Owner phải đảm bảo tính minh bạch của Product Backlog. 5. Một nhiệm vụ quan trọng nữa của Product Owner là phải luôn luôn sẵn sàng giải thích cho Nhóm Phát triển hiểu rõ các hạng mục của Product Backlog. Điều này đảm bảo Nhóm Phát triển hiểu đúng và đầy đủ về từng hạng mục mà họ triển khai. 6. Nhiệm vụ của Product Owner còn là theo dõi tiến độ phát triển sản phẩm, đảm bảo minh bạch và có thể giải trình với các bên liên quan khi có yêu cầu. Product Owner có thể sử dụng các công cụ như Biểu đồ Burndown, hay các công cụ khác để thực hiện nhiệm vụ này. Ngoài các nhiệm vụ trên, Product Owner là người có quyền và chịu trách nhiệm khi quyết định hủy Sprint (dừng Sprint bất thường). Danh mục kiểm tra của Product Owner Kiểm tra hằng ngày □ Đã làm rõ yêu cầu sản phẩm cho Nhóm Phát triển (nếu có) □ Đã làm mịn các hạng mục của Product Backlog, đặc biệt các hạng mục ở trên Kiểm tra theo Sprint □ Đã làm việc với các bên liên quan để cập nhật những kỳ vọng mới về sản phẩm □ Đã sắp xếp các hạng mục trong Product Backlog đảm bảo tối ưu hóa ROI Đã làm mịn các hạng mục của Product Backlog □ Đã xác định tiêu chí chấp nhận cho các hạng mục sẽ phát triển trong Sprint tới □ Đã tham gia Lập kế hoạch Sprint để trình bày về tổng quan sản phẩm, từng hạng mục sẽ làm trong Sprint tới và giải đáp mọi thắc mắc về yêu cầu trong Lập kế hoạch Sprint □ Đã tham gia và đưa ra phản hồi về sản phẩm trong Sơ kết Sprint Sự thành công của Product Owner phụ thuộc vào nhiều yếu tố như: Product Owner cần được trao quyền ra quyết định. Các quyết định này cần phải được tôn trọng. Chúng được thể hiện thông qua nội dung và trật tự của các hạng mục trong một Product Backlog duy nhất. Nhóm Phát triển chỉ làm việc dựa trên Product Back- log này chứ không phải làm theo bất cứ yêu cầu nào khác, cho dù yêu cầu đó xuất phát từ bất cứ ai. Product Owner phải có hiểu biết về lĩnh vực sản phẩm đang xây dựng. Điều này là cần thiết để giữ đúng hướng đi trong quá trình phát triển, đưa ra các quyết định, lựa chọn, thêm hay loại bỏ các tính năng nhằm giữ cho Nhóm Phát triển luôn làm việc trên những hạng mục cần thiết nhất và sản phẩm luôn mang lại giá trị cao nhất. Product Owner phải có đủ thời gian cho công việc của mình. Tốt nhất anh ta là người làm việc toàn thời gian cho một sản phẩm duy nhất. Nếu Product Owner phải làm việc trên nhiều sản phẩm thì sẽ dẫn đến tình trạng mất tập trung, làm suy giảm đáng kể hiệu quả công việc. Product Owner phải có kĩ năng giao tiếp và thương lượng tốt. Quá trình phát triển sản phẩm đòi hỏi Product Owner trao đổi và cộng tác thường xuyên với Nhóm Phát triển và các bên liên quan, cùng với đó là việc phải thương lượng để đưa ra các quyết định ảnh hưởng đến sản xuất và sản phẩm. Do đó, các kĩ năng này là rất quan trọng để đảm bảo công việc của Product Owner có thể đạt kết quả cao nhất. ⇒ Dừng và Nghĩ Bạn có thể viết lại mô tả công việc của Product Owner không? NHÓM PHÁT TRIỂN Nhóm Phát triển là đội ngũ trực tiếp làm ra sản phẩm, nhóm này bao gồm các chuyên gia có nhiệm vụ chuyển giao phần tăng trưởng có thể chuyển giao được ở cuối mỗi Sprint. Nhóm Phát triển trong Scrum cũng là một nhóm tự tổ chức và liên chức năng. Nhóm được trao quyền để tự định hướng và đưa ra các quyết định liên quan đến công việc sản xuất. Tự tổ chức cũng có nghĩa là nhóm có toàn quyền lựa chọn công cụ, kĩ thuật và cách thức để hoàn thành công việc. Trong quá trình sản xuất, họ tự tiến hành ước lượng, phân bổ, theo dõi, điều tiết công việc theo hình thức tập thể. Khi bắt đầu mỗi Sprint, Nhóm Phát triển tự lựa chọn các hạng mục từ danh sách đã được sắp xếp của Product Backlog sao cho phù hợp với khả năng sản xuất của mình. Đây là một khác biệt so với một số mô hình phát triển truyền thống - các mô hình hoạt động theo hình thức ra lệnh và kiểm soát. Trong mô hình sản xuất truyền thống các công việc thường được bộ phận quản lí phân chia và gán trách nhiệm cho từng người. Với cách thức làm việc như của Nhóm Phát triển trong Scrum sẽ giúp làm tăng ý thức sở hữu và tính cam kết của các thành viên. 29 Đối với mỗi hạng mục công việc, Nhóm Phát triển là những người ước lượng kích thước tốt nhất bởi vì họ là lực lượng trực tiếp sản xuất, là những người am hiểu về công việc và các yếu tố liên quan đến nó. Điều này không chỉ cần thiết đối với nhóm mà còn hữu ích đối với Product Owner khi quản lí Product Backlog. Nhóm Phát triển thường xuyên theo dõi tiến độ công việc để biết được khả năng của mình, tốc độ sản xuất, tình hình đạt được Mục tiêu Sprint và các mốc quan trọng của sản phẩm. Nhờ theo dõi liên tục và sự minh bạch về thông tin nên Nhóm Scrum nói chung, Nhóm Phát triển nói riêng có những điều chỉnh hợp lý trong tổ chức sản xuất. 27 Một đặc điểm quan trọng của Nhóm Phát triển đó là tính liên chức năng. Liên chức năng đối với Nhóm Phát triển có nghĩa là nhóm được trang bị đầy đủ các kĩ năng cần thiết để hoàn thành công việc và chuyển giao phần tăng trưởng ở cuối mỗi Sprint mà không cần sự hỗ trợ từ bên ngoài. Đặc điểm này là quan trọng vì nó giúp Nhóm Phát triển có thể hoạt động độc lập, trở thành một đơn vị sản xuất hoàn chỉnh, tổ chức vận hành và chuyển giao sản phẩm có chất lượng. Đặc điểm này giúp Nhóm Phát triển đưa ra các quyết định nhanh chóng, kịp thời mà không phụ thuộc và chờ đợi từ các cá nhân, đơn vị khác bên ngoài. Việc tổ chức nhóm liên chức năng là rất khác biệt so với cách tổ chức theo phòng/ban chuyên môn truyền thống. Ở những hệ thống có các phòng ban chuyên môn, công việc sản xuất đòi hỏi sự cộng tác, phối hợp giữa những bộ phận khá tách biệt. Điều này làm giảm đáng kể sự linh hoạt, gây lãng phí và làm chậm tốc độ sản xuất. Đối với một nhóm liên chức năng, sự cộng tác và đồng bộ diễn ra nhanh chóng và tối ưu giúp cho năng suất và hiệu quả sản xuất được nâng lên. Nhóm Phát triển không có sự phân chia chức danh hay vai trò, tất cả các thành viên đều có vai trò giống nhau. Mỗi thành viên thường có thế mạnh ở một vài kĩ năng nhất định và những kĩ năng đó góp lại trở thành kĩ năng chung của nhóm chứ không còn là của riêng cá nhân nào. Như vậy, chúng ta sẽ không thấy những chức danh như “nhà phân tích nghiệp vụ (BA)”, “nhà thiết kế (design- er)”, “lập trình viên (coder)”, “kiểm thử viên (tester)” trong Nhóm Phát triển. Thay vào đó, tất cả các thành viên đều được gọi chung là “nhà phát triển (developer)” và kĩ năng tổng thể của nhóm là phân tích nghiệp vụ, thiết kế, lập trình, kiểm thử. Việc xóa bỏ sự phân chia vai trò giúp làm tăng tính sở hữu tập thể, trách nhiệm tập thể và bình đẳng trong công việc. Đồng thời cũng giúp thúc đẩy việc học tập trong Nhóm Phát triển. 28 Các thành viên không chỉ tham gia giải quyết những hạng mục công việc mà mình có thế mạnh nhất, mà còn giúp sức trong những công việc khác. Điều này đòi hỏi sự trao đổi, học tập và rèn luyện những kĩ năng khác diễn ra giữa các thành viên. Theo thời gian mỗi thành viên sẽ học được những kĩ năng mới ngoài những kĩ năng vốn có của mình. Ví dụ, một thành viên với kĩ năng chính là thiết kế thì có thể có thêm kĩ năng mới là kiểm thử, một thành viên với kĩ năng chính là phân tích nghiệp vụ thì có thể có thêm kĩ năng mới là lập trình. Nhóm Phát triển gồm bao nhiêu thành viên là đủ? Nhóm Phát triển vận hành tốt nhất với số lượng thành viên vừa phải, quy định của Scrum là từ 3 đến 9 người. Nhóm quá ít thành viên sẽ dẫn đến khả năng sản xuất nhỏ và có thể thiếu các kĩ năng cần thiết (không liên chức năng), khó để tạo được các phần tăng trưởng hoàn chỉnh đáng kể ở cuối mỗi Sprint. Nhóm có quá nhiều thành viên sẽ làm tăng tính phức tạp trong quản lí, gây khó khăn trong tương tác, giao tiếp, đảm bảo minh bạch và làm giảm tính linh hoạt của nhóm. Nếu dự án lớn cần nhiều người, chúng ta cần chia nhỏ nhóm và sử dụng kĩ thuật Scrum ở quy mô lớn (tham khảo Chương 9). Có cần sự ổn định không? Nhóm Phát triển đòi hỏi tính ổn định cao để đạt được năng suất và chất lượng cao nhất trong sản xuất. Điều này sẽ thuận lợi cho các thành viên trong cộng tác, giao tiếp, tận dụng tối ưu sự đóng góp của mỗi người. Sự ổn định cũng giúp nhóm điều chỉnh các thói quen hoạt động của mình một cách phù hợp và hiệu quả nhất. Giữ cho nhóm ổn định cũng giúp khả năng tiên lượng khi lập kế hoạch tốt hơn do các yếu tố như hiệu suất và tốc độ sản xuất của nhóm ổn định. Tuy vậy, trong thực tế việc thay đổi thành viên đôi khi là khó tránh khỏi do nhiều nguyên nhân khác nhau. Khi này, nhóm biết rằng việc đó sẽ ảnh hưởng tới năng suất trong ngắn hạn. Nhóm Phát triển đóng góp những gì cho sản phẩm? Ngoài việc trực tiếp làm ra sản phẩm, sự am hiểu của Nhóm Phát triển về sản phẩm là rất quan trọng để đi đến thành công. Đặc biệt là đối với các sản phẩm mới. Ở đó, sản phẩm là cả một quá trình tìm tòi, thử nghiệm, điều chỉnh mà ngay cả Product Owner và các bên liên quan đều không biết rõ ràng từ trước. Nhóm Phát triển còn giúp sức cho Product Owner trong việc duy trì Product Backlog. Có những công việc mà Nhóm Phát triển là những người làm tốt nhất, chẳng hạn như việc ước tính kích thước của các hạng mục, các yêu cầu liên quan đến công nghệ, sự phụ thuộc giữa các hạng mục, v.v.. Đây là những yếu tố có ảnh hưởng lớn đến nội dung của Product Backlog. img479 LƯU Ý! Nhóm Phát triển hoạt động hướng vào mục tiêu chung, thay vì hướng vào công việc của từng cá nhân. Và tuân thủ nguyên tắc giới hạn lượng việc đang làm (Limit WIP - Limit Work-In- Progress). 30 CÂU HỎI ỨNG DỤNG 1. ScrumMaster có phải là người quản lí dự án hay không? Tại sao nói ScrumMaster là người lãnh đạo kiểu mới? 2. Cần có những tố chất gì để trở thành một ScrumMaster tốt? 3. Để làm tốt vai trò Product Owner bạn cần những kĩ năng nào? 4. Công việc chủ đạo của Product Owner với Product Backlog là gì? 5. ScrumMaster làm gì để giúp Nhóm Phát triển đạt được năng suất cao? 6. Tính liên chức năng và tự tổ chức giúp ích gì cho Nhóm Phát triển? 7. Nhóm Scrum sử dụng những công cụ chủ đạo nào để tăng cường sự minh bạch? 8. Nhóm của bạn có đủ tính chất để trở thành một nhóm Scrum không? Cần làm gì để có thể bù đắp những tính chất còn thiếu (nếu có)? 9. Nếu áp dụng Scrum cho một nhóm của bạn, ai sẽ đóng vai trò ScrumMaster? 10. Quy tắc làm việc nhóm của bạn có những mục nào là quan trọng nhất? 4CÁC SỰ KIỆN SCRUM Trong chương này... • Sprint • Lập kế hoạch Sprint • Scrum Hằng ngày • Sơ kết Sprint • Cải tiến Sprint Bất cứ ai ngừng học hỏi đều trở nên già cỗi, cho dù ở tuổi hai mươi hay đã tám mươi tuổi. Bất cứ ai không ngừng học hỏi vẫn mãi trẻ trung. Điều tuyệt vời nhất trong cuộc sống chính là giữ cho trí tuệ của bạn luôn tươi trẻ. Henry Ford Các sự kiện trong Scrum hình thành một thứ tự lặp đi lặp lại các công việc có chủ đích nhằm xây dựng một thói quen làm việc hiệu quả. Không gọi là các cuộc họp (dù chúng là các cuộc họp), các Sự kiện Scrum là cơ hội để cộng tác nhóm. Tất cả các Sự kiện Scrum đều được đóng khung thời gian (time-boxed), nghĩa là mỗi sự kiện có giới hạn thời gian tối đa. Điều này đảm bảo thời lượng vừa đủ để tránh lãng phí thời gian không cần thiết cho sự kiện. Bao gồm cả bản thân Sprint vốn chứa tất cả các sự kiện khác, mỗi sự kiện trong Scrum là một cơ hội chính thức để thực hiện cơ chế thanh tra và thích nghi. Mỗi sự kiện đều có quy cách rõ ràng. Nếu không thực hiện được hoặc thực hiện không đúng các sự kiện này có thể dẫn đến giảm sự minh bạch và đánh mất cơ hội để thanh tra và thích nghi. Các sự kiện trong Scrum bao gồm: 1. Sprint 2. Lập kế hoạch Sprint 3. Scrum Hằng ngày 4. Sơ kết Sprint 5. Cải tiến Sprint 31 Bảng tóm tắt các Sự kiện Scrum 32 Sprint là trái tim của Scrum. Sự kiện này có khung thời gian (time box) không vượt quá 1 tháng. Thông thường các Sprint có thể kéo dài từ 1 đến 4 tuần. Các nhóm phải quyết định độ dài ổn định cho nhóm của mình dựa trên điều kiện thực tế. Các phần tăng trưởng của sản phẩm có thể phát hành được được sản xuất gói gọn trong khung thời gian này. Trong suốt quá trình phát triển một sản phẩm, Sprint được khuyến nghị giữ khung thời gian cố định. Một Sprint mới bắt đầu ngay khi Sprint trước kết thúc. 33 Sprint chứa các sự kiện còn lại của Scrum. Nói cách khác, các sự kiện Lập kế hoạch Sprint, Scrum Hằng ngày, Sơ kết Sprint, Cải tiến Sprint diễn ra trong khung thời gian của Sprint. Chúng ta cần lưu ý, trong suốt Sprint: • Không cho phép có bất kì sự thay đổi nào ảnh hưởng đến Mục tiêu Sprint; • Thành phần Nhóm Phát triển được giữ nguyên; • Mục tiêu chất lượng không được cắt giảm; và, • Phạm vi có thể được làm rõ và tái thương lượng giữa Product Owner và Nhóm Phát triển. Mỗi Sprint có thể được coi như một tiểu dự án với độ dài tối đa là 1 tháng. Mỗi Sprint có một mục tiêu rõ ràng xác định việc phải xây dựng trong Sprint, một bản thiết kế và bản kế hoạch linh hoạt sẽ hướng dẫn quá trình xây dựng đó. Hủy một Sprint: Sprint có thể bị hủy trước khi kết thúc khung thời gian. Chỉ có Product Owner mới đủ thẩm quyền kết thúc Sprint, mặc dù Product Owner có thể chịu ảnh hưởng bởi những bên hữu quan khác, bởi Nhóm Phát triển hoặc bởi ScrumMaster. Một Sprint có thể bị hủy nếu như Mục tiêu Sprint không còn phù hợp nữa. Điều này xảy ra khi công ty chuyển hướng kinh doanh hoặc khi tình thế công nghệ có sự thay đổi. Nhìn chung, Sprint có thể bị hủy nếu nó không mang lại điều gì có ích. Thế nhưng, do thời gian mỗi Sprint tương đối ngắn, nên việc hủy một Sprint không mấy khi xảy ra. Khi Sprint bị hủy, các phần sản phẩm đã hoàn chỉnh được xem xét lại. Nếu phần nào đó của công việc đó là có thể chuyển giao được, thì Product Owner có thể chấp nhận chúng. Các hạng mục Product Backlog chưa hoàn tất sẽ được ước lượng lại và trả về Product Back- log để phát triển tiếp. Các phần việc đã thực hiện trên đó sẽ nhanh chóng hết tác dụng và phải thường xuyên được ước lượng lại. Việc hủy Sprint sẽ gây lãng phí tài nguyên, do mọi người phải mất thời gian, công sức để lên kế hoạch cho một Sprint mới. Việc hủy Sprint thường gây tổn hại nhất định cho Nhóm Phát triển, và rất ít khi xảy ra. 34 LẬP KẾ HOẠCH SPRINT Một Sprint bắt đầu bằng buổi Lập kế hoạch Sprint để xác định Mục tiêu Sprint và lên kế hoạch các công việc cần thực hiện. Sự kiện này được chia làm hai phần: Phần thứ nhất để lựa chọn các công việc cần làm trong Sprint và Phần thứ hai để quyết định cách thức hoàn thành các công việc đã lựa chọn trước đó. Toàn bộ buổi Lập kế hoạch Sprint sẽ lần lượt trả lời các câu hỏi: • Mục tiêu của Sprint này là gì? • Sprint này phải chuyển giao cái gì? • Làm sao để đạt được điều đó? Toàn bộ Nhóm Scrum bắt buộc phải tham gia phần thứ nhất của sự kiện. Ở phần thứ hai Product Owner có thể vắng mặt nhưng phải luôn sẵn sàng để hỗ trợ Nhóm Phát triển làm rõ các hạng mục khi cần thiết, chẳng hạn thông qua điện thoại hay các hệ thống trao đổi trực tuyến. Buổi Lập kế hoạch Sprint kéo dài trong 8 giờ đối với Sprint 1 tháng, đối với các Sprint ngắn hơn thì khung thời gian cho sự kiện có thể ngắn hơn. Ví dụ, đối với Sprint 2 tuần khung thời gian cho buổi Lập kế hoạch là khoảng 4 giờ. Thời gian dành cho hai phần của sự kiện này là bằng nhau, mỗi phần chiếm một nửa khung thời gian. Phần 1: Làm gì trong Sprint này? Kết thúc Phần 1 của buổi Lập kế hoạch Sprint; Nhóm Scrum sẽ đưa ra câu trả lời cho câu hỏi: Chúng ta sẽ làm gì trong Sprint này? Cụ thể kết quả của phần này là Mục tiêu Sprint và danh sách các hạng mục Product Backlog được lựa chọn để phát triển trong Sprint. Phần 1 được bắt đầu bằng việc Product Owner trình bày mục tiêu mong muốn đạt được trong Sprint này. Sau đó, Product Owner làm rõ thêm các hạng mục ở phần trên của Product Backlog (những hạng mục có độ ưu tiên cao nhất) để cả nhóm hiểu kӻ về hơn các hạng mục này. Product Owner cần làm rõ số lượng hạng mục Prod uct Backlog nhiều hơn số lượng mà Nhóm Phát triển có thể hoàn thành trong cho một Sprint (con số này dựa vào các Sprint trước đó hoặc dựa trên kinh nghiệm). Ví dụ, nếu ước lượng thấy nhóm có khả năng làm khoảng 5 hạng mục thì ít nhất cả nhóm phải hiểu rõ khoảng 8 hạng mục hoặc hơn thế. Việc đó giúp nhóm có đầy đủ thông tin để đưa ra các quyết định lựa chọn một cách chính xác cho Sprint này. Thông thường, những hạng mục này đã được phân tích kӻ và làm rõ từ một vài Sprint trước thông qua việc làm mịn Product Backlog, do đó công việc trong phần này không tốn quá nhiều thời gian. Sau đó, cả nhóm sẽ hợp tác để tìm hiểu công việc phải làm trong Sprint. Căn cứ vào Mục tiêu Sprint và năng lực hiện có, Nhóm Phát triển lựa chọn những hạng mục mà họ tin là có thể hoàn thành trong Sprint này, bắt đầu từ những hạng mục đứng đầu trong Product Backlog - nói cách khác, họ bắt đầu với những hạng mục có độ ưu tiên cao nhất do Product Owner sắp xếp. Đây là cách làm chủ chốt trong Scrum: Nhóm Phát triển quyết định có bao nhiêu hạng mục sẽ được hoàn thành, thay vì được giao bởi Product Owner. Điều này sẽ giúp Nhóm Phát triển đưa ra các dự báo tin cậy hơn do họ làm việc đó căn cứ vào những phân tích và lập kế hoạch của chính bản thân họ. Năng lực của nhóm Bạn cần phải tính được nhóm có bao nhiêu người làm việc bao nhiêu giờ trong Sprint này. Vì có thể có ai đó sẽ nghỉ hoặc phải giảm thời lượng làm việc để phục vụ cho nhiệm vụ khác. Ngoài ra, bạn cũng cần phải tính thời gian “không năng suất” của mỗi ngày. Bởi thực chất một người chỉ có thể tập trung làm việc trong một thời gian nhất định trong ngày. Nếu thời gian làm việc mỗi ngày là 8 tiếng, thì thời gian “năng suất” – tức thời gian mà mỗi thành viên có thể dành để thực sự làm việc trên các hạng mục Product Backlog – có thể chỉ là 5 hoặc 6 giờ. Để tránh được những ước lượng quá lạc quan (cũng có nghĩa là khả năng lớn sẽ phải làm thêm ngoài giờ hoặc không thể hoàn thành được mục tiêu đã định), bạn sẽ phải hết sức thực tế trong việc tính toán năng lực của cả nhóm trong Sprint. Để quyết định những hạng mục nào của Product Backlog sẽ triển khai trong Sprint này, Nhóm Phát triển sử dụng tốc độ sản xuất trung bình của mình trong quá khứ đồng thời tính khả năng của nhóm trong Sprint hiện tại. Ví dụ, vận tốc trung bình của Nhóm Phát triển 7 người là 80 point trong một Sprint (nhóm này ước tính các hạng mục Product Backlog theo point - điểm). Trong Sprint hiện tại, có một thành viên xin nghỉ phép 3 ngày. Vậy, khả năng của nhóm trong Sprint này chỉ đạt được 74 point. Do đó, nhóm chỉ lựa chọn số lượng hạng mục đủ để làm trong khả năng 74 point của mình. Nếu Nhóm Phát triển muốn lựa chọn một vài hạng mục có độ ưu tiên thấp ở phía dưới của Product Backlog họ cần thảo luận với Product Owner. Điều này thường xảy ra khi có sự phụ thuộc giữa các hạng mục hoặc nhóm cảm thấy hạng mục có độ ưu tiên thấp đó rất phù hợp để phát triển cùng với các hạng mục khác đã lựa chọn. Kết thúc Phần 1, Nhóm Phát triển và Product Owner thống nhất lại Mục tiêu Sprint và danh sách các hạng mục sẽ chuyển giao trong Sprint này. Mục tiêu Sprint là một đoạn mô tả ngắn về kết quả kỳ vọng đạt được sau khi Sprint kết thúc. Mục tiêu Sprint đóng vai trò định hướng Nhóm Phát triển trong suốt quá trình diễn ra Sprint và đồng thời giúp nhóm đưa ra được những quyết định hợp lý nhằm đạt được mục tiêu này. Một ví dụ về Mục tiêu Sprint là: “Xây dựng chức năng mua hàng bao gồm: Xem danh sách sản phẩm, thêm sản phẩm vào giỏ hàng, xem giỏ hàng, loại bỏ sản phẩm khỏi giỏ hàng, hiển thị trang thanh toán.” img513 Ví dụ: Lịch trình họp Lập kế hoạch Sprint cho một Sprint 1 tuần • 8:00 – 8:30. Phiên họp bắt đầu. Product Owner trình bày mục tiêu của Sprint và tóm tắt các hạng mục Product Backlog dự kiến. • 8:30 – 9:00. Nhóm Phát triển ước tính thời gian và tìm hiểu rõ các việc cần phải làm. Nhóm Phát triển và Product Owner cùng trao đổi về những điều nghi vấn về hạng mục Product Backlog (nếu có). • 9:00 – 9:30. Nhóm chọn hạng mục để đưa vào Sprint. Thực hiện tính toán tốc độ để đảm bảo tính khả thi của Mục tiêu Sprint. • 9:30 – 11:00. Chọn thời gian và địa điểm để họp Scrum Hằng ngày (nếu có thay đổi so với Sprint trước). Chia nhỏ hơn các hạng mục thành các đầu việc phải làm. Trong lúc thảo luận về chia nhỏ cách làm, nhóm có thể sẽ phải vẽ ra những phác thảo về thiết kế hệ thống, giao diện, và những quy ước hợp tác nhất định trong viết mã lệnh. • 11:00-11:15. Cả nhóm chốt lại kế hoạch của Sprint. Cập nhật các công việc lên Sprint Backlog và chuẩn bị vào Sprint làm việc. Phiên họp kết thúc. Tốc độ (Velocity) Tốc độ được tính bằng số lượng đơn vị được hoàn thành trong mỗi Sprint. Nếu bạn dùng đơn vị là điểm (point), thì tốc độ chính là số điểm mà nhóm hoàn thành được trong một Sprint. Qua thời gian, tốc độ của nhóm có thể sẽ tương đối ổn định. Đó là tiền đề quan trọng để nhóm có thể phỏng đoán khối lượng công việc của nhóm trong mỗi Sprint. ⇒ Dừng và Nghĩ Vì sao việc đặt mục tiêu Sprint lại quan trọng? Nói rộng ra, tại sao việc đặt mục tiêu lại quan trọng? ể Để đặt mục tiêu và lập kế hoạch hiệu quả cho Sprint, Nhóm Scrum có thể sử dụng SMART Rubric như là công cụ hướng dẫn 35 Phần 2: Làm sao để hoàn thành công việc đã chọn? Phần 2 của buổi Lập kế hoạch Sprint với mục đích trả lời cho câu hỏi: Làm sao để hoàn thành công việc đã chọn? Kết quả của phần này đó là Sprint Backlog - tức là bảng công việc được Nhóm Phát triển sử dụng trong suốt Sprint, bao gồm các hạng mục Product Backlog đã lựa chọn và danh sách công việc tương ứng với từng hạng mục Product Backlog đó. Nhóm Phát triển bắt đầu thiết kế hệ thống và lên danh sách các công việc cần làm. Đối với mỗi hạng mục trong danh sách đã lựa chọn, nhóm sẽ tách thành các công việc cụ thể. Các công việc này thường đủ nhỏ để hoàn thành trong vòng một ngày hoặc ít hơn. Một số loại công việc thường thấy như: thiết kế, viết kiểm thử, viết mã, viết tài liệu, nghiên cứu kĩ thuật hoặc công nghệ mới, v.v.. Tất cả các công việc này đều phải được Nhóm Phát triển ước lượng nỗ lực để hoàn thành từng công việc. Thường các nỗ lực này được lượng hóa theo đơn vị giờ hoặc point và chúng được Nhóm Phát triển điều chỉnh thường xuyên trong quá trình triển khai. Một trong các kĩ thuật thường dùng để ước lượng là Planning Poker (xem Chương 7). Tổng nỗ lực cho tất cả các hạng mục trên Sprint Backlog được nhóm sử dụng để theo dõi tiến độ Sprint. Giá trị này được cập nhật ngay vào Sprint Backlog và đồng thời cũng được sử dụng để tạo Biểu đồ Sprint Burndown nhằm theo dõi tiến độ Sprint. Sau mỗi ngày làm việc, các thành viên sẽ cập nhật đồng thời Sprint Backlog và Biểu đồ Burndown với các giá trị mới. Nếu Nhóm Phát triển thấy rằng lượng công việc vừa lựa chọn là quá nhiều hay quá ít so với khả năng của nhóm họ có thể trao đổi và thương lượng với Product Owner để loại bỏ bớt hoặc chọn thêm các hạng mục khác. Trong Phần 2, Nhóm Phát triển có thể cần thêm sự hỗ trợ về mặt kĩ thuật từ bên ngoài nhóm để việc phân tích, ước lượng công việc tốt hơn. Lập kế hoạch phát hành Có thể bạn sẽ cần một kế hoạch dài hơi hơn để cho ra được một bản phát hành có ý nghĩa lớn nào đó. Lúc này bạn cần phải duy trì một Kế hoạch Phát hành (Release Plan). Kế hoạch này sẽ phải dựa nhiều vào việc ước tính kích thước các hạng mục Product Backlog. Hãy xem thêm kĩ thuật ước tính linh hoạt được đề cập đến trong chương 7. Khi công việc ước tính cho từng hạng mục đã được hoàn tất, bạn có thể căn cứ vào tốc độ của nhóm mà dự đoán là đến khi nào thì có thể có được một bản phát hành có ý nghĩa. Để cho kế hoạch không quá cứng nhắc, có thể bạn sẽ cần phân loại các tính năng Phải có, Nên có, và Có thể có khi lựa chọn các tính năng sẽ hiện diện trong bản phát hành sắp tới. Tập hợp những phần Phải có có thể tạo thành một bộ tính năng thuộc dạng MVP (Minimum Viable Product – sản phẩm hữu dụng tối thiểu) có thể chuyển giao giá trị cơ bản tới người dùng cuối. Nên nhớ rằng tốc độ ước tính là con số dự báo, và trong quá trình hướng đến mục tiêu phát hành, nhóm của bạn có thể gặp phải những vấn đề không tính trước. Vì thế, kế hoạch phát hành cũng phải được hiệu chỉnh thường xuyên sau mỗi Sprint. Bạn cũng có thể dùng Biểu đồ Release Burndown (xem Chương 5) để theo dõi tiến độ đạt được mục tiêu phát hành qua các Sprint. 36 Danh mục kiểm tra Lập kế hoạch Sprint □ Buổi lập kế hoạch có diễn ra đúng giờ? □ Có thành viên nào thiếu không? Lý do vì sao? □ Product Backlog có sẵn sàng trước buổi lập kế hoạch? □ Product Owner có sơ kết lại tình hình sản phẩm hiện tại đầu buổi lập kế hoạch? □ Product Owner có đưa ra mong muốn mục tiêu Sprint đầu buổi lập kế hoạch? □ Khả năng của Nhóm Phát triển đã được tính? □ Có những vấn đề, sự kiện nào đặc biệt ảnh hưởng tới khả năng của nhóm không (ví dụ nghỉ hè, thành viên nào có việc riêng)? □ Nhóm Phát triển và Product Owner có rà soát những hạng mục có thể sẽ phát triển trong Sprint? □ Những hạng mục có thể sẽ phát triển trong Sprint đã có tiêu chí chấp nhận? □ Nhóm Phát triển đã phân ra các hạng mục sẽ phát triển thành các công việc đưa vào Sprint Backlog? □ Các hạng mục trong Sprint Backlog đã được ước lượng? Product Owner có hài lòng với cam kết của Nhóm Phát triển? □ Nhóm Phát triển có tin vào khả năng hoàn thành cam kết? Có điều gì cần lưu ý trong Sprint? □ Buổi Lập kết hoạch Sprint có đảm bảo khung thời gian? □ Đã cập nhật các tạo tác như Sprint Backlog, Biểu đồ Burndown? SCRUM HẰNG NGÀY 37 Scrum Hằng ngày là một nghi thức quan trọng diễn ra đều đặn hằng ngày trong suốt quá trình sản xuất. Đây là một buổi trao đổi ngắn không kéo dài quá 15 phút với mục đích giúp Nhóm Phát triển đồng bộ công việc và lập kế hoạch cho ngày làm việc tiếp theo. Đây là một sự kiện dành cho Nhóm Phát triển, tất cả các thành viên của Nhóm Phát triển đều phải tham dự. Scrum-Master thường tham dự nhưng chỉ để đảm bảo Nhóm Phát triển thực hiện đúng công việc này chứ không trực tiếp tham gia điều hành hay phát biểu đóng góp vào nội dung của sự kiện. Prod- uct Owner và một số người khác có thể tham dự nhưng chỉ được lắng nghe và không đóng bất cứ vai trò nào trong sự kiện này. Buổi Scrum Hằng ngày cần được diễn ra tại một địa điểm và khung thời gian cố định để giảm thiểu sự phức tạp. Thời điểm tổ chức được Nhóm Phát triển lựa chọn sao cho thuận lợi nhất đối với tất cả các thành viên. Thường thì các nhóm lựa chọn thời điểm Scrum Hằng ngày là đầu buổi sáng để khởi động cho một ngày làm việc mới. Việc lựa chọn thời điểm tùy thuộc vào nhóm, điều quan trọng là đảm bảo sự kiện này luôn luôn diễn ra đúng thời điểm đã lựa chọn nhằm tạo ra thói quen và không biến nó thành một sự kiện phức tạp. Nội dung buổi Scrum Hằng ngày chỉ gói trong khoảng thời gian 15 phút để các thành viên Nhóm Phát triển trả lời 3 câu hỏi: • Tôi đã làm được những gì từ buổi Scrum Hằng ngày trước cho tới bây giờ? • Tôi sẽ làm những gì từ bây giờ tới hôm sau? • Tôi đang gặp những khó khăn gì? Có một vấn đề đối với các Nhóm Phát triển khi thực hiện Scrum Hằng ngày đó là thảo luận sâu trong suốt buổi Scrum Hằng ngày, đặc biệt khi phát hiện ra vấn đề nào đó. Hãy đảm bảo mỗi thành viên chỉ trả lời ba câu hỏi trên, việc trao đổi giải quyết các vấn đề có thể thực hiện ngay sau khi Scrum Hằng ngày kết thúc. Việc này giúp đảm bảo thời lượng của buổi trao đổi không kéo dài quá 15 phút đồng thời giữ tập trung vào việc đồng bộ và phối hợp công việc giữa các thành viên thay vì giải quyết vấn đề. Scrum Hằng ngày được khuyến nghị người tham gia đứng thay vì ngồi để tăng sự tập trung. Đó là lý do sự kiện này còn được gọi là Standup Meeting. Nhiệm vụ của ScrumMaster trong Scrum Hằng ngày 38 Nhiệm vụ của ScrumMaster trong buổi Scrum Hằng ngày là đảm bảo điều kiện thuận lợi cho Nhóm Phát triển tiến hành sự kiện, ví dụ như địa điểm, đảm bảo nhóm giữ đúng khung thời gian tối đa 15 phút, ghi nhận các trở ngại được nhóm phát lộ, đảm bảo các thành viên tập trung vào đồng bộ và phối hợp công việc hiện tại thay vì sa đà vào các vấn đề khác. Ngoài ra, ScrumMaster quan sát trong suốt cuộc họp để cảm nhận không khí và những vấn đề tiềm ẩn. Nếu các vấn đề được phát biểu, ScrumMaster ghi lại và có thể quản lí trong một Danh sách Trở ngại (Impediment Backlog) và giải quyết dần. Để tháo gỡ khó khăn, đôi khi ScrumMaster phải vận dụng kĩ thuật hỏi 5 lần tại sao (5WHYs). 5WHYS Đây là kĩ thuật có nguồn gốc từ phương thức sản xuất Toyota đã được dùng phổ biến trong hầu hết các lĩnh vực. Để điều tra nguyên nhân và các lựa chọn để giải quyết vấn đề, người điều tra sẽ hỏi 5 lần liên tiếp tại sao. Dưới đây là ví dụ về một cuộc điều tra nguyên nhân của việc trả lại hàng: Vấn đề: “Khách hàng phàn nàn về chất lượng lô hàng vừa giao” Tại sao 1: Tại sao chất lượng lô hàng kém? Trả lời: Do nguyên vật liệu đầu vào kém chất lượng. Tại sao 2: Tại sao chất lượng nguyên vật liệu kém? Trả lời: Do trong quá trình sản xuất bị thiếu nguyên vật liệu nên phải mua bổ sung từ nguồn khác. Tại sao 3: Tại sao lại thiếu nguyên vật liệu? Trả lời: Do ước tính không chính xác nên mua thiếu. Tại sao 4: Tại sao lại ước tính nguyên vật liệu chưa chính xác? Trả lời: Do không biết yêu cầu nguyên vật liệu của bản thiết kế mới. Tại sao 5: Tại sao lại không biết yêu cầu nguyên vật liệu của thiết kế mới? Trả lời: Tại vì chưa làm thử trước đó. Thay vì quay ra đổ lỗi cho khách hàng ngay từ đầu, hoặc đổ lỗi cho đồng nghiệp, hoặc đổ lỗi cho bên giao hàng, chúng ta có thể nhìn ra vấn đề gốc rễ nằm ở quy trình sản xuất để khắc phục và tránh lặp lại. Một ngộ nhận thường thấy là dùng 5WHYs luôn cho ra nguyên nhân gốc rễ (root cause), kì thực 5WHYs chỉ giúp ta tìm ra được những khả năng. Và từ đó ta có thể ra quyết định chính xác hơn. Những lỗi nên tránh khi Scrum Hằng ngày #1. Scrum Hằng ngày trở thành là một buổi báo cáo công việc cho ScrumMaster #2. Scrum Hằng biến thành nơi dành cho ScrumMaster cập nhật tiến độ công việc #3. Scrum Hằng ngày biến thành một phiên thảo luận để giải quyết vấn đề #4. Scrum Hằng ngày diễn ra quá xa nơi làm việc #5. Nhóm Phát triển không thấy giá trị của buổi Scrum Hằng ngày #6. Các thành viên thường báo cáo là không gặp vấn đề gì #7. Scrum Hằng ngày không diễn ra như là một thói quen, hôm làm hôm bỏ SƠ KẾT SPRINT 39 Buổi Sơ kết Sprint sẽ được tiến hành khi thời gian triển khai Sprint đã hết để kiểm tra phần tăng trưởng đạt được trong Sprint vừa qua. Đây là một hoạt động thanh tra và thích nghi đối với sản phẩm đang được xây dựng. Kết thúc buổi Sơ kết Sprint lộ trình sản phẩm và Product Backlog có thể được điều chỉnh để phù hợp hơn với tình hình phát triển mới. Tham dự buổi Sơ kết Sprint có Nhóm Phát triển, Product Owner, ScrumMaster. Ngoài ra, Product Owner có thể mời thêm những người khác nếu phù hợp, chẳng hạn như khách hàng, người dùng, các bên liên quan, các lãnh đạo, và bất cứ ai quan tâm. Tất cả những người tham dự đều hoàn toàn tự do trong việc đưa ra các câu hỏi và đóng góp ý kiến của mình. Khung thời gian của buổi Sơ kết Sprint là một giờ tương ứng với một tuần làm việc của Sprint. Có nghĩa là, đối với Sprint 4 tuần thì thời gian tối đa là 4 giờ, với Sprint 2 tuần là 2 giờ. Bạn cũng có thể điều chỉnh thời lượng họp theo nhu cầu thực tiễn của nhóm. Một nội dung quan trọng của buổi Sơ kết Sprint là Nhóm Phát triển và Product Owner trao đổi với nhau để tìm hiểu về tình hình, ghi nhận các khuyến nghị của nhau. Đây là cơ hội để Product Owner tìm hiểu và nắm tình hình của sản phẩm và của Nhóm Phát triển. Còn đối với Nhóm Phát triển đây là cơ hội để tìm hiểu và nắm tình hình của Product Owner và của thị trường. Nội dung của Sơ kết Sprint như sau: 1. Product Owner trình bày Mục tiêu Sprint 2. Nhóm Phát triển trình bày kết quả đã hoàn thành 3. Trực tiếp sử dụng sản phẩm 40 Tiến trình một cuộc họp Sơ kết Sprint Một số lưu ý: 1. Không trình bày những tính năng chưa “hoàn thành” 2. Các phản hồi được đưa ra – Product Backlog có thể được đánh giá lại độ ưu tiên 3. Product Owner nên sử dụng kĩ thuật kiểm thử chấp nhận để đánh giá các tính năng. 4. Đây không là buổi demo sản phẩm. Trong thực tế, việc demo sản phẩm chỉ là một nội dung của buổi Sơ kết Sprint. Nếu chỉ tập trung vào demo sản phẩm thì sẽ bỏ qua một nội dung quan trọng khác liên quan đến việc thảo luận và cộng tác giữa các thành viên tham gia. Từ đó gây hiểu nhầm và thực hiện sai mục đích thực sự của buổi Sơ kết Sprint đó là thanh tra và thích nghi sản phẩm đang được xây dựng. Danh mục kiểm tra Sơ kết Sprint □ Buổi Sơ kết Sprint có thiếu thành viên nào trong Nhóm Scrum? Buổi Sơ kết Sprint có diễn ra đúng thời gian? □ Nhóm Scrum có trình bày Mục tiêu Sprint? □ Nhóm Phát triển chỉ trình bày những hạng mục đã hoàn thành? Product Owner và các bên liên quan có kiểm tra sản phẩm? □ Product Owner có đưa ra quyết định chấp nhận hoặc không chấp nhận phần tăng trưởng? □ Product Owner và các bên liên quan có đưa ra phản hồi về sản phẩm? Buổi Sơ kết Sprint có giữ đúng khung thời gian? CẢI TIẾN SPRINT 41 Cải tiến Sprint là sự kiện diễn ra ở cuối Sprint, ngay sau buổi Sơ kết Sprint. Mục đích của sự kiện này là để thanh tra và thích nghi quy trình làm việc. Nói cách khác là để tìm ra cách làm tốt hơn trong Sprint tới. Nhóm Phát triển và ScrumMaster bắt buộc phải tham gia buổi Cải tiến Sprint. Product Owner có thể tham gia hoặc không. ScrumMas ter cũng có thể mời những người khác cùng tham gia sự kiện này nhằm đóng góp ý kiến cho nhóm. Thời gian tối đa dành cho buổi Cải tiến Sprint là 3 giờ đối với Sprint 1 tháng. Đối với các Sprint ngắn hơn thì thời gian thường ngắn hơn, khoảng 45 phút tương ứng với một tuần làm việc của Sprint. Chẳng hạn, với Sprint 2 tuần thì khung thời gian là khoảng 1 giờ 30 phút. ⇒ Dừng và Nghĩ Giả sử sau mỗi Sprint, nhóm của bạn cải thiện năng suất 3%. Hãy tính xem, cả năm nhóm bạn có thể tăng năng suất được bao nhiêu? Dừng và nhìn lại, tìm kiếm các cải tiến và xây dựng tổ chức học tập. 42 Cây cầu Cải tiến, theo Rachel Davies Cần có một người giữ vai trò hỗ trợ cho buổi Cải tiến Sprint, người này có thể là ScrumMaster hoặc một người khác bên ngoài nhóm. Hoặc có một cách làm khá phổ biến đó là trao đổi chéo giữa các ScrumMaster, có nghĩa là ScrumMaster của nhóm này hỗ trợ Cải tiến Sprint cho nhóm khác. Các hoạt động chính của buổi Cải tiến Sprint là: • Liệt kê những điểm đã làm tốt • Liệt kê những điểm đã làm chưa tốt • Đưa ra một vài hành động cải tiến • Kế hoạch cải tiến cho Sprint sau Cách đơn giản nhất là cả nhóm cùng họp và bắt đầu với câu hỏi “Chúng ta đã làm tốt những gì?”, rồi trả lời câu hỏi tiếp theo “Có điều gì cần loại bỏ?” và “Có điều gì có thể làm tốt hơn? Bằng cách nào?”. Rồi sau đó cùng thống nhất một kế hoạch hành động cho Sprint sau. Có rất nhiều kĩ thuật cụ thể để tiến hành buổi Cải tiến Sprint. Ví dụ như Glad-Sad-Mad, SpeedBoat, v.v.. Trong đó, kĩ thuật đơn giản và được sử dụng phổ biến là Glad-Sad-Mad. Danh mục kiểm tra Cải tiến Sprint □ Nhóm Phát triển có mời thêm thành viên khác tham gia? □ Có thành viên nào của Nhóm Phát triển thiếu không? Lý do vì sao? Địa điểm, các văn phòng phẩm đã được chuẩn bị? □ Buổi Cải tiến có diễn ra đúng giờ? □ Mọi thành viên đã rõ mục đích, quy tắc và cách thức thực hiện buổi Cải tiến? □ Có rà soát các hành động cải tiến ở những Sprint trước? □ Đã chuẩn bị các dữ liệu cần thiết cho việc cải tiến? □ Có thành viên nào không tham gia tích cực vào buổi làm việc? Tại sao? □ Có hành động cụ thể được tìm ra? □ Buổi Cải tiến Sprint có giữ đúng khung thời gian? Các kĩ thuật Cải tiến Sprint 43 Glad Sad Mad 44 SpeedBoat Glad-Sad-Mad Glad-Sad-Mad là một kĩ thuật để thực hiện buổi cải tiến dựa trên việc phân loại các ý kiến của thành viên thành 3 nhóm: Glad (vui mừng), Sad (buồn), và Mad (tức giận). Những hạng mục nào mà thành viên đưa ra cảm thấy hài lòng thì được phân loại vào mục Glad. Những hạng mục nào mà họ chưa cảm thấy hài lòng và có thể cải tiến được thì đưa vào mục Sad. Những hạng mục nào mà gây cản trở nghiêm trọng và mình mong muốn loại bỏ nó ngay thì đưa vào mục Mad. Đây là một kĩ thuật được sử dụng phổ biến trong các buổi Cải tiến Sprint. 43 Cách tiến hành cụ thể như sau: ẩ