Như là một trong các phương pháp thuộc họ “Phát triển Phần mềm Linh hoạt” (Agile Software Development), Phát triển Phần Mềm Tinh gọn (Lean Software Development, hay gọi tắt là Lean Development) là một phiên bản của phương pháp Sản xuất Tinh gọn (Lean Manufacturing) áp dụng cho lĩnh vực phát triển phần mềm. Thuật ngữ “Lean Software Development” xuất xứ từ cuốn sách cùng tên của Mary Poppendieck và Tom Poppendieck. Cuốn sách diễn dịch lại tư duy Tinh gọn với ý nghĩa mới kèm theo các công cụ hữu hiệu để triển khai trong thực tiễn.
Trong đó “Bảy nguyên lí” diễn giải Tư duy Tinh gọn trong việc phát triển phần mềm là linh hồn cho quá trình phát tiển phần mềm tinh gọn. Chúng được mô tả ngắn gọn như dưới đây:
1. Loại bỏ lãng phí
Tất cả mọi thứ không tăng thêm giá trị cho khách hàng được coi là lãng phí (Muda). Chúng bao gồm:
- mã nguồn và chức năng không cần thiết
- sự chậm trễ trong quá trình phát triển phần mềm
- yêu cầu không rõ ràng
- kiểm thử không đủ, để lặp lại quá trình có thể tránh được
- quan liêu
- giao tiếp nội bộ chậm chạp
Để có thể loại bỏ lãng phí, người ta phải nhận ra nó. Nếu một số hoạt động có thể được bỏ qua, hoặc kết quả có thể đạt được mà không có nó, đó chính là lãng phí. Ví dụ về lãng phí trong phát triển phần mềm có thể kể đến: làm ra các code chưa hoàn thành rồi bỏ đi trong quá trình phát triển; các quy trình phụ và các tính năng không thường xuyên được sử dụng bởi khách hàng; chờ đợi cho các hoạt động khác, các đội khác, quy trình khác; sản phẩm có lỗi và chất lượng thấp; các công việc quản lí không tạo ra giá trị thực sự. Phát triển Tinh gọn tập trung loại bỏ các lãng phí để đạt trạng thái Tinh gọn, tạo điều kiện để đạt hiệu quả tối đa.
Để phân biệt và nhận ra lãng phí, kĩ thuật ánh xạ dòng giá trị được sử dụng. Trong đó, một dòng giá trị bắt đầu khi một đơn vị kinh doanh quyết định rằng thông tin tốt hơn sẽ giúp tăng doanh thu hoặc giảm chi phí. Đây là sự bắt đầu của dòng giá trị. Các dòng giá trị kết thúc khi phần mềm được triển khai bắt đầu tạo thêm doanh thu hoặc giảm chi phí. “Tồn kho” (inventory) trong dòng phần mềm giá trị phát triển là một phần thực hiện công việc: yêu cầu không được phân tích và thiết kế, bản thiết kế không được mã hóa, mã nguồn không được kiểm thử và tích hợp, các tính năng không được triển khai, các tính năng đã triển khai nhưng không phải tiết kiệm tiền hoặc giảm chi phí. Khi dòng giá trị phần mềm có ít công việc kiểu như thế, rủi ro sẽ được giảm và năng suất được cải thiện rất nhiều. Bước tiếp theo là chỉ ra nguồn lãng phí và loại bỏ chúng. Việc này cũng nên được thực hiện lặp đi lặp lại loại bỏ hết các quy trình và thủ tục không cần thiết.
2. Khuếch trương việc học
Phát triển phần mềm là một quá trình học tập liên tục để tạo ra tri thức mới. Phương pháp tốt nhất để cải thiện một môi trường phát triển phần mềm là khuếch trương việc học tập.
Quá trình học tập được đẩy nhanh tiến độ bằng cách sử dụng các chu kỳ lặp đi lặp lại ngắn – cùng với kĩ thuật tái cấu trúc (refactoring ) và kiểm thử tích hợp. Tăng cường thông tin phản hồi thông qua các buổi họp ngắn với khách hàng để xác định tình hình hiện tại và phác thảo những nỗ lực phát triển và điều chỉnh để cải thiện trong tương lai. Trong những phiên làm việc này, cả hai đại diện khách hàng và đội ngũ phát triển tìm hiểu thêm về vấn đề và tìm ra các giải pháp để đi tiếp. Vì vậy, khách hàng hiểu rõ hơn về nhu cầu của họ, dựa trên kết quả hiện có của các nỗ lực phát triển, còn các nhà phát triển thì có thể tìm hiểu làm thế nào để đáp ứng tốt hơn những nhu cầu đó. Thay vì bổ sung thêm tài liệu hoặc kế hoạch chi tiết, các ý tưởng khác nhau có thể được thử nghiệm bằng cách viết mã và tạo ra các bản build. Quá trình thu thập yêu cầu người dùng có thể được đơn giản hóa bằng việc làm các bản mẫu: trình diễn các giao diện trên màn hình (screen) cho người sử dụng cuối cùng và nhận lấy các dữ liệu của họ. Một ý tưởng quan trọng khác trong quá trình giao tiếp và học tập với khách hàng là phát triển dựa-theo-lô (set-based development) – kĩ thuật này giúp tập trung vào trao đổi về các ràng buộc của các giải pháp trong tương lai, những ý tưởng nào không thực sự là giải pháp; từ đó thúc đẩy việc đưa ra giải pháp thông qua đối thoại với khách hàng.
3. Quyết định càng muộn càng tốt
Do việc phát triển phần mềm luôn đi kèm với nhiều yếu tố không chắc chắn, nên để có kết quả tốt hơn, chúng ta phải quyết định dựa trên nhiều lựa chọn (options), trì hoãn quyết định càng lâu càng tốt cho đến khi chúng có thể được thực hiện dựa trên dữ kiện thực tiễn (facts) chứ không phải trên các giả định và dự đoán không chắc chắn. Một hệ thống càng phức tạp, thì càng chứa nhiều khả năng thay đổi, do đó cần thiết phải tạo ra các “độ trễ” cho các quyết định quan trọng. Cách tiếp cận lặp (iterative) thúc đẩy nguyên tắc này – khả năng thích ứng với những thay đổi và sửa chữa những sai lầm, những thứ có thể rất tốn kém nếu được phát hiện muộn, sau khi hệ thống đã được phát hành.
Cách tiếp cận trì hoãn này cũng có thể giúp khách hành nhận ra được những yêu cầu thực sự của họ vốn chỉ tường minh khi họ đã có những trải nghiệm rõ ràng về sản phẩm. Sự trì hoãn này sẽ giúp khách hàng loại bỏ các yêu cầu vốn không ổn trong các giả định ban đầu, giúp giảm thiểu lãng phí.
4. Chuyển giao càng nhanh càng tốt
Càng phát hành sớm các gói sản phẩm, bạn càng nhận lại được nhiều phản hồi sớm hơn về sản phẩm, và chúng có thể được đưa vào các cải tiến trong các phân đoạn tiếp theo của quá trình phát triển. Phân đoạn càng ngắn thì quá trình học tập và giao tiếp càng hiệu quả.
Khách hàng thì luôn đánh giá cao việc chuyển giao nhanh chóng các sản phẩm chất lượn vì chúng thường mang lại sự gia tăng tính linh hoạt trong hoạt động của họ. Công ty có thể chuyển giao nhanh hơn tốc độ thay đổi tư duy của khách hàng.
Đây là nguyên lí bổ sung cho nguyên lí “Quyết định càng muộn càng tốt”: càng chuyển giao nhanh, bạn càng có cơ hội để trì hoãn các quyết định. Ví dụ: bạn có thể thay đổi một chức năng trong 1 tuần, khi đó bạn không phải quyết định điều gì cho tới tuần sau, trước khi sự thay đổi là thực sự cần thiết.
Nguyên lí này cũng cho phép triển khai “hệ thống kéo” (pull system) trong phần mềm. Theo đó, bạn chỉ phát triển những gì khách hàng đang muốn có, chứ không phải là những gì họ muốn “từ ngày hôm qua”, do vậy sẽ giảm được các “lãng phí” không cần thiết (là các chức năng sẽ không được dùng trong thực tế).
5. Trao quyền cho nhóm
Cách tiếp cận tinh gọn ủng hộ việc “tìm người giỏi và để cho họ làm công việc của riêng mình”, quy trình khích lệ, tìm lỗi, loại bỏ những trở ngại, và không quản lý vi mô. Các cấp quản lí không có việc chính là chỉ cho developer những gì họ phải làm, mà chủ yếu lắng nghe họ, đưa ra các phân tích, lời khuyên và tìm kiếm các cải tiến. Với niềm tin “tất cả là ở con người”, Lean ủng hộ chủ trương động viên và khuyến khích để vươn cao hơn trong công việc của mình. Các nhà phát triển nên được trao quyền tiếp cận khách hàng, các lãnh đạo cung cấp hỗ trợ và giúp đỡ trong các tình huống khó khăn, cũng như đảm bảo rằng sự hoài nghi không hủy hoại tinh thần của đội. Các quyết định đi từ dưới lên (bottom-up) chứ không chỉ là từ cấp lãnh đạo (top-down).
6. Tạo ra tính toàn vẹn tự thân
Hơn cả “chất lượng”, tính toàn vẹn (integrity) là điều khiến người dùng muốn dùng sản phẩm. Phần mềm cần được đặt trong một hệ thống đầy đủ để được phát triển cho đúng. Bản thân nó không phải là “cái đích”, phần mềm luôn là phương tiện để người dùng đạt được “đích”.
Toàn vẹn có hai dạng: toàn vẹn nhận thức( hay toàn vẹn ngoại tại- external integrity) và toàn vẹn khái niệm (hay toàn vẹn nội tại – internal integrity). Trong đó toàn vẹn ngoại tại phản ánh sự nhận thức từ phía khách hàng về sự cân bằng giữa chức năng, tính khả dụng, độ tin cậy và các yếu tố kinh tế.
Còn toàn vẹn nội tại có nghĩa là các thành phần riêng biệt của hệ thống làm việc tốt với nhau như một tổng thể với sự cân bằng giữa tính linh hoạt, khả năng bảo trì, sự hiệu quả và tính đáp ứng. Điều này có thể đạt được bằng sự hiểu biết các miền vấn đề và giải quyết nó cùng một lúc, không phải theo trình tự. Do đó cần có thông tin đầy đủ, đa chiều từ nhiều phía với các hình thức giao tiếp trực diện thay vì các mớ tài liệu dày cộm. Luồng thông tin cần phải là đa chiều: từ developer tới khách hàng và phản hồi ngược lại.
Để đạt được toàn vẹn nhận thức, cần phải có được toàn vẹn khái niệm trước đã.
Một trong những cách làm đúng đắn để có được sự toàn vẹn kiến trúc là tái cấu trúc. Cùng với sự gia tăng tính năng là sự gia tăng sự phức tạp và lộn xộn trong cơ sở mã nguồn (codebase). Tái cấu trúc để giữ tính đơn giản (simplicity), rõ ràng, tối thiểu hóa các tính năng trong các đoạn mã nguồn. Sự lặp lại trong mã nguồn là những dấu hiệu cho thấy có thiết kế mã xấu và cần phải tránh. Quá trình xây dựng hoàn chỉnh và tự động nên được đi kèm với một bộ đầy đủ và tự động hóa các kiểm thử mức lập trình (developer testing) và mức khách hàng (customer tests), có versioning thống nhất, đồng bộ và có ý nghĩa nghĩa. Cuối cùng, sự toàn vẹn cần được xác nhận với các kiểm thử kỹ lưỡng để đảm bảo hệ thống có những gì khách hàng mong đợi. Kiểm thử tự động cũng được coi là một phần của quá trình sản xuất, và do đó nếu chúng không có giá trị thì có thể bị xem là lãng phí. Kiểm thử tự động không phải là một mục tiêu, mà là một phương tiện để hoàn thành công việc, đặc biệt là trong việc giảm thiểu các lỗi.
7. Thấy toàn cảnh
Hệ thống phần mềm ngày nay không đơn giản là tổng gộp của các bộ phận, mà còn là sản phẩm của sự tương tác giữa các thành đó. Vì vậy cần thiết phải tính đến các tác động toàn cục khi thực hiện các công việc tối ưu hóa cục bộ.
Lỗi trong phần mềm có xu hướng tích lũy trong quá trình phát triển và có liên hệ chặt chẽ với nhau. Cần dừng lại và phân tích các triệu chứng bất ổn khi bắt gặp. Hãy truy nguyên gốc rễ vấn đề. Bằng cách phân rã các nhiệm vụ lớn thành các nhiệm vụ nhỏ hơn, và tiêu chuẩn hóa các giai đoạn phát triển khác nhau, nguyên nhân gốc rễ của các lỗi này cần được phát hiện và loại bỏ.
Tư duy Tinh gọn (Lean Thinking) phải được thấu hiểu bởi tất cả các thành viên của dự án, trước khi triển khai thực hiện trong một tình huống cụ thể, thực tế cuộc sống, suy nghĩ. “Hãy suy nghĩ lớn, hành động nhỏ, thất bại nhanh chóng, và học ngay tức thì”. Chỉ khi tất cả các nguyên tắc tinh gọn được tuân thủ đầy đủ, kết hợp với các triển khai phù hợp với môi trường làm việc, chúng ta mới có một cơ sở cho sự thành công trong phát triển phần mềm tinh gọn.
Xem thêm:
- http://www.citerus.se/post/220180-interview-with-mary-poppendieck-an-introduction
- http://www.agilealliance.org/resources/articles/
- Mary & Tom Poppendieck: Lean Software Development: An Agile Toolkit, Addison-Wesley, 2003
Phương Tây thường nhờ cái nguyên lý của sự lợi mình và chủ nghĩa riêng một mình (1) để phát triển được cái sức làm giàu chung cho xã hội, nhờ cái nguyên lý ganh đua (2) nên sản nghiệp phát đạt và khoa học tiến bộ.Ở nước ta, nói tới sự ganh đua thì chỉ muốn xâm chiếm người khác; nói về sự lợi mình và chủ nghĩa riêng từng người thì bỏ cả hạnh phúc xã hội chẳng tưởng đến chi.Có thể nói một câu là những đức tính tốt ta dường như hết cả, mà chỗ hay của người chưa học được một chữ nào, những điều góp nhặt được phần nhiều là chỗ kém của ta đấy thôi.
Đó là tiêu đề của một nghiên cứu do nhóm tác giả Álvaro Soria, Marcelo R. Campo, và Guillermo Rodríguez thuộc Viện Nghiên cứu ISISTAN, Đại học UNICEN, Argentina thực hiện, và đã trình bày trong Hội thảo Kĩ thuật Phần mềm ASSE 2012.
Các tác giả đã cho thấy việc áp dụng RUP cho sinh viên sẽ khiến cho việc dạy học Software Engineering khó đạt được mục tiêu như đề ra. Và việc áp dụng phương pháp quản lí linh hoạt dựa trên Scrum, kết hợp với đề cương định hướng theo CMMI ver.1.3 sẽ giải quyết được các khó khăn mà việc dạy học SE theo lối truyền thống vấp phải. Trong cải tiến này, các GS trở thành các Agile Coach để giúp đỡ các nhóm làm việc và học tập, các Sinh viên tham gia trực tiếp vào các Development Project vận hành theo Scrum với các vai trò ScrumMaster, Team, Product Owner tiêu chuẩn. Việc đưa Scrum vào đề cương môn học có thể giúp sinh viên có được môi trường làm việc nhóm tốt hơn, giao tiếp hieuj quả hơn, và mang lại chất lượng phần mềm cao hơn. Ngoài ra, việc các Giáo sư giữ vai trò Agile coach sẽ giúp định hướng sinh viên và đối mặt với các trở ngại trong quá trình phát triển phần mềm.
Bài báo kết thúc bằng một nhận định thận trọng rằng “ dạy phát triển phần mềm bằng Scrum có vẻ sẽ hiệu quả hơn là phương pháp truyền thống”, và “chiến lược dạy học này có thể giúp sinh viên tham gia tốt hơn vào thị trường lao động”. Có một điều họ chắc chắn là Scrum giúp cho việc lĩnh hội các practices của CMMI nhẹ nhàng và hiệu quả hơn như bảng đối chiếu dưới đây:
ID | CMMI Practices | Scrum Practices |
1 | Thiết lập và duy trì các ước lượng các Tham số Lập kế hoạch | Thiết lập giai đoạn tiền-cuộc chơi (Pre-game Phase), và chơi Planning Poker |
2 | Thiết lập và duy trì một Kế hoạch Dự án như là điều căn bản của việc quản lí | Thiết lập Tầm nhìn, Định nghĩa và duy trì Product Backlog |
3 | Thiết lập và duy trì sự Cam kết Kế hoạch dự án | Thực hiện họp kế hoạch trực diện |
4 | Lựa chọn giải pháp sản phẩm hoặc các thành phần (product component) từ nhiều phương án khác nhau | Phát triển dựa trên vòng đời tăng trưởng và lặp |
5 | Phát triển bản thiết kế sản phẩm hoặc thành phần | Phát triển dựa trên vòng đời tăng trưởng và lặp |
6 | Thực hiện việc chuẩn bị cho kiểm định (verifcation) | Thiết lập “Tiêu chuẩn Hoàn thành”, thực hiện các buổi Sơ kết Sprint (Sprint Review) |
7 | Kiểm định các công việc dựa trên các yêu cầu phần mềm | Thực hiện kiểm định dựa trên “Tiêu chuẩn Hoàn thành” trong các buổi sơ kết |
8 | Chuẩn bị cho việc validation | Để các bên liên quan tham gia xác minh |
9 | Xác minh sản phẩm hoặc thành phần của sản phẩm để đảm bảo chúng là khả dụng trong môi trường vận hành | Thực hiện vai trò Product Owner và Scrum Master |
10 | Tạo các giao tiếp (interface) cho các thành phần, tương thích cả trong lẫn ngoài | Định nghĩa trong các Product Backlog |
11 | Tích hợp và ráp nối các thành phần, chuyển giao sản phẩm qua kiểm thử | Chuyển giao sản phẩm tăng trưởng (increment) |
12 | Chuẩn bị cho việc quản lí rủi ro | Định nghĩa Product Backlog Nhận diện các epic |
13 | Nhận biết và phân tích rủi ro để xác định tầm quan trọng tương đối của chúng | Thực hiện các cuộc họp hằng ngày |
14 | Giảm thiểu rủi ro | Thực hiện các cuộc họp hằng ngày Nhận biết các chướng ngại (impediments) |
15 | Quản lí yêu cầu và nhận biết các điểm thiếu nhất quán với kế hoạch và sản phảm | Thiết lập giai đoạn tiền-cuộc chơi (Pre-game Phase), và chơi Planning Poker Thực hiện họp kế hoạch trực diện Họp sơ kết sprint Quản lí User Stories trong Sprint Backlog |
16 | Theo dõi hiệu suất thực và tiến độ thực của dự án dựa trên kế hoạch | Thực hiện các cuộc họp hằng ngày Triển khai các cuộc họp Rà soát-Cải tiến (Retrospectives) |
17 | Thực hiện các hành động khắc phục khi tiến độ và hiệu suất không như mong đợi | Họp Sơ kết (review) Họp hằng ngày |
18 | Đánh giá khách quan sự tuân thủ các mô tả về quy trình, tiêu chuẩn và thủ tục | Triển khai các cuộc họp Rà soát-Cải tiến (Retrospectives) |
19 | Theo dõi và truyền thông các điểm không phù hợp và thực hiện biện pháp khắc phục | Triển khai các cuộc họp Rà soát-Cải tiến (Retrospectives) |
PS. Scrum như trong bài báo đề cập thực ra là một triển khai đặc thù của nhóm tác giả, có kết hợp các agile practice khác, và sử dụng các thuật ngữ cũ hơn so với Định nghĩa trong Scrum Guide mới nhất của Ken Schwaber và Jeff Sutherland.
Cách triển khai theo lối kết hợp CMMI và Scrum là một phương án phổ biến hiện nay, vốn bị quy định bởi các ràng buộc kinh tế và thị trường. Jeff và Ken cho rằng đó vẫn chưa phải là một tiếp-cận-đúng, xem trong Software In 30 Days.
Tật đầu sổ là tật lười, tật làm biếng. Lười suy nghĩ thích nhàn nhã, thích ngồi không. Nếu máu chúng ta chạy mạnh thì tất chúng ta phải xung xăng làm cái nọ cái kia chớ vô vi thì chịu sao nổi. Vậy thì trong văn học thôi ta đừng dùng cái khẩu khí hát cô đầu nữa mà phải thế này: cúc cung tận tuỵ.Thứ hai là tật “một tấc đến giời”. Ngồi mà thanh tịnh vô vi thì dễ hiểu vũ trụ lắm: Ta cho vũ trụ là thế nào thì vũ trụ sẽ thế ấy chớ chi. Nhưng sự thật là ta phải đi nghiên cứu tìm tòi mới hiểu vũ trụ được. Một tật nữa là não(1) huyền hoặc, não chuộng thần quyền. Gần đây trong thơ văn có cái mốt nói chuyện Liêu Trai. Có những thi sĩ nhất định lấy hồ ly làm vợ và nếu buông cụ Bồ Tùng Linh ra thì họ không biết nói gì.
Xuân Diệu, Sinh viên với quốc văn, 1945
Trích từ “Thói hư tật xấu người Việt”,Vương Trí Nhàn.
Theo chương trình của Sterling Group, các Giáo sư từ UK đã có chuỗi bài giảng đầy ấn tượng trong khuôn khổ hoạt động của nhóm tại các trường đại học Việt Nam.
Thật thích khi được lắng nghe những thông tin thú vị từ GS Alison Halstead, trường Aston về đổi mới và truyền cảm hứng trong giáo dục. Bài thuyết trình của GS như là một câu truyện về những nỗ lực cải cách giáo dục UK do chính GS là một trong cách leader của chương trình này. Cách thức mà trường Aston, nhóm GS Halstead đang vận hành tại UK để tổ chức một trường học chất lượng cao cho học sinh từ 14-19 tuổi có thể là một case-study tuyệt vời cho các nhà quản lí giáo dục cũng như các nhà giáo tại Việt Nam.
Tôi đặc biệt chú ý đến hai việc:
1. Tự do tái thiết từ triết lí đến cách làm để thay đổi tận gốc vấn đề
Làm sao để cho học sinh hứng thú với Toán, Lí, Hóa khi chúng toàn là các công thức chán ngắt? Làm sao để các sinh viên kĩ thuật chịu khó học các môn này?
Gợi ý là: hãy cho họ tiếp xúc thật với điện tử, với iPad, với iPhone (những thứ không hề chán ngắt), rồi chỉ ra có “bài toán”, “công thức” nào trong đó. Điều này đòi hỏi phải vận hành lối học problem-based triệt để với thiết bị thật, người thật, bài toán thật v.v. Như Dewey từng mong ước: học sinh được trải nghiệm cuộc sống thật ngay khi học. Việc này đặt ra cả núi thách thức khác: làm sao để có thiết bị thật, công xưởng thật, kĩ sư thật, bài toán thật? rồi làm sao để lồng ghép các vấn đề cần dạy học trong đó, hay nói cách khác curriculum phải như thế nào? Họ có đầy đủ tự do để làm điều đó với một trường học hoàn toàn mới (xem tại: http://www.auea.co.uk/), với sự cải tổ cực kì quan trọng: gắn kết trường học – công ty.
2. Liên hệ education-industry cực tốt
Nhờ vào các chính sách CSR (Corpoprate-Social Responsibilities), họ đã kêu gọi được mạnh thường quân chính là cá big-players trong ngành engineering của UK (e-On, Royal Airforce, Goodrich, NationalGrid, v.v.) để hỗ trợ thiết bị, tutor, tiền tài, … đồng thời với việc học thực tập ngay tại công ty với thời gian 1 năm với các chuyên gia tại các công ty.
Ở Việt Nam, chỉ có FPT University là có chính sách rõ ràng cho việc này: học 3 năm đầu, thực tập (gần) 1 năm tại FSOFT, quay lại học nốt năm cuối trước khi ra trường. Tuy nhiên, chính sách này vẫn có vẻ vướng phải vấn đề cố hữu của việc “thực tập” của SV: sự kết nối trường-công ty có vẻ như chưa được “tới bến”, sự liên kết lỏng lẻo, giả tạo. Sinh viên chưa chắc chắn được đối mặt với “problem” thật, được tham gia giải quyết chúng với các “tutor” thật, cùng cho ra “sản phẩm” thật. Do vậy có thể nó chưa đạt được cái inspiration tốt như mong đợi. Tiếp cận của trường Aston thì khác hẳn về chất.
Trong phần thuyết trình này của GS Halstead, Mr. Trần Ngọc Tuấn có nêu vấn đề CSR gần như yếu hoặc không có ở hầu khắp các công ty Việt Nam khiến cho mối liên kết trường học – công ty là cực kì khó khăn. Tôi thì chưa có điều kiện nghiên cứu nhiều vấn đề này, nhưng có tự đặt ra một câu hỏi: liệu có thực sự khó khăn thế hay không? hay là do chúng ta chưa chịu ngồi với nhau? Ai cũng biết cái “gap” giữa trường học và công ty nó lớn, cần thu hẹp, nhưng liệu hành động đã đủ chưa? Có vẻ như chúng ta kêu ca nhiều hơn là bắt tay hành động thực sự kể cả với các nỗ lực tầm vĩ mô, cũng như ở tầm vi mô – vốn sát sườn với các trường học, đặc biệt là các trường tư. Với kinh nghiệm chủ quan, tôi thấy một số cơ sở giáo dục đã có sự kết nối rất tốt với các employer chủ chốt trong ngành để nâng cao chất lượng giáo dục, tăng employability của người học. Câu trả lời có sẵn ở chỗ họ rồi.
Tôi luận rằng người nước Nam ta khi túng thiếu thì lo lắng thở than, trong lúc đói lo một hồi mà thôi, chớ no không lo nữa.Người nước của chúng ta, bởi không từng trải ít thấy rộng ít nghe xa (…) hễ vừa mới động nở nòi ra một thí (1) là đổi tính đổi nết, làm bề làm thế (2), muốn nghỉ mà ăn chơi. Bởi làm sao vậy? Bởi trong trăm người mới có một thì là trong một xóm ở chừng một trăm, người ấy đã đặng trên mấy bợm (3) khác. Có bạc chục bạc trăm, cho vô cho ra, đã có người thiếu nợ mình rồi; cho nên hết muốn ráng sức nữa. Vì vậy nhiều khi nghèo nàn khổ sở trở lại. Đến lúc nghèo rồi lại than thở trách trời, sanh mình sao mà vận xấu, mới cho khá rồi lại làm cho nghèo, tại trời không thương.
Nhóm Scrum có hai đặc điểm cực kì quan trọng là: tự tổ chức (self-organizing) và liên chức năng (cross-functional). Về tự tổ chức, tự quản, tự định hướng thì dễ hiểu, nhưng thế nào là “liên chức năng”? Bài này mong muốn chỉ ra một số hiểu lầm thường gặp, cũng như đào sâu thêm về khái niệm này trong phạm vi Scrum Framework để người học và thực hành Scrum đỡ bị rơi vào các nghịch lí khi cố gắng đối lập Scrum với những gì hiện có.
Có người bảo “cá nhân trong nhóm liên chức năng biết làm tất cả mọi việc, trong nhóm Scrum không có ai là tester hết, không cần designer trong nhóm Scrum nữa, chỉ có developer thôi”.
Có người lại bảo “nhóm liên chức năng có nghĩa là ai cũng có thể làm được việc thay thế người khác, không cần phân vai rõ ràng, một người có vấn đề sẽ không ảnh hưởng đến cả nhóm”.
Có người thì cao hứng phát biểu “một nhóm mà liên chức năng thì siêu năng suất”.
Những nhận định trên trên đều không ổn, và chúng là các điển hình về các ngộ nhận khi đề cập đến nhóm Scrum.
Vậy nhóm liên chức năng là gì?
Đây không phải là khái niệm mới mẻ gì, và về cơ bản nó chưa có nhiều thay đổi trong cách định nghĩa: đó là một nhóm bao gồm nhiều cá nhân với các chuyên môn khác nhau được kết hợp lại cùng làm việc hướng tới một mục tiêu chung.
Trong đội dự án, các cá nhân có thể đến từ nhiều phòng ban chức năng khác nhau, cũng có thể xuất phát từ bên ngoài (khách hàng, các cá nhân có liên quan, chuyên gia tư vấn v.v.). Nhưng khi đã thành một đội (team), thì các cá nhân làm việc tập trung cho đội như là một đơn vị (unit) để hoàn tất mục tiêu chung. Bên trong nhóm liên chức năng không có các nhóm nhỏ khác. Ví dụ: một Nhóm Scrum “Alpha” được thành lập với một Product Owner, một Scrum Master, 2 Tester, 5 Developer, 1 Architect, 1 UX Designer sẽ không phân chia chức năng thành các nhóm nhỏ khác như nhóm Testing (2 người), nhóm Developement (5 người) … nữa, mà chỉ có một nhóm duy nhất “Alpha” với các cá nhân có các chuyên môn khác nhau, hợp thành một đội thống nhất để làm việc hướng tới sản phẩm cần phát triển. Trong cách nói của Ken và Jeff, tester hay analyst … đều là developer, họ là nhà phát triển nhưng có chuyên môn đặc thù là kiểm thử hay phân tích; developer trong trường hợp này không có ý nghĩa là coder\programer. Việc xóa nhòa các title này có mục đích là để gom mọi người vào một mục tiêu chung, không phân biệt “nhãn mác” (title): phát triển phần mềm.
Khác với nhóm liên chức năng, nhóm chức năng (functional team) thường chỉ phụ trách một loại công việc đặc thù. Ví dụ, phòng thiết kế thì không code, phòng test thì không có ai design. Công việc của nhóm chức năng thường có tính cô lập cao.
Có phải cứ “liên chức năng” thì nhóm sẽ năng suất hay không?
Hỏi cách khác, liệu cứ thành lập một nhóm Scrum với cách tổ chức liên chức năng như thế, thì nhóm sẽ ngay tức khắc sẽ gia tăng năng suất lao động?
Rõ là không dễ dàng như thế rồi.
Liên chức năng chỉ là một “cấu hình” trong các cách thức cấu tạo nhóm làm việc. Và cách cấu hình này cho phép hình thành một đội độc lập với đầy đủ các chuyên môn cần thiết để hoàn tất công việc, dưới dạng một ‘business unit’ ở mức tối giản. Sự độc lập này tạo điều kiện cho nhóm ra các quyết định kịp thời, chính xác và nhanh chóng mà không bị phụ thuộc các đơn vị khác. Ví như trong cách thức tổ chức các nhóm chức năng (functional teams), một công việc phải đi qua nhiều công đoạn, mỗi công đoạn lại do các nhóm [với các chức năng] khác nhau đảm nhiệm, và vì thế sự phụ thuộc (dependency) gia tăng, khiến cho sự linh hoạt giảm xuống, và có nguy cơ làm giảm sự hiệu quả cũng như năng suất của nhóm.
Về mặt lí thuyết, với cấu hình “liên chức năng”, Nhóm Scrum có khả năng trở thành một “work cell” và có được “luồng một sản phẩm” (thuật ngữ của Lean), từ đó vừa gia tăng năng suất, vừa gia tăng chất lượng sản phẩm; đồng thời tạo điều kiện để vận hành “hệ thống kéo” (cũng thuật ngữ Lean), giúp loại bỏ các lãng phí không cần thiết, tối ưu hóa giá trị.
Nhưng một nhóm bất kì đều phải trải qua các giai đoạn Hình thành>Bão tố>Ổn định>Hiệu suất>Thoái trào (theo Tuckman). Có nghĩa là nó không thể đạt được hiệu quả ngay khi mới thành lập được.
Mặt khác, về “hiệu suất”, Katzenbach và Smith chỉ ra rằng một nhóm phải mất khá nhiều nỗ lực mới đạt được thành quả thực sự. Nó sẽ phải trải qua các trạng thái như là một “nhúm” các cá nhân rời rạc, cho tới khi trở thành một nhóm thực sự, rồi mới phát huy hiệu quả cao.
Hiệu suất hay không do nhiều nguyên nhân cấu thành. Hiệu suất thường là cái cuối cùng trong tất cả các nỗ lực, mà “cấu hình nhóm” là một trong các nỗ lực như vậy. Nếu coi “cấu hình nhóm” là phần “cứng”, thì còn nhiều yếu tố nữa quyết định nhóm có “hiệu suất” không, chính là các phần “mềm” của nhóm: cách vận hành nhóm, quy tắc, phương pháp, sự lãnh đạo v.v. Trong Scrum, các yếu tố “mềm” này được phân bố rải rác trong chính sách trao quyền để nhóm “tự tổ chức” (self-organizing), “tự quản” (self-managing), “tự định hướng” (self-directed); trong các phân bố vai trò trong nhóm (ai lãnh đạo việc gì, ai phụ trách việc gì); các quy tắc và công cụ cộng tác (các burndown chart, backlogs, events, metrics); cho đến nguyên lí và cơ chế đảm bảo sự minh bạch trong làm việc v.v. Tất cả các yếu tố đó kết hợp nhuần nhuyễn với “cấu hình” mới tạo nên một nhóm cộng tác chặt chẽ, mau trưởng thành, sớm đạt được trạng thái năng suất cao. Lấy ví dụ, việc một nhóm liên chức năng được trao quyền tự tổ chức sẽ phát huy được sự chủ động, giảm thiểu phụ thuộc vào bên ngoài (hay bên trên); cũng do một nhóm liên chức năng đã có đủ các kĩ năng cần thiết để giải quyết vấn đề nên hoàn toàn có thể trao quyền cho nó để tự nó phát huy năng lực tập thể giải quyết vấn đề theo cách tốt nhất; nhờ đó sự liên chức năng kết hợp với sự tự quản, tự tổ chức có thể thúc đẩy các sáng kiến từ dưới lên (bottom-up), trực tiếp, nhanh chóng và chính xác. Khi đó, lãnh đạo\quản lí thực hiện công việc chủ yếu là xúc tiến quá trình cộng tác nhóm và tự quản của nhóm thông qua đảm bảo quy trình, loại bỏ trở ngại, thiết lập và duy trì môi trường thuận lợi, thúc đẩy tiến trình thanh tra-thích nghi, v.v. chứ không còn bám sát từng đầu công việc nữa. Việc này đã được quy định chặt chẽ trong “mô tả công việc” của từng vai trò (Scrum Master, Product Owner, DevTeam) rồi.
Thế còn chuyện “liên chức năng thì không bị ảnh hưởng bởi xáo trộn cá nhân”? Chuyện một cá nhân ra đi mà nhóm không có xáo trộn chỉ là ảo tưởng. Chỉ có robot mới có thể đáp ứng được yêu cầu đó. Theo hướng đó thì chỉ việc đề cao quy trình, quản lí thật chặt đầu công việc của member theo lối “công nhân” tay chân, giao cho các công việc cố định, xếp vào các vị trí và công đoạn được mô tả rõ ràng Việc này khả thi ở chỗ khác, chứ tuyệt nhiên khó hiệu quả ở đội phát triển phần mềm vốn có bản chất phức tạp, và rất đa dạng trong từng công việc. Hơn thế nữa, việc gán chuyện “không xáo trộn” như vậy cho nhóm liên chức năng còn phản lại nguyên lí của Agile: “Cá nhân và tương tác hơn là quy trình và công cụ”. Cá nhân là tiền đề của nhóm, là nơi quyết định thành bại của nhóm. Nhưng cá nhân ấy là cá nhân đặt trong nhóm cộng tác, với các đòi hỏi cao về các “tương tác” có chất lượng thì mới giải phóng được năng lực của chính các cá nhân ấy. Còn “quy trình” chỉ là cái hỗ trợ cho việc phát huy năng lực của cả nhóm. Nhóm làm việc bao giờ cũng hướng tới sự gắn kết cao độ, càng gắn kết thì lại càng dễ bị xáo trộn bởi sự thay đổi của cá nhân trong nhóm. Nhóm liên chức năng có thể có một ưu điểm trong việc hỗ trợ nhau trong công việc (do đòi hỏi cộng tác chặt chẽ, sự minh bạch trong công việc, cũng như đó là một nhóm-học-tập liên tục), nên có thể giảm thiểu rủi ro của việc mất đi “chuyên gia”, nhưng việc xáo trộn, thậm chí sốc, là không thể tránh khỏi.
Cuối cùng, có phải trong Nhóm Scrum không còn tester, không còn QA nữa, mà chỉ còn developer? developer phải là dân “xịn” biết test ngon, biết code giỏi, biết design khéo? Cũng là ảo tưởng nốt! Và ảo tưởng này xuất hiện đơn giản là xuất phát từ việc hiểu nhầm khái niệm “cross-functionality” như đã nói ở bên trên.
Tìm kiếm
Sách mới: Tư duy thiết kế cho mọi người
Chuyên mục
- Agile Mindset (150)
- Chuyện đời (22)
- Công nghệ (14)
- Đọc (75)
- Sách (46)
- Giáo dục (200)
- Constructivism (5)
- Học cách học (35)
- Khai phóng Giáo dục (22)
- Tu thân (5)
- Khác (15)
- Lean Startup (17)
- Linh tinh xòe (53)
- Lan man (24)
- Quản trị mới (66)
- COVID19 (9)
- Tài nguyên (2)
- Tri thức và Nhận thức (18)
- Xã hội tri thức (24)
- Tổ chức học tập (20)