Đáp: Tôi tin tưởng mạnh mẽ rằng các thành viên SEPG có kĩ năng nên được tuyển lựa chứ không bị bắt buộc. Nếu bạn thực sự quan tâm về cải tiến qui trình phần mềm, bạn không nên phân công bất kì ai vào các vai trò này bởi vì họ sẵn có hay họ biết cái gì đó về CMMI. Thành công hay thất bại của cải tiến qui trình dựa rất nhiều vào kĩ năng của người hướng dẫn việc này.
Các thành viên SEPG lí tưởng cần bề dày kinh nghiệm. Kinh nghiệm này cho phép họ hiểu thay đổi được cần tới cho từng dự án, cũng như xuyên qua toàn thể tổ chức, và tác động của những thay đổi nào đó được thực hiện. Họ phải có khả năng lập kế hoạch và quản lí cải tiến qui trình như nó được thực hiện cho dự án phần mềm với yêu cầu dự án, ước lượng dự án, rủi ro dự án và theo dõi các nhân tố này trong toàn bộ vòng đời.
Lời khuyên của tôi là nhìn vào các tổ chức đã thành công trong cải tiến qui trình và tuyển người hướng dẫn việc này.
Hỏi: Phạm vi của cải tiến qui trình có thay đổi khi tổ chức trưởng thành không?
Đáp: Có chứ, tôi tin phạm vi của cải tiến sẽ đổi khi mức độ trưởng thành tăng lên. Có vài ý kiến nhưng sau đây là diễn giả riêng của tôi:
Từ mức 1 lên mức 2: Hội tụ vào cải tiến là ở mức Dự án
Từ mức 2 lên mức 3: Hội tụ vào cải tiến là ở mức Tổ chức (đa dự án)
Từ mức 3 lên mức 4: Hội tụ vào cải tiến ở mức Sản phẩm (đa tổ chức hỗ trợ cho một sản phẩm chính)
Từ mức 4 lên mức 5: Hội tụ vào cải tiến ở mức Kinh doanh (đa sản phẩm hay kinh doanh của công ti)
Hỏi: Tại sao chúng tôi cần tiến hành kiểm điểm phần mềm? Kiểm thử không đủ tốt sao? Khiếm khuyết tốn kém bao nhiêu?
Đáp: Phần lớn mọi người không nhận biết khiếm khuyết phần mềm tốn bao nhiêu. Để tôi cho bạn một kịch bản về chi phí chữa một khiếm khuyết:
Một khách hàng gọi điện và phàn nàn về một khiếm khuyết trong một ứng dụng, chi phí đầu tiên của bạn là chi phí thời gian mất cho việc nhận cú điện thoại. Tất nhiên, bạn muốn chữa khiếm khuyết đó ngay nhưng đầu tiên bạn cần tìm ra khiếm khuyết đã. Một ứng dụng điển hình trong môi trường ngày nay có thể chứa cả triệu dòng mã, và việc tìm ra một lỗi trong chương trình khổng lồ đó là không dễ dàng. Thời gian cho việc tìm lỗi có thể là vài tuần hay vài tháng, và nó tốn tiền. Rồi bạn phải sửa lỗi, chi phí về thiết kế, viết mã, kiểm thử và chuyển giao chương trình đã sửa cho khách hàng là không rẻ. Nó cũng có thể lấy mất vài tuần hay có thể vài tháng. Điều đó vẫn chưa hết, vì khách hàng vẫn phải tích hợp lại chương trình đã chữa vào bản thân sản phẩm cuối cùng, điều đó lại tốn thời gian và và tốn tiền nữa.
Kịch bản này chưa dừng lại ở đây. Với từng chi phí làm tốn thời gian của con người, bạn cần rút ra cái gì được biết tới trong bộ phận kế toán như “tổng phí chuẩn”: Chi phí của mọi mục gián tiếp tính vào trong một giờ làm việc như điện, đèn, đồ đạc, phần cứng máy tính, tiện nghi nhà cửa v.v. Thực hành bảo thủ thông thường trong kế toán là với mỗi giờ làm việc, tổng phí là gấp đôi số đó. Nếu bạn dành 2 ngày để tìm và sửa lỗi, tổng phí có thể là 6 ngày lương của người lập trình.
Tuy nhiên, điều đó vẫn chưa hết, vì thời gian sửa lỗi ngăn cản người lập trình phát triển thêm phần mềm (chi phí cơ hội bị mất). Trong ví dụ này, nhân tố mất của 6 ngày sẽ được tính vào.
Kịch bản đơn giản này về việc chữa một khiếm khuyết đơn giản làm tốn 12 ngày lương người lập trình. Như bạn có thể thấy, việc chữa lỗi là rất tốn kém và đó là lí do tại sao tôi bao giờ cũng động viên nhiều kiểm điểm phần mềm. Kiểm điểm phần mềm nhận diện và loại bỏ khiếm khuyết từ lúc đưa vào ứng dụng. Vài giờ kiểm điểm có thể tiết kiệm cho công ti nhiều tuần và tháng tìm, sửa lỗi và tất nhiên, tiết kiệm cho công ti nhiều tiền.
Hỏi: Tôi nghĩ phần mềm là thứ đặc biệt và người làm phần mềm là những người sáng tạo cá nhân, người không giống như người quan liêu. Chúng tôi không cần cải tiến phần mềm cứng nhắc ở đây.
Đáp: Chúng ta không xây dựng phần mềm như một tác phẩm nghệ thuật. Chúng ta không xây dựng phần mềm như một thứ để được ngắm nhìn. Chúng ta đang trong kinh doanh yêu cầu mọi qui trình phải được quản lí và kiểm soát để có sản phẩm phần mềm chất lượng cao. Tôi đồng ý rằng phần lớn người làm phần mềm đều là những nhà chuyên môn sáng tạo cao nhưng họ phải làm việc trong những ràng buộc nào đó như lịch biểu, chi phí, chất lượng, an toàn và tin cậy v.v. Nếu những ràng buộc này quá cứng nhắc, chúng ta phải làm việc để cải tiến nó và điều đó được gọi là “cải tiến qui trình phần mềm.”
Hỏi: Phương pháp hiện thời của chúng tôi không có tác dụng tốt. Phần lớn các dự án thất bại và khách hàng rất giận. Chúng tôi cần đưa vào công cụ và phương pháp mới, không cải tiến cái gì đó mà không có tác dụng.
Đáp: Mọi việc đưa vào công cụ và phương pháp mới sẽ đưa vào trộn lẫn cả rủi ro và ích lợi. Chừng nào rủi ro còn chưa được hiểu và được đề cập tới theo cách có trật tự, chúng sẽ có thể gây ra những vấn đề nghiêm trọng và không dự đoán được.
Khi tổ chức tiếp tục đưa vào công cụ, phương pháp mới, mà không đề cập đúng tới sự sẵn sàng sử dụng chúng và qui trình chấp thuận, công cụ và phương pháp mới sẽ tác động lên cách qui trình được thực hiện, do vậy phá huỷ sự liên quan của cơ sở lịch sử trực giác mà tổ chức vẫn dựa vào. Không có qui trình đề cập tới những rủi ro này, phần lớn công cụ và phương pháp mới có thể gây hại nhiều hơn là làm lợi.
Hỏi: Nhà tư vấn của chúng tôi khuyến cáo rằng tất cả các dự án phải làm tài liệu qui trình của mình để đạt tới CMMI mức 2. Đấy có phải là tất cả cho mức 2 không?
Đáp: Một số người có thể không có hiểu biết đầy đủ về CMMI và giả định rằng sự tồn tại của tập tài liệu trong tổ chức sẽ làm cho mọi dự án phần mềm thành công. Tài liệu qui trình là rất quan trọng nhưng nó không phải là “thứ duy nhất.” Bên cạnh việc xác định và làm tài liệu qui trình, tổ chức cần huấn luyện mọi người tuân theo qui trình, đo tính hiệu quả của qui trình, và cải tiến liên tục nó qua thời gian để cho bạn có thể lặp lại thành công của mình.
Hỏi: Việc quản lí dự án phần mềm có khác với quản lí dự án không? Vai trò của người quản lí dự án phần mềm là gì?
Đáp: Quản lí dự án phần mềm không thực sự khác với quản lí dự án nhưng nó yêu cầu các kĩ năng và kinh nghiệm riêng do bản chất không sờ mó được của phần mềm.
Vai trò nền tảng của người quản lí dự án phần mềm là đảm bảo rằng dự án có kiểm soát hiệu quả về cam kết thực hiện của nó. Điều này yêu cầu việc chuẩn bị thích hợp và xác định rõ ràng mọi vai trò, trách nhiệm và thẩm quyền của mọi người bên trong dự án phần mềm.
Dự án phần mềm bao giờ cũng bắt đầu với ước lượng về độ lớn công việc cần thực hiện, như phải xây dựng sản phẩm lớn thế nào, cần những loại kĩ năng nào để làm cho việc được thực hiện v.v.
Người quản lí dự án phần mềm giỏi bao giờ cũng bắt đầu với bản kế hoạch dự án để xác định lịch biểu tốt nhất mà có thể được đáp ứng trong tài nguyên đã dự kiến được yêu cầu. Nếu thiếu bản kế hoạch này, không cam kết nào có thể hơn là phỏng đoán có giáo dục.
Hỏi: Sự khác biệt giữa Quản lí cấu hình phần mềm Software Configuration Management (CM) và Quản lí yêu cầu phần mềm Software Requirements Management (RM) là gì?
Đáp: Mục đích của Quản lí yêu cầu Requirements Management (RM) là thiết lập và duy trì thoả thuận chung giữa khách hàng và dự án phần mềm (Người phát triển) liên quan tới yêu cầu của khách hàng.
Qui trình RM bao gồm:
1) Thu thập yêu cầu: Thiết lập qui trình để thu thập yêu cầu của khách hàng, và làm tư liệu các yêu cầu này.
2) Phân tích yêu cầu: Đánh giá và đảm bảo các yêu cầu đáp ứng các tiêu chí định tính nào đó (rõ ràng, hiểu được, kiểm được, dùng được v.v.)
3) Phối hợp hoạt động: Trao đổi các yêu cầu đã được kiểm nghiệm với các chức năng khác hay nhóm bị ảnh hưởng (như CM, SQA, nhóm kiểm thử v.v.)
Mục đích của Quản lí cấu hình Configuration Management (CM) là thiết lập và duy trì tính toàn vẹn của sản phẩm công việc của dự án phần mềm trong toàn bộ vòng đời của nó.
Qui trình CM bao gồm:
1) Nhận diện cấu hình của sản phẩm phần mềm (Khoản mục cấu hình) tại mỗi thời điểm đã nêu
2) Duy trì tính toàn vẹn của sản phẩm phần mềm (tuyến cơ sở, phục hồi lỗi, sao lưu, kiểm soát phiên bản v.v.)
3) Quản lí thay đổi khoản mục cấu hình (Thiết lập qui trình thay đổi, ban thay đổi, lược đồ ưu tiên, quyết định kĩ thuật, và đưa ra)
4) Báo cáo trạng thái của sản phẩm phần mềm cho cấp quản lí
Hỏi: Trong vài năm qua, SEPG của chúng tôi dành hầu hết thời gian vào họp hành. Thỉnh thoảng họ trình bày vài sơ đồ cho chúng tôi và chẳng làm gì khác. Chúng tôi chưa thấy hoạt động cải tiến nào. Tôi không biết liệu họ có làm việc của họ hay không. Chúng tôi phải làm gì?
Đáp: Nếu SEPG mất hàng năm để đi tới đôi bài trình bày và sơ đồ thì họ có thể không làm việc của họ một cách hiệu quả. Dường như SEPG của bạn chỉ “nói mà không làm” để làm cho cải tiến qui trình xảy ra. Có thể là họ không biết phải làm gì và làm sao tiến hành. Cũng có thể là họ không có kĩ năng cần thiết để làm mọi sự xảy ra, do đó, việc tham dự họp, việc tham gia vào các phiên hành động, cho họ ảo tưởng về “làm cái gì đó” trong khi thực tế vẫn bám lấy khái niệm làm “nghiệp vụ như thường.” Nếu bạn và các thành viên của nhóm bạn không thích thú với tiến bộ này, hãy trình mối băn khoăn của bạn cho người quản lí.
Hỏi: Tại sao thầy bao giờ cũng đưa người của tổ chức vào tổ thẩm định? Sao không huấn luyện một nhóm đặc biệt để tiến hành thẩm định?
Đáp: Nếu thẩm định được tiến hành mà không có sự tham gia thích hợp của những người trong tổ chức được thẩm định, nó có thể được coi như kiểm định thôi. “Kiểm định” có thể không dẫn tới cải tiến nào do thiếu cam kết của tổ chức, do mời chào, và do quyền sở hữu các phát kiến thẩm định.
Cải tiến bao giờ cũng yêu cầu cam kết từ mọi người trong tổ chức, do đó họ phải được tham gia vào trong qui trình thẩm định, hành động lập kế hoạch, và hành động triển khai để làm cho thay đổi xảy ra.
Tôi cực lực phản đối khái niệm “chuyên gia thẩm định” người có việc duy nhất là làm thẩm định và không làm gì khác. Nhớ là dễ chỉ cho ai đó khác nhược điểm nhưng khó chỉ nhược điểm của riêng bạn.
Hỏi: Làm sao thầy cải tiến được qui trình mà không xem xét tới con người? Tôi nghĩ thầy phải cải tiến quản lí con người trước.
Đáp: Bạn đúng đấy, không ai có thể cải tiến được qui trình mà không đề cập tới vấn đề con người và công nghệ. Mọi tổ chức phần mềm đều phụ thuộc vào chất lượng của con người phát triển phần mềm và công nghệ thích hợp họ sử dụng. Tuy nhiên, ngay cả với người giỏi nhất và công nghệ tốt nhất, bao giờ cũng có giới hạn về điều con người có thể thực hiện khi họ làm việc 50 tới 60 giờ một tuần. Khó mà thấy được làm sao họ có thể giải quyết được những thay đổi yêu cầu và thay đổi phạm vi lớn. Đó là lí do tại sao chúng ta cần có qui trình quản lí yêu cầu tại chỗ.
CMMI-20
Question: How do we assign people to SEPG? We want to improve our software process but do not have the skilled resources.
Answer: I strongly believe that skilled SEPG members should be recruited not prescribed. If you really care about software process improvement, you should not assign just any people to these roles because they are available or they know something about the CMMI. The success or failure of process improvement relies heavily on the skill of the people who lead them.
The ideal SEPG members need a wide breadth of experience. This experience allows them to understand the changes that are needed on individual project, as well as across the entire organization, and the impact of certain changes made. They must be able to plan and manage process improvement as though it were a software project with project requirements, project estimates, project risks and tracking these factors throughout the life cycle.
My advise is look around for organizations that have been successful in process improvement and recruit the people who leading them.
Question: Is the scope of process improvement changing as the organization maturing?
Answer: Yes, I believe the scope of improvement will change as maturity level increases. There are several opinions but following is my own interpretation:
At level 1 to level 2: The focus of improvement is at Project level
At level 2 to level 3: The focus of improvement is at Organization level (Multiple projects)
At level 3 to level 4: The focus of improvement is at Product level (Multiple organizations to support a major product)
At level 4 to level 5: The focus of improvement is at Business level (Multiple products or company business)
Question: Why do we need to conduct software reviews? Is testing not good enough? How much does a defect cost?
Answer: Most people do not aware how much a software defect cost. Let me give you a scenario on the cost of fixing a single defect:
A customer calls and complains of a defect in an application, your first cost is the cost of time it took to take a phone call. Of course, you want to fix the defect right away but first you need to find the defect. A typical application in today environment may contain a million lines of code, and finding a single defect in that huge program is not easy. The time of finding the defect may be several weeks or months, and it costs money. Then you have to fix the defect, the cost of design, code, test, and deliver the fix to the customer is not cheap. It may also take weeks or maybe months. That is not finishing, since the customer still has to re-integrate the fix into the final product itself, it will take time and costs money too.
The scenario does not end here. For each cost that takes up a person’s time, you need to factor in what is known in accounting department as “Standard overhead”: The cost of all indirect items that go into an hour of work like electricity, lights, furniture, computer hardware, building facilities etc. Common conservative practice in accounting is for each hour of work, the overhead is twice that much. If you spend 2 days of finding and fixing a defect, the overhead cost could be 4 days and the total cost is 6 days worth of a programmer salary.
However, that is not final yet, since the time to fix the defect preventing a programmer from developing more software (Lost opportunity costs). In this example, a lost factor of 6 days will be incurred.
This simple scenario of fixing a simple defect costs 12 days worth of programmer salary. As you can see, it is very costlier to fix a defect and that is why I always encourage more software reviews. Software reviews identify and remove defect from getting into the application. A few hours of review may save the company weeks and months in finding, fixing a defect and of course, save the company a lot of money.
Question: I think software is special thing and software people are individual creators who do not like bureaucracy. We do not need rigid software improvement here..
Answer: We are not building software as a piece of art. We are not building software as a thing to be admired. We are in a business that requires all processes be managed and controlled in order to have a highly quality software product. I do agree that most software people are highly creative professionals but they do have to work within certain constraints such as schedule, cost, quality, safety and reliability etc. If these constraints are too rigid, we must work to improve it and it is called “Software process improvement”
Question: Our current method does not work well. Most projects failed and the customer was very upset. We need to bring in new tools and methods, not improving something that does not work.
Answer: Every new tools and methods introduce will provides a mix of risks and benefits. Unless the risks are understood and addressed in an orderly way, they will likely cause serious and unanticipated problems.
When organization continue to bring in new tools, methods without properly addressing their readiness to use and the adoption process, the new tools and methods will impact the way the process is performed, thus destroying the relevance of the intuitive historical base on which the organization relies. Without a process to address these risks, most new tools and methods may do more harm than good.
Question: Our consultant recommends that all projects document their process to achieve CMMI level 2. Is that all there is for level 2?
Answer: Some people may not have a complete understanding of the CMMI and assume that the existence of a set of document in the organization will makes all software projects successful. Process document is very important but it is not “the only thing”. Beside define and document the process, the organization need to train people to follow the process, measure the effectiveness of the process, and continuously improving it over time so you can repeat your success.
Question: Is software project management different from project management? What is the role of a software project manager?
Answer: Software project management is not really different from project management but it does require specific skills and experiences due to the intangible nature of software.
The fundamental role of a software project manager is to make sure that the project has effective control of its commitment to perform. This requires adequate preparation and clearly defines all the roles, responsibility and authority of people within the software project.
The software project always starts with an estimates of the magnitude of the job to be done, such as how big is the product to be built, how long will it takes, what kind of skills needed to get the job done etc.
A good software project manager always start with a project plan to determine the best schedule which can be met with anticipated resources required. In the absence of this plan, no commitment can be better than just an educated guess.
Question: What is the different between Software Configuration Management (CM) and Software Requirements Management (RM)?
Answer: The purpose of Requirements Management (RM) is to establish and maintain a common agreement between the customer and the software project (Developer) regarding the customer’s requirements.
RM process includes:
1) Gathering requirements: Establish a process to collect customer requirements, and document these requirements.
2) Analyzing requirements: Evaluate and ensure requirements meet certain quality criteria (Clear, understood, testable, usable etc.)
3) Coordinating activities: Communicate validated requirements with other functions or affected groups (i.e. CM, SQA, Test groups, etc.)
The purpose of Configuration Management (CM) is to establish and maintain the integrity of the work products of the software project throughout its life cycle.
CM process includes:
1) Identifying the configuration of the software products (Configuration Items) at given points in time
2) Maintaining the integrity of the software products (Baseline, Error recovery, backup, version controls etc.)
3) Managing change to configuration Items (Establish change process, change board, priority scheme, technical decisions, and release)
4) Reporting status of the software products to management
Question: For the past few years, our SEPG spent most of their time in meetings. Sometimes they presented a few charts to us and nothing else. We have not seen any improvement activities yet. I do not know if they are doing their job or not. What should we do?
Answer: If an SEPG spend years to come up with a couple of presentations and charts then maybe they are not doing their job effectively. It seems like your SEPG only “Talk but not Work” to make process improvement happens. It is possible that they do not know what to do and how to proceed. It is also possible that they may not have the skills necessary to make thing happen, therefore, attending meetings, participating in process action session, give them the illusion of “doing something” while actually still sticking with notion of doing “business as usual”. If you and members of your group are not happy with the progress, raise the concern to your manager.
Question: Why do you always include organizational people in the assessment team? Why not train a special group to conduct assessment?
Answer: If an assessment is conducted without adequate participation by the people from the organization being assessed, it may be viewed as an audit. An “audit” may not lead to any improvement due to the lack of organization commitment, buy-in, and ownership of the assessment findings.
Improvement always requires commitments from people in the organization, therefore they should be involved in the assessment process, plan action, and deploy action to make changes happen.
I am strongly opposing the concept of “assessment experts” whose sole job is to do assessment and nothing else. Remember it is easy to point out somebody else weaknesses but your own.
Question: How do you improve the process without consider the people? I think you must improve people management first.
Answer: You are right, no one can improve the process without addressing people and technology issues. Every software organization is dependent on the quality of the people that develop software and the adequate technology they employ. However, even with the best people and technology, there is always a limit to what people can accomplish when they are working 50 to 60 hours a week. It is hard to see how they could handle significant requirements changes and scope changes. That is why we need to have a requirements management process in place.
