Agile, Scrum là gì phần 1?

I. Giới thiệu

• Trong các dự án, đặc biệt là các dự án phần mềm chúng ta sẽ gặp rất nhiều khó khăn trong việc thu thập đầy đủ và chính xác các yêu cầu của sản phẩm để lập kế hoạch tốt ngay từ đầu. Có quá nhiều vấn đề gây ảnh hưởng đến việc phát triển phần mềm. Trong khi đó có quá nhiều vấn đề mà chúng ta không lường trước được. Những vấn đề này có thể đến từ những yếu tố như kinh doanh, kỹ thuật, con người ....
• Trong giai đoạn những năm 1990 trên thế giới xảy ra cuộc khủng hoảng của quá trình phát triển phần mềm. Những phương pháp phát triển phần mềm theo cách truyền thống ngày càng bộc lộ nhiều nhược điểm và tỷ lệ các dự án thật bại cao. Từ đó các cá nhân và công ty riêng lẻ đã đưa ra các phương pháp phát triển phần mềm khác nhau để thích ứng với tình hình mới khiến cho phương pháp phát triển truyền thống đã không còn phù hợp
• Những phương thức phát triển phần mềm này giúp phần nào giải quyết được một số vấn đề nhưng lại nảy sinh vấn đề khác về sự chia sẻ, cộng tác, kỹ thuật, công cụ, hướng phát triển .... Do vậy năm 2001, nhóm 17 người có uy tín trong nghề phát triển phần mềm thời điểm đó đã gặp nhau và đi đến thống nhất cho ra đời một bản tuyển ngôn Agile:
  • Cá nhân và sự tương tác hơn là quy trình và công cụ
  • Phần mềm chạy tốt hơn là tài liệu đầy đủ
  • Cộng tác với khách hàng hơn là đàm phán hợp đồng
  • Phản hồi với sự thay đổi hơn là bám theo kế hoạch
• Bên cạnh đó Agile đưa ra 12 nguyên tắc thực tiễn dựa vào đó ta có thể thực hiện đúng theo tôn chỉ của Agile
  • Thoả mãn yêu cầu của khách hàng thông qua việc giao sản phẩm sớm và liên tục
  • Chào đón việc thay đổi yêu cầu, thậm chí là những thay đổi yêu cầu muộn
  • Giao phần mềm chạy được cho khách hàng một cách thường xuyên (giao hàng tuần hơn là hàng tháng)
  • Nhà kinh doanh và người phát triển phải cùng nhau làm việc hàng ngay trong suốt dự án
  • Các dự án được xây dựng xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc
  • Trao đổi trực tiếp mặt đối mặt là phương pháp hiệu quả nhất để truyền đạt thông tin
  • Phần mềm chạy được là thước đo chính của tiến độ
  • Phát triển bền vững và duy trì được nhịp độ phát triển liên tục
  • Liên tục quan tâm đến kĩ thuật và thiết kế để cải tiến sự linh hoạt
  • Sự đơn giản là cần thiết – nghệ thuật tối đa hóa lượng công việc chưa hoàn thành
  • Thích ứng thường xuyên với sự thay đổi
• Scrum được xây dựng dựa trên lý thuyết quản lý tiến trình thực nghiệm (empirical process control), hay “thực nghiệm luận” (empiricism). Lý thuyết này chỉ ra rằng tri thức đến từ kinh nghiệm và việc ra quyết định được dựa trên những gì đã biết. Scrum sử dụng các tiếp cận lặp (iterative), tăng trưởng (incremental) để tối ưu hóa tính khả đoán (predictability) và kiểm soát rủi ro.
• Ba yếu tố nòng cốt tạo thành một mô hình quản lý tiến trình thực nghiệm gồm: sự minh bạch (transparency), thanh tra (inspection) và thích nghi (adaptation)
• Minh bạch Các khía cạnh quan trọng của tiến trình phải được hiển thị rõ ràng cho những người có trách nhiệm với thành quả của tiến trình đó. Sự minh bạch yêu cầu các yếu tố này cần được định nghĩa theo một tiêu chuẩn để những người quan sát có thể hiểu những gì họ thấy theo cùng một cách.
• Thanh tra Người sử dụng Scrum phải thường xuyên thanh tra các tạo tác và tiến độ đến đích để phát hiện các bất thường không theo ý muốn. Tần suất thanh tra không nên quá dày để khỏi ảnh hưởng đến công việc. Công tác thanh tra có ích nhất khi được thực hiện bởi người có kĩ năng tại các điểm quan trọng của công việc.
• Thích nghi Nếu một người thanh tra xác định được rằng có vấn đề nào đó vượt quá giới hạn cho phép và hậu quả của vấn đề đó đối với sản phẩm là không thể chấp nhận được, thì quy trình hoặc các vật liệu được xử lý (processed material) phải được điều chỉnh. Sự điều chỉnh phải được tiến hành càng sớm càng tốt để giảm thiểu các sai sót khác có thể xảy ra

1. Nhóm Scrum

• Nhóm Scrum bao gồm Product Owner (Chủ Sản phẩm), Development Team (Nhóm phát triển) và Scrum Master. Các Nhóm Scrum là các nhóm tự quản (self-organizing) và liên chức năng (cross-functional). Các nhóm tự quản tự mình chọn cách thức tốt nhất để hoàn thành công việc của họ, chứ không bị chỉ đạo bởi ai đó bên ngoài nhóm. Các nhóm liên chức năng có đủ kĩ năng cần thiết để hoàn thành công việc mà không phụ thuộc vào bất kì người ngoài nào khác. Mô hình nhóm trong Scrum được thiết kế để tối ưu hóa sự linh hoạt, sáng tạo và năng suất

  • Product Owner Product Owner (Chủ sản phẩm) chịu trách nhiệm tối đa hóa giá trị của sản phẩm và công việc của Nhóm Phát triển. Cách thức để đạt được điều đó có thể rất khác nhau giữa các tổ chức, các Nhóm Scrum và các cá nhân.

    Product Owner là một người chủ yếu chịu trách nhiệm về việc quản lý Product Backlog. Đây là công cụ quản lý chứa

    • Mô tả các hạng mục Product backlog
    • Trình tự của các hạng mục trong Product Backlog để đạt được mục đích và hoàn thành các nhiệm vụ
    • Sự đảm bảo giá trị của các công việc của Nhóm Phát triển
    • Sự đảm bảo cho Product Backlog là luôn luôn hiện hữu, thông suốt và rõ ràng tới tất cả mọi người và chỉ ra những gì mà Nhóm Scrum sẽ làm việc
    • Sự đảm bảo cho Nhóm Phát triển hiểu rõ các hạng mục trong Product Backlog với các mức độ cần thiết
    • Product Owner có thể tự mình thực hiện công việc trên hoặc để Nhóm Phát triển làm. Tuy nhiên, Product Owner vẫn phải chịu trách nhiệm chính.

    Product Owner là một người, không phải là một ủy ban. Product Owner có thể cần tới một ủy ban tham gia vào Product Backlog, nhưng những người trong ủy ban muốn thay đổi trình tự các hạng mục trong Product Backlog phải thuyết phục được Product Owner.

    Để Product Owner thành công, cả tổ chức phải tôn trọng các quyết định của người này. Các quyết định đó được hiển thị trong nội dung và thứ tự trong Product Backlog. Không ai ngoài Product Owner được phép yêu cầu Nhóm Phát triển làm gì khác và Nhóm Phát triển cũng không được phép làm gì theo lời bất cứ người nào khác.

  • Development Team Nhóm Phát triển (Development Team) gồm các chuyên gia làm việc để cho ra các phần tăng trưởng có thể phát hành được (potentially releasable) cuối mỗi Sprint. Chỉ các thành viên của Nhóm Phát triển mới tạo ra các phần tăng trưởng này (Increment). Nhóm Phát triển được cấu trúc và trao quyền để tổ chức và quản lý công việc của họ. Sự hợp lực sẽ tối ưu hóa nỗ lực và hiệu quả tổng thể của Nhóm Phát triển. Nhóm Phát triển có các đặc trưng sau:

    • Đó là nhóm tự tổ chức. Không ai (kể cả Scrum Master) có quyền yêu cầu Nhóm Phát triển làm thế nào để chuyển Product Backlog thành các phần tăng trưởng có thể chuyển giao được
    • Đó là nhóm liên chức năng, với tất cả các kĩ năng cần thiết để tạo ra phần tăng trưởng của sản phẩm
    • Scrum không ghi nhận một chức danh nào trong Nhóm Phát triển ngoài Nhà phát triển (Developer), theo tính chất công việc của người này, không có ngoại lệ cho quy tắc này
    • Các thành viên Nhóm phát triển có thể có các kĩ năng chuyên biệt và các chuyên môn đặc thù, nhưng họ phải chịu trách nhiệm dưới một thể thống nhất là Nhóm Phát triển
    • Nhóm Phát triển không chứa các nhóm con nào khác với các chức năng đặc thù như nhóm kiểm thử hay phân tích nghiệp vụ.

    Độ lớn tối ưu của Nhóm Phát triển là đủ nhỏ để giữ được sự linh hoạt và đủ lớn để hoàn thành công việc. Ít hơn ba người có thể làm giảm sự tương tác và dẫn đến năng suất thấp. Các Nhóm Phát triển nhỏ hơn có thể phải đối mặt với các ràng buộc kĩ năng trong suốt Sprint, dẫn đến Nhóm Phát triển khó có thể chuyển giao gói tăng trưởng phát hành được. Một nhóm nhiều hơn chín người cần nhiều sự điều phối hơn.

  • Scrum Master

    • Scrum Master chịu trách nhiệm đảm bảo mọi người hiểu và dùng được Scrum. Scrum Master thực hiện việc này bằng cách đảm bảo Nhóm Scrum tuân thủ lý thuyết, các kĩ thuật thực hành và các quy tắc của Scrum.
    • Scrum Master là một lãnh đạo, nhưng cũng là người phục vụ Nhóm Scrum. Scrum Master giúp đỡ những người ngoài Nhóm Scrum hiểu cách phải tương tác với nhóm sao cho hiệu quả nhất.
    • Scrum Master giúp đỡ tất cả mọi người cải tiến các mối tương tác để tối đa hóa giá trị mà

    Scrum Master phục vụ Product Ower theo nhiều cách, bao gồm:

    • Tìm kiếm các kĩ thuật để quản lý hiệu quả Product Backlog
    • Giao tiếp tích cực với Nhóm Phát triển về tầm nhìn, mục đích và các hạng mục của Product Backlog
    • Huấn luyện cho Nhóm Phát triển biết cách tạo ra các hạng mục Product Backlog thật rõ ràng và đơn giản
    • Hiểu rõ việc lập kế hoạch dài hạn sản phẩm trong một môi trường thực nghiệm
    • Hiểu rõ và thực hành sự linh hoạt (agility)
    • Thúc đẩy các sự kiện Scrum theo yêu cầu hoặc khi cần thiết

    Scrum Master phục vụ gì cho Nhóm Phát triển? Scrum Master phục vụ Nhóm Phát triển theo nhiều cách, bao gồm:

    • Huấn luyện Nhóm Phát triển cách tự tổ chức và làm việc liên chức năng
    • Giúp đỡ Nhóm Phát triển để tạo ra các sản phẩm có giá trị cao
    • Loại bỏ các trở lực trong quá trình tác nghiệp của Nhóm Phát triển
    • Thúc đẩy các sự kiện Scrum theo yêu cầu hoặc khi cần thiết
    • Huấn luyện Nhóm Phát triển trong trường hợp tổ chức chưa có hiểu biết và ứng dụng đầy đủ về Scrum