Giảm thời gian giải quyết và làm lại trong phát triển phần mềm – dự án Six Sigma Green Belt trong công nghệ thông tin (CNTT)

Bài báo này mô tả việc thực hiện thành công dự án Six Sigma Green Belt trong công nghệ thông tin (CNTT), trong đó nhóm phát triển phần mềm đã áp dụng Six Sigma để giảm thời gian giải quyết các lỗi phần mềm và giảm thiểu việc làm lại, do đó tăng sự hài lòng của khách hàng.

Một nhóm phát triển phần mềm trong một công ty dịch vụ môi trường hàng đầu muốn giảm thời gian giải quyết các lỗi phần mềm và thay đổi các yêu cầu do khách hàng nội bộ của công ty gửi. Nhóm CNTT đã sử dụng một ứng dụng theo dõi lỗi để theo dõi các yêu cầu và lỗi đã gửi. Các hạng mục công việc được giao cho các thành viên trong nhóm phát triển và thử nghiệm; mã cập nhật đã được phát hành vào môi trường sản xuất theo chu kỳ xây dựng mỗi tháng một lần.

Mục đích của dự án này là giảm thời gian phát triển và thử nghiệm của các hạng mục công việc và giảm thiểu việc làm lại tốn kém bằng cách sử dụng DMAIC (Xác định, Đo lường, Phân tích, Cải thiện, Kiểm soát). Trong khuôn khổ của bài viết này, làm lại được định nghĩa là xem lại một hạng mục công việc sau khi nó được coi là đã giải quyết xong và đã được triển khai vào môi trường sản xuất.

Định nghĩa

Nhóm phát triển phần mềm, nhà phân tích kinh doanh và khách hàng đã xác định vấn đề hiện tại bằng ba tham số sau:

• Thời gian giải quyết cho các hạng mục công việc và các khuyết tật nên được giảm bớt.
• Yêu cầu của khách hàng không được hiểu rõ, dẫn đến việc làm lại tốn kém.
• Các hạng mục công việc liên quan được phân mảnh trong các chu kỳ xây dựng, điều này làm tăng thời gian giải quyết.

Đo lường

Dữ liệu lịch sử từ ứng dụng theo dõi lỗi cũng như thông tin cập nhật được sử dụng để ước tính thời gian giải quyết trung bình của một hạng mục công việc. Sử dụng dữ liệu biến đổi thu được bằng cách phân tích các phiếu đã gửi, người ta thấy rằng thời gian giải quyết trung bình cho một hạng mục công việc là một chu kỳ xây dựng (34 ngày), như thể hiện trong hình bên dưới. (Lưu ý thêm, nhiều dự án mất quá nhiều thời gian. Một nhà phân tích kinh doanh đã tham gia vào công ty và nhanh chóng dọn dẹp các công việc tồn đọng và giúp giải quyết các vấn đề còn tồn đọng.)

Lập bản đồ quy trình

Lập bản đồ quy trình được sử dụng để mô tả quy trình hiện có. Bảng 1 mô tả sự phân công hiện tại của các hạng mục công việc trong nhóm. Danh sách ưu tiên của các hạng mục công việc cho chu trình xây dựng bao gồm bốn hạng mục:

• Hai mục liên quan đến việc phát triển các công cụ quản trị trong một ứng dụng phần mềm: công cụ quản trị 1 và công cụ quản trị 2.
• Hai mục liên quan đến chỉnh sửa và hiển thị thông tin tài chính của khách hàng: công cụ 1 liên quan đến tài chính và công cụ 2 liên quan đến tài chính.

Người quản lý nhóm phát triển nhận ra rằng phát triển phần mềm là một quá trình sáng tạo và có thể nhanh chóng trở nên đơn điệu. Do đó, công việc được cấu trúc để Nhà phát triển 1 được giao hai hạng mục công việc: công cụ quản trị 1 và công cụ liên quan đến tài chính 1 trong khi Nhà phát triển 2 được giao hai hạng mục công việc khác: công cụ quản trị 2 và công cụ liên quan đến tài chính 2. Sự kết hợp và- phân công nhiệm vụ phù hợp đã được thiết lập để đảm bảo rằng tất cả các nhà phát triển sẽ có cơ hội làm việc trên tất cả các lĩnh vực của ứng dụng và có được kiến ​​thức miền (cả chức năng và kỹ thuật) của ứng dụng.

Trong kịch bản hiện tại, các mục công việc tương tự được giao cho các nhà phát triển khác nhau, gây ra sự phân mảnh mục công việc. Cả hai nhà phát triển sẽ nghiên cứu các lĩnh vực giống nhau của ứng dụng một cách độc lập; họ phải hiểu các yêu cầu, theo dõi các vấn đề thông qua các mô-đun mã, phát triển mã mới và mã kiểm tra cho cả hai hạng mục công việc. Vì các hạng mục công việc dành cho các nhà phát triển là khác nhau, nên thời gian phát triển và thử nghiệm khi kết hợp với nhau là rất quan trọng.

Nhóm nhận thấy rằng nếu các hạng mục công việc tương tự trong ứng dụng phần mềm được giao cho cùng một nhà phát triển, thì sẽ ít yêu cầu chuyển đổi ngữ cảnh hơn và thời gian phát triển và thử nghiệm sẽ giảm đáng kể (tức là chỉ còn một chu kỳ xây dựng). Nếu Nhà phát triển 1 được giao cả hai hạng mục công việc liên quan đến công cụ quản trị và nếu Nhà phát triển 2 được giao cả hai hạng mục công việc liên quan đến tài chính, thì thời gian phát triển và kiểm tra tổng thể có thể sẽ bị giảm xuống.

Một phân tích đầu vào-quá trình-đầu ra được sử dụng để lấy mẫu các yêu cầu thay đổi để xác định các đầu vào (x) đã ảnh hưởng đến thời gian giải quyết các yêu cầu của khách hàng. Các yêu cầu của khách hàng, mức độ ưu tiên của nhiệm vụ, kiến ​​thức kỹ thuật và giao tiếp đều có ảnh hưởng đáng kể đến tốc độ giải quyết và chất lượng của các hạng mục công việc được giải quyết. Sau đó, một ma trận nguyên nhân và kết quả đã được sử dụng để thu hẹp các yếu tố có thể có tác động tối đa đến thời gian giải quyết các hạng mục công việc và số lượng công việc phải làm lại. Các yêu cầu không rõ ràng và việc giao các hạng mục công việc không có kế hoạch cho các nhà phát triển nổi lên như những điểm tập trung quan trọng nhất.

Phân tích

Một số công cụ đã được áp dụng trong giai đoạn Phân tích của dự án này. Biểu đồ Pareto được sử dụng để phân tích định lượng các yêu cầu của khách hàng và xác định khu vực nào trong ứng dụng đã tạo ra yêu cầu khách hàng tối đa. Nó đã được quyết định ghi lại mã trong các lĩnh vực này và cung cấp đào tạo người dùng khi cần thiết. Công cụ 5 Whys được sử dụng để phân tích lý do phải làm lại trong các chu kỳ xây dựng.

Sự động não của nhóm phát triển, nhà phân tích kinh doanh và các khách hàng nội bộ đã dẫn đến những khám phá sau:

• Các yêu cầu đã được sửa đổi sau khi hạng mục công việc được giải quyết.
• Các sai sót trong các trang web và mô-đun liên quan đã được báo cáo vào những thời điểm khác nhau.
• Không phải lúc nào việc giải quyết các hạng mục công việc cũng đạt được như mong đợi của khách hàng.

Mỗi trường hợp này đều được yêu cầu làm lại.

Cải tiến

Nhóm phát triển phần mềm đã ghi lại một quy trình để cải thiện hiệu quả phát triển phần mềm và giảm thiểu việc làm lại. Chiến lược mới bao gồm các bước sau.

• Thu thập các yêu cầu rõ ràng của khách hàng: Các yêu cầu mơ hồ được xác định là nguyên nhân chính của việc làm lại. Người ta xác định rằng công việc phát triển phần mềm sẽ chỉ bắt đầu sau khi các yêu cầu của khách hàng được ghi chép và truyền đạt rõ ràng. Điều này liên quan đến nhiều cuộc thảo luận giữa khách hàng và giám đốc phát triển trước khi nhiệm vụ được giao cho các nhà phát triển phần mềm. Các mẫu thu thập yêu cầu đã được sửa đổi và mô-đun hóa để đảm bảo rằng tất cả thông tin cần thiết đều được đưa vào. Ảnh chụp màn hình được đưa vào bất cứ khi nào có thể để đảm bảo rằng các yêu cầu được truyền đạt rõ ràng.
• Giảm chuyển đổi kiến ​​thức: Khách hàng, giám đốc nhóm phát triển và nhà phân tích kinh doanh bắt đầu đầu tư nguồn lực đáng kể vào việc sắp xếp thứ tự ưu tiên và phân nhóm các hạng mục công việc. Các hạng mục công việc tương tự trong một ứng dụng phần mềm đã được tổng hợp và giao cho cùng một nhà phát triển. Điều này cho phép nhà phát triển giảm thiểu thời gian khôi phục kiến ​​thức bị lãng phí giữa các tác vụ và giảm đáng kể thời gian phát triển và kiểm tra phần mềm.
• Giảm công việc làm lại: Trong suốt vòng đời của một hạng mục công việc, khách hàng và nhóm phát triển bắt đầu cùng nhau xem xét sản phẩm đang phát triển bằng cách sử dụng các nguyên mẫu và ảnh chụp màn hình. Phương pháp lặp đi lặp lại này cho phép khách hàng sớm yêu cầu bất kỳ thay đổi bổ sung nào trong quá trình phát triển và giảm việc làm lại tốn kém. Kiểm tra đơn vị nghiêm ngặt và đánh giá mã ngang hàng trong nhóm phát triển đã tăng thêm độ tin cậy của mã. Chia sẻ kiến ​​thức giữa các nhà phát triển (thông qua các bài thuyết trình kỹ thuật và xây dựng kiến ​​thức miền trong các lĩnh vực của ứng dụng) đã được khuyến khích.

Các hạng mục công việc liên quan được kết hợp và giao cho một nhà phát triển phần mềm trong một chu kỳ xây dựng. Như thể hiện trong Bảng 2, Nhà phát triển 1 hoạt động trên các công cụ quản trị, trong khi Nhà phát triển 2 hoạt động trên các công cụ liên quan đến tài chính; tính liên tục này trong công việc cải thiện thời gian giải quyết hạng mục công việc.

Kết quả

Các nhà phát triển hiện nhận được sự làm rõ yêu cầu của khách hàng khi bắt đầu một hạng mục công việc, viết mã cần thiết và kiểm tra một hạng mục công việc trong một chu trình phát triển phần mềm duy nhất. Vì hiện nay kiến ​​thức và chuyển đổi ngữ cảnh là tối thiểu, thời gian phát triển và thử nghiệm giảm xuống và thời gian giải quyết các hạng mục công việc được cải thiện như trong Bảng 3.

Điều khiển

Danh sách các hạng mục công việc được sử dụng để giao nhiệm vụ mỗi tháng đã được sửa đổi để kết hợp các nhiệm vụ liên quan. Thời gian giải quyết cho các hạng mục công việc đã được theo dõi. Người ta thấy rằng bằng cách thu thập các yêu cầu chi tiết, ưu tiên cẩn thận các hạng mục công việc và giao các nhiệm vụ tương tự cho cùng một nhà phát triển, việc phát triển và thử nghiệm nhiều hơn có thể được hoàn thành trong một chu kỳ xây dựng duy nhất. Các lỗi được gửi đến ứng dụng theo dõi lỗi đã được theo dõi và số lượng yêu cầu làm lại giảm đáng kể.

Tóm lược

Kết quả của dự án này, thời gian giải quyết các hạng mục công việc liên quan đã giảm trung bình hai tuần (tùy thuộc vào số lượng hạng mục công việc cộng lại) với việc tiết kiệm đáng kể giờ công cho nhóm phát triển. Giờ đây, thời gian tiết kiệm được dùng để chủ động xác định và giải quyết các vấn đề, thiết kế các bài kiểm tra đơn vị mạnh mẽ, lập kế hoạch phát triển mới và cải thiện mã hiện có.

Thời gian giải quyết các hạng mục công việc được giảm xuống, giao tiếp giữa nhà phát triển và khách hàng được cải thiện và sự hài lòng của khách hàng tăng lên. Quan trọng nhất, dự án Vành đai xanh này mang lại văn hóa cải tiến liên tục trong nhóm phát triển phần mềm và các dự án tương tự được lên kế hoạch cho các lĩnh vực khác của ứng dụng phần mềm.

Nhìn nhận

Trong dự án này, nhóm đã sử dụng các công cụ từ Lean, Six Sigma và phát triển phần mềm nhanh nhẹn như đã được David Howell nêu trong Hội tụ phát triển phần mềm: Six Sigma-Lean-Agile.