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.
Bạn có tự hỏi, thành công giá trị thế nào? Câu hỏi này không dễ trả lời, và sẽ khác với mỗi người. Vì sao? Vì giá trị của thành công sẽ bằng với giá trị của những thất bại mà bạn đã trải qua để đạt được thành công đó.
Chúng ta luôn sợ thất bại, xem thất bại là sự xấu hổ. Vị của sự thất bại luôn không hề dễ nếm, mỗi khi thất bại, chúng ta dễ buông bỏ, chạy trốn khỏi nó. Nhưng để có được thành công, thì bạn phải chấp nhận thất bại, hay nói đúng hơn là học từ thất bại, để làm đúng hơn, tốt hơn.
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:
Có một số bạn chia sẻ với Scrumviet, thỉnh thoảng bạn lại nghe một ai đó nhắc đến “Sprint 0”, “Design Sprint”, “Hardening Sprint”.
Và bạn phân vân tự hỏi, liệu những dạng Sprint này là gì? Chúng có tồn tại không và có mang lại lợi ít khi thực hành Scrum không?
Scrum đề ra ba vai trò trong Scrum Team: Product Owner, Scrum Master và Development team. Nhưng cũng có nhiều câu hỏi được đặt ra, liệu một người có thể vừa làm Product Owner vừa làm Scrum Master?
As a Scrum Master, I know that serving Scrum Team, Product Owner and Organization to adopt Scrum is not easy. It takes time (and a lot of time) and patience. During that long journey, I recognize the importance of continuous improvement. I need to "make up my mind" every day, keep myself up to date along with continuous learning. By doing so, I can adapt myself and find better ways to support the Scrum Team and Organization to maximize values with Scrum.
(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ớ).
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. People do not like debt but somehow we will be in debt once in our life. When you are in debt, if you do not manage it well, you will have to pay big interest in future. Software Development also has debt and it's called Technical Debt.
Some people asked me about Sprint Length and how to define sprint length. Most of the concern is can we do Scrum with 1 day Sprint? Can we do Scrum with Sprint longer than 1 month? So this post will go through this topic.
Why Rhythm is important?
Empirical Process based on Transparency, Inspection, and Adaptation. Therefore Rhythm of Inspection, and Adaptation is very important. It will help your Scrum team have Time-Box and circle of Focus, Learn and Mature. "Rhythm helps team to focus and reduces the complexity" I always say Definition of Done is simple: It is just a common language/ understanding about "What done means" of Scrum Team and stakeholders.
But why is it very important? Well! Let's go through events inside a Sprint and see how DoD support Scrum team. 1. At Sprint Planning: Definition of Done helps and guides Development team forecast about how many Product Backlog Items they can do within this sprint to achieve a sprint goal. I got interesting questions about Daily Scrum and would like to share it today. Some people asked me a question about "hold Daily Scrum at the beginning of the day", let’s go into the details of this case:
- Scrum Master asked the team to have daily Scrum at the beginning of the day. - The reason he wants to have Daily Scrum at beginning of the day is: He thought Daily Scrum must be held at early of day and it also brings one benefit that people go to office right time, and people can start to work right after the meeting. Are we really a Team?Looking back a couple of years ago, I had a chance to work with the great team. Yes! They are a great team, but not from the beginning…that was a broken team when I came.
– The team used Scrum but the Transparency was lost. Developer hid issues from Product Owner when he came to ask. They said: “All good!”, but actually, they were deep in Bugs & Impediments and couldn’t deliver working software. Why we are here? Last week I had a short discussion with some fellows, one of the interesting topic is about "Human Resources", and most of them had an issue with how to align Scrum with HR department:
|