12/08/2018, 13:03

Cơ bản về Scrum

Scrum là một phương pháp phát triển phần mềm theo mô hình linh hoạt (Agile) dùng để quản lí quá trình phát triển sản phẩm. Nó sử dụng một chiến lược phát triển sản phẩm linh hoạt cho phép team có thể tự vận hành bằng cách khuyến khích không gian làm việc chung và sự cộng tác chặt chẽ giữa toàn ...

28-scrum-600x279.gif

Scrum là một phương pháp phát triển phần mềm theo mô hình linh hoạt (Agile) dùng để quản lí quá trình phát triển sản phẩm. Nó sử dụng một chiến lược phát triển sản phẩm linh hoạt cho phép team có thể tự vận hành bằng cách khuyến khích không gian làm việc chung và sự cộng tác chặt chẽ giữa toàn thể thành viên trong dự án.

Nguyên lí cơ bản của scrum là sự nhận thức ra rằng trong quá trình phát triển, khách hàng có thể thay đổi những yêu cầu của họ một cách thường xuyên (requirements volatility). Nó sẽ nảy sinh rất nhiều khó khăn nếu làm theo các phương pháp truyền thống là tuần tự và tuân thủ nghiêm ngặt theo kế hoạch ban đầu. Vì vậy, scrum sử dụng "chủ nghĩa kinh nghiệm" (empirical), cho rằng các vấn đề không thể được hiểu một cách đầy đủ, vì vậy cần tập trung vào việc hoàn thiện sản phẩm thật nhanh, để nhận được phản hồi ngay khi đang phát triển, và cũng là để thích nghi với sự phát triển của công nghệ và sự thay đổi trong việc kinh doanh.

Vai trò

Có 3 vai trò chính trong mô hình scrum:

Người chủ sản phẩm (Product owner)

Product owner vừa là đại diện cho team, vừa là "tiếng nói của khách hàng". Product owner viết các yêu cầu của khách hàng, đánh giá và thiết lập thứ tự ưu tiên, và thêm vào trong product backlog. Một team scrum nên có 1 product owner, vai trò này không nên gộp với scrum master. Product owner nên thuộc về business side của dự án, và không bao giờ nên dính dáng hay nói gì về các vấn đề kĩ thuật với các thành viên trong team. Vai trò này tương đương với vai trò "đại diện khách hàng" trong một số mô hình Agile khác.

Giao tiếp là vai trò chính của product owner, khả năng truyền đạt thứ tự ưu tiên và việc thấu hiểu những thành viên của team và thấu hiểu khách hàng là tối quan trọng để chèo lái dự án đi đúng hướng.

Như là bộ mặt của team tới khách hàng, sau đây là những nhiệm vụ mà product owner cần phải làm với khách hàng:

  • Mô tả giải pháp
  • Thông báo về các releases
  • Thông tin về tình trạng của team
  • Tổ chức các milestone review
  • Thoả thuận về thứ tự ưu tiên, phạm vị (scope), vốn, và kế hoạch
  • Đảm bảo product backlog đều được mọi người nhận thức rõ và chính xác

Thấu hiểu là một tổ chất mà một product owner, đó là khả năng đặt mình vào vị trí của người khác. Product owner phải làm việc với rất nhiều người với background, công việc, và mục tiêu khác nhau vì vậy anh ta cần phải nhìn thấy sự khác nhau giữa góc nhìn của những người ấy.

Đội ngũ phát triển (Development Team)

Là một team bao gồm 3-9 thành viên là những người trực tiếp tạo nên sản phẩm (bao gồm những công việc như phân tích, thiết kế, phát triển, test, giao tiếp kĩ thuật,...). Trong scrum, đội ngũ làm việc theo hình thức tự quản lí.

Điều phối viên (Scrum Master)

Scrum Master là người chịu trách nhiệm loại bỏ những trở ngại để team có thể đạt được mục tiêu và hoàn thành đúng hạn. Scrum master không phải là team lead hoặc project manager như các mô hình truyền thống, mà là một người hỗ trợ giúp team tránh khỏi những trở ngại. Trách nhiệm chính của scrum master bao gồm:

  • Giúp product owner duy trì product backlog để đảm bảo những việc cần làm có thể được hiểu rõ ràng.
  • Huấn luyện team làm theo những nguyên tắc scrum
  • Đề cao tính tự quản trong team
  • Giúp team loại bỏ những yếu tố trở ngại từ bên trong hay bên ngoài
  • Đảm bảo các cuộc họp trong team diễn ra suôn sẻ và đều đặn

Một trong những khác biệt giữa scrum master và project manager là project manager có trách nhiệm quản lí con người, còn scrum master thì không. Scrum master cũng không ra lệnh hay tạo ra áp lực cho các thành viên, bởi chúng chỉ gây thêm trở ngại cho dự án.

Luồng công việc (Workflow)

Một sprint (một vòng lặp phát triển) là một đơn vị phát triển cơ bản trong scrum. Nó là một khoảng thời gian làm việc được giới hạn trong thời lượng nhất định. Thời lượng được đặt ra từ đầu mỗi sprint và rơi vào khoảng 1-4 tuần, phổ biến nhất là 2 tuần.

Mỗi sprint bắt đầu bằng việc lên kế hoạch cho sprint đó, nhằm lên danh sách việc cần làm trong sprint (sprint backlog). Và nó kết thúc bằng việc review sprint. Khi sprint kết thúc thì sản phẩm phải là một dạng hoàn thành, nghĩa là nó cần được tích hợp hoàn toàn, test kĩ lượng, viết document đầy đủ và có khả năng đưa đến tay người dùng cuối.

Scrum_Framework.png

Lập kế hoạch

Khi bắt đầu một sprint, team cần tổ chức một buổi họp lên kế hoạch cho sprint bao gồm:

  • Phạm vi công việc trong sprint này
  • Lựa chọn trong product backlog những nhiệm vụ có khả năng hoàn thành
  • Từ product backlog, lập lên sprint backlog cụ thể
  • Tổ chức một buổi họp (thường là 4 tiếng cho 1 sprint 2 tuần):
    • Trong 2 tiếng đầu, toàn bộ team (development team, scrum master, product owner) sẽ thống nhất những nhiệm vụ trong product backlog cần giải quyết trong sprint lần này
    • 2 tiếng sau, phân tích những nhiệm vụ trên thành những nhiệm vụ cụ thể hơn để lập sprint backlog
  • Khi mà development team thống nhất được sprint backlog, đồng nghĩa việc họ phải cam kết sẽ phải hoàn thành trong vòng sprint đó.

Họp hàng ngày (Daily scrum)

Mỗi ngày trong một sprint, team sẽ họp daily scrum (hoặc stand-up, còn ở Framgia thường tổ chức team-meeting vào mỗi sáng)

  • Tất cả các thành viên trong development team cần làm như sau:

    • Bắt đầu họp vào đúng giờ, kể cả khi chưa đủ người
    • Nên họp vào cùng thời điểm hàng ngày (ở Framgia thường họp vào lúc 8:00 sáng)
    • Giới hạn trong vòng 15 phút
  • Trong buổi họp mỗi thành viên cần trả lời 3 câu hỏi sau:

    • Tôi đã làm gì hôm qua giúp cho team đạt được sprint goal?
    • Tôi sẽ làm gì hôm nay giúp cho team đạt được sprint goal?
    • Tôi có thấy trở ngại gì ngăn cản tôi hoặc team đạt được sprint goal không?

Những trở ngại sẽ được ghi lại bởi scrum master và chọn ra một người có trách nghiệm xử lí vấn đề. Không bàn chi tiết về vấn đề này trong buổi họp hàng ngày.

1200px-Daily_sprint_meeting.jpg

Review

Kết thúc mỗi sprint, team cần thực hiện 2 buổi họp: Đánh giá (Sprint Review):

  • Review những công việc đã hoàn thành và chưa hoàn thành
  • Demo những việc đã hoàn thành đến khách hàng
  • Buổi họp này thường kéo dài 2 tiếng cho 1 sprint 2 tuần

Nhìn lại (Sprint retrospective):

  • Nhìn lại những gì đã diễn ra trong sprint vừa rồi
  • Hai câu hỏi: Những gì đã diễn ra tốt trong sprint vừa rồi? Những gì có thể cải tiến trong sprint tới?
  • Buổi họp này thường kéo dài 1.5 tiếng cho sprint 2 tuần

Tham khảo

Wikipedia: Scrum_(software_development)

0