Trong một khoảng thời gian làm việc, Scrum team thường sẽ có thiên hướng tạo ra nhiều hoạt động cần thiết hơn cho công việc hằng ngày của mình. Nhưng cũng sẽ có những hoạt động, công việc không cần thiết (nữa) cần được xem xét và bỏ đi. Vì nếu không, những công việc không cần thiết này sẽ chiếm lấy sức lực và thời gian của team, mà đáng ra nên dành cho những việc cần thiết khác.
Vì vậy một khoảng thời gian nào đó, chúng ta nên nhìn lại những công việc hiện tại của mình: Điều gì tốt, điều gì làm chúng ta chậm lại, chúng ta đang tốn sức cho những việc gì nhưng lại không mang lại giá trị… Open The Box là một format dành cho buổi Sprint Retrospective để hỗ trợ Scrum team tập trung vào việc xác định: Điều gì hữu ích, điều gì không cần nữa, và những ý tưởng để làm tốt hơn trong Sprint sau.
Scrum dù đã bước qua tuổi 26, và được ứng dụng rộng rãi trên toàn thế giới. Nhưng hiện nay vẫn còn rất nhiều những hiểu lầm cơ bản về Scrum. Những hiểu lầm này tưởng chừng vô hại, nhưng lại khiến cho nhiều tổ chức bị cản trở trong việc tiếp cận và nhận được những giá trị mà Scrum có thể mang lại cho họ. Hôm nay tôi xin phép điểm qua nhanh 4 hiểu lầm thông thường nhất về Scrum trong bài viết này:
Drop, Add, Keep, Improve hay còn được gọi là DAKI - Sprint Retrospective, là một trong những Format cơ bản, dễ áp dụng cho Scrum team, nhưng lại mạnh mẽ và mang lại nhiều giá trị giúp team nhìn lại những vấn đề cần được giải quyết trong Sprint vừa qua.
Start - Stop - Continue là một format dành cho Sprint Retrospective cực kỳ đơn giản, và được áp dụng rất nhiều bởi các Scrum team. Đơn giản vì format này rất dễ hiểu và cách chuẩn bị cũng dễ dàng. Start - Stop - Continue cùng với Like & Dislike là hai format cơ bản nhất các Scrum Master mới bắt đầu đảm đương vai trò SM có thể tìm hiểu và áp dụng, vì tính hiệu quả và đơn giản của chúng.
Một trong những giá trị thể hiện được một Scrum team có thành công và tiến bộ qua từng Sprint hay không, được thể hiện qua việc Scrum Team xác định được giá trị khách hàng cần, và có cải tiến/tối ưu công việc của mình cần làm trong Sprint để đạt được Sprint Goal hay không. Việc Scrum team xác định/hiểu được nhu cầu của khách hàng, và Developer tự tối ưu hoá được công việc của mình trong Sprint là điều không dễ dàng, và có rất nhiều hiểu lầm và áp dụng KHÔNG đúng các công cụ và phương pháp như:
Scrum có 3 Artifacts là Product Backlog, Sprint Backlog và Product Increment. Mỗi Artifact đều có một vai trò rõ ràng và rất quan trọng với Scrum. Qua mỗi Artifact, giá trị của sản phẩm được minh bạch tối đa để mọi người có thể nhận biết và hiểu rõ được. Từ đó giúp cho Scrum Team có thể tối ưu hoá sản phẩm bằng chủ nghĩa kinh nghiệm: Transparent, Inspection, và Adaptation. Bài này tôi sẽ không nói nhiều về chi tiết của từng artifacts (để xem chi tiết các bạn có thể click vào link để xem những bài viết trước) mà sẽ nói qua về việc tại sao Artifacts lại quan trọng với sản phẩm. Và dòng chảy giá trị sản phẩm được tối ưu hoá thế nào qua Product Backlog, Sprint Backlog và Product Increment.
Từ Scrum guide 2020 - Development Team được thay đổi thành Developer.
Developer là một trong ba vai trò chính của Scrum Framework, họ là những người trực tiếp làm việc để tạo ta sản phẩm hoàn thiện, sử dụng được bởi người dùng.
Product Owner là một trong ba vai trò chính của Scrum Team. Product Owner như là một mini CEO của sản phẩm, người có trách nhiệm tối ưu hoá giá trị sản phẩm đó mang lại cho người dùng.
Daily Scrum là sự kiện diễn ra mỗi ngày, có thời gian cố định là 15 phút. Daily Scrum nên diễn ra cùng thời điểm và địa điểm mỗi ngày, để mọi người dễ dàng nhớ và thực hiện, giảm thiểu sự phức tạp.
Sprint Planning là một sự kiện trong Scrum, cuộc họp này bao gồm Scrum Team. Trong cuộc họp, Scrum team xem xét, dự đoán sẽ làm gì trong Sprint tiếp theo và làm như thế nào để hoàn thành và phát hành sản phẩm thoả với Definition of Done.
Product Backlog là gì?
Product Backlog là một danh sách chứa tất cả những thứ cần cho sản phẩm đó. Là một danh sách được quản lý và sắp xếp thứ tự bởi Product Owner.
Vài năm trước, tôi thường nghe thấy mọi người nói về việc: Scrum chỉ dành cho những dự án phần mềm và sản phẩm phần mềm. Điều này thực sự không thể tránh khỏi, khi ban đầu, Ken và Jeff xây dựng Scrum như một phương thức làm việc mới, thích hợp hơn cho lĩnh vực phát triển những sản phẩm phần mềm. Nhưng việc đó chỉ đúng vào những năm về trước.
Ngày nay, tôi ngày càng nghe nói nhiều hơn từ những người hay những tổ chức đã thành công trong việc áp dụng Scrum vào môi trường không phải là phần mềm. Mỗi lần nghe thấy những thông tin như vậy, càng khiến tôi tin vào tương lai của Scrum. Chính nó (Scrum), sẽ vươn xa ra khỏi môi trường phát triển phần mềm, và tiếp cận với một hướng rộng hơn, nói cách khác là có thể ứng dụng cho đa ngành nghề. Miễn là ngành nghề hay môi trường đó chứa đựng sự phức tạp, khó đoán và khó nắm bắt. Vì sao lại như vậy? Vì hai lý do dưới đây:
(Bài viết này tôi xin giữ lại một số "thuật ngữ" tiếng Anh, vì khi dịch những "thuật ngữ" này sang tiếng Việt sẽ không còn đủ ý của nó nữa.)
Scrum Master là ai? Scrum Framework đã định nghĩa ba vai trò chính: Scrum Master, Product Owner và Developer. Trong đó, Scrum Master là vai trò trung tâm kết nối. Scrum Master giúp cho Scrum Framework được hiểu rõ và thực hành một cách đúng đắn bởi Scrum Team, đồng thời phát huy tối đa giá trị của Scrum Framework trong Scrum Team và cũng như trong Tổ Chức. Scrum Guide đã đề cập rõ, vai trò của Scrum Master phải phục vụ: Scrum Team (bao gồm Developer, Product Owner) và Tổ Chức. "Phục vụ" ở đây không có nghĩa Scrum Master phải bưng trà, rót nước, đặt lịch họp cho team... Mà nghĩa của từ "phục vụ" này tức là Scrum Master sẽ phải đề cao thành công của team, và tổ chức lên trên hơn thành công của cá nhân mình. Hay nói cách khác, Scrum Master là một Servant Leader (Người lãnh đạo đầy tớ). Linh Hoạt / Nhanh nhẹn
Ở những dự án phần mềm truyền thống, chúng ta viết ra trước những yêu cầu và kế hoạch chi tiết. Sau đó trình bày nó cho nhà đầu tư, kèm theo thông báo về chi phí cần thiết cho việc thay đổi bất cứ điều gì trong kế hoạch hay yêu cầu ban đầu (thường là rất cao). Những thay đổi sẽ được kiểm soát một cách rất gắt gao. Thậm chí còn có những kế hoạch để giảm thiểu thay đổi yêu cầu. Cách tiếp cận này thường sẽ làm cho dự án dễ đi vào ngõ cụt. Vì nó được xây dựng trên việc chúng ta phải biết tất cả những gì chúng ta muốn ngay từ ban đầu (nhưng thật ra là không). Và phải đảm bảo không có thay đổi nào làm cho sản phẩm tốt hơn (điều này là bất khả thi với tốc độ thay đổi chóng mặt trên thị trường cạnh tranh khốc liệt hiện nay). Có nhiều câu hỏi được đặt ra quanh việc có nên sử dụng Scrum và Agile? Giá trị nhận được là gì? Scrum và Agile có những điều gì vượt trội hơn những phương thức phát triển phần mềm truyền thống? Hôm nay trong loạt bài Scrum cơ bản, Scrumviet xin chia sẻ đến các bạn một vài giá trị mà Scrum và Agile sẽ mang lại cho doanh nghiệp hay đội nhóm của bạn khi được áp dụng đúng.
Scrum là gì?
Scrum là một framework được dùng để phát triển những sản phẩm phức tạp ('Complex'), hay giải quyết những vấn đề phức tạp. Scrum được xây dựng dựa trên chủ nghĩa kinh nghiệm ('Empiricism') và qua đó những công việc phức tạp được giải quyết theo cách tối ưu nhất. Những ngày qua Scrumviet nhận được nhiều thắc mắc về chứng chỉ PSM I, PSM II và PSM III của Scrum.org. Hôm nay Scrumviet viết chút chia sẻ về ba cấp độ của chứng chỉ PSM này.
Hiện tại trên thế giới có hai tổ chức đào tạo Scrum lớn nhất là: Scrum.org và Scrum Alliance. Những ngày đầu tìm hiểu về Scrum, tôi cũng lò mọ phân vân mình nên học hay thi chứng chỉ của tổ chức nào.
Tìm kiếm trên mạng thì vô vàng thông tin, không biết đâu mà lần, nhưng nhờ thông qua những người bạn đã từng sở hữu cả hai chứng chỉ PSM và CSM, và tìm hiểu thêm từ những trainer, thì tôi đã quyết định chọn học và thi những chứng chỉ của Scrum.org. |