Thay đổi trong chốc lát: Thiết kế Agile

Làm sao để có những trải nghiệm tuyệt vời. Hãy nghĩ đến nhà hàng yêu thích của bạn, nội thất trong chiếc xe hơi, hay những phần mềm trong điện thoại. Làm sao con người có thể tạo ra những trải nghiệm như thế. Chúng ta cần phải xem xét những chi tiết nào, thiết kế ra sao, lập kế họach như thế nào? Liệu có thể tạo ra những trải nghiệm tuyệt vời nếu bạn không hình dung ra được bản thiết kế hoàn chỉnh trước khi bạn bắt đầu?

Đó là một trường hợp hay gặp trong việc thiết kế ra những trải nghiệm người dùng trong giới hạn của phát triển phần mềm agile. Là một nhà thiết kế, làm sao bạn có thể đáp ứng được trong một môi trường liên tục thay đổi. Bài viết này sẽ giới thiệu sơ qua với các bạn về mô hình Agile và cho bạn một vài tips cho các nhà thiết kế trong môi trường như vậy.

Phát triển thông qua Agile

Thông thường, các trào lưu hướng tới Agile là một phản ứng với suy nghĩ về ngành công nghiệp phần mềm như là một công việc nặng nề, chậm chạp và cồng kềnh. Đặc biệt hơn, Agile là một phong trào để chống lại mô hình phát triển phần mềm thác nước (waterfall model). Ở đó việc thiết kế chiếm vai trò quan trọng và cần phải có trước khi phát triển. Với việc sử dụng mô hình waterfall, người ta sẽ bàn giao phần mềm trong cuối quá trình phát triển. Vấn đề là việc phát triển có thể bị trì hoãn, tốn nhiều tiền hơn dự đoán, hoặc là không còn thích hợp khi phần mềm được hoàn thành.

Agile được hình thành như là một phương pháp thay thế để có được sản phẩm có giá trị qua việc bàn giao từng phần nhỏ. Thông thường, phương pháp phát triển Agile diễn ra thông qua các chu kỳ lặp đi lặp lại được xác định trước, thường là từ 1 đến 2 tuần. Vào cuối mỗi lần lặp, một khách hàng sẽ xác định tập hợp các yêu cầu, gọi là các Story, cần được bàn giao. Mỗi 1 story sẽ có một vòng đời của riêng mình ( thông thường là ở backlog, đang phát triển (in-process), xem xét (review), và đợi đi vào sản xuất (production queue), và liên tục được xếp thứ tự ưu tiên bởi khách hàng. Điều đó có nghĩa là các yêu cầu có thể thay đổi thường xuyên trong suốt quá trình phát triển.

Trong quá trình phát triển, tái cấu trúc diễn ra liên tục để chắc chắn rằng các tính năng gắn kết tốt với nhau để tạo ra một ứng dụng hoàn chỉnh. Lợi ích chính của Agile là có thể bàn giao được các phần mềm chạy tốt một cách nhanh chóng, và nó cho phép sự thay đổi về yêu cầu trong suốt quá trình phát triển. Là một nhà thiết kế bạn có thể tự hỏi làm cách nào (hoặc tại sao) lại cho phép thay đổi yêu cầu. Bởi vì không hề có những thiết kế lớn được tạo ra trước đó, các nhà phát triển phần mềm có thể bắt đầu với những tính năng đơn giản cho khách hàng, và điều đó mang lại giá trị trực tiếp.

Mặc dù điều này có thể dẫn đến một cuộc thảo luận lớn là làm sao xác định được ‘giá trị’ cho khách hàng trong trường hợp này. Tôi đặc biết muốn nhấn mạnh từ phần mềm ‘hoạt động’ thay cho phần mềm ‘lý thuyết’.Trong quá trình phát triển Agile, thay đổi không những được phép mà còn được kỳ vọng. Giả sử rằng hiện tại bạn được giao nhiệm vụ tạo ra một ứng dụng du lịch cho mobile. Khách hàng muốn người dùng có thể browse các điểm đến, viết đánh giá và book chuyến đi. Với Agile, ta có thể hoàn toàn bàn giao sản phẩm với một và tính năng nhỏ gần như tức thì. Hơn nữa, bởi vì kích thước của mỗi tính năng là nhỏ, một bản thiết kế lớn có thể là không cần thiết.

Tuy nhiên, ta có thể bàn giao cho khách hàng một sản phẩm hoạt động được trong bất cứ thời điểm nào của quá trình phát triển. Điều quan trọng là phải làm rõ rằng việc bàn giao sản phẩm trước khi sản phẩm cuối được hoàn thiện, thì sản phẩm đó có thể không giải quyết được hết các vấn đề mà lẽ ra nó cần phải giải quyết.

Việc phân phối này sẽ cho phép khách hàng có thể nhìn thấy quá trình phát triển và có thể chỉ đạo được quá trình phát triển theo cách họ thấy phù hợp. Sử dụng phương pháp này cho phép quá trình phát triển có thể thích ứng với sự thay đổi về nhu cầu, ngân sách, cũng như trong nghề nghiệp của khách hàng. Không những thế nó có tiềm năng để phát triển ra những thứ mới, ví như một khái niệm hoàn toàn mới.

Vấn đề với phương pháp này việc cho phép sự thay đổi liên tục có thể dẫn đến việc các tính năng có thể không hoạt động trùng khớp với nhau. Và rất hiếm khi có thời gian để tạo ra một thiết kế hoàn thiện hướng tới người dùng. Là một nhà thiết kế, làm sao bạn có thể tạo ra những trải nghiệm cho người dùng trong môi trường như thế. Chúng ta hãy dành một chút thời gian để kiểm tra một vài vấn đề mới nổi cũng như một số giải pháp để làm việc trong lĩnh vực thay đổi liên tục và khó dự đoán.

Thiết kế mà không có bản thiết kế trước

Bạn càng sớm hiểu thực tế về việc sẽ không có bản thiết kế trước thì càng tốt. Bởi vì trong môi trường Agile, thật khó để có những thiết kế mang tính trung thực cao trước quá trình phát triển. Ngoại lệ duy nhất có thể là khi các hướng dẫn về style hoặc branding được xác định rõ ràng. Ngay cả khi đó, bạn vẫn có thể lãng phí thời gian của mình cũng như của khách hàng khi bạn tạo ra một thiết kế có độ trung thực cao mà sau đó yêu cầu lại bị thay đổi.

Mặc dù có thể bạn sẽ không có cơ hội để tạo ra một thiết kế lớn trước quá trình phát triển, ta có thể tận dụng lợi thế của thời gian ngắn ngủi ngay trước quá trình phát triển được bắt đầu (được gọi là lần lặp số 0). Tại thời gian này, hãy cố gắng thực hiện được càng nhiều công việc nền tảng càng tốt. Nếu bạn thực sự may mắn có được sự tiếp xúc trực tiếp với khách hàng, hãy hỏi thật nhiều câu hỏi trong thời gian này. Những gì họ hình dung? Đâu là những tính năng mà họ hướng đến? Đâu là những tính năng lý thuyết được giới thiệu? Tại sao họ lại xây dựng ứng dụng này? Ai là người sử dụng?Kịch bản lý tưởng là gì? Những thông tin này có thể giúp bạn tránh được những công việc làm lại (rework) và cụt đường trong thiết kế.

Đáp ứng với các biến đổi

Quá trình phát triển có thể bị thay đổi bất cứ lúc nào. Điều này có thể gây ra thất vọng nếu như những ý tưởng mới khác biệt quá xa so với những ý tưởng ban đầu. Trở lại với ứng dụng du lịch và giả định rằng sau khi sử dụng tính năng đầu tiên, khách hàng muốn bỏ đi tính năng viết đánh giá, thay vào đó là tính năng gửi tin nhắn đến những người dùng khác.

Làm sao bạn phản ứng với vấn đề này? Có thể rất thất vọng, nhưng bạn hãy nhắc nhở mình về các yêu cầu và nhu cầu hiện tại của khách hàng. Thêm vào đó, bạn cần phải chia tách và bỏ đi những gì không cần thiết. Thỉnh thoảng, điều đó có nghĩa là bỏ đi những thứ mà bạn phải mất công cả ngày để tạo ra. Hãy nghĩ rằng điều đó là bình thường.

Giữ cho thiết kế đơn giản

Có thể chúng ta không biết chân trời ở đâu, hãy giữ cho tất cả các giải pháp và thiết kế càng đơn giản càng tốt. Hãy giảm các vấn đề xuống đến mẫu số chung thấp nhất, và chỉ tạo ra những thứ cần thiết, không hơn, không kém. Những hệ thống như vậy không những duy trì dễ dàng hơn, mà chúng cũng có thể giúp bạn tiết kiệm thời gian trong trường hợp có sự thay đổi, thêm hay bớt.
Các giải pháp đơn giản và nhanh chóng có thể là tất cả những gì cần thiết. Có nghĩa là tìm đến sự hoàn hảo đến từng chi tiết. Điều này không có nghĩa là từ bỏ quan điểm của bạn trên toàn bộ ứng dụng. Ngược lại, đôi khi thời gian quan trọng nhất để xem xét các thiết kế cao cấp là khi bạn đang tạo ra một giải pháp cụ thể. Trong bất kỳ trường hợp nào, hãy đáp ứng phù hợp trong phạm vi của các stories, các tính năng và trong quá trình lặp.

Duy trì sự nhất quán thông qua phát triển

Mặc dù thiết kế hoàn chỉnh không được tạo ra, điều quan trọng là phải hiểu được tính nhất quán và tương thích. Là nhà thiết kế, thách thức lớn nhất có thể là phải đảm bảo rằng tất cả các phần được triển khai hoạt động phù hợp với nhau thành một thể thống nhất. Vấn đề về triển khai có thể là một rào cản, thiết kế của bạn đối với một tính năng có thể hoàn thành ngay lập tức, nhưng do sự nhanh chóng trong agile, nó không được triển khai một cách đầy đủ. Vì điều này, hãy nhớ rằng quan trọng là phải xem xét lại tất cả các story trong toàn bộ quá trình lặp.

Ngoài ra, đôi khi thiết kế cho các chức năng được thực hiện tốt, nhưng thiết kế cho toàn bộ ứng dụng lại có cảm giác rời rạc.
Để tránh điều này, hãy thử tạo ra một sơ đồ dòng chảy thấp (low-fidelity task flow digram) hoặc phác thảo để ghi nhớ làm sao tất cả đều phù hợp. Nó không chỉ tạo cho bạn một số ý tưởng về bối cảnh và định hướng, nó cũng cung cấp cho các nhà phát triển định hướng ngay lập tức nếu cần thiết.

Đôi khi, cũng là cần thiết để ra khỏi dòng chảy lặp và kiểm tra lại toàn bộ hệ thống xem nó có đồng nhất không. Liệu các components có phù hợp với nhau? Nếu không, tại sao? Trong khi bạn làm việc với những vấn đề có thể xảy ra, hãy ghi nhớ về giới hạn (scope) của một quy trình lặp và bàn giao (deliverable). Tái cấu trúc cho mục đích nhất quán là tốt, nhưng nó cũng khiến cho đội phát triển phải hoạt động chậm lại. Bạn cần phải có những sự chuẩn bị và kế hoạch cho những điều này. Hãy cố tạo ra những stories cho việc review và cập nhật trải nghiệm người dùng cho sản phẩm của bạn.

Tránh các bẫy xoáy thiết kế

Là nhà thiết kế, đôi khi việc khó khăn nhất là làm sao dừng việc thiết kế lại. Quan trọng là phải nhớ đến giới hạn và tốc độ trong Agile. Có nghĩa là đôi khi thiết kết của bạn không phải là hoàn hảo đến từng chi tiết. Điều đó cũng không sao. Chỉ cần có thể giao tiếp với đội phát triển rằng mọi thứ nên hoạt động như thế nào. Một trong những chiến lược cho điều này là viết lên bảng trắng, chia sẻ với những nhà thiết kế khác và đội phát triển. Điều này cho phép các ý tưởng của bạn nhanh chóng được giao tiếp và cho phép các ý tưởng đó được kỹ thuật hóa với tất cả các giải pháp hoặc tính năng bạn đang xem xét. Hãy thử vẽ thật nhiều màn mình và giao diện.

Xem xét dự án của bạn

Mặc dù phát triển Agile rất nhanh chóng, hãy luôn tập trung vào người sử dụng, khách hàng, con người, hoặc hình dung ra những người có thể sử dụng sản phẩm của bạn. Điều quan trọng là phải hình dung ra ai sẽ là người sử dụng ứng dụng này? Họ sử dụng nó như thế nào? Ở đâu và trong hoàn cảnh nào.

Hãy ghi nhớ điều này và giúp những người khác hiểu dự án của bạn. Hãy luôn tự hỏi, liệu sản phẩm là một thành công. Điều đó rất đơn giản. Khách hàng có happy không? Người sử dụng có happy không? Mặc dù là chủ quan, nhưng đôi khi đó là thước đo duy nhất cho những nỗ lực của bạn.

Điều cuối cùng

Thiết kế trong Agile có thể là một thử thách, nhưng cũng không phải tất cả đều xấu. Agile cho phép một dòng phản hồi nhất quán từ phía khách hàng. Vì tính năng này được phát hành mỗi quá trình lặp, bạn có thể có cái nhìn sâu sắc, liên tục đối với việc thiết kế của bạn được sử dụng như thế nào và được hiểu ra làm sao. Mặc dù nó không thay thế cho kiểm thử người dùng theo cách truyền thống, việc demo cho khách hàng luôn cung cấp những phản hồi nhất định.

Theo cách nào đó, Agile có thể là một sân tập tuyệt vời cho nhà thiết kế bởi vì nó cung cấp một cơ hội để tạo ra những giải pháp nhỏ gọn, dễ quản lý hơn với một chu kỳ phản hồi nhanh chóng. Đối với một số người, việc tao ra những thiết kế hướng người dùng hiệu quả và đáng nhớ trong một môi trường nhanh và hay thay đổi có vẻ khó khăn. Đôi khi, thách thức này lại mang đến niềm vui và thú vị.

Điều quan trọng cần lưu ý là không có một phương pháp nào hoặc một quá trình nào gọi là tốt nhất. Cũng như sự tương tác của con người và các mô hình, chúng ta vẫn còn đang tìm hiểu và điều tra. Tuy nhiên, một khi bạn tích cực xem xét người dùng cuối và luôn nghĩ rằng mình đang thiết kế cho họ, bạn sẽ làm tốt mà thôi.

TạpChíLậpTrình dịch từ UXMagazine

Phạm Thùy Dương