Chu trình Agile- Scrum

Phương thức phát triển linh hoạt, còn được gọi là phát triển thích ứng, là các phương pháp tập trung vào các cá nhân nhằm mục miêu làm hài lòng khách hàng thông qua việc thực hiện một phần mềm đầy đủ chức năng trong quá trình sản xuất nó.

Nguyên tắc và các giai đoạn khác nhau

Nguyên tắc của phương pháp SCRUM là phát triển một phần mềm theo cách gia tăng dần thông qua việc bảo trì một danh sách hoàn toàn công khai các yêu cầu phát triển hay sửa chữa cần thực hiện (backlog). Với việc bàn giao diễn ra thường xuyên, thời gian thông thường là 4 tuần, mỗi khi khách hàng nhận phần mềm, đó sẽ là một phần mềm với nhiều tính năng hơn và hoạt động tốt hơn. Để làm được điều này, phương pháp dựa trên các phát triển lặp lại với tốc độ không đổi trong khoảng thời gian từ 2 đến 4 tuần. Việc nâng cấp có thể dễ dàng tích hợp hơn theo chu trình chữ V.

Cụ thể hơn, phương pháp này được trao đổi thông qua 4 hình thức họp bàn :

• Họp hàng ngày : mỗi ngày, toàn đội sẽ tập trung trong vòng 15 phút vào đầu buổi sáng để tổng kết công việc ngày hôm qua, kế hoạch công việc sẽ làm trong ngày hôm nay và kiểm tra các tình huống có thể cản trở công việc trong ngày hôm nay.
• Họp lên kế hoạch : toàn đội sẽ tập trung để quyết định các tính năng cần thực hiện của Sprint sau và cập nhật danh sách chung.
• Họp kiểm tra lại công việc : trong cuộc họp này, mỗi người sẽ trình bày công việc đã làm trong thời gian thực hiện một sprint. Việc chứng minh các tính năng mới hay trình bày kiến trúc sẽ được tổ chức. Đây là một cuộc họp không chính thức kéo dài khoảng 2 giờ với sự tham gia của toàn đội.
• Họp tổng kết : mỗi khi kết thúc một sprint, toàn đội sẽ họp về những tính năng hoạt động tốt và những tính năng chưa tốt. Trong cuộc họp khoảng 15 đến 30 phút này, môi người tham gia sẽ bỏ phiếu để xác định nhưng cải tiến cần có trong giai đoạn tiếp theo.

Ưu điểm của phương pháp này là giảm thiểu tối đa thời gian chuẩn bị tài liệu nhằm nâng cao khả năng sản xuất. Ý tưởng ở đây chính là việc chuẩn bị tài liệu tối thiểu sẽ cho phép lưu lại các quyết định đã đưa ra trong dự án và có thể dễ dàng tham gia vào vào phần mềm khi phần mềm đi vào giai đoạn bảo trì.

Tổ chức

Phương pháp SCRUM đòi hỏi sự tham gia của 3 tác nhân :

• Product owner : Trong phần lớn các dự án, người quản lý sản phẩm (product owner) là người chịu trách nhiệm đội ngũ dự án khách hàng. Đây chính là người sẽ xác định và ưu tiên các danh sách tính năng của sản phẩm và lựa chọn thời gian, nội dung của mỗi sprint trên cơ sở các giá trị (trách nhiệm) mà đội ngũ trao đổi với họ.
• ScrumMaster : là người hỗ trợ đắc lực cho dự án, ScrumMaster là người kiểm tra công việc mà mỗi người có thể làm hết khả năng thông qua việc loại bỏ các hạn chế và tránh cho toàn đội những vấn đề cản trở từ bên ngoài. ScrumMaster cũng giám sát đặc biệt việc tuần thủ các giai đoạn khác nhau của phương pháp Scrum.
• Đội ngũ : thông thường với quy mô từ 4 đến 10 người, đội ngũ tập trung các kỹ sư có vai trò cần thiết trong một dự án, đó là kỹ sư kiến trúc, thiết kế, lập trình, kiểm thử… Đội ngũ tự tổ chức công việc và không thể thay đổi trong toàn bộ thời gian của một sprint.

Ưu điểm 

Phương pháp Scrum khác với các phương pháp phát triển khác nhờ vào những ưu điểm khiến cho phương pháp này trở thành câu trả lời hiệu quả cho những hạn chế hiện hành của các nhà quản lý sản phẩm :

• Phương pháp lặp lại và gia tăng : cho phép tránh “hiệu ứng đường hầm” nghĩa là chỉ thấy được kết quả khi giao hàng kết thúc và mà không thể hay hầu như không thể thấy trong giai đoạn phát triển, thường xuất hiện trong việc phát triển theo chu trình chư V.
• Thích ứng tối đa cho phát triển sản phẩm và ứng dụng : việc kết hợp hàng loạt nội dung của các sprint cho phép thêm sự thay đổi hay một tính năng không được dự báo trước lúc bắt đầu. Đó chính là các yếu tố làm nên phương pháp “linh hoạt”.
• Phương pháp tham gia : mỗi thành viên của nhóm sẽ được mời trình bày và có thể tham gia vào các quyết định đưa ra trong dự án. Điều này khiến các thành viên tham gia đóng góp và trpr nên tích cực hơn.
• Tăng cường giao tiếp : làm việc trong cùng một phòng để phát triển hay kết nối thông qua các phương tiện giao tiếp khác nhau, đội ngũ có thể dễ dàng giao tiếp và trao đổi về những trở ngại gặp phải để loại bỏ chúng nhanh chóng.
• Tối đa hóa hợp tác : trao đổi hàng ngày giữa khách hàng và đội ngũ Pentalog cho phép hai bên hợp tác tốt hơn và giúp đỡ lẫn nhau.
• Tăng năng lực sản xuất : bằng cách loại bỏ một số “khó khăn” của các phương pháp truyền thống như việc chuẩn bị tài liệu hay đào tạo quá nhiều, phương pháp SCRUM cho phép tăng năng lực sản xuất của đội ngũ. Thông qua việc thêm vào phương pháp này việc đánh giá mỗi mô đun cho phép xác định thông qua số liệu, từ đó mỗi người có thể xác định được năng suất trung bình của toàn đội.

Rủi ro và giải pháp 

Phương phápScrum không hoàn toàn là một giải pháp lý tưởng cho mọi vấn đề cố hữu trong việc phát triển phần mềm tin học. Chúng ta luôn cần phải tỉnh táo trước những rủi ro sau, tuy nhiên những rủi ro này vẫn có phản ứng hệ thống được rút ra từ biện pháp ngoại suy của phương pháp :

• Quy mô đội ngũ : trung bình giới hạn từ 7 đến 10 người, quy mô đội ngũ có thể là một trở ngại nếu nó vượt quá số lượng đề xuất này. Việc tổ chức các cuộc họp sẽ không khả thi và nền tảng của phương pháp này trở nền suy yếu. Giải pháp chính là việc thực hiện phương pháp Scrum của Scrum. Đây chính là việc chia tách dự án thành đội ngũ theo quy mô đề xuất và thêm vào một cấp cao hơn gồm các ScrumMaster của mỗi nhóm Scrum.
• Số lượng yêu cầu nhiều : số yêu cầu có thể đến từ nhiều kênh của dự án và đôi khi có thể khó quản lý vì các khía cạnh khác nhau của chúng. Ở mức độ nhận giao hàng, những mâu thuẫn này có thể làm chậm quá trình xác nhận. Để khắc phục vấn đề này, bắt buộc phải sử dụng công cụ duy nhất quản lý các yêu cầu, một công cụ chuẩn cho mọi dự án cả Pentalog.
• Chất lượng phát triển : số lượng đội ngũ càng tăng, chất lượng càng khó kiểm soát. Điều này hoàn toàn đúng khi dự án được triển khai tại nhiều chi nhánh. Các rủi ro đặc biệt liên quan đến chất lượng code và số lượng khiếm khuyết được xác định tại thời điểm tích hợp. Vì thế, điều quan trong là cần phải có một chính sách chất lượng nghiêm ngặt và kế hoạch chất lượng dự án xác định chính xác các quy tắc dự án. Việc kiểm tra code thường xuyên và việc thiết lập các chỉ tiêu đánh giá năng lực của các lập trình viên cho phép giảm thiểu rủi ro này.

Hình thức tổ chức này danh cho ai?

Hình thức tổ chức này có thể sử dụng trong phần lớn các dự án. Tuy nhiên, nó đặc biệt phù hợp với các dự án không có phạm vi chặt chẽ mà theo đó khách hàng mong muốn được theo dõi và đánh giá, một sự tham gia rất quan trọng trong chu trình phát triển.

Phương diện “sẵn sàng” từ phía khách hàng là tiêu chi xác định trong việc lựa chọn phương pháp phát triển này. Thật vậy, chúng tôi đánh giá thời gian thực hiện tương đương với thời gian cần thiết cho người quản lý sản phẩm nhằm đáp ứng các yêu cầu của phương pháp này: chuyển giao một vài hoạt động của trưởng dự án theo phương pháp cổ điển sang người quản lý sản xuất (khoảng cách giữa các đội và nhu cầu).

Techtalk via pentalog