Categories
Dev's Corner

Product Owner là gì? Vai trò và nhiệm vụ của Product Owner (PO)

Thành viên nào trong nhóm phát triển sản phẩm linh hoạt (agile product development) cũng có trách nhiệm của riêng mình. Trong số những người này, thì mô tả công việc của product owner (giám đốc sản phẩm) có lẽ là đa dạng và quan trọng nhất.

Tìm hiểu về product owner.
Tìm hiểu về product owner. Ảnh: romanpichler.com

Đội ngũ phát triển sản phẩm vào năm 2021 sẽ hoàn toàn khác với đội ngũ hồi 5 năm trước.

Phương pháp kinh doanh và công nghệ mới đã đưa tới sự thay đổi đáng kể trong cách thức hoạt động của các nhóm phát triển sản phẩm, đồng thời làm cho các vị trí riêng lẻ trong nhóm phát triển sản phẩm được săn đón trong nhiều lĩnh vực công việc.

Product owner là một trong những vị trí có giá trị cao trong một nhóm như vậy. Đây cũng là một vị trí rất đáng để làm việc — xét về kinh nghiệm chuyên môn và mức lương.

Trong trường hợp bạn muốn tạo dựng sự nghiệp như một product owner, điều quan trọng là bạn phải biết thông tin chi tiết về vị trí đó.

Để giúp bạn hiểu thêm về công việc của product owner, bài viết này sẽ cung cấp chi tiết về mô tả công việc cũng như vai trò và trách nhiệm của vị trí này.

Product owner làm gì?

Product owner là thành viên trong đội ngũ phát triển sản phẩm, người đảm bảo rằng mỗi sản phẩm sẽ mang lại giá trị tối đa cho người dùng.

Họ thường giữ vị trí trung tâm trong mỗi chu kỳ phát triển sản phẩm. Ngoài ra, họ có khả năng hoạt động với nhiều vai trò khác nhau trong một nhóm liên chức năng (cross-functional).

Một product owner linh hoạt có thể đảm nhận một số vai trò trong scrum.

Một số trong các vai trò này là:

  • Nhà làm chiến lược kinh doanh (Busines Strategist)
  • Nhà thiết kế sản phẩm lấy người dùng làm trung tâm (User-centric product designer)
  • Nhà phân tích kinh doanh (Business analyst)
  • Nhà quản lý nghiên cứu thị trường (Market research manager)
  • Nhà quản lý dự án (Project manager)
  • Trưởng nhóm phát triển

Ngoài ra, product owner cũng có thể được yêu cầu đảm bảo các thực hành tốt nhất về quản lý tác vụ nhằm giữ vững phương pháp luận agile trong quá trình phát triển.

4 Trách nhiệm chính của Product owner

Như đã nói, một giám đốc sản phẩm đôi khi sẽ được yêu cầu đảm nhiệm một số vai trò, đặc biệt nếu sản phẩm yêu cầu đầu vào từ một chuyên gia đơn nhất.

Công việc của Product Owner.
Công việc của Product Owner.

Tuy nhiên, mô tả công việc product owner năm 2021 có 4 trách nhiệm chính mà bất kỳ ai ở vị trí này cũng phải hoàn thành.

Hãy cùng xem xét các trách nhiệm chính của product owner

1. Xác định Tầm nhìn sản phẩm

Một product owner phải điều hành nhóm phát triển sản phẩm từ góc độ chiến lược. Họ phải nắm rõ mục tiêu phát triển sản phẩm và có trách nhiệm truyền đạt mục tiêu đó cho những người còn lại trong nhóm.

Vì là người chủ chốt trong đội ngũ sản phẩm, họ cần giao tiếp với tất cả các bên liên quan, bao gồm khách hàng, đội ngũ phát triển và quản lý doanh nghiệp.

Điều này là để đảm bảo tất cả mọi người tham gia vào việc định nghĩa và vòng đời sản phẩm đều nắm bắt mục tiêu sản phẩm và những mục tiêu đó phù hợp với mục tiêu doanh nghiệp.

Để xác định Tầm nhìn sản phẩm, PO phải:

  • Duy trì một tầm nhìn gắn kết và duy nhất về sản phẩm
  • Thích ứng với tính chất linh hoạt và nhanh chóng của quy trình phát triển sản phẩm (agile product development)
  • Cập nhật tình hình cho các bên liên quan
  • Tạo một lộ trình phát triển sản phẩm khả thi
  • Đảm bảo tính khả thi của sản phẩm đối với mục tiêu kinh doanh

Nhìn chung, product owner đóng vai trò trung tâm giao tiếp và định hướng chiến lược cho tất cả những ai liên quan đến sản phẩm.

2. Quản lý backlog sản phẩm

Backlog sản phẩm là danh sách việc cần làm của nhóm phát triển sản phẩm cho mỗi lần chạy sản phẩm.

Một product owener chịu trách nhiệm tạo và duy trì backlog sản phẩm. Họ cũng cần đảm bảo rằng backlog luôn được cập nhật dựa trên nhu cầu phát triển của dự án.

Ngoài ra, product owner còn phải làm cho tất cả các bên liên quan tiếp cận được với backlog trong suốt quá trình phát triển.

Để tạo ra một backlog sản phẩm hiệu quả, họ phải:

  • Đưa ra các đầu mục backlog phù hợp với mục tiêu kinh doanh
  • Ưu tiên các đầu mục dựa trên chiến lược sản phẩm
  • Vạch ra các ràng buộc của dự án
  • Thực hiện trình tự phát triển hiệu quả nhất

Nhìn chung, product owner cần liên tục tìm cách tối ưu backlog để đạt hiệu suất sản phẩm và giá trị kinh doanh tốt nhất có thể.

3. Ưu tiên nhu cầu sản phẩm

Phát triển sản phẩm Agile yêu cầu đội nhóm chỉ ra các nhu cầu của dự án và sắp xếp chúng theo thứ tự ưu tiên.

Product owner chịu trách nhiệm phối hợp với phần còn lại của scrum team và sắp xếp ưu tiên các nhu cầu theo 3 khía cạnh: phạm vi, thời gian và ngân sách.

PO thực hiện điều này bằng cách cân nhắc từng mức độ ưu tiên so với mục tiêu và nhu cầu của các bên liên quan.

Trong khi ưu tiên các nhu cầu, PO còn:

  • Xác định rõ bất kỳ và tất cả các ràng buộc của dự án.
  • Xác định khu vực phát triển nào có ít ràng buộc hơn.
  • Xác định sản phẩm nào sẽ được đưa vào phát triển tại thời điểm nào.
  • Lặp lại quy trình sắp xếp ưu tiên cho mỗi lần cải tiến sản phẩm.

Nhìn chung, product owner phải đảm bảo rằng đường thời gian phát triển (timeline) có tính thực tế. Khi đường thời gian được phát triển, họ phải hỗ trợ nhóm phát triển bám sát theo.

4. Giám sát quá trình phát triển sản phẩm

Khi chiến lược, tầm nhìn và các ưu tiên đã được thiết lập, product owner cần giám sát sản phẩm thực tế trong suốt chu kỳ phát triển.

Product owner là người đóng vai trò quan trọng trong mỗi sự kiện phát triển, bao gồm lập kế hoạch, cải tiến quy trình, đánh giá sản phẩm và chạy nước rút.

Để giám sát quá trình phát triển, product owner cần:

  • Làm việc với đội ngũ phát triển để nhận diện, xác định và tổ chức các bước cần thiết cho các lần cải tiến tiếp theo
  • Làm việc với các nhóm để điều chỉnh quá trình phát triển
  • Nhận diện bất kỳ khu vực nào có tiềm năng cải tiến
  • Hỗ trợ giai đoạn thiết kế sản phẩm

Nhìn chung, product owner phải theo dõi sự phát triển trong khi liên tục tìm cách để làm cho các quy trình hiệu quả hơn.

Product owner cần có những năng lực nào?

Yêu cầu năng lực đối với Product Owner
Yêu cầu năng lực đối với Product Owner. Ảnh: visual-paradigm.com

Dưới đây là một số khả năng mà PO cần có để hoàn thành vai trò:

  • Kiến thức tổng quản về agile software development (phát triển phần mềm linh hoạt)
  • Có kinh nghiệm quản lý dự án
  • Khả năng xác định câu chuyện người dùng (user story)
  • Kỹ năng truyền đạt xuất sắc, đặc biệt là với khách hàng và ban lãnh đạo
  • Hiểu biết các nguyên tắc khoa học máy tính (đối với các sản phẩm phần mềm)
  • Khả năng giải quyết vấn đề liên tục
  • Kinh nghiệm làm việc trong các nhóm Agile (nhóm phát triển phần mềm linh hoạt)

Ngoài ra, product owner nên biết về bản chất luôn thay đổi của thị trường phần mềm. Công nghệ phát triển nhanh chóng mang đến một loạt thách thức riêng cho các nhóm phát triển sản phẩm

Điều đó, cùng với sự thay đổi nhu cầu của khách hàng thường là lý do khiến một sản phẩm không tạo được dấu ấn trên thị trường.

Mặc dù phương pháp agile quản lý rất nhiều thách thức, sản phẩm cuối cùng cần một chuyên gia giám sát sự phát triển của nó.

Đây là nơi phát huy khả năng của product owner.

Product owner lý tưởng năm 2021

Product owner là vị trí quan trọng do sự đa dạng về kỹ năng cần thiết.

Trách nhiệm của product owner tương tự như những gì bạn thấy trong mô tả công việc của scrum master hoặc product manager.

Khác biệt duy nhất giữa cả hai là product manager chỉ là một trong nhiều vai trò mà product owner phải thực hiện.

Do đó, đôi khi, nội dung tuyển dụng việc làm cho product owner có thể gây nhầm lẫn — đặc biệt nếu bạn không nhận thức đầy đủ về những gì vị trí đó yêu cầu.

Nếu bạn đang cân nhắc sự nghiệp product owner, hãy đảm bảo là bạn nắm vững mô tả công việc của nó.

Tham khảo: productmanagerhq.com

Categories
Dev's Corner

20 năm Tuyên ngôn Agile

Tháng 2 năm 2021 tròn đúng kỷ niệm 20 năm Tuyên ngôn phát triển Phần mềm Agile – một cuộc cách mạng trên thị trường phần mềm và có tầm ảnh hưởng trên nhiều ngành nghề.

Tuyên ngôn phát triển phần mềm Agile
Tuyên ngôn phát triển phần mềm Agile

Ngay cả khi bản tuyên ngôn không thay đổi, việc áp dụng cách hiểu của nó cũng khác nhau ở mỗi nơi.

Trong bài viết này, chúng ta sẽ xem xét khái niệm về Agile, những thực tiễn đã thay đổi theo thời gian và hướng đi của nó trong một thế giới đang thay đổi.

Tuyên ngôn Agile

Phát triển phần mềm theo Agile
Phát triển phần mềm theo Agile

Chúng tôi đã tìm ra được những cách thức phát triển phần mềm tốt hơn bằng cách thực hiện và giúp đỡ người khác áp dụng chúng. Qua đó, chúng tôi đánh giá cao:

  • Cá nhân và sự tương tác hơn là quy trình và công cụ
  • Phần mềm hoạt động tốt hơn là tài liệu đầy đủ
  • Sự cộng tác với khách hàng hơn là đàm phán hợp đồng
  • Phản hồi trước thay đổi hơn là bám sát kế hoạch.

Mặc dù những hạng mục bên phải có giá trị của chúng, chúng tôi vẫn đánh giá cao những hạng mục ở bên trái hơn.

12 Nguyên tắc Agile

12 nguyên tắc Agile.
12 nguyên tắc Agile. Ảnh: Unsplash
  1. Làm hài lòng khách hàng thông qua việc chuyển giao sớm và liên tục phần mềm có giá trị là ưu tiên cao nhất.
  2. Đón nhận những thay đổi trong yêu cầu, thậm chí thay đổi muộn trong quá trình phát triển. Các quy trình Agile khai thác những thay đổi vì lợi thế cạnh tranh của khách hàng.
  3. Thường xuyên chuyển giao phần mềm hoạt động tốt tới khách hàng, từ vài tuần đến vài tháng, khoảng thời gian càng ngắn càng tốt.
  4. Đội ngũ business và đội ngũ lập trình phải cùng làm việc hàng ngày xuyên suốt dự án.
  5. Xây dựng dự án với những cá nhân có động lực cao. Mang đến cho họ môi trường và sự hỗ trợ cần thiết, đồng thời tin tưởng họ có thể hoàn thành tốt công việc.
  6. Phương pháp hiệu quả nhất để truyền đạt thông tin là đối thoại trực tiếp.
  7. Phần mềm hoạt động tốt là thước đo chính của tiến độ dự án.
  8. Các quy trình Agile thúc đẩy phát triển bền vững. Các nhà đầu tư, lập trình viên, và người dùng nên luôn duy trì nhịp độ phát triển liên tục.
  9. Liên tục quan tâm đến các công nghệ và thiết kế tiên tiến để gia tăng tính linh hoạt.
  10. Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa hoàn thành – là vô cùng quan trọng.
  11. Các kiến ​​trúc, yêu cầu, và thiết kế tốt nhất được tạo ra bởi các team tự quản.
  12. Theo định kỳ, đội ngũ phát triển cùng nghiệm lại cách làm việc hiệu quả hơn, sau đó sẽ điều chỉnh và thay đổi hành vi cho phù hợp.

Những thay đổi trong quy trình phát triển phần mềm Agile

Trong một thế giới đang thay đổi, kỳ vọng về phần mềm ngày càng tăng và lập trình viên độc lập nay đã được thay thế bằng nguyên một đội ngũ lập trình.

Giao tiếp và điều phối trong phát triển phần mềm ngày càng phức tạp
Giao tiếp và điều phối trong phát triển phần mềm ngày càng phức tạp, nên việc bám sát phương pháp truyền thống không còn là lựa chọn tối ưu. Ảnh: Burst

Trong bài “20 Jahre Agiles Manifest – Deftiv den Kinderschuhen entwachsen”, Jutta Eckstein (business coach, change manager) đưa ra danh sách những thay đổi về phát triển phần mềm theo Agile. Trích đoạn:

  • Nếu team đảm bảo rằng các story luôn có cùng size thì việc estimate từng story sẽ không cần thiết nữa.
  • Trong một thời gian dài, các story chỉ được công nhận nếu chúng tương ứng với format Connextra (“As a …, I want …, so …”). Thay vào đó, giờ đây, các story chỉ đóng vai trò như một loại ghi nhớ cho một cuộc hội thoại về nội dung của story (và không có format cho các bản ghi nhớ hội thoại).
  • Flow ngày càng trở nên quan trọng. Điều này bao gồm thực tế là các sprint hay iteration thường không còn đóng vai trò quan trọng nữa. Điều này có nghĩa là các team không lập kế hoạch hai tuần một lần, mà phối hợp hàng ngày theo Kanban những gì có thể hoàn thành và những gì được bổ sung sau từ backlog. Như vậy, việc lập kế hoạch, phản ánh và điều chỉnh có tính liên tục hơn.
  • Với sự gia tăng của tốc độ phát triển phần mềm, những trào lưu mới như DevOps đã góp phần tạo ra một cách nhìn tốt hơn về phát triển phần mềm trong một bối cảnh rộng hơn. Tuy nhiên, không phải lúc nào người ta cũng hiểu được ý tưởng cơ bản của DevOps. Ngày càng có nhiều công ty đặt đội ngũ DevOps bên cạnh đội ngũ phát triển hoặc đảm nhiệm vai trò kỹ sư DevOps. Họ bỏ qua thực tế rằng DevOps là một thái độ, một văn hóa chứ không phải một chức năng, vai trò hay nhiệm vụ đặc biệt.

Jutta Eckstein bổ sung rằng một vài phương pháp vốn là cơ sở của bản tuyên ngôn vẫn còn đóng một vai trò nhất định ở thời điểm hiện tại.

Ví dụ: crystal method (tập trung vào cá nhân và sự tương tác) hoặc phát triển phần mềm mang tính thích ứng.

Extreme Programming (XP) phát triển trong những năm gần đây vì người sáng lập Kent Beck đã quay trở lại sau khi ông vắng bóng trong nhiều năm vì lý do cá nhân.

Cũng cần lưu ý rằng có một sự thiển cận trong nguyên tắc thứ 3 của Tuyên ngôn Agile khi giới hạn tần suất chuyển giao phần mềm xuống còn “một vài tuần” nhưng DevOps và chu kỳ continuous delivery ngày nay cho phép chúng ta release nhiều phần mềm trong một ngày.

Uncle Bob (Robert Cecil Martin) trả lời cho điểm này như sau:

“Vào thời điểm năm 2001, chúng tôi không thể tưởng tượng sẽ làm được gì nhanh hơn vài tuần. Tom Gilb là người duy nhất trong cộng đồng có thể làm được, nhưng ông ấy không có mặt tại cuộc họp. Chúng tôi nghĩ rằng hai tuần là giới hạn thấp hơn và không ai bận tâm đến việc chất vấn điều này, và rõ ràng đây là điểm thiển cận”.

Tương lai của Agile

Agile không còn chỉ được hiểu trong bối cảnh phát triển phần mềm nữa.

Chúng ta có “Scaling Agile” với niềm tin rằng toàn bộ tổ chức cần hoạt động theo các nguyên tắc Agile.

Agile trong doanh nghiệp hiện là một chủ đề ngày càng nhận được nhiều quan tâm và động lực.

Để áp dụng Agile vào các quy trình truyền thống của doanh nghiệp, Bjarte Bogsnes nhấn mạnh một thách thức lớn trong bài “Chuyển đổi Agile và hiện tượng con voi trong phòng” (tựa gốc: Agile Transformation and the Elephant in the Room).

“Thật khó để mở rộng quy mô Agile bằng cách sử dụng cùng một framework và cùng một ngôn ngữ đã hoạt động rất tốt để chuyển đổi phát triển phần mềm. Đối với các giám đốc điều hành, “Scrum” nghe có vẻ giống như một căn bệnh ngoài da, “Sprint” không chỉ việc chạy nhanh hơn, “Slack” không phải nói về sự lười biếng, còn “continuous delivery” không phải là chỉ đến một dây chuyền lắp ráp hiệu quả.
Chúng ta cần một bản dịch, một thứ giúp ban điều hành doanh nghiệp hiểu rõ hơn ý nghĩa của Agile ở cấp độ kinh doanh. Agile trong doanh nghiệp thực sự có ý nghĩa gì trong thực tế?”

Theo Bogsnes, “con voi trong phòng” (một điều hiển nhiên nhưng ai cũng lờ đi) chính là quy trình lập ngân sách.

Vì trước giờ đây được coi là quy luật kinh doanh rồi, nên khó mà thay đổi nó. Nếu nó không được thay đổi, bất kỳ sự chuyển đổi theo hướng Agile nào cũng sẽ gặp khó khăn.

“Quy trình lập ngân sách có lẽ là rào cản cơ bản nhất đối với sự chuyển đổi Agile. Ngân sách hàng năm, quá trình lập ngân sách, và tư duy đằng sau nó đều là phản đề của Agile theo nhiều khía cạnh. Lập ngân sách được xây dựng dựa trên hai giả định cơ bản: tương lai có thể dự đoán được và không thể tin ai được. Còn gì ngược với Agile hơn chứ?”


Nhiều tổ chức trên khắp thế giới đã giải quyết vấn đề này và bổ sung nguyên lý Agile cho các quy trình trong doanh nghiệp bằng cách tuân theo 12 nguyên tắc bên cạnh việc lập ngân sách theo Bjarte Bogsnes.

Thay vì được sử dụng theo nghĩa hẹp của nó là lập kế hoạch và kiểm soát, “ngân sách” có thể là văn hóa lãnh đạo và hệ thống quản lý hiệu suất.

12 nguyên tắc bên cạnh việc lập ngân sách doanh nghiệp theo Agile.
12 nguyên tắc bên cạnh việc lập ngân sách doanh nghiệp theo Agile. Ảnh: Agile Alliance
12 nguyên tắc bên cạnh việc lập ngân sách doanh nghiệp theo Agile (tiếng Việt)
12 nguyên tắc bên cạnh việc lập ngân sách doanh nghiệp theo Agile (tiếng Việt)

Theo Agilemanifesto.org & Rakia Ben Sassi

Categories
Dev's Corner

5 Giá trị của Scrum và cách Scrum Master làm việc

5 Giá trị của Scrum

Scrum là công cụ tạo nên thành công của rất nhiều team trong suốt nhiều năm nay và có thể nói, yếu tố thành công chủ yếu xoay quanh 5 giá trị của Scrum.

Tôi sẽ kể cho các bạn về khoảng thời gian tôi tham gia nhóm nhảy trường trung học nhé.

Trải nghiệm này liên quan ra sao đến Scrum nhỉ? Gambaru sẽ cùng bạn kết nối dữ kiện và hướng đến 5 giá trị cốt lõi và cực kỳ thực tế của Scrum.

5 Giá trị của Scrum và cách Scrum master làm việc
5 Giá trị của Scrum và cách Scrum master làm việc

1. Can đảm

Trong nhóm nhảy, chúng tôi là một nhóm theo đuổi nhiều phong cách khác nhau.

Tôi nhớ có lần một số chị lớp trên đã lên tiếng và đề xuất một số thay đổi cho bài nhảy giáo viên đã chuẩn bị trước đó, sao cho phù hợp hơn với phong cách khiêu vũ cổ điển.

Các thành viên của một Scrum Team có lòng can đảm để làm những gì phải làm và giải quyết những thách thức khó khăn - The Scrum Guide.
Các thành viên của một Scrum Team có lòng can đảm để làm những gì phải làm và giải quyết những thách thức khó khăn – The Scrum Guide. Ảnh: Pexels

Điều gì xảy ra tiếp theo?

Một số bước nhảy đã được điều chỉnh. Hậu bối chúng tôi lúc đó mới nhận ra rằng bạn có thể nói ra suy nghĩ của mình và điều đó thực sự đã giúp cả nhóm gắn kết tốt hơn.

Tương tự, Scrum Team cần sẵn sàng dũng cảm áp dụng văn hóa phê bình mang tính xây dựng và giao tiếp cởi mở.

Bạn có thể làm gì với tư cách là một Scrum Master?

  • Giúp đỡ team – Nếu thành viên trong team chuẩn bị thực hiện một task mới, hãy hướng dẫn họ nếu họ cần giúp đỡ. Khuyến khích, động viên team trở thành một không gian an toàn để mọi người không cảm thấy có trở ngại trong việc yêu cầu hỗ trợ.
  • Hãy tự xây dựng lòng can đảm – Hãy làm gương. Hãy đứng lên bảo vệ lẫn nhau nếu cảm thấy team mình đang gặp áp lực hoặc tinh thần đội nhóm đang đi xuống.

2. Tập trung

Vì các cuộc thi thay đổi chủ đề và phong cách liên tục, chúng tôi phải chuẩn bị các điệu nhảy trong thời gian ngắn và chuẩn bị/biểu diễn chúng với khả năng tốt nhất của mình.

“Hãy luôn nhớ rằng, sự tập trung sẽ quyết định thực tại của bạn.” - George Lucas.
“Hãy luôn nhớ rằng, sự tập trung sẽ quyết định thực tại của bạn.” – George Lucas. Ảnh: Paul Skorupskas – Unsplash

Trong Sprint theo khung thời gian cố định (time-boxed Sprint), team cần phải tập trung vào các mục tiêu đã đặt ra ban đầu.

Bạn có thể làm gì với tư cách là một Scrum Master?

  • Điều phối – Hướng dẫn team bạn giới hạn lại số lượng task và mức độ ưu tiên cho mỗi người trong một Sprint để đảm bảo mọi thành viên đều tập trung.
  • Nhắc lại trọng tâm trong Daily Scrum – Thảo luận với team làm thế nào để cả nhóm đạt được mục tiêu.

3. Cam kết

Cam kết là điều đã thúc đẩy nhóm nhảy của chúng tôi.

Chúng tôi đều có chung mong muốn giành được danh hiệu cấp khu vực và tất cả mọi người đều cam kết thực hiện mục tiêu trên.

“Các cá nhân cần cam kết đạt được các mục tiêu của Scrum Team.” - The Scrum Guide.
“Các cá nhân cần cam kết đạt được các mục tiêu của Scrum Team.” – The Scrum Guide. Ảnh: freepik

Ở mỗi buổi biểu diễn, chúng tôi phải cố gắng hết sức và làm việc cùng nhau.

Chúng tôi phải nghĩ làm thế nào để mang đến màn trình diễn tốt nhất với tư cách là một nhóm nhảy và đồng thời cũng phải trình diễn đạt nhất có thể với tư cách vũ công cá nhân.

Các thành viên một Scrum Team nên cam kết hướng đến tầm nhìn của team và cùng nhau tạo ra các mục tiêu thực tế.

Các team nhỏ trong Scrum Team cần duy trì cam kết với Mục tiêu Sprint và tự tổ chức để đạt được các mục tiêu này trong thời gian Sprint đề ra.

Bạn có thể làm gì với tư cách là một Scrum Master?

  • Điều phối Sprint Planning – Đảm bảo rằng team mình cảm thấy thoải mái với việc lập kế hoạch và có phạm vi để giải quyết các lỗi hay vấn đề trong quá trình thực hiện.
  • Bảo vệ nhóm trước việc phạm vi dự án bị thay đổi, vượt phạm vi (scope creeps/changes) – Là Scrum Master, hãy bảo vệ team khỏi những thay đổi không mong muốn trong Sprint, những thay đổi về Mục tiêu Sprint và cả áp lực không đáng có từ Product Owner.

4. Tôn trọng

Là một team, để thực hiện hết khả năng của mình, chúng ta cần làm việc như một nhóm duy nhất và điều đó chỉ có thể xảy ra nếu có sự tôn trọng lẫn nhau.

"Không ai trong chúng ta thông minh bằng tất cả chúng ta." - Ken Blanchard, Tác giả sách Vị giám đốc một phút.
“Không ai trong chúng ta thông minh bằng tất cả chúng ta.” – Ken Blanchard, Tác giả sách Vị giám đốc một phút. Ảnh: Matthew Henry – Burst

Trong Scrum Team, tôn trọng có nghĩa là tin tưởng các thành viên hoàn thành nhiệm vụ của họ, lắng nghe và xem xét ý tưởng của mọi người cũng như công nhận thành tích của nhau.

Bạn có thể làm gì với tư cách là một Scrum Master?

  • Ăn mừng các thành tựu – Là một team, hãy cùng ăn mừng thành tích lớn nhỏ của nhau.
  • Tôn trọng các cá nhân – Cho các thành viên không gian riêng của mình và tôn trọng những đóng góp của họ cho cả team.

5. Cởi mở

Khi học một bài nhảy mới, nếu ai trong nhóm gặp khó khăn, chúng tôi thường trao đổi, nói chuyện sớm nhất để có thể học và giải quyết mọi vấn đề sớm nhất.

“Scrum Team và các bên liên quan đồng ý cởi mở về tất cả công việc và những thách thức khi thực hiện công việc.” - The Scrum Guide
“Scrum Team và các bên liên quan đồng ý cởi mở về tất cả công việc và những thách thức khi thực hiện công việc.” – The Scrum Guide. Ảnh: Reshot

Khi các thành viên của một Scrum Team sớm nói về những trở ngại họ đang gặp phải, họ có xác suất quyết tâm và tiến bộ cao hơn.

Bạn có thể làm gì với tư cách là một Scrum Master?

  • Hãy trung thực – Điều này phải bắt đầu từ bạn, hãy có những buổi trò chuyện trung thực với cả nhóm.
  • Hãy là tấm lưới an toàn – Là một Scrum Master, hãy tập quan sát những điểm đang gặp vấn đề. Nếu thấy các vấn đề không được đề cập trong các buổi stand-up chẳng hạn, hãy hỏi các thành viên trong team xem họ có đang đi đúng hướng không.

Bạn nghĩ gì về 5 giá trị Scrum này? Mời các Scrum Master tài năng chia sẻ thêm những kinh nghiệm của riêng các bạn ở phần comment phía dưới cho cả cộng đồng Gambaru học hỏi thêm nhé!

Theo Rishika Mittal