Cập nhật 10:42, 22/08/2023
1353 lượt xem
Admin
Bài viết này dành cho BA/PO/PM/Scrum Master là một bộ kĩ năng quản lý dự án cho việc sprint planning.Để đọc hiểu bài này các bạn cần có kiến thức nền tảng về Agile, Scrum, Sprint, Product Backlog, User Story. Các bạn xem thêm video hướng dẫn của mình về Agile và các thuật ngữ ở đây.
Như các bạn đã biết, BA/PO là người chuẩn bị 100% Product Backlog trước khi kick off dự án. Các ticket này được tạo từ nhiều nguồn khác nhau như Stakeholder, Dev team.. nhưng chắc chắn đều dựa trên Scope of Project đã được define bởi BA/PO và được sự đồng thuận và xác nhận từ các Stakeholder (Sponsor dự án, các stakeholder của các phòng ban, và Project Manager từ công ty BA đang làm việc)
Câu hỏi là khi nào, ở đâu, ai là người tham gia và như thế nào để có thể chia các ticket để thực hiện việc planning các ticket này trong 1 dự án. Mục đích của hành động này nhằm đảm bảo các việc cần làm trong 1 dự án được lên kế hoạch, có mục tiêu rõ ràng. Một dự án thành công không thể chỉ trông chờ vào ngày deadline của dự án mà cần chia nhỏ deadline của dự án thành các milestone để từ đó thực hiện và đạt được mục tiêu. Các milestone này chính là các Sprint ( vòng lặp ). Nếu phát hiện ra rủi ro trễ sprint thì sẽ được phát hiện kịp thời và điều chỉnh thay vì tới cuối dự án. Đây cũng là một trong những lợi ích cao nhất mà Agile tạo ra trong SDLC.
Khi nào thực hiện Sprint Planning?
Tùy theo mô hình mà dự án và công ty bạn đang làm việc triển khai sẽ có thời điểm chia khác nhau.Nếu dự án đang áp dụng Scrum của Agile Methodology thì sự kiện Sprint planning meeting sẽ được diễn ra sau khi BA/PO đã chuẩn bị cho Product Backlog theo Scope of Product.
Sprint Planning meeting diễn ra ở đâu?
Sự kiện này sẽ được diễn ra ở nội bộ công ty. Nơi tập trung hầu hết nguồn lực của đội phát triển cho dự án này và có thể những nguồn lực ngoài.
Ai là người tham gia vào Sprint Planning meeting?
Chính là những tác nhân tham gia vào quy trình phát triển sản phẩm cho dự án này bao gồm BA/PO, QC, Developers, PM/ Scrum Master (Nếu có).
Sprint Planning meeting được diễn ra như thế nào?
Step 1: Chuẩn bị trước ngày này
Trước khi bắt đầu nói chi tiết về buổi meeting này, điều kiện cần là BA/PO phải có trong tay Product Scope, Product backlog. Tất nhiên không thể thiếu 1 ngày quan trọng là Deadline (Ngày Go live). Bây giờ mình sẽ đưa ra các giả định như sau để mọi người hiểu được cơ chế của vấn đề.
1 Print thường sẽ là 2 tuần ( Tương đương 14 ngày )
Vậy tổng số Print cho dự án này là = Tổng số ngày Development/ 14= 53/14= 3,78 Sprints ~ 4 Sprints.
Lúc này, BA/PO đã phân tích và tạo tickets cho 5 modules được ưu tiên nhất của dự án ( Các bạn lưu ý không nhất thiết phải đợi đến khi phân tích đủ requirement và tạo ticket cho dự án thì mới start development được nhé. Thông thường chỉ cần chuẩn bị trước từ 1-2 print là team dev đã có thể start được )
Giả định tiếp theo là BA/PO đã tạo ticket cho 5 modules của sprint đầu. Số lượng ticket là 30 tickets.
Đây là những thông tin BA/PO cần phải có trước ngày Sprint Planning Meeting (Grooming)
Step 2: Lead meeting
Đầu tiên, BA/PO cần chia sẻ cho team hiểu về Scope và mục tiêu của sprint. Nếu như là Sprint đầu tiên thì cần nói chi tiết về mục tiêu dự án, ý nghĩa dự án, ngày Golive, các bên tham gia và làm cách nào để đo lường được dự án. Nếu trong team có PM/Scrum Master thì họ có thể thay BA nói về các thông tin high level của dự án.
Sau khi những người tham gia đã hiểu được mục tiêu và Scope của sprint, BA/PO bắt đầu chia sẻ requirement, giải thích cặn kẽ để team hiểu được mục đích của từng ticket bao gồm tính năng và giao diện đi kèm (Nếu có). Team sẽ đặt các câu hỏi để hiểu rõ hơn về từng ticket. Việc đặt câu hỏi này có thể xuất phát từ bất cứ người nào trong team nhằm tìm ra các thông tin ẩn giấu nhưng không được đề cập trong requirement.
Sau khi đã clear rõ requirement, dev team sẽ cùng nhau thực hiện việc estimation từng ticket. Việc estimate này thường sẽ bằng cách chấm số điểm cho từng ticket. Mình sẽ viết một bài chia sẻ về cách thức chấm điểm cho ticket sau. Output của hành động này là mỗi ticket của sprint sắp diễn ra được chấm điểm đầy đủ. Lúc này ta sẽ có tổng số điểm của sprint cần đạt được. Dựa vào đây để so sánh với số điểm của sprint trước để xét tính hợp lý của mức độ effort cần bỏ ra cho sprint này.
Giả sử sprint trước số điểm thực tế đạt là 30. Vậy sprint này tổng số điểm phải lớn hơn hoặc bằng 30. Tùy theo giai đoạn, nếu dự án có nguy cơ trễ thì có thể tăng điểm bằng cách add thêm ticket từ backlog vào sprint. Tất nhiên có một lưu ý là team dev ngày càng quen với dự án và framework của dự án thì performance cũng sẽ tăng dần đều theo thời gian nên việc tăng số điểm cho từng sprint là hoàn toàn hợp lý. BA/PO dần cũng sẽ học được kinh nghiệm từ việc “canh” mức tăng cho phù hợp. Tất nhiên dựa trên sự quan sát và làm việc với team cũng như biết được năng lực của các bạn dev trong team.
Một lưu ý cho BA/PO nữa đó là Sprint đầu tiên của dự án. Có thể gọi là Sprint 0 ( Sprint chuẩn bị) thường sẽ được plan bằng các chỉ số đo lường của các dự án trước. Sprint này việc đón nhận rủi ro trễ là hoàn toàn bình thường do các bạn dev cần thời gian set up code, môi trường, framework, database cũng như logic và requirement của hệ thống. Ngoài ra, giai đoạn mới bắt đầu tìm hiểu và nhập cuộc thì developer cần thời gian để thích nghi. BA/PO có thể dùng sprint 0, 1 để đo lường năng lực để từ đó planning cho phù hợp. Khi đã chạy vào guồng, tức là lúc này tất cả dev đều đã quen với các item kể trên, BA/PO sẽ tăng “đô” lên để thúc đẩy performance của cả team.
Sau khi estimation cho sprint, BA tiến hành tạo sprint cho dự án sau đó cập nhật ticket vào sprint board.
BA/PO cần đảm bảo ticket đã sẵn sàng cho ngày làm việc tới bằng cách đưa ticket vào Sprint board, sắp xếp thứ tự theo mức độ ưu tiên từ trên xuống dưới ở cột “To Do” của board để hàng ngày khi Daily Meeting, tất cả ticket đã sẵn sàng để pick bởi dev team.
Có một thắc mắc là nếu sprint đã được plan từ trước đó, vậy trong quá trình development mà stakeholder có change requirement hoặc add new requirement và muốn nó phải được diễn ra trong sprint này thì có được không và làm như thế nào?
Với kinh nghiệm cá nhân và góc nhìn của mình thì điều này hoàn toàn được vì đây cũng là ưu điểm của Agile là tính linh động (Flexible) của nó. Nếu new ticket kia mang lại nhiều giá trị hơn ( Ưu tiên lớn hơn) so với các ticket khác thì chúng ta có thể add thêm ticket vào board ( Trường hợp chỉ vài ticket và số point tổng cộng tầm 5-7 point đổ lại). Nếu số point lớn hơn có thể move out các ticket khác cho sprint kế tiếp và thay thế bằng các ticket mới. Và stakeholder cần xác nhận lại Goal mới của sprint cũng như aware được việc impact của những ticket này đến Timeline của dự án.
Một kinh nghiệm nữa là đừng bao giờ plan quá chặt cho 1 dự án với số print mà không có sprint dự phòng. Tức là cần tính dôi thêm 10% ( mức độ này tùy thuộc vào dự án, kinh nghiệm và văn hóa công ty) cho tổng số sprint vì để phòng bị cho các vấn đề phát sinh trong lúc làm dự án như Change requirement, Out of Scope, issue production, issue UAT, mất nguồn lực đột ngột..
P/s: Cảm ơn các bạn đã đọc bài viết. Nếu thấy hay đừng tiếc nút Like, Share và bình luận để lan tỏa niềm cảm hứng tích cực.
Bài viết đều dựa trên quan điểm và kinh nghiệm cá nhân của mình, mong nhận được sự góp ý xây dựng và trao đổi từ các anh chị em trong nghề. Vì một cộng đồng công nghệ Việt Nam hùng mạnh.
Quý Nguyễn – Founder True Skill Center.
Xem qua video hướng dẫn bên dưới nhé.
Riêng đối với PO business và PO toàn diện, trước khi chuyển đổi từ BA qua phải Brainwashing lại bản thân (Tẩy não toàn bộ tư duy gia công) vì các bạn làm BA 1 thời gian sẽ "bị" cái này vào lối mòn tư duy mà ko biết. Mục tiêu lúc nào cũng là tìm hiểu business problem, nghĩ giải pháp rồi bàn giao
Bài viết này được viết hoàn toàn dựa trên trải nghiệm thực tế của bản thân và áp dụng hiệu quả trong cuộc sống của mình, hi vọng nó cũng giúp ích cho các bạn.
Trong bài viết dưới đây, True Skill sẽ giới thiệu cho bạn cách sử dụng phương pháp MoSCoW để ưu tiên các nhiệm vụ của dự án hiệu quả hơn và đảm bảo mọi người đều mong đợi những điều tương tự
“INSPIRED is the authority on how to build a product that customers actually want. It’s not about hiring product managers - it’s about estab- lishing a culture that puts the user first, and builds the organization and teams around that customer to ensure that you are building the best product possible. From CEOs to APMs, this is required reading.” Nguồn: Marty Cagan
Hãy nhập ngay email của bạn vào form bên dưới để được nhận tư vấn trực tiếp từ trung tâm.
True Skill Center ra đời với mong muốn trở thành nơi đào tạo những kĩ năng thực chiến cho thị
trường lao động tri thức chất lượng cao.
Trụ sở chính: 220/66 Xô Viết Nghệ Tĩnh, phường 21, Bình Thạnh, Thành phố Hồ Chí Minh
0374 567 558
quynguyen@trueskillcenter.com