Quản trị dự án

Lean – Tinh gọn hóa quy trình một cách hiệu quả

Các nhóm Agile biết rằng họ luôn có thể cải tiến cách họ làm việc sao cho hiệu quả hơn. Các thành viên trong nhóm có tư duy Lean rất giỏi trong việc tìm ra các hạng mục sẽ không mang lại giá trị nếu mà họ dành thời gian thực hiện những việc đó. Sau đó, họ loại bỏ các yếu tố đang làm cho công việc của họ bị chậm lại. Hãy sẵn sàng để tìm hiểu xem Lean hoạt động như thế nào, ứng dụng ra sao và đây có thật sự là tư duy nên áp dụng trong thực tiễn hay không?

 

Mô hình phát triển sản phẩm tinh gọn – Lean

Nói một cách chính xác, Lean không phải là một phương pháp luận Agile; tuy nhiên, cách tiếp cận Lean phù hợp và liên quan chặt chẽ với Agile. Lean bắt nguồn từ hệ thống sản xuất xe hơi của Toyota được cải tiến dựa trên hệ thống sản xuất xe hơi hàng loạt của Henry Ford. Vì vậy, Lean tiếp cận đầu tiên trong lĩnh vực sản xuất, sau đó được áp dụng cho phát triển phần mềm và cuối cùng được điều chỉnh cho các loại công việc tri thức khác.

Khi đề cập đến Lean trong bối cảnh Agile, chúng ta thực sự đang nói về một tập con của Lean được gọi là “phát triển sản phẩm tinh gọn” – “Lean Product Development”. Trong khi các hệ thống Lean nguyên thủy thiên về dây chuyền sản xuất sản phẩm, thì việc phát triển sản phẩm tinh gọn – Lean liên quan đến việc phát triển các sản phẩm mới và tốt hơn. Các nguyên tắc tổng quát của phát triển sản phẩm tinh gọn bao gồm:

  • Sử dụng các công cụ quản lý trực quan
  • Xác định giá trị đem lại cho khách hàng
  • Trao dồi kiến thức và cải tiến liên tục

Agile và Lean có liên quan như thế nào?

Các nguyên tắc tổng quát của Lean được liệt kê ở trên cũng là nguyên tắc chung cho Kanban và tất cả các phương pháp Agile khác. Mặc dù có nhiều ý kiến khác nhau, nhưng chúng ta có thể thấy tư duy Lean là một tập hợp bao trùm các phương pháp Agile và Kanban. Theo quan điểm này, phát triển sản phẩm tinh gọn – Lean, Kanban và các phương pháp Agile đều là những thể hiện chuyên biệt của tư duy Lean – Lean Thinking, và bổ sung thêm những tính chất riêng của từng phương pháp cụ thể. Quan điểm này có thể giúp chúng ta hiểu mối quan hệ giữa Lean, Kanban và Agile.

7 Nguyên tắc cốt lõi của Lean

Lean tập trung vào bảy nguyên tắc cốt lõi, như được hiển thị bên dưới:

 

Hãy xem xét 7 nguyên tắc này chi tiết hơn:

  • Eliminate waste – Loại bỏ lãng phí: Để tối đa hóa giá trị, chúng ta phải giảm thiểu lãng phí. Trong công việc tri thức, lãng phí có thể ở dạng công việc chỉ hoàn thành một phần, sự chậm trễ, quá trình chuyển giao, các tính năng không cần thiết, v.v. Vì vậy, để tối đa hóa giá trị mà chúng ta nhận được từ các dự án, chúng ta phải tìm cách để xác định và sau đó loại bỏ lãng phí. Chẳng hạn như nhóm của bạn đang viết tài liệu mà không ai đọc? Hay việc bạn đang dành rất nhiều thời gian để làm công việc theo cách thủ công thay vì có thể được tự động hóa? Cũng có thể là việc bỏ nhiều công sức vào việc thảo luận và ước lượng các tính năng mà các tính năng này có thể không cần thiết?
  • Empower the team – Trao quyền cho nhóm: Thay vì áp dụng phương pháp quản lý vi mô (sâu sát tới từng cá nhân, từng công việc), chúng ta nên tôn trọng kiến ​​thức chuyên môn của các thành viên trong nhóm, để họ đưa ra các quyết định về công việc cần thiết trong dự án, để họ tự tổ chức miễn sao cho công việc đạt được hiệu quả và dự án thành công.
  • Deliver fast – Phân phối nhanh: Chúng ta có thể tối đa hóa lợi ích đem lại (ROI) của dự án bằng cách nhanh chóng đưa ra/bàn giao các sản phẩm có giá trị cho khách hàng thông qua các lần lặp (iteration) và phát hành (release). Chúng ta sẽ tìm ra giải pháp tốt nhất thông qua quá trình phân phối nhanh này. Một cách mà Lean giúp các nhóm tập trung vào việc phân phối giá trị càng sớm càng tốt là xác định điều nhỏ nhất tạo ra giá trị mà họ có thể cung cấp và sau đó tập trung cả nhóm vào việc phân phối nó nhanh nhất có thể. Các nhóm Lean thường nói về các tính năng tiếp thị tối thiểu (Minimally Marketable Features – MMF) như một mục tiêu cho mỗi đợt release. Tương tự, xác định sản phẩm nhỏ nhất đem lại giá trị cho khách hàng — gọi là Sản phẩm khả thi tối thiểu (Minimally Viable Product – MVP). Bằng cách tập trung vào việc phân phối MMF và MVP, các nhóm Lean đảm bảo rằng họ có được sản phẩm có giá trị đến tay khách hàng càng sớm càng tốt.
  • Optimize the whole – Tối ưu hóa tổng thể: Chúng ta nên hướng đến việc xem xét các giải pháp, công việc, tối ưu ở mức độ toàn hệ thống chứ không chỉ là từng phần của hệ thống. Chúng ta cần tuy duy vượt ra ngoài các thành phần riêng lẻ của dự án và tìm cách triển khai sao cho nó phù hợp với tổ chức. Bên cạnh đó, để tối ưu hóa tổng thể, chúng ta cũng cần tập trung vào việc hình thành các mối quan hệ cộng tác giữa các nhóm tốt hơn.
  • Build quality in – Tích hợp chất lượng: Phát triển sản phẩm tinh gọn không cố gắng “kiểm tra” chất lượng của sản phẩm ở công đoạn cuối cùng; thay vào đó, chúng ta cần tích hợp chất lượng vào trong sản phẩm (từ khâu lên kế hoạch, thiết kế, xây dựng,…) và liên tục đảm bảo chất lượng trong suốt quá trình phát triển.
  • Defer decisions – Trì hoãn quyết định: Chúng ta cần cân bằng giữa việc lập kế hoạch sớm từ đầu với việc đưa ra các quyết định và cam kết càng trễ càng tốt. Ví dụ như việc đánh giá lại mức độ ưu tiên của các hạng mục trong product backlog trước mỗi iteration cũng chính là trì hoãn quyết định khi chúng ta có nhiều thông tin hơn để phù hợp với nhu cầu khách hàng, hoặc việc trì hoãn quyết định càng trễ càng tốt giúp tránh bị ràng buộc vào một giải pháp có giới hạn công nghệ ngay từ ban đầu.
  • Amplify learning – Mở rộng quá trình học tập: Khái niệm này liên quan đến việc tạo điều kiện trao đổi thông tin sớm và thường xuyên, nhận phản hồi càng sớm càng tốt và xây dựng sản phẩm, kinh nghiệm dựa trên những gì chúng ta học được. Vì các dự án có đặc thù là công việc tri thức thường dựa trên việc khám phá những điều không chắc chắn thông qua trải nghiệm/thử sai, chúng ta nên bắt đầu sớm và liên tục học hỏi.
Tham khảo:   Work Performance Data vs. Work Performance Information vs. Work Performance Reports

 

Ví dụ: Mối liên kết giữa các phương pháp thực hành của Agile với nguyên tắc Lean

Phương pháp thực hành Agile

Nguyên tắc Lean

Loại bỏ lãng phí

Trao quyền cho nhóm

Phân phối nhanh

Tối ưu hóa tổng thể

Tích hợp chất lượng

Trì hoãn quyết định

Mở rộng quá trình học tập

Các nhóm tự quyết định

 

x

 

 

 

 

 

Lập kế hoạch lặp lại vừa đúng thời điểm

 

 

 

 

 

 

 

Các cuộc họp retrospective

 

 

 

 

 

 

x

Mỗi iteration kéo dài 2 tuần

 

 

x

 

 

 

 

Thực hiện unit test trong quá trình phát triển phần mềm

 

 

 

 

x

 

 

Quan sát người dùng để học cách họ làm việc, thao tác

 

 

 

 

 

 

 

Các bản thiết kế nguyên mẫu chính là yêu cầu dự án

x

 

 

 

 

 

 

 

7 Loại lãng phí của Lean

Mặc dù tất cả các khái niệm ở trên đều quan trọng, nhưng mục tiêu loại bỏ lãng phí là động lực chính cho phương pháp tiếp cận Lean. Mary và Tom Poppendieck (các chuyên gia về Lean đã viết nhiều về việc sử dụng Lean trong các dự án phần mềm) đã chuyển đổi 7 loại lãng phí truyền thống trong quá trình sản xuất thành 7 loại lãng phí trong phát triển phần mềm, được minh họa trong bảng bên dưới đây:

 

Các loại lãng phí

Miêu tả

Ví dụ

Công việc hoàn thành một phần

Công việc đã bắt đầu, nhưng chưa hoàn thành; công việc được hoàn thành một phần có thể làm rối loạn, vì chúng ta không thực sự biết dự án đang tiến triển tới đâu

Code đang chờ test.

Các yêu cầu đang chờ được bắt đầu đưa vào xây dựng.

Các quy trình dư thừa

Công việc dư thừa không tăng thêm giá trị

Tài liệu không sử dụng đến.

Quy trình phê duyệt không cần thiết.

Tính năng dư thừa

Các tính năng không bắt buộc hoặc được coi là “có-thì-cũng-tốt”

Phần mềm kế toán có hiệu ứng 3D.

Sử dụng công nghệ quá phức tạp cho một tính năng đơn giản.

Nhảy việc – Đa nhiệm

Làm cùng lúc nhiều việc của nhiều dự án khác nhau

Thường xảy ra ở những người được giao cho nhiều dự án cùng lúc

Chờ

Sự chậm trễ khi chờ xem xét và phê duyệt

Chờ khách hàng đánh giá bản thiết kế

Chờ phê duyệt tài liệu

Chuyển giao/Bàn giao/Di chuyển

Nỗ lực cần thiết để truyền đạt hay phân phối thông tin từ nhóm này sang nhóm khác; nếu các nhóm không làm cùng một chỗ, việc truyền đạt sẽ tốn nhiều công sức hơn.

Các nhóm không làm cùng một chỗ.

Công việc bàn giao.

Sai sót/Lỗi

Tài liệu hoặc phần mềm bị lỗi cần sửa

Yêu cầu từ phía khách hàng bị sai.

Phần mềm bị lỗi.

Tham khảo:   Team charter (Điều lệ nhóm) là gì? Thành phần của Điều lệ nhóm?

 

Ví dụ: Phân loại lãng phí

Hoạt động

Loại lãng phí

Xếp hàng vào thang máy

Chờ

Khởi động lại máy tính sau khi hệ điều hành bị lỗi

Lỗi, Chờ

Lưu tài liệu ở định dạng cũ để tương thích với phần mềm cũ

Quy trình dư thừa, Chuyển giao

Tạo thông báo bằng tiếng Pháp và tiếng Tây Ban Nha để tuân thủ các tiêu chuẩn của công ty, mặc dù không ai ở công ty nói những ngôn ngữ này

Quy trình dư thừa, Tính năng dư thừa

Gửi đơn phê duyệt cho việc đặt hàng văn phòng phẩm

Quy trình dư thừa

Tất nhiên, những loại hoạt động này không phải lúc nào cũng lãng phí. Lãng phí chỉ xảy ra nếu không thu được bất kỳ lợi ích nào từ hoạt động này. Các thông báo an toàn nên được cung cấp cho bất kỳ ai cần, và các bản dịch không cần thiết của thông báo đó có thể bị coi là lãng phí. Tương tự như vậy, việc phê duyệt đơn đặt hàng văn phòng phẩm có thể hữu ích để ngăn việc lạm dụng, biển thủ, nhưng đối với những trường hợp chỉ cần một số vật dụng văn phòng phẩm cơ bản, quá trình này không có giá trị gì và có thể bị coi là lãng phí.

Value stream maps – Bản đồ luồng giá trị giúp thấy được sự lãng phí

Công cụ này sẽ giúp nhóm Lean tìm ra sự lãng phí trong quy trình họ đang sử dụng để xây dựng phần mềm. Để xây dựng bản đồ luồng giá trị, hãy nghĩ lại tất cả các bước mà nhóm đã thực hiện để xây dựng một tính năng, từ khi tính năng được thảo luận lần đầu tiên cho đến khi được chuyển giao. Ghi tên cho mỗi bước, sử dụng mũi tên để kết nối các bước. Tiếp theo, theo dõi lượng thời gian nhóm đã thực hiện từng bước và lượng thời gian phải chờ giữa mỗi bước. Thời gian chờ đợi giữa các bước được xem là lãng phí. Vẽ một đường đi lên để thể hiện rằng dự án đang hoạt động và đường đi xuống để thể hiện rằng dự án đang chờ.

Đôi khi, việc vẽ ra quy trình mà nhóm đang sử dụng sẽ giúp chỉ ra nơi lãng phí đang làm nhóm chậm lại. Bản đồ luồng giá trị giúp thấy được rõ ràng lượng thời gian mà nhóm đang dành cho công việc không mang lại giá trị cho khách hàng. Khi nhóm của bạn có thể thấy rõ sự lãng phí, họ có thể làm việc cùng nhau tìm ra cách giảm thời gian chờ đợi.

 

Cũng giống như Scrum tập trung vào tính minh bạch, kiểm tra và thích ứng, các nhóm Lean đo lường cách hệ thống của nhóm đang hoạt động trước khi thực hiện thay đổi và sau đó đo lường tác động của những thay đổi mà họ thực hiện. Thông qua những chỉ số:

  • Cycle time, hoặc lượng thời gian cần để hoàn thành một tính năng hay nhiệm vụ từ khi nhà bắt đầu làm việc cho đến khi được phân phối.
  • Một phép đo khác là Lead time, hoặc khoảng thời gian từ khi một tính năng được xác định cho đến khi được phân phối.
  • Cycle time và lead time giúp suy nghĩ về quy trình của nhóm từ hai khía cạnh khác nhau.
  • Khi ở trong một nhóm làm việc trên một hạng mục công việc, chúng ta thường nghĩ về cycle time hoặc khoảng thời gian đã trôi qua kể từ khi nhóm bắt đầu lập kế hoạch cho hạng mục công việc đó cho đến khi hoàn thành.
  • Nhưng khách hàng không thực sự thấy cycle time. Giả sử một khách hàng yêu cầu nhóm cung cấp một tính năng, nhưng nhóm không thể bắt đầu làm tính năng đó trong 6 tuần. Sau khi nhóm bắt đầu, phải mất 8 tuần để hoàn thành. Cycle time là 8 tuần, nhưng lead time là 14 tuần – và đó là phép đo mà khách hàng thực sự quan tâm.
  • Các nhóm cũng sẽ đo lường flow efficiency (hiệu quả của luồng giá trị), hoặc phần trăm thời gian cho một tính năng mà nhóm đã thực sự dành để thực hiện nó (thay vì chờ đợi):
Tham khảo:   Vai trò của Giám đốc dự án - Role of the Project Manager

Flow efficiency = 100 * Cycle time ÷ Lead time %

Tạo bản đồ luồng giá trị của lần release gần nhất là một cách tuyệt vời để giúp nhóm suy nghĩ về cách cải thiện quy trình của mình.

Tổng kết

Tư duy Lean là một cách tiếp vận vô cùng giá trị để loại bỏ các lãng phí, tối ưu hóa quá trình làm việc và tăng năng suất của nhóm. Tư duy Lean là nền tảng cho tất cả các phương pháp Agile. Taiichi Ohno (Hệ thống sản xuất Toyota, trang 9, CRC Press 1988) có nói: “Không có phương pháp thần kỳ nào cả. Thay vào đó, cần có một hệ thống quản lý tổng thể nhằm phát huy hết khả năng của con người, giúp nâng cao khả năng sáng tạo và đạt hiệu quả một cách tốt nhất, cũng như sử dụng tốt các phương tiện và máy móc, đồng thời loại bỏ mọi lãng phí.” Vì vậy, các nhóm đừng ngần ngại trao đổi, chia sẻ với nhau, nhằm tìm ra những lý do, gốc rễ vấn đề gây lãng phí để hoàn thành công việc, mục tiêu đã đề ra một cách hiệu quả.

 


Kiến thức tổng hợp bởi Masterskills (PMP, PMI-ACP, PMI-ATP Instructor) 

References: PMI – ACP Exam Prep by Mike Griffin, Head First Agile

 

Product Backlog là gì? Có quan hệ như thế nào với WBS

Bản tuyên ngôn Agile – lịch sử hình thành Agile

12 nguyên tắc của Agile

Trong dự án Agile, công việc ước tính có thật sự cần thiết?

Quản lý dự án với Scrum

Scrum of Scrums

User stories – Công cụ lên kế hoạch của Agile

Story points – Công cụ ước lượng của Agile

Velocity là gì – Công cụ đo lường tốc độ hoàn thành công việc của nhóm Agile

Story Map – Lập kế hoạch tổng quát trong Agile

Agile Retrospectives – Nhìn lại và cải tiến hiệu quả công việc dự án

Kanban – phương pháp giúp cải tiến quy trình làm việc của dự án

PDCA – Chu trình cải tiến liên tục

Personas – Công cụ xây dựng hình tượng khách hàng trong Agile

Hướng Dẫn Scrum – The Scrum Guide

Bóng đá có 3-5-2, Scrum có 3-5-3

Bắt đầu với Scrum từ đâu đây ta?

Một số cách chạy Daily scrum hiệu quả

 

  Viện Đào Tạo Kỹ Năng Masterskills chuyên Đào Tạo tại Doanh Nghiệp (In-house) trên Toàn Quốc  
G

0903966729

1
Hỗ trợ bạn qua Zalo