Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Workflow
Code

SCRUM: Câu chuyện về một đội ngũ Agile

by
Difficulty:AdvancedLength:LongLanguages:

Vietnamese (Tiếng Việt) translation by Thai An (you can also view the original English article)

Scrum là một trong những kỹ thuật agile được sử dụng nhiều nhất. Đó không phải là về viết code; thay vào đó, kỹ thuật này tập trung vào việc tổ chức và quản lý dự án. Nếu bạn có ít thời gian, hãy để tôi kể cho bạn về cách thức mà đội ngũ tôi cùng nhau làm việc và chúng tôi áp dụng các kỹ thuật Scrum ra sao.


Lược sử

Nguồn gốc của Scrum thực ra đã nằm ngoài kỷ nguyên Agile.

Nguồn gốc của Scrum thực ra đã nằm ngoài kỷ nguyên Agile. Năm 1986, Hirotaka Takeuchi và Ikujiro Nonaka đã lần đầu tiên đề cập đến kỹ thuật này, dành cho phát triển sản phẩm thương mại. Bài báo chính thức đầu tiên định nghĩa Scrum, do Jeff Sutherland và Ken Schwaber viết, được trình bày năm 1995.

Mức độ phổ biến của Scrum đã tăng lên ngay sau khi Agile Manifesto xuất bản năm 2001, cũng giống cuốn sách Agile Software Development with Scrum, đồng tác giả bởi Ken Schwaber và Mike Beedle.


Một số cơ sở

Scrum định nghĩa tập hợp các đề xuất khuyến khích các đội ngũ tuân theo. Nó cũng định nghĩa vài tác nhân - hoặc vai trò (nếu bạn thích thuật ngữ đó),  cùng với một quy trình tuần hoàn của việc sản xuất và định kỳ lên kế hoạch. Có vài công cụ phù hợp với quy trình của Scrum. Tôi sẽ nhắc đến một vài công cụ trong bài viết này, nhưng các công cụ mạnh nhất là tấm bảng trắng và những mảnh giấy dán ghi chú.

Sẽ không bao giờ có một danh sách "các thực tiễn Scrum tốt nhất", bởi vì bối cảnh của đội ngũ và dự án sẽ đánh bại tất cả các cân nhắc khác. - Mike Cohn

Các vai trò

Mọi thứ bắt đầu với con heo và con gà. Con gà hỏi con heo liệu có hứng thú cũng mở một nhà hàng. Con gà nói rằng chúng có thể gọi là "Ham-and-Eggs." Con heo trả lời, "Không, cảm ơn. Tôi sẽ xử lý, nhưng bạn chỉ được tham gia!"

Đó là Scrum! Nó chỉ định một tập hợp các vai trò cụ thể, được chia thành hai đội ngũ:

  • Committed (cam kết) - những người trực tiếp chịu trách nhiệm sản xuất và phân phối sản phẩm cuối cùng. Những vai trò này bao gồm toàn bộ đội ngũ như một tổng thể, các thành viên của đội ngũ, scrum master (chuyên gia scrum) và product owner (chủ sản phẩm).
  • Involved (tham gia) - đại diện cho những người có quan tâm đến dự án, nhưng những họ không chủ động tham gia hoặc trực tiếp vào quy trình sản xuất và phân phối. Những vai trò này thường là các bên liên quan và các nhà quản lý.

Đây là cách chúng tôi bắt đầu

Tất cả mọi thứ phụ thuộc vào sự cống hiến và sự quyết tâm. Nếu bạn muốn đội ngũ của mình hoạt động hiệu quả, có năng suất và phân phối đúng hẹn, bạn cần có người am hiểu một số hình thái kỹ thuật Agile. Scrum có thể (hoặc không thể) lý tưởng với bạn, nhưng chắc chắn là một trong những khởi đầu tôt nhất. Hãy tìm ai đó trong đội ngũ của bạn, sẵn sàng giúp đỡ người khác, hoặc chính bạn, có thể đảm nhận trách nhiệm giới thiệu Scrum.

Bạn có thể hỏi tại sao bạn cần quan tâm một đội ngũ khác (như của tôi) thực hành Scrum thế nào. Bạn nên thế bởi vì tất cả chúng tôi đều học cách làm Scrum tốt hơn bằng cách nghe những câu chuyện về cách những người khác triển khai nó ra sao - đặc biệt là họ đang làm tốt điều đó. - Mike Cohn

Đội ngũ tài năng mà tôi làm việc cùng đã biết rất nhiều về Agile. Chúng tôi đã chuyển đổi từ Waterfall sang một quy trình agile hơn và phát hành khá thường xuyên. Chúng tôi nỗ lực thành công để phát hành mỗi 3 đến 6 tháng, có lượng lỗi thấp sau mỗi lần phát hành.

Nhưng, chúng tôi vẫn còn rất xa so với thành tựu của ngày hôm nay. Chúng tôi đã bỏ lỡ quy trình, hoặc các quy tắc, điều đó sẽ buộc chúng tôi thay đổi quan điểm về sản phẩm và quy trình. Đó là thời điểm mà người quản lý đội ngũ của chúng tôi giới thiệu cho chúng tôi về Scrum, một thuật ngữ mà vào thời điểm đó chúng tôi chưa từng nghe nói đến.

Người này đảm nhận vai trò của Scrum Master.

Scrum Master (chuyên gia về Scrum)

Scrum Master dễ dàng trở thành một trong những vai trò quan trọng nhất. Người này chịu trách nhiệm kết nối giữa Product Owner (được xác định bên dưới) và Team (đội ngũ), sẽ được định nghĩa sau. Người này thường sở hữu kiến thức vững chắc về kỹ thuật và tích cực tham gia vào quá trình phát triển. Người đó cũng giao tiếp với Product Owner về User Stories (các yêu cầu từ người dùng) và cách tổ chức Backlog.

Scrum Master điều phối quá trình phát triển, nhưng anh ta không quản lý vi mô (đội ngũ sẽ tự tổ chức). Tuy nhiên, khi bắt đầu quá trình, Scrum Master có thể quản lý vi mô một phần của đội ngũ để cải thiện khả năng tương tác và tự tổ chức đội ngũ của họ.

Scrum Master đảm nhận nhiều trách nhiệm hơn và tôi sẽ đề cập đến chúng khi chúng tôi thảo luận về quy trình này.


Giới thiệu thuật ngữ "Sprint"

Về cá nhân chúng tôi không có bất kỳ vấn đề gì với các bản phát hành vào mỗi 3 đến 6 tháng, nhưng ban đầu tôi không thể hình dung được lịch phát hành thường xuyên như vậy. Tôi nghĩ rằng nó quá nhanh và không cho chúng tôi thời gian cần thiết để tích hợp và gỡ lỗi các sản phẩm của chúng tôi. Nhưng sau đó, Scrum Master của chúng tôi đã giới thiệu cho chúng tôi thuật ngữ, sprint.

Sprint: một đơn vị phát triển cơ bản trong Scrum. Có thể trong khoảng một tuần đến một tháng và sản phẩm ở trạng thái ổn định sau mỗi sprint.

Nghe có vẻ thái quá! Ổn định mỗi tuần > không thể nào! Nhưng, trong thực tế, hoàn toàn có thể. Đầu tiên, chúng tôi đã giảm chu kỳ phân phối của mình từ 3 tháng xuống còn 1.5, và cuối cùng, xuống còn 1 tháng. Tất cả điều này đã được thực hiện mà không cần thay đổi phong cách của chúng tôi. Tuy nhiên, bạn sẽ cần giới thiệu vài quy tắc cho một sprint ngắn hơn 30 ngày. Không có quy tắc kỳ diệu nào được đề ra ở đây; các quy tắc phải có lợi cho dự án của bạn.

Nếu tôi nhớ một cách chính xác, sự thay đổi đáng kể đầu tiên trong quá trình phát triển của chúng tôi là do sự ra đời của việc lên kế hoạch sprint.

Lên kế hoạch cho sprint

Đây là một trong số cuộc họp mà Scrum khuyến nghị. Trước mỗi sprint mới, đội ngũ, product owner và scrum master lên kế hoạch cho sprint tiếp theo. Cuộc họp này có thể mất cả ngày, nhưng sprint ngắn hơn có thể chỉ cần một vài giờ hoặc lâu hơn.

Quá trình của chúng tôi chủ yếu là xem xét các backlog tồn đọng của sản phẩm và quyết định một tập hợp con của các user story sẽ được đưa vào sprint kế tiếp. Những quyết định này được đưa ra từ các cuộc thương lượng trực tiếp trong đội ngũ, được đại diện bởi scrum master và product owner.

Product Owner (chủ sản phẩm)

Thiết lập định hướng của sản phẩm bằng cách dự đoán tính năng nhỏ nào sẽ cung cấp giá trị tốt nhất sẽ là nhiệm vụ khó khăn nhất.

Người này chịu trách nhiệm xác định User Stories và duy trì Product Backlog. Anh ấy (hoặc cô ấy) cũng là cầu nối giữa đội ngũ và cấp quản lý cao hơn. Product Owner đánh giá các yêu cầu từ các bên liên quan, cấp quản lý cao hơn, người dùng và phản hồi khác (như báo cáo lỗi, khảo sát người dùng, v.v.).

Anh ấy hoặc cô ấy ưu tiên backlog này, cung cấp giá trị tối đa cho các bên liên quan trong thời gian nhanh nhất có thể. Product Owner đạt được điều này bằng cách lập kế hoạch cho những user story có giá trị nhất có thể được hoàn thành đúng hẹn. Điều này nghe có vẻ phức tạp - thực sự thế! Trong thực tế, thiết lập đính hướng của sản phẩm bằng cách dự đoán tính năng nhỏ nào sẽ cung cấp giá trị lớn nhất có thể là nhiệm vụ khó khăn nhất của toàn bộ quá trình. Mặt khác, đôi khi nó khá dễ dàng. Bạn có thể có một ngàn người dùng yêu cầu một tính năng cụ thể. Trong những trường hợp này, sự lựa chọn chính xác rất rõ ràng.

Nếu những người dùng đó chiếm phần lớn trong nền tảng người dùng của bạn, việc cung cấp tính năng cụ thể đó sẽ cải thiện sự trung thành.

Nhưng lần nữa cho thấy đây là lựa chọn khó khăn. Điều gì sẽ xảy ra nếu bạn có thể tăng 100% nền tảng người dùng của mình bằng cách triển khai một tính năng khác biệt? Vì vậy, bạn có thể tăng mức độ trung thành của người dùng hiện tại hoặc tăng số lượng người dùng. Vậy chọn lựa chính xác là gì? Tất cả phụ thuộc vào hướng đi hiện tại của doanh nghiệp và product owner phải quyết định nơi để thực hiện sản phẩm.

Trong công ty tôi làm việc, những quyết định này phổ biến rộng rãi cho đội ngũ. Đây không phải là một yêu cầu của quy trình Scrum, nhưng nó đặc biệt hữu ích với các đội ngũ mới. Việc chia sẻ thông tin có ích trong việc giúp mọi người hiểu tại sao vài quyết định được đưa ra và tại sao các tính năng dường như rõ ràng có thể bị trì hoãn hoặc bỏ đi.


Bảng kế hoạch

Tôi nhớ buổi sáng nó đã xảy ra: Tôi đến văn phòng, chỉ để thấy scrum master của chúng tôi chuẩn bị một bảng kế hoạch tạm thời với tờ giấy A4 và băng keo trong suốt. Tôi không biết anh ấy đang làm gì. Như mọi buổi sáng, tôi chuẩn bị một bình cà phê, và chờ đợi.

Khi hoàn thành, một tấm bảng trắng được treo trên tường. Nó có vài cột và biến thành hình chữ nhật. Một số ghi chú màu sắc rải rắm "tấm bảng." Đó là hai năm trước đây.


Bảng này giờ chứa đựng quy trình phát triển Lean (tinh gọn) mà ngày nay chúng tôi sử dụng. Hãy nhớ rằng, Agile chủ yếu là sự thay đổi và thích nghi với thay đổi. Đừng bao giờ mù quáng làm theo các quy tắc.

Vì vậy, trên bảng đó có những gì?

Các cột cho quá trình phát triển

Có bốn cột chính:

  • Release Backlog (phát hành các tồn đọng) - Nơi tất cả các story nằmtrong phiên bản hiện tại. Vâng, sản phẩm đã sẵn sàng để phát hành sau mỗi sprint, nhưng điều đó không nhất thiết là chúng tôi thực sự phát hành nó. Chúng tôi thường có các sprint kéo dài năm ngày.
  • Sprint Backlog - Khi chúng tôi lập kế hoạch, chúng tôi thương lượng những gì product owner muốn hoàn thành trong sprint. Làm thế nào chúng tôi quyết định những điều chúng tôi có thể và không thể hoàn thành? Bằng cách ước tính độ khó của từng story (xem bên dưới - Đánh giá các story). Kết quả cuối cùng là tập hợp các story được chuyển từ release backlog sang sprint backlog. Đội ngũ tập trung hoàn thiện những story trong tuần tới.
  • Working on (đang thực hiện) - Cột này đơn giản. Khi các thành viên trong đội ngũ nhận một story, họ bổ sung nó vào cột này, để cho mọi người thấy điều họ đang làm. Điều này nhằm để kiểm soát nhân viên, hơn là giao tiếp với các thành viên trong đội ngũ. Mọi người luôn nên biết bạn cùng đội ngũ của họ đang làm gì. Trong hình trên, các dấu trang nhỏ dán trên các giấy dán ghi chú có ghi tên của các thành viên trong đội ngũ của tôi.
  • Done (hoàn thành) - Hoàn thành tất cả mọi thứ! Vâng, đây là nơi story hoàn thành hiện diện. Tuy nhiên, điều quan trọng là xác định "những gì đã được thực hiện." Vào cuối giai đoạn của một sprint lý tưởng, tất cả các story và lỗi từ sprint backlog phải được hiện diện trong cột này.

Lời khuyên: Nhiều đội ngũ muốn chia cột Working On thành nhiều cột khác để xác định rõ hơn các giai đoạn làm việc khác nhau. Chúng tôi chia thành Design (thiết kế), Development (phát triển) và Testing (kiểm nghiệm). Hãy tự nghĩ ra các bước riêng của bạn, dựa theo quy trình của bạn.

Định nghĩa của hoàn thành

Cái gì đã hoàn thành? Khi nào bạn có thể tự tin nói rằng một story đã hoàn thành? Làm sao bạn biết được?

"Hoàn thành" phải được định nghĩa rõ ràng và chính xác, để mọi người biết khi nào một story hoàn thành. Định nghĩa của "hoành thành" giữa các đội ngũ có thể khác nhau, và thậm chí giữa trong các dự án. Không có quy tắc nào chính xác. Tôi khuyên bạn nên nêu lên vấn đề này trong một cuộc họp đội ngũ và quyết định điều gì xác định một story hoàn thành là gì. Dưới đây là vài ý tưởng mà có thể bạn có thể xem xét:

  • Tạo một thiết kế tối giản.
  • Tạo một mockup GUI.
  • Sử dụng TDD hoặc đảm bảo rằng có các unit test.
  • Viết code.
  • Hãy để một thành viên khác trong đội ngũ kiểm tra story của bạn.
  • Toàn bộ hệ thống có thể được xây dựng và biên dịch với code mới.
  • Functional test hoặc acceptance test vượt qua như mong đợi, sau khi code mới được tích hợp vào hệ thống.

Có nhiều ý tưởng có thể được nói đến trong định nghĩa về hoàn thành. Lấy những điều bạn cho là cần thiết cho đội ngũ của bạn và sử dụng nó. Ngoài ra, đừng quên điều chỉnh định nghĩa này theo thời gian. Nếu bạn nhận thấy rằng định nghĩa của bạn đang trở nên lỗi thời, bạn có thể cân nhắc loại bỏ vài yếu tố hoặc thêm các ý tưởng cần thiết (nhưng thường bị lãng quên).

Trong hình trên, các giấy dán ghi chú màu xanh lá cây mô tả những điều chúng tôi coi là được hoàn thành, cho từng phần của quy trình.


Điền vào tấm bảng

Đó là câu hỏi chúng tôi từng tự hỏi. Cho đến lúc đó, chúng tôi đã không sử dụng giấy dán ghi chú để lên kế hoạch. Chúng tôi đã sử dụng phần mềm để theo dõi các story và lỗi của người dùng, nhưng, ngoài ra, chúng tôi không sử dụng thêm gì cả. Sau bữa trưa, scrum master của chúng tôi tặng chúng tôi một mớ giấy ghi chú màu sắc. Sau khi chuẩn bị một tá ghi chú, anh ta giải thích chúng cho chúng tôi.

User Stories

User Story là một định nghĩa ngắn gọn, chỉ một câu về một tính năng hoặc chức năng.

Chúng đại diện cho các tính năng chính mà chúng tôi muốn thực hiện. User Story là một định nghĩa ngắn gọn, chỉ một câu về tính năng hoặc chức năng. Nó được gọi là một user story (câu chuyện của người dùng), bởi vì nó được trình bày từ quan điểm của người dùng. Đương nhiên, thuật ngữ user (người dùng) nói đến người sử dụng ứng dụng của chúng tôi. Người này có thể nằm trong một hoặc nhiều hình thức khác nhau: quản trị viên hệ thống, người dùng có quyền hạn chế, người quản lý, v.v.

Một ví dụ về một story như vậy có thể nghe giống như "Khi là người dùng, tôi muốn chia sẻ một thư mục với các thành viên trong đội ngũ của mình."

Vào thời điểm đó, chúng tôi chưa xác định product owner, vì vậy scrum master của chúng tôi đã phát minh ra những story này. Điều này có thể chấp nhận được ở giai đoạn đầu, nhưng tôi cực kỳ khuyên bạn nên tách biệt hai vai trò này. Nếu không, làm thế nào scrum master có thể thương lượng sprint backlog với product owner?

Bạn có thể tự nghĩ rằng: "Tại sao phải thương lượng? Chẳng phải thực sự tốt hơn khi chỉ một người quyết định nên làm gì và khi nào?" Không hẳn. Hai vai trò sẽ bị ảnh hưởng bởi góc nhìn của một người của một hệ thống hoặc dự án. Mặt khác, hai người khả năng cao hơn để cung cấp một đường lối khách quan hơn cho đội ngũ, để đat được sự đảm bảo cho mục tiêu cuối cùng (phần mềm có giá trị tốt hơn).

Product Owner nên xác định rõ user story; đội ngũ sẽ thương lượng việc thực hiện và scrum master đại diện cho họ.

User Story định rõ mọi thứ mới cần phải được thực hiện; chúng được thể hiện bằng các giấy dán ghi chú màu vàng trên bảng của chúng tôi.

Lỗi, lỗi, lỗi

Việc theo dõi lỗi vô cùng quan trọng.

Chúng tôi cũng liệt kê ra các lỗi trên bảng. Bạn có thấy những ghi chú dính màu đỏ không? Đó là những lỗi mà chúng tôi cần sửa cho lần phát hành tiếp theo.

Các đội ngũ khác nhau xử lý lỗi theo những cách khác nhau. Nhóm của chúng tôi trộn các lỗi với các story, nhưng chúng tôi luôn bắt đầu sprint bằng cách sửa các lỗi.

Tôi biết các đội ngũ khác chồng chất lỗi trong một khoảng thời gian của 3 sprint và dành mỗi sprint thứ 4 để sửa chúng. Những người khác chia sprint thành bugs/stories theo tỉ lệ 25/75. Hơn nữa, các đội ngũ khác có thể làm việc trên các story vào buổi sáng và sửa lỗi sau bữa chiều; chỉ đơn giản là tùy vào công ty.

Tùy thuộc vào bạn để tìm giải pháp tốt nhất cho đội ngũ của bạn, và tất nhiên, theo dõi các lỗi của bạn. Viết chúng trên các giấy dán ghi chú để bạn có thể theo dõi các sự cố của hệ thống và cách khắc phục các sự cố đó. Việc theo dõi lỗi của bạn là vô cùng quan trọng.

Nhiệm vụ hoặc các story phụ

Nhiệm vụ được viết dưới dạng các câu đơn giản theo góc nhìn của nhà phát triển.

Lý tưởng nhất là mỗi story nên đủ ngắn gọn để được dễ dàng hoàn thành, nhưng việc chia tách các story thành các story khác có thể rõ ràng là khó khăn. Một số dự án đơn giản là thể làm vậy. Tuy nhiên, bạn sẽ tìm thấy những story lớn mà vài thành viên trong đội ngũ có thể làm việc. Điều quan trọng là phân chia khối lượng lớn công việc thành các phần nhỏ hơn, dễ quản lý hơn.

Một phương pháp chia nhỏ những story lớn thành các nhiệm vụ. Nhiệm vụ được viết dưới dạng câu đơn giản theo góc nhìn của nhà phát triển. Ví dụ: story chia sẻ thư mục trước đó có thể được chia thành vài nhiệm vụ, chẳng hạn như: "Tạo giao diện người dùng để chia sẻ", "Thực hiện cơ chế chia sẻ công khai", "Thực hiện chức năng kiểm soát truy xuất", "Bổ sung hộp kiểm soát truy cập cho giao diện người dùng" v.v. Vấn đề là bạn phải suy nghĩ nhiều hơn về story mỗi khi bạn chia nó thành những nhiệm vụ nhỏ hơn. Nhóm của bạn sẽ kiểm soát tốt hơn nhiều đối với một story, khi bạn phân tích từng phần.

Chúng tôi sử dụng giấy dán ghi chú màu xanh nhạt cho các nhiệm vụ trên bảng của chúng tôi. Nhìn vào cột cuối cùng (cột "Done") và bạn sẽ tìm thấy các nhiệm vụ của chúng tôi trong các story người dùng. Câu chuyện đặc biệt đó đã được chia thành khoảng 4 nhiệm vụ.


Nhiệm vụ về kỹ thuật

Một số hoạt động nhất định phải được hoàn tất để kết thúc một nhiệm vụ, story hoặc sprint nói chung. Các tác vụ này thường liên quan đến cơ sở hạ tầng, nhưng bạn có thể thấy rằng các tác vụ yêu cầu các thay đổi cho hệ thống. Quá trình này có thể hoặc không phải là một phần của story. Ví dụ: bạn có thể thấy rằng phải cài đặt ứng dụng của bên thứ ba để thực hiện khả năng chia sẻ của ứng dụng. Đây có phải là một phần của user story của chúng tôi? Có thể đúng, nhưng có thể không.

Chúng tôi xác định rằng những nhiệm vụ này nên được tách ra khỏi story thực sự. Điều này giúp chúng tôi theo dõi tốt hơn các nhiệm vụ bổ sung. Trên bảng của chúng tôi, bạn có thể tìm thấy các nhiệm vụ này trên các giấy dán ghi chú màu xanh lá cây. Sprint backlog có 1 cái, và 3 cái ở testing.

Backlog về mặt kỹ thuật

Đối với một đội ngũ trẻ có ít kinh nghiệm với Agile và Scrum, thật hữu ích khi làm nổi bật các nhiệm vụ này bằng backlog nhỏ.

Backlog này là nơ dành cho các nhiệm vụ về cơ sở hạ tầng, chẳng hạn như cập nhật hệ thống kiểm thử tự động, cấu hình một máy chủ mới và những thứ khác, giúp cho việc phát triển hàng ngày của chúng tôi dễ dàng hơn. Đây là những thứ phải được hoàn thành lúc nào đó, nhưng không liên quan trực tiếp đến việc phát triển.

Bạn không cần phải đưa các mục này vào một backlog riêng biệt. Trên thực tế, tôi biết các đội ngũ không tách chúng ra. Đội ngũ của chúng tôi đã bỏ backlog về kỹ thuật khoảng vài tháng trước; chúng tôi quyết định các nhiệm vụ về cơ sở hạ tầng cũng quan trọng như các nhiệm vụ khác. Tuy nhiên, đối với một đội ngũ trẻ có ít kinh nghiệm với Agile và Scrum, thật hữu ích khi làm nổi bật các nhiệm vụ này bằng backlog nhỏ. Vì vậy, tôi khuyên bạn nên thử qua. Nó có thể hiệu quả cho bạn, và, nếu không thì sau đó chỉ cần đưa nhiệm vụ về cơ sở hạ tầng lên bảng kế hoạch của bạn, có thể bằng một màu khác.


Thử thách lớn: sự đánh giá

Trong cuộc họp để lập kế hoạch, chúng tôi quyết định những story và lỗi của người dùng từ product backlog (hoặc release backlog trong trường hợp của chúng tôi) để đưa vào sprint tiếp theo. Điều này nghe có vẻ đơn giản, nhưng, trong thực tế, khá phức tạp.

Product Owner tiên phong với một loạt các story cần hoàn thành. Danh sách này thường có nhiều công việc hơn số lượng có thể hoàn thành trong sprint. Scrum master cùng với đội ngũ phải thuyết phục product owner về những nhiệm vụ có thể được thực hiện trong một sprint. Theo thời gian, quá trình này trở nên dễ dàng hơn, khi product owner tìm hiểu tốc ươc tính của đội ngũ. Sau đó, một lần nữa, đội ngũ có thể cải thiện năng suất trong mỗi sprint, do đó cho phép hoàn thành nhiều story hơn. Bí quyết là có một đội ngũ thực sự muốn vượt qua cả mong đợi!

Bây giờ, product owner muốn hoàn thành nhiều story hơn số chúng tôi có thể làm trong một sprint. Chúng tôi cần đánh giá số lượng công việc chúng tôi có thể làm liên quan đến các story được product owner gửi đến và chúng tôi có thể thực hiện việc này theo nhiều cách khác nhau.

Điểm số của story

Các điểm của story là một trong những phương pháp phổ biến nhất để đánh giá story, lỗi hoặc nhiệm vụ. Các điểm số không hẳn là phương pháp tốt nhất, nhưng vẫn là một khởi đầu tốt.

Vậy điểm cho story là gì? Giai đoạn đầu của quá trình, đội ngũ tìm kiếm story đơn giản nhất họ có thể tìm thấy trên bảng. Không quan trọng là story khó như thế nào, hoặc mất bao lâu để hoàn thành. Khi họ tìm thấy story đó, họ đặt nó như một story tham chiếu của một điểm. Trong vài dự án, một story như vậy có thể đơn giản như thay đổi các thành phần UI trong mười phút; trong khi đó, story đơn giản nhất cho các hệ thống phức tạp hơn có thể mất hai giờ và cần 3 người để hoàn thành. Bây giờ bạn có một cơ sở, đánh giá các story và lỗi khác và gán điểm cho chúng.

Việc này có các khó khăn tiềm ẩn, và có vài kỹ thuật chấm điểm giúp đánh giá story tốt hơn. Dưới đây là hai trong số đó:

  • Sử dụng số Fobinacci - 1,2,3,5,8 (và có thể 13, nhưng một story tầm 13 có vẻ quá lớn với tôi).
  • Sử dụng số mũ của 2 - 1,2,4,8 (và có thể 16, nhưng nên tránh số này).

Bạn có thể tự do lựa chọn bất cứ cách nào bạn cảm thấy thoải mái nhất. Hãy dùng agile! Có thể bạn muốn sử dụng tăng lên 2 điểm, bởi vì nhiệm vụ của bạn được đánh giá tốt nhất theo cách đó. Chúc mừng bạn!

Semaphores

Những con số rất tuyệt, và nhiều người làm về kỹ thuật yêu thích chúng. Tuy nhiên, bạn có thể thấy rằng, tại vài thời điểm, các lập trình viên bắt đầu liên kết các điểm story với thời gian. Họ sẽ nghĩ, "Tôi phải mất 2 ngày để làm điều này. Hãy cho nó 5 điểm". Điều này sai. Việc đánh giá đi từ xấu đến tồi tệ hơn khi áp dụng điều này. Điểm của story không bao giờ nên liên quan đến thời gian.

Sử dụng các màu semaphore có thể giảm bớt vấn đề này. Thay vì gán số cho các story, đội ngũ có thể liên kết những story đó với các màu sắc. Đội ngũ của chúng tôi đã thực hiện thay đổi này vài tháng trước và đã thay đổi quan điểm của chúng tôi rất nhiều.

Đương nhiên, mỗi màu có một ý nghĩa khác nhau.

  • Màu xanh lá cây biểu thị một nhiệm vụ dễ dàng có thể được hoàn thành trong sprint tiếp theo.
  • Màu vàng đề cập một nhiệm vụ khó khăn hơn - một nhiệm vụ đòi hỏi nhiều nỗ lực hơn từ vài thành viên trong đội ngũ. Nó cũng có cơ hội hoàn thành cao trong sprint tiếp theo.
  • Nhãn màu đỏ được gán cho các story, cực kỳ khó khăn và có thể không được hoàn thành trong một sprint. Sẽ có ít hoặc không có những story như vậy, nhưng nếu bạn chấp nhận sprint một tuần, năm ngày là một thời gian ngắn.

Kích thước T-Shirt

Những con số với bạn có thể xấu xí, màu sắc quá nghệ thuật. Đã đến lúc cho kích cỡ áo phông! Kỹ thuật này đề xuất từ bỏ việc so sánh độ phức tạp của story với thời gian hoàn thành. Nói một cách đơn giản, thay vì dùng con số, bạn sử dụng các kích thước như S, M, L, XL, XXL cho các story của mình.

Cá nhân tôi chưa bao giờ cảm thấy hứng thú với loại đánh giá này, nhưng vài người cảm thấy rằng đó là cách tốt nhất để thực hiện. Hãy thử nó, nếu bạn cảm thấy thoải mái với ý tưởng này.


Product Owner, các bên liên quan và người quản lý phải biết điều mong đợi vào cuối sprint. Họ phải quyết định xem những story đã được thực hiện có nên được phát hành hay không và họ phải biết khi nào các tính năng đã sẵn sàng. Phát hành từ mỗi tính năng mới vào cuối chu kỳ phát triển của sản phẩm không phải là một giải pháp tốt; việc phát hành các tính năng có giá trị nhất thường xuyên hơn là cách thực hành tốt hơn. Để đạt được điều này, họ phải biết điều gì hiện diện theo ngắn hặn và thông tin của họ nên bắt nguồn từ đội ngũ. Do đó, đội ngũ nên đánh giá, tốt nhất có thể, công việc họ có thể làm trong một sprint.


Dự liệu tốc độ phát triển

Vậy bạn muốn thấy bạn thực hiện tốt đến mức nào trong sprint hiện tại? Một phương pháp thường được sử dụng là biểu đồ burndown:


Trong biểu đồ này, chúng tôi có một sprint 5 ngày và chúng tôi giả định rằng chúng tôi có thể hoàn thành 10 điểm trong một sprint. Mỗi giá trị điểm đại diện cho các điểm story còn lại vào cuối mỗi ngày. Đường màu xanh cho thấy hướng đi lý tưởng: 2 điểm ổn định cho mỗi ngày. Đường màu đỏ cho thấy hiệu suất thực tế của chúng tôi hoặc tốc độ phát triển thực sự.

Không chỉ trên hình ảnh của bảng kế hoạch, nhưng đội ngũ của tôi đã từng có một tờ giấy A4 được dán phía trên bảng kế hoạch, với biểu đồ burndown cho mỗi sprint. Vào cuối mỗi ngày, một trong số thành viên trong đội ngũ chịu trách nhiệm tính toán số điểm hoàn thành cho ngày hôm đó. Thật đơn giản: nếu các lập trình viên chuyển các story từ cột này sang cột khác khi họ làm việc, việc tìm kiếm các story còn lại chưa hoàn thành khá dễ.

Không có story hoàn thành nửa vời. Nếu một story được hoàn thành, thì nó đã hoàn thành. Nếu nó không hoàn thành, thì nó không được tính vào biểu đồ burndown.

Tất nhiên, bạn sẽ thất bại lớn khi đánh giá! Điều này đặc biệt đúng khi bắt đầu. Không có cách nào để tránh khỏi điều này, thật không may. Không có cách nào để biết bạn có thể giao phó bao nhiêu điểm. Biểu đồ đầu tiên của bạn rất có thể trông giống như:


Biểu đồ đầu tiên của chúng tôi chắc chắn gần giống như vậy. Tôi nghĩ rằng chúng tôi thậm chí không hoàn thành một nửa số chúng tôi cam kết. Tại sao? Vâng, bởi vì việc đánh giá là khó khăn. Bất kể bạn làm gì, hay bạn giỏi đến mức nào, khi ai đó hỏi bạn rằng mức độ phức tạp của việc mà bạn đã từng hoàn thành, thì bạn sẽ khó có thể đưa ra đánh giá chính xác. Đừng hoảng sợ! Hãy cố gắng hết sức. Qua thời gian, những điều này trở nên dễ dàng hơn. Bạn có thể đánh giá với độ chính xác 70% tại vài thời điểm cho những sprint ngắn hạn. Nếu sprint dài hơn, độ chính xác của bạn sẽ thấp hơn, bởi vì sẽ có nhiều story hơn để đánh giá và nhiều biến số có thể sai.

Khi điều này xảy ra, bạn hãy điều chỉnh. Với sprint tiếp theo, mất 4 điểm. Như thế này:


Lần nữa điều này khá tệ. Bạn đã quá thận trọng, và sớm hoàn thành. Đó là một phản ứng tự nhiên để đội ngũ điều chỉnh, dựa trên sự thất bại của đánh giá trước đó. Tuy nhiên, đây lại là một thất bại, nhưng ở mặt khác.

Vấn đề ư? Bạn làm gì sau khi hoàn thành điều bạn dự định? Chuyện khác? Làm thế nào để bạn biểu đạt nó trên biểu đồ? Bạn không thể vẽ lại đường ban đầu.

Khi làm việc với các biểu đồ burndown, trung bình bạn nên luôn tạo 3-5 biểu đồ, để xác định điểm cho sprint sắp tới. Tất nhiên, lúc đầu, bạn không có sẵn thông tin như vậy, vì vậy bạn sẽ không chính xác như trong sau này. Không sao đâu.

Sau một thời gian, biểu đồ của bạn càng ngày sẽ bắt đầu giống với ví dụ đầu tiên. Hầu hết thời gian, bạn sẽ hoàn thành tất cả các story và có một tốc độ duy trì.

Tốc độ?

Thuật ngữ này đề cập đến tốc độ phát triển của bạn. Nó liên quan đến bạn có thể làm được bao nhiêu trong một sprint. Một trong những khái niệm quan trọng nhất trong Agile là có tốc độ phù hợp. Làm cho đội ngũ phân phối với một tốc độ ổn định. Với quản lý dự án truyền thống, tốc độ giảm khi một dự án kéo dài. Sự phức tạp và cứng nhắc buộc tốc độ phát triển giảm xuống.

Phương pháp và kỹ thuật Agile hướng đến mục tiêu duy trì tốc độ không đổi. Hãy phân phối nhanh bây giờ, và phân phối nhanh hơn sau này. Họ làm điều đó như thế nào? Scrum là một trong những yếu tố của câu đố. Các yếu tố quan trọng khác bao gồm các kỹ thuật mà các lập trình viên có thể sử dụng để khiến cho code và quy trình phát triển của họ tốt hơn. Ví dụ: XP (Lập trình eXtreme), Pair Programming, TDD (Test Driven Development), v.v ... Tất cả những điều này, cùng nhau có thể làm cho một đội ngũ thực sự tuyệt vời.

Vì vậy, chúng tôi dự liệu tốc độ này, nhưng thực sự chúng tôi làm gì với nó?

Lời khuyên: Dự liệu tốc độ là để đưa ra dự đoán tốt hơn; không phải để đánh giá một đội ngũ hoặc các thành viên của nó.

Hãy sử dụng tốc độ để biết những gì đội ngũ của bạn có thể làm. Hãy sử dụng tốc độ để biết những gì mong đợi. Hãy sử dụng tốc độ để làm cho đội ngũ của bạn muốn nhiều hơn và tốt hơn. Không bao giờ sử dụng tốc độ để đánh giá đội ngũ của bạn hoặc đánh giá năng suất của các lập trình viên của bạn.


Luôn nhìn lại và cải thiện

Sau vài sprint đầu tiên, scrum master của chúng tôi đã tập hợp cả đội ngũ. Anh ấy bắt đầu hỏi chúng tôi về những điều tốt và xấu của tuần trước. Việc này có thể không thoải mái lúc bắt đầu, nhưng vẫn cực kỳ quan trọng. Mô tả những gì bạn cảm thấy đã sai trong tuần trước sẽ mang đến ý thức. Và tất nhiên cũng hữu ích để làm nổi bật những điều tốt đẹp đã diễn ra!

Các cuộc họp này thường được gọi là Hồi tưởng. Chúng đề xuất phạm vi để làm nổi bật những điều tốt và điều sai. Dưới đây là vài ví dụ từ quan điểm của riêng tôi.

Những điều xấu

  • Các thành viên trong đội ngũ đã tranh đấu quá nhiều
  • Thành viên đội ngũ X hoặc Y không hợp tác khi lập trình cặp (pair programming)
  • Chúng ta đã tốn quá nhiều thời gian cho những điều nhỏ nhặt, như X hoặc Y
  • Chúng tôi không thực hành lập trình cặp suốt
  • Chúng tôi không viết unit test cho mô-đun M

Khi thảo luận vấn đề, hãy cố gắng gạt cảm xúc cá nhân sang một bên; nói về những điều làm phiền bạn. Đây là cách duy nhất để đội ngũ giải quyết vấn đề. Điều quan trọng nhất là ngay lập tức đề xuất một giải pháp cho từng vấn đề. Đừng chỉ đơn giản là viết danh sách ra và lãng quên chúng; hãy dành ra vài phút và để cả đội ngũ nghĩ về điều cần làm để tránh các vấn đề đó vào tuần tới.

Những điều tốt đẹp

  • Chúng tôi hoàn thành đúng hạn
  • Chúng tôi đã có thể trò chuyện mà không cần tranh đấu
  • Vài trong trong chúng tôi trở nên dễ tiếp thu hơn với các đề xuất và ý tưởng
  • Chúng tôi đã viết tất cả các code qua TDD

Lần nữa làm nổi bật càng nhiều càng tốt - đặc biệt là vào lúc bắt đầu hoặc với các lập trình viên cấp thấp. Ví dụ, tất cả code được viết bằng TDD có thể là thành tựu lớn đối với một đội ngũ cấp thấp. Hãy khiến họ cảm thấy thực sự thoải mái với điều này, hãy khiến họ muốn làm điều đó nhiều hơn nữa. Tương tự áp dụng hiệu quả cho đội ngũ ngũ cao cấp; đơn giản họ làm nổi bật những điều khác (TDD được hoàn thành theo phản xạ).


Tôi muốn xem bạn đã làm gì trong sprint này

Bản demo dành cho bên liên quan (và product owner) biết tiến trình của dự án.

Tiêu đề này xuất phát từ scrum master của tôi. Tại thời điểm đó, ông cũng là product owner. Trước khi kết thúc sprint, anh ấy yêu cầu chúng tôi trình bày cho anh ấy chúng tôi đã hoàn thành cái gì. Chúng tôi đã chuẩn bị bản Demo hoặc một ví dụ hoạt động trong môi trường được kiểm soát.

Scrum đề xuất các bản demo này vào cuối sprint. Chúng nên được hoàn thành trước buổi họp retrospective (hồi tưởng) mà chúng tôi đã thảo luận ở trên. Đội ngũ nên chuẩn bị một môi trường đặc biệt và đảm bảo rằng sản phẩm có khả năng trình diễn các tính năng được hoàn thành trong sprint này. Bản demo cho các bên liên quan (và product owner) xem tiến độ của dự án.

Bạn có thể tự hỏi tại sao tôi lại đề cập đến một môi trường được kiểm soát, khi sản phẩm của chúng tôi sẽ sẵn sàng vào cuối mỗi sprint. Vâng, sản phẩm phải càng gần với thực tế càng tốt, nhưng điều đó không có nghĩa là bản thân tính năng này đã sẵn sàng. Thông thường, sẽ có những tính năng quá lớn để đáp ứng trong một sprint. Sản phẩm sẽ vẫn ổn định, nhưng tính năng sẽ không hoàn toàn sẵn sàng. Khi các bên liên quan xem bản demo, họ muốn xem lại tính năng và nó có thể làm được gì. Trong nhiều trường hợp, để giới thiệu vài chức năng cho các tính năng chưa hoàn thành, trước tiên phải chuẩn bị những môi trường đặc biệt.

Ngoài ra, dựa trên các bản demo này, product owner có thể xác định rằng một tính năng lớn hơn đủ tốt và phiên bản mới của sản phẩm sẽ được phát hành và gửi đến người dùng. Hầu hết thời gian, ngay cả khi một tính năng chưa hoàn thiện, một bản phát hành sẽ giúp dự án nhận được phản hồi có giá trị của người dùng và tập trung hoàn thành tính năng để làm hài lòng nhiều người dùng nhất có thể.

Chà, điều này nghe có vẻ khá đơn giản. Bạn là một đội ngũ agile, bạn luôn giữ các test ở màu xanh lá cây và sản phẩm của bạn ở tình trạng ổn định. Chuẩn bị một bản demo nhanh chóng sẽ khó khăn đến đâu? Khó hơn bạn tưởng đấy!

Nếu tôi nhớ chính xác, nhóm chúng tôi đã thử hơn 5 lần trước khi chúng tôi nỗ lực để chuẩn bị bản demo một cách chính xác. May mắn cho chúng tôi, các bên liên quan đã không được tính đến trong những bản demo thất bại đầu tiên!


Tuy nhiên, chúng tôi cần thêm sự hướng dẫn

Trong các cuộc họp này, mỗi thành viên trong đội ngũ phải trả lời 3 câu hỏi.

Đó là khi scrum master của chúng tôi đề xuất tổ chức một cuộc họp mỗi ngày. Vâng! Mỗi ngày, mỗi buổi sáng, vào một giờ cố định!

Tôi thấy điều này rất tốt cho các đội ngũ mới - cho những người chưa thoải mái với nhau hoặc với dự án. Các cuộc họp hàng ngày này, được gọi là Daily Scrum, được đội ngũ duy trì, vào một thời điểm nhất định mỗi ngày. Điều này nên được duy trì trước khi bất kỳ công việc được hoàn thanh theo ngày tương ứng. Trong đội ngũ của tôi, chúng tôi thiết lập thời gian là 10 giờ sáng mỗi ngày, điều này rất khó thực hiện. Tuy nhiên, đó là quyết định chính xác.

Daily Scrum là một cuộc họp ngắn gọn và đơn giản (không quá mười lăm phút). Phạm vi là giúp các thành viên trong đội ngũ xem ai đang làm gì và xác định các vấn đề và vướng mắt gì đang có trong dự án phát triển.

Lời khuyên: Vì chúng tôi muốn đảm bảo rằng các cuộc họp này ngắn gọn, chúng tôi chỉ đứng. Mọi người thường mệt mỏi sau 15 phút đứng, thật hoàn hảo! Nếu bạn thấy đồng nghiệp đang tìm chỗ ngồi và nghỉ ngơi, thì có thể cuộc họp của bạn đã diễn ra quá lâu.

Trong các cuộc họp này, mỗi thành viên trong đội ngũ phải trả lời 3 câu hỏi:

  • Hôm qua bạn đã làm gì? - Một câu trả lời ngắn được mong đợi - tối đa 2-3 câu.
  • Hôm nay bạn sẽ làm gì? - Vẫn câu trả lời ngắn gọn, đại loại như "Tôi sẽ làm việc với story này ngày hôm nay."
  • Có vấn đề trong quá trình của bạn không? Nếu có, nó là gì? Chúng có thể được giải quyết nhanh chóng không? Đây sẽ là một câu trả lời nêu bật các vấn đề và giải pháp (nếu bạn đã có). Không nên thảo luận chi tiết trong khi cuộc họp này diễn ra. Scrum Master nên ghi chú lại vấn đề và cùng đội ngũ làm việc để giải quyết vấn đề đó, sau khi cuộc họp được kết thúc.

Ưu tiên giải quyết vấn đề theo cách của những người phát triển trong đội ngũ, để họ có thể tiếp tục công việc càng sớm càng tốt. Thông thường, người gặp vấn đề có khả năng giải quyết kịp thời. Những lần khác, anh ấy hoặc cô ấy cần sự giúp đỡ của các thành viên trong nhóm. Và khi khác, vấn đề có thể nghiêm trọng đến mức đội ngũ sẽ phải ngừng phát triển và tập trung hoàn toàn vào việc giải quyết thứ đang ngăn cản họ tiếp tục công việc.

Tôi nhớ đội ngũ của tôi bắt gặp khó khăn cực độ này trong nhiều lần khác nhau. Có những nhiệm vụ và story, dường như khá rõ ràng ở khi mới nhìn vào, nhưng sau khi một cặp hoặc một lập trình viên đơn lẻ có dịp đào sâu vào vấn đề, điều hiển nhiên trở nên khó hiểu và không đúng. Chúng tôi đã phát hiện ra nhiều lần rằng một thư viện bên thứ ba không thể cung cấp cho chúng tôi các chức năng cần thiết và cuối cùng tập trung mọi nỗ lực của chúng tôi để tìm một thư viện khác phù hợp hơn - hoặc thậm chí tự triển khai một giải pháp.

Phần lớn dự án của chúng tôi được viết bằng PHP. Một số thời điểm, chúng tôi phải interface dự án của chúng tôi với VMWare. Chúng tôi đã xem xét các thư viện chính thức cho VMWare API và phát hiện ra có các phiên bản Java và Perl. Ngoài ra còn có chọn lưa không chính thức Ruby. Chúng tôi chắc chắn rằng chúng tôi có thể sử dụng một trong số chúng và chỉ cần thực hiện vài lệnh exec() của PHP để thu kết quả sau cùng dưới dạng chuỗi. Như chúng tôi nghĩ, việc phân tích từ đó có thể cực đơn giản.

Hóa ra điều này là không thể. Cả thư viện API đều không hiệu quả như chúng tôi mong đợi. Một số bị bỏ qua hoặc không đầy đủ, và chúng gần như không thể phân tích kết quả sau cùng. Cuối cùng, chúng tôi đã buộc phải làm một việc mà chưa ai từng làm trước đây: triển khai thư viện API VMWare trong PHP. Thật không may, không có cách hợp lý có thể chấp nhận được để thực hiện nó.

Vấn đề này rất nghiêm trọng; nó đẩy lùi các kế hoạch ban đầu qua nhiều tuần! Tất nhiên, product owner của chúng tôi đã được thông báo ngay lập tức và cùng với anh ấy, chúng tôi đã lên kế hoạch một lịch trình mới và phát triển các story mới, bao gồm việc tạo ra thư viện API này.

Thông thường vấn đề của bạn sẽ nhỏ hơn nhiều. Mọi người có thể bị mắc kẹt với vài logic phức tạp hơn, nhưng, nhiều lúc vào sáng hôm sau, họ đã có ý tưởng và giải pháp. Những lần khác, họ chỉ đơn giản là đi trật hướng và một thành viên trong nhóm sẽ cần giúp họ trở về đúng hướng. Đây là những vấn đề điển hình của bạn.


Tổng kết

Ở đây chúng tôi đang ở phần kết thúc. Ít nhất, đây là cách đội ngũ của tôi bắt đầu với Scrum. Một số quy tắc rất hữu ích; một số khác thì ít hơn. Hơn nữa, vài quy tắc chỉ hữu ích trong một thời gian ngắn, trong khi những quy tắc khác vẫn được đội ngũ của chúng tôi tuân thủ.

Tôi chỉ có thể khuyên bạn nên nắm lấy quy trình của Agile, thử Scrum và đưa ra kết luận của riêng bạn. Tôi bảo đảm bạn sẽ tìm thấy nhiều cách thức để áp dụng cho đội ngũ của mình. Hãy dùng agile, thích nghi nó với phong cách làm việc của bạn, cho các dự án và tính cách của bạn, và đừng sợ bổ sung các quy tắc của riêng bạn.

Sau tất cả thì Agile đề cập đến sự thích nghi, không mù quáng tuân theo một tập hợp quy tắc được xác định trước!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.