The heart of agile
Thật không khó để hỏi chị google những giá trị cốt lõi mà Agile đem lại. Đôi khi có thể trong các cuộc phỏng vấn ứng viên có thể trả lời trôi chảy 4 giá trị cốt lõi đó cũng như khi hỏi về các tính chất của lập trình hướng đối tượng nhưng điều đó không chứng minh được rằng họ hiểu về Agile hay hiểu về OOP.
Phía sau các giá trị cốt lõi là các nguyên tắc. Sau các nguyên tắc là các bài học xương máu.
Không nắm được giá trị cốt lõi, không hiểu nguyên tắc thì máu còn chảy.
Vậy cốt lõi nhất của Agile là gì nếu bạn được hỏi ?
SỰ THÍCH NGHI là câu trả lời. (the heart of agile is adaptability)
Hiểu lầm thường gặp
Nó xuất phát từ việc họ so sánh giữa Waterfall và Agile như bức hình trên. Điều này sẽ khiến dẫn đến hiểu lầm cơ bản như sau
Nếu coi Product Goal là một bức tranh đứa trẻ này.
Thì mỗi một Iteration trong Agile sẽ được coi là một tấm ghép cho bức tranh hoàn chỉnh kia. Vậy là mỗi cycle cố gắng delivery một mẩu ghép ấy. Điều này dẫn tới khi có sự thay đổi gần như phải đập đi làm lại vì khi nghĩ rằng sản phẩm là một bức tranh cụ thể rồi người ta không có ý thức thiết kế kiến trúc cho sự thay đổi. Họ tin tưởng rằng những gì đã dựng lên ngày hôm nay sẽ sống mãi với thời gian. Ít nhất là cho tới khi sản phẩm được hoàn thành.
Đây là hiểu lầm khá phổ biến, nó khiến cho Agile trở thành mô hình waterfall thu nhỏ.
Trong thực tế, thì mỗi một iteration chỉ là một thử nghiệm (experiment) để thăm dò. Có thể sự thăm dò này thất bại, nhưng sự thất bại này là cần thiết để lùi một bước và tiến 3 bước. Giống như cách chúng ta lùi lại để lấy đà. Vậy cái cần thiết là chúng ta phải biết cách nhìn thẳng vào vấn đề, phân tích bài học và tìm ra nguyên tắc. 12 Nguyên tắc mà Agile đưa ra là những nguyên tắc lớn.
Trong khi dễ nhận thấy mỗi iteration được tạo ra nó mặc nhiên phải “passed”, chẳng khi nào thấy ai nói rằng chúng tôi đã thất bại. Họ sợ bị ảnh hưởng danh tiếng và cảm xúc và động lực. (Yếu đuối như những đứa trẻ)
Nhân tiện để nói về những đứa trẻ. Tôi sẽ lấy ví dụ để bạn dễ hình dung.
Bạn mua cho nó rất nhiều đồ chơi mà bạn nghĩ nó thích nhưng kết cục nó chẳng chơi món nào cả. Đơn giản vì cái bạn nghĩ nó thích thì nó không thích. Tốn tiền và thất vọng sẽ xảy ra với bạn và cả đứa trẻ cho dù nó không biết nói. Đâu đó chúng ta liên tưởng tới các sản phẩm được hoàn thiện xong rồi mới tung ra thị trường và chẳng ai đón nhận.
Agile giải quyết vấn đề này như thế nào ? Bạn cần trao đổi trực tiếp với đứa trẻ hỏi nó xem nó thích gì rồi mua đúng cái nó muốn. Quá đơn giản nhưng đôi khi chúng ta gặp phải khách hàng mà họ cũng không biết cách trình bày vấn đề của mình một cách rõ ràng hoặc đơn giản là họ cũng chẳng biết giải pháp nào cho vấn đề của họ.
Nếu khách hàng của bạn không biết trình bày rõ ràng cái họ muốn thì giống với đứa trẻ không biết nói, thấy khó mà chiều. Muốn gì thì phải nói ra chứ. Đằng này nói cũng như không ( giống như bài tôi đề cập về US: Viết cũng như không, toàn viết điều hiển nhiên). Vậy bạn phải làm gì với đứa trẻ không biết nói để biết được cái nó muốn.
Chỉ có cách là quan sát và xem xét behavior của nó. Behavior là cách đứa bé phản ứng lại với những thứ nó tiếp xúc, bạn hoàn toàn có thể quan sát và đánh giá. Vậy bạn phải thử nghiệm để quan sát đứa trẻ bằng cách đưa cho nó từng món đồ chơi một, xem phản ứng nó thế nào. Nhìn khuân mặt hớn hở của nó là bạn biết nó thích rồi. Thử nghiệm thành công.
Hành vi được định nghĩa là một phản ứng có thể quan sát và nhìn thấy được thông qua bất kỳ tình huống nào
Behavior và Interaction khác nhau ở chỗ nào: Như đã nói ở trên Hành vi là phản ứng có thể quan sát. Còn Interaction gần như không cần phải quan sát vì nó đã được quy định sẵn rồi, không cho khách hàng sự lựa chọn nào cả.
Vậy làm sao để quan sát được hành vi của khách hàng ở tít gốc mít đằng kia thông qua hệ thống internet. Không có cách nào cả. Giống như việc bạn muốn cho một đứa trẻ biết con Khủng Long là con nào thì chỉ có cách là mua một mô hình giả lập con khủng long. Vậy để giải quyết vấn đề này ta cũng làm y chang như vậy. Ta phải có công cụ để modeling user Behavior not modeling the GUI of application. Giả lập con khủng long có thể dùng nhựa, dùng đất, dùng cao su, còn giả lập User Behavior thì dùng gì. Đó chính là User Story ( Công cụ cho việc giả lập hành vi người dùng để phát triển phần mềm)
Theo cách này người ta đề ra phương pháp BDD (Behavior Development Driven) phát triển sản phẩm theo hướng hành vi, trải nghiệm của người dùng. Họ đẩy từng thử nghiệm thông qua iteration (sprint trong scrum) để xem phản ứng của khách hàng và thu thập thông tin lấy phản hồi, sau đó mới quyết định làm trong các iteration tiếp theo nhằm có sự tăng trưởng.
Còn nếu bạn trực tiếp quan sát được nắm bắt được và chắc chắn rằng khách hàng của bạn thích cái này, cái kia thì không cần phải thăm dò. Hoặc những cái bạn làm là cái mà khách hàng trực tiếp yêu cầu thì cứ làm luôn và ngay ( giống bên outsource vẫn làm: nhận đơn hàng và đưa hàng, that is all). Cái này phù hợp với thứ dễ hiểu, ngắn và nhanh. Không cần làm phức tạp mọi cái nữa. Waterfall là phù hợp cho dự án kiểu này. Cái mà bạn chắc chắn là đúng.
Trong khi nếu chúng ta dùng agile nhưng tâm hồn waterfall, nghĩa là vẫn mindset cũ ( mindset hoàn thành) thì chúng ta chỉ tìm cách hoàn thành công việc trong sprint đó. Cố gắng chỉ cho các ban bệ quản lý, khách hàng…. thấy, chúng tôi đã “làm việc xuất sắc như thế nào”. Nhưng tăng trưởng không đồng nghĩa với hoàn thành. Sự chăm chỉ không đồng nghĩa với hiệu quả.
Increment is not complement: Bạn hoàn thành và thêm vào các gì đó cho sản phẩm không có nghĩa là nó có tăng trưởng
Agile hướng tới tự quản. Nên bạn không cần phải làm màu các chỉ số KPI hoặc các matrix nào cả. Cái bạn cần ở các chỉ số đó là để đo sự tăng trưởng của sản phẩm. Nó không nên dùng thể hiện rằng team bạn toàn những cá nhân kiệt xuất ( xứng đáng được tăng lương) với khả năng hoàn thành xuất sắc “Task được giao” 100% 200% và vài nghìn 1000%.
Cốt lõi của agile là sự thích nghi. Sự thích nghi càng cao khi có thay đổi thì khả năng sống và tồn tại của sản phẩm cũng tỷ lệ thuận theo. Ví sản phẩm của bạn là một sự sống cần nuôi dưỡng thì những KPI bạn dựng lên nên để đo sức khỏe cho nó thay vì perform năng lực của nhóm.
