Trong ngành công nghệ thông tin hiện nay, khái niệm Agile đã trở nên khá phổ biến. Mọi người đang nói về nó. Hầu hết các công ty công nghệ thông tin đều đã áp dụng một mức độ nào đó của agile.
Cũng có nhiều phương pháp dưới sự bao trùm của phát triển agile, bao gồm Lập trình cực đoan (XP), Scrum, Phương pháp Crystal, Phát triển phần mềm thích ứng (ASD), Phát triển dựa trên tính năng (FDD), Phát triển hệ thống động (DSDM), và nhẹ nhàng. RUP, Phát triển dựa trên kiểm thử (TDD), và nhiều hơn nữa. Trong số nhiều phương pháp phát triển agile, việc thực hiện Scrum là phổ biến hơn.
Agile hay Waterfall? Xem các số liệu
Báo cáo gần đây nhất từ Nhóm Standish đã đề cập đến các dự án mà họ nghiên cứu từ năm 2013 đến 2017. Trong khoảng thời gian này, tổng quan về thành công, thách thức và thất bại được hiển thị dưới đây cho agile và waterfall, với các dự án Agile có khả năng thành công gấp khoảng 2 lần và ít có khả năng thất bại hơn 1/3.
(Nguồn: vitalitychicago.com — So sánh tỷ lệ thành công của dự án Waterfall và Agile)
Bài viết này chủ yếu chia sẻ sự hiểu biết về Scrum, quy trình thực hiện Scrum và những thay đổi do việc thực hiện Scrum mang lại, và giải thích Scrum đang hoạt động là gì.
Scrum là gì?
Scrum là một khuôn khổ để phát triển và duy trì các sản phẩm phức tạp và là một quy trình phát triển gia tăng, lặp đi lặp lại. Trong khuôn khổ này, toàn bộ quy trình phát triển bao gồm nhiều chu kỳ lặp ngắn, một chu kỳ lặp ngắn gọi là Sprint, và mỗi Sprint kéo dài từ 2 đến 4 tuần.
Trong Scrum, sử dụng Backlog sản phẩm để quản lý nhu cầu của sản phẩm. Backlog sản phẩm được sắp xếp theo thứ tự ưu tiên của việc thực hiện, với giá trị thương mại là nguyên tắc chính của việc sắp xếp. Trong Sprint, nhóm Scrum chọn các yêu cầu có ưu tiên cao nhất từ Backlog sản phẩm để phát triển. Các yêu cầu được chọn sẽ được thảo luận, phân tích và ước lượng tại cuộc họp lập kế hoạch Sprint để có được danh sách các nhiệm vụ gọi là Sprint backlog. Khi nhóm Scrum hoàn thành tất cả các nhiệm vụ trong danh sách Sprint backlog, Sprint kết thúc và tiến hành đến chu kỳ lặp Sprint tiếp theo.
Tại sao Scrum thất bại ở một số công ty
Scrum có giá trị lớn. Tuy nhiên, việc thực hiện Scrum trong một số công ty là khó khăn. Một số người nói rằng Scrum không có tác động thực chất trong tổ chức của họ. Tại sao họ lại có kết quả như vậy? Những lý do chính có thể là:
- Agile nhanh hơn — Nhóm dự án thiếu sự hiểu biết đúng đắn về agile. Họ đơn giản nghĩ rằng sự linh hoạt là nhanh chóng, tức là theo kịp tiến độ, và có thể thoát khỏi bất kỳ ràng buộc nào của hệ thống.
- Agile nhanh hơn, hoặc chúng ta cần làm thêm giờ — Tôi đã nghe rằng một số công ty phải phát triển một chức năng mới. Do việc thực hiện scrum, nhóm dự án được yêu cầu làm thêm giờ, và các nhiệm vụ phát triển từ 2 tuần trở lên sẽ được phát hành trong vòng một tuần. Việc thực hiện Scrum có nghĩa là nhóm dự án đang làm thêm giờ, điều này dẫn đến một “nỗi sợ” trong sự linh hoạt của nhóm dự án;
- Backlog sản phẩm không được duy trì tốt — PO không đủ điều kiện cho công việc, không thể phân chia các câu chuyện người dùng hiệu quả, hoặc việc phân chia câu chuyện của người dùng là không hợp lý, không thể nhận ra sự phát triển gia tăng;
- Vấn đề hình thành đội ngũ — Scrum có yêu cầu cao về các đội tự tổ chức, nhưng nhiều thành viên trong nhóm cảm thấy rằng họ không đạt tiêu chuẩn của sự tự tổ chức;
- Thiếu văn hóa Agile — Scrum ủng hộ sự minh bạch trong công việc, sự hoàn thành dự án theo thời gian thực và sự công nhận nhiệm vụ của từng người. Bảng Sprint và biểu đồ burndown của dự án không bị cản trở, và nhiều người không thoải mái với điều đó;
- Kiểm tra và điều chỉnh không đúng chỗ — Trong quá trình lặp lại, vấn đề không thể được phát hiện kịp thời, hoặc vấn đề được tìm thấy, và vấn đề không thể được giải quyết hiệu quả, điều này khiến nhóm dự án cảm thấy thất vọng. và còn nhiều hơn nữa.
Nếu kiến thức về Scrum chỉ dừng lại ở:
“Tôi có một ý tưởng vào buổi sáng, nó sẽ được hiện thực hóa vào buổi chiều, và sẽ được đưa lên mạng vào buổi tối.”
Điều đó là không phù hợp. Theo ý kiến của tôi, Scrum chắc chắn có giá trị. Các chức năng chính của Scrum bao gồm:
- Scrum có thể đảm bảo ưu tiên phát triển backlog sản phẩm có giá trị cao đối với khách hàng và đáp ứng tốt hơn nhu cầu của người dùng.
- So với phương pháp phát triển theo quy trình waterfall, việc thực hiện Scrum có thể giúp đội ngũ gấp đôi hiệu quả phát triển và tối đa hóa vai trò của đội ngũ;
- Scrum có thể rút ngắn chu kỳ phát triển và tăng cường hiệu quả giao hàng dự án.
Tuy nhiên, việc thực hiện Scrum không có nghĩa là không phải tuân theo các quy tắc và ràng buộc của dự án. Vậy tư thế đúng để thực hiện Scrum là gì?
Các bước để thực hiện Scrum
1. Giao một PO
PO là người sở hữu sản phẩm, đây là một vai trò, và PO là người duy nhất sở hữu danh sách công việc quản lý sản phẩm. Tất nhiên, trong một số công ty, PO đã tồn tại như một tổ chức — ví dụ, công ty chúng tôi đã thực hiện PO như một tổ chức trong việc thực hiện Scrum.
Là một người sở hữu, phải có cái nhìn tổng thể; hiểu sâu về thông tin và định hướng ngành; có khả năng nắm bắt định hướng của sản phẩm, phụ trách lập kế hoạch và quản lý sản phẩm ngắn hạn, trung hạn và dài hạn; có khả năng tiến hành nghiên cứu người dùng và lập kế hoạch chức năng sản phẩm theo yêu cầu chiến lược của công ty, theo dõi nhu cầu luôn thay đổi, và tiếp tục đổi mới sản phẩm.
Ngoài ra, nếu bạn sử dụng PO như một tổ chức, trong một dự án phát triển phần mềm, đội ngũ PO có thể bao gồm các bên liên quan khác như các quản lý sản phẩm, người dùng cuối.
2. Hình thành một đội ngũ phát triển
Đội ngũ là người thực hiện sản phẩm và chịu trách nhiệm giao hàng các phần gia tăng có thể giao hàng và các phần sản phẩm “hoàn thành” vào cuối mỗi Sprint.
Đội ngũ chủ yếu bao gồm nhân viên phát triển và kiểm thử, và đội ngũ phải có khả năng thực hiện tầm nhìn của PO về sản phẩm.
Kích thước của đội ngũ nên khoảng từ 5 đến 9 người.
Đội ngũ Scrum cũng nên đa chức năng và các thành viên có khả năng “full stack” là ưu tiên hơn, ngay cả khinó có thể khó thực hiện trong hầu hết các công ty.
3. Chọn Scrum Master
Scrum Master chịu trách nhiệm về quy trình Scrum và phục vụ PO và đội ngũ phát triển. Scrum Master phải có cảm giác về nghi thức, và có thể tổ chức hiệu quả và hiệu suất các cuộc họp lập kế hoạch lặp lại, cuộc họp đứng hàng ngày, cuộc họp trình diễn chức năng, và cuộc họp đánh giá lại; Scrum Master phải có mức độ thực hiện cao và duy trì độ tin cậy để giúp đội ngũ. Tập trung vào các mục tiêu giao hàng và mục tiêu chất lượng để đảm bảo các đội ngũ giao hàng sản phẩm chất lượng cao một cách hiệu quả; thúc đẩy các đội ngũ xây dựng quy trình hiệu quả, hướng dẫn các đội ngũ về các giá trị, nguyên tắc và thực tiễn agile; chịu trách nhiệm đào tạo các thành viên khác trong đội ngũ để đảm bảo rằng Scrum được sử dụng đúng cách; Giao tiếp, quản lý vấn đề, giải quyết xung đột, giúp đội ngũ loại bỏ tất cả các rào cản.
4. Duy trì Backlog sản phẩm
Sản phẩm Backlog là một tập hợp tất cả các mục backlog, và dựa trên chiến lược của công ty và tầm nhìn sản phẩm. PO sắp xếp tất cả các mục trong sản phẩm backlog theo thứ tự ưu tiên dựa trên giá trị kinh doanh, và hình thành một danh sách mục ưu tiên.Sản phẩm backlog có thể được coi như là “bản đồ” của phát triển sản phẩm. Để hiểu bối cảnh sản phẩm, các mục trong sản phẩm backlog là tài liệu tham khảo tốt nhất.
Mỗi ngày chúng ta phải đối mặt với những yêu cầu mới từ các đối thủ cạnh tranh mới, điều này có nghĩa là PO phải liên tục tối ưu hóa thiết kế sản phẩm và điều chỉnh các ưu tiên của sản phẩm backlog để đối phó với những thay đổi mới.
Trong quá trình này, PO nên tham khảo ý kiến của tất cả các bên liên quan và các đội để đảm bảo rằng sản phẩm backlog phản ánh đúng yêu cầu của người dùng.
5. Ước lượng Agile sử dụng Điểm câu chuyện
Ước lượng Agile tương đối thường được thực hiện trong quá trình lập kế hoạch sprint hoặc điều chỉnh trong một sprint và sản phẩm backlog được đánh giá bởi đội ngũ cùng với người chịu trách nhiệm cho công việc phát triển và kiểm tra thực tế.
Để thực hiện việc lập kế hoạch sprint hiệu quả hơn trong thực tế, PO và Scrum Master sẽ thực hiện một ước lượng sơ bộ trước cuộc họp lập kế hoạch sprint. Họ cần đặt ra những câu hỏi như:
- Xem liệu kế hoạch sprint có khả thi không?
- Có đủ thông tin để hoàn thành những vấn đề này không?
- Việc chia tách mục sản phẩm backlog có hợp lý không?
Khi đội phát triển thực hiện ước lượng, nên từ bỏ phương pháp truyền thống (tức là số giờ được phân bổ cho nhiệm vụ) và sử dụng phương pháp ước lượng Agile bằng cách sử dụng điểm câu chuyện – số Fibonacci (1, 2, 3, 5, 8, 13, 21…) để đánh giá nỗ lực cần thiết cho việc thực hiện một mục.
Tại thời điểm ước lượng, đội cần xác định trước một mục backlog có thể ở dạng câu chuyện người dùng như một tài liệu tham khảo cho việc ước lượng. Ngoài ra, cần lưu ý rằngkhi điểm câu chuyện đơn lẻ của đánh giá lớn hơn 21, câu chuyện người dùng cần được chia tách lại, và điểm câu chuyện người dùng đơn lẻ không quá 8 là trạng thái lý tưởng.
6. Cuộc họp lập kế hoạch sprint
Đây là cuộc họp Scrum thực sự đầu tiên. Đội, Scrum Master và PO ngồi lại với nhau để lập kế hoạch nội dung của sprint.Như một dự án phát triển phần mềm, khi vào câu chuyện người dùng của kế hoạch sprint, câu chuyện người dùng nên đã được chia tách và thiết kế trực quan hoàn thành.
Chu kỳ sprint thường cố định, chủ yếu từ 2 đến 4 tuần. Đội bắt đầu với câu chuyện người dùng có ưu tiên cao nhất trong danh sách việc cần làm của sản phẩm để xem có thể hoàn thành bao nhiêu trong một sprint.
Nếu đội đã thực hiện nhiều sprint, tham khảo:
- Các “điểm câu chuyện” đã hoàn thành trong các lần lặp trước,
- Đội có thể ước lượng các điểm câu chuyện gần đúng cho lần lặp này.
- “Điểm câu chuyện” tương đương với tốc độ của đội.
Scrum Master và Đội nên cố gắng tăng con số này trong mỗi lần lặp sprint.
Tất cả các thành viên trong đội nên đạt được sự đồng thuận về mục tiêu của một sprint, tức là những gì cần hoàn thành trong một lần lặp sprint. Tại cuộc họp lập kế hoạch sprint, PO cần thông báo cho Đội thứ tự ưu tiên của việc thực hiện câu chuyện người dùng. Đội hứa hẹn sẽ hoàn thành bao nhiêu câu chuyện trong lần lặp sprint tiếp theo. Trong quá trình sprint, không ai có thể đơn phương thay đổi nội dung sprint mà không có sự cho phép.
7. Cuộc họp Đứng hàng ngày
Cuộc họp Đứng hàng ngày là nguồn sống cho Scrum. Các thành viên tham gia thường bao gồm PO, Scrum Master và đội. Đội giao tiếp nội bộ tại một địa điểm cố định và vào một thời gian cố định mỗi ngày.Thời gian thường là buổi sáng, thời gian không quá 15 phút, và đứng. Scrum Master hỏi đội các thành viên những câu hỏi sau:
- Bạn đã làm gì hôm qua?
- Bạn dự định làm công việc gì hôm nay?
- Có những trở ngại và khó khăn nào?
Ý nghĩa của điều này là để toàn bộ đội biết rõ tiến độ của từng nhiệm vụ trong chu kỳ sprint này, và liệu tất cả các nhiệm vụ có thể hoàn thành đúng hạn hay không.
Các nhiệm vụ của đội không được phân công từ trên xuống, mà được quyết định theo sáng kiến và tự nguyện. Nếu nhiệm vụ trước chưa hoàn thành, bạn không thể xin nhiệm vụ tiếp theo, và bạn không thể yêu cầu hai nhiệm vụ không thể hoàn thành trong cùng một ngày.
Scrum Master có trách nhiệm loại bỏ các trở ngại mà các thành viên trong đội gặp phải.
8. Theo dõi tiến độ dự án với Bảng tác vụ Scrum
Trong Scrum, công việc phải minh bạch, và thực hành phổ biến nhất là thực hiện một bảng tác vụ Scrum.
Một số đội giỏi sử dụng các công cụ bên thứ ba để sử dụng bảng Scrum điện tử, chẳng hạn như Visual Paradigm hoặc Jira; một số đội thích sử dụng bảng trắng vật lý lớn ngoại tuyến.
Bất kể bạn sử dụng bảng Scrum điện tử hay bảng trắng vật lý, các cột của Kanban thường bao gồm ba phần: danh sách việc cần làm, các mục đang tiến hành và các mục đã hoàn thành. Khi tiến độ của lần lặp tiến triển, đội sẽ kịp thời cập nhật vấn đề vào cột Scrum Kanban tương ứng mỗi ngày.
9. Theo dõi tiến độ với biểu đồ burn-out
Một công cụ khác để làm cho công việc minh bạch là biểu đồ burn-out. Trong hình dưới đây, một trục đại diện cho khối lượng công việc, và trục còn lại đại diện cho thời gian. Mỗi ngày Scrum Master ghi lại các điểm còn lại cần hoàn thành và sau đó vẽ chúng trên biểu đồ burn-out. Lý tưởng nhất, đồ thị là một đường cong đi xuống, giảm xuống bằng không khi phần còn lại của công việc được hoàn thành.
10. Trình diễn sản phẩm
Phần trình diễn của Hướng dẫn Scrum được gọi là Cuộc họp Đánh giá Sprint, trong đó nêu rõ rằng nó nên bao gồm việc trình bày công việc đã được thực hiện bởi đội phát triển và trả lời các câu hỏi về sự gia tăng sản phẩm. Cuộc họp thường được tổ chức trước khi phát hành lần lặp này.Công việc quan trọng nhất của cuộc họp này là xác minh các kịch bản thực hiện của các câu chuyện người dùng với các đánh giá chấp nhận cho từng mục đã hoàn thành để đáp ứng định nghĩa hoàn thành.
Cuộc họp này là nơi bất kỳ ai cũng có thể tham gia, không chỉ PO, Scrum Master và đội, mà còn cả các bên liên quan, doanh nghiệp và quản lý, và thậm chí cả khách hàng.
Đây là một cuộc họp mở nơi bất kỳ ai cũng có thể tham gia, không chỉ PO, Scrum Master và đội, mà còn cả các bên liên quan, doanh nghiệp và quản lý, và thậm chí cả khách hàng.
Các đội chỉ nên trình bày những mục đáp ứng định nghĩa hoàn thành, tức là, những kết quả có thể được giao mà không cần phải thực hiện thêm bất kỳ công việc nào nữa. Kết quả này có thể không phải là một sản phẩm hoàn chỉnh, nhưng ít nhất nó là một tính năng hoàn chỉnh và có thể sử dụng cho người dùng cuối.
11. Phản hồi Sprint
Cuộc họp tổng kết sprint thường được tổ chức vào ngày thứ hai sau khi kết thúc sprint này.
Cuộc họp tổng kết sprint nên xem xét cẩn thận các câu hỏi sau:
- Điều gì đã xảy ra cần được cải thiện;
- Tại sao điều đó lại xảy ra?
- Tại sao chúng ta lại bỏ qua nó vào thời điểm đó;
- Làm thế nào chúng ta có thể tăng tốc công việc.
Là một đội, để làm cho quá trình tổng kết sprint này hiệu quả, đội cần phải tin tưởng lẫn nhau. Chúng ta phải nhớ các cuộc thảo luận và lập luận dựa trên các vấn đề dự án và kỹ thuật:
- Không có đúng, sai và lo lắng tuyệt đối,
- Khuyến khích sự va chạm kỹ thuật;
- Không được tham gia vào các cuộc thảo luận về tấn công cá nhân;
- Chống lại những người đeo kính màu để nhìn người khác,
- Hướng dẫn mọi người thảo luận một cách hợp lý;
- Dũng cảm chấp nhận những thách thức từ người khác,
- Chấp nhận những thiếu sót của chính mình.
- Chịu trách nhiệm về quy trình và kết quả của chính mình,
- động não và tìm kiếm giải pháp cho các vấn đề. Điều này là rất quan trọng.
Cuối cùng, đội xác định một trong những cải tiến đáng giá nhất và đặt nó là ưu tiên hàng đầu cho sprint tiếp theo. Bạn cần xác định điều gì là “thành công” theo cách cụ thể và có thể hành động để nhanh chóng xác định xem các cải tiến đã được thực hiện trong cuộc họp tổng kết sprint tiếp theo hay chưa.
Sau khi sprint cuối cùng kết thúc, bắt đầu vào vòng lặp sprint mới.
Tóm tắt
Scrumlà sự kết hợp của 3355. Các khái niệm cốt lõi của khung scrum có thể được ghi nhớ đơn giản là 3.3.5.5 như sau:
3 vai trò
- Chủ sở hữu sản phẩm
- Nhóm phát triển
- Người hướng dẫn Scrum
3 sản phẩm
- Danh sách sản phẩm
- Danh sách công việc của sprint — Danh sách việc cần làm của sprint
- Tăng trưởng sản phẩm — Tăng trưởng sản phẩm có thể giao hàng
5 sự kiện
- Sprint
- Cuộc họp lập kế hoạch sprint
- Cuộc họp Scrum hàng ngày
- Cuộc họp tổng kết sprint
- Cuộc họp tổng kết sprint
5 giá trị
- Cởi mở
- Tôn trọng
- Dũng cảm
- Tập trung
- Cam kết
Các mục tiêu của 3355 nằm sau ba trụ cột của Scrum
- Minh bạch
- Kiểm tra
- Thích ứng
Định nghĩa về “Hoàn thành” (DoD) được đạt được bằng cách thực hiện 3 trụ cột thông qua 5 sự kiện của Nhóm Scrum.
This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.