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
TPS – Toyota Production System- là kinh điển quản lí, xây dựng tổ chức trường tồn. Chính nó tạo nên và khuếch trương Tư duy Tinh gọn (Lean Thinking), Sản xuất Tinh gọn (Lean Manufacturing). Giờ đây Lean đã có ở mọi nơi: khởi sự, phát triển sản phẩm (đủ loại hình), dịch vụ. Dưới đây là tóm tắt 14 nguyên lí của nó:
Nguyên lí #1: Ra các quyết định quản lí dựa trên một triết lí dài hạn, dù phải hy sinh những mục tiêu ngắn hạn
- Trang bị một ý thức về mục tiêu có tính triết lí để thay thể bất kì một hình thức ra quyết định ngắn nhạn nào. Làm việc, phát triển và lèo lái theo mục đích chung lớn lao hơn là chỉ kiếm tiền.
- Tạo ra giá trị cho khách hàng, cho cộng đồng và cho nền kinh tế. Đó là khởi điểm.
- Có trách nhiệm
Nguyên lí #2: Tạo ra một chuối quy trình liên tục làm bộc lộ sai sót
- Tái thiết các quy trình nghiệp vụ để đạt được một luồng liên tục có giá trị gia tăng cao. Triệt tiêu thời gian chết trong các quy trình.
- Liên kết các thông tin, nhân sự, chu trình để phát hiện tức thì các trục trặc
- Làm chuỗi giá trị trở nên rõ nét trong văn hóa của công ty, làm chìa khóa cho quy trình cải tiến liên tục và phát triển nhân sự.
Nguyên lí #3: Sử dụng hệ thống kéo để tránh sản xuất quá mức
- Cung cấp đúng cái khách hàng cuối cần, đúng thời điểm, đúng số lượng họ mong muốn.
- Tối thiếu hóa khối lượng công việc trong qui trình (Work-In-Progress:WIP)
- Đáp ứng tốt với các thay đổi hằng ngày
Nguyên lí #4: Bình chuẩn hóa lượng công việc
- San bằng sự trồi sụt trong kế hoạch sản xuất
- Dàn đều khối lượng công việc tại tất cả các quy trình nghiệp vụ, thay thế hình thức sản xuất ngừng/chạy
Nguyên lí #5: Xây dựng thói quen biết dừng lại để giải quyết trục trặc, đạt đến chất lượng tốt ngay từ ban đầu
- Chất lượng là động cơ xác định giá trị
- Tự nhận biết trục trặc và tự dừng lại. Tự kiểm lỗi (Self-check) là nền tảng để xây dựng chất lượng.
- Thiết lập hệ thống phụ trợ để nhanh chóng giải quyết trục trặc
- Xây dựng văn hóa biết dừng lại và chậm rãi để có chất lượng ngay từ đầu
Nguyên lí #6: Chuẩn hóa các nghiệp vụ là nền tảng của sự cải tiến liên tục cùng việc giao quyền cho nhân viên
- Sử dụng biện pháp ổn định lặp lại thường xuyên tại mọi khu vực để duy trì khả năng phán đoán, nhịp dộ sản xuất cùng với thông lượng đều đặn của các quy trình. Đây là nền tảng của luồng một sản phẩm (one-piece-flow) và hệ thống kéo (pull system).
- Tiêu chuẩn hóa các thói quen làm việc tốt. Cải tiến các tiêu chuẩn không ngừng.
Nguyên lí #7: Quản lí trực quan để không có trục trặc nào bị che khuất
- Dùng chỉ dẫn hình ảnh để nhận biết sớm tình trạng công việc
- Thiết kế hệ thống bảng biểu hỗ trợ luồng một sản phẩm và hệ thống kéo
- Rút ngắn báo cáo xuống 1 trang giấy
Nguyên lí #8: Chỉ áp dụng các công nghệ tin cậy, đã được kiểm chứng toàn diện, để phục vụ cho các quy trình và con người của công ty.
- Công nghệ để hỗ trợ chứ không phải thay thế con người
- Kiểm nghiệm cẩn thận trước khi áp dụng
- Khuyến khích xem xét công nghệ mới, nhanh chóng triển khai nếu đã chín muồi
Nguyên lí #9: Phát triển những nhà lãnh đạo, người hiểu thấu đáo công việc, sống cùng triết lí và truyền đạt lại cho người khác
- Phát triển lãnh đạo từ bên trong công ty
- Lãnh đạo phải là hình mẫu cho triết lí và cách thức kinh doanh của công ty
- Lãnh đạo phải am tường nghiệp vụ, là mentor khi cần truyền dạt văn hóa công ty
Nguyên lí #10: Phát triển các cá nhân và tập thể xuất sắc có thể tuân thủ triết lí của công ty
- Tạo dựng văn hóa mạnh và ổn định
- Đào tạo trong khuôn khổ văn hóa công ty
- Sử dụng nhóm liên chức năng để cải thiện chất lượng và năng suất công việc
- Liên tục huấn luyện làm việc nhóm vì mục tiêu chung
Nguyên lí #11: Tôn trọng mạng lưới đối tác và các nhà cung cấp bằng cách thử thách họ và giúp họ cải tiến
- Thử thách đối tác để họ phát triển
- Đặt mục tiêu và hỗ trợ đối tác để đạt mục tiêu
Nguyên lí #12: Đích thân đi đến và xem xét hiện trường để hiểu tường tận tình hình (Genchi Genbutsu)
- Đi đến nguồn gốc vấn đề, đích thân quan sát thực địa. Kể cả lãnh đạo cao cấp.
- Chỉ nghĩ và nói dựa trên dữ liệu thực tiễn đã được kiểm chứng
Nguyên lí #13: Ra quyết định không vội vã thông qua sự đồng thuận và xem xét kĩ lưỡng mọi khả năng, rồi nhanh chóng thực hiện
- Xem xét tất cả các khả năng trước khi quyết định. Khi quyết định rồi thì nhanh chóng thực hiện.
- Quyết định chậm nhất có thể.
Nguyên lí #14: Trở thành một tổ chức học hỏi bằng việc không ngừng tự phê bình và cải tiến liên tục (Kaizen)
- Khi có quy trình ổn định, dùng các công cụ cải tiến liên tục.
- Thiết lập quy trình tối thiểu hóa tồn kho.
- Củng cố tri thức của doanh nghiệp.
- Sử dụng phản tỉnh (hansei, reflection) tại những giai đoạn then chốt để thoải mái nhìn nhận sai sót, tránh lặp lại.
- Học tập thông qua tiêu chuẩn hóa những thói quen làm việc tốt
Sách Lean Startup có dạy rằng “fail fast” tức là hãy bắt tay vào việc và sẵn sàng đón nhận thất bại càng sớm càng tốt. Không phải đợi tới một năm thử nghiệm với bao nhiêu đầu tư, nguồn lực và hy vọng để rồi nhận ra mình sai lầm. Trong thế giới biến động không ngừng, sự tiên lượng dường như rất xa xỉ bởi sự phức tạp vượt quá tầm hiểu biết và kiểm soát của con người. Vì vậy cách thông minh hơn là đừng có tiên đoán cái gì xa quá, mà hãy tự tin mà “chập chững” bước đi; ta có thể ngã nhưng đứng dậy ngay được. Và hãy mong đợi những cú ngã như vậy.
Anh bạn quý mến phương Nam của tôi đã có hơn một năm rưỡi chuyển đổi thành công sang Agile cũng có chia sẻ kinh nghiệm “xương máu” như vậy:
1. Trong suy nghĩ, luôn cho phép mọi người mắc sai lầm, và cả chính mình nữa
2. Trong hành động, phải bắt tay vào ngay, không đợi đến khi bạn có đủ thông tin mới làm việc.
Sự khác biệt trong tiếp cận của Agile nói chung chính là ở chỗ này: thực tiễn sẽ dạy ta thông tin ta cần biết, cái ta cần phải làm. Và để biết được điều đó thì chỉ có một cách duy nhất là bắt tay vào thực tiễn và chấp nhận sai lầm. Và thông minh hơn nếu như ta có cách giảm thiểu rủi ro và thiệt hại (nếu có) của sai lầm ấy. Cách đó chính là việc “do small” – làm cái nhỏ thôi, và nhích lên từng bước một. Thất bại là mẹ của thành công. Sao lại phải sợ thất bại nhỉ !?
Tìm kiếm
Sách mới: Tư duy thiết kế cho mọi người
Bài viết mới
Đang được chú ý
Chuyên mục
- Agile Mindset (149)
- Chuyện đời (22)
- Công nghệ (14)
- Đọc (75)
- Sách (46)
- Giáo dục (197)
- Constructivism (5)
- Học cách học (35)
- Khai phóng Giáo dục (19)
- Tu thân (5)
- Khác (15)
- Lean Startup (16)
- Linh tinh xòe (53)
- Lan man (24)
- Quản trị mới (57)
- COVID19 (9)
- Tài nguyên (2)
- Tri thức và Nhận thức (17)
- Xã hội tri thức (23)
- Tổ chức học tập (20)