Scrum - Hướng dẫn nhanh

Agile đã trở thành một trong những từ thông dụng lớn trong ngành phát triển phần mềm. Nhưng chính xác thì phát triển nhanh là gì? Nói một cách đơn giản, phát triển nhanh là một cách khác để thực hiện các nhóm và dự án phát triển phần mềm.

Để hiểu những gì là mới, chúng ta hãy tóm tắt lại các phương pháp truyền thống. Trong phát triển phần mềm thông thường, các yêu cầu sản phẩm được hoàn thiện trước khi tiếp tục phát triển.

Mô hình thác nước

Mô hình phát triển phần mềm được sử dụng phổ biến nhất với đặc điểm này là Mô hình thác nước như được mô tả trong sơ đồ sau. Tuy nhiên, trong hầu hết các trường hợp, các chức năng mới được thêm vào và các yêu cầu trước đó cũng có thể thay đổi. Mô hình Waterfall không được cấu trúc để đáp ứng các yêu cầu thay đổi liên tục như vậy. Hơn nữa, người dùng sẽ không biết rõ về chức năng của sản phẩm cho đến khi sản phẩm có sẵn toàn bộ.

Mô hình gia tăng lặp lại

Trong mô hình gia tăng lặp đi lặp lại, sự phát triển bắt đầu với một số lượng hạn chế các yêu cầu đã hoàn thiện và ưu tiên. Sản phẩm có thể phân phối là phần gia tăng hoạt động của sản phẩm. Một tập hợp các hoạt động từ yêu cầu đến phát triển mã được gọi là lặp lại. Dựa trên chức năng của phần tăng thêm và bất kỳ hoặc tất cả các yêu cầu mới, được sửa đổi, đang chờ xử lý, lô yêu cầu tiếp theo được trao cho lần lặp tiếp theo. Kết quả của quá trình lặp lại tiếp theo là sự gia tăng khả năng làm việc của sản phẩm. Điều này được lặp lại cho đến khi sản phẩm hoàn thành các chức năng cần thiết.

Người dùng thường không tham gia vào công việc phát triển và nó có thể gây ra khoảng cách giao tiếp dẫn đến các chức năng không chính xác. Sự tham gia là tích cực cho nhóm phát triển, nhưng đòi hỏi thời gian của nhóm và có thể gây ra sự chậm trễ. Hơn nữa, bất kỳ thay đổi yêu cầu không chính thức nào trong quá trình lặp lại có thể dẫn đến nhầm lẫn và cũng có thể tạo ra creep phạm vi. Với tiền đề này, phát triển Agile ra đời.

Phát triển nhanh

Phát triển Agile dựa trên phát triển gia tăng lặp đi lặp lại, trong đó các yêu cầu và giải pháp phát triển thông qua hợp tác nhóm. Nó đề xuất một cách tiếp cận lặp lại theo hộp thời gian và khuyến khích phản ứng nhanh chóng và linh hoạt với sự thay đổi. Đó là một khung lý thuyết và không chỉ định bất kỳ thực hành cụ thể nào mà nhóm phát triển phải tuân theo. Scrum là một khung quy trình nhanh cụ thể xác định các thực hành bắt buộc phải tuân theo.

Việc triển khai sớm các phương pháp nhanh bao gồm Quy trình hợp nhất Rational (1994), Scrum (1995), Crystal Clear, Lập trình cực đoan (1996), Phát triển phần mềm thích ứng, Phát triển theo hướng tính năng (1997) và Phương pháp phát triển hệ thống động (DSDM) (1995). Chúng bây giờ được gọi chung làagile methodologies, sau khi Tuyên ngôn Agile được xuất bản vào năm 2001.

Tuyên ngôn Agile

Tuyên ngôn Agile được xuất bản bởi một nhóm các nhà phát triển phần mềm vào năm 2001, nêu bật tầm quan trọng cần được trao cho nhóm phát triển, đáp ứng các yêu cầu thay đổi, sự tham gia của khách hàng.

Tuyên ngôn Agile như sau:

“Chúng tôi đang khám phá ra những cách tốt hơn để phát triển phần mềm bằng cách thực hiện nó và giúp những người khác làm điều đó. Thông qua công việc này, chúng tôi đã nhận ra giá trị:

Các cá nhân và tương tác qua các quy trình và công cụ
Làm việc phần mềm trên tài liệu toàn diện
Sự cộng tác của khách hàng trong quá trình đàm phán hợp đồng
Đáp ứng sự thay đổi so với việc tuân theo một kế hoạch

Có nghĩa là, trong khi có giá trị trong các mục ở bên phải, chúng tôi đánh giá các mục ở bên trái nhiều hơn. "

… Tuyên ngôn về Phát triển Phần mềm Agile, Tác giả: Beck, Kent, et al. (2001)

Định nghĩa các Mục trong Tuyên ngôn Agile

Các mục tuyên ngôn bên trái có thể được mô tả như sau:

Mục kê khai	Sự miêu tả
Cá nhân và tương tác	Cần phải chú trọng: tự tổ chức và động lực của các thành viên trong nhóm tương tác liên tục cho công việc, làm rõ, thông tin giữa các thành viên trong nhóm
Phần mềm làm việc	Việc cung cấp phần mềm làm việc trong khoảng thời gian ngắn giúp đạt được sự tin tưởng của khách hàng và sự đảm bảo trong nhóm.
Sự cộng tác của khách hàng	Sự tham gia thường xuyên của khách hàng với nhóm phát triển đảm bảo thông tin về các sửa đổi cần thiết.
Đáp ứng với sự thay đổi	Tập trung vào phản ứng nhanh với các thay đổi được đề xuất, điều này có thể thực hiện được với thời gian lặp lại ngắn.

Yếu tố quan trọng của Tuyên ngôn Agile là chúng ta phải tin tưởng mọi người và khả năng cộng tác của họ. Vì lý do này, các phương pháp luận nhanh nhẹn cụ thể được phát triển khai thác khả năng của các thành viên trong nhóm bằng cách nhấn mạnh đến tinh thần làm việc nhóm và hợp tác trong suốt vòng đời của dự án.

Các nguyên tắc chính của Agile

Tuyên ngôn Agile dựa trên các nguyên tắc sau:

Nguyên tắc	Sự miêu tả
Sự hài lòng và giao hàng	Sự hài lòng của khách hàng thông qua phần mềm làm việc sớm và liên tục.
Đón đầu thay đổi	Hoan nghênh các yêu cầu thay đổi, ngay cả ở các giai đoạn phát triển sau này.
Giao hàng thường xuyên	Cung cấp phần mềm hoạt động thường xuyên (hàng tuần thay vì hàng tháng).
Giao tiếp là chìa khóa	Đảm bảo sự liên kết chặt chẽ giữa các nhà phát triển với các doanh nhân hàng ngày.
Môi trường và Niềm tin	Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ sự hỗ trợ cần thiết và tin tưởng họ.
Giao tiếp mặt đối mặt	Khuyến khích trò chuyện mặt đối mặt để đảm bảo giao tiếp hiệu quả và hiệu quả.
Phần mềm như là thước đo của sự tiến bộ	Phần mềm làm việc là thước đo chính của sự tiến bộ.
Phát triển bền vững	Thúc đẩy phát triển bền vững với khả năng duy trì một tốc độ không đổi trong suốt quá trình phát triển.
Chú ý đến chi tiết	Liên tục chú ý đến kỹ thuật xuất sắc và thiết kế tốt.
Sức mạnh của ít hơn	Sự đơn giản là điều cần thiết.
Nhóm tự tổ chức	Sự quan tâm thường xuyên của nhóm về việc trở nên hiệu quả trong những hoàn cảnh thay đổi.

phương pháp Agile

Phương pháp phát triển hệ thống động (DSDM)

Nó là một khuôn khổ nhanh cho các dự án phần mềm. Nó được sử dụng để tinh chỉnh các cách tiếp cận truyền thống. Phiên bản mới nhất của DSDM được gọi là DSDM Atern. Tên Atern là viết tắt của Arctic Tern - một loài chim biển có thể di chuyển những khoảng cách rộng lớn, đại diện cho nhiều đặc điểm của phương pháp là những cách làm việc tự nhiên như ưu tiên và cộng tác.

Scrum

Đây là khung nhanh nhẹn phổ biến nhất, đặc biệt tập trung vào cách quản lý các nhiệm vụ trong môi trường phát triển dựa trên nhóm. Scrum sử dụng mô hình phát triển lặp đi lặp lại và tăng dần, với thời gian lặp lại ngắn hơn. Scrum tương đối đơn giản để thực hiện và tập trung vào việc giao hàng nhanh chóng và thường xuyên.

Lập trình cực đoan (XP)

Nó là một loại phát triển phần mềm nhanh nhẹn. Nó ủng hộ việc phát hành thường xuyên trong các chu kỳ phát triển ngắn, nhằm mục đích cải thiện năng suất và giới thiệu các điểm kiểm tra nơi các yêu cầu mới của khách hàng có thể được chấp nhận. Phương pháp này lấy tên từ ý tưởng rằng các yếu tố có lợi của thực tiễn kỹ thuật phần mềm truyền thống được đưa đến mức cực đoan. (Lập trình cực đoan là một chuyên ngành phát triển phần mềm tổ chức mọi người sản xuất phần mềm chất lượng cao hơn một cách hiệu quả hơn.) XP giải quyết các giai đoạn phân tích, phát triển và thử nghiệm bằng các cách tiếp cận mới tạo ra sự khác biệt đáng kể cho chất lượng của sản phẩm cuối cùng.

Phát triển theo hướng thử nghiệm (TDD)

Đây là một quy trình phát triển phần mềm dựa trên sự lặp lại của một chu kỳ phát triển rất ngắn: đầu tiên nhà phát triển viết một trường hợp thử nghiệm tự động xác định một cải tiến mong muốn hoặc một chức năng mới, sau đó nó tạo ra ít mã nhất để vượt qua thử nghiệm đó và cuối cùng đưa mã mới đến các tiêu chuẩn có thể chấp nhận được.

Dựa vào

Thực tiễn sản xuất coi việc chi tiêu các nguồn lực cho bất kỳ mục tiêu nào khác ngoài việc tạo ra giá trị cho khách hàng cuối cùng là lãng phí và do đó là mục tiêu cần loại bỏ. Làm việc từ quan điểm của khách hàng tiêu thụ một sản phẩm hoặc dịch vụ, giá trị thuật ngữ được định nghĩa là bất kỳ hành động hoặc quy trình nào mà khách hàng sẵn sàng trả tiền cho. Lean tập trung vào việc duy trì giá trị với ít công việc hơn.

Kanban

Đó là một hệ thống để cải thiện và duy trì mức sản xuất cao. Kanban là một phương pháp mà thông qua đó Just-In-Time (JIT), chiến lược mà các tổ chức sử dụng để kiểm soát chi phí hàng tồn kho, đạt được. Kanban đã trở thành một công cụ hữu hiệu hỗ trợ điều hành một hệ thống sản xuất nói chung và nó được chứng minh là một cách tuyệt vời để thúc đẩy cải tiến.

Phần kết luận

Trong 10 năm qua, ngày càng có nhiều câu chuyện thành công, nơi các công ty đã cải thiện đáng kể sự thành công và hiệu suất của các nhóm và dự án phát triển CNTT của họ bằng các phương pháp hoạt động nhanh. Điều này đã khiến cho nhanh chóng được áp dụng rộng rãi trong nhiều ngành khác nhau, bao gồm cả truyền thông và công nghệ, các doanh nghiệp lớn và thậm chí cả chính phủ.

Agile Framework giúp các nhóm hưởng lợi từ:

Thời gian giao hàng / tiếp thị nhanh hơn
Giảm thiểu sự không chắc chắn và rủi ro
Tăng lợi tức đầu tư (ROI) bằng cách tập trung vào Giá trị khách hàng

Trong số các phương pháp luận nhanh nhẹn khác nhau này, Scrum đã tỏ ra cực kỳ thành công trên toàn thế giới trong 20 năm qua.

Scrum là một khuôn khổ để phát triển và duy trì các sản phẩm phức tạp. Ken Schwaber và Jeff Sutherland đã phát triển Scrum. Cùng nhau, họ đứng sau các Quy tắc Scrum.

Định nghĩa Scrum

Scrum là một khuôn khổ trong đó mọi người có thể giải quyết các vấn đề phức tạp về khả năng thích ứng, đồng thời cung cấp các sản phẩm có giá trị cao nhất có thể một cách hiệu quả và sáng tạo.

Scrum là một khung quy trình đã được sử dụng để quản lý việc phát triển sản phẩm phức tạp từ đầu những năm 1990. Scrum không phải là một quy trình hay một kỹ thuật để xây dựng sản phẩm; đúng hơn, nó là một khuôn khổ trong đó bạn có thể sử dụng các quy trình và kỹ thuật khác nhau. Scrum làm rõ hiệu quả tương đối của các phương pháp quản lý và phát triển sản phẩm của bạn để bạn có thể cải thiện.

Khung Scrum bao gồm các Nhóm Scrum và các vai trò, sự kiện, hiện vật và quy tắc liên quan của họ. Mỗi thành phần trong khuôn khổ phục vụ một mục đích cụ thể và là yếu tố cần thiết cho sự thành công và cách sử dụng của Scrum.

Các quy tắc của Scrum gắn kết các sự kiện, vai trò và hiện vật lại với nhau, chi phối các mối quan hệ và sự tương tác giữa chúng. Các quy tắc của Scrum được mô tả trong suốt hướng dẫn này.

Note- Trong toàn ngành, có những quan niệm sai lầm rằng Scrum có nghĩa là không có tài liệu, nhóm scrum chỉ bao gồm các nhà phát triển, v.v. Nó không hoàn toàn như vậy; chúng tôi sẽ làm rõ về những điều này trong các phần sau.

Khung quy trình Scrum

Trong Scrum, các sự kiện được quy định được sử dụng để tạo ra sự đều đặn. Tất cả các sự kiện đều là sự kiện được đóng hộp thời gian, sao cho mọi sự kiện đều có thời lượng tối đa. Các sự kiện được mô tả tỉ mỉ hơn trong các chương tiếp theo.

tăng tốc

Trọng tâm của Scrum là Sprint, một hộp thời gian kéo dài hai tuần hoặc một tháng, trong đó phần tăng sản phẩm có thể thay thế được sẽ được tạo ra. Một Sprint mới bắt đầu ngay sau khi kết thúc Sprint trước. Sprint bao gồm lập kế hoạch Sprint, tổng kết hàng ngày, công việc phát triển, đánh giá Sprint và hồi cứu Sprint.

Trong lập kế hoạch Sprint, công việc sẽ được thực hiện trong Sprint do Nhóm Scrum cộng tác lên kế hoạch.
Cuộc họp Scrum Hàng ngày là một sự kiện kéo dài 15 phút để Nhóm Scrum đồng bộ hóa các hoạt động và lập kế hoạch cho ngày đó.
Đánh giá Sprint được tổ chức vào cuối Sprint để kiểm tra Phần gia tăng và thực hiện các thay đổi đối với Product Backlog, nếu cần.
Sơ kết Sprint diễn ra sau Sơ kết Sprint và trước khi Lập kế hoạch Sprint tiếp theo. Trong cuộc họp này, Nhóm Scrum phải tự kiểm tra và lập một kế hoạch cho các cải tiến sẽ được thực hiện trong Sprint tiếp theo.

Phần kết luận

Scrum là một khung quy trình xác định các quy tắc, sự kiện và vai trò nhất định để mang lại sự đều đặn. Tuy nhiên, nó có thể được điều chỉnh cho phù hợp với bất kỳ tổ chức nào, dựa trên nhu cầu, miễn là không vi phạm các quy tắc cơ bản của scrum.

Nhóm Scrum bao gồm ba vai trò, đó là ScrumMaster, Chủ sở hữu sản phẩm và Nhóm.

Đội sản xuất

ScrumMaster (đôi khi được viết là Scrum Master, mặc dù thuật ngữ chính thức không có khoảng trắng sau “Scrum”) là người quản lý quy trình scrum. Anh ấy / cô ấy có trách nhiệm-

làm cho quá trình chạy trơn tru
loại bỏ những trở ngại ảnh hưởng đến năng suất
tổ chức và tạo điều kiện cho các cuộc họp quan trọng

Chủ sở hữu sản phẩm

Product Owner có trách nhiệm tối đa hóa giá trị của sản phẩm và công việc của Nhóm. Cách thực hiện điều này có thể rất khác nhau giữa các tổ chức, Nhóm Scrum và cá nhân.

Product Owner là người duy nhất chịu trách nhiệm quản lý Product Backlog. Quản lý Product Backlog bao gồm-

Thể hiện các hạng mục Product Backlog một cách rõ ràng.
Sắp xếp các hạng mục Product Backlog để đạt được mục tiêu và sứ mệnh tốt nhất.
Tối ưu hóa giá trị của công việc mà Nhóm thực hiện.
Đảm bảo rằng Product Backlog có thể nhìn thấy, minh bạch và rõ ràng cho tất cả mọi người và cho thấy những gì Nhóm sẽ làm việc thêm.
Đảm bảo rằng Nhóm nghiên cứu hiểu các mục trong Product Backlog ở mức độ cần thiết.

Chủ sở hữu sản phẩm có thể thực hiện công việc trên hoặc nhờ Nhóm làm việc đó. Tuy nhiên, Product Owner vẫn phải chịu trách nhiệm về các nhiệm vụ này.

Chủ sở hữu sản phẩm là một người, không phải là một ủy ban. Product Owner có thể đại diện cho mong muốn của một ủy ban trong Product Backlog, nhưng những người muốn thay đổi mức độ ưu tiên của hạng mục Product Backlog phải đề cập đến Product Owner.

Để Product Owner thành công, toàn bộ tổ chức phải tôn trọng các quyết định của họ. Các quyết định của Chủ sở hữu sản phẩm được hiển thị trong nội dung và thứ tự của Product Backlog. Không ai được phép yêu cầu Nhóm làm việc theo một loạt các yêu cầu khác và Nhóm không được phép làm theo những gì người khác nói. Điều này được đảm bảo bởi ScrumMaster.

Đội

Nhóm tự tổ chức và hoạt động chéo. Điều đó có nghĩa là nhóm bao gồm các nhà phân tích, nhà thiết kế, nhà phát triển, người kiểm tra, v.v. phù hợp và liên quan đến dự án.

Một số người trong ngành gọi nhóm này là nhóm phát triển. Tuy nhiên, tham chiếu như vậy dẫn đến tranh cãi rằng nhóm chỉ có thể có nhà phát triển và không có vai trò nào khác. Đó là một sự hiểu biết hiển nhiên rằng đó chỉ là một quan niệm sai lầm. Để phát triển một sản phẩm phần mềm, chúng tôi yêu cầu tất cả các vai trò và đó là bản chất của scrum - nhóm sẽ phối hợp hoạt động. Các nhóm liên chức năng có tất cả các năng lực cần thiết để hoàn thành công việc mà không phụ thuộc vào những người khác không thuộc nhóm, do đó có thể tiết kiệm thời gian và công sức. Mô hình nhóm trong Scrum được thiết kế để tối ưu hóa tính linh hoạt, sáng tạo và năng suất.

Quy mô Nhóm tối ưu đủ nhỏ để vẫn nhanh nhẹn và đủ lớn để hoàn thành công việc quan trọng trong Sprint. Quy mô Đội nên được duy trì trong khoảng từ năm đến chín người, nếu có thể. Ít hơn năm thành viên trong nhóm làm giảm sự tương tác và dẫn đến hiệu quả năng suất thấp hơn. Có hơn chín thành viên đòi hỏi quá nhiều sự phối hợp.

Nhóm scrum làm việc cùng nhau chặt chẽ hàng ngày để đảm bảo luồng thông tin trôi chảy và giải quyết vấn đề nhanh chóng. Nhóm scrum cung cấp sản phẩm lặp đi lặp lại và tăng dần, tối đa hóa cơ hội cho phản hồi. Việc cung cấp gia tăng một sản phẩm hoàn chỉnh đảm bảo luôn có sẵn một phiên bản hữu ích tiềm năng của sản phẩm đang hoạt động.

ScrumMaster là một người có trách nhiệm được đào tạo, người cung cấp các dịch vụ như được mô tả bên dưới -

Dịch vụ ScrumMaster cho Chủ sở hữu sản phẩm

ScrumMaster phục vụ Chủ sở hữu sản phẩm theo một số cách, bao gồm:

Tìm kiếm các kỹ thuật để quản lý Product Backlog hiệu quả.
Giúp Nhóm Scrum hiểu sự cần thiết của các hạng mục Product Backlog rõ ràng và ngắn gọn.
Hiểu biết về lập kế hoạch sản phẩm trong môi trường thực nghiệm.
Đảm bảo rằng Product Owner biết cách sắp xếp Product Backlog để tối đa hóa giá trị.
Hiểu biết và rèn luyện tính nhanh nhẹn.
Tạo điều kiện cho các sự kiện Scrum khi cần thiết.

Dịch vụ ScrumMaster cho Nhóm Scrum

ScrumMaster phục vụ Nhóm Scrum theo một số cách, bao gồm:

Huấn luyện Nhóm Scrum về tự tổ chức và chức năng chéo.
Giúp Nhóm Scrum tạo ra các sản phẩm có giá trị cao.
Loại bỏ những cản trở đối với tiến trình của Nhóm Scrum.
Hỗ trợ các sự kiện Scrum khi được yêu cầu hoặc cần thiết.
Huấn luyện Nhóm Scrum trong môi trường tổ chức mà Scrum chưa được chấp nhận và hiểu rõ.

Dịch vụ ScrumMaster cho Tổ chức

ScrumMaster phục vụ tổ chức theo nhiều cách, bao gồm-

Dẫn dắt và huấn luyện tổ chức trong việc áp dụng Scrum.
Lập kế hoạch triển khai Scrum trong tổ chức.
Giúp nhân viên và các bên liên quan hiểu và ban hành Scrum và phát triển sản phẩm theo kinh nghiệm.
Gây ra sự thay đổi để tăng năng suất của Nhóm Scrum.
Làm việc với các ScrumMaster khác để tăng hiệu quả của việc áp dụng Scrum trong tổ chức.

Phần kết luận

Khung quy trình Scrum có thể được xem bằng một chuỗi các sự kiện và các tạo tác tương ứng. Các sự kiện Scrum là các sự kiện đóng hộp thời gian. Điều đó có nghĩa là, trong một dự án, mọi sự kiện scrum đều có thời lượng tối đa được xác định trước. Những sự kiện này tạo sự minh bạch về tiến độ dự án cho tất cả những ai tham gia vào dự án. Các sự kiện quan trọng của scrum là-

Sprint
Kế hoạch nước rút
Các cuộc họp Scrum hàng ngày
Sơ kết Sprint
Cuộc hồi tưởng Sprint

Sprint

Trong Sprint, một Sản phẩm đang hoạt động được phát triển. Nó thường có thời hạn là hai tuần hoặc một tháng, và thời lượng này không đổi cho tất cả các sprint trong dự án. Chúng ta không thể có thời lượng khác nhau cho các nước rút khác nhau trong một dự án. Một Sprint mới bắt đầu ngay sau khi kết thúc Sprint trước.

Mục tiêu Sprint là một bộ mục tiêu cho Sprint. Nó cung cấp hướng dẫn cho Nhóm về lý do tại sao Nhóm xây dựng Phần tăng trưởng. Nó được tạo trong cuộc họp Lập kế hoạch Sprint. Phạm vi của sprint được làm rõ và thương lượng lại giữa Product Owner và Nhóm Phát triển khi biết thêm về các yêu cầu. Do đó, mỗi Sprint gắn liền với nó, một định nghĩa về những gì sẽ được xây dựng, một thiết kế và kế hoạch linh hoạt sẽ hướng dẫn việc xây dựng nó, công việc phát triển và kết quả của sản phẩm.

Một Sprint nên được hủy bỏ nếu Mục tiêu Sprint trở nên lỗi thời. Điều này có thể xảy ra nếu tổ chức thay đổi hướng đi hoặc nếu điều kiện thị trường hoặc công nghệ thay đổi. Chỉ chủ sở hữu sản phẩm mới có thể hủy chạy nước rút, mặc dù những người khác cũng có ảnh hưởng như vậy.

Do tính chất thời lượng ngắn của Sprint, việc hủy bỏ trong một sprint hiếm khi có ý nghĩa. Vì việc hủy bỏ sprint tiêu tốn tài nguyên, để tổ chức lại thành một Sprint khác, chúng rất hiếm gặp.

Nếu Sprint bị hủy bỏ và một phần công việc được sản xuất trong sprint có khả năng bị hủy bỏ, thì Product Owner thường chấp nhận nó. Tất cả các Mục Sprint Backlog chưa hoàn thành sẽ được đưa trở lại Product Backlog.

Kế hoạch nước rút

Công việc sẽ được thực hiện trong Sprint được lên kế hoạch trong Cuộc họp lập kế hoạch Sprint. Cuộc họp Lập kế hoạch Sprint có thời lượng tối đa là bốn giờ cho nước rút hai tuần và tám giờ cho một tháng. Scrum Master có trách nhiệm đảm bảo rằng cuộc họp diễn ra và tất cả những người tham dự được yêu cầu đều có mặt và hiểu mục đích của cuộc họp đã lên lịch. Scrum Master kiểm duyệt cuộc họp để giám sát việc duy trì cuộc thảo luận và kết thúc đúng thời gian.

Lập kế hoạch Sprint tập trung vào hai câu hỏi sau:

Những gì cần phải có và có thể được cung cấp trong Sprint Increment?
Công việc cần thiết để thực hiện Sprint sẽ đạt được như thế nào?

Các yếu tố đầu vào cho cuộc họp này là:

Sản phẩm tồn đọng
Sự gia tăng sản phẩm mới nhất
Năng lực dự kiến của Nhóm trong Sprint
Thành tích trong quá khứ của Đội

Nhóm Scrum thảo luận về chức năng có thể được phát triển trong Sprint. Product Owner cung cấp thông tin làm rõ về các hạng mục Product Backlog. Nhóm sẽ chọn các hạng mục từ Product Backlog cho Sprint, vì chúng là những hạng mục tốt nhất để đánh giá những gì họ có thể hoàn thành trong Sprint. Nhóm bao gồm các nhà phân tích, nhà thiết kế, nhà phát triển và người thử nghiệm. Công việc được thực hiện theo kiểu cộng tác nên hạn chế tối đa việc làm lại.

Nhóm Scrum sau đó đưa ra Mục tiêu Sprint. Mục tiêu Sprint là một mục tiêu cung cấp hướng dẫn cho Nhóm về lý do tại sao Nhóm xây dựng Phần tăng trưởng Sản phẩm. Sau đó, Nhóm sẽ quyết định cách họ sẽ xây dựng chức năng đã chọn thành một Sản phẩm hoạt động được trong Sprint. Các hạng mục Product Backlog được chọn cho Sprint này cộng với kế hoạch phân phối chúng được gọi là Sprint Backlog.

Công việc trong một sprint được ước tính trong quá trình lập kế hoạch sprint và có thể có quy mô và / hoặc nỗ lực khác nhau. Vào cuối cuộc họp Lập kế hoạch Sprint, công việc được chia thành các nhiệm vụ có thời lượng từ một ngày trở xuống. Điều này giúp dễ dàng phân bổ công việc và theo dõi việc hoàn thành. Nếu Nhóm nhận thấy rằng họ có quá nhiều hoặc quá ít công việc, Nhóm có thể thương lượng lại các hạng mục Product Backlog đã chọn với Product Owner.

Nhóm cũng có thể mời những người khác (không thuộc Nhóm Scrum) tham dự cuộc họp Lập kế hoạch Sprint để nhận được lời khuyên về lĩnh vực hoặc kỹ thuật hoặc trợ giúp trong việc ước lượng.

Các cuộc họp Scrum hàng ngày

Cuộc họp Scrum Hàng ngày là cuộc họp kéo dài 15 phút dành cho Nhóm, được tiến hành hàng ngày để hiểu nhanh công việc kể từ Cuộc họp Scrum Hàng ngày cuối cùng và lập kế hoạch cho 24 giờ tới. Cuộc họp này còn được gọi là Cuộc họp Đứng lên Hàng ngày.

Cuộc họp Scrum Hàng ngày được tổ chức tại cùng một thời điểm và cùng một địa điểm mỗi ngày để giảm bớt sự phức tạp.

Trong cuộc họp, mỗi thành viên trong Nhóm giải thích:

Anh ấy đã làm gì ngày hôm qua để giúp Nhóm đạt được Mục tiêu Nước rút?
Anh ấy sẽ làm gì hôm nay để giúp Nhóm đạt được Mục tiêu Sprint?
Anh ấy có thấy bất kỳ trở ngại nào ngăn cản anh ấy hoặc Nhóm nghiên cứu đạt được Mục tiêu Nước rút không?

Scrum hàng ngày bị nhầm là một sự kiện theo dõi trạng thái, tuy nhiên, trên thực tế, nó là một sự kiện lập kế hoạch.

Đầu vào cho cuộc họp phải là cách nhóm đang thực hiện để đạt được Mục tiêu Sprint và đầu ra phải là một kế hoạch mới hoặc được sửa đổi để tối ưu hóa nỗ lực của nhóm trong việc đạt được Mục tiêu Sprint.

Mặc dù Scrum Master điều phối Cuộc họp Scrum Hàng ngày và đảm bảo rằng các mục tiêu của cuộc họp được đáp ứng, Cuộc họp là trách nhiệm của Nhóm.

Nếu cần, Nhóm có thể họp ngay sau Cuộc họp Scrum Hàng ngày, để thảo luận chi tiết hoặc để lập kế hoạch lại phần còn lại của công việc Sprint.

Sau đây là những lợi ích của Cuộc họp Scrum Hàng ngày -

Cải thiện giao tiếp trong Nhóm.
Xác định những trở ngại, nếu có, để tạo điều kiện sớm loại bỏ những trở ngại tương tự, để giảm thiểu tác động đến Sprint.
Làm nổi bật và thúc đẩy việc ra quyết định nhanh chóng.
Nâng cao trình độ hiểu biết của Đội.

Đánh giá Sprint

Đánh giá Sprint được tổ chức vào cuối mỗi Sprint. Trong buổi Sơ kết Sprint, bản trình bày về phần gia tăng sắp được phát hành sẽ được xem xét. Trong cuộc họp này, Nhóm Scrum và các bên liên quan hợp tác để hiểu những gì đã được thực hiện trong Sprint. Dựa trên điều đó, và bất kỳ thay đổi nào đối với Product Backlog trong Sprint, những người tham dự sẽ thực hiện các bước tiếp theo được yêu cầu để có thể tối ưu hóa giá trị. Do đó, mục tiêu của Sơ kết Sprint là thu thập phản hồi và tiến trình một cách thống nhất.

Buổi Sơ kết Nước rút thường được tổ chức trong hai giờ cho nước rút hai tuần và bốn giờ cho nước rút một tháng.

Scrum Master đảm bảo rằng -

Cuộc họp diễn ra.
Những người tham gia hiểu rõ mục đích.
Cuộc họp tập trung vào chương trình được yêu cầu và được hoàn thành trong thời gian yêu cầu.

Sơ kết Sprint bao gồm các khía cạnh sau:

Những người tham dự bao gồm Nhóm Scrum và các bên liên quan chính, được Chủ sở hữu sản phẩm mời.
Product Owner giải thích những hạng mục Product Backlog đã được hoàn thành trong sprint và những gì chưa được hoàn thành.
Nhóm thảo luận về những gì diễn ra tốt đẹp trong Sprint, những vấn đề mà nó gặp phải và cách giải quyết những vấn đề đó.
Nhóm trình bày công việc đã hoàn thành và trả lời các câu hỏi, nếu có, về Phần tăng thêm.
Sau đó, toàn bộ nhóm thảo luận về những việc cần làm tiếp theo. Do đó, Sơ kết Sprint cung cấp thông tin đầu vào có giá trị cho việc Lập kế hoạch Sprint của Sprint tiếp theo.
Sau đó, Nhóm Scrum xem xét tiến trình, ngân sách, khả năng tiềm năng và thị trường cho lần phát hành sản phẩm dự kiến tiếp theo.
Kết quả của Sơ kết Sprint là một Product Backlog được cập nhật, xác định các hạng mục Product Backlog có thể xảy ra cho Sprint tiếp theo.

Sprint Retrospective

Sơ kết Sprint diễn ra sau Sơ kết Sprint và trước khi Lập kế hoạch Sprint tiếp theo. Đây thường là một cuộc họp kéo dài một giờ cho các cuộc chạy nước rút kéo dài hai tuần và một cuộc họp ba giờ cho một cuộc họp Sprint kéo dài một tháng.

Mục đích của Sprint Retrospective là -

Kết hợp những bài học từ Sprint trước, liên quan đến con người, mối quan hệ, quy trình và công cụ.
Xác định các hạng mục chính hoạt động tốt và các cải tiến tiềm năng.
Lập kế hoạch thực hiện các cải tiến để tăng chất lượng sản phẩm.

Sprint Retrospective là cơ hội để Nhóm Scrum xem xét và cải tiến trong khuôn khổ quy trình Scrum để làm cho kết quả Sprint tiếp theo hiệu quả hơn.

Reference

Scrum Artifacts cung cấp thông tin chính mà Nhóm Scrum và các bên liên quan cần biết để hiểu sản phẩm đang được phát triển, các hoạt động đã thực hiện và các hoạt động đang được lên kế hoạch trong dự án. Các tạo tác sau được định nghĩa trong Khung quy trình Scrum:

Tồn đọng sản phẩm
Sprint backlog
Biểu đồ ghi xuống
Increment

Đây là những tạo tác bắt buộc tối thiểu trong một dự án scrum và những tạo tác của dự án không bị giới hạn bởi những điều này.

Tồn đọng sản phẩm

Product Backlog là danh sách theo thứ tự các tính năng cần thiết như một phần của sản phẩm cuối cùng và nó là nguồn yêu cầu duy nhất cho bất kỳ thay đổi nào đối với sản phẩm.

Product Backlog liệt kê tất cả các tính năng, chức năng, yêu cầu, cải tiến và bản sửa lỗi cấu thành những thay đổi sẽ được thực hiện đối với sản phẩm trong các bản phát hành trong tương lai. Các mục Product Backlog có các thuộc tính mô tả, đơn hàng, ước tính và giá trị. Những mục này thường được gọi là Câu chuyện của người dùng. Chủ sở hữu sản phẩm chịu trách nhiệm về Product Backlog, bao gồm nội dung, tính khả dụng và đặt hàng của nó.

Product Backlog là một hiện vật đang phát triển. Phiên bản sớm nhất của nó có thể chỉ chứa các yêu cầu ban đầu được biết đến và hiểu rõ nhất. Product Backlog được phát triển như một sản phẩm và môi trường mà nó sẽ được sử dụng, tiến triển. Product Backlog liên tục thay đổi để kết hợp những gì cần thiết để làm cho nó hiệu quả. Miễn là một sản phẩm tồn tại, Product Backlog của nó cũng tồn tại.

Khi sản phẩm đang được xây dựng được sử dụng và thu được giá trị, Product Backlog trở thành một danh sách lớn hơn và đầy đủ hơn. Những thay đổi về yêu cầu kinh doanh, điều kiện thị trường hoặc công nghệ, gây ra những thay đổi trong Product Backlog, khiến nó trở thành hiện vật sống động.

Tinh chỉnh Product Backlog có nghĩa là thêm chi tiết, ước tính và thứ tự ưu tiên vào các mục Product Backlog. Đây là một quá trình liên tục được thực hiện bởi Product Owner và Nhóm. Nhóm Scrum quyết định cách thức và thời điểm thực hiện sàng lọc.

Các hạng mục Product Backlog có thể được cập nhật bất kỳ lúc nào bởi Product Owner hoặc theo quyết định của Product Owner.

Các mục Product Backlog được đặt hàng cao hơn thường rõ ràng và chi tiết hơn những mục có thứ tự thấp hơn. Các ước tính chính xác hơn được thực hiện dựa trên độ rõ ràng hơn và tăng chi tiết. Thứ tự càng thấp, càng ít chi tiết.

Các hạng mục Product Backlog có thể là yêu cầu ứng viên cho Sprint sắp tới được tinh chỉnh để các hạng mục này có thể được phát triển trong Sprint. Các hạng mục Product Backlog mà Nhóm có thể phát triển trong một Sprint được coi là đã sẵn sàng để lựa chọn trong cuộc họp lập kế hoạch Sprint.

Sprint backlog

Sprint Backlog là tập hợp các hạng mục Product Backlog được chọn cho Sprint, cùng với một kế hoạch để cung cấp Phần tăng trưởng của sản phẩm và thực hiện Mục tiêu Sprint.

Sprint Backlog là dự báo của Nhóm về chức năng nào sẽ được cung cấp trong Phần tiếp theo và công việc cần thiết để cung cấp chức năng đó như một Phần tăng thêm sản phẩm đang hoạt động.

Sprint Backlog là một kế hoạch có đủ chi tiết để có thể hiểu được nhưng Nhóm cần theo dõi trong Scrum Hằng ngày. Nhóm điều chỉnh Sprint Backlog trong suốt Sprint và Sprint Backlog xuất hiện trong Sprint. Sự xuất hiện này xảy ra khi Nhóm làm việc thông qua kế hoạch và tìm hiểu thêm về công việc cần thiết để đạt được Mục tiêu Sprint.

Khi công việc mới được yêu cầu, Nhóm sẽ thêm nó vào Sprint Backlog. Khi công việc được thực hiện hoặc hoàn thành, công việc ước tính còn lại sẽ được cập nhật. Khi các yếu tố của kế hoạch được coi là không cần thiết, chúng sẽ bị loại bỏ. Chỉ Nhóm có thể thay đổi Sprint Backlog của mình trong Sprint. Sprint Backlog là một bức tranh thời gian thực, dễ nhìn thấy về công việc mà Nhóm dự định hoàn thành trong Sprint và nó chỉ thuộc về Nhóm.

Tăng

Phần tăng thêm là tổng của tất cả các hạng mục Product Backlog đã hoàn thành trong một Sprint kết hợp với phần tăng thêm của tất cả các Sprint trước đó. Vào cuối Sprint, Phần tăng thêm mới phải là một sản phẩm đang hoạt động, có nghĩa là nó phải ở trong tình trạng có thể sử dụng được. Nó phải ở trong tình trạng hoạt động bất kể Product Owner quyết định phát hành nó thực sự hay không.

Nhóm Scrum cần có sự đồng thuận về những gì được coi là Phần gia tăng. Điều này thay đổi đáng kể đối với Nhóm Scrum, nhưng các thành viên trong nhóm phải có sự hiểu biết chung về ý nghĩa của việc hoàn thành công việc. Điều này được sử dụng để đánh giá khi nào công việc hoàn thành trên Phần tăng trưởng sản phẩm.

Sự hiểu biết tương tự sẽ hướng dẫn Nhóm nghiên cứu biết số lượng hạng mục Product Backlog mà Nhóm có thể chọn trong Lập kế hoạch Sprint. Mục đích của mỗi Sprint là cung cấp các Phần mở rộng của chức năng có thể liên quan.

Các nhóm cung cấp Sự gia tăng chức năng của sản phẩm mỗi Sprint. Phần tăng thêm này có thể sử dụng được, vì vậy Chủ sở hữu sản phẩm có thể chọn phát hành nó ngay lập tức. Nếu sự hiểu biết về phần gia tăng là một phần của các quy ước, tiêu chuẩn hoặc hướng dẫn của tổ chức phát triển, thì tất cả các Nhóm Scrum phải tuân theo mức tối thiểu đó. Nếu đó không phải là quy ước của tổ chức phát triển, Nhóm Scrum phải xác định định nghĩa về Phần tăng trưởng phù hợp với sản phẩm.

Mỗi Phần tăng thêm là phụ gia cho tất cả các Phần tăng thêm trước đó và được kiểm tra kỹ lưỡng, đảm bảo rằng tất cả các Phần tăng thêm hoạt động cùng nhau.

Khi Nhóm Scrum trưởng thành, dự kiến rằng định nghĩa của họ về Phần tăng thêm sẽ mở rộng để bao gồm các tiêu chí nghiêm ngặt hơn để có chất lượng cao hơn. Bất kỳ một sản phẩm nào cũng nên có một định nghĩa về Tăng trưởng là tiêu chuẩn cho bất kỳ công việc nào được thực hiện trên đó.

Biểu đồ ghi xuống nước rút

Tại bất kỳ thời điểm nào trong Sprint, có thể tính tổng công việc còn lại trong Sprint Backlog. Nhóm nghiên cứu theo dõi tổng số công việc còn lại này cho mỗi buổi Scrum Hằng ngày để dự đoán khả năng đạt được Mục tiêu Sprint. Bằng cách theo dõi các công việc còn lại trong suốt Sprint, Nhóm có thể quản lý tiến độ của nó.

Sprint Burn-Down Chart là một phương pháp thực hành để xác định xu hướng công việc được Nhóm Scrum thực hiện. Điều này đã được chứng minh là một kỹ thuật hữu ích trong việc theo dõi tiến trình Sprint hướng tới Mục tiêu Sprint.

Chủ sở hữu sản phẩm theo dõi tổng số công việc còn lại này ít nhất mỗi Sprint Review. Product Owner so sánh số tiền này với công việc còn lại trong các buổi Đánh giá Sprint trước để đánh giá tiến độ hoàn thành công việc dự kiến theo thời gian mong muốn cho mục tiêu. Thông tin này được chia sẻ với tất cả các bên liên quan.

Phần kết luận

Các vai trò, sự kiện, hiện vật và quy tắc của Scrum là không thể tránh khỏi. Nếu chỉ một số phần của Scrum được triển khai, kết quả không phải là Scrum. Scrum cần được triển khai toàn bộ và hoạt động tốt nếu phù hợp với các kỹ thuật, phương pháp luận và thông lệ khác.

Reference

Như bạn đã hiểu, Câu chuyện người dùng thường được sử dụng để mô tả các tính năng của sản phẩm và sẽ tạo thành một phần của Tạo tác Scrum - Product Backlog và Sprint Backlog.

Câu chuyện của người dùng

Trong phát triển phần mềm, các tính năng của sản phẩm đóng một vai trò quan trọng. Đó là các tính năng mà người dùng cuối cùng thích sử dụng trong sản phẩm cuối cùng. Chúng được gọi là Yêu cầu trong thuật ngữ chung. Sự thành công của dự án phát triển phần mềm nằm ở việc hiểu các yêu cầu của người dùng một cách chính xác và phù hợp, sau đó thực hiện chúng trong sản phẩm cuối cùng. Do đó, các yêu cầu hoặc tính năng của sản phẩm cần được nhóm dự án phát triển biết kỹ lưỡng.

Năm 1999, Kent Beck đưa ra thuật ngữ Câu chuyện người dùng cho các tính năng của sản phẩm. Ông mô tả rằng một Câu chuyện người dùng được tường thuật từ góc độ người dùng liên quan đến những gì họ muốn có hơn là những gì hệ thống có thể làm cho anh ta. Do đó, chế độ xem đã thay đổi hoàn toàn từ sản phẩm sang người dùng và Câu chuyện của người dùng trở thành tiêu chuẩn thực tế cho các Yêu cầu trong tất cả các khuôn khổ Agile.

Trong các dự án Scrum, Product Backlog là một danh sách các câu chuyện của người dùng. Những Câu chuyện Người dùng này được ưu tiên và đưa vào Sprint Backlog trong Cuộc họp Lập kế hoạch Sprint.

Ước tính cũng dựa trên câu chuyện của người dùng và quy mô của sản phẩm được ước tính trong Điểm câu chuyện của người dùng.

Cấu trúc câu chuyện người dùng

Cấu trúc Câu chuyện người dùng như sau:

Với tư cách là <Loại người dùng> ,

Tôi muốn <Thực hiện một số tác vụ> ,

Để <Tôi có thể đạt được mục tiêu / lợi ích / giá trị nào đó> .

Hãy cùng chúng tôi xem xét cách một câu chuyện người dùng được đóng khung cho tình huống Khách hàng Ngân hàng rút tiền mặt từ ATM.

Câu chuyện người dùng: Rút tiền mặt của khách hàng

Như một Customer,

tôi muốn withdraw cash from an ATM,

Vậy nên I don't have to wait in line at the Bank

Tiêu chí chấp nhận câu chuyện của người dùng

Mỗi Câu chuyện người dùng cũng có Tiêu chí chấp nhận được xác định, do đó, tính đúng đắn của việc triển khai câu chuyện người dùng được xác nhận bằng cách vượt qua Kiểm tra chấp nhận dựa trên Tiêu chí chấp nhận.

Sau đây là tiêu chí chấp nhận mẫu cho ví dụ về việc rút tiền mặt của khách hàng trong User Story.

Acceptance Criterion 1:

Given rằng tài khoản đáng tin cậy

Và thẻ hợp lệ
Và bộ phân phối chứa tiền mặt,

When khách hàng yêu cầu tiền mặt

Then đảm bảo tài khoản được ghi nợ

Và đảm bảo tiền mặt được phân phối
Và đảm bảo thẻ được trả lại.

Acceptance Criterion 2:

Given rằng tài khoản được thấu chi

Và thẻ hợp lệ

When khách hàng yêu cầu tiền mặt

Then đảm bảo thông báo từ chối được hiển thị

Và đảm bảo tiền mặt không được phân phối
Và đảm bảo thẻ được trả lại.

Viết câu chuyện người dùng

Chủ sở hữu sản phẩm chịu trách nhiệm về Product Backlog và do đó đối với Câu chuyện của người dùng. Tuy nhiên, nó không có nghĩa là chỉ có chủ sở hữu sản phẩm mới viết những câu chuyện của người dùng. Bất kỳ ai trong Nhóm Scrum đều có thể viết câu chuyện của người dùng và hoạt động có thể được dàn trải trong toàn bộ dự án khi các yêu cầu được tinh chỉnh và các chức năng mới được bổ sung.

Yêu cầu phi chức năng trong câu chuyện của người dùng

Có thể kết hợp các yêu cầu phi chức năng trong các câu chuyện của người dùng. Trong ví dụ về máy ATM đã cho, máy ATM có sẵn cho người dùng 24X7, 365 ngày là một yêu cầu phi chức năng, có thể được mô tả bằng một trường hợp sử dụng.

Quản lý câu chuyện của người dùng

Câu chuyện của người dùng được quản lý trong Product Backlog. Câu chuyện của người dùng được sắp xếp theo mức độ ưu tiên. Các câu chuyện của người dùng được ưu tiên nhất được tinh chỉnh ở mức chi tiết, trong khi các câu chuyện của người dùng ít ưu tiên nhất được giữ ở mức chi tiết hơn. Đối với mỗi sprint, những câu chuyện về người dùng được ưu tiên nhất và do đó chi tiết hơn sẽ được đưa vào sprint backlog. Nếu một câu chuyện của người dùng được thêm vào product backlog, thì mức độ ưu tiên của nó sẽ được xác định trước tiên và nó được đặt theo vị trí của nó theo mức độ ưu tiên. Các câu chuyện của người dùng có thể được đánh giá lại bất cứ lúc nào. Cũng có thể xóa bất kỳ câu chuyện người dùng nào nếu được yêu cầu.

Lợi ích với Câu chuyện của người dùng

Lợi ích chính của Câu chuyện người dùng nằm ở chính định nghĩa lấy người dùng làm trung tâm. Điều này là do cuối cùng, chính người dùng sẽ sử dụng sản phẩm trong các tình huống người dùng có liên quan. Nó kết nối người dùng cuối với các thành viên trong nhóm.
Bản thân cú pháp của Câu chuyện người dùng đảm bảo nắm bắt được mục tiêu hoặc lợi ích hoặc giá trị mà người dùng muốn đạt được.
Vì các tiêu chí chấp nhận tạo thành một phần của câu chuyện người dùng nên nó sẽ là một lợi thế bổ sung cho Nhóm Scrum.
Có thể thực hiện các thay đổi đối với câu chuyện người dùng trong quá trình thực hiện dự án. Nếu phạm vi của câu chuyện người dùng trở nên lớn, nó cần được chia thành các câu chuyện người dùng nhỏ hơn. Các điều kiện trong tiêu chí chấp nhận cũng có thể được thay đổi.
Khi các sản phẩm gia tăng đang hoạt động được chuyển đến người dùng vào cuối mỗi sprint, nhóm scrum có thể nhận được phản hồi từ người dùng trong cuộc họp đánh giá sprint. Điều này cho phép liên tục kết hợp phản hồi vào sản phẩm.

Phần kết luận

Câu chuyện người dùng của Scrum đưa người dùng đến gần hơn với nhóm Scrum và ngăn chặn những bất ngờ vào phút cuối.

Theo dõi sprint thường được thực hiện bằng cách sử dụng Burn-Down Chart. Biểu đồ Burn-Down cho thấy nỗ lực còn lại theo số giờ hàng ngày. Ví dụ, chúng ta hãy xem xét chạy nước rút 2 tuần -

Sprint Duration: 2 tuần

No. of Days per Week: 5

No. of Hrs. per Day: 6

No. of Resources: 6

Do đó, tổng số nỗ lực còn lại khi bắt đầu chạy nước rút là 2 * 5 * 6 * 6 = 360 giờ.

Do đó, trong một kịch bản lý tưởng, 36 giờ làm việc được giảm bớt trong số công việc còn lại và biểu đồ tiêu hao trông như sau:

Nếu công việc chạy nước rút được thực hiện theo kế hoạch hàng ngày, thì tiến độ scrum gần như được điều chỉnh đến mức lý tưởng.

Nếu công việc chạy nước rút bị trì hoãn và không đạt được cam kết về thời gian, biểu đồ ghi lại sẽ như sau:

Tuy nhiên, vì biểu đồ giảm giá được vẽ hàng ngày và sự trượt giá được biết sớm, nên các hành động điều chỉnh có thể được thực hiện để đáp ứng đường thời gian nước rút. Giả sử, nhóm kéo dài để đáp ứng mốc thời gian, biểu đồ giảm giá trông như sau:

Do đó, tại bất kỳ thời điểm nào trong Sprint, tổng công việc còn lại trong Sprint có thể được hình dung và khả năng tiến hành cuộc họp sprint có thể được cải thiện.

Phần kết luận

Biểu đồ ghi giảm giúp nhóm Scrum theo dõi tiến trình của họ và những việc cần làm để đạt được mục tiêu nước rút.

Trong các Dự án Scrum, Ước tính được thực hiện bởi toàn bộ nhóm trong Cuộc họp Lập kế hoạch Sprint. Mục tiêu của Ước tính sẽ là xem xét các Câu chuyện của Người dùng cho Sprint theo mức độ ưu tiên và theo Khả năng của nhóm thực hiện trong Khung thời gian của Sprint.

Chủ sở hữu sản phẩm đảm bảo rằng Câu chuyện của người dùng được ưu tiên là rõ ràng, có thể được ước tính và chúng được đưa vào phần đầu của Product Backlog.

Vì toàn bộ Nhóm Scrum chịu trách nhiệm phân phối phần gia tăng sản phẩm, nên cẩn thận khi lựa chọn Câu chuyện của người dùng cho Sprint dựa trên quy mô của Phần gia tăng sản phẩm và nỗ lực cần thiết cho việc tương tự.

Quy mô của Phần gia tăng sản phẩm được ước tính theo Điểm câu chuyện của người dùng. Sau khi quy mô được xác định, nỗ lực được ước tính bằng dữ liệu trong quá khứ, tức là nỗ lực trên mỗi Điểm câu chuyện của người dùng được gọi là Năng suất.

Kỹ thuật ước tính Scrum

Ước tính Scrum về Câu chuyện của người dùng dựa trên mức độ khó của từng Câu chuyện của người dùng. Để đánh giá mức độ khó, một thang điểm cụ thể được sử dụng.

Có một số loại thang đo được sử dụng trong Ước lượng Scrum. Sau đây là một số ví dụ -

Định cỡ số (1 đến 10)
Kích cỡ áo phông (XS, S, M, L, XL XXL, XXXL)
Trình tự Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, v.v.)
Các giống chó (Chihuahua, ………, Great Dane)

Kỹ thuật ước lượng thường được chọn theo cách mà toàn bộ nhóm scrum đều quen thuộc và cảm thấy thoải mái với các giá trị của thang đo. Kỹ thuật được sử dụng phổ biến nhất và phổ biến nhất là Planning Poker dựa trên chuỗi Fibonacci.

Lập kế hoạch Kỹ thuật Poker

Trong Kỹ thuật Lập kế hoạch Ước tính Poker, các ước tính cho Câu chuyện của Người dùng được tính bằng cách lập kế hoạch chơi Poker. Toàn bộ Nhóm Scrum đều tham gia và nó dẫn đến các ước tính nhanh chóng nhưng đáng tin cậy.

Planning Poker được chơi với một bộ bài. Khi sử dụng dãy Fibonacci, các thẻ có các số - 1, 2, 3, 5, 8, 13, 21, 34, v.v. Những con số này đại diện cho Điểm câu chuyện. Mỗi người ước tính có một bộ bài. Các số trên thẻ phải đủ lớn để tất cả các thành viên trong nhóm có thể nhìn thấy khi một trong các thành viên trong nhóm giơ thẻ.

Một trong những thành viên trong nhóm được chọn làm Người điều hành. Người điều hành đọc mô tả của Câu chuyện người dùng mà ước tính đang được thực hiện. Nếu người ước tính có bất kỳ câu hỏi nào, Product Owner sẽ trả lời họ.

Mỗi người ước tính chọn riêng một thẻ đại diện cho ước tính của họ. Các thẻ không được hiển thị cho đến khi tất cả những người ước tính đã thực hiện lựa chọn. Khi đó, tất cả các thẻ đồng thời được lật lên và giơ lên để tất cả các thành viên trong nhóm có thể xem từng ước tính.

Trong vòng đầu tiên, rất có thể các ước tính sẽ khác nhau. Các nhà ước tính cao và thấp giải thích lý do cho các ước tính của họ. Cần lưu ý rằng tất cả các cuộc thảo luận chỉ nhằm mục đích hiểu biết và không có gì được thực hiện với tư cách cá nhân. Người điều hành phải đảm bảo như vậy.

Nhóm có thể thảo luận về câu chuyện và ước tính của họ trong vài phút nữa.

Người điều hành có thể ghi chú vào cuộc thảo luận sẽ hữu ích khi câu chuyện cụ thể được phát triển. Sau khi thảo luận, mỗi người ước tính ước tính lại bằng cách chọn lại một thẻ. Các thẻ một lần nữa được giữ bí mật cho đến khi mọi người đã ước tính, tại thời điểm đó chúng được lật cùng một lúc.

Lặp lại quá trình cho đến khi các ước tính hội tụ thành một ước tính duy nhất có thể được sử dụng cho câu chuyện. Số lượng vòng ước tính có thể thay đổi tùy theo từng câu chuyện của người dùng.

Lợi ích của Lập kế hoạch Ước tính Poker

Lập kế hoạch chơi poker kết hợp ba phương pháp ước tính -

Expert Opinion: Trong cách tiếp cận Ước tính dựa trên Ý kiến của Chuyên gia, một chuyên gia được hỏi về một thứ gì đó sẽ mất bao lâu hoặc nó sẽ lớn như thế nào. Chuyên gia cung cấp một ước tính dựa trên kinh nghiệm hoặc trực giác hoặc cảm giác của họ.

Ước tính ý kiến chuyên gia thường không mất nhiều thời gian và chính xác hơn so với một số phương pháp phân tích.

Analogy: Ước tính tương tự sử dụng so sánh Câu chuyện của người dùng. Câu chuyện người dùng trong Ước tính được so sánh với Câu chuyện người dùng tương tự được triển khai trước đó. Điều này dẫn đến kết quả chính xác vì ước tính dựa trên dữ liệu đã được chứng minh.

Disaggregation: Ước tính phân biệt được thực hiện bằng cách chia Câu chuyện người dùng thành Câu chuyện người dùng nhỏ hơn, dễ ước tính hơn. Các câu chuyện người dùng được đưa vào Sprint thường trong khoảng từ hai đến năm ngày để phát triển. Do đó, các Câu chuyện người dùng có thể kéo dài thời gian hơn cần được chia thành các Trường hợp sử dụng nhỏ hơn. Cách tiếp cận này cũng đảm bảo rằng sẽ có nhiều câu chuyện có thể so sánh được.

Phần kết luận

Lập kế hoạch Poker là một cách tiếp cận thú vị nhưng hiệu quả để ước tính. Vì phiên này mở để thảo luận trước khi có ước tính cuối cùng, nên nhóm sẽ dễ dàng đi đến thống nhất và cũng có cái nhìn bao quát về việc triển khai User Story.

Công cụ Scrum tạo điều kiện thuận lợi cho việc lập kế hoạch và theo dõi cho các dự án Scrum. Họ cung cấp một nơi duy nhất để quản lý sản phẩm tồn đọng, tồn đọng sprint, lập kế hoạch và theo dõi Sprint, hiển thị biểu đồ Burndown, tiến hành các cuộc họp Scrum hàng ngày và tiến hành các Cải tiến Scrum.

Có nhiều loại Công cụ Scrum khác nhau có sẵn. Một số miễn phí (mã nguồn mở), một số trả phí và đối với một số, bạn nhận được phiên bản chắt lọc của công cụ. Tuy nhiên, để có được tất cả các tính năng và khả năng mở rộng, bạn cần phải mua một phiên bản đầy đủ.

Các công cụ Scrum có sẵn

Sau đây là danh sách một số Công cụ Scrum hiện có trên thị trường. Công cụ Nguồn mở được đánh dấu bằng Dấu hoa thị.

Axosoft	Nhanh nhẹn	Buồng lái nhanh nhẹn	Jira (GreenHopper)	Hòa mình
Scrumwise	Agilo cho Scrum	Banana Scrum	Kunagi	OnTime ngay
Phiên bản Một	AgileWrap	Scrum Hằng ngày	Khoảng thời gian	Pango Scrum
Acunote	Công cụ theo dõi Agile *	Digaboard *	iMeta Nhanh nhẹn	Pivotal Tracker
Chương trình làm việc nhanh nhẹn	Nhiệm vụ nhanh	EasyBacklog	Ice Scrum *	pmScrum
Ghế dài nhanh nhẹn	Agile Soup	Giải thích PMT	Hansoft	Prj Planner
Bạn thân nhanh nhẹn	Người quản lý nhanh nhẹn	Agile Express *	GravityDev	Thẻ dự án
Agile Fant *	Nhật ký nhanh nhẹn	Fire Scrum *	Điểm tựa *	Quantum Whisper
Scrum nhanh	Retrospectiva *	Scrum'd	Nhà máy Scrum *	Cục cằn
Rally Dev	Scrinch *	Bảng điều khiển Scrum *	Scrum Edge	Scrum Pad
Tìm kiếm lại các Backlog	Scrum 2 Go	Bàn Scrum	Scrum Do	Tweet Scrum
Scrumrf	Thời gian Scrum *	Scrumwise	Chọn Nhà máy Giải pháp	Tranh bóng *
Rùa đô thị	ScrumTool	Scrum Works	Hộp thời gian	Tangy Orange Scrum

Phần kết luận

Agile nói chung, Scrum nói riêng không có nghĩa là không có tài liệu hướng dẫn. Các Tạo tác Scrum được xác định, Lập kế hoạch và Theo dõi Scrum được thiết lập tốt.

Công cụ Scrum tạo điều kiện thuận lợi trong việc nắm bắt và theo dõi thông tin liên quan đến các Dự án Scrum. Việc lựa chọn công cụ phụ thuộc vào các tính năng mà tổ chức yêu cầu, ngoài ra còn có nhu cầu đối với bất kỳ công cụ nào khác.

Scrum hỗ trợ sự hợp tác liên tục giữa khách hàng, các thành viên trong nhóm và các bên liên quan có liên quan. Phương pháp tiếp cận theo thời gian và phản hồi liên tục từ chủ sở hữu sản phẩm đảm bảo sản phẩm luôn hoạt động với các tính năng cần thiết. Ngoài ra, Scrum cung cấp các lợi ích khác nhau cho các vai trò khác nhau trong dự án.

Lợi ích cho khách hàng

Các Sprint có thời lượng ngắn hơn và các câu chuyện của người dùng được ưu tiên được đưa vào mỗi lần lập kế hoạch chạy nước rút. Nó đảm bảo rằng tại mỗi lần giao hàng nước rút, các tính năng theo yêu cầu của khách hàng ngay lập tức được đưa vào. Hơn nữa, nếu khách hàng đưa ra bất kỳ yêu cầu thay đổi nào, thì yêu cầu đó sẽ được đưa vào nước rút hiện tại hoặc được đưa vào nước rút tiếp theo. Vì vậy, đội ngũ phát triển nhanh chóng đáp ứng các yêu cầu của khách hàng rất nhanh.

Lợi ích đối với tổ chức

Tổ chức có thể tập trung vào nỗ lực cần thiết để phát triển các câu chuyện người dùng được ưu tiên và do đó giảm chi phí và công việc lại. Do những lợi ích cụ thể của scrum đối với khách hàng, việc tăng hiệu quả của nhóm phát triển, sự hài lòng của khách hàng và do đó sẽ có thể duy trì khách hàng và giới thiệu khách hàng. Nó làm tăng tiềm năng thị trường của tổ chức.

Lợi ích cho người quản lý sản phẩm

Product Manager đóng vai trò là Product Owner trong dự án. Trách nhiệm của chủ sở hữu sản phẩm là đảm bảo sự hài lòng của khách hàng. Vì Scrum tạo điều kiện cho phản hồi nhanh, ưu tiên công việc, tiếp thu các thay đổi, người quản lý sản phẩm có thể dễ dàng đảm bảo rằng công việc phù hợp với nhu cầu của khách hàng, từ đó đảm bảo sự hài lòng của khách hàng.

Lợi ích cho người quản lý dự án

Quản lý dự án đóng vai trò của Scrum Master trong dự án. Bản chất cộng tác của Scrum tạo điều kiện cho việc lập kế hoạch và theo dõi dễ dàng và cụ thể. Việc sử dụng Biểu đồ Burndown để hiểu công việc còn lại và các cuộc họp Scrum hàng ngày cung cấp cho Người quản lý dự án nhận thức về trạng thái của dự án tại mọi thời điểm. Nhận thức này là điều cần thiết để giám sát dự án và để nắm bắt và giải quyết các vấn đề một cách nhanh chóng.

Lợi ích đối với Nhóm phát triển

Do tính chất đóng hộp về thời gian của sprint và việc phân phối sản phẩm tăng dần vào cuối mỗi sprint, nhóm phát triển trở nên hào hứng khi thấy rằng công việc của họ được sử dụng ngay lập tức. Sự hợp tác trong nhóm được xây dựng khiến nhóm thích thú với công việc họ làm. Vì câu chuyện của người dùng cho mỗi sprint đều dựa trên các ưu tiên của khách hàng, nên nhóm cũng hiểu rằng công việc của họ được đánh giá cao.

Scrum Alliance cung cấp chứng chỉ Scrum. Các chứng chỉ sau đang được cung cấp -

ScrumMaster được chứng nhận (CSM)
Chủ sở hữu sản phẩm Scrum được chứng nhận (CSPO)
Học viên Scrum được chứng nhận (CSP)
Huấn luyện viên Scrum được chứng nhận (CSC)
Nhà đào tạo Scrum được chứng nhận (CST)

ScrumMaster được chứng nhận (CSM)

Certified Scrum Master là chứng chỉ cơ bản để trở thành thành viên của Scrum Alliance, đóng vai trò của Scrum Master và đủ điều kiện nhận các chứng chỉ khác. Chứng nhận yêu cầu tham gia khóa học CSM. Sau đó, ứng viên nhận được email nêu rõ các chi tiết về tư cách thành viên Scrum và bài kiểm tra trực tuyến CSM. Sau khi làm bài kiểm tra, ứng viên được cấp chứng chỉ Certified ScrumMaster (CSM).

Chủ sở hữu sản phẩm Scrum được chứng nhận (CSPO)

Chủ sở hữu sản phẩm Scrum được chứng nhận là chứng nhận cơ bản để trở thành thành viên của Liên minh Scrum, đóng vai trò Chủ sở hữu sản phẩm và đủ điều kiện nhận các chứng chỉ khác.

Học viên Scrum được chứng nhận (CSP)

Certified Scrum Practitioner là chứng chỉ dành cho các ScrumMasters và Chủ sở hữu sản phẩm có kinh nghiệm. Ứng viên phải là ScrumMaster hoặc Product Owner trong ít nhất một năm. Ứng viên phải nộp một đơn đăng ký có mô tả chi tiết về những gì họ đã làm trong vai trò được chỉ định.

Ứng viên có thể đạt được chứng chỉ CSP ngay sau chứng chỉ CSM hoặc chứng chỉ CSPO, miễn là ứng viên tích cực thực hành vai trò của ScrumMaster hoặc vai trò Chủ sở hữu sản phẩm trong thời gian bắt buộc.

Huấn luyện viên Scrum được chứng nhận (CSC)

Certified Scrum Coach là chứng chỉ dành cho những người tập trung vào huấn luyện. Chứng nhận yêu cầu ứng viên đã huấn luyện các Nhóm Scrum thông qua việc áp dụng và thông thạo Scrum của họ trong ít nhất 1500 giờ trong 5 năm qua.

Nhà đào tạo Scrum được chứng nhận (CST)

Certified Scrum Trainer là chứng chỉ dành cho những người muốn dạy các lớp CSM hoặc CSPO. Người nộp đơn phải có CSM hoặc CSPO và phải là CSP trong ít nhất một năm trước khi nộp đơn.

Sau đây là một số câu hỏi thường gặp về Scrum -

Question: What is the difference between Scrum and Agile Development?

Answer : Phát triển Agile là một phương pháp luận phần mềm, trong khi Scrum là một trong những khuôn khổ quy trình tuân theo Agile.

Question: Are Sprints and Iterations the same?

Answer: Cả Sprint of Scrum và Lặp đi lặp lại của mô hình Tăng dần lặp lại đều cung cấp các bước gia tăng sản phẩm hoạt động. Tuy nhiên, chúng khác nhau ở chỗ:

Vòng đời của Sprint và Lặp lại là khác nhau.
Sprint được đóng hộp thời gian, trong khi Lặp lại thì không.
Thời lượng Sprint ít hơn nhiều so với thời lượng Lặp lại.

Question: Is Scrum Master a job title or a role that someone with an existing job title fills?

Answer: Scrum Master là một vai trò mà một người có chức danh đảm nhiệm. Thực tế thông thường là người đóng vai trò quản lý dự án cũng đóng vai trò của ScrumMaster.

Question: Can Product Owner and ScrumMaster’s roles be played by the same person?

Answer: Không, vì quyền sở hữu khác nhau. Product Owner chăm sóc Product Backlog, Ưu tiên các Câu chuyện của Người dùng và Xác thực phần tăng thêm của sản phẩm đang hoạt động với các câu chuyện của người dùng được phân bổ cho Sprint.

Question: Is it that Scrum Projects need not have any Documentation?

Answer : Không. Dự án Scrum, giống như bất kỳ Dự án nào khác yêu cầu tài liệu như câu chuyện người dùng, thiết kế, trường hợp thử nghiệm, v.v.

Phần kết luận

Agile và Scrum không giống nhau. Scrum là một trong những khuôn khổ quy trình thích ứng với Agile. Scrum được khuyên dùng cho các nhóm có các thành viên trong nhóm có kinh nghiệm vì Khung làm việc đòi hỏi sự cộng tác và tự tổ chức lớn. Nếu các quy tắc Scrum không được tuân thủ nghiêm ngặt, một dự án có thể dẫn đến thất bại. Do đó, cần phải hiểu đúng về các khái niệm Scrum trong toàn bộ nhóm. Vì Sprint có thời lượng ngắn và được đóng hộp thời gian, nên không có thời gian để tìm hiểu các chi tiết cụ thể của Scrum trong công việc, ngay cả khi Scrum Master liên tục giám sát dự án.