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
Recommended for you
- 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 27/2559 - 01 Jul 2023 Phương pháp Shuhari - Làm sao học ít hiểu nhiều? 19/961
- 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)? 13/403
- 20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 12/366
- 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) 9/490
- 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 9/370
- 01 Aug 2022 "Sponsored Content" là gì? Khác nhau giữa Sponsored Content và Native Advertising? 7/795
- 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 6/641
- 14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 6/409
- 04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 6/680
- 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 6/414
- 04 Jan 2023 Đánh giá nhân sự theo chuẩn người Nhật 6/384
- 09 Dec 2021 Sơ đồ chuỗi giá trị (Value Stream Mapping - VSM) là gì? 5/485
- 01 Apr 2022 Chi phí nhà thầu phụ chiếm bao nhiêu phần trăm gói thầu? 5/158
- 01 Sep 2020 Co-founder là gì? Vai trò của các Co-Founder khi lập nghiệp. 5/224
- 15 Apr 2020 Phần mềm BPM là gì? So sánh với ERP và các phần mềm Workflows 5/553
- 03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 4/495
- 02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 4/322
- 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)? 4/309
- 08 Mar 2022 Mô hình nguồn mở hoạt động ra sao? 3/197
- 01 May 2023 [Tư vấn CNTT] Quản lý ngân sách CNTT cho doanh nghiệp 3/169
- 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 3/478
- 08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 3/239
- 23 Feb 2023 "Tinh Gọn" là gì? "Tinh Gọn" có thực sự chỉ là cách dịch từ "Lean"? 3/118
- 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ì? 2/222
- 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? 2/209
- 14 Jun 2021 8 loại lãng phí doanh nghiệp phải tìm cách loại bỏ 2/425
- 08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 2/190
- 08 Mar 2020 Vì sao doanh nghiệp cần phải tạo Web bán hàng? 2/161
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 2/164
- 03 May 2022 Mô hình Hybrid Agile là gì? 2/459
- 01 Feb 2022 Thách thức với doanh nghiệp chuyển đổi số trong thời đại VUCA 2/688
- 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 1/95
- 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 1/396
- 17 Aug 2020 Mục tiêu dự án là gì? Làm thế nào để xác định mục tiêu? 1/223
- 18 Mar 2018 Dịch vụ Hosting cho Website là gì? Các lời khuyên chọn Hosting tốt nhất 1/235
- 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? 1/142
- 03 Feb 2020 Sản phẩm OEM và ODM là gì? 1/455
- 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 1/148
- 09 Feb 2021 Tầm nhìn là gì? Tí dụ minh họa cụ thể về tầm nhìn 1/124
- 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 1/504
- 24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 1/278
- 01 Aug 2019 5 nguyên lý khởi nghiệp tinh gọn rút ra từ thực tế 1/395
- 17 Feb 2018 Hệ luỵ khi sử dụng Web Hosting từ nhà cung cấp kém chất lượng /140
- 21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì /250
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 để.
Khám phá thêm các chủ đề sau
Đọc thêm: Hướng dẫn hợp tác viết bài (guest blogging)
Các chủ đề được quan tâm nhiều nhất
CHIA SẺ BÀI VIẾT
Link copied!
Mới cập nhật