AgileBreakfast sẽ là người bạn thân thiết của mỗi người học, thực hành, quản lí theo triết lí Agile. Bài viết phong phú, đa dạng, hữu ích, chất lượng về các góc cạnh của Agile, Scrum, Kanban, Lean, Lean Startup… Từ triết lí tới công cụ và thủ thuật.
Tất tần tật, tại đây:
Giới thiệu sách “Lean Mindset: Ask the right questions” của Tom Poppendieck và Mary Poppendieck
Đầu năm 2013, trong thời gian công du vòng quanh thế giới để thực hiện một loạt các workshop có tên Lean Mindset (trong đó cả Hà Nội và Tp.Hồ Chí Minh đều là điểm dừng chân, may mắn thay!), Tom và Marry đang hoàn tất cuốn sách cùng tên của mình: Lean Mindset. Có vẻ như đây là cuốn sách cuối cùng trước khi nghỉ hưu của hai “tư tưởng gia” (thought leader) của cộng đồng Agile quốc tế.
Bìa sách Lean Mindset
Trong khi phần nhiều sách Agile dạy “chiêu” (practices), với hàng loạt những “cách làm việc A, cách làm việc B, để làm việc C v.v.” thì thật hiếm có những sách dạy cách tư duy (mindset) làm “bánh lái” cho các “chiêu thức” đó. Bộ sách của nhà Poppendieck lúc nào cũng được săn đón bởi nó luôn khơi gợi và nuôi dưỡng tư duy cho những người người thực hành Agile, từ người tập tọe, tới lãnh đạo và các chuyên gia Agile khác.
Khi mới viết cuốn sách đầu tay rất nổi tiếng năm 2003, Tom&Mary vẫn còn xếp Lean Software Development (LSD) vào cùng họ với Agile Software Development (như tựa đề đã ám chỉ – Lean Software Development: An Agile Toolkit). Tuy nhiên, sau một thập kỉ, nhiều thứ đã thay đổi. Một số tác giả khác cũng đã cố gắng tiếp cận LSD theo cách thức độc lập với Agile, xếp nó như là bộ phận con của Lean Product Development. Bản thân Mary & Tom cũng đã có thời gian trải nghiệm đủ dài với LSD để nhận thấy những gì là khiếm khuyết, thiếu sót của Agile. Sau bộ ba cuốn sách với phạm vi được giới hạn trong thế giới phần mềm (lần lượt là: “Lean Software Development”, “Implementing Lean Software Development” và “Leading Software Development”), Mary & Tom tự nhận thấy họ không thể viết thêm về phần mềm nữa, như lời bạt của cuốn sách thứ tư này đã đề cập. Do vậy, cuốn “Lean Mindset” xuất bản tháng 9 năm 2013 như là điểm kết thúc một chặng đường dài với Phần mềm để trở về với tư duy tinh gọn “thuần khiết” hơn, không bị ảnh hưởng bởi lĩnh vực hẹp và trào lưu Agile ồn ào như trước.
Ở Lean Mindset, hai tác giả muốn nêu bật đặc tính “là một tư duy” của Lean, chứ không phải là một “phương pháp” hay “chiêu thức”. Do đó, như tựa nhỏ của cuốn sách đã gợi ý, tác giả tập trung vào “hỏi các câu hỏi đúng đắn”. Việc này không chỉ là nội dung của bản thân cuốn sách, mà còn là phong cách xuyên suốt của quyển sách mỏng nhưng giàu ý tứ. Ngoài các câu hỏi chính yếu của từng chương như “Mục đích của kinh doanh là gì?”, “Bạn đang làm việc để làm gì?”, “Điều gì khiến con người làm việc hiệu quả”, “Năng suất là gì?” và nó có quan trọng không?, “vai trò của thiết kế là gì?” hay “vì sao phải cách tân đột phá?”; các tác giả còn liệt kê một danh sách dài những câu hỏi để bạn đọc động não, suy tư (reflect) kĩ thêm về tất cả các phương diện của một công việc có ý nghĩa. Với danh sách câu hỏi quý hơn vàng này, thời gian tương tác thực sự với cuốn sách có thể dài và sâu hơn rất nhiều so với số trang ngắn ngủi và lượng thông tin ít ỏi có chọn lọc của cuốn sách. Đó quả là một cách tiếp cận tốt để “tấn công” vào tư duy và thúc đẩy sự thay đổi tích cực.
Một trong những nét chấm phá thú vị của cuốn sách là sự xuất hiện của hai nhân vật giả tưởng Otto – một thanh niên có trực giác nhanh nhạy và Anna – một cô gái rất lí tính, lúc nào cũng đòi hỏi phân tính tỉ mỉ và chu đáo. Thỉnh thoảng họ lại hiện lên và làm nổ ra những đoạn hội thoại vô cùng hữu ích, có khi rất dài, cũng có lúc thật ngắn gọn, giúp cho bạn đọc vừa được thư giản, vừa tăng thêm chiều sâu tư duy cho nội dung được bàn tới. Có thể rất nhiều câu hỏi quan trọng của bạn sẽ được Otto và Anna trả lời hoặc khơi mào giúp.
Một đặc sắc nữa cuốn cuốn sách có lẽ là nằm ở các tình huống nghiên cứu được chọn lựa. Là một cuốn sách đậm tính triết lí, Lean Mindset vẫn có thể thu hút người đọc với những phân tích đa chiều và sâu sắc ở rất nhiều tình huống thực tiễn, như trường hợp của Intel, WIKISPEED, CareerBuilder, hay của Spotify. Những phân tích này thậm chí có thể gợi ý những quy trình công việc thực thụ cho những nhà lãnh đạo và quản lí doanh nghiệp.
Bất chấp nhiều ưu điểm như nhận xét bên trên, bạn đọc có thể gặp một số khó khăn nhất định nếu chưa một lần tìm hiểu qua Tinh gọn là gì. Cuốn sách này không tập trung định nghĩa nó, hay giúp người đọc có thể “triển khai” tư tưởng tinh gọn vào công việc (như ba tập sách trước từng làm). Vì vậy, có thể cuốn sách này sẽ kén người đọc hơn, vớt ít kì vọng “sát mặt đất” hơn.
Để kết thúc việc giới thiệu một cuối sách còn mới, còn chờ thời gian thẩm định độ hay/dở, chúng ta cùng nhau “thưởng thức” một vài câu hỏi hay được rút ra từ trong sách:
Xin mời!
PS. Trên TapChiLapTrinh.vn có một số tổng hợp về Tinh gọn, bạn có thể tìm hiểu thêm sơ bộ về tinh gọn (Lean) là gì: ở đây.
Mary và Tom Poppendieck khuyến khích các nhà phát triển phần mềm nghĩ về phần mềm như là một hệ thống hơn là một chương trình máy tính đơn thuần. Đó phải là hệ thống của bản thân phần mềm, phần cứng mà nó được cắm vào, cái tính chất kết nối của những phần cứng ấy, và tính chất của con người vận hành cả cái hệ thống ấy để thực thi những công việc theo nhu cầu.
Như vậy tức là khi phát triển phần mềm, ta không chỉ phát triển phần mềm. Mà ta đang đi tìm một cách thức làm việc mới có sự tham gia của [những] chiếc máy có cài phần mềm ấy.
Theo cách hiểu như thế, có nhiều “truyền thống” có thể bị phá bỏ.
Xin lấy một ví dụ nhỏ về tính “đầy đủ” của phần mềm.
Hơn năm trước tôi làm Product Owner của một dự án nhỏ cho trung tâm. Bản alpha mà tôi yêu cầu chỉ gồm rất ít chức năng, định nghĩa dữ liệu đầu vào được quy định chặt chẽ do người dùng tạo ra, không có authorization theo role, chỉ dùng một role duy nhất. Phần mềm làm ra chứa đầy lỗi, thiếu cả đống chức năng. Thế nhưng trong suốt quá trình sử dụng bản alpha đó để làm việc, mọi quá trình nghiệp vụ không hề gặp phải vấn đề gì. Điều gì đã xảy ra với những lỗi vẫn còn trong hệ thống? Và những chức năng bị thiếu thì sao đây? Câu trả lời rất đơn giản: người dùng được chỉ cho những chỗ không nên động vào, tránh và xử lí các lỗi khi gặp phải. Thực ra chỉ có một lần duy nhất người dùng thao tác sai sót dẫn đến phải khởi tạo lại dữ liệu, còn trong các trường hợp khác không hề hấn gì.
Cho đến bây giờ khi chúng tôi gắn version cho sản phẩm là 1.01 thì hệ thống “có vẻ” vẫn thiếu đầy chức năng. Một phân hệ authorization đầy đủ chẳng hạn, tới giờ vẫn như lúc alpha.
Chúng tôi đã cắt đi được phần lớn (>50) lãng phí nhờ vào việc nhận biết những feature nào không được dùng, và quan trọng hơn là đã vận hành xây dựng một hệ thống phần mềm với sự tham dự của yếu tố con người chứ không phải là chỉ làm ra một phần mềm hoàn chỉnh nhưng cô lập.
Bạn có thể cười chê rằng chúng tôi là những tay mơ, không theo chuẩn mực. Nhưng thực tế là chúng tôi cũng chỉ cần đến thế, sao phải làm hơn? Nhất lại là chúng tôi hoàn toàn kiểm soát được hệ thống. Sau hơn một năm vận hành, chúng tôi chưa gặp phải technical debt đáng kể nào, tất cả là nhờ cách vận dụng chữ “hệ thống”.
Phần mềm như là một hệ thống
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:
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ố.
Theo dõi slideshow dưới đây:
Dễ như bỡn nhỉ 😉
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
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, …
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
Trước hết, tôi sẽ làm rõ khái niệm “Value Stream Mapping” đã đề cập ở trên:
“Value stream mapping is a lean manufacturing technique used to analyze and design the flow of materials and information required to bring a product or service to a consumer. At Toyota, where the technique originated, it is known as “material and information flow mapping”. It can be applied to nearly any value chain.” (Theo Wikipedia.org)
Chúng ta có thể hiểu kỹ thuật này đã được triển khai trong “Sản xuất Tinh gọn” (Lean Manufacturing), nó giúp phân tích toàn bộ dòng sản phẩm (từ khi bắt đầu tới khi bàn giao sản phẩm) nhằm tìm ra những nút mang lại giá trị thực sự (cho khách hàng) trên dòng (stream, flow) sản xuất và những nút (điểm) lãng phí (thừa thãi), không đem lại giá trị. Với những nút (công đoạn) thực sự mang lại giá trị thì sẽ tập trung nguồn lực để làm sao cho hiệu quả nhất, còn ngược lại với những nút lãng phí cần được loại bỏ khỏi dòng sản xuất (hoặc làm sao cho đỡ tốn kém nguồn lực nhất, nếu không loại bỏ được nó).
Thực hành kỹ thuật này thực ra không hề khó khăn, tôi có thể mô tả cách làm qua những bước căn bản sau:
- Chuẩn bị một tờ giấy trắng (A4, A3, A2, v.v.) tùy thuộc vào kích cỡ (số bước triển khai) của một công việc mà bạn thường phải làm; bút màu càng nhiều màu càng tốt.
- Tưởng tượng trong đầu lần lượt các bước sẽ phải thực hiện từ khi bắt đầu tới khi hoàn thành công việc đó.
- Vẽ các bước đó lần lượt ra tờ giấy bạn đã chuẩn bị.
- Điền các giá trị về thời gian vào mỗi nút (thời gian thực hiện công đoạn đó)
- Điền các giá trị (nếu có) về độ trễ giữa mỗi nút (các nút nối với nhau bởi mũi tên, ta có thể điền giá trị này lên đó)
- Xác định những nút không mang lại giá trị thực sự và tìm giải pháp để loại bỏ hoặc giảm bớt nguồn lực để thực hiện
- Xác định những nút mang lại giá trị thực sự và tập trung nguồn lực để nhằm đạt được hiệu quả cao nhất.
- Tính độ hiệu quả của dòng hiện tại của bạn và ước tính độ hiệu quả mới nếu loại bỏ được những lãng phí và cải tiến để tăng hiệu quả ở những nút mang lại giá trị.
Xin cảm ơn ông bà Poppendieck và các đồng nghiệp tham dự buổi Lean4Every1 tối qua đã cho tôi cảm hứng để viết bài này.
Trong phương thức sản xuất hàng loạt, nhà sản xuất dựa trên khảo sát thị trường rồi dự đoán sản lượng rồi tiến hành sản xuất, rồi đẩy ra thị trường tiêu thụ.
Trước khi lượng hàng này tiêu thụ hết, chúng nằm ở chỗ nào đấy, thường là trên đường đi hoặc trong kho lưu trữ. Vì thế tồn kho lớn.
Trong kinh doanh, tồn kho là nỗi kinh hãi của nhà sản xuất khi thị trường đi xuống hoặc biến động. Nếu như khách không mua nữa, toàn bộ hàng hóa thành ra “của nợ”. Tồn kho khi đó là dấu hiệu rõ ràng của lỗ to, và thậm chí .. phá sản.
Thế thì làm sao để tránh tồn kho lớn? Có ít nhất hai cách:
1. Làm tốt khâu dự báo, để có số lượng sản xuất khớp với lượng tiêu thụ. Đồng thời phải có hệ thống tiêu thụ tốt để làm ra hao biêu tiêu thụ hết bấy nhiêu.
2. Đừng sản xuất hàng loạt nữa, để giảm thiểu tồn kho ngay từ đầu
Cách thứ nhất thì đòi hỏi phải có hệ thống dự báo tốt (dữ liệu, chuyên gia). Nhưng điều này thường là bất khả khi hệ thống (thị trường) phức tạp (complex). Khi đó, mọi dự đoán dài hạn thường trật lất. Đặc biệt trong hoàn cảnh thị trường luôn biến động (như thời kì chúng ta đang sống đây chẳng hạn).
Cách thứ hai loại bỏ tư duy hướng-nhà-sản-xuất (manufacture-centric) để cho khách hàng quyết định lượng hàng cần sản xuất (customer-centric). Có bao nhiêu đơn đợt đặt hàng thì sản xuất bấy nhiêu, sẽ không tồn kho.
Vận hành theo kiểu thứ nhất, ta có một hệ thống đẩy (Push System); theo kiểu thứ hai, ta có một hệ thống kéo (Pull system).
***
Thử xem một ví dụ về hệ thống kéo trong một nhóm phát triển phần mềm sử dụng Scrum và một bảng công việc kiểu Kanban.
Như bạn đã biết, các yêu cầu phần mềm được đặt trong một danh sách ưu tiên: Product Backlog, người được ưu tiên là Product Owner, tức là người thuộc “phe khách hàng”
Scrum Framework, ảnh: Bas Vodde et al.
Nhóm Scrum sẽ căn cứ năng lực hiện tại của mình (capacity) để lựa chọn số lượng yêu cầu cho phù hợp để đưa vào sản xuất trong một Sprint để có chức năng chạy tốt ở cuối Sprint đó. Tại thời điểm Sơ kết Sprint (Sprint Review), chức năng đó có thể dùng ngay được (potentially shippable increment). Vậy là không hề có chức năng nào là “tồn kho”. Khách hàng (PO) trực tiếp đặt hàng, với số lượng vừa phải để nhóm Scrum sản xuất.
Trong cách làm truyền thống, toàn bộ các yêu cầu sẽ được “giao” cho nhóm sản xuất, làm xong tất cả các chức năng rồi mới đóng gọi lại (trong toàn bộ thời gian phát triển của dự án), tức là khách hàng (thực ra là cấp quản lí) ĐẨY yêu cầu cho đội sản xuất, còn ở đây, đội sản xuất KÉO các “đơn đặt hàng” từ khách hàng.
Việc KÉO cũng được áp dụng trong công việc nội bộ của đội sản xuất (Development Team). Sau buổi Họp kế hoạch Sprint, các công việc được đặt trong Sprint Backlog. Căn cứ vào yêu cầu công việc và năng lực cá nhân, các developer (có thể có chuyên môn khác nhau: coder, designer, tester …) sẽ KÉO công việc từ SprintBacklog để hoàn thành nhiệm vụ chứ không đợi cấp quản lý ĐẨY việc cho mình. Nói thêm, vì yêu cầu công việc, các nhân sẽ phải thực hiện việc kéo rất thông mình trong tinh thần cộng tác. Ví dụ như, cả nhóm sẽ phải tạo ra LUỒNG MỘT SẢN PHẨM để cùng nhau kéo các công việc sao cho giải quyết dứt điểm từng yêu cầu (tức là đánh dấu DONE cho nó) trước khi kéo các công việc khác để làm. Để có thể triển khai được luồng một sản phẩm, đội sản xuất phải liên chức năng. Đội liên chức năng có đầy đủ kĩ năng cần thiết để không phải chờ ai (bên ngoài nhóm ) làm xong việc mới đưa ra được chức năng chạy tốt.
Thực tế đã cho thấy, một hệ thống kéo – một trong những kĩ thuật chủ chốt trong sự thành công của các phương pháp tinh gọn và Agile (như Lean Software Development, Lean Manufacturing, Kanban, Scrum, v.v.), giúp cho các nhóm làm việc đạt hiệu quả cao hơn nhờ tinh giảm được lãng phí, giới hạn luồng công việc (WIP) để đạt được chất lượng cao hơn cho sản phẩm, thích ứng tốt hơn với sự biến động khó lường của môi trường.
Viết ra như một phần của thú vui tư duy.
Để cho bớt dài thêm bài viết, các phần trích dẫn, liên kết tôi để dạng hyperlink,
bác nào muốn kiểm chứng, đọc thêm thì nhấn vào xem thêm chi tiết.
Trở về từ talkshow của ông Phạm Toàn ở L’Espace về bộ sách triết học cho trẻ con “Thú vui tư duy”, mở máy ra thì bị anh Facebook hỏi một câu rất xách mé “trong đầu mày nghĩ gì?”. Thế là trả lời, nguyên văn là thế này:
“Dạy học cốt ở cái đúng, không phải hấp dẫn” – T
Theo như tôi hiểu được trong ngữ cảnh của câu nói ấy ở L’Espace, ông Toàn đặc biệt nhấn mạnh đến việc phải tìm cái đúng để dạy, vì dạy cái sai mà hấp dẫn sẽ di hại khôn lường. Đây là nguyên lí hết sức căn bản trong giáo dục. Ông có lấy ví dụ trường hợp hỏa hoạn: nếu có lửa cháy cái thư viện đang ngồi (ở L’Espace) thì phải hô to, dứt khoát “đi đằng này, từng người một!” , chứ không phải nói theo kiểu lịch sự (theo ‘thông lệ’ của trung tâm Văn hóa Pháp), nicely “kính các anh chị, anh chị vui lòng xếp hàng một, đi lại nhẹ nhàng qua lối này vì có lửa đang cháy … “ 😀
Nhiều người trẻ và không còn trẻ trong hội thảo đã có những sự tán đồng nhất định đối với quan điểm này cùng ông Toàn vì chính họ là nạn nhân của những thời kì dạy toàn cái sai…
Có cụ nào đó dạy rằng “hãy nhìn vào hành động để đánh giá một ai đó”. Tôi thấy ông Toàn không bao giờ là người coi thường phương pháp, thậm chí “CÁCH” còn rất được đề cao (như là sự phân biệt giữa giáo dục truyền thống và hiện đại). Nhìn vào các hành động của ông Toàn thì thấy ông rất coi trọng tâm lí học, phương pháp, thao tác .. trong xây dựng sách giáo khoa và thực tiễn giảng dạy; những câu hỏi như “dạy sao cho dễ hiểu?”, “dạy và học sao cho hấp dẫn?” … luôn là những thứ được đặt làm nền tảng cho các bài học. Cứ lấy sách Cánh Buồm ra xem thì sẽ rõ.
Cùng một cái gốc chung với ông Toàn, ông Hồ Ngọc Đại có công thức tóm tắt công nghệ giáo dục ngắn gọn chỉ với hai từ: CÁI &CÁCH . Hai cái đó hữu cơ trong một, không thể tách rời. Câu nói của ông Toàn không đi ra khỏi quỹ đạo của hai chữ ấy.
Nhưng ông bàn thêm gốc là “CÁI”. Ví dụ, đất nước này thiếu nền tảng triết học phương Tây trầm trọng, vì CÁI duy nhất được biết tới là triết học (nếu có thể gọi đấy là triết học) Mạc văn Lê…
Thôi kể chuyện hội thảo đến đấy thôi, chuển sang cái “thú vui tư duy nho nhỏ” của tôi. Cũng liên quan đến CÁI và CÁCH.
1. DO THE RIGHT THING, AND DO IT RIGHT.
Đây là câu thuộc nằm lòng của nhiều nhà kinh doanh và quản lí. Phải tìm cái đúng mà làm, rồi làm nó một cách đúng đắn. Tức là nếu có cả CÁI và CÁCH thì bi-si-nít-xờ sẽ thành công rực rỡ.
Đây là bài học vỡ lòng trong nhiều sách dạy kinh doanh và quản lí. Nó liên quan đến hai chữ quan trọng mà không phải ai cũng phân biệt được, và khi dịch ra tiếng Việt thì nhiều khi cứ dịch như nhau: EFFICIENT và EFFECTIVE
Tra từ điển Webster thì nó là thế này:
Efficient:
1: being or involving the immediate agent in producing an effect <the efficient action of heat in changing water to steam>
2: productive of desired effects; especially : productive without waste <an efficient worker>
Effective:
1
a : producing a decided, decisive, or desired effect <an effective policy>
b : impressive, striking <a gold lamé fabric studded with effective…precious stones — Stanley Marcus>
2: ready for service or action <effective manpower>
3: actual <the need to increase effective demand for goods>
4: being in effect : operative <the tax becomes effective next year>
5 of a rate of interest : equal to the rate of simple interest that yields the same amount when the interest is paid once at the end of the interest period as a quoted rate of interest does when calculated at compound interest over the same period — compare nominal
Còn đây là hình vẽ trong sách nhập môn quản lý – “Essentials of Contemporary Management” của Gareth Jones và Jennifer George:
Effectiveness (người người gọi là Hiệu quả) chỉ cái đúng đắn trong sự lựa chọn cái để làm: vision, chiến lược, mục tiêu, sản phẩm v.v. thuộc loại này. Tìm cái gì để “Một vốn bốn lời” là có được Effectiveness.
Efficiency (có người dịch là Hiệu lực, năng suất, hầu hết hồn nhiên dịch ra là ‘hiệu quả’), chỉ khía cạnh phương pháp, cách thức đạt được kết quả. Chi ít tiền hơn để đạt được một mục tiêu thì là “hiệu quả” hơn.
Nhiều công ty đã đóng cửa, thua lỗ hay bị hoen ố hình ảnh vì đầu tư không đúng chỗ ngay cả khi họ sở hữu những bộ óc “có sạn” , một núi tiền khổng lồ sẵn sàng rót vào các chiến dịch truyền thông\quảng cáo, hay một núi know-how đã được tích lũy qua hàng chục năm chinh chiến trên thương trường ác liệt. Có thể họ chỉ có được Efficiency nhưng không có Effectiveness.
Mong đợi của của các nhà quản lí luôn luôn nằm ở góc trên bên tay phải của ma trận trên: vừa effective, vừa efficient. Gọi chung là ước vọng 2E.
Tuy vậy, thế “giới này quả là rộng lớn, và chúng ta có rất nhiều việc phải làm” với hai chữ EFFECTIVE và EFFICIENT này 🙂
2. Về sự phức hợp (Comlexity)
Thế giới ngày nay cực kì phức hợp. Sự phức hợp có trong hầu như ở những công việc đơn giản nhất hằng ngày. Ví dụ, “nên dạy trẻ con ứng xử thế nào với đèn đỏ khi đi trên đường Hà Nội?”, thử trả lời đi, bạn sẽ thấy nó cực kì rắc rối.
Ma trận Stacey là một công cụ tốt cho những nhà quản lí, những chiến lược gia nhìn nhận, phân tích, đánh giá tình hình và đưa ra các quyết định đúng đắn trong nhiều tình huống khác nhau. Nó trông như thế này:
Nguồn: Stacey RD. Strategic management and organisational dynamics: the challenge of complexity. 3rd ed. Harlow: Prentice Hall, 2002.
Tạm tán phét về mấy vùng trong ma trận Stacey:
Thật đen đủi, có quá nhiều sự việc mà chúng ta đối diện hằng ngày không thuộc vùng SIMPLE, cũng chẳng thuộc vùng COMPLICATED. Làm sao bây giờ, huhu…
3. Lean Startup (Khởi sự Tinh gọn): Tìm cái đúng mà làm
Vài năm nay đồng chí Eric Ries trở nên nổi như cồn nhờ vào cái mô hình cho Tech Startup (trước hết là những công ty khởi sự từ IT, sau tới các ngành khác). Lean không có gì mới, nhưng kết hợp Lean, Agile và các ý tưởng về bi-di-nít-xờ cùng với ong-tờ-rơ-pờ-rơ-nơ-síp để ra được cái Lean Startup một cách tài tình như thế thì Eric Ries nổi như rứa cũng phải thôi.
Sách của ông này đây:
Ảnh : TheBln.com
Ồ, cái anh Lean Startup này có liên quan gì đến CÁI và CÁCH ?
Có đấy, hình dưới đây nói lên nhiều điều:
Theo Eric Ries, The Lean Startup – Google Tech Talk
Lean Startup là một cách tiếp cận để sống trong vùng Phức hợp, khi cả yếu tố giải pháp (kĩ thuật) và sản phẩm (yêu cầu) đều không rõ ràng. Để sống được, Tech Startups rất hay phải đi tìm các sản phẩm chưa từng có (để tạo lợi thế cạnh tranh cho người đi sau), để làm được việc đó, có khi lại phải dùng các công nghệ (hay innovation) chưa từng có (cái ai cũng có và làm được thì nhiều người làm rồi). Vậy nên toàn là UNKNOWN và UNCERTAINTY. Trong bối cảnh như vậy thì không thể làm việc theo kiểu “tớ biết hết rồi” được. Phải để khách hàng kiểm định giả thuyết, lean startups phải là các tổ chức học tập liên tục để “biết” được cái cần làm là gì dựa trên các dữ liệu thực tiễn (empirical). Cách tiếp cận truyền thống có thể đơn giản hóa theo kiểu “Khảo sát kĩ thị trường> lập kế hoạch > Thực thi > Kiểm soát” không hiệu quả vì nó dựa trên những điều giả định (prescriptive) tiềm ẩn rất nhiều sai sót. Lean Startup dùng từ khóa unknown để khai mở cách tiếp cận mới: vì không biết nên phải vừa đi vừa dò, từng bước nhỏ thôi (baby steps), đi đến đâu xác minh đến đó, rồi cải tiến và xác định bước tiếp theo. Kể cả Requirement lẫn Technology, phải liên tục tìm kiếm cái đúng đắn để làm thông qua các vòng phản hồi ngắn (short feedback life cycle). Nếu coi Requirement (hay Customer) là CÁI, và Technology (hay solution) là CÁCH (hay phương tiện), thì Lean Startup có được một đường lối để luôn luôn suy nghĩ và kiểm định hai thứ này. Đây là một cách tiếp cận đương đại, hiệu quả [và thời thượng nữa] về 2E.
4. Scrum – phải có CÁCH đúng, để có được CÁI đúng
Trong tài liệu mới nhất cùng viết với nhau của hai đồng tác giả của Scrum, “Software in 30 days”, Jeff Sutherland và Ken Schwaber có viết cả một Chương 2 để biện luận cho cái này: “RIGHT APPROACH, RIGHT RESULTS”, với đầy đủ các dữ liệu chặt chẽ từ thực tế phát triển phần mềm.
Như vậy, theo quan điểm của hai ông Schwaber và Sutherland, Scrum là một CÁI về phần CÁCH để có được các CÁI khác đúng đắn trong phát triển phần mềm. Gần giống với trường hợp của Lean Startup như đã nói ở trên. Software thuộc về thế giới Complex là chủ yếu, còn Scrum có thể phát huy trong khu vực nà. Cách xác định CÁI và CÁCH của họ được minh họa bằng Stacey Graph dưới đây:
Nguồn: Ken Schwaber, Scrum for Vietnam
5. Thế nào là ĐÚNG (RIGHT)? Đâu có đơn giản thế?
Cả cái mệnh đề “do the right thing, then do things right”, cho đến “right approach, right results” đều dùng một từ quá khó: ĐÚNG.
Nhận biết được cái gì đúng là cực khó. Đây cũng là phân vùng mà Triết học (không kể là Triết học ‘Người nhớn’ hay là Triết học ‘Trẻ con’) bận tâm như một trong các vấn đề cơ bản. Xin được rời xa bi-di-nít để được dẫn ra đây hai quan điểm “cổ điển” (“cổ điển” – classic không có nghĩa là cũ, và cũng không có nghĩa là không còn giá trị ở “hiện tại” nữa) về chuyện này:
Jeremy Bentham, John Stuart Mill và những hậu duệ theo quan điểm vị lợi (utilitarianism) cho việc đúng là việc mang lại nhiều lợi cho nhiều người nhất trong bối cảnh. Có nghĩa là không có cái đúng tự thân, đúng hay không là ở sự vận dụng cái TÙY.
Emmanuel Kant thì lại không cho là như thế: cái gì đúng không phụ thuộc vào việc nó làm gì với ai mà bởi vì nó đúng tự thân.
Hai cái trường phái này vẫn còn tồn tại, ảnh hưởng, và gây nhiều tranh cãi liên miên cho tới ngày nay. Chắc là sẽ không có ngày kết thúc. Đây cũng là những chủ đề nổi bật trong các bài giảng về triết học hoặc công lí của các trường đại học ngày nay (xem bài giảng của GS Micheal Sandel của trường Harvard tại đây).
Xem ra việc đánh giá cái gì là đúng, sai có phần không đơn giản như ta nghĩ.
Xin dừng đột ngột chuyện triết học ở đây để chuyển về chủ đề cuối cùng:
6. Triết học thì can hệ gì vào công việc (là nghĩa rộng của từ bi-di-nít-xờ: business = ‘sự bận’ = ‘có việc’)?
Quay trở lại cái hình của Stacey ở trên cùng. Trên trục hoành, càng xa dần cái gốc, sự không chắc chắn. Cái chuyện RIGHT hay WRONG trong thế giới phức hợp là rất không chắc chắn. Ở những khu vực như vậy, khả năng “judgement” (năng lực phán đoán) càng trở nên quan trọng. Thật đáng tiếc cho các nhà quản lí, các nhà kĩ thuật , khả năng này lại cần rất nhiều tri thức về khoa lịch sử, nhân văn và triết học … để bồi đắp, chứ không phải là các thứ về logic, hay công thức toán học (là những thứ được dạy nhiều trong trường kinh doanh hay công nghệ).
Với xuất phát điểm như vậy, Ikujiro Nonaka và Hirotaka Takeuchi chủ trương một thế hệ lãnh đạo mới của thế kỉ XXI (bối cảnh của thời đại tri thức, nơi ‘sinh sống’ của các tổ chức sáng tạo tri thức – knowledge-creating company, và quản lí dựa vào tri thức – knowledge-based management) phải là “Wise Leader” với kĩ năng lãnh đạo “Phronetic Leadership” có nội dung quan trọng về phronesis (practical wisdom – dịch thô thiển ra là “sự khôn ngoan thực tiễn”) – một phạm trù triết học có xuất xứ từ thời Aristotle. Các cấu thành của Phronesis của nhà lãnh đạo kiểu mới này gồm:
Để dễ hình dung, người lãnh đạo theo mô tả của Nonaka phải là một nhà-tư-tưởng-vận-động-viên, người có khả năng tư duy sâu sắc và năng lực hành động mạnh mẽ, như minh họa của hình dưới đây:
Nguồn: Nonaka.
Khuyến cáo của Nonaka có thể rất lạ đời:”nhà kinh doanh và lãnh đạo cần phải có hiểu biết sâu sắc về khoa xã hội, nhân văn và triết học”.
Đấy, cái liên quan giữa kinh doanh và triết học là như vậy đấy!
7. Kết
Thú vui tư duy của tôi sẽ còn nối dài vô tận cho tới khi nào xuống mồ. Còn bài này thì phải dừng lại cái đã, khối việc cơm gáo gạo tiền đang đắp đống chờ giải quyết.
Có một điều tôi vẫn băn khoăn về câu trích ở đầu bài “do the right thing, then do it right” có phải là câu của chúa không nữa? Vì tôi thấy nó ở trong giáo dục, trong kinh doanh, trong quản lí, trong Scrum như đã kể ở trên. Và còn chỗ nào nữa mà nó không đúng?
Ai mà biết được?
Nhưng thôi, xin cảm ơn những người đã nhảy vào đầu tôi để có được bài viết dài nhằng không giống phong cách viết bình thường trên blog này. Cũng xin trân trọng bác nào đã đầy bao dung dung và kiên nhẫn để đọc tới dòng này của một bài viết cực kì hổ lốn như cái tiêu đề của nó. Em lượn đây 
Trong một entry trước, tôi đã có dịp chia sẻ một số hình ảnh của 5S, Kanban ở một trung tâm dịch vụ của Ford Motor tại Hà Nội.
Vừa rồi đi Pleiku lại chộp được mấy hình ảnh về Kaizen/5S ở thủy điện IALY. Có thể thấy Lean vào nước ta từ khá sớm. Nhưng có vẻ như chỉ dừng lại ở việc áp dụng 5S và Kaizen. Không biết Kaizen có phát huy tác dụng không (ở FPT thì rõ là không thấy phát huy mấy), nhưng tác dụng của 5S thì thấy rõ, cứ gọi là “sạch bong kin kít”.
Xem hình ảnh dưới đây:
