Scrum là một phương pháp Agile (phát triển phần mềm linh hoạt) dựa trên cơ chế lặp và tăng trưởng. Scrum được thiết kế để hỗ trợ việc phát triển, cung cấp và cải tiến các sản phẩm phức tạp. Với Scrum, sản phẩm được xây dựng trong một chuỗi các quy trình lặp lại, có tên là vòng sprint. Qua đó, bạn có thể liên tục cải tiến sản phẩm, kỹ thuật, team (nhóm) và môi trường làm việc. Cũng nhờ vậy mà bạn có thể cung cấp giá trị cho khách hàng trong suốt quá trình phát triển.
Scrum là một khung tổ chức công việc (framework) dùng trong các dự án phát triển phần mềm với mục tiêu là chuyển giao các sản phẩm mới đều đặn, sau từ 1-4 tuần.
Theo Scrum.org – đơn vị nổi tiếng giới thiệu các lý thuyết về Scrum, Scrum là một framework giúp chúng ta giải quyết các vấn đề phức tạp luôn thay đổi, mà vẫn giữ hiệu quả và sáng tạo khi chuyển giao các sản phẩm có giá trị cao.
Scrum cũng được tổ chức này nhấn mạnh, không phải là một hệ thống các phương pháp luận (methodology). Mà nó bao gồm các cách thức nhất định để giúp 1 nhóm làm việc cộng tác với nhau trong thực tiễn nhằm chuyển giao sản phẩm phức tạp (như phần mềm).
Scrum khuyến khích team học tập qua trải nghiệm, tự tổ chức các hoạt động của team để giải quyết các bài toán, và reflect – suy tưởng, phản tư về những thành công cũng như thất bại của team để liên tục tìm ra các cải tiến.
The answer: Scrum is just one of the ways to achieve agile thinking. Scrum is in the big Agile umbrella. That big umbrella includes many different methods, ways and practices.
Có thể nói, Scrum là một trong những cách tiếp cận phổ biến nhất hiện nay khi đội nhóm muốn ứng dụng agile vào công việc.
Cần lưu ý rằng Scrum là khung làm việc, còn Agile là mindset. Agile mindset là tư tưởng, tư duy làm việc. Triết lý agile chỉ đề cập đến 4 giá trị và 12 nguyên tắc định hướng giúp phát triển phần mềm một cách linh hoạt, nhanh chóng đưa ra thị trường, chứ không chỉ rõ cụ thể ta nên làm như thế nào khi ứng dụng vào đội nhóm.
Bởi vậy, chúng ta khó có thể trở thành người có Agile mindset ngay trong 1 thời gian ngắn. Nhưng bằng cách sử dụng các framework (trong đó Scrum là 1 loại framework phổ biến), chúng ta có thể rút ngắn quá trình đưa những giá trị và nguyên tắc của Agile vào thực tiễn công việc hàng ngày.
Scrum được xây dựng dựa trên những lý thuyết về quy trình thực tế. Những lý thuyết này dựa trên 3 trụ cột.
Sức mạnh của một dự án hay một công ty nằm ở việc mọi người phối hợp với nhau để hoàn thành mục tiêu, sứ mệnh đã đề ra. Để có thể đẩy thuyền đi đến đích, các team, các thành viên cần được truy cập vào những thông tin hữu ích với họ trong quá trình phát triển sản phẩm.
Trong Scrum đề ra các sự kiện họp như Sprint Planning, Sprint Review, Sprint Retrospective, daily meeting để giúp tăng cường sự tương tác và trao đổi thông tin giữa các thành viên làm việc.
Khía cạnh minh bạch này cũng liên quan mật thiết tới 2 trụ cột còn lại. Sẽ rất khó để có thể thanh tra nếu công việc, quy trình không hiển lộ ra cho người khác biết. Và cũng sẽ rất khó để kịp thời, nhanh chóng điều chỉnh kế hoạch nếu bị thiếu thông tin, hoặc nhiễu loạn thông tin.
Ví dụ:
Daily meeting là lúc để các thành viên trao đổi, tương tác với nhau về công việc, về sản phẩm đang thực hiện. Đồng thời nhìn vào những công cụ trình bày, như Kanban board, thể hiện rõ quy trình, trạng thái của luồng việc sẽ giúp cả độ phát triển và Product Owner hiểu nhau hơn, đồng thời có thể nhanh chóng xử lý các vấn đề vướng mắc hoặc chưa được làm rõ.
Để đảm bảo chất lượng cho sản phẩm, tránh những sự sai khác quá lớn về sản phẩm làm ra thực tế so với sản phẩm mong muốn ban đầu, chúng ta cần phải thanh tra những thứ được tạo ra một cách thường xuyên, định kỳ.
Sự thanh tra được thực hiện ở một thời điểm nhất định, chứ không nên xen ngang vào giữa chừng.
Ví dụ: Các thành viên đội phát triển cùng với Product Owner tham gia Sprint Review, Sprint Retrospective. Đây là các hoạt động thể hiện tính chất thanh tra. Khi ấy họ sẽ thanh tra chính sản phẩm chuyển giao, và các quy trình phát triển sản phẩm.
Khi có sự chệch hướng so với Product Roadmap, hoặc do nhu cầu thị trường thay đổi, sản phẩm và quy trình cũng cần được điều chỉnh nhanh chóng để thích nghi với những thay đổi này.
Ví dụ: Đội phát triển cần thích ứng sản phẩm của mình vào cuối mỗi Sprint, để phù hợp với lộ trình phát triển sản phẩm, với yêu cầu của Product Owner, hay của các Stakeholders
Các giá trị cốt lõi của Scrum được hiểu là những người sống với giá trị này sẽ dễ dàng hơn khi thực hiện Scrum trong công việc. Đó là.
Dũng cảm là một giá trị rất quan trọng mà các thành viên team Scrum cần hướng tới. Đội Scrum hay development team cần phải cảm thấy an toàn để nêu ra ý kiến của mình, để nói không khi cần, và thử nghiệm những điều mới mẻ. Đội phát triển cũng cần sự dũng cảm để thách thức những mô thức cũ, cản trở con đường đạt được mục tiêu.
Scrum coi trọng sự tập trung vào ít thứ. Nghĩa là bắt đầu một thứ và kết thúc nó, hạn chế số lượng công việc đang diễn ra cùng lúc, hạn chế số việc ở trạng thái Doing (limit WIP)
Các thành viên của team làm việc Scrum cần phải có sự cam kết với các mục tiêu của đội nhóm. Họ là người lựa chọn sẽ thực hiện điều gì, và gắn chặt với những điều mình chọn.
Như bạn đã biết, lõi của Scrum là Sprint. Mỗi Sprint đều cần có những mục tiêu rõ ràng trong 1 timebox (từ 1-4 tuần). Đội phát triển có thể chia nhỏ mục tiêu thành các phần có thể xử lý được và bắt tay vào thực hiện công việc. Các thành viên cần đánh giá tính thực tế của các mục tiêu đưa để thống nhất các công việc cần hoàn thành cho phù hợp để họ giữ được cam kết với những thứ mình mong muốn chuyển giao.
Các thành viên trong Scrum team hay đội phát triển cần thể hiện sự tôn trọng lẫn nhau, tôn trọng Product Owner và các bên liên quan (Stakeholders), cũng như Scrum Master.
Các đội nhóm sống với tinh thần Agile cần biết rằng sức mạnh để đạt được mục tiêu nằm ở trí tuệ tập thể, ở cách thức họ cộng tác ăn ý với nhau. Mỗi cá nhân đều có đóng góp nhất định vào mục tiêu của Sprint. Vì vậy, họ cần tôn trọng ý kiến của nhau, ghi nhận nỗ lực của nhau, thậm chí chấp nhận sự không hoàn hảo của các thành viên.
Đội phát triển cần không ngừng tìm kiếm những ý tưởng mới, những cơ hội mới để học hỏi. Một đội nhóm agile cũng cần thành thật với nhau khi cần sự giúp đỡ.
Product backlog là một danh mục các công việc cần hoàn thành, được quản lý bởi Product Owner hoặc Product Manager.
Danh mục này là một danh sách các tính năng, yêu cầu, nâng cấp hoặc lỗi là đầu vào cho Sprint backlog. Bản chất của Product Backlog là to-do list.
Do những công việc trong Product Backlog có thể bị thay đổi do yêu cầu của khách hàng thay đổi, nhu cầu thị trường thay đổi nên nó cần Product Owner thường xuyên chăm nom, sắp xếp thứ tự ưu tiên và quản lý, duy trì.
Sprint backlog là một danh sách các đầu việc, hoặc user story, bug được lựa chọn bởi development team (đội phát triển), mang vào để triển khai trong 1 Sprint. Trước mỗi Sprint, đội phát triển sẽ có buổi họp Sprint Planning để lựa chọn sẽ thực hiện các đầu việc nào từ Product Backlog.
Sprint Backlog có thể linh hoạt và tiến hóa trong 1 Sprint. Tuy nhiên những mục tiêu cơ bản Sprint goal – điều mà team muốn đạt được trong Sprint đó thì không thể nhượng bộ.
Là sản phẩm có thể dùng được từ 1 Sprint.
Ở Magestore, chúng mình sẽ chuyển giao increment – phần tăng trưởng của sản phẩm vào cuối mỗi tuần cho người dùng. Sprint của chúng mình được cả công ty ấn định là kéo dài 1 tuần. Và cứ đến sáng thứ 2 của tuần mới, các team sẽ cùng minh họa và giới thiệu các sản phẩm này tới toàn công ty để mọi người cùng hiểu được các team khác đang có bước tiến như thế nào trong sự phát triển của toàn công ty.
Bạn có thể ít nghe đến từ Increment vì có thể mọi người thường dùng từ Sprint Goal, milestone, hay hoặc shipped epic. Đó là tùy thuộc vào mỗi công ty, mỗi đội nhóm và cách định nghĩa hoàn thành của bạn.
Burndown chart là biểu đồ thể hiện lượng công việc còn lại tới khi hoàn thành. Nó thể hiện tốc độ team của bạn “đốt cháy” các công việc để tiến tới mục tiêu như thế nào.
Trục dọc thường là lượng công việc, trục ngang là ngày hoặc Sprint.
Nếu nhìn vào Sprint burndown, thấy công việc của team bạn đang chậm chơi so với kỳ vọng, biểu thị lượng việc hoàn thành đang ít, cột việc còn lại vẫn cao qua 2-3 ngày đầu của Sprint, team bạn cần để ý và tập trung hoàn thành các đầu mục việc quan trọng nhất để đạt mục tiêu Sprint. Cùng với đó có thể họp làm mịn, tìm ra các nút thắt cản trở công việc được hoàn thành.
Nhìn vào Product Burndown chart qua các Sprint tuần tự, bạn cũng sẽ thấy nhịp độ chuyển giao công việc của team. Sẽ không có 1 đường thẳng tắp từ trên xuống dưới vì đội nhóm nào cũng sẽ gặp những biến cố hoặc trắc trở hoặc thuận lợi khác nhau khiến cho nhịp độ chuyển giao lên xuống dao động qua từng Sprint. Nhưng nhìn vào biểu đồ, bạn cũng sẽ có cái nhìn tổng quan hơn về tiến trình thực hiện product backlog hoặc project.
Vai trò và kỹ năng của từng bộ phận: Phân biệt rõ sự khác biệt giữa về công việc, trách nhiệm giữa các vai trò trong Scrum và các kỹ năng cần thiết ở từng vị trí. Trong Scrum, đội ngũ tham gia phát triển phần mềm được phân chia ra 03 vai trò với trách nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù. Ba vai trò này bao gồm:
Product Owner là người chịu trách nhiệm về thành công của dự án, hoặc của sản phẩm. Họ sẽ tập trung vào khía cạnh business (kinh doanh), khía cạnh khách hàng và nhu cầu của thị trường, sau đó thiết lập các ưu tiên cho công việc để đội phát triển tiến hành.
Một Product Owner hiệu quả là người:
Scrum Master là người am hiểu rõ về Scrum trong đội phát triển. Họ sẽ coach team, Product Owners và các bên liên quan khi những người này tham gia vào quy trình Scrum.
Một Scrum Master có năng lực là người hiểu các công việc được thực hiện bởi đội phát triển và giúp đội này tối ưu hóa sự minh bạch và hiệu suất chuyển giao. Anh ấy/cô ấy giữ vai trò người điều phối (facilitator), tập hợp các nguồn lực cần thiết (cả về nhân sự lẫn trang thiết bị, logistics…) cho các buổi họp Sprint Planning, Stand-up, Sprint Review, Sprint Retrospective.
Đội phát triển chính là những người thực hiện xây dựng sản phẩm, hoàn thành những thứ cần được chuyển giao tới khách hàng.
Một đội phát triển hiệu quả bao gồm các thành viên có mối quan hệ thân thiết với nhau, ngồi gần nhau trong cùng 1 không gian (co-located) và thường có từ 5-7 thành viên.
Một trong những quy tắc để xác định số lượng thành viên cho đội phát triển, dựa trên câu nói nổi tiếng của Jeff Bezos, CEO Amazon: “Một team chỉ nên đủ nhỏ để ăn chung 2 chiếc bánh pizza.” – (8 miếng bánh-> tối đa 8 người)
Đội phát triển này nên là một cross-function team, gồm những người có nhóm kỹ năng khác nhau (skill set), để có thể training lẫn nhau, nhờ đó không ai trở thành nút thắt trong luồng chảy công việc.
Đồng thời, đội này cùng cần là một đội tự tổ chức (self-organizing team). Họ được trao quyền để lựa chọn sẽ giải quyết các bài toán được đề ra như thế nào. Họ cũng là những người sẽ dự tính khối lượng công việc mà họ có thể hoàn thành được trong Sprint và cam kết với chúng.
Đây thường là trách nhiệm của Product Owner. PO là người định hướng sản phẩm tới tầm nhìn đã đưa ra. PO cũng cần có sự nhanh nhạy về mặt thị trường, về khách hàng để thay đổi lộ trình phát triển sản phẩm khi cần.
PO đồng thời sẽ là cầu nối giữa người dùng và khách hàng với đội phát triển. PO sẽ tiếp nhận ý kiến phản hồi từ cả 2 phía để tạo nên một danh mục các công việc sẵn sàng cho việc triển khai trong thời gian tiếp theo.
Đây là cuộc họp lên kế hoạch, đặt mục tiêu cho Sprint của đội phát triển. Các user story cụ thể sẽ được thêm vào Sprint backlog từ Product backlog. Các user story cần được các thành viên đồng thuận với nhau rằng là khả thi để thực hiện trong Sprint này.
Cuối buổi họp Sprint Planning, đội phát triển cần rõ với nhau về những gì sẽ cần được chuyển giao trong Sprint, và các phần tăng trưởng sản phẩm sẽ chuyển giao sẽ trông như thế nào.
Một Sprint kéo dài ít nhất là 1 tuần, nhiều nhất là 4 tuần. Đây là khoảng thời gian đội phát triển làm việc, phối hợp với nhau để hoàn thành phần tăng trưởng sản phẩm (increment).
Trong khoảng thời gian này, phạm vi công việc của Sprint có thể được Product Owner và đội phát triển (development team) mang ra thương lượng, nếu thấy cần thiết.
Tất cả các sự kiện từ Planning cho đến Retrospective đều diễn ra trong phạm vi 1 Sprint.
Thời lượng của 1 Sprint nên được giữ vững trong một khoảng thời gian phát triển sản phẩm, điều này giúp cho đội phát triển học được từ các trải nghiệm trong quá khứ và áp dụng chúng vào các Sprint trong tương lai.
Đây là các buổi họp cực ngắn, tổ chức vào một khung giờ cố định, hàng ngày. Các thành viên tham gia trả lời 3 câu hỏi: Hôm qua làm gì? Hôm nay sẽ làm gì? Khó khăn, trở ngại đang gặp phải là gì?
Cuộc họp này chỉ nên giới hạn trong 15 đến 30 phút. Mục đích là để kiểm tra tiến độ hoàn thành sprint goal và điều chỉnh sprint backlog nếu cần thiết. Ngoài ra, các buổi daily Scrum còn phải đưa ra được kế hoạch làm việc cho 24 giờ tiếp theo.
Cuối mỗi Sprint, team sẽ tụ họp với nhau trong một buổi để demo increment – phần tăng trưởng sản phẩm. Team cũng sẽ chỉ ra những hạng mục công việc đã hoàn thành, và đón nhận góp ý từ product owner.
Product Owner sẽ là người quyết định có phát hành phần tăng trưởng sản phẩm này hay không.
Sprint Review cũng là lúc để Product Owner nhìn lại vào Product Backlog sau khi Sprint vừa diễn ra, đưa ra những dự định cho Sprint tiếp theo.
Retrospective là cuộc họp để đội phát triển cùng ngồi lại với nhau và trao đổi về những gì đã diễn ra thuận lợi, những gì chưa tốt trong Sprint. Đó có thể là về quy trình, về con người, về công cụ, thậm chí về chính các sự kiện họp diễn ra trong Sprint.
Mục đích của Retrospective là tạo ra không gian và cơ hội để các thành viên reflect, tìm ra các cải tiến cho Sprint tiếp theo.
Không thực hiện đưa toàn bộ yêu cầu/ nghiệp vụ hệ thống vào Code và Testing cùng một lúc, mà sẽ chia các yêu cầu làm theo từng giai đoạn. Mỗi giai đoạn chỉ làm một số lượng yêu cầu nhất định.
Các quy tắc, các công cụ, sự kiện, vai trò trong Scrum khá dễ hiểu. Việc tổ chức các công việc phức hợp thành các phần nhỏ hơn là khía cạnh tiếp cận mà Scrum mang đến giúp team giải quyết các công việc khó. Đi kèm với đó, các vai trò và sự kiện được định sẵn giúp hình thành sự minh bạch và cộng tác cao trong suốt chu trình phát triển.
Khi team liên tục chuyển giao giá trị, thì team sẽ có động lực hơn và hạnh phúc hơn khi nhìn thấy tiến trình phát triển của mình trong một thời gian ngắn.
Đối với doanh nghiệp nói chung, ứng dụng Scrum có thể giúp doanh nghiệp đẩy nhanh tốc độ phát hành sản phẩm ra thị trường, tăng năng suất làm việc của nhân sự hay mang lại sự hài lòng cho khách hàng.
Tuy nhiên, càng ứng dụng Scrum, bạn sẽ thấy rằng sẽ cần thời gian để thành thạo Scrum. Các khái niệm về phân đoạn nhỏ như Sprint, các cuộc họp daily meeting, Sprint Review và các thực hành của Scrum master có thể là thách thức với nhiều team mới.
Nhưng lợi ích lâu dài của Scrum sẽ rất đáng để bạn vượt qua những trở ngại ban đầu. Nếu tổ chức của bạn chưa áp dụng triết lý agile và sử dụng khung làm việc Scrum vào trong đội nhóm làm việc, thì có thể học từ những khái niệm cơ bản nhất, và thử ứng dụng với một team đang sống với các giá trị sát nhất với Scrum (dũng cảm, tập trung, cam kết, tôn trọng, cởi mở).
Nguồn: https://anhtester.com/blog/scrum-la-gi-tong-quan-ve-mo-hinh-scrum-b428.html
You need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
SUBSCRIBE TO OUR NEWSLETTER
