Kinh nghiệm vừa có nghĩa là làm thử, vừa có nghĩa là kinh qua.

Khi một hoạt động được duy trì để biến thành sự kinh qua các hệ quả, khi sự thay đổi do hành động đem lại được phản ánh ngược trở lại để biến thành một sư thay đổi  ở bên trong chúng ta, khi ấy tình trạng liên tục thay đổi sẽ chất đầy ý nghĩa.

Một lượng nhỏ kinh nghiệm còn tốt hơn cả một tấn lí thuyết đơn giản chỉ bởi vì chỉ có trong kinh nghiệm thì lí thuyết mới có được ý nghĩa sống động và có thể kiểm chứng. Một kinh nghiệm giản đơn, dù là một kinh  nghiệm vô cùng tầm thường, cũng có thể sinh ra và chuyên chở mọi lí thuyết (hoặc nội dung trí tuệ), song một lí thuyết mà tách rời khỏi một kinh nghiệm thì dứt khoát không thể lĩnh hội được, ngay cả xét nó là lí thuyết.

Không có kinh nghiệm nào có ý nghĩa lại có thể tồn tại mà không có yếu tố nào đó của tư tưởng.

Tư duy tức là nỗ lực chủ tâm nhằm phát hiện các mối liên hệ cụ thể giữa điều chúng ta làm và hệ quả của việc làm đó, sao cho hai quá trình đó trở nên liên tục.

Người ta chỉ hoàn toàn biết chắc chắn điều gì đó khi nó đã được kết thúc, đã được hoàn thành.

Tư duy xuất hiện cùng với sự can dự vào các tình huống vẫn còn đang diễn ra và chưa hoàn thành.

Bởi chưng chúng ta không sống trong một thế giới mà mọi thứ đều được an bài và kết thúc, mà chúng ta sống trong một thế giới đang tiến triển liên tục, và công việc chính của chúng ta trong thế giưới đó bao giờ cũng mang tính chất tương lai và hồi tưởng – và cả mọi tri thức xét như để phân biệt với tư duy, bao giờ cũng là sự hồi tưởng – có giá trị ở chỗ nó đem lại sự vững chắc, an toàn và phong phú cho những mối quan hệ của chúng ta với tương lai.

Trích ra từ Dân chủ và Giáo dục.

Lâu lâu trên blog Tạp Chí Lập Trình mới lại có một bài hút khách như vậy. Anh bạn Mê Kim Dung đã có những phân tích khá sắc sảo về tính đơn giản của các thiết kế trong các sản phẩm công nghệ hiện đại.

Nguyên lí về sự đơn giản (Simplicity) được nhắc đến từ rất lâu. Ngay từ đầu thập kỉ trước, KISS (“Keep it Short and Simple”, hay “Keep It Simple, Stupid!”) đã là một nguyên lí căn bản của Extreme Programming, và của cả OSS (được đề cập đến trong kinh điển “The Cathedral and the Bazaar“).

Câu hỏi về “tại sao” được trả lời rất thuyết phục. Nhưng đến cái phần này thì mới ngại: HOW? Đặc biệt với các bạn làm phần mềm vốn quen với lối làm việc kiểu tuần tự Phân tích>Thiết kế>Mã hóa>Kiểm thử>Đóng gói.

Trong bài có nhắc tới một thống kê của Standish:

“Thống kê cho thấy trong một hệ thống thông thường có đến 45% số lượng chức năng không bao giờ dùng đến, 35% ít khi dùng, chỉ có 20% là thường sử dụng. Vậy đừng lo việc lược bớt chức năng sẽ làm phần mềm của bạn không đáp ứng được yêu cầu người sử dụng. Thực tế, nhiều chức năng chỉ làm đội chi phí và thêm bối rối cho phía khách hàng mà thôi.”

Tuy vậy, làm sao để cắt đi cái 45%+35% kia là cả một câu chuyện dài trong ngành phần mềm, cho đến giờ vẫn còn là vấn đề nổi cộm. Hơn thế, làm sao để có được một thiết kế cho phép việc đó (tức là cắt bỏ đi những cái dư thừa), làm sao để luôn giữ cho thiết kế thật đơn giản? Đó cũng là câu chuyện dài không kém. Vì nó động tới sự kiên trì và đòi hỏi nỗ lực để đạt được một trình độ kĩ năng nhất định.

Tôi có gợi ý cho bạn đọc bài này nhé: Go Agile 😉

Tiện đây xin chia sẻ hai tài liệu thuyết trình ngắn của tôi, một cái về Simple Design, một practice không thể thiếu của các nhà phát triển linh hoạt; một cái về nguyên lí tương đồng giữa Agile và Phần mềm Tự do Mã mở (FOSS) hòng cung cấp thêm một một vài ý tưởng để hiện thực hóa cái How ở trên.

Về Simple Design:

Về so sánh giữa Agile và FOSS, trong đó có nhiều quan điểm được nhắc lại trong bài viết của Mê Kim Dung:

Trong bài một tôi đã trình bày cách thức dùng giấy dán để quản lí công việc cá nhân. Ở bài hai, tôi đã lấy ví dụ về một công cụ quản lí trực tuyến hỗ trợ làm việc di động. Ở bài này tôi xin trình bày một ý tưởng đơn giản khác mà một số người thấy có vẻ “tiện hơn” để làm personal kanban. Các bước thực hiện khá đơn giản:

1. Bạn cần một chương trình giả lập giấy dán trên máy tính (trên Windows, Ubuntu hay MacOS đều có cả). 
2. Dọn sạch desktop.
3. Tạo ba (hay nhiều) cột như các cách làm ở bài trước

Một kanban trên desktop có thể sẽ trông như thế này:

Kanban trên Desktop

Ở đây tôi dùng phần mềm Stickies trên Windows để làm ví dụ.

Nếu bạn là coder, có thể bạn sẽ thích một cái desktop kiểu như vậy. Vì nó sạch sẽ, muốn ẩn đi rất dễ dàng. Hơn thế, nếu bạn dán trên desktop, tức là bạn không thể mang cái kanban theo (trừ khi công ty cho phép bạn remote control). Điều này giúp cho coder có thể “ngắt kết nối” với chuyện công việc sau khi rời khỏi nơi làm việc; tạm quên đi để nạp lại năng lượng cho ngày code tiếp theo.

Với kanban kiểu này, bạn vừa có được sự đơn giản, dễ dàng và trông analog như giấy dán;  lại tiết kiệm và dễ làm, cho những người không thích giấy tờ, ghi ghi , chép chép.

Tới đây tôi xin dừng vệt bài về personal kanban theo hướng công cụ. Có thể tôi sẽ quay trở lại với các khía cạnh khác của chủ đề thú vị này.

Lời cuối, xin được nhắc lại cái ý quan trọng này trong Tuyên ngôn Agile:
“Cá nhân và tương tác hơn là quy trình và công cụ”. Personal kanban là công cụ, kể cả có lí thuyết Lean hỗ trợ thì độ nó cũng không quyết định được hiệu quả công việc hằng ngày của bạn. Nếu biết dùng một cách hữu hiệu, nó sẽ giúp ích; nếu không, nó chỉ làm phiền ta thêm thôi. Có người bảo càng ít công cụ càng dễ tự do. Cũng có ý đúng đấy 🙂

Bài trước tôi đã giới thiệu với các bạn cách tạo lập một personal kanban với đồ rất analog. Bài này tập trung giới thiệu các công cụ kanban trên các thiết bị số: PC, laptop, iPad, smartphone.

Có rất nhiều công cụ giúp bạn tạo được personal kanban, tôi sẽ liệt kê ra một số ở phần 3 của bài này. Để cho dễ dàng, tôi chọn công cụ Trello để tiện giới thiêu cách làm. Trello là một hệ thống mạnh mẽ, dễ sử dụng. Và đặc biệt là nó hỗ trợ nhiều nền tảng. Bạn có thể tạo một kanban trên Trello và bảo trì nó từ PC, laptop hoặc sử dụng iPad hay một smartphone chạy Android. Rất tiện cho những người làm việc phải di chuyển nhiều. Trello dùng rất tốt cho nhóm (nhỏ lớn đều OK) nhưng điều đó không ngăn cản ta có thể dùng cho mục đích cá nhân 😉

Ý đồ là tạo lập một bảng công việc lưu trữ “trên mây”, có thể truy xuất ở mọi nơi, mọi lúc. Như hình dưới đây:

Bài này có ba bần: giới thiệu cách tạo kanban trên Trello bằng hình, sử dụng trên thiết bị di động; và phần cuối liệt kê các công cụ tạo kanban số.

Một: tạo kanban trên Trello

Theo dõi slideshow dưới đây:

Dễ như bỡn nhỉ 😉

Hai: dùng trên thiết bị di động

Lên chợ (Apple Apps Store, hoặc Google Play Store) tải về ứng dụng Trello. Cài vào máy, đăng nhập như trên. Và dùng như trên web.

Trên iPad bạn sẽ có giao diện giống như trên web. Nếu bạn dùng iPhone hoặc smartphone chạy Android thì mỗi màn hình của Trello chỉ chứa một cột. Lướt sang bên cạnh để xem cột tiếp theo. Các thao tác kéo thả và chỉnh sửa thì không có gì khác biệt.

Ảnh chụp màn hình Galaxy Tab 7 Plus

Ba: Các lựa chọn khác

Tôi chỉ lấy Trello làm ví dụ, bạn có thể lựa chọn rất nhiều tool để làm việc này. Quy tắc rất đơn giản: hỏi Mr. Google.

Xin kể ra đây vài cái mà mọi người hay nhắc tên: KanbanFlow, Pomodoro Daisuki, LeanKit, Kanbanery, JIRA, KanbanTool, PearlTrees, pharmaciepourhomme.fr…

Trên “chợ” ứng dụng cho smartphone cũng có rất nhiều. Dùng search engine và tìm kiếm với từ khóa kanban hoặc personal kanban sẽ có đủ “đồ chơi” cho bạn thử.

Bạn thử đi rồi xem cái nào vừa ý, vừa túi tiền thì dùng nhé. Tôi xin miễn bình luận về cái nào là tốt nhất.

Hãy để công nghệ nối dài cánh tay cho bạn, đừng bắt mình phải vác thêm một cánh tay nữa nhé 😉

Trở về từ buổi gặp mặt ScrumCoffee #1, đọc lại bài viết “Hãy tinh gọn trong công việc và cuộc sống” của chủ thớt FU Agile ở Hòa Lạc, Mr. Nguyễn Ngọc Anh, tôi chợt nhớ là phải viết cái gì đó đơn giản để ai đó cũng có thể làm được, giúp phần giảm đi những xì trét vì không thể kham nổi nhiều việc cùng một lúc.

Và đây sẽ là vệt bài về cách tạo ra các bảng công việc cá nhân (Personal Kanban – đây là phương pháp đơn giản lần đầu được để xuất bởi Jim Benson) sử dụng nguyên lí của Lean (tinh gọn) để quản lí công việc cá nhân. Đã có rất nhiều người làm thành công, và tôi mong muốn thật nhiều người thành công hơn nữa.

Ý tưởng rất đơn giản: Giới hạn khối lượng công việc (Limit Work-In-Progress) về khả năng của cá nhân (capacity), trực quan hóa đầu việc, và quản lí công việc theo luồng.

Bài 1 sẽ hướng dẫn bạn dùng mấy tờ giấy dán để làm một Kanban tại phòng làm việc, tại nhà hoặc trong một cuốn sổ ghi chép. Rất analog.

Bài 2 sẽ hướng dẫn bạn dùng một số công cụ số hóa để làm việc, dành cho những người bận rộn và hay làm việc di động

Bài 3 sẽ là một ý tưởng hơi “khùng khùng” một chút dành riêng các bạn lập trình viên

*****

Phần 1: Tạo Personal Kanban với giấy dán

Mời bạn xem hai cái Personal Kanban của hai người sau đây:

Kanban của một Giám đốc Đào tạo

Personal Kanban của một Lập Trình Viên – Sinh viên

Rất dễ làm phải không?

Tạo ra ba cột: Cần làm (ToDo), Đang làm(Doing) và Xong (Done).

Khi có việc cần làm (việc tự nghĩ ra, việc được giao…), ta viết vào tờ giấy dán và đặt vào ToDo trước, phân tích kĩ lưỡng nên làm ngay hay để làm sau. Việc này có bản chất là “lập kế hoạch”, sẽ giúp ta có được trình tự và cách làm công việc có bài bản hơn. Nhiều người bắt tay vào làm ngay việc được giao mà không suy nghĩ, tính toán. Đó không phải là chiến lược tốt. Nếu ta có thể xếp độ ưu tiên theo giá trị (cái nào có giá trị thì làm trước), thì ta có thể mất ít công sức hơn mà làm được nhiều giá trị hơn (sử dụng quy tắc Pareto, 80-20).

Khi quyết định làm việc gì, ta sẽ chuyển công việc sang cột Doing. Có thể ghi ngày giờ bắt đầu làm lên giấy.  Giới hạn số lượng thẻ ở cột này (ví dụ 3). Đừng để nhiều, vì nó sẽ khiển bạn phải nhảy từ công việc nọ sang công việc kia (task-switching), là nguồn cơn của thiếu hiệu quả và xì-trét. Con số 3 hay năm tùy thuộc giới hạn khả năng của từng người, chỉ bạn mới biết được. Khi bạn đặt con số 5 và thấy bắt đầu rối tung lên thì chắc là phải giới hạn con số đó xuống 4. Thực hiện trong một tuần rồi đánh giá lại con số đó. Qua một hai tuần ta sẽ có con số hợp lí. Nhưng khi khởi đầu, tôi gợi ý là nên để con số 3.

Khi làm xong việc gì thì đặt nó sang cột Done, có thể ghi ngày giờ kết thúc lên giấy để đánh giá về sau.

Việc đặt một công việc sang cột Done chứ không vứt đi sẽ giúp bạn nhìn thấy được tiến độ công việc, tạo giá trị thúc đẩy bản thân. Đó là giá trị của trực quan hóa (visualization).

Về tờ giấy dán, bạn có thể chọn nhiều màu, dùng nó tùy theo chủ ý. Ví dụ: các việc học tập để giấy xanh, các việc giấy tờ để giấy vàng, các việc liên quan đến khách hàng dùng giấy đỏ v.v. Tùy bạn. Nhưng hãy dùng có chủ ý. Việc này sẽ giúp cho bảng trực quan hơn, có sức sống hơn.

Bạn làm ngay được chứ?

Xin chào đón các góp ý và thảo luận của các bạn. Nếu thành công và có ích, nhắn lại cho tôi nhé 😉

Tiếp theo: Digital personal kanban,  Dán Kanban lên desktop

Malcom Knowles: người lớn học tập (khoa nghiên cứu lĩnh vực này gọi là andragogy, đối lập với “sư phạm”- pedagogy tức là daỵ cho trẻ con) theo những nguyên lí quan trọng nhất sau đây:

1. Người lớn cần phải được can dự vào quá trình lập kế hoạch  và đánh giá kết quả học tập (self-concept).
2. Trải nghiệm (Experience – gồm cả những sai sót) cung cấp nền tảng cho các hoạt động học tập.
3. Người lớn quan tâm đến những nội dung học tập có liên hệ trực tiếp tới công việc hoặc trong đời tư của họ.
4. Người lớn học theo kiểu lấy vấn đề làm trung tâm (problem-centered) hơn là hướng đến nội dung (content-oriented).

Jeff Sutherland yêu cầu bốn đặc điểm tối thiểu nhất của một Product Owner gồm:

1. Có hiểu biết rộng (Knowledgeability) – về thị trường, sản phẩm, khách hàng, đối thủ..
2. Sẵn sàng (Availability) – một nửa thời gian cho khách hàng, một nửa thời gian cho DevTeam
3. Có khả năng ra quyết định (Decidability) – có khả năng đưa ra quyết định cuối cùng về Product Backlog
4. Trách nhiệm (Accountability) – biết được mình đang làm vì lí do gì, tối đa hóa lợi ích ra sao cho công ty

Mike Cohn có đưa ra một danh sách khác với năm đặc điểm ABCDE (cho dễ nhớ):

1. Sẵn sàng (Available) – như trên
2. Thông hiểu nghiệp vụ (Business Savvy) – không hiểu biz thì không thể làm sản phẩm được
3. Giao tiếp tốt (Communicative) – vì phải làm việc với đủ dạng các bên hữu quan (từ devteam đến khách hàng, nhà đầu tư v.v.)
4. Có thể ra quyết định được (Decisive) – như trên
5. Được trao quyền (Empowered) – không được trao quyền thì không ra quyết định được ( tính chất 4) 

Ta thấy trong hai danh sách của hai “bố già” Agile, chỉ có hai điều trùng lặp là “Avalibility” và “Decisive”. Nếu PO là bán thời gian (dành rất ít thời gian cho sản phẩm và cho nhóm Scrum), hoặc không có quyền quyết định (phải chờ phê duyệt, hoặc không thể tự mình đưa ra quyết định nào) thì nhóm Scrum sẽ gặp phải khó khăn lớn.

Nhìn bộ “tiêu chuẩn” này, hẳn nhiều người có thể sẽ thấy băn khoăn. Bạn nghĩ sao?

Trong nghề lập trình, thật khó sống nếu thiếu framework (dịch thô là “khung làm việc”). Framework là cái khung với rất nhiều thứ được xây dựng sẵn để tái sử dụng cho từng nhóm chức năng\công việc nhất định. Ví dụ, Java Collection Framework giúp cho việc tạo ra và sử dụng các cấu trúc dữ liệu, một phần cực kì quan trọng của bất kì chương trình nào, trở nên nhẹ nhàng hơn. Nếu ai đã từng lập trình C hay Pascal mà không dùng framework để tạo danh sách liên kết, sẽ thấy được sự tiện lợi (không bàn đến các yếu tố khác) của cái lớp LinkedList trong Java Collection Framework. Gần như không phải làm gì thêm để có thể dùng ngay lớp ấy để tạo danh sách. Trong túi khôn của các lập trình viên, mỗi người thường có vài chục framework như vậy.

Nhưng framework không chỉ giới hạn trong giới lập trình. Tư duy chung của framework có thể áp dụng ở mọi nơi: có một chút lý thuyết hay mô hình về cái gì đó, xây dựng một số công cụ để hiện thực hóa cái mô hình đó để “người dùng” có thể sử dụng luôn để hữu ích trong việc gì đấy. ví dụ, Cynefine framework được dùng để hỗ trợ ra quyết đinh trong những tình huống phức hợp (complex) bao gồm ý tưởng về phân vùng các ngữ cảnh theo độ phức tạp như Đơn giản (Simple), Rắm rối (Complicated), Phức hợp (Complex), Hỗn độn (Chaotic) hay Vô định (Disorder); và một biểu đồ để phân vùng sự việc để hỗ trợ ra quyết định hay hoạch định chiến lược.

Cynefine Framework (Wikipedia)

Trong các phương pháp luận về Agile Software Development, Scrum được gọi là framework cũng theo cái tư duy tương tự. Nó xây dựng một cái khung với một số “công cụ” dựng sẵn, có thể tái sử dụng ngay để tiết kiệm công sức cho những người muốn ứng dụng tư duy linh hoạt (agile) vào công việc của mình.

Rõ ràng là việc sử dụng framework đã giúp người mới bắt đầu dễ dàng tạo ra giá trị mà không cần phải nhọc công học hỏi lâu. Nếu phải học cách cấu trúc và  tạo danh sách liên kết rồi mới dùng cho bài toán cụ thể thì có thể ta sẽ phải mất một ngày[cũng chưa chắc tạo ra cấu trúc dữ liệu tốt], trong khi với hỗ trợ của Java Collection Framework, ta chỉ cần một giờ [mà vẫn có một cấu trúc dữ liệu tương đối tốt]. Đây chính là một cách để đứng trên vài những người khổng lồ.

Tuy vậy, chúng ta sử dụng framework, chứ không tùy biến framework. Mỗi framework ẩn chứa bên trong nó là hàng tá lí thuyết và công sức lao động trí tuệ. Nó có lí do để “không hơn, không kém”. Cho nên việc một người mới toe khi nhìn thấy framework mà đã tính cách tùy biến nó, cắt bớt gia giảm nó thì chỉ có thể gọi bằng cái tên hồ đồ, tùy tiện.

Trong thế giới Agile, có một từ ScrumBut để ám chỉ việc này.

Bạn có thể thành thạo Scrum, rồi biến nó thành cái của riêng công ty bạn (tham khảo mô hình ShuHaRi), và gọi nó bằng một cái tên hoàn toàn khác (như Saleforce, IBM … đã làm ); nhưng nếu đó là lần đầu tiên bạn học cách dùng Scrum, và nghĩ rằng phải chế biến ngay ScrumBut thì thôi xin đừng gọi nó là Scrum nữa, đừng nói “tôi cũng dùng Scrum” nữa, tội nghiệp các bác Ken và Jeff. Vì Scrum nó là phờ-rêm-guấc-kờ.

ScrumMaster không quản lí nhân sự, không quản lí tiến độ, cũng chẳng quản lí công việc được gán cho ai, càng không quản lí tiền bạc, hay yêu cầu. Vậy thế cái tay này làm cái gì?

Trong những lớp học tôi dạy về Scrum, phần nhiều học viên cứ nghĩ là ScrumMaster chẳng có việc gì để làm. Nên trong các ý kiến thảo luận, họ thường để một ai đó – như Product Owner, hay Developer, Tester .. – kiêm nhiệm. Cực chẳng đã mới để một người làm ScrumMaster độc lập, vì sợ tốn rì-suộc (resource). Hi hi.

Kì thực thì có vài ScrumMaster mới nhận cái công việc này sẽ thấy ngập lụt, “ôi sao nhiều việc thế”, “thế này thì làm sao nổi”. Hihi.

Vậy thì hằng ngày cái vị ScrumMaster này làm những gì? Xin liệt kê ra đây vài cái thử xem có nhiều không nhé:

1. Tổ chức các cuộc họp

Chả có mô hình làm việc nào lại có lắm kiếu họp thế: Họp kế hoạch, Họp sơ kết, Họp Cải tiến, Họp viết Yêu cầu, Họp Scrum Hằng ngày, rồi đủ các kiểu họp đột xuất khác. ..

Đó là cấu thành rất cơ bản để vận hành cơ chế Thanh tra – Thích nghi. Giữ cho các  cuộc họp này đầy đủ, đúng giờ và hữu ích không hề là việc dễ.

2. Chọc ngoáy liên tục (còn gọi là thanh tra quy trình)

Giữ “con mắt cú vọ” trên tất cả các phương diện của dự án, ScrumMaster sẽ phải dùng hàng tá các câu hỏi để phát lộ vấn đề, phát lộ ý tưởng, để giúp nhóm nhanh chóng đạt được mục tiêu Sprint.

Để “quan sát” ta có thể bắt đầu với:

• Mình có nhìn thấy taskboard không?
• Khách hàng có biết việc gì đang diễn tra trên bảng không?
• Có gì được cập nhật từ hôm qua đến nay không?
• Có nhìn thấy burndown\burnup không?
• Có điểm nào bất thường trên burndown chart không?
• ….

Để điều tra, “đào bới” thêm, ta có thể dùng các câu hỏi Socratic:

Bình thường chúng ta làm việc, cốt cho xong chứ không phải lúc nào cũng nghĩ xem ta làm thế có tốt không, có hiệu quả không, có tiết kiệm không.

Cái sự thể này có nhiều nguyên do của nó: đàn anh ở công ty bảo thế, giáo viên ở trường xưa dạy thế, anh bạn mình làm thế, hay .. cả công ty làm thế.

Ví như, trong một bài tập trong khóa học Lean Mindset ở Đại học FPT vừa qua, có một Project Manager kì cựu đã vẽ ra một luồng công việc cùng với thời gian để hoàn tất nó (trong Lean gọi là Value Stream Map). Kết quả khiến chính chị và nhiều người khá bất ngờ: độ hiệu quả (efficiency) chỉ đạt khoảng 10%. Có nghĩa là chỉ 10% thời gian trong toàn bộ chu trình làm việc của nhóm mang lại giá trị, còn lại là những việc ta làm để làm gì đó, chứ không hề mang lại giá trị thực sự [cho khách hàng].

Hóa ra để biết có hiệu quả không, chẳng phải khó lắm. Chỉ cần dừng lại, vẽ ra luồng công việc từ lúc khởi đầu cho đến lúc hoàn tất; gán thời gian cho từng bước, và thời gian chờ; cộng lại toàn bộ thời gian tạo giá trị, chia cho tổng thời gian của toàn bộ quá trình; ta sẽ trực quan hóa (visualize) mọi thứ, kể cả các vấn đề, những chỗ dư thừa, những chỗ ách tắc mất kiểm soát… Phát lộ để nhìn thấy và thực hiện giải quyết vấn đề.