“Tinh gọn” Scrum

Những thảo luận gần đây về phát triển phần mềm Agile luôn nhắc đến Scrum, Lean và Kanban – ba công cụ để lập kế hoạch, theo dõi và triển khai các hoạt động phát triển phần mềm. Những phương pháp này thường được những người thực hành Agile so sánh và đối chiếu với nhau và có vài người đã khẳng định Scrum Framework  và Lean Thinking kết hợp với nhau rất tốt trong khi vài người khác lại cho rằng 3 phương pháp phát triển phần mềm là 3 hướng hoàn toàn khác biệt.

Tháng 7-2012 Microsoft tiến hành thanh tra các tính chất “Tinh gọn” của Scrum cùng nhiều cách để giúp nhóm Scrum cải tiến thông qua Tư duy tinh gọn và xuất bản sách trắng “Tinh gọn” Scrum. Tác giả sách trắng là David Starr – David Starr là Chief Software Craftsman tại Scrum.org, ông chuyên nghiên cứu để cải tiến sự chuyên nghiệp của phát triển phần mềm. Ông cũng sáng lập cộng đồng kĩ thuật trực tuyến, ElegantCode.com.

1. Tổng quan

Hiện tại Scrum đã quá phổ biến; trong các nhóm nói rằng đang phát triển phần mềm theo các phương pháp Agile, 92% đang dùng Scrum[1]. Khi đã đạt được những thành công nhờ Scrum, nhiều nhóm bắt đầu tìm cách trưởng thành các kĩ thuật bên ngoài framework Scrum cơ bản. Tài liệu này đưa ra cách mở rộng framework Scrum bằng các kĩ thuật của Lean và Kanban, theo tư duy Kaizen, hay Cải tiến liên tục.

1.1 Scrum

Framework Scrum được Ken Schwaber và Jeff Sutherland giới thiệu năm 1995, là một cách làm việc để nhóm chuyển giao phần mềm theo các phân đoạn lặp và tăng dần. Các nhóm Scrum làm việc theo những khung thời gian được gọi là Sprint, kéo dài tối đa là một tháng, tạo ra các chức năng hoàn thiện chạy tốt sau mỗi Sprint.

Framework Scrum rất dễ hiểu, hiện nay đã rất phổ biến với các nhóm phát triển phần mềm và khách hàng của họ. Scrum tạo ra các nhóm tự tổ chức và liên chức năng tập trung làm việc trong suốt Sprint để chuyển giao một phần tăng trưởng của phần mềm chạy tốt và có thể phát hành được.

Scrum được hệ thống hóa trong Hướng dẫn Scrum, tài liệu mô tả rõ các vai trò, tạo tác và các sự kiện trong Scrum. Hướng dẫn Scrum được các tác giả của Scrum duy trì và có thể download tại Scrum.org.

1.2 Lean

Tư duy tinh gọn (Lean Thinking) là một phương pháp tối ưu hóa hệ thống tập trung vào giảm thiểu lãng phí và cải thiện luồng giá trị tổng quan của một hệ thống. Lean có một lịch sử lâu đời trong lĩnh vực sản xuất và đang dần phổ biến trong phát triển phần mềm những năm gần đây.

Khi được áp dụng vào phát triển phần mềm, Tư duy tinh gọn được thể hiện qua 7 nguyên lý dưới đây, những nguyên lý này được giới thiệu lần đầu tiên trong cuốn sách: “Lean Software Development: An Agile Toolkit”[2].

1. Loại bỏ lãng phí
2. Khuếch trương việc học
3. Quyết định càng muộn càng tốt
4. Chuyển giao càng nhanh càng tốt
5. Trao quyền cho nhóm
6. Tạo ra tính toàn vẹn tự thân
7. Nhìn toàn cảnh

Áp dụng những nguyên lý này vào các phần việc cụ thể để chuyển giao sản phầm phần mềm không phải là mục tiêu cuối cùng. Mọi người không nói “Làm Lean”; ta dùng các nguyên lý của Lean để trợ giúp việc đưa ra quyết định và chọn các kĩ thuật giúp cải tiến tổng thể hệ thống. Ví dụ, kĩ thuật TDD (Test-Driven Development) giúp tạo ra tính toàn vẹn trong phần mềm bằng cách thanh tra từ thời điểm bắt đầu, nhờ đó giúp hiện thực nguyên lý: Đưa tính toàn vẹn tự thân vào quá trình phát triển phần mềm.

1.3 Kanban

Một kĩ thuật bắt nguồn từ Tư duy tinh gọn là Kanban[3], một phương pháp dùng Tư duy tinh gọn làm phương pháp chính thức để loại bỏ lãng phí, chuyển giao chỉ-khi-cần (just-in-time), và phòng tránh người làm việc bị quá sức (overburdening). Không như Scrum, Kanban không phải phương pháp tiếp cận lặp và tăng trưởng dần; thay vì các phân đoạn lặp, Kanban dựa trên 5 hoạt động cốt lõi.

1. Trực quan hóa luồng công việc
2. Giới hạn công việc đang làm (Work in Progress – WIP)
3. Quản lý luồng
4. Minh bạch hóa các chính sách về qui trình
5. Cải thiện sự cộng tác

Mỗi nhóm dùng Kanban lại có những qui trình khác nhau. Phương pháp Kanban chỉ đơn giản là một tập hợp các kĩ thuật để quản lý một qui trình, sau đó chú tâm tối ưu hóa nó. Kanban rất dễ áp dụng vào các qui trình cũ, gồm cả Scrum.

1.4 Scrum và Kaizen

Khi những phần tăng trưởng của phần mềm chạy tốt đã được chuyển giao đều đặn mỗi Sprint, các Nhóm Scrum tìm kiếm những cách mới để cải thiện cách làm việc của mình. Trái tim của Scrum hiệu quả là Kaizen – tư duy cải tiến liên tục. Các nhóm Scrum tốt luôn dùng vô số các kĩ thuật để Kaizen. Các kĩ thuật và công cụ như ước lượng tương đối, phát triển hướng kiểm thử, build tự động, và lập trình cặp thường được các nhóm Scrum sử dụng thuần thục.

Ngoài những thực hành, kĩ thuật, công cụ bổ sung tốt cho Scrum, còn có một mô hình mở rộng Scrum được miêu tả và quản lý tại scrum.org. Mô hình mở rộng Scrum này khuyến khích cộng đồng ghi lại những thực hành bổ sung tốt cho Scrum. Tại thời điểm tôi viết bài này, đã có vài phần mở rộng về việc áp dụng các thực hành Lean vào Scrum được đề xuất. Lợi thế của áp dụng Tư duy tinh gọn vào Scrum là không thể phủ nhận.Không ngạc nhiên, rất nhiều người thực hành Scrum đã nhận thấy năng suất cao hơn và chất lượng tốt hơn khi áp dụng Tư duy tinh gọn vào Scrum.

2. Nhìn Scrum qua mắt kính Lean

Framework Scrum gồm các vai trò, tạo tác và sự kiện dưới đây. Nếu bạn chưa quen thuộc với framework scrum căn bản, hãy đọc Hướng dẫn Scrum rồi quay lại đọc tiếp bài viết này.

Hướng dẫn scrum định rõ các qui tắc để làm việc với các thành phần này, nhưng Tư duy tinh gọn cung cấp một framework để tối ưu hóa hơn nữa việc tương tác giữa các vai trò, tạo tác và sự kiện của Scrum. Nhóm scrum chọn một phần của product backlog để chuyển giao mỗi Sprint, và tập trung vào chuyển giao một phần tăng trưởng với tính năng và chất lượng thích hợp. Tư duy tinh gọn có thể giúp làm mượt luồng công việc trong suốt Sprint và giảm lãng phí của luồng giá trị chung.

Cả Scrum và Lean đều kiên quyết giữ chất lượng ở mức cao để đảm bảo sự thành công của mọi công việc. Để thấy rõ các nguyên lý chung giữa Phát triển phần mềm tinh gọn và Scrum, chỉ cần phân tích các vai trò, tạo tác và sự kiện của Scrum dưới lăng kính của Tư duy tinh gọn.

2.1 Các sự kiện

Ngoại trừ Sprint, vốn là container cho các event còn lại, các sự kiện trong Scrum thực sự chỉ là các cuộc họp. Tư duy tinh gọn thường coi các cuộc họp là lãng phí, và lãng phí thì cần phải bị loại bỏ triệt để.

Điều này có thể dẫn đến kết luận rằng các sự kiện của Scrum là không cần thiết. Tuy nhiên mỗi sự kiện trong Scrum đều được cẩn thận thiết kế để loại bỏ các cuộc họp bất thường làm gián đoạn công việc. Các sự kiện Scrum được thực hiện tốt sẽ giúp giảm bớt các cuộc họp và thời gian xử lý các vấn đề phát sinh.

Mỗi sự kiện trong scrum đều được thiết kể để thanh tra hay thích nghi điều gì đó. Việc thanh tra trợ giúp cho nguyên lý của Lean về khuếch trương việc học và tạo tính toàn vẹn tự thân cho qui trình phát triển. Việc điều chỉnh một kế hoạch, yêu cầu hay những tạo tác khác trong một sự kiện Scrum trợ giúp cho nguyên lý Lean về trì hoãn các quyết định và nhìn toàn cảnh. Bảng dưới đây liệt kê những điều mà các sự kiện Scrum thanh tra và thích nghi.

2.2 Các tạo tác

Các tạo tác của Scrum vốn cần phải đơn giản hết mức có thể và không thể đơn giản hơn nữa. Các yêu cầu, kế hoạch và thậm chí cả phần mềm được nhóm Scrum chuyển giao đạt giá trị cao nhất khi chúng chỉ gồm những chi tiết cần thiết để hoàn thành công việc.

2.2.1 Product Backlog

Trong một thế giới hoàn hảo, chỉ cần dùng lời nói để đưa ra yêu cầu phần mềm. Người làm phần mềm sẽ hiểu rõ hoàn toàn các yêu cầu, không cần các miêu tả trung gian. Điều này hoàn toàn khả thi với những nhóm rất nhỏ có quan hệ gần gũi với khách hàng. Nhưng với những nhóm lớn hơn thì không thể. Việc tạo ra các yêu cầu của chức năng cần làm luôn cần thiết cho việc lập kế hoạch. Lean cho rằng các yêu cầu giống như hàng tồn kho(inventory) – một lãng phí phổ biến theo Tư duy tinh gọn – do đó cần giảm thiểu tối đa chúng.

Trong Scrum, ta quản lý các yêu cầu trên Product backlog vốn cần rất ít các biểu mẫu, việc giấy tờ. Các hạng mục Product backlog không cần phải cực kì chi tiết hay được diễn đạt hoàn hảo

Dù ta cần Product backlog và các yêu cầu để lập kế hoạch làm việc, thì tốt nhất là chỉ viết ra và làm mịn các hạng mục Product backlog trước khi Nhóm phát triển làm hạng mục đó một khoảng thời gian ngắn. Những Nhóm Scrum chuyên nghiệp tránh tạo ra những yêu cầu mà có thể không bao giờ được làm đến.

2.2.2 Sprint Backlog

Trong một thế giới hoàn hảo, ta không cần phải lập kế hoạch. Nhóm phát triển chỉ cần nhận yêu cầu các tính năng cần phát triển, bỏ qua bối cảnh và chi phí của yêu cầu. Dù qui trình làm việc đơn giản này rất mềm dẻo, nó chưa tính đến việc phát triển phần mềm vốn là một công việc phức hợp. Phát triển các sản phẩm phức hợp thì cần có kế hoạch, dù cho kế hoạch đó đơn giản và thiếu chi tiết.

Hướng dẫn Scrum định nghĩa Sprint backlog là một phần của Product backlog gồm các hạng mục được chọn làm trong một Sprint, và một kế hoạch để chuyển giao chúng. Sprint backlog cho thấy các công việc tồn đọng (lãng phí) của dự án trong Sprint, được làm mịn ít nhất là mỗi ngày. Việc làm mịn hàng ngày đảm bảo kế hoạch không trở thành một lời hứa suông và cho phép Nhóm phát triển trì hoãn các quyết định thực thi đến thời điểm muộn nhất có thể.

Nhóm Scrum xây dựng các yêu cầu và kế hoạch chỉ vừa đủ để tối thiểu hóa chi phí. Phương pháp tối thiểu hàng tồn kho này của Lean cho phép nhóm trì hoãn việc ra quyết định và trao quyền cho nhóm tự tổ chức trong Sprint. Thay vì tập trung vào các yêu cầu và kế hoạch, Nhóm Scrum tập trung vào giá trị được chuyển giao trong mỗi Phần tăng trưởng

2.2.3 Phần tăng trưởng

Mỗi Sprint sẽ phải chuyển giao được ít nhất một phần tăng trưởng của phần mềm chạy tốt. Phần tăng trưởng của sản phẩm là tạo tác duy nhất của Scrum không bị coi là lãng phí bởi Tư duy tinh gọn. Dù vậy, phần tăng trưởng sản phẩm vẫn có thể có lãng phí bên trong nó. Lãng phí biểu hiện dưới dạng các tính năng không dùng đến, lỗi, chức năng chưa hoàn thiện, mã khó bảo trì hay thiết kế không tốt.

Nhóm Scrum năng suất cao không ngừng loại bỏ lãng phí trong bản thân sản phẩm. Thường thì điều này được làm thông qua việc thanh tra phần tăng trưởng thường xuyên trong suốt Sprint và giữ chất lượng luôn ở mức cao. Điều này chính là cốt lõi của nguyên lý Tính toàn vẹn tự thân trong Lean.

Nhóm Scrum cũng được lợi khi chuyển giao các phần tăng trưởng mà tuân thủ đúng các nguyên lý của Lean. Scrum yêu cầu phần tăng trưởng luôn được thanh tra tại buổi Sơ kết Sprint. Những phản hồi về phần tăng trưởng tại buổi Sơ kết Sprint chính là nền tảng để khuếch trương việc học.

2.3 Các vai trò

Các vai trò trong Scrum đã được điều chỉnh cẩn thận để trao quyền cho nhóm Scrum và cân bằng các áp lực bên trong nhóm. Để ScrumMaster, Nhóm phát triển và Product Owner cộng tác làm việc thành công thì cần mọi người đều hiểu rõ vai trò của mỗi người trong nhóm. Việc cộng tác này đảm bảo mọi thành viên trong Nhóm Scrum hiểu toàn bộ hệ thống Scrum và làm minh bạch bất kì quyết định thiên vị cho một vai trò nào làm ảnh hưởng đến nhóm Scrum.

Đồng tác giả của Scrum, Jeff Sutherland, lưu ý rằng yếu tố căn bản để triển khai Lean thành công là trí tuệ tập thể từ nhân viên và những nhân viên được trao quyền cùng các quản lý được hỗ trợ. Nhóm phát triển tự tổ chức của Scrum là thể hiện của nhân viên được trao quyền trong Tư duy tinh gọn, những người có thể khuếch trương việc học trong tổ chức mà không cần sếp phải áp đặt.

ScrumMaster là một vai trò độc đáo chỉ Scrum có, được Hướng dẫn Scrum mô tả như sau:

Trách nhiệm của ScrumMaster là đảm bảo Scrum được hiểu đúng và làm đúng bằng cách đảm bảo rằng nhóm Scrum tuân thủ đúng lý thuyết, các kĩ thuật và các luật của Scrum. ScrumMaster là một lãnh đạo phục vụ cho Nhóm Scrum. – Hướng dẫn Scrum, tháng 10-2011.

Một trong những kĩ năng và hoạt động chính của một ScrumMaster là hỗ trợ (facilitation). Trong hầu hết các trường hợp, ScrumMaster điều hành các sự kiện Scrum. ScrumMaster là nhà quản lý, nhưng là quản lý việc áp dụng đúng Scrum chứ không phải quản lý con người.

3. Để Scrum tinh gọn hơn

Tư duy tinh gọn giúp ta sẽ thấy thêm được nhiều vấn đề mà Scrum đã làm lộ ra, tạo lợi nhuận lớn. Tư duy tinh gọn cũng là một cách tốt để duy trì văn hóa Kaizen. Dù các Nhóm Scrum vẫn đang phải nghiên cứu cách để ứng dụng Lean vào Scrum nhưng có nhiều kĩ thuật dần trở nên phổ biến nhờ được chứng minh đã giúp cho các Nhóm Scrum hiệu quả hơn.

Có nhiều kĩ thuật và cách làm phổ biến được dùng trong các công việc trí óc trực tiếp thỏa mãn các nguyên lý Tinh gọn. Dưới đây là một số kĩ thuật và cách để nhận ra chúng trong một Nhóm Scrum.

Danh sách dưới đây không gồm đầy đủ các kĩ thuật mà chỉ đơn giản là các ví dụ về cách Nhóm Scrum dùng các kĩ thuật thường thấy của Lean. Thêm vào đó, mỗi kĩ thuật có thể được áp dụng theo nhiều cách. Chỉ vài kĩ thuật Lean được miêu tả ở đây. Các Nhóm Scrum có thể gặp các tình huống khác so với miêu tả trong bài viết này.

3.1 Loại bỏ lãng phí

Loại bỏ lãng phí có lẽ là kĩ thuật Lean căn bản nhất. Lean coi tất cả những điều không cực kì cần thiết để tạo ra sản phẩm là lãng phí. Những lãng phí thường gặp trong phát triển phần mềm gồm có:

1. Các tính năng hoặc mã không dùng đến
2. Lỗi dẫn đến việc phải làm lại
3. Thời gian chờ đợi giữa 2 việc
4. Công việc bị luân chuyển giữa 2 người, nhóm hay qui trình
5. Yêu cầu quá chi tiết
6. Yêu cầu không đầy đủ
7. Giao tiếp không tốt hoặc chậm chạp

Vài lãng phí là không thể tránh khỏi, thậm chí là cần thiết. Theo định nghĩa khắt khe nhất, tài liệu về yêu cầu là lãng phí. Thẻ chỉ mục của một yêu cầu không được chuyển giao đến khách hàng, do đó nó là lãng phí. Bản thân thẻ yêu cầu không phải là một tính năng của sản phẩm mà chỉ là đại diện cho phần việc cần làm để tạo ra tính năng. Thẻ yêu cầu tồn tại để giúp nhà phát triển nghĩ kĩ và theo dõi công việc của họ. Dù hầu hết các nhóm coi đây là hoạt động cần thiết, ta có thể dễ dàng nhận thấy sự lãng phí của nó.

Dù có vài lãng phí là cần thiết, phần lớn các lãng phí có thể được giảm thiểu, tối ưu hóa, hay loại bỏ. Vài lãng phí trong luồng giá trị phát triển phần mềm, ví dụ như chờ quá lâu để checkin mã, có thể bị nhìn thấy và loại bỏ dễ dàng. Có những lãng phí khác của các nhóm phát triển phần mềm, ví dụ việc tạo ra nhiều tài liệu yêu cầu trước khi bắt đầu phát triển đã trở thành văn hóa công ty thì sẽ cần rất nhiều thời gian và công sức để thay đổi hoàn toàn.

3.1.2 Tình huống

Scrum đã được áp dụng 6 tháng. Nhóm phát triển tạo ra phần tăng trưởng của phần mềm sau mỗi Sprint hai tuần và tất cả các chỉ số chất lượng có chiều hướng tích cực.

3.1.3 Cách tiếp cận Lean

Các ScrumMaster họp để thảo luận về cách huấn luyện nhóm nhằm nâng cao năng suất và chất lượng. Một ScrumMaster đề nghị loại bỏ lãng phí theo Tư duy tinh gọn. Các ScrumMaster khác đồng ý cùng tìm kiếm các lãng phí và chia thành 2 loại, 1 loại là lãng phí có thể loại bỏ ngay lập tức và 1 loại cần thời gian để loại bỏ.

Lãng phí trong loại đầu tiên có thể được loại bỏ bởi ScrumMaster hay Nhóm phát triển mà không cần xin phép hay chờ đợi gì. Loại còn lại được cho vào một “Backlog lãng phí” là những lãng phí cần nhiều thời gian hay công sức để loại bỏ. Dưới đây là ví dụ một bảng 2 loại lãng phí:

Với danh sách trên, các ScrumMaster sẽ cùng nhóm Scrum của mình đưa ra những hành động để cải tiến ngay lập tức. Dù có các ScrumMaster huẩn luyện nhóm để đạt được chất lượng cao hơn, bản chất tự tổ chức của các nhóm Scrum yêu cầu các nhóm phải tự mình coi trọng các thay đổi và tạo ra các kế hoạch để thực hiện chúng.

Phiên Cải tiến Sprint là một diễn đàn chuyên dùng để chia sẻ các ý tưởng cải tiến và tìm cách thực hiện chúng. Những phiên Cải tiến Sprint hiệu quả thường tạo ra được các kế hoạch để thực hiện cải tiến, giúp tạo thành văn hóa Kaizen. Việc loại bỏ hoặc giảm bớt lãng phí ở backlog có thể cần giúp đỡ bên ngoài nhóm Scrum. ScrumMaster sẽ chịu trách nhiệm về những lãng phí này bởi vì công việc của ScrumMaster bao gồm cả việc cải tiến cách áp dụng Scrum và nâng cao tính linh hoạt của tổ chức.

4. Giới hạn việc đang làm

4.1 Tình huống

Một Nhóm phát triển gồm 5 thành viên đã dùng Scrum 12 tuần, hoàn thành 3 Sprint 4 tuần với các kết quả khác nhau. Trong khi phần tăng trưởng có chất lượng tốt hơn so với trước khi triển khai Scrum, mọi người có vẻ hoàn thành được ít việc hơn và Nhóm phát triển vẫn chưa hợp tác tốt. Dù trong các phiên Scrum Hằng ngày các thành viên đều thấy mỗi người đang làm việc riêng, mỗi người một việc nhưng tình hình vẫn không có gì tiến triển.

Trong phiên Lập kế hoạch Sprint, Nhóm phát triển tạo một danh sách “To Do” gồm các công việc cần làm để chuyển giao các hạng mục Product Backlog của Sprint. Cách làm này tạo ra một Sprint Backlog và một cơ chế để theo dõi tiến độ Nhóm phát triển trong Sprint.

Nhóm phát triển đặt một bảng công việc trong khu vực làm việc của nhóm để theo dõi tiến độ trong suốt Sprint. Trong Sprint trước, ScrumMaster chụp ảnh của bảng công việc mỗi ngày trước khi bắt đầu Scrum Hằng ngày. Dưới đây là một vài bức ảnh.

ScrumMaster cùng Nhóm phát triển xem những bức ảnh này. Có vài điều có thể thấy rõ, ví dụ:

• Số phần việc đang làm lớn hơn số thành viên của Nhóm phát triển
• Trong ngày 2, một nhà phát triển đã kéo tất cả phần việc của Feature C vào cột “In progress” và để mặc chúng trong suốt Sprint
• Feature B đến tận cuối Sprint mới được làm và đã không được làm xong.
• Tính năng C được làm trong suốt Sprint nhưng chưa hoàn thành. Người làm tính năng C gặp khó khăn khi không ai giúp đỡ giải quyết vấn đề mình không nắm rõ. Dù cô đã kêu gọi sự giúp đỡ trong buổi Scrum Hằng ngày nhưng không ai giúp vì mọi người đều tập trung vào việc của mình và không thấy có trách nhiệm với Tính năng C.
• Các tính năng được xếp vào Sprint Backlog theo thứ tự của độ ưu tiên được đặt ra trong buổi Lập kế hoạch Sprint và Product Owner đã cực kì thất vọng về việc không hoàn thành Tính năng B trong Sprint, dù đã được xếp thứ tự cao hơn những tính năng đã được chuyển giao phía dưới.
• Có nhiều tính năng được làm cùng một lúc, khiến cho nhiều phần mã nguồn cùng thay đổi trong Sprint dẫn đến lỗi và phải làm lại khi tích hợp do các nhà phát triển vô tình sửa mã của nhau.

Tất cả những vấn đề trên đều do Nhóm phát triển làm quá nhiều việc cùng một lúc. Khi phải chuyển đổi giữa các việc và để ý quá nhiều việc cùng lúc, thành viên nhóm cảm thấy quá tải và ngập trong công việc trên Sprint Backlog. Do đó mỗi người đều chuyên tâm vào việc của mình và làm việc cá nhân thay vì như một thành viên của nhóm.

4.2 Áp dụng Lean

Trong buổi Cải tiến Sprint, ScrumMaster giải thích về giới hạn việc đang làm, Nhóm phát triển quyết định sẽ thử áp dụng kĩ thuật này. Nhóm phát triển quyết định tuân theo 3 qui tắc để giảm lượng việc đang làm trong Sprint tiếp theo:

1. Các tính năng trên Sprint Backlog sẽ được làm theo thứ tự từ trên xuống dưới.
2. Chỉ cho phép tối đa 3 việc cùng làm tại một thời điểm. Nếu có công việc thứ 4 được đặt vào cột In progress, nhóm sẽ tạm dừng để tìm xem tại sao lại xuất hiện nút thắt cổ chai trong luồng công việc.

ScrumMaster tiếp tục chụp ảnh bảng công việc trong suốt Sprint sau. Dưới đây là một vài bức ảnh trong số đó.

Trong buổi Cải tiến Sprint, Nhóm phát triển xem các bức ảnh và nói ra các thay đổi mà họ thấy được trong Sprint trước:

1. Các thành viên Nhóm phát triển cùng nhau làm những công việc phức tạp. Dù đôi khi có những ý kiến khác nhau về cách làm nhưng nhanh chóng được thống nhất và tiến độ chung của nhóm nhanh hơn.
2. Các thành viên bắt đầu hiểu các tính năng của sản phẩm mà trước đây họ không để ý. Mọi người đều thấy có cảm giác cùng sở hữu toàn bộ sản phẩm thay vì mỗi người chỉ tập trung làm những tính năng mà họ nắm rõ như trước kia.
3. Sự phức tạp do thay đổi cùng lúc ở nhiều phần của mã nguồn được giảm bớt rất nhiều. Nhờ đó, năng suất của Nhóm phát triển tăng lên đáng kể.
4. Dù Tính năng E chưa được hoàn thành trong Sprint, tất các các tính năng được chuyển giao đều có độ ưu tiên cao hơn Tính năng E. Product Owner vẫn cảm thấy vui và quyết định phát hành Phần tăng trưởng cho khách hàng dù thiếu tính năng có độ ưu tiên thấp này.

Dù Sprint Backlog được tạo ra sau phiên Lập kế hoạch Sprint đã giới hạn khối lượng công việc cho Sprint, việc giới hạn việc đang làm trong Sprint có thể đẩy nhanh tốc độ làm việc và năng suất cao hơn. Giới hạn việc đang làm trong Sprint cũng làm tăng sự cộng tác và giảm rủi ro do mọi người không hiểu phần việc của nhau.

4.3 Giảm thời gian chờ

Có rất nhiều thời gian chờ trong phát triển phần mềm. Ta có thể dễ dàng tìm thấy loại lãng phí này trong hầu hết các Nhóm phát triển. Các Nhóm Scrum mới thấy rằng họ phải chờ nhiều thứ trong một Sprint, gồm có:

• Sự cho phép làm gì đó
• Một qui trình mất nhiều thời gian để hoàn thành
• Nhận chuyển giao từ một nhóm hay một người khác
• Chờ các kiểm thử chạy hay nghiệm thu xong
• Truy cập vào tài nguyên cần thiết
• Cộng tác cùng người ngoài nhóm

Tệ hơn việc Nhóm Scrum phải chờ đợi là khách hàng và việc kinh doanh phải mất thời gian chờ đợi việc tích hợp, đóng gói và phát hành phần mềm. Vấn đề này tăng lên theo cỡ của bên phát triển. Càng thêm nhiều nhà phát triển hay nhóm vào một dự án thì công sức tích hợp phần việc của họ vào sản phẩm càng tăng cao.

Khoảng thời gian chờ dài nhất trong Scrum là một Sprint. Là vật chứa cho tất cả các sự kiện của Scrum, yêu cầu duy nhất về độ dài Sprint là ngắn hơn hoặc bằng 1 tháng. Điều này giúp giới hạn thời gian chờ để có được một phần tăng trưởng chạy được của phần mềm không dài quá một tháng. Hầu hết các Nhóm Scrum chuyển giao các phần tăng trưởng chạy được thường xuyên hơn.

4.4 Tình huống

Một công ty có 6 Nhóm Scrum phát triển một phần mềm lớn và phức tạp. Mỗi Nhóm Scrum tập trung làm một phần tính năng riêng biệt và phối hợp thông qua một Product backlog chủ. Sprint dài 3 tuần bao gồm cả thời gian tích hợp phần việc của tất các các Nhóm Phát triển.

Trước đây Sprint chỉ kéo dài 2 tuần, nhưng khi sản phẩm to lên thì việc phát triển cũng phức tạp thêm, các nhóm Scrum mới được thêm vào cần nhiều thời gian để tích hợp vào sản phẩm, vì vậy độ dài Sprint được tăng lên để phù hợp với việc tích hợp.

Tuần 3 được mọi người gọi là Tuần tích hợp. Tích hợp các tính năng mới vào mã nguồn chính là hoạt động chính trong thời gian này. Trong Tuần tích hợp, một Nhóm tích hợp được thành lập với các thành viên đại diện từ các Nhóm phát triển để điều hành các công việc tích hợp.

Nhóm tích hợp không nhận thêm tính năng mới trong Tuần tích hợp, mặc dù họ đưa ra những thay đổi nhỏ để xử lý các vấn đề khi tích hợp. Điều này gây ra những lộn xộn khi phải thay đổi mã không theo trật tự nào để phục vụ cho Nhóm tích hợp trong Tuần tích hợp.

Hình vẽ dưới đây cho ta thấy cách quản lý cài đặt thông thường trong một Sprint. Nhóm phát triển tạo một nhánh phát triển riêng khi bắt đầu mỗi Sprint. Nhóm ghép mã vào cuối tuần thứ 2. Trong tuần 3, Nhóm phát triển phục vụ các yêu cầu từ Nhóm tích hợp khi cần.

Dù việc tích hợp trong Sprint là cần thiết, ⅓ năng lực của 6 Nhóm Scrum đang được dùng cho việc tích hợp. Trong thời gian này, phần lớn năng lực của nhóm được dùng cho các công việc ngoài Sprint. Để ý rằng trong ví dụ trên Nhóm 5 không làm gì trong Tuần tích hợp. Tuần tích hợp khiến luồng làm việc của Nhóm Scrum bị gián đoạn do phải liên tục chuyển đổi qua lại việc tích hợp. Vài nhóm đã bí mật tạo nhánh và viết mã để giữ năng suất trong suốt tuần tích hợp, làm tăng độ phức tạp và mất sự minh bạch cần thiết để đưa ra được những quyết định đúng.

4.5 Áp dụng Lean

ScrumMaster của các nhóm thảo luận để đưa ra các phương án giải quyết. Một ScrumMaster nói rằng nhóm mình đã rất thành công khi áp dụng giới hạn việc đang làm trong hai tuần đầu tiên mỗi Sprint. Các ScrumMaster thấy rằng nếu mọi nhóm đều giới hạn việc đang làm xuống chỉ còn một tính năng tại một thời điểm thì có thể tích hợp mỗi khi tính năng đó hoàn thành.

Nếu áp dụng giới hạn này cho tất cả các Nhóm phát triển thì các nhóm sẽ không cần chờ đến cuối tuần thứ 2 mới tích hợp mà có thể tích hợp khi tính năng họ phát triển đạt được đủ các điều kiện trong Định nghĩa hoàn thành.

Trong phiên Cải tiến Sprint tiếp theo, các Nhóm phát triển đồng ý thử tích hợp ngay khi nhóm hoàn thành 1 tính năng. Các nhóm đặt ra một số qui tắc mới:

1. Mỗi Nhóm phát triển giới hạn việc đang làm xuống 1 tính năng tại 1 thời điểm
2. Một tính năng được coi là hoàn thành khi nó đã được tích hợp vào mã nguồn chính
3. Trước khi bắt đầu một tính năng mới, Nhóm phát triển sẽ cập nhật phiên bản mã mới nhất từ mã nguồn chính xuống.

Kết quả của cải tiến trên được thể hiện trong hình dưới đây:

Những qui định mới giúp các nhóm có luồng chuyển giao các tính năng trơn tru hơn. Các Nhóm phát triển không phải ngồi chơi hay bị gián đoạn công việc trong tuần thứ 3 của Sprint nữa khi không còn Tuần tích hợp.

Thời gian tích hợp trong Sprint lúc đầu cao hơn nhưng khi mọi người quen dần với mô hình Tích hợp liên tục này, năng suất của các Nhóm phát triển đều tăng lên. Càng ngày càng có nhiều tính năng được hoàn thành trong một Sprint. Khi một tính năng chỉ được coi là “hoàn thành” nếu tính năng đó đã được tích hợp vào mã nguồn chính thì không còn ai phải băn khoăn về việc khi nào thì tính năng thực sự hoàn thành. Định nghĩa hoàn thành của mỗi tính năng hiện nay đã bao gồm việc tích hợp vào mã nguồn chính. Rủi ro bị lỗi khi tích hợp được giảm thiểu đáng kể.

Cuối cùng, cải tiến này giúp giảm thời gian chờ tích hợp cho các Nhóm phát triển, làm tăng năng suất tổng của các Nhóm phát triển và bỏ đi Tuần tích hợp. Nhờ đó các Nhóm Scrum có thể quay lại với Sprint ngắn hơn, giúp Product Owner có thể phát hành thường xuyên hơn.

5. Trì hoãn cam kết

Trì hoãn cam kết là nguyên lý gốc từ Lean được thể hiện thành một giá trị trong Phát triển phần mềm tinh gọn. Nguyên lý này thường được miêu tả là: “chờ đến thời điểm trách nhiệm cuối cùng” mới đưa ra quyết định.

Việc ra quyết định hành động vội vàng tạo ra rất ít hoặc không tạo ra giá trị, việc suy nghĩ cũng vậy. Khi chờ đến thời điểm buộc phải đưa ra quyết định, ta sẽ có được nhiều thông tin nhất về vấn đề cần ra quyết định. Khi đó ta sẽ giảm được rủi ro đưa ra quyết định sai và có thêm thời gian nghĩ ra các lựa chọn hay cách làm khác.

5.1 Tình huống

Trong phiên Lập kế hoạch Sprint, Nhóm phát triển tạo ra kế hoạch chi tiết để thực hiện các hạng mục trong Product backlog được đưa vào Sprint. Thường thì kế hoạch này sẽ thay đổi trong Sprint khi nhóm có thêm thông tin. Nhóm thấy rằng khi công việc càng kém rõ ràng thì kế hoạch càng hay thay đổi. Biết rằng những yêu cầu chưa được dùng đến là lãng phí, nhóm muốn tránh việc làm lại kế hoạch.

Khi một người cam kết làm một hành động thì phải bỏ qua các lựa chọn khác. Điều này thường khiến người cam kết bỏ đi các ý tưởng. Thường có vài cách để triển khai một tính năng nhưng khi đã chọn được một cách làm, nhà phát triển có thể bỏ qua việc cân nhắc dùng các cách khác để giải quyết vấn đề và những đổi mới tiềm tàng bị lãng phí.

5.2 Áp dụng Lean

Nhóm phát triển quyết định cho vào Sprint Backlog những hạng mục lớn hơn và chưa được làm rõ. Thực tế, nhóm quyết định có thể cho một hạng mục Product backlog vào Sprint mà chưa cần kế hoạch chi tiết cho nó.

Nhóm phát triển chờ đến khi biết thêm nhiều thông tin hơn mới lập kế hoạch chi tiết. Để làm việc này, nhóm chia những hạng mục lớn trong Sprint backlog thành những hạng mục nhỏ hơn khi bắt đầu công việc. Việc trì hoãn lập kế hạch chi tiết cho đến khi thực sự cần thiết cho phép nhóm thay đổi cách làm ngay sát thời điểm thực thi, đảm bảo nhóm làm theo cách tốt nhất có thể thay vì làm theo một kế hoạch không còn phù hợp với thực tế.

Việc trì hoãn giúp nhóm biết thêm nhiều cách làm các tính năng để lựa chọn khi nhóm thực sự bắt tay vào làm . Nhờ nhóm đã hiểu rõ sản phẩm trong khi làm những tính năng trước và có đủ thời gian để nghiên cứu nếu cần.

6. Trực quan hóa luồng công việc

Bước đầu tiên trong phương pháp Kanban đòi hỏi phải trực quan hóa luồng công việc thực sự của nhóm. Điều này tương đồng với nguyên lý “Nhìn toàn cảnh” của Lean và đòi hỏi phải thấy được luồng công việc thực sự chứ không phải là phiên bản lý tưởng được miêu tả trong tài liệu qui trình kinh doanh hay trong một mô hình nào đó. Luồng công việc chỉ có ích khi nó thực sự đã diễn ra.

Khi luồng công việc được trực quan hóa, ta có thể dùng nó để theo dõi công việc. Dưới đây là một mô hình mẫu của một qui trình phát triển theo từng giai đoạn phần mềm, kiểu thác nước với vài tính năng đang được tiến hành cùng lúc.

Các Nhóm Scrum đã dùng cách trực quan hóa luồng công việc này trong nhiều năm để theo dõi công việc trong Sprint. Các nhóm Scrum thường dùng “Bảng công việc” Scrum hay gọi đơn giản là “Bảng Scrum”. Bảng Scrum thường đơn giản hơn so với bảng phía trên, tương tự như bảng dưới đây.

Việc dùng dạng bảng trực quan hóa luồng công việc này là do yêu cầu của Scrum về Nhóm phát triển liên chức năng. Nhóm phát triển liên chức năng là điểm đặc trưng của framework Scrum. Một nhóm liên chức năng có đủ khả năng cần thiết để chuyển giao một Phần tăng trưởng hoàn chỉnh trong mỗi Sprint. Các thành viên trong nhóm liên chức năng làm nhiều bước phát triển phần mềm cùng một lúc.

Các nhóm liên chức năng có thể làm một ít phần việc của mỗi giai đoạn trong khi cùng nhau phát triển một tính năng. Cách làm này rất khác với cách làm theo kế hoạch cố định trong đó các chuyên gia tập trung hoàn thành một giai đoạn tại một thời điểm. Hơn nữa, thành viên các nhóm liên chức năng vẫn có chuyên môn riêng, nhưng tất cả các thành viên nhóm thường cùng làm tất cả những phần việc cần thiết để chuyển giao phần mềm dù cho phần việc đó có nằm trong chuyên môn của thành viên đó hay không. Các nhóm phát triển phần mềm liên chức năng thường đạt được năng suất cao hơn các nhóm có chuyên môn cố định.

6.1 Tình huống

Một nhóm phát triển đang chuyển giao Phần tăng trưởng của phần mềm nhưng các thành viên nhóm không cộng tác tốt. Lập trình viên làm việc riêng trước khi đưa mã cho tester để kiểm thử trước khi kết thúc Sprint.

Với cách làm này, tester chỉ có một khoảng thời gian ngắn cuối Sprint để kiểm thử do vậy đôi khi Nhóm phát triển bỏ qua việc kiểm thử và chuyển giao Phần tăng trưởng mà chưa kiểm thử hồi quy đầy đủ. Dẫn đến những lỗi sau khi phát hành mà lẽ ra có thể được phát hiện sớm hơn nếu được kiểm thử hồi quy đầy đủ.

6.2 Áp dụng Lean

ScrumMaster làm việc cùng nhóm để vẽ ra mô hình luồng công việc thực tế trong Sprint. Dù nhóm dùng Bảng Scrum tại phiên Scrum Hằng ngày, luồng công việc thực tế  vẫn là một qui trình chia thành các bước rõ ràng. Nhóm tạo ra mô hình dưới đây để thể hiện luồng công việc thực sự:

ScrumMaster giải thích với nhóm rằng năng suất sẽ tăng khi làm việc theo nhóm liên chức năng. Dù chưa hiểu hoàn toàn, các thành viên nhóm đồng ý thử cải tiến luồng công việc theo hướng liên chức năng hơn. Nhóm phát triển không thay đổi bảng luồng công việc và vẫn dùng nó để theo dõi công việc trong Sprint nhưng thống nhất sẽ cố gắng hết sức để gộp các bước lại. Theo đó, nhóm tìm những cơ hội để gộp 2 bước thành một, qua đó thay thế việc chuyển giao bằng cộng tác làm việc. Nhóm từ từ thay đổi cách mỗi người làm việc cùng nhau. Tại mỗi phiên Cải tiến Sprint nhóm vẽ lại mô hình theo những cải tiến mà nhóm đã thực hiện trong Sprint.

Đầu tiên, Arnie và Kyle đồng ý cùng làm việc để ghép hai giai đoạn thiết kế và viết mã vào thành một. Hai người thử vài kĩ thuật để cộng tác tốt hơn và nhanh chóng nhận thấy luồng công việc đã thay đổi thành như sau:

Sau đó Nhóm phát triển bắt đầu áp dụng việc viết các kiểm thử hồi qui chức năng trước khi viết mã, tạo thành thay đổi như sau:

Trong vài tháng tiếp theo, Nhóm phát triển tìm kiếm thêm nhiều cách để giảm số giai đoạn trong luồng chuyển giao. Văn hóa của nhóm thực sự thay đổi khi các chuyên gia chia sẻ kiến thức cho nhóm và mọi người cùng tham gia vào các loại công việc để giúp luồng công việc của nhóm trôi chảy hơn. Thành viên nhóm dần thấy mình trở thành những “specializing generalist” trong quá trình cộng tác làm việc.

Khi thành viên nhóm cộng tác nhiều hơn, kiến thức chung về phần mềm đang phát triển cũng tăng lên và các thành viên cũng hiểu rõ hơn về công việc của những người khác. Việc hợp tác này sẽ xóa bỏ ranh giới giữa các giai đoạn làm việc một cách tự nhiên và tạo ra một luồng công việc đơn giản hơn trong Sprint. Nhóm phát triển đã trở thành nhóm liên chức năng và có luồng công việc như sau:

Sau nhiều Sprint cải tiến để loại bỏ các giai đoạn trung gian, nhóm đã tạo thành luồng làm việc đúng chuẩn của Scrum: tất cả những việc đang làm chỉ thuộc về một giai đoạn phát triển duy nhất. Ví dụ trên cho ta thấy quá trình một bảng Kanban được tối ưu hóa hoàn toàn trở thành một bảng Scrum truyền thống.

7. Tạo ra tính toàn vẹn tự thân

Rất nhiều kĩ thuật của nghệ nhân phần mềm tập trung vào việc tạo ra tính toàn vẹn tự thân của mỗi hạng mục trong qui trình phát triển. Các mẫu thiết kế phần mềm (design pattern), các kĩ thuật phát triển kiểm thử trước (test-fist development), tái cấu trúc, và lập trình cặp đều có mục đích tăng chất lượng phần mềm ngay tại thời điểm tạo ra nó. Dùng các kĩ thuật giúp tăng chất lượng ngay từ giai đoạn đầu của quá trình phát triển đảm bảo nhóm không bị phụ thuộc vào việc kiểm tra chất lượng khi “việc đã rồi”.

7.1 Tình huống

Một nhóm phát triển đã thử nghiệm kĩ thuật phát triển kiểm thử trước và áp dụng thành công mẫu Given/When/Then của điều kiện chấp nhận vào các kiểm thử đơn vị được các lập trình viên viết trong khi viết mã.

Nhóm có những bộ kiểm thử đơn vị chất lượng, dễ đọc mà các lập trình viên thường xuyên dùng chúng để thiết kế và kiểm thử mã thông qua kiểm thử tự động.

Dù cách làm này ổn ở mức độ kiểm thử đơn vị, những chuyên gia kiểm thử trong Nhóm phát triển vẫn dùng Microsoft Word để tạo các điều kiện chấp nhận cho kiểm thử chức năng. Sau khi các lập trình viên hoàn thành viết mã cho tính năng, các chuyên gia kiểm thử thực hiện thủ công các kiểm thử này và tìm thấy số lượng lớn các lỗi, các lập trình viên phải sửa lại tính năng rồi kiểm thử lại. Việc này đôi khi khiến nhóm không hoàn thành đươc các tính năng trước buổi Sơ kết Sprint.

7.2 Áp dụng Lean

Sau khi thảo luận về luồng công việc của điều kiện chấp nhận tại phiên Cải tiến Sprint, Nhóm phát triển quyết định làm theo cách sau:

1. Các chuyên gia kiểm thử sẽ tạo các điều kiện chấp nhận bằng các kiểm thử tự động fail mà bên trong chưa được triển khai thay vì bằng file Mircosoft Word.
2. Các kiểm thử tự động mới sẽ chạy hàng ngày vào 5 giờ sáng và 3 giờ chiều, xuất ra các báo cáo về các kiểm thử pass và fail. Các kiểm thử mới được tạo luôn bị fail.
3. Khi lập trình viên bắt đầu làm một tính năng mới, anh ta sẽ viết mã chi tiết cho các kiểm thử chấp nhận trước.
4. Các lập trình viên sẽ cộng tác với chuyên gia kiểm thử khi viết mã chi tiết cho các kiểm thử để đảm bảo viết đúng nội dung của kiểm thử
5. Tính năng chỉ được coi là hoàn thành khi các kiểm thử pass
6. Tất cả các kiểm thử phải pass khi kết thúc Sprint

Sau vài Sprint làm theo cách này, lượng lỗi và sửa lỗi đã giảm xuống. Nhóm phát triển theo dõi các báo cáo kiểm thử tự động hai lần một ngày và nhận thấy xu hướng pass và fail của các kiểm thử. Họ tạo một báo cáo về xu hướng pass và fail của các kiểm thử chấp nhận trong 2 tuần của Sprint theo như đồ thị dưới đây.

Nhóm phát triển thấy rằng xem xét báo cáo này tại các phiên Scrum Hằng ngày có giá trị hơn cả Burndown chart. ScrumMaster sau đó công nhận đồ thị mới này là một phần thiết yếu trong Sprint backlog.

Hướng dẫn Scrum nói rõ rằng Sprint backlog là một tập hợp các hạng mục trong Product backlog được chọn đưa vào Sprint cùng với một kế hoạch để chuyển giao chúng. Với Nhóm phát triển này, kế hoạch chuyển giao được tạo thành từ các kiểm thử chấp nhận fail, nhóm theo dõi tiến độ thông qua số kiểm thử pass và fail. Cùng với các công việc trên Sprint backlog, các kiểm thử có thể được thêm vào, xóa đi hay chỉnh sửa trong Sprint. Khi một kiểm thử được tạo ra thì tính năng tương ứng có thể hoàn thành sau vài ngày.

Việc dùng các kiểm thử tự động hiện tại đã trở thành yêu cầu và cơ chế kiểm thử hồi qui các tính năng nghĩa là các kiểm thử đã trở thành yêu cầu của phần mềm. Các công việc làm trong Sprint trở thành quá trình viết mã để vượt qua các kiểm thử tự động. Kĩ thuật phát triển kiểm thử trước này đã định hình lại suy nghĩ của nhóm về Scrum và nhúng việc xác nhận yêu cầu vào quá trình phát triển, nhờ đó tạo nên tính toàn vẹn tự thân cho sản phẩm.

Rất nhiều phần trong Scrum phù hợp với các nguyên lí của Lean. Khi Nhóm Scrum đã thành thục và tìm kiếm cách để cải tiến Scrum, họ thường dùng Tư duy tinh gọn làm công cụ hiệu quả để tạo ra nhiều giá trị hơn khi dùng mô hình phát triển lặp và tăng dần.

Dù những kĩ thuật cụ thể có thể thay đổi, việc liên tục chú ý vào cải tiến là tối quan trọng để giữ các Nhóm phát triển “khỏe mạnh”. Framework Scrum đủ linh hoạt để kết hợp với các phương pháp cải tiến của Lean cũng như Kanban. Soi xét Scrum thông qua mắt kính của Tư duy tinh gọn thường dẫn đến chất lượng tốt hơn, năng suất cao hơn và ít lãng phí hơn.

Chủ động tối ưu hóa cách làm Scrum của một nhóm có thể sẽ gặp khó khăn.Khi tìm kiếm các cách cải tiến, đừng để sự hoàn hảo trở thành kẻ thù của vừa đủ tốt.

Làm hoàn hảo Scrum không quan trọng bằng việc chuyển giao phần mềm có chất lượng cao được khách hàng coi trọng. Vì vậy, trước tiên mọi người hãy tập  trung vào những việc giúp cải thiện sản phẩm mạnh nhất.