Phương pháp phát triển Scrum. Scrum: một phương pháp quản lý dự án mang tính cách mạng

Phương pháp Scrum là gì? Làm thế nào để sử dụng nó trong quá trình phát triển và hơn thế nữa? Tại sao tính linh hoạt không phải lúc nào cũng tốt?

Việc học của tôi tiếp tục, ba lần một tuần tôi làm quen với những kiến ​​thức mới trong lĩnh vực phát triển và hiểu biết các sản phẩm kỹ thuật số từ bên trong. Đối với một nhà tiếp thị, đây là một thế giới mới. Bạn nghe về một loại Agile nào đó, bạn hiểu rằng nó có liên quan đến sự phát triển và bạn có thể dễ dàng tiếp tục cuộc trò chuyện về các thuật ngữ chung. Nhưng ngay khi nói đến chi tiết, tôi đã nổi.

Phương pháp Scrum là phương pháp phổ biến nhất trong số tất cả những thứ linh hoạt trong quá trình phát triển và hơn thế nữa. Tôi bắt đầu quan tâm đến việc tìm hiểu nó là gì và ứng dụng thực tế của công cụ này là gì. Tôi trình bày một đánh giá để bạn xem xét.

Scrum là gì

Scrum là một phương pháp phát triển linh hoạt hoặc khung quản lý linh hoạt (tức là cấu trúc) với trọng tâm là chất lượng quy trình.

Bản chất của phương pháp này là việc tạo ra một sản phẩm được chia thành các phần nhất định. Một khoảng thời gian hoặc một chặng chạy nước rút (thường là 2 tuần) được dành để hoàn thành những phần đó. Vào cuối mỗi lần chạy nước rút như vậy, cần phải chứng minh phần đã hoàn thành. Hình ảnh trên chỉ là nguyên tắc chung của các quy trình. Chúng ta hãy xem xét kỹ hơn.

Scrum hoạt động như thế nào

Xem bên dưới cách Scrum thực sự hoạt động.

Cho đến nay nó trông giống như chữ viết Trung Quốc, vì vậy tôi khuyên bạn nên xem xét từng phần riêng lẻ và tháo rời từng thành phần của cấu trúc. Tôi đánh giá cao cuốn sách “Các phương pháp linh hoạt” của Boris Volfsan; nó đã hình thành nền tảng cho tài liệu này (một số hình ảnh được lấy từ đó).

Cấu trúc Scrum

Hãy xem Scrum bao gồm những yếu tố nào.

Vai trò

• Chủ sở hữu/người quản lý sản phẩm. Đặt nhiệm vụ, xác định mức độ ưu tiên cho nhiệm vụ, tương tác với khách hàng.
• Scrum master là người chịu trách nhiệm về các quy trình trong nhóm, điều phối công việc và giám sát bầu không khí nội bộ. Lập kế hoạch chạy nước rút, tổ chức cuộc họp scrum và tham gia chứng minh kết quả vào cuối mỗi lần chạy nước rút.

Cuộc họp Scrum là cuộc họp hàng ngày để xem xét tiến độ của sprint. Bạn đã làm gì, có vấn đề gì không, bạn dự định làm gì? Không quá 15 phút cho mỗi cuộc họp. Tất cả các thành viên trong nhóm phải nói. Scrum Master giám sát thời gian và hiệu suất của mọi người.

• Nhóm – 7±2 người thực hiện các yêu cầu của chủ sở hữu sản phẩm.

Hiện vật

• Tồn đọng sản phẩm. Danh sách các yêu cầu với mức độ ưu tiên và chi phí lao động.
• Sprint backlog. Một phần của sprint backlog, tức là một số nhiệm vụ thực tế có thể phù hợp với một sprint.
• Tăng sản phẩm. Đã hoàn thành một phần sản phẩm để trình diễn. Trong các dự án kỹ thuật số, đây có thể là chức năng. Ví dụ: một mẫu đăng ký làm việc trên trang web có thể được hiển thị.

Quy trình

• Kế hoạch nước rút. Nhóm với Scrum Master lập kế hoạch làm việc cho lần chạy nước rút trong tương lai, nghĩa là lập ra một (danh sách) nhiệm vụ tồn đọng trong nước rút.
• Đánh giá nước rút. Trình diễn sự gia tăng sản phẩm sau mỗi lần chạy nước rút. Nhóm hiển thị chức năng hoạt động cho chủ sở hữu sản phẩm (và khách hàng theo yêu cầu), người này sẽ lần lượt thực hiện các thay đổi đối với các yêu cầu nếu cần thiết.
• Hồi tưởng lại. Xem lại sprint vừa qua để cải thiện quy trình. Nhóm, Scrum Master và Product Owner thảo luận về sprint vừa qua, đưa ra kết luận và suy nghĩ về những gì có thể được cải thiện.
• Cuộc họp Scrum. (xem định nghĩa ở trên trong khối “Vai trò”)
• Tăng tốc. Theo quy định, giai đoạn này kéo dài hai tuần trong đó nhóm quản lý để phát triển chức năng sẵn sàng để trình diễn.

Xin lỗi đã làm gián đoạn việc đọc. Tham gia kênh telegram của tôi. Những thông báo mới về các bài báo, quá trình phát triển sản phẩm kỹ thuật số và tăng trưởng, tất cả đều có ở đó. Đang chờ bạn! Tiếp tục đi...

Ví dụ về scrum

Hãy tưởng tượng rằng bạn cần tạo một trang web/dịch vụ để dọn dẹp ngôi nhà mùa hè của mình. Bạn có một ngôi nhà ở nông thôn, nơi khu vực này hoàn toàn hỗn loạn và bạn không thể dành những ngày cuối tuần để dọn dẹp vì bạn muốn thư giãn một chút. Vì vậy, thì đấy, dịch vụ Uberimoydvor!

Chúng tôi tin rằng dịch vụ này sẽ dựa trên trang web. Người dùng đăng ký, để lại yêu cầu và nhân viên điều hành sẽ gọi lại cho anh ta, người này sẽ làm rõ các chi tiết và đồng ý về thời gian thuận tiện cho khách hàng. Chúng tôi muốn sử dụng Scrum để phát triển trang web.

Ví dụ: chúng tôi chọn một nhiệm vụ quan trọng hoặc câu chuyện của người dùng như một phần của việc tạo trang web: “Đăng ký khách hàng/người dùng”. Và chia nó thành những phần nhỏ hơn. Chúng tôi tạo ra một sản phẩm tồn đọng.

Câu chuyện chính của người dùng được chia thành các nhiệm vụ nhỏ. Tiếp theo, cùng với nhóm, các ưu tiên được đặt ra và các nhiệm vụ được chia thành các lần chạy nước rút. Đừng quên quy tắc cơ bản: sau khi chạy nước rút, chúng ta phải có sẵn chức năng để trình diễn.

Trong thực tế, có nhiều câu chuyện của người dùng hơn (chẳng hạn như “Đăng ký người dùng”). Một dịch vụ/sản phẩm có thể bao gồm nhiều câu chuyện như vậy nên việc ưu tiên được xây dựng từ trên xuống dưới, từ trái sang phải. Ở phần trên bên trái là các câu chuyện quan trọng nhất của người dùng (Hoạt động) và các nhiệm vụ quan trọng nhất.

Để hiển thị các nhiệm vụ tồn đọng, các tờ ghi chú dán thông thường và một tấm bảng (đôi khi thậm chí là một bức tường) được sử dụng. Đây là những gì nó có thể trông như thế nào.

Rõ ràng là không thể quản lý một “khổng lồ” như vậy trong thời gian thực, do đó, để dễ dàng làm việc, toàn bộ bức tường này được chuyển sang một phần mềm/chương trình đặc biệt (Jira, Trello, Redmine và các trình theo dõi quản lý dự án khác). Ở đó bạn có thể phân công trách nhiệm cho các nhiệm vụ và người thực thi, thay đổi trạng thái nhiệm vụ, v.v.

Bức tường cũng hoạt động tốt, vì ở giai đoạn sáng tạo, cả nhóm đều đam mê và cảm thấy mình đang đóng góp cho sự nghiệp chung. Nhưng sau đó bạn cần chuyển nó sang một công cụ phù hợp.

Hãy quay lại với việc dọn dẹp sân. Vì vậy, chúng tôi đã chọn chạy nước rút với các nhiệm vụ và bắt đầu làm việc. Nhóm hoàn thành khối lượng công việc mỗi ngày và Scrum Master tổ chức các cuộc họp lập kế hoạch kéo dài 15 phút (cuộc họp Scrum), nơi anh ta cập nhật trạng thái của các nhiệm vụ chạy nước rút và tìm ra những khó khăn trong công việc nếu chúng phát sinh.

Điều rất quan trọng là Scrum Master phải giám sát bầu không khí và các mối quan hệ trong nhóm; nhiệm vụ của anh ấy là hình thành và duy trì một nhóm có khả năng tự tổ chức và năng động. Để làm được điều này, cần phải giải quyết các vấn đề và hiểu lầm giữa tất cả những người tham gia. Scrum Master là huấn luyện viên giúp cải thiện nhóm.

Sau 2 tuần chạy nước rút, Scrum Master và nhóm tiến hành minh họa chức năng. Trong ví dụ của chúng tôi, chúng tôi đã tạo được một biểu mẫu đăng ký và hiển thị nó cho chủ sở hữu sản phẩm. Anh ấy xem xét và điều chỉnh nếu cần thiết. Sau khi công việc được chấp nhận, chúng tôi chuyển sang lần chạy nước rút tiếp theo.

Hồi tưởng: Phân tích nước rút

Một vài ngày sau khi hoàn thành sprint, chủ sở hữu sản phẩm, scrum master và nhóm sẽ cùng nhau tiến hành một cuộc cải tiến (đánh giá sprint). Đây là một cuộc họp kéo dài vài giờ (tùy thuộc vào độ dài của nước rút và quy mô của nhóm) để giải quyết những khó khăn nảy sinh trong nước rút cuối cùng.

Những người tham gia chia sẻ ý kiến ​​của họ và quyết định những gì có thể được cải thiện trong các lần chạy nước rút trong tương lai. Do đó, có sự phát triển tự nhiên của các quy trình, vì với mỗi lần lặp lại mới, trải nghiệm trước đó sẽ được tính đến và phân tích.

Cách ưu tiên

Thật tốt khi chúng ta sử dụng quản lý Scrum, nhưng làm cách nào để ưu tiên một danh sách khổng lồ các câu chuyện của người dùng? Suy cho cùng, một dự án có thể bao gồm rất nhiều câu chuyện như vậy.

Đó chính là mục đích của một chủ sở hữu sản phẩm. Chính anh là người hiểu rõ nhu cầu của khán giả, theo dõi thị trường và đưa ra kết luận về những việc nên làm trong những hồ sơ tồn đọng. Nhiệm vụ chính là giải quyết nhu cầu của khách hàng và bắt đầu tốt hơn với nhu cầu quan trọng nhất.

Đồng thời, cần phải tính đến khả năng của đội. Cô ấy có thể giải quyết được bao nhiêu vấn đề trong một lần chạy nước rút? Đây là những loại nhiệm vụ gì? Lập kế hoạch tiến độ tổng thể thực hiện như thế nào? Đánh giá bên trong hồ sơ tồn đọng sẽ giúp ích.

Đánh giá câu chuyện của người dùng bên trong hồ sơ tồn đọng

Chúng tôi đã tạo một hồ sơ tồn đọng, nhưng làm thế nào để đánh giá câu chuyện của người dùng về độ phức tạp? Với mục đích này, phương pháp tiêu chuẩn được sử dụng. Đây là một đánh giá tương đối cho phép bạn hiểu được tiềm năng của nhóm và ước tính sơ bộ các nguồn lực.

Chúng tôi lấy một câu chuyện của người dùng từ hồ sơ tồn đọng làm mẫu và gán cho nó một giá trị (điểm câu chuyện). Tiếp theo, chúng tôi đánh giá các câu chuyện khác của người dùng từ quan điểm của người đã chọn.

Ví dụ: trong dịch vụ của chúng tôi có câu chuyện của người dùng “Đăng ký người dùng”. Chúng tôi lấy nó làm mẫu và đặt cho nó giá trị một điểm hoặc một điểm câu chuyện (như được gọi trong các phương pháp linh hoạt). Mỗi thành viên trong nhóm viết đánh giá của riêng mình cho những câu chuyện còn lại của người dùng trong danh sách, có tính đến nhiệm vụ đã được lấy làm mẫu và giao cho Scrum Master.

Trong ví dụ trên, “Thư viện ảnh có khách hàng hài lòng” tốn 0,5 điểm câu chuyện, tức là về độ phức tạp, nó thấp hơn 2 lần so với câu chuyện tham khảo của chúng tôi “Đăng ký người dùng”. Các thành viên trong nhóm đưa ra tất cả các xếp hạng một cách ẩn danh; bạn có thể viết và lật chúng lên nhãn dán.

Khi mọi người đã đưa ra xếp hạng của mình, kết quả sẽ mở ra. Scrum Master tạo điều kiện thảo luận giữa những người tham gia đã đưa ra những ước tính cao nhất. Trong hình trên, đây là 2 và 8. Họ đồng ý với nhau và vòng bỏ phiếu thứ hai bắt đầu.

Tất cả những người tham gia phải đi đến thống nhất ý kiến ​​và điểm số được san bằng. Do đó, chúng tôi nhận được thông tin chi tiết về tất cả các câu chuyện của người dùng dựa trên điểm số tương đối.

Tiếp theo, có tính đến mức độ ưu tiên, các nhiệm vụ được thu thập vào các lần chạy nước rút và bắt đầu công việc. Dựa trên kết quả của các lần chạy nước rút đã hoàn thành, có thể thấy rõ nhóm có thể hoàn thành gần đúng bao nhiêu điểm câu chuyện. Và trong quá trình phân tích (hồi tưởng) sau đó, có thể tìm thấy những điểm tăng trưởng.

Điều này cung cấp cho chúng tôi đồng hồ đo nội bộ hoặc đơn vị tiền tệ mà nhóm nhận được trong mỗi lần chạy nước rút. Nó có thể được sử dụng để đo lường hiệu quả của nhóm và dự đoán những lần lặp lại trong tương lai.

Có thể sử dụng Scrum không chỉ trong quá trình phát triển không?

Có và không. Trước khi tôi bắt đầu hiểu 5 chữ cái này (Scrum) nghĩa là gì, tôi đã sử dụng một số nguyên tắc trong công việc của mình. Việc lập kế hoạch, sử dụng nhiều công cụ khác nhau và xây dựng cái gọi là “nhiệm vụ chạy nước rút” của bạn đã diễn ra.

Nhưng đây vẫn không phải là Scrum. Scrum là một phương pháp và hệ thống cho phép bạn linh hoạt và không ngừng cải tiến các quy trình trong nhóm.

Nhiệm vụ nên điển hình. Dù người ta có thể nói gì đi nữa, phát triển là một hoạt động kỹ thuật, nghĩa là một nhiệm vụ có thể được đưa đến một tiêu chuẩn nhất định. Và điều này dễ thực hiện hơn nhiều so với trong lĩnh vực sáng tạo, tiếp thị hoặc quản lý.

Một số thực tiễn từ phương pháp này có thể áp dụng được trong các lĩnh vực khác. Đúng là làm việc với nhóm và phân tích công việc đã hoàn thành. Dự báo nhiệm vụ ở một giai đoạn thời gian, vâng. Quản lý tác vụ trong các chương trình tiện lợi cũng vậy, đúng vậy.

Khi nào nên sử dụng Scrum

Chủ yếu trong các dự án nhỏ và khởi nghiệp. Có thể thực hiện được ở những công ty lớn, chẳng hạn như Mail.ru, nhưng cần có quyền tự do hành động nhất định và các nhóm chức năng tách biệt với chủ sở hữu sản phẩm của riêng họ. Đừng quên rằng Scrum hướng đến sự linh hoạt và thay đổi. Các nhóm không được lớn hơn 7±2 người, nếu không sẽ không thể tổ chức liên lạc một cách hiệu quả.

Sắc thái

Nếu bạn quyết định triển khai Scrum trong các dự án của mình, hãy tính đến các sắc thái sau:

• Không tập trung vào khách hàng. Không phải tất cả khách hàng đều sẵn sàng với các tiêu chuẩn Scrum nhất định.
• Hệ thống ứng phó rủi ro không được tính đến. Nhóm có thể dành thêm thời gian để hoàn thành nhiệm vụ, nhưng nếu có sai lệch đáng kể so với kế hoạch, hệ thống sẽ dừng lại.
• Phẩm chất của nhóm và con người. Vì trọng tâm là đội tự tổ chức nên tất cả những người tham gia phải có tinh thần trách nhiệm cao và động lực phù hợp. Tạo ra một đội như vậy là một nhiệm vụ rất khó khăn.
• Đội sản xuất. Người chịu trách nhiệm về các quy trình và động lực của nhóm phải cảm nhận được tất cả những người tham gia và các mối liên hệ trong nhóm. Đây là chuyên gia hiếm có và cũng khó tìm trên thị trường.

Hãy kết thúc

Bất chấp các sắc thái và tính năng của phương pháp Scrum, tôi muốn lưu ý rằng nó vẫn là phương pháp phổ biến nhất trong số tất cả các phương pháp linh hoạt. Một số phần của nó có thể được áp dụng trong các lĩnh vực kinh doanh khác và các nguyên tắc có thể tạo thành nền tảng cho chiến lược phát triển của riêng bạn.

Scrum là một trong những cách khả thi để triển khai phương pháp phát triển linh hoạt (Agile). Không giống như mô hình thác nước của vòng đời phần mềm, đặc điểm nổi bật của Scrum là tính lặp lại.

Quá trình phát triển được chia thành các giai đoạn riêng biệt, kết quả của mỗi giai đoạn đó là một sản phẩm hoàn chỉnh. Vào cuối mỗi giai đoạn (theo thuật ngữ Scrum là một giai đoạn chạy nước rút), sản phẩm hoàn chỉnh sẽ được giao cho khách hàng. Phản hồi từ khách hàng cho phép bạn xác định các vấn đề tiềm ẩn hoặc sửa đổi một số khía cạnh của kế hoạch ban đầu. Vì vậy, Scrum cho phép bạn tuân thủ tốt nhất các nguyên tắc phát triển Agile.

Trước khi bắt đầu mô tả vòng đời của một dự án Scrum, cần nói về các vai trò chính được áp dụng trong phương pháp Scrum:

• Chủ sở hữu sản phẩm (Chủ sở hữu sản phẩm)đại diện cho lợi ích của người dùng cuối.
• Đội sản xuất giám sát việc tuân thủ các nguyên tắc phát triển Scrum, điều phối quy trình, tiến hành cuộc họp hàng ngày (Cuộc họp Scrum).
• Nhóm Scrum (Nhóm Scrum) tham gia phát triển sản phẩm. Nhóm Scrum bao gồm các lập trình viên, người thử nghiệm, nhà phân tích và các chuyên gia khác.

Vì vậy, hãy xem xét các bước phát triển chính dành riêng cho Scrum.

Bước 1: Tạo Product Backlog

Product backlog là danh sách các yêu cầu đối với sản phẩm đang được phát triển, được sắp xếp theo mức độ quan trọng. Các mục trong danh sách này được gọi là Câu chuyện của người dùng. Mỗi câu chuyện có một ID duy nhất. Dưới đây là ví dụ về câu chuyện của người dùng từ sản phẩm tồn đọng được sử dụng khi làm việc trên Trình quản lý nhân viên XB:

Mô tả của mỗi câu chuyện phải bao gồm một tập hợp các trường bắt buộc cần thiết để tiếp tục thực hiện dự án:

• Tầm quan trọng. Mức độ quan trọng của nhiệm vụ theo ý kiến ​​của chủ sở hữu sản phẩm. Được mô tả bằng một số tùy ý.
• Ước tính ban đầu. Đánh giá sơ bộ về phạm vi công việc. Đo bằng điểm câu chuyện.
• Cách trình diễn. Mô tả cách thể hiện một nhiệm vụ đã hoàn thành.

Ngoài các trường bắt buộc này, bạn có thể thêm các trường bổ sung nếu cần:

• Danh mục (Bản nhạc) dùng để cho phép chủ sở hữu sản phẩm chọn tất cả các mục thuộc một danh mục nhất định và gán cho chúng mức độ ưu tiên thấp hoặc cao. Một ví dụ về danh mục như vậy sẽ là “Bảng điều khiển”.
• Các thành phần bao gồm một danh sách các thành phần sản phẩm sẽ được thay đổi trong khi thực hiện câu chuyện. Các thành phần này có thể là các mô-đun ứng dụng, chẳng hạn như xác thực hoặc tìm kiếm.
• Người yêu cầu- một khách hàng quan tâm đến việc triển khai một chức năng nhất định. Trường này là cần thiết nếu bạn cần thông báo cho khách hàng về tình trạng hiện tại.
• ID trong hệ thống theo dõi lỗi (ID theo dõi lỗi) chứa các liên kết đến các lỗi được phát hiện liên quan đến một câu chuyện có ID cụ thể.

Sau khi tổng hợp xong hồ sơ tồn đọng của dự án, bạn có thể tiến hành bước tiếp theo - lập kế hoạch chạy nước rút.

Bước 2: Lập kế hoạch Sprint và tạo Sprint Backlog

Ở giai đoạn lập kế hoạch, thời gian chạy nước rút được xác định. Một giai đoạn chạy nước rút ngắn cho phép bạn phát hành các phiên bản hoạt động của sản phẩm thường xuyên hơn, do đó nhận được phản hồi từ khách hàng thường xuyên hơn và xác định kịp thời các lỗi có thể xảy ra. Mặt khác, chạy nước rút dài cho phép bạn dành nhiều thời gian hơn để giải quyết vấn đề. Thời lượng chạy nước rút tối ưu được chọn làm điểm giao thoa giữa hai quyết định này và thường là khoảng 2 tuần. Ở giai đoạn này, sự tương tác giữa chủ sở hữu sản phẩm và nhóm Scrum là rất quan trọng. Chủ sản phẩm xác định mức độ ưu tiên của một nhiệm vụ cụ thể và nhiệm vụ của nhóm Scrum là xác định nỗ lực cần thiết.

Trong quá trình lập kế hoạch chạy nước rút, nhóm chọn các câu chuyện của người dùng có mức độ ưu tiên cao nhất từ ​​sản phẩm tồn đọng và quyết định cách giải quyết các nhiệm vụ được giao. Các story được chọn để triển khai trong sprint này là: Sprint backlog. Số lượng story có trong sprint backlog phụ thuộc vào thời lượng của chúng theo điểm story được chỉ định cho mỗi story ở giai đoạn đánh giá sơ bộ. Con số này được chọn sao cho mỗi story được triển khai thành công vào cuối sprint.

Bước 3. Chạy nước rút. Cuộc họp Scrum

Khi các câu chuyện của người dùng liên quan đến sprint đã được xác định, quá trình sẽ bắt đầu.

Thật thuận tiện khi sử dụng thẻ chỉ mục để hình dung quá trình phát triển. Chúng có thể ở dạng những tấm thẻ lớn có tên của một câu chuyện cụ thể và những tờ ghi chú nhỏ mô tả các nhiệm vụ riêng lẻ cần thiết để thực hiện câu chuyện. Sau khi bạn bắt đầu thực hiện một nhiệm vụ cụ thể, nhãn dán của nhiệm vụ đó sẽ di chuyển từ trường “Đã lên kế hoạch” sang khu vực “Đang tiến hành”. Sau khi hoàn thành công việc của nhiệm vụ, nhãn dán sẽ chuyển sang trường "Thử nghiệm" và sau đó, nếu thử nghiệm thành công, sẽ chuyển sang trường "Xong". Bằng cách xếp hạng các câu chuyện theo tầm quan trọng của chúng, bạn có thể biết được trạng thái hiện tại của dự án:

Phần mềm được thiết kế cho loại nhiệm vụ này cũng có thể được sử dụng. Một ví dụ về phần mềm như vậy là Atlassian JIRA.

Một đặc điểm khác biệt quan trọng của Scrum là cuộc họp hàng ngày (cuộc họp Scrum), mục đích là cung cấp cho nhóm thông tin đầy đủ và đáng tin cậy về giai đoạn của quá trình phát triển. Trong cuộc họp, mỗi thành viên của nhóm Scrum sẽ báo cáo nhiệm vụ nào họ đã hoàn thành, nhiệm vụ nào sẽ được thực hiện và những khó khăn họ gặp phải khi làm việc.

Kết quả của mỗi cuộc gặp gỡ cũng sơ đồ đốt cháy. Trục X hiển thị số ngày làm việc trong sprint và trục Y hiển thị tổng số story point cho sprint này. Sau khi hoàn thành một nhiệm vụ yêu cầu một số điểm câu chuyện nhất định để giải quyết nó, bạn có thể đánh dấu trên sơ đồ điểm mà dự án hiện đang được đặt. Một ví dụ về sơ đồ như vậy được xây dựng trong JIRA được đưa ra dưới đây:

Nó cho phép bạn đánh giá tiến độ làm việc của nhóm và quyết định nên tăng hay giảm số lượng story trong sprint tiếp theo. Các cuộc họp hàng ngày giúp tăng tính linh hoạt của quá trình phát triển và cung cấp cái nhìn sâu sắc về những điều chỉnh cần thiết cần thực hiện trong quá trình giai đoạn thiết kế của các lần chạy nước rút tiếp theo.

Bước 4. Thử nghiệm và trình diễn sản phẩm

Vì lý tưởng nhất là mỗi lần chạy nước rút đều cung cấp một sản phẩm sẵn sàng cho sản xuất nên thử nghiệm là một phần quan trọng của Scrum. Có nhiều cách khác nhau để giảm thiểu chi phí ở giai đoạn này: từ việc giảm số lượng câu chuyện trong giai đoạn chạy nước rút và kết quả là giảm số lượng lỗi cho đến việc đưa người thử nghiệm vào nhóm Scrum.

Phần cuối cùng của mỗi lần chạy nước rút là phần minh họa cho thành phẩm. Nhóm Scrum viết một bài đánh giá trong đó mô tả các mục tiêu của sprint, các nhiệm vụ được đặt ra và cách giải quyết chúng. Chủ sở hữu sản phẩm, khách hàng và người dùng, dựa trên các đánh giá và trình diễn, quyết định những gì cần thay đổi trong quá trình phát triển tiếp theo.

Bước 5. Hồi tưởng lại. Lập kế hoạch cho lần chạy nước rút tiếp theo

Dựa trên những phản hồi nhận được về sản phẩm sau khi trình diễn, một cuộc hồi tưởng sẽ được tiến hành. Mục tiêu chính của nó là xác định cách cải thiện quy trình phát triển trong lần chạy nước rút tiếp theo để tránh các vấn đề và làm việc hiệu quả hơn. Khi các cách để cải thiện chất lượng công việc đã được xác định, nhóm có thể bắt đầu lập kế hoạch cho lần chạy nước rút tiếp theo.

Phần kết luận

Điểm nổi bật của Scrum là tính linh hoạt và tập trung vào sự phát triển và thay đổi liên tục. Điều này phần lớn đạt được thông qua giao tiếp và tương tác liên tục. Trong giai đoạn Lập kế hoạch Sprint, Chủ sản phẩm liên lạc với Nhóm Scrum để xác định những nhiệm vụ mà câu chuyện của người dùng có thể được chia thành và cách chúng có thể được triển khai. Trong các cuộc họp hàng ngày, các thành viên nhóm Scrum thảo luận về việc thực hiện từng nhiệm vụ riêng lẻ và xác định các cách khả thi để giải quyết các vấn đề phát sinh. Vào cuối giai đoạn chạy nước rút, sản phẩm hoàn chỉnh sẽ được trình bày cho khách hàng, họ có thể đánh giá chức năng hiện tại và lưu ý những gì họ muốn thay đổi. Tính năng đặc biệt này của Scrum có thể hữu ích nếu theo thời gian, tầm nhìn của khách hàng về hình thức sản phẩm sẽ thay đổi. Cuối cùng, tất cả thông tin thu được từ các giai đoạn này đều được tính đến trong tất cả các lần chạy nước rút tiếp theo, giúp tối ưu hóa quá trình phát triển theo cách tốt nhất có thể.

Hai tab sau thay đổi nội dung bên dưới.

Scrum là gì? Bản chất của kỹ thuật

Những người tham gia quản lý dự án, hay đơn giản là quản lý, đều biết rõ việc tổ chức phối hợp nhóm tốt khó khăn như thế nào. Bởi vì thiếu mạch lạc, kế hoạch liên tục bị vi phạm, tiến độ chậm tiến độ, ngân sách dự án tăng cao, tiền bạc và thời gian trôi qua kẽ tay, nhiệm vụ của các bộ phận khác nhau bị trùng lặp, mọi người tranh cãi và không giúp đỡ lẫn nhau, mặc dù có vẻ như nỗ lực của họ đều nhằm đạt được cùng một mục tiêu. Ngoài ra, khách hàng thường không hài lòng với phiên bản cuối cùng của sản phẩm được tạo ra.

Phương pháp Scrum do Jeff Sutherland và Ken Schwaber phát triển, được thiết kế để giải quyết tất cả những vấn đề này. Scrum— Điều này trái ngược với cách tiếp cận từng bước cổ điển được thực hiện khi thực hiện dự án. Phương pháp Scrum đã được nhiều công ty áp dụng, cả trong các ngành công nghệ nơi nó xuất phát, cũng như từ các ngành truyền thống và thậm chí phi lợi nhuận. Cách tiếp cận cơ bản của phương pháp Scrum có thể được áp dụng cho nhiều hoạt động đòi hỏi tinh thần đồng đội.

Đặc điểm quan trọng của Scrum là tính linh hoạt và tập trung vào khách hàng, vì nó giả định sự tham gia trực tiếp của khách hàng (khách hàng) vào quá trình làm việc.

Scrum không yêu cầu triển khai bất kì những công cụ đắt tiền. Phương pháp Scrum có thể được mô tả ngắn gọn như sau:

1. Đầu tiên bạn cần chọn« Chủ sở hữu sản phẩm» — một người có tầm nhìn về những gì bạn sẽ tạo ra hoặc đạt được.

2. Sau đó bạn cần thu thập"Đội" , trong đó sẽ bao gồm những người trực tiếp thực hiện công việc. Họ phải có kỹ năng và kiến ​​thức để giúp hiện thực hóa tầm nhìn của chủ sở hữu sản phẩm.

3. Bạn cần chọn một “Scrum Master” - ai đó sẽ theo dõi tiến độ của dự án, tạo điều kiện cho các cuộc họp ngắn và giúp nhóm loại bỏ những trở ngại để đạt được mục tiêu.

4. Khi bắt đầu công việc, bạn cần tạo danh sách đầy đủ nhất tất cả các yêu cầu đối với sản phẩm hoặc mục tiêu. Các mục trong danh sách này nên được ưu tiên. Danh sách được gọi là"Tồn đọng sản phẩm" . Nó có thể phát triển và thay đổi trong suốt vòng đời của dự án.

5. Các thành viên trong nhóm phải đánh giá từng mục bằng hệ thống tính điểm của riêng họ về độ khó và chi phí cần thiết để hoàn thành mục đó.

6. Sau đó những người tham giaĐội sản xuất và chủ sở hữu sản phẩm phải tiến hành việc đầu tiên cuộc họp scrum , nơi họ sẽ lập kế hoạch chạy nước rút— thời gian nhất định để hoàn thành một phần công việc. Thời gian chạy nước rút không quá một tháng. Đối với mỗi lần chạy nước rút, đội kiếm được một số điểm nhất định. Nhóm phải không ngừng phấn đấu để vượt quá số điểm tích lũy cho lần chạy nước rút trước trong lần chạy nước rút mới, tức là đạt được mục tiêu của mình— luôn vượt quá kết quả của chính bạn— « tăng động lực năng suất» .

7. Để tất cả người tham gia nhận thức được tình trạng của sự việc, bạn cần tạo bảng scrum với ba cột:« Việc cần làm, hoặc tồn đọng" ; "Trong tiến trình"; " Làm ra " . Những người tham gia dán các nhãn dán có nhiệm vụ lên bảng, các nhãn dán này sẽ được di chuyển từng cái một khỏi cột khi họ làm việc."Tồn đọng" vào cột "đang tiến hành" rồi vào cột "hoàn thành".

8. Tiến hành hàng ngày cuộc họp scrum . Theo Jeff Sutherland« đây là nhịp đập của toàn bộ quá trình Scrum» . Bản chất của nó rất đơn giản— Mỗi ngày, khi đang di chuyển, mười lăm phút để mọi người trả lời ba câu hỏi:« » , « » , « » .

9. Khi kết thúc sprint, nhóm sẽ đánh giá nó— tổ chức một cuộc họp trong đó những người tham gia nói về những gì đã được thực hiện trong sprint.

10. Sau khi trình bày kết quả của sprint, những người tham gia tổ chức một cuộc họp nhìn lại quá trình, nơi họ thảo luận về những gì nhóm đã làm tốt, những gì có thể làm tốt hơn và những gì có thể cải thiện ngay bây giờ.

Nhược điểm của phương pháp quản lý dự án truyền thống

Là tác giả của cuốn sách, Jeff Sutherland, lưu ý, cách tiếp cận truyền thống để thực hiện dự án theo hình thức mô hình thác nước, bao gồm tiến độ từng bước hướng tới mục tiêu, có nhiều nhược điểm. Toàn bộ quá trình diễn ra rất chậm, thường xuyên nảy sinh những khó khăn khó lường, hơn nữa, thường xuyên xảy ra trường hợp nhà thầu tạo ra sản phẩm không làm khách hàng hài lòng chút nào.

Mô hình thác nước liên quan đến việc sử dụng biểu đồ Gantt— lịch trình cho biết các giai đoạn công việc và thời gian hoàn thành chúng. Tiến độ của dự án được vạch ra chi tiết và từng bước của công việc đều được phản ánh. Giả định rằng mỗi giai đoạn của dự án lần lượt chuyển sang giai đoạn tiếp theo,— Đây là nguyên tắc xếp tầng.

Tại sao? Như Jeff Sutherland lưu ý, Henry Gantt đã phát minh ra những biểu đồ như vậy vào năm 1910. Chúng trở nên phổ biến trong Thế chiến thứ nhất. Tuy nhiên,« Ai nghiên cứu lịch sử cuộc chiến này đều biết rằng cả việc đào tạo nhân lực lẫn hệ thống tổ chức đều không phải là điểm mạnh của nó. Tôi không thể hiểu tại sao khái niệm Thế chiến thứ nhấttrở thành thực tếcông cụ thiết kế phân tích và được sử dụng ngay cả trong thế kỷ 21. Chúng ta đã từ bỏ nguyên tắc chiến tranh chiến hào, nhưng bằng cách nào đó "rãnh" của nó ý tưởng tổ chức vẫn còn phổ biến cho đến ngày nay» .

Trong điều kiện hiện đại, mô hình này không phù hợp và giống với mô hình của Bộ Chính trị Ban Chấp hành Trung ương CPSU."tin" báo cáo rằng nó nhận được vào đêm trước khi Liên Xô sụp đổ và không liên quan gì nhiều đến tình hình thực tế.

Triết lý Scrum

Phương pháp Scrum phản ánh niềm đam mê của tác giả đối với võ thuật Nhật Bản. Theo ông, ở Nhật Bản« Scrum không được coi là mốt nhất thời. Người Nhật coi Scrum là một cách tiếp cận để giải quyết vấn đề, một cách hành động, một cách tồn tại. — nói chung, như một lối sống. Khi dạy kỹ thuật này cho mọi người, tôi thường nói về kinh nghiệm nhiều năm của mình trong môn võ Aikido Nhật Bản. » .

Điểm chung của Aikido và Scrum là chúng chỉ có thể thành thạo trong quá trình làm việc, khi« cơ thể, tâm trí và tinh thần của bạn hòa làm một thông qua việc luyện tập không ngừng và theo đuổi sự xuất sắc. Bằng cách luyện tập Aikido, chúng ta hiểu được khái niệm shuhari (Shu Ha Ri) — nó vừa là khái niệm võ thuật vừa là thước đo mức độ kỹ năng » .

Bản chất của làm việc nhóm trong Scrum

Scrum - Đây trước hết là tinh thần đồng đội. Tác giả xác định ba đặc điểm của các đội tốt nhất:

sự tìm kiếm không ngừng nghỉ để đạt được sự xuất sắc;

• quyền tự trị - khả năng tự tổ chức;
• đa chức năng. Sự hiện diện của các chuyên gia khác nhau và văn hóa tương tác và hỗ trợ lẫn nhau.

Đội nên có quy mô như thế nào? Jeff Sutherland đề xuất các nhóm nhỏ— khoảng bảy người. Ông trích dẫn dữ liệu rằng nếu một nhóm bao gồm hơn chín người thì tốc độ làm việc của nhóm đó sẽ giảm xuống.

Ngoài ra, tác giả còn nhớ lại “định luật Brooks”:

« Nếu dự án không đúng thời hạn, việc bổ sung thêm lao động sẽ làm trì hoãn nó hơn nữa. » .

Đội trưởng- đây là Scrum Master . Nhiệm vụ của anh ấy— tổ chức các cuộc họp ngắn gọn và cởi mở, giúp nhóm vượt qua những trở ngại cản trở công việc, dẫn dắt nhóm đi theo con đường cải tiến liên tục« và thường xuyên tìm kiếm câu trả lời cho câu hỏi« Làm thế nào chúng ta có thể làm tốt hơn những gì chúng ta đã làm tốt?» .

Không đa nhiệm

Tác giả cảnh báo chống lại đa nhiệm— thực tế là không có, bộ não của chúng ta không thể thực hiện hai hành động cùng một lúc, nó chỉ chuyển đổi giữa các nhiệm vụ và tổng thời gian để hoàn thành từng nhiệm vụ sẽ tăng lên so với khi chúng ta thực hiện chúng luân phiên. Phương pháp Scrum giả định rằng bạn cần thực hiện từng nhiệm vụ một chứ không phải« quản lý năm dự án cùng một lúc» .

« Sử dụng phương pháp truyền thống là cố gắng làm mọi việc cùng một lúc, nhóm sẽ hoàn thành ba dự án của mình trước cuối tháng 7. Nếu nhóm tiếp cận nó bằng một chiến lược linh hoạt như Scrum và làm việc trên từng dự án cùng một lúc, giảm thiểu thời gian và công sức liên quan đến việc chuyển đổi ngữ cảnh, thì việc này có thể được thực hiện vào đầu tháng 5. » .

Bản chất của công việc là dòng chảy

Scrum giúp bạn đạt được"chảy" - trạng thái tập trung cao độ nhất khi bạn làm những gì bạn cần làm mà không cần nỗ lực nhiều, không ép buộc hay ép buộc bản thân. Tác giả tin rằng điều chính để làm việc thành công— đạt được và quản lý trạng thái này.« Trong công việc của bạn, bạn cần phải đạt được điều chính— kiểm soát dòng chảy dễ dàng. Trong võ thuật hoặc thiền định, chúng ta đạt được cảm giác thống nhất trong chuyển động mà không cần nỗ lực,— đó là năng lượng chảy qua chúng ta không bị cản trở. Khi bạn xem những vũ công hoặc ca sĩ tuyệt vời, bạn sẽ cảm nhận được họ phục tùng nguồn năng lượng này như thế nào. Chúng ta phải cố gắng đạt được trạng thái như vậy trong công việc của mình.» .

Làm thế nào để đạt được nó? Đằng sau trạng thái dòng chảy là kỷ luật nội bộ,

« Không nên lãng phí chuyển động » .

Scrum và hạnh phúc

Mọi người muốn được hạnh phúc. Nhưng Jeff Sutherland chắc chắn rằng hạnh phúc— Đây không phải là thảm thực vật không hoạt động mà là một cuộc sống tươi sáng, phong phú và năng động. Scrum góp phần mang lại cuộc sống hạnh phúc vì nó giúp bạn làm việc và hành động hiệu quả.

Vào cuối mỗi lần chạy nước rút, những người tham gia tổ chức một cuộc họp hồi tưởng, nơi họ nói về công việc của mình và chuyển các nhiệm vụ đã xem xét vào một cột" Làm ra " , sau đó thảo luận về những gì tốt và những gì có thể cải thiện. Họ tìm ra trở ngại chính và tìm ra cách khắc phục nó trong lần chạy nước rút tiếp theo. Đây là giải pháp cho vấn đề cải tiến liên tục.

Các thành phần của Scrum

Chạy nước rút

Như đã lưu ý ở trên, khi bắt đầu chạy nước rút và để đảm bảo tính mở và khả năng hiển thị, bạn cần tạo một bảng đặc biệt và chia nó thành ba cột:“Tồn đọng”; "Trong tiến trình"; " Làm ra " . Trước mỗi lần chạy nước rút, các thành viên trong nhóm đứng vào một cột"Tồn đọng" những ghi chú về những nhiệm vụ mà họ nghĩ rằng họ có thể hoàn thành trong thời gian chạy nước rút. Trong quá trình chạy nước rút, bất kỳ thành viên nào trong nhóm sau khi thực hiện một nhiệm vụ sẽ dán lại nhãn dán từ phần đó."Tồn đọng" trong cột "Đang xử lý" . Sau khi hoàn thành nhiệm vụ- trong cột “Hoàn thành” . Bằng cách này, mọi người có thể thấy những gì những người tham gia khác hiện đang làm.

Tuy nhiên, có một lưu ý quan trọng— « không có gì được chuyển vào cột" Làm ra " cho đến khi phần này của dự án được khách hàng kiểm tra» .

« Một khía cạnh quan trọng khác của sprint: sau khi nhóm phê duyệt danh sách yêu cầu, các nhiệm vụ trong danh sách này sẽ được thực hiện. „ bị chặn“ . Không ai có quyền thay đổi hoặc bổ sung » . Tác giả khuyến nghị điều này bởi vì rằng bất kỳ sự can thiệp nào cũng sẽ làm chậm lại công việc của nhóm.

Cuộc họp hàng ngày

Vấn đề là họ phải đứng, hàng ngày, vào cùng một thời điểm, thời lượng không quá mười lăm phút và người tham gia phải hỏi ba câu hỏi giống nhau:« Hôm qua bạn đã làm gì để giúp nhóm hoàn thành sprint?» , « Hôm nay bạn sẽ làm gì để giúp nhóm hoàn thành sprint?» , « Những trở ngại nào đang cản đường đội?» .

Làm đến cùng

Trong Scrum, điều quan trọng là học cách cảm nhận nhịp điệu của nhóm. Trường hợp xấu nhất— khi ở cuối nước rút thứ gì đó vẫn còn một nửa hoàn thành. Tốt hơn hết là đừng bắt đầu công việc kinh doanh này.

« Nguồn lực, công sức, thời gian, tiền bạc đã bỏ ra nhưng vẫn chưa nhận được một sản phẩm hoạt động đầy đủ » .

Lập kế hoạch trong Scrum

Quá trình lập kế hoạch trong Scrum diễn ra như thế nào? Trước tiên, bạn cần lập danh sách tất cả những điều ảnh hưởng đến mục tiêu của mình. Sau đó, hãy ưu tiên chúng. Nếu không đáp ứng được giới hạn về thời gian và tài chính thì bạn có thể dễ dàng loại bỏ những mục cuối cùng trong danh sách hơn.

Phải làm gì tiếp theo? Mỗi mục trong danh sách cần được đánh giá xem sẽ cần bao nhiêu công sức, thời gian và các nguồn lực khác để hoàn thành. Làm thế nào để thực hiện đánh giá? Tác giả đề xuất thang đo đánh giá tương đối. Ví dụ: bạn có thể so sánh các nhiệm vụ"ở chó". Vấn đề này - chó dachshund hay chó tha mồi? Hoặc có thể là Great Dane?

Nhưng trong mọi trường hợp, việc đặt các giá trị số sẽ thuận tiện hơn. Ví dụ,« Dachshund— đơn vị; Đại Đan Mạch— mười ba; chú chó labrador trở thành số năm và chú chó bulldog — ba» .

Tác giả cũng gợi ý sử dụng một kỹ thuật lập kế hoạch poker thú vị. Bản chất của nó— Mỗi người tham gia quá trình lập kế hoạch được phát một bộ bài có số Fibonacci— 1, 2, 3, 5, 8, 13, v.v. Mỗi mục trong danh sách, một đơn vị công việc phải được đánh giá, được bày ra trên bàn.

Yêu cầu là những câu chuyện

Để xây dựng thành công và rõ ràng danh sách các yêu cầu về sản phẩm cũng như tạo ra các hồ sơ tồn đọng cho mọi người, Scrum sử dụng một cách tiếp cận đặc biệt. Thay vì một danh sách nhiệm vụ đơn giản, các câu chuyện của người dùng được biên soạn— những câu chuyện ngắn chứa đựng những mong muốn của người dùng đối với sản phẩm cuối cùng.

« Hãy tưởng tượng bạn đang trang điểm „ Yêu cầu của người dùng Amazon.com “ . Phiên bản dùng thử trông như thế này: „ Với tư cách là người tiêu dùng, tôi muốn có hiệu sách lớn nhất thế giới nơi tôi có thể mua bất kỳ cuốn sách nào vào bất kỳ lúc nào “ .Mô tả này rất phù hợp với tính cách của Amazon, nhưng câu chuyện quá mơ hồ nên không hữu ích. thứ gì đóLÀM. Chúng ta cần chia nhỏ lịch sử của mình. Làm cho nó thực sự rất cụ thể và chức năng. Dưới đây là một số câu chuyện mẫu của người dùng mà bạn có thể viết khi nghĩ đến cuốn sách. cửa hàng trực tuyến :Là một người tiêu dùng, tôi thích tìm kiếm sách theo thể loại để nhanh chóng tìm thấy những cuốn tôi thích đọc. Là một người tiêu dùng, khi tôi chọn sách để mua, tôi muốn bỏ từng cuốn vào giỏ hàng của mình cùng một lúc. Là người quản lý sản phẩm , Tôi muốn có thể theo dõi việc mua hàng của khách hàng, để biết những cuốn sách nào có thể được cung cấp cho họ. Dưới đây là những yêu cầu của người dùng được thực hiện một cách chuyên nghiệp, bản chất mà nhóm nên tính đến » .

Câu chuyện của người dùng phải hoàn chỉnh, độc lập với nhiều trường hợp khác nhau và có thể triển khai được trong thực tế. Những tiêu chí này cho thấy sự sẵn sàng của câu chuyện. Điều quan trọng nữa là câu chuyện có thể được đánh giá về tính khả thi của nó.

Cách lập kế hoạch chạy nước rút

Trong Scrum, quy trình lập kế hoạch diễn ra vào đầu mỗi sprint mới và được gọi là— « kế hoạch nước rút» . « Mọi người cùng nhau xem danh sách các câu chuyện của người dùng đã được xếp hàng để thực hiện; tìm hiểu xem mỗi thành viên trong nhóm có thể đảm nhận bao nhiêu nhiệm vụ; xem xét cẩn thận liệu họ có thể hoàn thành các nhiệm vụ đã chọn ở trạng thái sẵn sàng hoàn toàn trong lần chạy nước rút này hay không; liệu họ có thể chứng minh các đơn vị công việc đã hoàn thành cho khách hàng và cho khách hàng thấy các chức năng đã hoàn thiện của sản phẩm hay không; Liệu họ có thể tự nhủ khi kết thúc chặng nước rút rằng họ đã quản lý được mọi thứ không? » .

Sau đó cả nhóm đồng thanh nói:" Phía trước! "— và đi làm

Nhưng công việc là gì? Thói quen, nghĩa vụ? Từ quan điểm của Scrum, công việc— Đây là lịch sử. Nó có nghĩa là gì? Điều này có nghĩa là bạn nên giới thiệu ai đó cần công việc của bạn; rồi nó là gì và cuối cùng là tại sao mọi người cần nó.

Các đội cần hiểu rõ động lực của mình— cô ấy có thể hoàn thành bao nhiêu công việc trong một lần chạy nước rút. Điều này sẽ giúp cô ấy làm việc thông minh hơn và loại bỏ mọi trở ngại cản đường cô ấy.

« Động lực x thời gian = kết quả. Biết bạn đang đi nhanh như thế nào sẽ giúp bạn biết khi nào bạn sẽ về đích » .

Cởi mở trong mọi việc

Scrum đảm bảo tính minh bạch của mọi hành động và quy trình.

Điều này được thể hiện trong một bảng ba cột mà tất cả các thành viên trong nhóm đều có quyền truy cập.

« bí mật— TÔI. Không có gì có thể được giữ bí mật. Mọi người nên biết mọi thứ, kể cả dữ liệu tài chính. Sự xáo trộn chỉ cần thiết cho những người tìm kiếm lợi ích riêng của họ. » .

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

Scrum đảm nhận ba vai trò: Nhóm Scrum - người thực hiện các dự án cụ thể;Đội sản xuất - đây là người theo dõi tiến độ của dự án và giúp nhóm giải quyết vấn đề, còn chủ sở hữu sản phẩm— người giải quyết các vấn đề về khái niệm sản phẩm và tổng hợp các hồ sơ tồn đọng.

« Đội sản xuấtvà nhóm chịu trách nhiệm về tốc độ làm việc cũng như tốc độ hoàn thành dự án. Chủ sản phẩm chịu trách nhiệm đảm bảo rằng hoạt động làm việc nhóm hiệu quả sẽ mang lại kết quả có lợi. » . Chủ sản phẩm cần có kiến ​​thức sâu sắc về thị trường và phải có quyền đưa ra quyết định.

Đây có thể là trách nhiệm quá lớn đối với một người, vì vậy các dự án lớn có thể có sự tham gia của một nhóm chủ sở hữu sản phẩm.

Giảm thiểu rủi ro trong Scrum

Vì Scrum cung cấp khả năng phân phối dự án theo từng bước nên điều này giúp giảm thiểu rủi ro. Điều này giúp nhanh chóng giới thiệu sản phẩm cho khách hàng và nhận được phản hồi từ họ.

« Phương pháp Scrum rất hữu ích cho doanh nghiệp vì nó trả lời nhanh chóng câu hỏi: chúng ta có thể kiếm tiền nếu làm cái này hay cái kia không?

Bạn không cần phải chi nhiều tiền trước khi nhận ra một cái gì đó không hoạt động.

Hướng dẫn này sẽ giúp các nhà phát triển và người kiểm tra phần mềm hiểu và bắt đầu với phương pháp Agile SCRUM.

Tìm hiểu các thuật ngữ cơ bản nhưng quan trọng được sử dụng trong quy trình Agile Scrum cùng với ví dụ thực tế về quy trình hoàn chỉnh.

SCRUM là một quy trình linh hoạt, là sự kết hợp của các mô hình lặp và tăng dần.

Một trong những nhược điểm chính của mô hình thác nước truyền thống là cho đến khi hoàn thành giai đoạn đầu tiên, ứng dụng không chuyển sang giai đoạn khác. Nếu xảy ra một số thay đổi ở giai đoạn sau của chu kỳ thì sẽ rất khó thực hiện những thay đổi này vì nó sẽ đòi hỏi phải sửa đổi các giai đoạn trước đó và thực hiện lại các thay đổi.

Một số tính năng chính của SCRUM là:

• Đội ngũ có tổ chức và có mục đích
• Không có yêu cầu về tài liệu, chỉ cần có văn bản chính xác đi vào vấn đề là đủ.
• Nhóm chức năng hoạt động như một đơn vị duy nhất.
• Kết nối chặt chẽ với người dùng, giúp hiểu rõ các tính năng.
• Có một trục thời gian chính xác tối đa là 1 tháng.
• Thay vì làm mọi thứ cùng một lúc, Scrum thực hiện từng chút một trong mỗi việc trong một khoảng thời gian nhất định.
• Trước khi thực hiện bất kỳ hành động nào, các đặc điểm và tính sẵn có của nguồn lực đều được xem xét.

Để hiểu rõ phương pháp này, điều quan trọng là phải hiểu các thuật ngữ chính của SCRUM.

Các thuật ngữ SCRUM quan trọng:

1. Nhóm Scrum

Nhóm Scrum là nhóm gồm 7 +/- 2 thành viên. Các thành viên trong nhóm là sự kết hợp của các nhà phát triển, người thử nghiệm, người cơ sở dữ liệu, người vận hành hỗ trợ, v.v., cũng như chủ sở hữu sản phẩm và người quản lý scrum. Tất cả những người này làm việc chặt chẽ với nhau trong một khoảng thời gian đệ quy nhất định để phát triển và thực hiện các chức năng được chỉ định.

2. Chạy nước rút

Chạy nước rút là một khoảng thời gian tiêu chuẩn trong đó công việc phải được hoàn thành và sẵn sàng để xem xét hoặc phát hành sản phẩm. Thông thường khoảng thời gian này mất từ ​​​​hai tuần đến một tháng. Khi chúng tôi nói rằng chúng tôi thực hiện 1 lần chạy nước rút trong một tháng, điều đó có nghĩa là chúng tôi làm việc trong một tháng cho các nhiệm vụ và chuẩn bị chúng để xem xét vào cuối tháng đó.

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

Chủ sản phẩm là người bán hàng chính hoặc người dùng chính của ứng dụng đang được phát triển.

Chủ sản phẩm là người đại diện cho phía khách hàng. Anh ấy/cô ấy có quyền quyết định cuối cùng và phải luôn sẵn sàng phục vụ nhóm. Anh ấy/cô ấy phải có mặt khi ai đó cần giải thích điều gì đó. Điều quan trọng là chủ sở hữu sản phẩm phải hiểu và không đặt ra các yêu cầu mới vào giữa giai đoạn chạy nước rút hoặc khi nó đã bắt đầu.

4. Bậc thầy Scrum

Scrum Master là người điều phối của nhóm Scrum. Anh ấy/cô ấy đảm bảo rằng nhóm scrum làm việc hiệu quả và tiến bộ. Trong trường hợp có bất kỳ sự can thiệp nào, Scrum Master sẽ tìm và giải quyết cho nhóm.

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

Câu chuyện của người dùng là những yêu cầu hoặc chức năng phải được hoàn thành. Trong scrum chúng ta không có những tài liệu yêu cầu lớn này, ngược lại, các yêu cầu được nêu trong một đoạn văn, thường ở định dạng sau:

Làm sao<тип пользователя>

Tôi muốn<доступная цель>

để đạt được thành tích<результат/причина>

Ví dụ:

Với tư cách là quản trị viên, tôi muốn có thể khóa mật khẩu để hạn chế truy cập trái phép trong trường hợp người dùng nhập sai mật khẩu 3 lần liên tiếp.

Có một số đặc điểm của câu chuyện của người dùng phải được tuân thủ. Câu chuyện của người dùng phải ngắn gọn, thực tế, có thể đánh giá, đầy đủ, có thể thương lượng và có thể kiểm tra được.

Mỗi câu chuyện của người dùng có một tiêu chí chấp nhận mà nhóm phải xác định và hiểu rõ ràng. Tiêu chí chấp nhận mô tả chi tiết câu chuyện của người dùng và cung cấp các tài liệu được hỗ trợ. Điều này cho phép câu chuyện của người dùng được chi tiết. Bất kỳ thành viên nào trong nhóm đều có thể viết ra tiêu chí chấp nhận. Nhóm xác minh căn cứ vào các trường hợp/điều kiện thử nghiệm của họ dựa trên các tiêu chí này.

6. “Sử thi”

Sử thi là những câu chuyện mơ hồ của người dùng. Hoặc, chúng ta có thể nói rằng đây là những câu chuyện của người dùng chưa được xác định và được lưu trữ cho các lần chạy nước rút trong tương lai. Chỉ cần cố gắng kết nối điều này với cuộc sống, hãy tưởng tượng rằng bạn đang đi nghỉ. Vì bạn sẽ rời đi vào tuần tới nên bạn đã lên kế hoạch cho mọi thứ: đặt phòng khách sạn, tham quan, đóng gói hành lý du lịch, v.v. Nhưng kỳ nghỉ năm sau của bạn thì sao? Bạn chỉ có ý tưởng mơ hồ rằng mình có thể đến địa điểm XYZ chứ không có kế hoạch chi tiết nào cả.

“Epic” giống như kỳ nghỉ của bạn vào năm tới: bạn biết rằng mình có thể đi, nhưng đi đâu, khi nào và với ai – vẫn chưa có suy nghĩ nào về vấn đề này.

Tương tự như vậy, có những tính năng sẽ được triển khai trong tương lai nhưng vẫn chưa biết chi tiết về chúng. Thông thường, một cơ hội bắt đầu bằng một “sự kiện hoành tráng” và sau đó được chia thành các câu chuyện có thể thực hiện được.

7. Nhật ký mong muốn sản phẩm

Nhật ký mong muốn sản phẩm là một loại phân đoạn hoặc nguồn lưu trữ tất cả các câu chuyện của người dùng. Nó được duy trì bởi chủ sở hữu sản phẩm. Nhật ký mong muốn của sản phẩm có thể được coi là danh sách mong muốn của chủ sở hữu sản phẩm, người sẽ ưu tiên nó theo nhu cầu kinh doanh. Trong quá trình lập kế hoạch (xem phần tiếp theo), một trong những câu chuyện của người dùng được lấy từ hồ sơ tồn đọng, nhóm bắt đầu động não, lên ý tưởng, tinh chỉnh và quyết định chung (với ý kiến ​​đầu vào của chủ sở hữu sản phẩm) câu chuyện nào của người dùng sẽ chấp nhận.

8. Danh sách mong muốn chạy nước rút

Mỗi lần một câu chuyện của người dùng được lấy từ nhật ký mong muốn của sản phẩm. Nhóm Scrum động não, xác định tính khả thi và quyết định câu chuyện nào sẽ được thực hiện trong một lần chạy nước rút nhất định. Danh sách tổng thể của tất cả các câu chuyện của người dùng mà nhóm Scrum đang xử lý trong một sprint nhất định được gọi là sprint backlog.

9. Điểm câu chuyện của người dùng:

Những điểm này là sự thể hiện bằng số về mức độ phức tạp của câu chuyện của người dùng. Dựa trên những điểm số này, điểm số và khối lượng công việc của một câu chuyện sẽ được xác định. Điểm không phải là tuyệt đối, chúng là tương đối. Để đảm bảo rằng những nỗ lực và ước tính của chúng tôi là chính xác, chúng tôi cần kiểm tra xem các câu chuyện của người dùng có lớn hay không. Câu chuyện của người dùng càng nhỏ và rõ ràng thì ước tính sẽ càng chính xác.

Mỗi câu chuyện của người dùng được gán một điểm Fibonacci (1, 2, 3, 5, 8, 13, 21). Con số càng cao thì câu chuyện càng phức tạp.

Nói chính xác hơn thì

• Nếu bạn đặt cược 1/2/3 điểm nghĩa là câu chuyện ngắn và độ khó thấp.
• Nếu bạn cho 5/8 điểm thì đó là độ khó trung bình và
• 13 và 21 điểm – câu chuyện rất phức tạp.

Khó khăn ở đây nằm ở việc phát triển và khối lượng công việc kiểm thử

Để quyết định nên cho bao nhiêu điểm, nhóm Scrum bắt đầu động não và quyết định chung. Có thể nhóm phát triển sẽ cho một câu chuyện cụ thể 3 điểm vì đối với họ có thể là 3 dòng mã thay thế, nhưng nhóm thử nghiệm sẽ cho 8 điểm vì họ cảm thấy việc thay mã này sẽ có tác động nhiều hơn đến các mô-đun, vì vậy số lượng công việc sẽ có nhiều hơn trong quá trình thử nghiệm. Nhưng dù bạn cho bao nhiêu điểm thì bạn cũng phải biện minh cho quyết định của mình. Do đó, một phiên động não diễn ra và nhóm quyết định sẽ ghi bao nhiêu điểm.

Bất cứ khi nào bạn quyết định đặt cược bao nhiêu điểm, hãy xem xét các yếu tố sau:

• Mối quan hệ của lịch sử với các ứng dụng/mô-đun khác,
• Bộ kỹ năng tài nguyên
• Sự phức tạp của lịch sử
• Học kể chuyện,
• Tiêu chí chấp nhận câu chuyện của người dùng

Nếu bạn không biết về một câu chuyện cụ thể, đừng thay đổi kích thước của nó.
Nếu bạn thấy điểm của một câu chuyện rất cao, hãy chia nó thành những câu chuyện nhỏ hơn.

10. Biểu đồ phân tích nhiệm vụ

Biểu đồ phân tích nhiệm vụ trình bày một biểu đồ hiển thị v/s ước tính về nỗ lực thực tế của các nhiệm vụ scrum.

Đây là cơ chế theo dõi cho một lần chạy nước rút cụ thể. Nhiệm vụ hàng ngày được theo dõi để kiểm tra xem các câu chuyện có đang tiến tới hoàn thành hay không.

Ví dụ: Để hiểu điều này, hãy nhìn vào bức tranh:

Tôi chọn:

• Chạy nước rút hai tuần (10 ngày)
• 2 tài nguyên cho công việc thực tế của sprint.

"Lịch sử" -> cột hiển thị các câu chuyện của người dùng được thực hiện cho lần chạy nước rút. "Nhiệm vụ" -> cột hiển thị danh sách các tác vụ liên quan đến câu chuyện của người dùng.

“Phạm vi công việc” -> cột hiển thị số lượng công việc. Thước đo này bây giờ là tổng khối lượng công việc để hoàn thành nhiệm vụ. Nó không mô tả khối lượng công việc của bất kỳ người cụ thể nào.

“Ngày 1 – Ngày 10”->– (các) cột hiển thị thời gian còn lại cho đến khi kết thúc câu chuyện. Xin lưu ý rằng đây KHÔNG phải là thời gian đã trôi qua mà là thời gian vẫn còn.

“Số lượng công việc ước tính” -> chỉ số tổng khối lượng công việc. Đối với "Bắt đầu", đây chỉ đơn giản là tổng của toàn bộ nhiệm vụ: SUM (C5:C15)

Tổng khối lượng công việc phải hoàn thành trong 1 ngày là 70/10 = 7. Như vậy, khi kết thúc ngày đầu tiên, khối lượng công việc phải giảm xuống còn 70-7 = 63. Tương tự, tính cho tất cả các ngày cho đến ngày thứ 10, khi khối lượng công việc ước tính phải bằng 0 (dòng 16)

“Khối lượng công việc còn lại” ->Đúng như tên gọi, đây là lượng công việc còn lại trước khi câu chuyện hoàn thành. Cũng có thể xảy ra trường hợp khối lượng công việc thực tế nhiều hơn hoặc ít hơn dự kiến.

Bạn có thể sử dụng các hàm và biểu đồ trong Excel để tạo biểu đồ phân tích nhiệm vụ này.

Các giai đoạn của biểu đồ burndown nhiệm vụ:

1. Nhập tất cả các câu chuyện (cột A5 – A15)
2. Nhập tất cả công việc (cột B5-B15)
3. Nhập ngày (ngày 1 – ngày 10)
4. Nhập khối lượng công việc ban đầu (tổng hợp nhiệm vụ C5-C15)
5. Áp dụng công thức tính “khối lượng công việc ước tính” cho mỗi ngày (từ ngày 1 đến ngày 10). Nhập công thức vào D15 (c16-$C$ 16/10) và kéo nó vào tất cả các ngày.
6. Mỗi ngày hãy nhập số lượng công việc thực tế. Nhập công thức vào D17 (SUM (D5:D15)) để tổng hợp số lượng công việc còn lại và kéo nó sang tất cả các ngày khác.
7. Chọn cái này và tạo một biểu đồ như thế này:

11. Tốc độ của đội

Tổng số điểm mà nhóm scrum lưu trữ trong một lần chạy nước rút được gọi là vận tốc của nhóm. Một nhóm Scrum được đánh giá dựa trên tốc độ của nó. Phải nói rằng cần lưu ý rằng việc đạt được số điểm tối đa KHÔNG phải là mục tiêu ở đây, mà kết quả chất lượng tốt sẽ làm tăng mức độ thoải mái của nhóm scrum.

Ví dụ: Đối với một sprint cụ thể: tổng số user story là 8. Mỗi user story có một số điểm nhất định

Như vậy vận tốc là tổng số điểm = 30

12. Định nghĩa “sẵn sàng”:

Lịch sử được LÀM trong Scrum chỉ khi có sự phát triển, đảm bảo chất lượng đầy đủ và có cơ hội đưa vào sản xuất.

Các hoạt động trong SCRUM:

#1: Cuộc họp lập kế hoạch

Cuộc họp lập kế hoạch là điểm khởi đầu của SCRUM. Đây là cuộc họp nơi toàn bộ nhóm Scrum tập hợp lại. Chủ sở hữu sản phẩm chọn các câu chuyện của người dùng từ sản phẩm tồn đọng dựa trên mức độ ưu tiên và nhóm bắt đầu động não. Trong quá trình thảo luận, nhóm Scrum xác định mức độ phức tạp của câu chuyện và đo lường nó theo chuỗi Fibonacci. Nhóm xác định các nhiệm vụ cũng như số lượng công việc (tính bằng giờ) có thể được thực hiện để hoàn thành việc triển khai câu chuyện của người dùng.

“Lập kế hoạch trước cuộc họp” đặt trước cuộc họp. Đây giống như bài tập về nhà mà nhóm Scrum làm trước khi họp trong cuộc họp lập kế hoạch chính thức. Nhóm cố gắng viết ra các yếu tố phụ thuộc hoặc các yếu tố khác mà họ muốn thảo luận trong cuộc họp.

#2: Hoàn thành mục tiêu Sprint

Đúng như tên gọi, nhiệm vụ của nhóm Scrum là hoàn thành nhiệm vụ của mình và chuyển câu chuyện của người dùng sang trạng thái “hoàn thành”.

#3: Cuộc họp Scrum hàng ngày (cuộc gọi)

Trong chu kỳ chạy nước rút, mỗi ngày nhóm scrum họp không quá 15 phút (đây có thể là một cuộc gọi, nên thực hiện vào đầu ngày). Ba câu hỏi được đặt ra tại cuộc họp:

1. Thành viên trong nhóm đã làm gì kể từ cuộc họp cuối cùng?
2. Thành viên nhóm dự định làm gì hôm nay?
3. Có trở ngại nào cho đội không?

Scrum Master nỗ lực giải quyết những vấn đề này. Nếu người tham gia gặp phải bất kỳ khó khăn nào, Scrum master sẽ giúp giải quyết chúng.

#4: Xem xét kết quả

Vào cuối mỗi chu kỳ chạy nước rút, nhóm SCRUM gặp lại nhau và trình diễn việc triển khai các câu chuyện của người dùng cho chủ sở hữu sản phẩm. Chủ sản phẩm có thể đối chiếu các câu chuyện theo tiêu chí chấp nhận của họ. Một lần nữa, Scrum Master có trách nhiệm chủ trì cuộc họp này.

#5: Cuộc họp hồi tưởng

Một cuộc họp hồi cứu diễn ra sau khi xem xét kết quả. Nhóm SCRUM tập hợp, thảo luận và ghi lại các điểm sau:

1. Điều gì đã diễn ra tốt đẹp trong lần chạy nước rút trước (cách thực hành tốt nhất)
2. Điều gì đã không được thực hiện tốt
3. Bài học kinh nghiệm
4. Các yếu tố hành động

Nhóm Scrum phải tiếp tục tuân theo các phương pháp thực hành tốt nhất, bỏ qua “các phương pháp thực hành tồi” và thực hiện các bài học kinh nghiệm trong các lần chạy nước rút tiếp theo. Cuộc họp hồi cứu giúp liên tục cải tiến quy trình SCRUM.

Quá trình này được thực hiện như thế nào? Ví dụ!

Sau khi đọc về các thuật ngữ kỹ thuật của SCRUM, hãy để tôi thử minh họa toàn bộ quá trình bằng một ví dụ.

Bước 1: Hãy tưởng tượng một nhóm SCRUM gồm 9 người, gồm 1 chủ sở hữu, 1 Scrum master, 2 người thử nghiệm, 4 nhà phát triển và 1 quản trị viên cơ sở dữ liệu.

Bước 2: Ví dụ: Một chu kỳ chạy nước rút sẽ kéo dài 4 tuần. Vì vậy, chúng tôi có sprint 1 tháng: từ ngày 5 tháng 6 đến ngày 4 tháng 7.

Bước 3: Chủ sản phẩm có danh sách ưu tiên các câu chuyện của người dùng trong Product Backlog.

• Chủ sản phẩm lấy 1 câu chuyện từ danh sách mong muốn của sản phẩm, mô tả nó và chuyển cho nhóm để suy nghĩ.
• Toàn bộ nhóm thảo luận và trực tiếp đến gặp chủ sở hữu sản phẩm để giải thích chi tiết về câu chuyện của người dùng.
• Các câu chuyện của người dùng khác cũng được chấp nhận theo cách tương tự. Nếu có thể, nhóm có thể tiếp tục và đo lường các câu chuyện.

Sau khi thảo luận, các thành viên trong nhóm trở lại nơi làm việc và

• Họ xác định nhiệm vụ cá nhân của họ cho mỗi câu chuyện.
• Tính toán chính xác lượng thời gian họ cần để làm việc. Người tham gia tính toán thời gian này như thế nào? Hãy kiểm tra:

Tổng số giờ làm việc = 9

Dấu trừ 1 giờ nghỉ giải lao, trừ 1 giờ họp hành, trừ 1 giờ dành cho email, thảo luận, xử lý sự cố, v.v.
Vậy số giờ làm việc thực tế = 6

Tổng số ngày làm việc trong sprint = 21 ngày.
Tổng số giờ có sẵn = 21 * 6 = 126

Thành viên đang đi nghỉ 2 ngày = 12 giờ (điều này khác nhau đối với mỗi thành viên, một số có thể đi nghỉ, một số thì không.)
Số giờ thực tế = 126-12 = 114 giờ.

Điều này có nghĩa là người tham gia thường sẽ có mặt trong 114 giờ trong lần chạy nước rút này. Vì vậy, anh ta sẽ chia nhiệm vụ chạy nước rút cá nhân của mình sao cho sẽ hoàn thành nó trong 114 giờ.

• Ý kiến ​​cuối cùng về user story từ sản phẩm tồn đọng đã được hoàn thành và câu chuyện được chuyển sang sprint backlog.
• Với mỗi câu chuyện, mỗi thành viên trong nhóm sẽ thông báo nhiệm vụ cụ thể của mình. Nếu bạn muốn thảo luận về những vấn đề này, bạn có thể đo lường hoặc thay đổi kích thước của chúng (hãy nghĩ đến chuỗi Fibonacci!).
• Scrum Master hoặc nhóm nhập các nhiệm vụ cá nhân và thời gian của họ cho từng câu chuyện vào chương trình.
• Khi tất cả các story đã hoàn thành, Scrum Master đánh dấu tốc độ ban đầu và Sprint chính thức bắt đầu.

Bước #6: Khi chạy nước rút bắt đầu, mỗi thành viên trong nhóm bắt đầu thực hiện các nhiệm vụ được giao.

Bước #7: Nhóm họp hàng ngày trong 15 phút và thảo luận 3 câu hỏi:

• Họ đã làm gì vào ngày hôm qua?
• Hôm nay họ dự định làm gì?
• Có sự can thiệp nào không?

Bước #8: Scrum Master theo dõi tiến độ hàng ngày bằng Biểu đồ Burndown

Bước #9: Trong trường hợp có bất kỳ sự can thiệp nào, Scrum Master sẽ giải quyết.

Bước #10: Ngày 4 tháng 7 toàn đội họp lại để xem xét kết quả. Mỗi thành viên trong nhóm trình bày câu chuyện của người dùng đã triển khai cho chủ sở hữu sản phẩm.

Bước #11: Vào ngày 5 tháng 7, nhóm gặp lại nhau trong một cuộc họp hồi tưởng, nơi họ thảo luận về

• Điều gì đã diễn ra tốt đẹp?
• Điều gì đã không diễn ra tốt đẹp
• Các yếu tố hành động

Bước #12: Vào ngày 6 tháng 7, nhóm gặp lại nhau cho cuộc họp lập kế hoạch cho sprint tiếp theo và chu trình tiếp tục.

(Bấm vào để phóng to hình ảnh)

Các chương trình có thể được sử dụng cho hoạt động SCRUM:

Có nhiều công cụ có thể được sử dụng rộng rãi để theo dõi các hoạt động scrum. Dưới đây là một số trong số họ:

• Xplanner
• Phiên bảnMột
• máy đo tốc độ
• ScrumNinja

Phần kết luận:

Ban đầu, mọi người có thể gặp một số khó khăn khi cố gắng thành thạo kỹ thuật này, nhưng khi thực hành, bạn sẽ thấy SCRUM hoạt động rất kỳ diệu. SCRUM tập trung tài nguyên để bạn có thể thấy ứng dụng của mình phát triển.

Nhiều tổ chức tạm thời khuyến khích nhóm (như một nhiệm vụ scrum) dành một vài giờ để tự học và phát triển. Cũng trong quá trình ôn tập, các thành viên trong nhóm trình bày những gì họ đã học được và đôi khi trình bày các chương trình hoặc ứng dụng mà họ đã phát triển. Cá nhân tôi đánh giá cao phương pháp này vì nó giúp mọi người có cơ hội mở rộng kiến ​​thức cũng như thể hiện kỹ năng của mình.

Tôi đang tiếp tục làm luận án về quản lý dự án. Hôm nay chúng ta sẽ xem nhanh Scrum, xem xét những lỗi phổ biến dẫn đến vấn đề. Bài đăng này không có vẻ hoàn chỉnh, nó là một bài tổng quan và dành cho những người chưa quen với Scrum hoặc chỉ mới làm quen một phần (ví dụ: họ làm việc trong Scrum đã sửa đổi).

Hiện nay, Scrum là một trong những phương pháp phát triển phần mềm phổ biến nhất. Theo định nghĩa, Scrum là một khuôn khổ phát triển cho phép mọi người giải quyết các vấn đề mới nổi trong khi vẫn làm việc hiệu quả và tạo ra các sản phẩm có giá trị cao nhất.

Điều này cho thấy rằng trong Scrum không thể tìm ra câu trả lời cho mọi câu hỏi và hướng dẫn hành động trong mọi tình huống (ví dụ, mô tả chính thức của Scrum chỉ cho biết cần ước tính thời gian cần thiết để hoàn thành công việc chứ không chỉ rõ loại ước tính, tức là đây có thể là lập kế hoạch đánh bài hoặc một phương pháp đánh giá khác). Vì vậy, tên của chủ đề là không chính xác :)

Khi nói về phương pháp Scrum, họ thường muốn nói đến một phương pháp phát triển phần mềm linh hoạt được xây dựng trên cơ sở các quy tắc và thực tiễn của Scrum, do đó, có thể hóa ra Scrum của bạn thú vị hơn Scrum của tôi và cũng khác xa so với Scrum của tôi. vì VAZ 7 là của BMW 7 Series :)

Vai trò trong Scrum

Trong Scrum cổ điển có 3 vai trò cơ bản:
-Chủ sở hữu sản phẩm
-Đội sản xuất
-Nhóm phát triển

Chủ sở hữu sản phẩm(PO) là cầu nối giữa nhóm phát triển và khách hàng. Công việc của PO là tối đa hóa giá trị của sản phẩm đang được phát triển và công việc của nhóm.

Một trong những công cụ PO chính là Product Backlog. Product Backlog chứa các nhiệm vụ công việc cần thiết để thực thi (chẳng hạn như Câu chuyện, Lỗi, Nhiệm vụ, v.v.), được sắp xếp theo thứ tự ưu tiên (khẩn cấp).

Đội sản xuất(SM) là “lãnh đạo phục vụ”. Công việc của Scrum Master là giúp nhóm tối đa hóa hiệu quả bằng cách loại bỏ các trở ngại, hỗ trợ, đào tạo và động viên nhóm cũng như hỗ trợ PO

Nhóm phát triển(Nhóm phát triển, DT) gồm các chuyên gia trực tiếp làm việc trên sản phẩm đang được sản xuất. Theo Hướng dẫn Scrum (tài liệu mô tả chính thức về Scrum từ các tác giả của nó), DT phải có những phẩm chất và đặc điểm sau:
- Hãy tự tổ chức. Không ai (kể cả SM và PO) có thể chỉ cho nhóm cách chuyển Product Backlog thành một sản phẩm hoạt động được
-Có tính đa năng, có tất cả các kỹ năng cần thiết để cho ra đời một sản phẩm hoạt động được
-Toàn bộ nhóm chịu trách nhiệm về công việc được thực hiện chứ không phải từng thành viên trong nhóm

Quy mô nhóm được đề xuất là 7 (cộng hoặc trừ 2) người. Theo các nhà tư tưởng Scrum, các nhóm lớn hơn đòi hỏi quá nhiều tài nguyên giao tiếp, trong khi các nhóm nhỏ hơn sẽ tăng rủi ro (do có thể thiếu các kỹ năng cần thiết) và giảm lượng công việc mà nhóm có thể hoàn thành trên mỗi đơn vị thời gian.

Quy trình scrum

Nền tảng của Scrum là Sprint, trong đó công việc phát triển sản phẩm được thực hiện. Vào cuối Sprint, cần có một phiên bản hoạt động mới của sản phẩm. Sprint luôn bị giới hạn về mặt thời gian (1-4 tuần) và có thời lượng như nhau trong suốt vòng đời của sản phẩm.

Trước khi bắt đầu mỗi Sprint, Lập kế hoạch Sprint được thực hiện để đánh giá nội dung của Product Backlog và tạo Sprint Backlog, trong đó chứa các nhiệm vụ (Story, Bugs, Tasks) phải được hoàn thành trong sprint hiện tại. Mỗi sprint phải có một mục tiêu, đây là yếu tố thúc đẩy và đạt được bằng cách hoàn thành các nhiệm vụ trong Sprint Backlog.

Mỗi ngày Scrum hàng ngày được thực hiện, trong đó mỗi thành viên trong nhóm trả lời các câu hỏi “hôm qua tôi đã làm gì?”, “tôi dự định làm gì hôm nay?”, “tôi đã gặp phải những trở ngại gì trong công việc?” Nhiệm vụ của Daily Scrum là xác định trạng thái và tiến độ công việc trên Sprint, phát hiện sớm các trở ngại mới nổi và phát triển các giải pháp thay đổi chiến lược cần thiết để đạt được mục tiêu của Sprint.

Khi kết thúc Sprint, Sprint Review và Sprint Retrospective được thực hiện, nhiệm vụ là đánh giá hiệu quả (hiệu suất) của nhóm trong Sprint vừa qua, dự đoán hiệu quả (hiệu suất) dự kiến ​​trong lần chạy nước rút tiếp theo, xác định hiện tại vấn đề, đánh giá khả năng hoàn thành tất cả công việc cần thiết trên sản phẩm, v.v.

Sơ đồ biểu diễn quá trình được thể hiện trong hình sau:

Những tính năng quan trọng thường bị lãng quên

Bạn thường nghe nói Scrum không hoạt động hoặc hoạt động kém hơn mong đợi. Cần lưu ý rằng điều này thường xảy ra nhất vì một trong những lý do sau:

1. Scrum được áp dụng không đúng hoặc không đầy đủ.
Theo các tác giả của Scrum, kinh nghiệm thực nghiệm là nguồn thông tin đáng tin cậy chính. Sự cần thiết phải triển khai Scrum đầy đủ và chính xác được nêu trong Hướng dẫn Scrum và là do cách tổ chức quy trình không điển hình và sự thiếu vắng người lãnh đạo và quản lý chính thức.

2. Tầm quan trọng của việc tạo động lực cho nhóm bị đánh giá thấp.
Một trong những nguyên tắc cốt lõi của Scrum là các nhóm đa chức năng, tự tổ chức. Theo nghiên cứu của các nhà xã hội học, số lượng nhân viên năng động, có khả năng tự tổ chức không vượt quá 15% dân số đang làm việc.
Do đó, chỉ một tỷ lệ nhỏ nhân viên có thể làm việc hiệu quả trong Scrum mà không có những thay đổi đáng kể trong vai trò của Scrum Master và Product Owner, điều này trái với hệ tư tưởng Scrum và có khả năng dẫn đến việc sử dụng Scrum không đúng hoặc không đầy đủ.

3. Scrum được sử dụng cho một sản phẩm có yêu cầu trái ngược với hệ tư tưởng Scrum.
Scrum thuộc họ Agile nên Scrum hoan nghênh những thay đổi trong yêu cầu bất kỳ lúc nào (Sản phẩm tồn đọng có thể được thay đổi bất kỳ lúc nào). Điều này gây khó khăn cho việc sử dụng Scrum trong các dự án có chi phí cố định/thời gian cố định. Hệ tư tưởng Scrum cho rằng không thể thấy trước tất cả các thay đổi, do đó, chẳng ích gì khi lập kế hoạch trước cho toàn bộ dự án, giới hạn bản thân trong việc lập kế hoạch đúng lúc, tức là chỉ lập kế hoạch cho những công việc phải hoàn thành trong hiện tại. Tăng tốc. Có những hạn chế khác.

Ưu điểm và nhược điểm

Scrum có những ưu điểm khá hấp dẫn. Scrum tập trung vào khách hàng và thích ứng. Scrum cung cấp cho khách hàng khả năng thực hiện các thay đổi đối với yêu cầu bất kỳ lúc nào (nhưng không đảm bảo rằng những thay đổi này sẽ được triển khai). Khả năng thay đổi yêu cầu là điều hấp dẫn đối với nhiều khách hàng phần mềm.

Scrum khá dễ học và cho phép bạn tiết kiệm thời gian bằng cách loại bỏ các hoạt động không quan trọng. Scrum cho phép bạn có được một sản phẩm có khả năng hoạt động vào cuối mỗi Sprint.
Scrum nhấn mạnh một nhóm đa chức năng, tự tổ chức có thể hoàn thành các nhiệm vụ được yêu cầu với sự phối hợp tối thiểu. Điều này đặc biệt hấp dẫn đối với các công ty nhỏ và công ty khởi nghiệp vì nó loại bỏ nhu cầu thuê hoặc đào tạo nhân viên quản lý chuyên ngành.

Tất nhiên, Scrum cũng có những nhược điểm quan trọng. Do tính đơn giản và tối giản của nó, Scrum đặt ra một số ít quy tắc khá nghiêm ngặt. Tuy nhiên, điều này mâu thuẫn với ý tưởng lấy khách hàng làm trung tâm về nguyên tắc, vì khách hàng không quan tâm đến các quy tắc nội bộ của nhóm phát triển, đặc biệt nếu họ giới hạn khách hàng. Ví dụ: nếu cần, theo quyết định của khách hàng, Sprint backlog có thể được thay đổi, bất chấp sự mâu thuẫn rõ ràng với các quy tắc Scrum.

Vấn đề lớn hơn nó có vẻ. Bởi vì Scrum thuộc họ Agile; Ví dụ, Scrum không tạo ra một kế hoạch truyền thông và ứng phó rủi ro. Do đó, gây khó khăn hoặc không thể giải quyết chính thức (về mặt pháp lý hoặc hành chính) các hành vi vi phạm quy tắc Scrum.

Một điểm yếu khác của Scrum là nó nhấn mạnh vào một nhóm đa chức năng, tự tổ chức. Mặc dù chi phí cho việc phối hợp nhóm giảm rõ rệt nhưng điều này lại dẫn đến tăng chi phí cho việc lựa chọn, động viên và đào tạo nhân sự. Trong những điều kiện thị trường lao động nhất định, việc thành lập một nhóm Scrum chính thức và hiệu quả có thể là điều không thể.

Danh sách các nguồn được sử dụng

Hướng dẫn Scrum. Hướng dẫn dứt khoát về Scrum: Quy tắc của trò chơi. (Ken Schwaber, Jeff Sutherland)
Tâm lý học quản lý, Sách giáo khoa. (A. A. Trus)
Người quản lý dự án truyền thống chuyển sang Scrum như thế nào: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)

Cảm ơn bạn trước vì những lỗi và sự không chính xác này!