
Phát triển Phần mềm Tinh gọn (Lean Software Development)
Last updated: December 31, 2023 Xem trên toàn màn hình



- 04 Mar 2020
Kinh nghiệm lập dự toán chi phí dự án phần mềm theo phương pháp Man-Month 2138
- 01 Jul 2023
Phương pháp Shuhari - Làm sao học ít hiểu nhiều? 585
- 01 Aug 2022
"Sponsored Content" là gì? Khác nhau giữa Sponsored Content và Native Advertising? 519
- 01 Feb 2022
Thách thức với doanh nghiệp chuyển đổi số trong thời đại VUCA 494
- 04 Jan 2023
Phát triển phần mềm linh hoạt theo mô hình Big Bang 487
- 18 May 2021
Cây cầu hiện đại vô dụng nhất thế giới và câu chuyện cái kết của thay đổi yêu cầu 414
- 03 Mar 2020
Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 371
- 14 Jun 2021
8 loại lãng phí doanh nghiệp phải tìm cách loại bỏ 356
- 03 May 2022
Mô hình Hybrid Agile là gì? 353
- 01 Aug 2019
5 nguyên lý khởi nghiệp tinh gọn rút ra từ thực tế 331
- 15 Apr 2020
Phần mềm BPM là gì? So sánh với ERP và các phần mềm Workflows 329
- 09 Dec 2021
Sơ đồ chuỗi giá trị (Value Stream Mapping - VSM) là gì? 326
- 03 Feb 2020
Sản phẩm OEM và ODM là gì? 320
- 18 Mar 2021
Kỹ thuật ước lượng dự án phần mềm linh hoạt dựa vào Story Point - phương pháp T-Shirt Sizing 314
- 20 Jul 2021
Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 275
- 02 Aug 2021
Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 272
- 12 May 2021
Các yêu cầu thay đổi (Change Requests) - nỗi ám ảnh của team dự án phần mềm 267
- 14 Aug 2022
Khác biệt giữa tiêu chí hoàn thành DOD (Definition of Done) với tiêu chí nghiệm thu (Acceptance Criteria) 266
- 02 Aug 2023
Tổng hợp một số project tham khảo khi xây dựng các ứng dụng theo mô hình Microservices 257
- 12 May 2020
Quy trình sản xuất Tinh Gọn và áp dụng mô hình 5S của Nhật Bản 249
- 01 Aug 2023
Phân tích yêu cầu phần mềm sẽ nhìn vào thực trạng (AS-IS) hay tương lai (TO-BE)? 242
- 28 Jun 2024
Tại sao các kỹ sư IT giỏi nhất lại là những người theo thuyết bất khả tri về công nghệ (technology agnostics)? 226
- 04 Jan 2023
Đánh giá nhân sự theo chuẩn người Nhật 220
- 02 Mar 2018
Tại sao ví Scrum như dòng điện xoay chiều? 207
- 17 Aug 2020
Mục tiêu dự án là gì? Làm thế nào để xác định mục tiêu? 179
- 14 Apr 2019
Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 178
- 12 Sep 2021
Túi càn khôn của lập trình viên Agile cần trang bị những gì? 162
- 08 Jan 2022
Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 156
- 14 May 2024
Chiến lược răng lược là gì? Làm thế nào để tận dụng chiến lược răng lược trong kinh doanh? 147
- 08 Mar 2022
Mô hình nguồn mở hoạt động ra sao? 147
- 08 Mar 2020
Vì sao doanh nghiệp cần phải tạo Web bán hàng? 143
- 08 Feb 2021
Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 142
- 24 Mar 2019
Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 136
- 14 Dec 2022
Phương pháp kiểm tra Fagan Inspection là gì? 135
- 01 May 2023
[Tư vấn CNTT] Quản lý ngân sách CNTT cho doanh nghiệp 132
- 01 Apr 2022
Chi phí nhà thầu phụ chiếm bao nhiêu phần trăm gói thầu? 130
- 01 Sep 2020
Co-founder là gì? Vai trò của các Co-Founder khi lập nghiệp. 129
- 19 Aug 2020
Lift & Shift - Phương pháp tối ưu dịch chuyển hệ thống phần mềm qua đám mây 129
- 17 Feb 2018
Hệ luỵ khi sử dụng Web Hosting từ nhà cung cấp kém chất lượng 118
- 21 Apr 2020
Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 112
- 18 Mar 2018
Dịch vụ Hosting cho Website là gì? Các lời khuyên chọn Hosting tốt nhất 110
- 09 Feb 2021
Tầm nhìn là gì? Tí dụ minh họa cụ thể về tầm nhìn 103
- 03 Oct 2021
Khác biệt giữa thiết kế phần mềm và thiết kế công trình xây dựng 98
- 25 Apr 2018
Bảo hộ bản quyền phần mềm dưới khía cạnh sở hữu trí tuệ như thế nào? 86
- 22 Jul 2020
Quản lý dự án phần mềm trong thực tế và câu chuyện thành công của InfoSys 75
Hiện nay, trong quá trình phát triển phần mềm, một trong số những nguyên nhân thường xuyên khiến cho các dự án thất bại đó là nguyên nhân về thời gian. Vậy điều gì khiến các dự án thường thất bại trong việc bàn giao sản phẩm đúng thời hạn? Lý do chính của vấn đề này là thời hạn bàn giao sản phẩm thường được định ra trước khi dự án bắt đầu và ít có thay đổi còn yêu cầu về sản phẩm, quy trình làm việc thường xuyên bị thay đổi trong quá trình phát triển khiến thời gian bị trễ hơn so với khi dự tính. Chính vì vậy, để giải quyết vấn đề này, chúng ta cần hạn chế sự thay đổi trong quá trình phát triển. Vì vậy chúng ta cần tìm hiểu nguyên nhân chính của những thay đổi là gì? Có rất nhiều nguyên nhân nhưng phần lớn các thay đổi thường đến từ phía khách hàng. Cách dễ nhất để hạn chế điều này là đưa đến cho khách hàng những gì họ cần một cách nhanh nhất, khiến họ không có thời gian để thay đổi. Một ví dụ đơn giản như khi bạn mua hàng online, bởi vì thời gian giao hàng khá nhanh nên bạn chỉ có thời gian để suy nghĩ mình cần gì trước khi thực hiện việc mua bán, sau khi đặt hàng xong, bạn có rất ít thời gian để thay đổi. Đó chính là cốt lõi của quy trình phát triển phần mềm tinh gọn. Vậy quy trình phát triển tinh gọn là gì?
1. Khái niệm về quy trình phát triển tinh gọn
a. Nguồn gốc, xuất xứ
Quy trình phát triển tinh gọn (Lean) là quy trình được đưa ra bởi Toyota vào đầu những năm 1940. Và mục đích chính của nó là hướng đến công đoạn sản xuất. Tuy nhiên, điểm chung giữa quy trình sản xuất và quy trình phát triển phần mềm là đều hướng đến tính bền vững và đạt được lợi nhuận.
b. Khái niệm về quy trình phát triển tinh gọn
Cốt lõi của quá trình phát triển tinh gọn là hạn chế tối đa lãng phí- những yếu tố sẽ khiến chúng ta khó đạt được lợi nhuận tối đa từ khách hàng. Ví dụ như:
-
Hợp lý hóa chuỗi giá trị
-
Hạn chế lãng phí từ tiến trình
-
Xây dựng quy tắc cho thời điểm đưa ra quyết định
Một số ví dụ về những công ty đã áp dụng quy trình phát triển tinh gọn và thành công đó là IBM khi ra mắt DB2, salesforce.com đã thay đổi 1 tổ chức hơn 500 nhân viên thành mô hình phát triển agile, là Microsoft với việc thay đổi quy trình phát triển hệ điều hành và những công cụ phát triển phần mềm theo tiến trình phát triển tinh gọn.
2. Bảy nguyên tắc của quy trình phát triển tinh gọn
Để thực hiện đúng quy trình phát triển tinh gọn chúng ta cần tuân thủ 7 nguyên tắc dưới đây:
a. Hạn chế lãng phí (Eliminate waste)
-
Mọi quy trình tinh gọn đều bắt đầu từ việc xem xét và xác định lãng phí là gì và nó xuất hiện do đâu. Nói một cách đơn giản hơn thì tất cả những gì chúng ta thực hiện mà không mang lại giá trị thỏa mãn yêu cầu, mong muốn của khách hang thì đó chính là lãng phí.
-
Có 7 nguyên nhân thường gây lãng phí trong quá trình phát triển phần mềm như sau:
- Những phần việc chưa hoàn chỉnh ( Có thể là những quy trình chưa thực hiện hoàn chỉnh trong quá trình phát triển phần mềm. VD: tạo tài liệu, tạo testcase…)
- Những quy trình mở rộng
- Những chức năng mở rộng
- Thời gian chuyển giữa các phần công việc ( + Khi một người được giao quá nhiều nhiệm vụ trong dự án trong 1 thời điểm)
- Thời gian chờ ( Chờ bản thiết kế, chờ bản phân tích yêu cầu…)
- Thời gian chuyển giao sản phẩm
- Defect ( Những lỗi không được phát hiện trong quá trình kiểm thử…)
Mọi mục tiêu mà quy trình này hướng đến đó là tập trung vào tiến trình thực hiện từ lúc nhận được yêu cầu cho tới khi bàn giao sản phẩm. để thực hiện được điều đó, khi nhận được yêu cầu từ khách hàng, chúng ta cần đặt ra các câu hỏi: cần phải thực hiện những gì với yêu cầu đó để tiến hành bàn giao sản phẩm đúng thời hạn. Làm thế nào để tiến trình thực hiện yêu cầu là nhanh nhất có thể?
Một ví dụ nhỏ như sau: Trong trường hợp khách hàng yêu cầu chờ để xác nhận yêu cầu, chờ bản thiết kế, chờ để phát triển, chờ để kiểm thử… thì tiến trình công việc không thể nhanh và thực hiện liên tiếp được. Giải pháp ở đây là xây dựng một nhóm nòng cốt để biến những yêu cầu lớn thành những yêu cầu chi tiết hơn và thực hiện chúng một cách liên tiếp.
b. Nâng cao kiến thức (Create Knowledge)
Khuếch trương việc học (Amplify learning) hoặc Mở rộng tri thức (Create Knowledge).
Nguyên tắc cơ bản thứ 2 của quy trình phát triển tinh gọn là về kiến thức. Mỗi thành viên cần phải học hỏi nhiều nhất có thể để biết được mình làm gì là đúng với yêu cầu khách hàng đưa ra.
-
Tuy nhiên, môi trường phát triển phần mềm không yêu cầu mọi thứ phải hoàn hảo, không yêu cầu chúng ta phải lên kế hoạch và chỉ làm việc theo kế hoạch, không yêu cầu phải thực hiện đúng ngay từ lần đầu tiên…
-
Quy trình phát triển phần mềm tinh gọn tập trung vào việc tăng các phản hồi và rút ra bài học từ đó.
c. Trì hoãn quyết định (Defer commitment)
Quyết định càng muộn càng tốt.
-
Trì hoãn quyết định là nguyên tắc giúp cho các quyết định trở nên linh hoạt hết mức có thể trong thời gian cho phép trong các trường hợp chưa chắc chắn về yêu cầu khách hàng đưa ra. Ví dụ như khi được khách hàng đưa ra một yêu cầu mà chưa rõ cách giải quyết, chúng ta có thể thực hiện prototype bàn giao trước cho khách hàng, sau đó nhận phản hồi và thực hiện đúng với yêu cầu.
-
Có rất nhiều cách để thực hiện nguyên tắc trên. Ví dụ như:
Chia sẻ từng phần thiết kế hoàn chỉnh Tổ chức, hợp tác trực tiếp giữa các thành viên cùng mục đích Xây dựng các yếu tố phát hiện ra thời điểm chính xác để đưa ra các quyết định Xây dựng các yếu tố hạn chế thay đổi Sử dụng các bộ kiểm thử tự động
d. Chuyển giao càng nhanh càng tốt (Deliver fast)
Chuyển giao sản phẩm nhanh hết mức có thể. điều này giúp hạn chế được các công việc tồn đọng trong mỗi chu trình, đưa lại cho chúng ta những phản hồi nhanh nhất và cho phép chúng ta thực hiện những điều đúng đắn trong chu trình tiếp theo.
e. Trao quyền quyết định cho đội phát triển (Empowerthe team)
Trong quy trình phát triển tinh gọn, mọi việc đều diễn biến rất nhanh, và việc quyết định cần làm gì, làm gì mới đúng cần phải được quyết định bởi những người trực tiếp thực hiện điều đó. Tiến trình trong tổ chức tinh gọn được dựa trên những thành viên của tổ chức, không phải dựa trên chỉ thị từ phía quản lý.
f. Cải tiến liên tục về chất (Build quality in)
Nếu chúng ta muốn của bàn giao sản phẩm nhanh điều đó phụ thuộc vào việc phản hồi của khách hàng, nếu chúng ta muốn thỏa mãn yêu cầu của khách hàng một cách tối đa thì không thể coi nhẹ chất lượng sản phẩm.
g. Có cái nhìn bao quát (Optimize the whole)
Trong quá trình phát triển phần mềm, để tránh việc xung đột giữa các tính năng trong một sản phẩm, cần phải chú ý đến nguyên nhân của từng xung đột và giải quyết chúng triệt để.
