Phương pháp Lean Agile trong hành động

Ví dụ về Cổng thông tin sinh viên

Một trường cao đẳng cộng đồng muốn phát triển một cổng thông tin sinh viên nhằm cung cấp các dịch vụ trực tuyến cho sinh viên. Họ đã mời một đại diện sinh viên, nhân viên từ bộ phận và các thành viên của nhóm quản trị cổng thông tin để thành lập một nhóm tham gia vào dự án phát triển cổng thông tin sinh viên. Dưới đây là nội dung trích từ cuộc họp đầu tiên.

Cuộc họp với các bên liên quan

Chương trình họp

• Gợi ý các tính năng cho cổng thông tin sinh viên
• Thảo luận về tính khả thi của danh sách tính năng đề xuất
• Ưu tiên các tính năng cần triển khai như cốt lõi, đợt tiếp theo, nên có…

Steve (Đội Phát triển): Chào mừng… Chúng tôi mong muốn cuộc họp sẽ mang lại hiệu quả và kết quả tốt hơn. Khi bạn đề xuất các tính năng mong muốn, chúng ta có thể sử dụng định dạng sau như cách chuẩn để diễn đạt: ai (bạn là ai), tính năng gì (bạn muốn), và (tại sao bạn muốn)… Những tính năng này sẽ được ghi lại dưới dạng các câu chuyện người dùng (user stories) như công cụ giao tiếp trong suốt dự án này.

Sau đó, chúng tôi đã thảo luận và tạo ra một danh sách các câu chuyện người dùng từ các bên liên quan khác nhau:

Đại diện sinh viên: đăng ký môn học, thanh toán học phí, xem lịch học, chỉnh sửa lịch học, xem bảng điểm, bỏ môn học…

Đại diện học thuật: thêm thông tin môn học, chỉnh sửa thông tin môn học, xóa thông tin môn học…

Quản trị viên cổng thông tin: sao lưu thông tin môn học, chỉnh sửa trạng thái tài khoản sinh viên

Bây giờ, chúng tôi có một đống thẻ có thể được sắp xếp thành các hàng và cột

Ưu tiên các tính năng đề xuất

Đại diện phát triển: Chúng tôi đã có danh sách các câu chuyện người dùng được ưu tiên để triển khai trong vòng lặp tiếp theo. Để làm điều này, chúng ta cần đi sâu vào từng câu chuyện người dùng để hiểu rõ và thu thập thêm thông tin. Hãy cùng đi qua câu chuyện người dùng cốt lõi đầu tiên: ‘đăng ký môn học’

Chúng tôi nhận được một số thông tin bổ sung sau từ người dùng cuối trong cuộc họp:

• Học thuật: sinh viên phải là sinh viên chính quy đã đăng ký
• Quản trị: sinh viên phải cung cấp thông tin đăng nhập chính xác để đăng nhập
• Học thuật: môn học chưa đầy
• Học thuật: các điều kiện tiên quyết của môn học phải được đáp ứng
• Quản trị: một môn học được chọn để thêm vào lịch học không được xung đột với khung thời gian của môn học khác
• Nhà phát triển: bạn muốn những tính năng nào khác được nhóm lại cùng với tính năng này thành một danh sách trong hệ thống mục tiêu?
• Sinh viên: bỏ môn học, xem lịch học, chỉnh sửa lịch học.

Ba yếu tố C của câu chuyện người dùng

Các câu chuyện người dùng tốt không chỉ đơn thuần là những tuyên bố. Một câu chuyện người dùng chuẩn gồm ba phần, thường được gọi là ba yếu tố C. Yếu tố C đầu tiên của mỗi câu chuyện người dùng nên tuân theo định dạng chuẩn: Là một [vai trò], tôi muốn [làm điều gì đó], để [thu được lợi ích nào], đây là nội dung tối thiểu cần có trong thẻ câu chuyện người dùng. Yếu tố C thứ hai là ‘cuộc thảo luận’ (Conversations), bao gồm nội dung thảo luận giữa người dùng cuối, chủ dự án và đội phát triển, ghi lại các cuộc trao đổi bằng lời nói hoặc nhiều thông tin hữu ích khác như email, sơ đồ bố trí (wireframes) hoặc bất kỳ nội dung liên quan nào khác cho dự án. Yếu tố C cuối cùng là ‘xác nhận’ (confirmation), là các tiêu chí chấp nhận dùng để xác minh rằng câu chuyện người dùng đã được triển khai đúng và được giao thành công.

Hãy để tôi làm rõ thêm một chút về cách phát triển phần xác nhận của một câu chuyện người dùng. Ở đây, chúng tôi sử dụng mẫu phổ biến nhất được gọi là Gherkin, sử dụng công thức Given-When-Then để hướng dẫn việc viết các bài kiểm thử chấp nhận cho một Câu chuyện Người dùng:

• (Given.. và) một bối cảnh nhất định
• (When.. và) một hành động nào đó được thực hiện
• (Then.. và) Thực hiện một số hành động

Các công cụ như Cucumber và khung thử nghiệm Jbehave khuyến khích việc sử dụng mẫu Given/Then/Then để thực hiện kiểm thử tự động, mặc dù nó cũng có thể được sử dụng thuần túy như một phương pháp heuristics bất kể có hay không sử dụng công cụ.

Hãy cùng thu thập tất cả thông tin cho câu chuyện người dùng “đăng ký khóa học” và sắp xếp theo định dạng 3Cs:

Bây giờ, hãy đưa thông tin vào UeXceler, bao gồm quá trình chuyển đổi và xác nhận mà chúng tôi đã phát triển trước đó.

Chia tách Epic thành các Câu chuyện Người dùng

Nếu chúng ta tìm hiểu sâu hơn về câu chuyện người dùng “đăng ký khóa học”, có thể chúng ta sẽ thấy nó quá lớn để đưa vào một sprint. Chúng ta có thể xem nó như một Epic (câu chuyện người dùng lớn hơn), có thể chia thành một nhóm các câu chuyện người dùng nhỏ hơn liên quan. Chúng ta có thể chia một Epic thành các nhiệm vụ, tôi gọi đó là chia tách ngang, hoặc thay vào đó, chúng ta có thể chia Epic thành các tình huống và gọi là chia tách dọc.

Chia tách ngang

Cách tiếp cận truyền thống để xây dựng một tính năng lớn là phân rã nó thành các công việc cần thực hiện ở các lớp kiến trúc. Ví dụ: mô hình – giao diện – điều khiển (MVC) hoặc kiến trúc khách hàng – máy chủ, nhằm tạo sự tách biệt trách nhiệm cho kiến trúc hệ thống, và sau đó tinh chỉnh nó thành kiến trúc n tầng như: giao diện người dùng (GUI), logic điều khiển, mô hình đối tượng, ánh xạ quan hệ đối tượng, lớp cơ sở dữ liệu và v.v. Có khá nhiều thành phần trong kiến trúc n tầng, và ở đây tôi chỉ liệt kê một vài ví dụ sau:

• Cho phép chúng tôi phát triển chuyên môn cao trong một trong các lớp kiến trúc
• Các ứng dụng khác sẽ có thể tái sử dụng chức năng được công khai bởi các lớp của bạn.
• Bạn có thể phân phối các lớp của mình trên nhiều tầng vật lý. Điều này có thể tạo ra tác động rất tốt đến ứng dụng của bạn bằng cách cải thiện hiệu suất (đôi khi), khả năng mở rộng và độ bền lỗi.
• Việc bảo trì ứng dụng của bạn trở nên dễ dàng hơn nhờ vào sự耦 hợp thấp giữa các lớp.
• Việc thêm nhiều chức năng vào ứng dụng của bạn trở nên dễ dàng hơn.
• Các lớp giúp ứng dụng của bạn dễ kiểm thử hơn.

Có rất nhiều triển khai thành công dựa trên kiến trúc n tầng, chẳng hạn như Ruby on Rails và kiến trúc dựa trên dịch vụ web.

Câu chuyện người dùng và chia tách ngang

Mặc dù có những lợi ích từ kiến trúc n tầng cho hệ thống của chúng ta, nhưng nó cũng có một số nhược điểm khi chúng ta sử dụng nó cùng với phương pháp câu chuyện người dùng. Nó thường dẫn đến vòng phản hồi rất chậm, tùy thuộc vào kích thước của tính năng, vì chúng ta phải chờ tất cả mọi người hoàn thành phần riêng của mình để tích hợp và đảm bảo hoạt động đúng. Thuật ngữ “cắt ngang” (horizontal slicing) đề cập đến việc sử dụng phương pháp lớp kiến trúc này như phương pháp chính để phân rã các tính năng lớn.

Chia tách dọc

Để tăng tốc vòng phản hồi, chúng ta có thể lấy một Epic và chia nhỏ thành nhiều tình huống người dùng, cắt xuyên qua từng lớp kiến trúc. Chúng ta có thể chia nhỏ hầu hết mọi tính năng thành các mảnh sao cho việc xây dựng, tích hợp và kiểm thử tất cả các mảnh chỉ mất tối đa vài ngày. Mỗi mảnh bao gồm bất kỳ công việc nào cần thực hiện trong một lớp kiến trúc, cũng như bất kỳ kiểm thử và tích hợp nào cần thiết để sẵn sàng phát hành.

Thông thường, chia tách ngang chia các tính năng thành các câu chuyện người dùng hoặc nhiệm vụ ở cấp độ thành phần kiến trúc. Ví dụ: giao diện người dùng phía trước, cơ sở dữ liệu hoặc dịch vụ phía sau. Trong khi đó, một mảnh dọc sẽ tạo ra phần mềm hoạt động, có thể minh họa và mang lại giá trị kinh doanh. Do đó, chia tách dọc cải thiện khả năng của đội ngũ để cung cấp một phần tăng trưởng sản phẩm có thể phát hành được trong mỗi sprint. Hãy tưởng tượng cắt một chiếc bánh có các lớp kem, sô cô la, trái cây và bánh. Nếu bạn cắt bánh theo chiều ngang, bạn bè của bạn chỉ nhận được một miếng bánh, sô cô la, kem hoặc trái cây. Tôi chắc chắn rằng bạn bè của bạn sẽ thích một miếng có một chút của tất cả các lớp. Chỉ nhận một lớp bánh sẽ không cho họ cảm nhận được hương vị thực sự của cả chiếc bánh. Một cách tiếp cận thân thiện hơn với bạn bè là tạo ra các mảnh cắt dọc (giá trị mong muốn).

Chia tách Epic theo chiều ngang với mục tiêu

Hãy nhớ lại rằng trong buổi họp với các bên liên quan, chúng tôi đã có quá trình chuyển đổi cho câu chuyện người dùng “đăng ký khóa học”, tính năng này ban đầu được đề xuất bởi sinh viên (vai trò chính) và được các bên liên quan khác hỗ trợ. Khi chúng tôi đi sâu vào chi tiết của câu chuyện người dùng, chúng tôi nhận thấy có khá nhiều thông tin được lưu lại bởi các bên liên quan khác sẽ tham gia vào câu chuyện người dùng với vai trò hỗ trợ.

Trong thực tế, một số sinh viên có thể không quan tâm hoặc thậm chí không muốn các ràng buộc do những người có vai trò hỗ trợ đặt ra. Ví dụ, một sinh viên quên mật khẩu và đã nhập sai ba lần, họ có thể không muốn đi qua quy trình đặt lại mật khẩu, nhưng vẫn tự tin thử lại nhiều lần nữa, hoặc sinh viên không muốn có giới hạn về số lượng sách thư viện, thời gian mượn, v.v. Những người muốn đặt ra một số quy tắc kinh doanh, ràng buộc cho các tính năng được đề xuất như mục tiêu người dùng của họ, chính là những người tham gia với vai trò hỗ trợ trong câu chuyện người dùng. Tính năng không nên hoạt động nếu không có các quy tắc kinh doanh và mục tiêu thứ hai được áp đặt lên tính năng được đề xuất. Nếu chúng ta chia tách Epic theo chiều ngang dựa trên mục tiêu của các nhân tố phụ vào một nhóm câu chuyện người dùng, chúng ta có thể vừa đáp ứng được mục tiêu của các nhân tố phụ, vừa làm cho câu chuyện người dùng có thể kiểm thử và nhận phản hồi trực tiếp từ người phù hợp.

Hãy cùng tìm hiểu thông tin từ các phần chuyển đổi và xác nhận để xem chúng ta có thể chia tách câu chuyện lớn “đăng ký khóa học” thành một nhóm câu chuyện người dùng liên quan như thế nào.

1. Sinh viên phải là sinh viên đã đăng ký, nếu không họ sẽ không có quyền truy cập do thông báo dành cho sinh viên mới. Nếu họ đã nhận được thông báo nhưng tài khoản chưa được kích hoạt, họ cần đăng ký tài khoản mới trực tuyến (được đánh dấu bằng vòng tròn đỏ số 1)
2. Nếu chúng ta tìm hiểu sâu hơn quy trình đăng nhập, chúng ta biết rằng, nếu một sinh viên nhập sai thông tin xác thực ba lần, thì họ cần phải vào quy trình “đặt lại mật khẩu” (được đánh dấu bằng vòng tròn đỏ số 2 & 3)

Kho chứa câu chuyện người dùng chung

Hãy cùng tạo các câu chuyện người dùng này trong UeXceler:

Câu chuyện người dùng Đăng nhập Tài khoản được tạo trong ngăn chứa câu chuyện người dùng chung. Ngoài các câu chuyện người dùng đăng nhập, còn có hai câu chuyện người dùng liên quan khác đang được tạo trong ngăn chứa câu chuyện người dùng chung, đó là “đặt lại mật khẩu” và “Tạo tài khoản sinh viên mới” vì những lý do sau:

• Trong trường hợp nếu sinh viên nhập sai thông tin tài khoản 3 lần liên tiếp, sẽ kích hoạt câu chuyện người dùng “đặt lại mật khẩu”;
• và nếu một sinh viên mới chưa đăng ký tài khoản sinh viên, họ có thể kích hoạt câu chuyện người dùng “Tạo tài khoản sinh viên mới” ngay trên màn hình đăng nhập.

1. Là một sinh viên, tôi muốn đăng nhập vào cổng sinh viên, để…
2. Là quản trị viên cổng, tôi muốn xác minh người đăng nhập là một sinh viên đã đăng ký, để…
3. Là người phụ trách khóa học, tôi muốn xác minh tính phù hợp trước khi cho phép khóa học được chọn được thêm vào lịch học của sinh viên, để…

Chúng ta có thể xem xét ba câu chuyện người dùng này được chia theo chiều ngang từ cốt truyện lớn – “đăng ký khóa học”, nhưng các câu chuyện người dùng này sẽ đáp ứng mục tiêu của một số nhân vật hỗ trợ mà bạn có thể nhận phản hồi và xác nhận. Nếu các điều kiện tiên quyết không được đáp ứng, câu chuyện người dùng chính sẽ hoàn toàn mất ý nghĩa.

Bạn có thể thấy rằng chúng tôi đã đặt tất cả các câu chuyện người dùng này vào ngăn chứa câu chuyện người dùng chung, và lý do là chúng có khả năng chia sẻ cùng một điều kiện tiên quyết với các tính năng (câu chuyện người dùng) liên quan khác trên cùng một trang gọi, chẳng hạn như “xem lịch”, “sửa lịch”, “rút khỏi khóa học” và v.v.

Ngăn chứa trường hợp sử dụng

Có ba phần còn lại được đánh dấu vòng tròn đỏ số 4, 5 và 6 trong hình trên. Chúng là các kịch bản thay thế của cốt truyện lớn “đăng ký khóa học”. Bất kỳ điều kiện nào trong ba điều kiện này bị sai, sẽ có một kịch bản thay thế tương ứng và có thể được biểu diễn dưới dạng câu chuyện người dùng tách ra. Có thể chúng ta có thể chia theo chiều ngang hoặc chiều dọc, nhưng liệu việc chia theo chiều dọc luôn được ưu tiên hơn? Không nhất thiết, điều này thực sự phụ thuộc vào tình huống. Trên thế giới này không có một giải pháp phù hợp với mọi trường hợp, chúng ta cần xem xét phương pháp nào phù hợp hơn với trường hợp của bạn. Hãy để tôi làm rõ thêm một chút.

Ví dụ, nếu bạn định giao câu chuyện người dùng chính cho một nhà phát triển và ba câu chuyện người dùng đăng nhập, đăng ký tài khoản mới và đặt lại mật khẩu cho một nhà phát triển khác. Bạn có thể ưu tiên người phụ trách câu chuyện người dùng chính phát triển kịch bản thành công trước trong sprint hiện tại, rồi lần lượt phát triển các kịch bản thay thế trong các sprint tiếp theo bằng chính nhà phát triển đó (nếu khung thời gian cho phép). Nhưng nếu khung thời gian ngắn và đồng thời bạn cảm thấy quá nặng đối với cùng một nhà phát triển phải đảm nhận toàn bộ cốt truyện lớn, thì bạn có thể chia nhỏ theo chiều ngang thành các nhiệm vụ để phân công cho nhiều nhà phát triển cùng lúc.

Chia nhỏ cốt truyện lớn thành các kịch bản

Nếu chúng ta xem xét chi tiết của kịch bản được mô tả trong phần xác nhận của cốt truyện lớn, chúng ta có thể dễ dàng tìm thấy các mảnh dọc cho một nhóm câu chuyện người dùng liên quan.

1. Là người phụ trách khóa học, tôi muốn xác minh yêu cầu tiên quyết trước khi cho phép khóa học được chọn được thêm vào lịch học của sinh viên, để…
2. Là người phụ trách khóa học, tôi muốn kiểm tra tính sẵn có của khóa học trước khi cho phép khóa học được thêm vào lịch học của sinh viên, để…
3. Là người phụ trách khóa học, tôi muốn xác minh tính sẵn có của khung thời gian của sinh viên trước khi cho phép khóa học được chọn được thêm vào lịch học của sinh viên, để…

Chia nhỏ cốt truyện lớn thành các nhiệm vụ

Nếu chúng ta muốn cốt truyện lớn được phân rã thành các nhiệm vụ nhỏ hơn để phát triển song song trong cùng một sprint như sau:

1. Kiểm tra trạng thái giới hạn số lượng khóa học
2. Kiểm tra yêu cầu tiên quyết của khóa học
3. Kiểm tra khung thời gian

Bây giờ, tùy chọn của bạn để chia nhỏ cốt truyện lớn thành các câu chuyện người dùng cho quá trình phát triển linh hoạt. Bạn có thể thấy câu chuyện người dùng “Đăng ký khóa học” và các câu chuyện người dùng liên quan được đặt trong một ngăn chứa trường hợp sử dụng (cốt truyện lớn) còn được gọi là Đăng ký khóa học, được dùng như một chỗ trống để chứa tất cả các câu chuyện người dùng chính và các câu chuyện người dùng được tách ra từ câu chuyện chính.