Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)?
Last updated: August 27, 2023 Xem trên toàn màn hình
Recommended for you
- 11 May 2021
Khác nhau giữa Padding và Buffer trong quản lý rủi ro dự án 602 - 04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 558
- 18 May 2021 Cây cầu hiện đại vô dụng nhất thế giới và câu chuyện cái kết của thay đổi yêu cầu 489
- 01 Jun 2021 Bản thiết kế sơ bộ (Brief) là gì? 452
- 03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 409
- 01 Jan 2024 Tổng hợp 25 quy luật quan trọng trong quản lý dự án 402
- 03 May 2022 Mô hình Hybrid Agile là gì? 399
- 18 Mar 2021 Kỹ thuật ước lượng dự án phần mềm linh hoạt dựa vào Story Point - phương pháp T-Shirt Sizing 357
- 02 Aug 2023 Tổng hợp một số project tham khảo khi xây dựng các ứng dụng theo mô hình Microservices 311
- 20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 304
- 01 Aug 2021 Hiện tượng Gold plating (mạ vàng) là gì? Tại sao có ảnh hưởng quyết định đến chất lượng dự án? 298
- 01 Aug 2023 Phân tích yêu cầu phần mềm sẽ nhìn vào thực trạng (AS-IS) hay tương lai (TO-BE)? 279
- 28 Jun 2024 Tại sao các kỹ sư IT giỏi nhất lại là những người theo thuyết bất khả tri về công nghệ (technology agnostics)? 248
- 02 Mar 2018 Tại sao ví Scrum như dòng điện xoay chiều? 218
- 14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 212
- 08 Aug 2023 Mất kiểm soát phạm vi dự án (Scope Creep) và hiệu ứng quả cầu tuyết (snowball) 207
- 08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 182
- 12 Sep 2021 Túi càn khôn của lập trình viên Agile cần trang bị những gì? 177
- 10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 166
- 08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 157
- 12 Jan 2024 Tư duy hệ thống trong Quản Lý Dự Án diễn ra như thế nào? 155
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 149
- 24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 146
- 21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 122
- 14 Sep 2021 COQ (Cost of quality) áp dụng cho chất lượng phần mềm như thế nào? 84
- 22 Jul 2020 Quản lý dự án phần mềm trong thực tế và câu chuyện thành công của InfoSys 83
Khái niệm "Sprint Zero" hoặc "Iteration Zero" đã tồn tại trong nhiều thập kỷ. Nó như là một thùng chứa tất cả các hoạt động cần được thực hiện trước Sprint đầu tiên.
Thông thường, các hoạt động này sẽ bao gồm cả việc xây dựng team, thiết lập cơ sở hạ tầng, vị trí hậu cần và những thứ tương tự khác. Hiếm khi sprint zero này thực sự mang lại một sản phẩm có thể bàn giao được. Đây là một chủ đề gây tranh cãi. Nhiều người cho rằng Sprint Zero là bất lợi cho agile process. Trong một số trường hợp, nó có thể dẫn đến water fall trong cam kết của team đối với khả năng bàn giao của mỗi sprint. Trong các trường hợp khác, có thể khiến hình thành một hệ thống team phân cấp mà không phù hợp với cơ cấu tổ chức của Agile (tổ chức phẳng - các vai trò ngang hàng). Sprint Zero thường không phù hợp với các nguyên tắc Lean.
Cho dù chúng ta có thích khái niệm Sprint Zero hay không, tuy nhiên, chúng ta có thể đồng ý rằng có những công việc thường phải làm để chuẩn bị cho sprint đầu tiên mà không hoàn toàn thuộc về sprint đầu tiên đó. Cho dù chúng ta gọi nó là "Sprint Zero" hay “Project before the Project” hoặc thậm chí chỉ là “pre-work” thì các công việc "tiền trạm" vẫn cần được hoàn thành. Bí mật ở chỗ, gần như tất cả các văn bản hướng dẫn pre-work là hướng tới các thành viên của nhóm phát triển.
Còn đối với Product Owner thì họ làm gì? Nếu bạn là Product Owner, trong khi nhóm đang thực hiện tất cả các nhiệm vụ trước khi dự án bắt đầu, thì bạn cần tập trung vào việc làm 5 điều quan trọng dưới đây.
1. Phát triển tầm nhìn sản phẩm
Nếu PO không có một tầm nhìn vững chắc về sản phẩm (làm thế nào để cải thiện vị thế của công ty và giá trị sẽ cung cấp cho thị trường là gì?) thì chưa thể bắt đầu sprint đầu tiên. Trong bất cứ dự án nào, sprint đầu tiên sẽ luôn có một số tầm nhìn,một trong số đó là trăn trở về mục đích phát triển của sản phẩm là gì. Chỉ cần nhớ không đầu tư quá nhiều thời gian vào tầm nhìn ban đầu này, dù là về thời gian hay cam kết. Tầm nhìn ban đầu gần như luôn luôn là sai ở một mức độ nào đó, và nó sẽ là công việc của PO để đảm bảo rằng nhóm đang xây dựng đúng sản phẩm cho thị trường. Điều này thường đòi hỏi PO thiết lập các giả định ban đầu.
2. Xã hội hóa tầm nhìn sản phẩm
Một khi đã có được một tầm nhìn ban đầu, điều quan trọng là PO phải thảo luận với các stakeholder. Trong một môi trường đơn giản, stakeholder có thể chỉ bao gồm các đại diện khách hàng và các bên liên quan triển khai công nghệ. Nếu trong một môi trường có quy mô thì có thể sẽ có thêm một đội ngũ quản lý sản phẩm và nhiều nhóm chức năng khác cần làm việc cùng. Tại sao công việc này rất quan trọng? Bởi vì ngay sau khi dự án bắt đầu sẽ không có thời gian để bảo vệ tầm nhìn của sản phẩm đối với các bên liên quan vì họ có thể có những quan điểm khác biệt, và cả những lợi ích khác nhau. Nếu để rơi vào tình trạng này, sẽ trở nên rất khó khăn đối với các bên liên quan, đối với việc quản lý và đặc biệt là đối với team. PO phải duy trì sự tôn trọng đối với quyền sở hữu sản phẩm của mình, và việc xã hội hoá tầm nhìn ngay từ ban đầu sẽ là một trong những cách dễ dàng nhất để giải quyết vấn đề này.
3. Hiểu rõ vấn đề của các bên liên quan (stakeholder)
Trên thực tế, nhiệm vụ này nghe có vẻ to lớn. Liệu PO có thể thực sự hiểu những vấn đề của stakeholder đến mức mình mong muốn? Tất nhiên là không rồi. Tuy nhiên, điều bắt buộc là phải đủ hiểu để có thể bắt đầu phân phối sản phẩm đáp ứng được nhu cầu của họ. Rốt cuộc, PO sẽ sớm thay mặt stakeholder để quyết định. Những điều tối thiểu PO cần hiểu bao gồm
- Sự hiểu biết về khách hàng (hoặc người dùng cuối): Họ là ai? Các danh mục khác nhau của họ và cách bạn mong đợi họ tương tác với sản phẩm của bạn?.
- Sự hiểu biết về động cơ của khách hàng để mua (hoặc chấp nhận) sản phẩm của bạn, cách thức và lý do tại sao nhu cầu của họ chưa được đáp.
- Một ý tưởng tốt về những gì họ đánh giá và cách họ nhìn bản thân họ. Nếu PO có những trao đổi hợp lý về những vấn đề trên thì Sprint đầu tiên có thể bắt đầu. Hãy nhớ tiếp tục tìm hiểu về các bên liên quan trong quá trình làm việc.
4. Tạo ra một số ý tưởng cho sản phẩm
Xác định phạm vi của Sprint là công việc của team (ví dụ như đối với dự án dựa trên mô hình Scrum), lý do cho điều này là: Nếu PO tự ý đưa ra phạm vi dự án, mỗi sprint sẽ là một dự án có thể kéo dài tới ... một năm. Thay vào đó, hãy cho phép team, những người hiểu về dự án được thực hiện việc này. Tuy nhiên, team sẽ phải bắt đầu từ một điểm xác định, thí dụ với product backlog, và bạn cần có danh sách các item trong product backlog để team có thể lên kế hoạch xem họ cần làm những hạng mục nào trước (sprint backlog), cần bàn giao những gì (deliverable). Những gì bạn cần trước cuộc họp planning meeting đầu tiên là một tập hợp các ý tưởng nhỏ - cung cấp một mức giá trị tối thiểu cho doanh nghiệp của khách hàng.
5. Chỉ viết đủ User Story để hỗ trợ cho lần đầu tiên Release
Một khi bạn có danh sách những ý tưởng nhỏ, hãy chọn một vài ý tưởng và biến chúng thành user story. Bạn sẽ có nhiều thời gian để giải thích chi tiết về các user story này sau, nhưng nếu bạn có một vài lựa chọn và có thể viết chúng ra thì bạn sẽ có một điều kiện tốt để có một buổi sprint planning meeting tuyệt vời trước khi sprint bắt đầu. Một vài lời khuyên ở đây:
- Đừng tạo quá nhiều User story. Bạn nên gặp team trước khi dành quá nhiều thời gian để viết chúng
- Giữ cho user story ngắn gọn không quá chi tiết.
- Đừng lo lắng về các chủ đề lớn hơn (như story map hay road map) ở giai đoạn này. Bạn sẽ không có đủ nội dung để lấp đầy và làm chi tiết chúng.
Nguồn: https://www.frontrowagile.com/blog/posts/125-sprint-zero-for-product-owners
(viblo)
Khám phá thêm các chủ đề sau
Đọc thêm: Hướng dẫn hợp tác viết bài (guest blogging)
Các chủ đề được quan tâm nhiều nhất
CHIA SẺ BÀI VIẾT
