Đáp: Học để thực hiện cải tiến qui trình trong tình hình thực cũng giống như học lái xe hơi vậy. Đọc sách là không đủ để cho mọi người tự tin đi vào phố hay đi trên đường cao tốc. Bạn phải thực hiện nó từng nhiệm vụ nhỏ mỗi lúc để học các kĩ năng cải tiến. Gợi ý của tôi là tuân theo bản lộ trình cho cải tiến qui trình, đặc biệt tuân theo vác qui tắc triển khai và nhớ rằng bạn đang học cho tới khi bạn thu được kĩ năng cần thiết để làm nó nhanh hơn, tốt hơn và rẻ hơn.
Hỏi: Sau đánh giá CMMI, tổ chức của tôi muốn nhanh chóng tiến sang mức trưởng thành tiếp. Kế hoạch cải tiến của chúng tôi có tổng cộng 15 nhiệm vụ nhưng người quản lí của chúng tôi quyết định rằng chúng tôi nên thực hiện tất cả những nhiệm vụ này song song để xúc tiến cuộc hành trình sang mức tiếp. Điều đó là có thể chứ?
Đáp: Tôi tin làm nhiều điều thế ngay một lúc là sai lầm lớn. Cải tiến qui trình là quá trình học tập, bạn học khi bạn thực hiện từng nhiệm vụ và áp dụng điều bạn học vào nhiệm vụ tiếp. Tôi mạnh mẽ thúc giục tổ chức của bạn đừng thực hiện quá 2 hay 3 nhiệm vụ một lúc. Thực hiện quá nhiều nhiệm vụ lấy đi nhiều nguồn lực quí giá khỏi hoạt động hàng ngày như phát triển phần mềm, quản lí dự án. Nó cũng tạo ra lẫn lộn và ngăn cản tổ chức không áp dụng được các bài học rút ra trong việc cải tiến qui trình cho thực hiện tương lai. Tôi tin cách tiếp cận này sẽ không làm cho tổ chức của bạn đi sang mức trưởng thành tiếp mà bạn muốn mà chỉ dẫn tổ chức của bạn và con đường nguy hiểm của lẫn lộn và hỗn độn. Tôi không biết tại sao bạn lại vội vàng thế? Tổ chức của bạn có thực sự muốn cải tiến hay chỉ săn đuổi theo con số mức độ trưởng thành vô nghĩa?
Hỏi: Vai trò của Đảm bảo chất lượng phần mềm – Software Quality Assurance (SQA) là gì? Làm sao họ có thể chịu trách nhiệm về chất lượng khi họ thậm chí không phát triển phần mềm?
Đáp: Chính sai lầm là giải định rằng SQA chịu trách nhiệm về chất lượng. Người duy nhất chịu trách nhiệm về chất lượng phần mềm là người phát triển nó. Vai trò của SQA là kiểm điểm và điều phối cách những người phát triển tạo ra phần mềm và báo cáo với cấp quản lí về bất kì lệch lạc nào so với chuẩn, thủ tục, và qui trình. Chính công việc của cấp quản lí là nhấn mạnh rằng các vấn đề chất lượng phải được sửa chữa trước khi sản phẩm được đưa ra. Nếu cấp quản lí không hỗ trợ cho SQA bằng việc theo các khuyến cáo của họ thì SQA sẽ không có hiệu quả.
Hỏi: Tôi tin cải tiến qui trình là chuyện phí thời gian của người phát triển phần mềm bận rộn. Tôi thà lập trình còn hơn cải tiến qui trình.
Đáp: Nếu bạn được trông đợi hoàn thành dự án của mình dựa trên lịch biểu phi thực tế với việc ngắt quãng thường xuyên thì bạn phải tự hỏi mình “có cách nào tốt hơn để cải tiến tình hình hiện thời không?” Tôi tin cải tiến qui trình phần mềm có thể làm cho dự án của bạn bớt hỗn độn, môi trường làm việc của bạn ít bị dồn nén do việc cải tiến trong ước lượng dự án. Tuy nhiên, bạn phải quyết định liệu bạn có muốn cải tiến hay không. Bạn có thể lập trình hàng nghìn dòng mã và thích thú điều đó nhưng điều gì xảy ra nếu khách hàng của bạn cứ thay đổi yêu cầu hàng tuần? Bạn có tiếp tục lập trình hết tuần nọ tới tuần kia và biết rằng điều bạn làm sẽ lại bị thay đổi không? Bạn phải thay đổi thái độ của mình về cải tiến qui trình và coi rằng nó không phải là phí thời gian mà là hoạt động có giá trị gia tăng có thể làm cho việc lập trình của bạn tốt hơn và đối xử với nó như một phần của công việc của bạn.
Hỏi: Tại sao chúng ta nhấn mạnh quá nhiều vào cải tiến qui trình phần mềm? Sao không tập trung vào con người hay công nghệ?
Đáp: Khi chúng ta nghĩ cải tiến qui trình phần mềm, chúng ta phải xem xét sự cân bằng của ba cấu phần: Qui trình, Con người và Công nghệ. Cả ba cấu phần này đều đóng vai trò quan trọng trong việc xác định cách cải tiến qui trình phần mềm thành công thế nào. Chúng ta cần các qui trình tốt để hoàn thành việc phát triển phần mềm của mình. Chúng ta cần công nghệ tốt để hỗ trợ cho các qui trình này. Chúng ta cũng cần người có kĩ năng cao và có động cơ dùng các qui trình và công nghệ đó để làm việc. Chung cuộc chính con người mới chịu trách nhiệm cho thành công hay thất bại của nỗ lực cải tiến.
Hỏi: Yêu cầu của chúng tôi liên tục thay đổi hàng tuần; dường như là khách hàng của chúng tôi không có khả năng quyết định. Chúng tôi có thể làm gì để có hiệu quả?
Đáp: Phát triển yêu cầu là cả quá trình thương lượng và sáng tạo. Điều này nghĩa là cấp quản lí phải có tham gia vào trong quá trình này, bên cạnh khách hàng và người phát triển.
1) Khách hàng: Biết nhu cầu nghiệp vụ của họ và cách nó hoạt động. Khi họ tranh cãi về các cách tiếp cận khác với người phát triển, họ sẽ thu được cái nhìn sâu sắc mới về vấn đề của mình và thường đổi quan điểm của họ.
2) Người phát triển: Biết các vấn đề kĩ thuật, cái gì khả thi, và cái gì có thể được thực hiện trong thời gian và chi phí thoả đáng.
3) Cấp quản lí: Biết rằng yêu cầu có thể là vô giới hạn cố hữu, và doanh nghiệp tốt yêu cầu cả tính sáng tạo và tính hiện thực. Họ phải kiểm điểm các yêu cầu để đảm bảo rằng nó có thể được thực hiện với thời gian và chi phí sẵn có.
Khi việc phát triển diễn ra, thông tin mới thu được rất có thể sẽ ảnh hưởng tới các thoả hiệp đã thực hiện. Đó là lí do tại sao các yêu cầu không bao giờ hoàn chỉnh mà liên tục tiến hoá. Để hiệu quả, Cấp quản lí phải can thiệp và nhấn mạnh vào bản mẫu để hiểu tốt hơn về yêu cầu và đưa ra tăng dần để giảm rủi ro của việc biến hoá yêu cầu.
Hỏi: Tại sao cải tiến qui trình lại là quá trình tiến hoá?
Đáp: Nó là tiến hoá bởi vì nó cần thời gian. Mọi qui trình đều phải được xác định, được làm tài liệu, được đo, được cải tiến, được bảo trì và được hỗ trợ. Điều này tương phản với cách tiếp cận “Giải pháp mì ăn liền” như thuê người giỏi nhất, mua công cụ tốt hơn, và làm tài liệu thật dầy rồi hi vọng việc cải tiến sẽ xảy ra.
Mô hình cải tiến qui trình như CMMI là tiến hoá bởi vì nó ngụ ý rằng cái gì đó phải được làm trước cái khác. Việc kiểm soát quản lí dự án căn bản phải được làm chủ trước khi qui trình chuẩn của tổ chức có thể được phát triển. Tuyến cơ sở cách đo phải được thiết lập trước khi cấp quản lí có thể dùng các sự kiện và dữ liệu để ra quyết định. Qui trình phải có tại chỗ và được thể lệ hoá đầy đủ trước khi tổ chức có thể bắt đầu tối ưu nó và đạt tới phẩm chất đẳng cấp thế giới. Phần lớn các tổ chức có mức trưởng thành cao đều không tới đó chỉ qua một đêm. Họ phải mất nhiều năng liên tục làm việc vất vả để đạt tới trạng thái có danh tiếng này.
Hỏi: Chúng tôi là thành viên của Nhóm qui trình kĩ nghệ phần mềm (SEPG) chịu trách nhiệm cải tiến phần mềm trong tổ chức phần mềm lớn. Tuy nhiên, dường như là không ai trong tổ chức của chúng tôi quan tâm tới chúng tôi. Người quản lí lờ chúng tôi đi, người phát triển không kính trọng chúng tôi, và khách hàng phàn nàn rằng chúng tôi không gia tăng giá trị. Chúng tôi phải làm gì?
Đáp: Bước đầu tiên trong cải tiến qui trình hiệu quả là thay đổi hành vi của người quản lí và người phát triển. Là thành viên SEPG, bạn có thể khởi đầu và hỗ trợ cho thay đổi nhưng thay đổi thực chỉ xảy ra khi người khác có được thái độ mới hướng tới qui trình phần mềm. Vấn đề là làm sao làm cho người phát triển phần mềm làm được những điều không trực tiếp đóng góp cho việc chuyển giao sản phẩm phần mềm? Đây là vấn đề khó bởi nhiều lí do.
Thứ nhất, người phát triển bao giờ cũng bận. Thứ hai, họ có thể không hiểu điều bạn muốn họ làm hay tại sao làm. Và thứ ba, họ có thể không tin rằng điều bạn gợi ý sẽ giúp họ làm việc của họ. Do đó, điều quan trọng nhất là làm cho cấp quản lí hành xử khác đi. Đây là lí do tại sao chúng ta có thẩm định phần mềm để nhận diện điểm mạnh, điểm yếu và rủi ro của việc không cải tiến để cho cấp quản lí có thể nhận ra sự khẩn thiết. Chừng nào họ còn sẵn lòng sống với các hậu quả của qui trình hỗn độn, tổ chức sẽ tiếp tục ở mức độ trưởng thành 1, bất kể cái gì bạn làm hay bất kì ai làm. Điều then chốt mà cấp quản lí cần là nhấn mạnh vào việc quản lí dự án có trật tự và kỉ luật để đưa ra cam kết, làm tài liệu qui trình và chất lượng sản phẩm. Nếu họ không đồng ý với điều này, chẳng cái gì sẽ có tác dụng.
Đây là vài gợi ý bạn có thể thấy hữu dụng:
1) Đảm bảo rằng cấp quản lí thừa nhận rằng cải tiến qui trình là trách nhiệm của họ. Nếu những người phát triển không tham gia vào hay không hỗ trợ tích cực cải tiến qui trình, nó sẽ không xảy ra.
2) Thu được thoả thuận từ cấp quản lí về vài hành động mấu chốt để thực hiện đầu tiên. Tôi gợi ý mỗi lúc chỉ một thay đổi nhỏ. Đừng cố làm cái gì đó mơ hồ kiểu như “Có được mức 2”. Để tạo ra tiến bộ, bạn cần hội tụ và cái gì đó hữu dụng, thực tế, như giám định phần mềm để loại bỏ lỗi. Hành động này là đo được nếu bạn lập tuyến cơ sở truwowssc nhất. Bạn phải thu thập số các lỗi sau khi đưa ra và số các lỗi được tìm thấy trong giám định sản phẩm.
3) Bạn cần đảm bảo rằng mọi người đều biết trách nhiệm của họ. Viết những điều đó ra cũng là ý tưởng tốt.
4) Thiết lập kế hoạch làm việc, giữ cho nó đơn giản, hội tụ, và không quá 3 tháng về thời hạn cho từng pha (Xác định, Thử nghiệm, Làm mịn, và Thể lệ hoá). Đảm bảo bản kế hoạch này có các điểm kiểm (trạng thái theo tuần) và nhận diện tài nguyên rõ ràng.
5) Biểu lộ điều được đưa vào trong việc làm một thay đổi được hoàn thành. Bạn có thể làm điều này bằng báo cáo tiến độ với cấp quản lí và đảm bảo đưa vào những cam kết lịch biểu và tài nguyên (Kế hoạch so với Thực hiện). Những điều này sẽ giúp mọi người nhận ra cái gì được đưa vào và và nó tốn bao lâu. Nó cũng làm hiển nhiên rằng vấn đề không phải là vài giờ mà là sự sẵn có của người dự án nữa.
6) Tuyên dương thành công. Đều đặn nhận diện thành tựu thực, nêu tên người có công trạng trách nhiệm, và công bố sự hoàn thành của họ. Tuy nhiên, SEPG phải khiêm tốn, đứng ngoài quá trình thừa nhận, việc của bạn là điều phối, không phải tuyên bố công trạng về bất kì cái gì. Điều này sẽ xây dựng nên lòng nhiệt tình, giành được liên minh, và biểu lộ tiến bộ. Một khi đà có rồi, sẽ khó dừng lại và bạn sẽ đi vững trên đường.
7) Chìa khoá cho cải tiến thành công là làm nhiều thay đổi nhỏ và đơn giản. Ích lợi chính từ phần lớn những thay đổi tới từ vài hành động. Đừng làm thay đổi lớn, bạn sẽ không thành công. Nhớ câu hỏi “Ăn voi thế nào?” Đáp: “Bằng nhiều miếng nhỏ.”
8) Tuân theo “bản lộ trình cải tiến.” Nhớ cung cấp đủ thông tin để mọi người biết điều cần làm và khi nào. Thử nghiệm nó, lấy phải hồi khởi đầu từ những người tham gia dự án, người dùng cải tiến qui trình rồi làm mịn nó dựa trên kết quả thử nghiệm, và thu thập dữ liệu. Bạn có lẽ phải huấn luyện mọi người và chắc chắn sẽ phải giúp họ bắt đầu. Cải tiến là quá trình học tập. Bạn sẽ học rất nhiều từ việc thực hiện thay đổi hơn là từ lập kế hoạch hay nói về nó. Học từ thực tế không đánh giá, cho nên trước khi làm cho người khác thay đổi, bạn phải tự thay đổi mình trước.
9) Nếu cấp quản lí không đồng ý phân công người phát triển cho nhiệm vụ cải tiến, lên tới quản lí cấp cao và làm rõ ràng rằng không có sự tham gia của người phát triển, việc cải tiến qui trình là phí thời gian và tiền bạc. Với những điều kiện này, hoặc quản lí cấp cao phải bước vào hỗ trợ, hoặc bạn sẽ phải tìm việc ở đâu đó khác.
10) Nếu quản lí cấp cao từ chối giải quyết vấn đề này, họ không thực sự được thuyết phục về nhu cầu cải tiến. Bất kể điều họ nói, bạn cần dừng hay làm gián đoạn nỗ lực cho tới khi bạn có được sự chú ý của họ. Nếu bạn có vài người quản lí hỗ trợ, hãy tranh thủ họ và giúp cho họ cải tiến. Đừng phí thời gian với “người lạc hậu.” Ý tưởng là làm cho người ta nhanh chóng thành công, với dữ liệu cải tiến vững chắc. Phần còn lại sẽ tự vào chỗ.
11) Để kết luận, chìa khoá thành công là làm cải tiến qui trình từng bước mỗi lúc. Đảm bảo rằng cấp quản lí đồng ý với nhu cầu thay đổi và biết chi phí cùng ích lợi của nó. Nhớ, thay đổi cần thời gian và bạn phải kiên nhẫn. Thay đổi cũng yêu cầu quyền lãnh đạo và thái độ có thể-làm. Việc của SEPG là việc rất gian nan, yêu cầu cam kết, cống hiến, kĩ năng và tri thức. Nó cũng là việc không béo bở gì, với nhiều công việc gian khó mà không “Vinh quang”. Đó là lí do tại sao tôi bao giờ cũng nhắc nhở rằng chỉ “rất ít người” phù hợp với loại công việc này. Nếu bạn muốn là anh hùng, thì thử viết mã, nó bao giờ cũng được cần tới ở tổ chức mức 1.
Question: We have read many improvement books and they all are very good but when we start to implement improvement in our own organization, things fell apart. What do you suggest?
Answer: Learning to implement process improvement in a real situation is like learning to drive a car. Reading books are not enough to give people the confidence to go into the street or highway right away. You have to implement it one small task at a time to learn the improvement skills. My suggestion is to follow the roadmap for process improvement, especially follow the deployment rules and remember that you are learning until you acquire the necessary skills to do it faster, better, and cheaper.
Question: After a CMMI assessment, my organization wants to move quickly to the next maturity level. Our improvement plan has total of 15 tasks but our manager decided that we should implement all tasks in parallel to expedite the journey to the next level. Is it possible?
Answer: I believe it is a big mistake to do so many things all at once. Process improvement is a learning process, you learn as you implement each task and apply what you learned to the next task. I strongly urge your organization not to implement more than 2 or 3 tasks at once. Implementing too many tasks takes away the precious resources from day to day activities like software development, managing projects. It also creates confusion and prevents organization from applying lessons learned in process improvement to future implementation. I believe this approach will not get your organization to the next maturity level where you want to be but lead your organization into a dangerous path of confusion and chaotic. I do not know why you are in such a hurry? Is your organization really want to improve or just chasing after a meaningless maturity level number?
Question: What is the role of Software Quality Assurance (SQA)? How can they be responsible for quality when they are not even developing software?
Answer: It is a mistake to assume that SQA is responsible for quality. The only person responsible for the quality of software is the one who develop it. The role of SQA is to review and monitor the way developers create software and reports to management about any deviations from standards, procedures, and processes. It is the job of management to insist that the quality problems be fixed before the product is released. If management does not support SQA by following their recommendations then SQA will not be effective.
Question: I believe process improvement is a waste of time of busy software developers. I rather program than improve the process.
Answer: If you are expected to complete your projects based on an unrealistic schedule with constant interruptions then you must ask yourself “is there any better way to improve the current situation?” I believe software process improvement can make your project less chaotic, your work environment less stressful due to the improvement in project estimates. However, you must decide whether you want to improve or not. You may program thousand lines of code and enjoy it but what happen if your customer keeps changing the requirements every week? Would you continue to program week after week and knowing that what you do will be changed again? You must change your attitude about process improvement and consider that it is not a waste of time but value-added activity that can make your programming work better and treat it as part of your job.
Question: Why do we emphasize too much on software process improvement? Why not concentrate on people or technology?
Answer: When we think of software process improvement, we must consider the balance of three components: Process, People and Technology. All three components play an important role in determining how successful software process improvement is. We need good processes to accomplish our software development. We need good technology to support these processes. We also need highly skilled and motivated people to use those processes and technology to do the work. Ultimately it is people who are responsible for the success or failure of the improvement effort.
Question: Our requirements continue to change weekly; it seems that our customer is not able to make up their mind. What can we do to be effective?
Answer: Requirement development is both a negotiating and a creative process. This means that management must be involved in the process, beside customer and developer.
1) The customer: Know their business need and how it works. As they debate alternative approaches with the developers, they will gain new insights on their problems and often change their views.
2) The Developer: Know the technical issues, what is feasible, and what can be done in a reasonable time and cost.
3) The Management: Know that requirements can be inherently unlimited, and a good business requires both creativity and reality. They must review requirements to ensure that it can be done within available time and cost.
As development proceeds, new information is gained that will likely affect the compromises already made. That is why requirements are never complete but continue to evolve. To be effective, Management must intervene and insist on prototype to better understand the requirement and incremental release to reduce the risks of requirement creep.
Question: Why process improvement is an evolutionary process?
Answer: It is an evolution because it takes time. Every process must be defined, documented, used, measured, improved, maintained and supported. This is in contrast to the “Instant solution” approach such as hire the best people, buy the better tools, and document the biggest volume then hope improvement will happen.
Process improvement model such as the CMMI is an evolution because it implies that something must be done before others. A basic project management control must be mastered before an organizational standard process can be developed. Measurements baseline must be established before management can use facts and data to make decision. Process must be in place and fully institutionalized before an organization can begin to optimize it and achieve world class quality. Most high maturity level organizations do not get there overnight. It took them many years of continuing hard working to achieve the prestigious status.
Question: We are members of a Software Engineer Process Group (SEPG) responsible for software improvement in a large software organization. However, it seems that no one in our organization is interested in us. Managers ignored us, developers did not respect us, and customer complained that we are not value-added. What should we do?
Answer: The first step in effective process improvement is changing the behavior of the managers and developers. As SEPG members, you can initiate and support the change but real change only happens when other people acquire a new attitude toward software process. The question is how to get software developers to do things that do not directly contribute to the delivery of software products? This is a difficult problem for many reasons. First, developers are always busy. Second, they may not understand what you want them to do or why. And third, they may not believe that what you suggest will help them do their jobs. Therefore, the most important thing is to get management to behave differently. This is why we have software assessment to identify strengths, weaknesses and risks of not improving so management can realize the urgency. As long as they are willing to live with the consequences of a chaotic process, the organization will continue to be at maturity level 1, regardless of anything you do or anyone does. The key thing management need is to insist on an orderly and discipline project management for making commitments, document processes and quality product. If they do not agree to this, nothing else will work.
Here are some suggestions that you may find useful:
1) Make sure that management recognizes that process improvement is their responsibility. If the developers do not participate in or actively support process improvement, it will not happen.
2) Get an agreement from management on a few critical actions to accomplish first. I suggest only one small change at a time. Do not try to do something as vague as “Getting to level 2”. To make progress, you need to focus on something useful, practical, such as software inspections to remove defects. This action is measurable if you set a baseline first. You must collect number of post-released defects and number of defects found during product inspection.
3) You need to make sure that everybody knows their responsibilities. It would be a good idea to get these in writing.
4) Establish an operational plan, keep it simple, focused, and no more than 3 months in duration per phase (Define, Pilot, Refine, and Institutionalize). Make sure the plan has checkpoints (Weekly status) and resources identify clearly.
5) Demonstrate what is involved in getting just one change accomplished. You can do this with progress report to management and make sure to include a schedule and resources commitments (Plan vs Actual). These will help everybody realizes what is involved and how long does it take. It will make it obvious that the problem is not work hours but availability of project people too.
6) Make a big deal out of success. Periodically identify real achievements, credit the people responsible by name, and publicize their accomplishment. However, the SEPG must be humble, stay out of the recognition process, your job is to coordinate, do not claim credit for anything. This will build enthusiasm, enlist allies, and demonstrate progress. Once the momentum is going, it is hard to stop and you will be well on your way.
7) The key to process improvement is making a lot of small and simple process changes. The major benefits from most changes come from a few actions. Do not make big change, you will not be successful. Remember the question “How does one eat an elephant?” Answer: “By several small pieces”.
8) Follow the “improvement road map”. Remember to provide just enough information so people know what to do and when. Pilot it, get some initial feedback from project people who use the improve process then refine it based on pilot results, and collect data. You probably have to train people and will certainly have to help them get started. Improvement is a learning process. You will learn a great deal more from implementing change than from planning or talking about it. Learn from practice not opinion, so before having others to change, you must change yourself first.
9) If management does not agree to assigning developer to improvement tasks, go to the senior management and make it clear that without the participating of developers, process improvement is a waste of time and money. Under these conditions, either senior management must step in and helps, or you will have to look for a job elsewhere.
10) If senior management refuses to handle the problem, they are not truly convinced of the need for improvement. Regardless of what they say, you need to stop or discontinue the effort until you have their attention. If you have a few supportive managers, enlist them and help their people to improve. Do not waste time with “Laggards” The idea is to get one quick success, with solid improvement data. The rest will fall into places.
11) In conclusion, the key to success is to take process improvement one step at a time. Make sure that management is in agreement with the need for changes and know its costs and benefits. Remember, change takes time and you must have patience. Change also requires leadership and a can-do attitude. A SEPG job is a very hard job, requires commitment, dedication, skills and knowledge. It is also a thankless job, with a lot of hard work but no “Glory”. That is why I always mentioned that only “a very few people” suitable for this kind of work. If you want to be a hero, try coding, it is always needed at level 1 organization.
