Category: software development

Blog, Development | Apr 26, 2018
PHẦN MỘT
Chúng ta hẳn còn nhớ lần đầu đọc Tuyên ngôn Agile (The Agile Manifesto). Nó đem đến cảm giác cực kì phấn khích. Những giá trị của nó thúc đẩy và gia tăng sức mạnh của đội nhóm. Nó tạo ra giá trị sâu sắc hơn cho khách hàng và đẩy lùi những chuyện vớ vẩn khỏi công việc phát triển phần mềm. Mọi thứ đã đâu vào đấy.
Tua nhanh đến năm 2018, và “Houston, có biến”.
Scrum hữu dụng, và mọi thứ vẫn đâu vào đấy, nhưng… việc áp dụng Agile và Scrum một cách nhanh chóng đã tạo ra một cơn ác mộng cho những người lên kế hoạch ở cấp độ tổ chức (enterprise-level planners) – những người chịu trách nhiệm cho việc ước lượng Epic/Portfolio. Lĩnh vực này đã lấy một thông lệ được tạo ra cho những nhóm nhỏ làm việc mật thiết với nhau một cách đồng bộ – sau đó cải tiến để áp dụng cho số đông.
Một nhóm Scrum trở thành vài nhóm hay hàng chục nhóm, mỗi nhóm có một cách hiểu khác nhau về “thế nào là một Story Point”. Hiện nay, không hề có nhóm nào có cùng trải nghiệm, cơ sở hạ tầng hay các bộ kĩ năng giống với nhóm nào; do đó, không hề có nhóm nào định nghĩa Story Point giống nhóm nào.
Rồi đột nhiên, các quản lý cấp cao cố gắng chia Epic backlog dựa trên hơn 25 diễn giải khác nhau về một Story Point. Càng nhiều nhóm đang làm trên một sản phẩm, ngọn núi phải leo càng lớn [Xin thứ lỗi cho sự châm biếm này]
17 anh chàng ở Snowbird (17 người tham gia cuộc họp ở Snowbird, từ đó đi đến Tuyên ngôn Agile năm 2001 – ND) sẽ nói gì?
Scrum cơ bản sẽ nói rằng đừng cố thử ước lượng một Epic backlog, vì việc đó chỉ phí công và đầy chỗ không chính xác. Các chi tiết chắc chắn sẽ thay đổi, và mọi thứ sẽ lại được sắp xếp lại thứ tự ưu tiên vào phút cuối. Nhưng nói điều đó với Epic/Portfolio Manager đang phải đảm đương việc đưa ra một lịch trình tiến độ để cấp vốn, hẳn bạn sẽ nhận được ánh mắt hình viên đạn!
Ước lượng Epic bị lệch từ số ngày của các nhóm Scrum đơn lẻ khi việc ước lượng vốn vô cùng đơn giản. Các dependency, bộ kĩ năng sẵn có, các công cụ để hoàn thiện công việc được lặp đi lặp lại. Các thành viên riêng lẻ biết về năng lực và giới hạn của từng người. Khi ai đó nói rằng một story là 5 point, mọi người trong team biết chính xác điều người đó ngụ ý là gì. Khi Scrum mở rộng (grew legs), ý nghĩa của “5 points” dần trở nên mơ hồ. Càng thêm nhiều nhóm, càng khó cho các nhà quản lý để diễn giải Story Point. Ở khoảng 10 hay 20 nhóm Scrum… thì tất cả hoàn toàn là một đống hỗn độn! Nếu không có một đường trung đạo (center line) cho việc ước lượng, cả nhóm sẽ trở nên bất ổn rất nhanh.
Điều này làm dấy lên câu hỏi: “Liệu Story Point có còn là cách hiệu quả để ước lượng các Epic trong Scrum?”
Một số người cho là có, bạn vẫn có thể dùng Story Point với framework mở rộng (scaling framework) đúng đắn. Một số khác cho là Scrum đã đi quá xa so với những nguyên lý Agile vì công việc không thể chia nhỏ. Khi quy mô của Scrum tăng lên, làm thế nào để các nhóm có thể thiết lập một tiêu chuẩn thống nhất cho việc ước lượng Epic backlog để những nhà quản lý cấp cao, những bên liên quan và những nhóm khác có thể đồng ý với nhau?
ƯU ĐIỂM VÀ NHƯỢC ĐIỂM CỦA STORY POINTS
Chúng tôi đã có vài cuộc thảo luận nội bộ và đi đến những ưu điểm và nhược điểm của việc sử dụng Story Point đối với việc ước lượng trong Scrum ở cấp cao. Hãy đọc qua danh sách dưới đây và cho chúng tôi biết ý kiến của bạn về chủ đề này, về những điều bạn chưa đồng ý và những chỗ chúng tôi còn thiếu sót nhé.
Ưu điểm: Story Points giúp chia nhỏ những backlog lớn.
Story Points có thể rất hữu dụng với vai trò là một phần của một scaling framework như SAFe và NEXUS. Những framework này cung cấp những phương pháp ước lượng có khả năng mở rộng (scalable estimation techniques) để chia nhỏ công việc ở các cấp độ Epic, Program và Portfolio:
· SAFe xem xét bức tranh lớn về cách công việc đi từ quản lý sản phẩm (Product Management) đến quản trị sản phẩm (Governance), các nhóm Program và các nhóm Dev, rồi đến khách hàng.
· NEXUS thiên về cách tiếp cận từ dưới lên, tập trung vào việc việc hợp nhất nhiều nhóm Scrum làm việc trên cùng một sản phẩm. Thông qua sự minh bạch, NEXUS cố gắng bảo vệ và tăng cường những kết nối giữa các nhóm và giữ cho việc thay đổi đồng bộ nhất có thể.
Từ góc độ chiến thuật, một phương pháp được các nhà huấn luyện khuyên dùng là để cho nhóm đang làm công việc ước lượng đảm đương các cuộc họp về ước lượng (meeting the estimate). Cùng một nhóm đó luôn làm trên cùng một module nên ý nghĩa của các Story Point được duy trì rõ ràng và thống nhất từ Sprint này sang Sprint khác. Nhược điểm là năng lực cho mỗi module (capacity per module) trong mỗi lần phát hành (release) bị cố định, vì các nhóm không thể [đồng thời] nhảy từ module này sang module khác (across the modules). Bạn bị bó buộc trong lượng công việc có thể được hoàn thành trong một lần release cho mỗi module.
Một cách tiếp cận khác là chỉ định một hoặc hai đại diện từ mỗi Scrum để tham gia một buổi họp ước lượng chính thức. Những người đại diện này có thể đưa ra quyết định về các story size mà không cần bắt cả nhóm phải ngừng công việc của mình. Phương pháp này giả định rằng mỗi người đại diện đều có kiến thức về cách nhóm của họ định nghĩa một Story Point, để họ có thể chia sẻ, thảo luận và tìm ra những lý do chung để ước lượng các story. Nhược điểm ở đây là mỗi nhóm Scrum phải tin và làm theo bất cứ điều gì mà những người đại diện mà họ đã chọn đặt ra về ước lượng cho mỗi story. Đồng thời, rủi ro có thể xảy ra là những người đại diện bị ảnh hưởng từ những cách tiếp cận về ước lượng của các đại diện từ những nhóm khác.
Nhược điểm: Đây không phải là Scrum!
Những chuyên gia về Agile sẽ cho rằng các phương pháp này không đại diện cho Scrum. Nếu cùng một nhóm luôn làm trên cùng một module, liệu điều này có đe dọa khả năng mở rộng không? Khái niệm về các nhóm tự quản lý thì sao? Từ quan điểm năng lực, việc giới hạn một nhóm thành một module không thúc đẩy khả năng mở rộng. Điều này không còn là agile mở rộng (scaled agile) nữa. Từ góc độ của nhóm, nếu chỉ có một sự ước lượng mang tính đại diện xa rời với cả nhóm, tính ổn định của nhóm sẽ gặp rủi ro vì (1) người đại diện không có kiến thức đúng về vấn đề dependency hay integration cụ thể hoặc (2) người đó có thể trở nên chịu ảnh hưởng từ những kinh nghiệm của một nhóm khác không phù hợp với cách thức hoạt động của nhóm mình. Trong cả hai trường hợp, người ta lo sợ rằng mọi thứ đang trở nên đi từ trên xuống (top-down) quá mức, tạo ra những cách biệt về tốc độ (Velocity gap) và một đống hỗn độn ngu ngốc trong PMO.
PHẦN HAI:
Trong phần dưới đây, chúng ta sẽ đi qua những ưu điểm và nhược điểm của các story point để thiết lập một cơ sở (baseline) thiết yếu nhằm huy động ngân sách, và liệu chúng có đang bao hàm nhiều hơn so với thứ mà Scrum dự định cho chúng không.
Ưu điểm: Story Points thiết lập một baseline thiết yếu để huy động ngân sách
Story Points đem đến cho nhà quản lý một điểm tham chiếu dữ liệu cơ sở để ước lượng và tính toán tốc độ (Velocity) giữa nhiều nhóm với nhau, vốn là điều mà ai cũng biết là chuyện ác thiết yếu nếu cần gọi vốn cho bất kì dự án lớn nào.
Trong waterfall, các nhà quản lý có thể nói chuyện với các bên liên quan trên phương diện những con số (giờ, ngày, tuần, tháng). Ai cũng có thể hiểu những con số. Chẳng có gì tốn ít hơn một giờ. Khi Internet và Agile xuất hiện, không còn dùng giờ được nữa vì nhiều task có thể được hoàn thành còn nhanh hơn cả thời gian dự định họp để lên kế hoạch cho nó! Mặt khác, một số story có những Timeline và Dependency cần cung cấp tài liệu cho những bên liên quan. Story Point cung cấp cho các nhà quản lý một ý tưởng cơ bản về chỗ mà một story đổ vào spectrum, liên quan đến kinh nghiệm trước đó của một nhóm và cách họ đóng gói nó.
CTO của chúng tôi, Kaushal Amin so sánh việc ước lượng Epic với việc hỏi xem cần bao nhiêu cái thùng (công sức – Effort) để chuyển đồ:
Công ty A nói rằng họ sẽ chuyển hết đồ với 150 thùng. Công ty B có thể chuyển hết với 100 thùng. Nhìn qua thì có vẻ công ty B năng suất hơn, nhưng nếu công ty B dùng những cái thùng lớn hơn thì sao? Công sức cần bỏ ra có thể y như nhau, chỉ là các công ty đó ước lượng “kích thước thùng” (bucket size) khác nhau mà thôi.
Ở cấp độ Program, bạn không thể ép buộc cùng một “kích thước thùng” (bucket size) giữa các nhóm. Tuy nhiên, Story Point có thể giúp các nhóm chia nhỏ công việc đến từng đơn vị chức năng nhỏ nhất để theo thời gian, những người lập kế hoạch cấp cao có thể nghiên cứu và hiểu từng nhóm đang dùng bucket size nào để ước lượng.
Nhược điểm: Story Point [đang] bao hàm nhiều ý nghĩa hơn so với vai trò mà Scrum sắp đặt cho nó
Ưu điểm cũng chính là nhược điểm. Story Point chưa bao giờ được tạo ra với dự định là sẽ trở thành một thước đo hiệu suất. Việc ước lượng Story Point chỉ là ước lượng, không phải dự báo. Nhưng, chúng đang được sử dụng để so sánh năng lực giữa các nhóm với nhau.
Scrum chưa bao giờ dự định bó buộc các nhóm vào một cam kết “làm hay là chết”. Story Point tượng trưng cho một sự ước tính theo kiểu vừa ước đoán vừa lập luận “tốt vừa đủ” về quy mô liên quan trong một dự án. Nếu toàn bộ dự định về tính linh động (intent of Agility) là để cho phép các tổ chức phản ứng với những thay đổi theo kế hoạch, thì chúng ta không có được lợi ích đẩy đủ của Scrum.
Trong phần sau và cũng là phần cuối về ước lượng story point, chúng ta sẽ xem xét những ưu điểm và nhược điểm của story point để tạo điều kiện cho các nhóm nâng cao chất lượng và những vai trò nhất định không hiểu story point từ góc độ kinh doanh.
KAUSHAL AMIN
Chief Technology Officer

Người dịch: Trà Giang, 20180510