Nêu các trò chơi của những người tham gia vào scrum quy trình


Các khái niệm kiến thức cơ bản của mô hình scrum mà bạn nên nên nắm được để phát triển dự án. Mọi vai trò, phương tiện, nghi thức như thế nào sẽ được trình bày cụ thể trong bài viết này.

Với những dự án đòi hỏi khả năng thay đổi, cập nhật, điều chỉnh thường xuyên, phát triển liên tục. Tiêu chí quan trọng nhất là: sao cho nhanh nhất có thể đưa ra được các tính năng đến người dùng. Những dự án mà không đòi hỏi mọi thứ về yêu cầu phải đầy đủ ngay từ đầu, làm theo từng bước phân tích ⇒ thiết kế ⇒ code ⇒ test (Waterfall):

  • Chú trọng vào con người và sự tương tác giữa các thành viên hơn quy trình và công cụ
  • Chú trọng vào ứng dụng chạy tốt hơn là tài liệu đầy đủ (Spec)
  • Chú trọng đáp ứng được thay đổi hơn là tuân theo kế hoạch.

Các khái niệm của scrum

1. Các role, vị trí trong mô hình scrum (scrum roles)

  • Product owner (PO): Là người phụ trách sản phẩm, có quyền hạn trong việc quyết định tính năng của sản phẩm, quyết định thứ tự ,độ ưu tiên trong quá trình phát triển dự án. Khi team gặp phải tranh cãi về yêu cầu dự án, kỹ thuật, luồng chương trình mà không thông nhất được thì PO sẽ là người ra quyết định cuối cùng. PO cũng là người trả lời các câu hỏi của team về sản phẩm. Thông thường vị trí này sẽ là khách hàng ( người thuê làm sản phẩm trong dự án outsourcing ) và khách hàng này phải hiểu quy trình, cách thức làm Scrum. Product owner cũng là 1 thành viên của team. Trong trường hợp khách hàng không thể tham gia như một PO thực sự thì vị trí thay thế có thể là project manager hoặc BrSE, BA: người đóng vai trò phụ trách liên lạc với khách hàng trực tiếp và thường xuyên. Một điều rất quan trọng khi áp dụng mô hình scrum là: khách hàng phải biết và chấp nhận áp dụng mô hình này. Với scrum team, thời gian ban đầu áp dụng thì tiến độ có thể chậm và cả team sẽ tiến bộ dần theo thời gian. Khách hàng phải hiểu và chấp nhận điều đó, tránh can thiệp quá sâu vào tiến độ và quy trình của scrum team.
  • Scrum master: Là người hỗ trợ cho Product owner và team. Scrum master không quản lý team, mà giúp team giải quyết những vấn đề cản trở, quấy nhiễu cho việc đạt được mục tiêu của team. Đảm bảo các luật lệ quy tắc do team đưa ra phải được tuân theo. Ví dụ: khi 1 thành viên trong team bị gọi nhờ sang support dự án khác thì Scrum master sẽ đứng ra đề thương thuyết điều chỉnh và có thể là từ chối support nếu dự án của mình không cho phép. Hoặc đơn giản là pha trà buổi sáng cho anh em nếu trong team bảo uống trà buổi sáng sẽ làm việc hiệu quả hơn Mô hình chuẩn thì vị trí Scrum master có thể là bất kỳ ai trong team và có thể luân phiên thay nhau làm (nếu muốn). Ở VN vị trí scrum master thường là PM hoặc team lead. Nhưng có sai lầm rất hay gặp đó là: hoặc là khi daily meeting một mình ông scrum master nói hoặc là theo kiểu hỏi đáp ông scrum master hỏi member khác đáp --> Hãy để mọi người trong team tự nói và người nói đầu tiên thì là random bất cứ ai.
  • Scrum team: là toàn bộ thành viên còn lại của dự án. Scrum team đòi hỏi khả năng tự tổ chức, tự quản lý công việc theo cam kết và trách nhiệm đã hoàn thành công việc. Thường bao gồm 7 người. Tối thiểu là 3 và tối đa là 9. Các thành viên trong team thường đủ các vị trí để tạo nên sản phẩm: BA, tester, programmer, desinger...

2. Các đối tượng, phương tiện của scrum ( Artifacts)

  • Product backlog: toàn bộ danh sách các yêu cầu, tính năng của sản phẩm. Danh sách này sẽ được cập nhật thường xuyên bởi PO và bất kỳ ai trong team Độ ưu tiên thứ tự của các tính năng sẽ được PO quyết định.
  • Sprint: 1 giai đoạn của dự án với thời gian cố định. Độ dài của 1 sprint sẽ được team và PO quyết định. Thông thường là từ 1 - 4 tuần.
  • Sprint backlog: các tính năng của sản phẩm sẽ được làm trong 1 sprint. Việc chọn các tính năng nào nên làm và thứ tự ưu tiên sẽ do PO lựa chọn, team cùng thảo luận ở buổi sprint planing. Team có quyền bỏ bớt hoặc đưa thêm tính năng vào trong sprint dựa trên thứ tự mà PO đưa ra dựa trên đánh giá thời gian. Lưu ý là scope - phạm vi của sprint không được thay đổi.
  • Planing poker: quân bài ghi các con số để cho điểm đánh giá các tính năng trong 1 sprint
  • Velocity (Burn down chart): biểu đồ thể hiện kết quả mà team đã làm được trong 1 sprint.

3. Các nghi thức trong scrum (Ceremonies)

  • Sprint planing meeting: Làm khi bắt đầu 1 sprint, PO thường sẽ mô tả và đưa ra thứ tự của các item trong Product backlog. Scrum team có thể đặt câu hỏi cho PO để hiểu hơn về sản phẩm. Sau đó team sẽ thảo luận và lựa chọn các item sẽ làm được trong sprint này.
  • Daily meeting: thực hiện hàng ngày và từng thành viên trong team nếu các vấn đề để trả lời cho 3 câu hỏi
    • Hôm qua làm gì?
    • Hôm nay sẽ làm gì?
    • Có gặp vấn đề gì không?

Lưu ý ở đây là chỉ nên nói theo kiểu mô tả ngắn, nêu vấn đề chứ không nên đi sâu vào mô tả chi tiết, rồi trình bày giải pháp bla bla.. Các vấn đề gặp phải hay thảo luận sẽ được làm sau buổi daily meeting này với những người liên quan. Để tránh mất nhiều thời gian của cả đội.

  • Sprint review/Demo meeting: Được thực hiện khi gần kết thúc 1 sprint: trong buổi này team sẽ show( demo) các tính năng đã làm được trong sprint. Team và PO sẽ review và quyết định những task nào được coi là xong (done). Với những feature chưa done sẽ được đẩy trở lại product backlog và xếp lại thứ tự.
  • Sprint retrospection meeting: thực hiện gần khi kết thúc 1 sprint sau buổi sprint review: Cả team sẽ nhìn lại công việc trong sprint này để cải thiện và đạt hiệu quả hơn trong sprint tiếp theo. Có thể sử dụng các tool để thu thập các con số thông kê về số point( điểm estimate cho các feature ) thực hiện được, số bugs phát sinh. Team cùng thảo luận về tech, về quy trình, cách thức làm việc trao đổi, best practice để có thể làm tốt hơn.

4. Các rule cần định nghĩa trong scrum

  • Enough to start: không chú trọng vào quy trình tài liệu, làm thế nào để có thể đưa ra được sản phẩm sớm nhất.
  • Definition of done: Đưa ra định nghĩa của team 1 task, 1 tính năng như thế nào được coi là hoàn thành.
  • Time box: giới hạn thời gian của sprint , của các buổi meeting phải tuân thủ đúng như thời gian đưa ra. Để đảm bảo scrum team hoạt động ổn định.

5. Giới thiệu các nguồn tham khảo

digital.ai:rất hay và dễ hiểu, có animated motion minh họa 

Agile and Related Methodologies (My experiences and experiments) ~ Agile related methodologies (Scrum , XP, Kanban Lean Systems and Software)

Theo viblo.asia

Japan IT Works

Trong bài trước chúng ta đã nắm được cơ bản về các vai trò (Role) trong SCRUM những nó chưa được mô tả chi tiết để bạn có thể hình dung được trách nhiệm cũng như yêu cầu của mỗi Role. Trong bài này chúng ta sẽ cùng xem chi tiết hơn những mô tả công việc của các Role để hiểu rõ hơn về chúng.

1. Product Owner

Về định nghĩa Product Owner là người sở hữu sản phẩm, hiểu rõ nhất về sản phẩm và các yêu cầu của sản phẩm. Thông thường vai trò này được đảm nhiệm bởi khách hàng. Nếu khách hàng không có người thực hiện việc này thì có thể người đóng vai trò Business Analyst của công ty phần mềm hoặc của đơn vị tư vấn thực hiện vai trò này. Product Owner chịu trách nhiệm về yêu cầu đầu ra của sản phẩm và là người chấp nhận sản phẩm.

Chúng ta sẽ xem xét trách nhiệm của Role này để hiểu hơn về yêu cầu công việc của họ.

Theo http://scaledagileframework.com Product Owner có các trách nhiệm sau:

– Quản lý Product Backlog:  Product Owner là người chịu trách nhiệm chính trong việc xây dựng, hiệu chỉnh và duy trì Product Backlog.  Product Backlog chứa chủ yếu là các User Stories (chức năng) cộng thêm các defect (lỗi phát sinh) và một số công việc liên quan khác. Nó đóng vai trò quan trọng trong việc đưa ra sản phẩm có chất lượng, tiến độ dự án cũng như giảm thiểu các rủi ro.

– Định nghĩa Sprint Backlog: Product Owner chịu trách nhiệm Review, xác định thứ tự ưu tiên và hiểu rất rõ về backlog nên sẽ là thành phần quan trọng trong cuộc họp Sprint Planning. Product Owner cũng là người thông qua cuối cùng cho Sprint Backlog.

– Giám sát thường xuyên quá trình xây dựng các Stories: Trong quá trình phát triển các chức năng nếu cần bất kỳ sự thay đổi nào thì Product Owner luôn chịu trách nhiệm chính trong việc thông qua các thay đổi đó.

– Xét duyệt các chức năng được đưa ra trong mỗi phiên bản: Product Owner còn chịu trách nhiệm xét duyệt các chức năng có trong mỗi phiên bản Release.  Điều này bao gồm việc kiểm tra các chức năng có đáp ứng được các yêu cầu hay không? Có qua được qui trình kiểm thử không? Có đảm bảo chất lượng và khả năng sử dụng hay không?

– Sắp xếp các giai đoạn Release (PSI/release: Potentially Shippable Increment): trong quá trình phát triển theo SCRUM, dự án sẽ liên tục Release theo từng giai đoạn và Product Owner có vai trò quan trọng trong việc sắp xếp thời gian, các chức năng Release cũng như phối hợp Demo cho khách hàng, các nhà đầu tư.

– Tham gia và chuẩn bị cho quá trình hoạch định: Như một thành viên mở rộng của bộ phận quản lý, Product Owner có trách nhiệm trong việc phối hợp để hoạch định quá trình xây dựng sản phẩm, ước lượng, sắp xếp các sự kiện ra mắt sản phẩm, Demo v….

Ngoài ra, tùy theo từng dự án, product owner có thể tham gia xây dựng tầm nhìn, chiến lược, hoạch định các kế hoạch liên quan cho sản phẩm.

Từ các trách nhiệm đó, chúng ta có thể xác định một số yêu cầu kỹ năng cơ bản của Product Owner như sau:

–          Phải có kinh nghiệm về sản phẩm sẽ phát triển

–          Có kiến thức tốt về quản lý, công nghệ bao gồm cả kiến trúc, thiết kế v.v..

–          Hiểu rõ về khách hàng và qui trình nghiệp vụ của sản phẩm

–          Hiểu rõ nhu cầu, chức năng của sản phẩm, mức độ ưu tiên của sản phẩm.

–          Có kỹ năng lãnh đạo và giải quyết vấn đề

–          Phải có kỹ năng giao tiếp tốt cả với khách hàng và nhóm dự án

–          Có khả năng dẫn dắt, động viên nhóm dự án làm việc để họ phấn đầu hoàn thành dự án đúng mục tiêu đề ra.

Như vậy, Product Owner là một Role đòi hỏi có kinh nghiệm, nó nắm một phần quan trọng vai trò của người quản lý dự án trong mô hình truyền thống nhưng khác ở chỗ là tập trung vào sản phẩm. Làm tất cả mọi thứ sao cho sản xuất được một sản phẩm tốt nhất. PM theo mô hình truyền thống có quá nhiều thứ phải quan tâm.

2. SCRUM Master

Scrum Master là người chịu trách nhiệm chính để nhóm phát triển thực hiện đúng các yêu cầu của SCRUM. German Sakaryan đã liệt kê các công việc chính của Scrum Master trên http://www.scrumalliance.org như sau:

  1. 1.       Đảm bảo cho qui trình Scrum được tuân thủ
  2. 2.       Đảm bảo sự tương tác hợp lý giữa PO, Team và Management
  3. 3.       Bảo vệ và động viên Team
  4. 4.       Giúp công tác tổ chức (như họp, hạ tầng v.v..)
  5. 5.       Giúp Team tập trung vào công việc và đạt mục tiêu của Sprint hiện tại
  6. 6.       Làm việc với PO
  7. 7.       Training về Sprint cho Team, PO, Management và tổ chức
  8. 8.       Đảm bảo và giúp cho mọi thứ thông suốt
  9. 9.       Đấu tranh để phát triển một team có năng suất cao
  10. 10.   Hỗ trợ các hoạt động như Team building, phát triển kỹ năng cho các thành viên, xây dựng feedback v.v..
  11. 11.   Phát hiện và giải quyết các vấn đề
  12. 12.   Giúp team học hỏi từ các kinh nghiệm

Về kỹ năng được yêu cầu thì đây là một vị trí yêu cầu về các kỹ năng quản lý. Có thể liệt kê một số các yêu cầu kỹ năng như sau:

–          Am hiểu về SCRUM và các qui trình của SCRUM

–          Có kỹ năng về quản lý, lãnh đạo, xử lý tình huống, giải quyết các mâu thuẩn, động viên, phát huy khả năng làm việc của người khác

–          Có kiến thức cơ bản về kỹ thuật

3. Development Team

Team chịu trách nhiệm chính là phát triển sản phẩm, nó bao gồm các kỹ sư phần mềm làm việc cùng nhau.  Tùy theo yêu cầu của từng dự án mà kỹ năng của các thành viên trong team khác nhau. Dưới đây, chúng ta sẽ liệt kê những yêu cầu chung của một kỹ sư phần mềm.

Trách nhiệm của Team:

– Hiểu rõ yêu cầu, phân tích, thiết kế, coding sản phẩm

– Làm việc với PO để nắm rõ yêu cầu, đề xuất giải pháp, yêu cầu thay đổi các stories

– Tham dự các cuộc họp Kick off, Sprint Planning, Sprint Review, Dialy Scrum Meeting

– Nhận công việc, ước lượng và chịu trách nhiệm với công việc của mình về chất lượng, thời hạn hoàn thành

– Sửa lỗi và đóng góp cải tiến sản phẩm

– Hiểu rõ và tuân thủ Scrum Process

Yêu cầu kỹ năng các thành viên dự án:

–          Hiểu và áp dụng được Scrum

–          Có các kỹ năng về phân tích thiết kế, ngôn ngữ lập trình, cơ sở dữ liệu được yêu cầu của một kỹ sư phần mềm

–          Có kỹ năng làm việc nhóm

4. Kết luận

Chúng ta đã tìm hiểu sâu hơn về các vai trò trong SCRUM, hy vọng bài viết giúp các bạn nắm rõ hơn về trách nhiệm và kỹ năng của các thành phần tham gia vào SCRUM.  Tất nhiên, khi áp dụng SCRUM tùy theo đặc điểm của tổ chức mà bạn định nghĩa các vai trò cho sát với thực tế tại đơn vị của bạn.

Sau khi đã nắm cơ bản về SCRUM chúng ta sẽ bàn đến việc chuyển đổi từ phương thức truyền thống sang SCRUM. Bài tiếp theo chúng ta sẽ bàn về “Sự khác biệt giữa phương thức truyền thống và Agile”. Mời các bạn đón đọc.

Bài trước: Thực hành áp dụng SCRUM