Recently I've got some free time and implemented several automated tests for an application being in testing and development for quite a long time. I did not expect much from my tests but cutting the cost of re-testing the basics of the system functionality under different operating systems.
I have implemented only 4 tests that I have executed against only one operating system. To my sheer surprise the application crashed. It crashed on doing the same sequence of operations it has just did successfully in the previous tests. Hm... I have re-run the entire suite once again and it failed. Wow!
This is not the first time I noted that automated tests is not necessarily a replacement for manual tests. It is rather an addition to it. Automated tests help finding defects one could not find manually and vice versa.
Having said that there are issues your testers are unlikely to find manually, I dare say that automation is absolutely a must for any type of a project. Thos of you who compromise this idea to project cost simply do compromising the quality.
The cost of automation is not as bad as it may seem to be. I will write on this a little more in the following blogs. As of now, I may assure you the cost is not that big as you may imagine. For example, for those 4 tests I wrote slightly more than 200 lines of test code (just 200 simple plain lines of code!). This is all it takes!
It has taken me only one and a half day to create, debug, and run the entire suite on one platform. It just a little longer than it takes to it once manually. However, now I have a suite that I can run with a single click. I don't need to spend my time on it anymore. So I can focus on what matters instead of doing tedious routine work again and again.
When deciding whether to pursue automation, do not think of the losses. Think of what will have in return. Think of the advantages you will have. Yes it takes time and resources to build a reliable automated suite. However, it is worth of every dime spent on it when you are a little further down the road.
Good luck with your automated testing!
Thursday, April 1, 2010
Friday, March 26, 2010
Who decides if the product ready?
In my career I have often been in the situation when I was asked whether or not the product is ready to be shipped. After so many times I was through it I still hesitate when I am asked this question. The reason why I couldn't answer it for sure is that I do not have all the required information to draw a decision.
Being a quality manager all I can judge upon is the quality. But the quality is not the mere criteria to take into consideration when trying to figure if you are ready to release. There are also business demands and limitations, promises made to customers, market situation, corporate strategy, and so on. All those questions are beyond the authority of a quality manager.
So, what to do if you are asked this question yet. Below is how I would behave at different positions.
Quality manager
Above I mentioned that the only criteria you can asses is the quality. You have to start answering this question since the very start of the project. You have to build this answer with all the activities on testing and QA throughout the project timeline. Start building it up from the very beginning - test strategy and keep it in sight all the time. Assess and mitigate quality risks. as you learn new information about the product do the corrections of testing course.
When it's time to answer this question, use all the information you have collected. Just compare metrics against previous similar releases (or against you previous experience with similar systems) and state things as they are, without too much of optimism. If the product is a crap say so. Don't be afraid. You will not be punished for the truth in case you kept saying so all the time when you were asked. Saying that everything is fine during the project and demanding that it's a crap in the end looks unprofessional.
Providing your answer make sure that everyone understands that you are talking of QUALITY CRITERIA ONLY. So that no one can bear an incorrect opinion that you are taking the responsibility for a BUSINESS DECISION.
The best way to say it IMO:
- All the testing we have planned is completed. No issues that are considered critical for the release are open. Latest cycles of testing did not reveal many regression issues. The changes in the latest builds were scarce and undergo all a strict process of risk assessment and regression testing. Fixes which were too risky to do have been moved on to the next version. I can say that we are in good shape from the quality perspective.
In case it's not as good you may also add:
- However, we have experienced significant problems with testing the system under high load. The tools that we have used did not allow us generating required load capacity. So, we do not know how system reacts to peak load. It is a risk for the system operation. After discussion with management we decided that this risk can be accepted.
In the case when it's not good at all:
- Every time we start testing the system it brings many new issues. Defect arrival rate is at almost the same rate all the time. It stays as high as X defects per day till the very end of testing cycle. I would strongly recommend analyzing the reason why we introduce so many defects, improve the process and do another cycle of development and testing to create a product of acceptable quality.
Project manager
As a project manager you have to be sure that your quality manager is confident with the quality of the release. If it is not the case then try to find out the nature of the risks. Assess those risks against project goals and made a decision. It can be a hard one nonetheless you are in better position to make it than anyone else on the project team.
Software tester
I knew several top managers who liked asking it to software testers. They believed that they can get to know the information from first hands, thus testing the correctness of information provided by middle level managers. I don't think this is a good idea. Anyway, as a tester, you need to be prepared. Before giving the answer, make it clear that you can answer only based on YOUR experience with the system. Your experience may be limited to some module or type of testing. If it went good then say that only that system's feature is OK. Do not pretend you possess all the information to say so about the whole product. This may be a killer. I also was in the situation when I was asked "why do you say that everything goes smooth if your guy told me that his module is full of bugs and he sees no end to it?" or opposite "why do you keep telling me that things go so badly when your guys report the system is fine?". Do not put your manager in the situation like this.
Top manager
Well you have someone to report to (board of directors or something) you also need to weight your words. The most dangerous but exciting about your position is that this decision is completely yours. So, don't show a weakness and don't expect that someone else will step up and do it for you. All the responsibility as well as all the fame is yours.
Before making a decision, ask your managers (quality and production). But don't be pushy. Do not force them saying what you want to hear. Be as objective as you can.
It's all for now. Sorry for a mess in thoughts I wrote it real fast. Hope this helps you avoid embarrassing situation when you are asked if the product is ready to be released.
Being a quality manager all I can judge upon is the quality. But the quality is not the mere criteria to take into consideration when trying to figure if you are ready to release. There are also business demands and limitations, promises made to customers, market situation, corporate strategy, and so on. All those questions are beyond the authority of a quality manager.
So, what to do if you are asked this question yet. Below is how I would behave at different positions.
Quality manager
Above I mentioned that the only criteria you can asses is the quality. You have to start answering this question since the very start of the project. You have to build this answer with all the activities on testing and QA throughout the project timeline. Start building it up from the very beginning - test strategy and keep it in sight all the time. Assess and mitigate quality risks. as you learn new information about the product do the corrections of testing course.
When it's time to answer this question, use all the information you have collected. Just compare metrics against previous similar releases (or against you previous experience with similar systems) and state things as they are, without too much of optimism. If the product is a crap say so. Don't be afraid. You will not be punished for the truth in case you kept saying so all the time when you were asked. Saying that everything is fine during the project and demanding that it's a crap in the end looks unprofessional.
Providing your answer make sure that everyone understands that you are talking of QUALITY CRITERIA ONLY. So that no one can bear an incorrect opinion that you are taking the responsibility for a BUSINESS DECISION.
The best way to say it IMO:
- All the testing we have planned is completed. No issues that are considered critical for the release are open. Latest cycles of testing did not reveal many regression issues. The changes in the latest builds were scarce and undergo all a strict process of risk assessment and regression testing. Fixes which were too risky to do have been moved on to the next version. I can say that we are in good shape from the quality perspective.
In case it's not as good you may also add:
- However, we have experienced significant problems with testing the system under high load. The tools that we have used did not allow us generating required load capacity. So, we do not know how system reacts to peak load. It is a risk for the system operation. After discussion with management we decided that this risk can be accepted.
In the case when it's not good at all:
- Every time we start testing the system it brings many new issues. Defect arrival rate is at almost the same rate all the time. It stays as high as X defects per day till the very end of testing cycle. I would strongly recommend analyzing the reason why we introduce so many defects, improve the process and do another cycle of development and testing to create a product of acceptable quality.
Project manager
As a project manager you have to be sure that your quality manager is confident with the quality of the release. If it is not the case then try to find out the nature of the risks. Assess those risks against project goals and made a decision. It can be a hard one nonetheless you are in better position to make it than anyone else on the project team.
Software tester
I knew several top managers who liked asking it to software testers. They believed that they can get to know the information from first hands, thus testing the correctness of information provided by middle level managers. I don't think this is a good idea. Anyway, as a tester, you need to be prepared. Before giving the answer, make it clear that you can answer only based on YOUR experience with the system. Your experience may be limited to some module or type of testing. If it went good then say that only that system's feature is OK. Do not pretend you possess all the information to say so about the whole product. This may be a killer. I also was in the situation when I was asked "why do you say that everything goes smooth if your guy told me that his module is full of bugs and he sees no end to it?" or opposite "why do you keep telling me that things go so badly when your guys report the system is fine?". Do not put your manager in the situation like this.
Top manager
Well you have someone to report to (board of directors or something) you also need to weight your words. The most dangerous but exciting about your position is that this decision is completely yours. So, don't show a weakness and don't expect that someone else will step up and do it for you. All the responsibility as well as all the fame is yours.
Before making a decision, ask your managers (quality and production). But don't be pushy. Do not force them saying what you want to hear. Be as objective as you can.
It's all for now. Sorry for a mess in thoughts I wrote it real fast. Hope this helps you avoid embarrassing situation when you are asked if the product is ready to be released.
Friday, March 5, 2010
Bad process or bad implementation?
Recently, in a course of a training session, we touched ground on what seems to be an interesting topic to me. One of training attendees raised a discussion related to pro and cons of different processes. In order to prevent another holy war I warned everyone that it scarcely matter what process people do use. What really matters is whether they know how to use it. Fool with a tool is still a fool.
Same is true to the processes. We have invented several big-name process as well as dozens of not so famous ones, however we keep looking. Why? - Because we are not satisfied with the results. Because we think that things could be organized better. And all we do in this intention is going cycles around several simple ideas (think ahead, do just enough, think before doing, think after you are done, observe and make corrections). All the process that I know of, are about these concepts, wrapping them in different objects, providing different interfaces to the user. Though the ideas behind stay as simple.
If we all use the same underline ides why some are successful and some are not? The answer is not in the plane of definition but it's in the plane of implementation. Do you remember that saying above? ;) The process is not a panacea. If you expect that a weak, diseased organization wearing a CMM hat will do much better then you are deadly wrong. People are what make processes to work or to fail. People are undermining it by doing thing "slightly different" or doing "just opposite" only because they think that they know better. Just look around and see if there are any of those characters right beside you. And start correcting things right away. Start from yourself ;)
P.S. I am not saying that all the processes are equally feasible for all teams. No. I only was speaking that nearly all the processes are GOOD and COULD HAVE BEEN WORKING if they were applied correctly. Anyway, the process is always better than no process at all. If it's your case, you know where to start! :)
Same is true to the processes. We have invented several big-name process as well as dozens of not so famous ones, however we keep looking. Why? - Because we are not satisfied with the results. Because we think that things could be organized better. And all we do in this intention is going cycles around several simple ideas (think ahead, do just enough, think before doing, think after you are done, observe and make corrections). All the process that I know of, are about these concepts, wrapping them in different objects, providing different interfaces to the user. Though the ideas behind stay as simple.
If we all use the same underline ides why some are successful and some are not? The answer is not in the plane of definition but it's in the plane of implementation. Do you remember that saying above? ;) The process is not a panacea. If you expect that a weak, diseased organization wearing a CMM hat will do much better then you are deadly wrong. People are what make processes to work or to fail. People are undermining it by doing thing "slightly different" or doing "just opposite" only because they think that they know better. Just look around and see if there are any of those characters right beside you. And start correcting things right away. Start from yourself ;)
P.S. I am not saying that all the processes are equally feasible for all teams. No. I only was speaking that nearly all the processes are GOOD and COULD HAVE BEEN WORKING if they were applied correctly. Anyway, the process is always better than no process at all. If it's your case, you know where to start! :)
Tuesday, March 2, 2010
Three simple ideas on management
Today I had an interesting conversation with a manager who is in charge of testing at some world famous organization here in Minsk. She told me that she is about to go on long vacation, so she needs to teach one of her champions how to cope with things while she is out.
One interesting thing I noted is that she realized how much she is of a manager only after trying to teach someone else. Well, this is a known old effect when one can only learn how she knows something by trying to teach someone else. Despite we believe we know something we may have troubles explaining it because the knowledge is scarce and has gray areas, things that we never knew but nonetheless important to get the whole idea. And otherwise, for some of us it is important to test the knowledge by teaching others. This what she did and how she got to know that she is much more powerful a manager than she realized. Try yourself ;)
Another thing we touched is management and who is capable of doing it right. We both come from the same organization where she was my team leader. We know our managers well enough and went into discussing their strong and weak points. One of the most discouraging I found is blaming someon else in the failure. Manager is responsible for all work created by the team. So there is no sense and even more damage to the image in trying to guard against the blame with the subordinates. The relationships between manager and subordinates are built upon trust and openness. If the former blames the latter then this link break free, so there is no normal relationships after that.
The third interesting topic of discussion was aptitude. We both agreed that a person is on rightful place in the organization needs only slight attention and rare correction from a manager. Ijn contrary, a person who misbehaves often and requires a lot of attention from managers will only become a greater distracter in the future. So, finding the right place is very important. No matter who you are employer or an employee.
If you are not at the right place move on. Don’t waste time, yours and that of a manager! :)
One interesting thing I noted is that she realized how much she is of a manager only after trying to teach someone else. Well, this is a known old effect when one can only learn how she knows something by trying to teach someone else. Despite we believe we know something we may have troubles explaining it because the knowledge is scarce and has gray areas, things that we never knew but nonetheless important to get the whole idea. And otherwise, for some of us it is important to test the knowledge by teaching others. This what she did and how she got to know that she is much more powerful a manager than she realized. Try yourself ;)
Another thing we touched is management and who is capable of doing it right. We both come from the same organization where she was my team leader. We know our managers well enough and went into discussing their strong and weak points. One of the most discouraging I found is blaming someon else in the failure. Manager is responsible for all work created by the team. So there is no sense and even more damage to the image in trying to guard against the blame with the subordinates. The relationships between manager and subordinates are built upon trust and openness. If the former blames the latter then this link break free, so there is no normal relationships after that.
The third interesting topic of discussion was aptitude. We both agreed that a person is on rightful place in the organization needs only slight attention and rare correction from a manager. Ijn contrary, a person who misbehaves often and requires a lot of attention from managers will only become a greater distracter in the future. So, finding the right place is very important. No matter who you are employer or an employee.
If you are not at the right place move on. Don’t waste time, yours and that of a manager! :)
Saturday, January 16, 2010
A silly question: why testing takes long?
Recently I came across an amusing post on one of professional forums dedicated to testing. The post was an elaborated description of how to convince management that testing needs so much time to complete. The author worked his way beautifully introducing parameters and formulas, ezplaining assumptions and proving theories with examples. Great job - no doubt! But... it's all useless :)
No manager will care to read it through and through. None!
The mere fact that the management needs to be convinced in things that SHALL BE OBVIOUS is a problem per se. With that multi-pages work author only supposed to solve the symptoms instead of targeting the disease root-cause.
What could be the root cause for the managers to doubt that testing team work efficiently? What managers need from testing to be in order to feel comfortable about its performance? I am sure you guessed right :) All they expect from your team is VISIBILITY. Just let them see what it takes to define strategy, make required environmental preparations, procure and learn tools, create tests, combine suites, execute tests, submit defects, work with fixed and rejected defects, and so on. I you manage to build a transparent process that everyone can watch in the motion you will never ever be asked to prove that you spend your resource cycles effectively.
Another important issue is getting management involved in taking all important decisions. Make them not just supervisors but active contributors. Share with managers all the important decisions, discuss and argue your position. Let them help you with their experience as well as let them see your professional level by providing them technical assistance. Once a decision is not just your but theirs as well they start feeling much better :)
In short, this is all you need to make sure that you are never asked that silly question - "Why does testing take so long?!"
No manager will care to read it through and through. None!
The mere fact that the management needs to be convinced in things that SHALL BE OBVIOUS is a problem per se. With that multi-pages work author only supposed to solve the symptoms instead of targeting the disease root-cause.
What could be the root cause for the managers to doubt that testing team work efficiently? What managers need from testing to be in order to feel comfortable about its performance? I am sure you guessed right :) All they expect from your team is VISIBILITY. Just let them see what it takes to define strategy, make required environmental preparations, procure and learn tools, create tests, combine suites, execute tests, submit defects, work with fixed and rejected defects, and so on. I you manage to build a transparent process that everyone can watch in the motion you will never ever be asked to prove that you spend your resource cycles effectively.
Another important issue is getting management involved in taking all important decisions. Make them not just supervisors but active contributors. Share with managers all the important decisions, discuss and argue your position. Let them help you with their experience as well as let them see your professional level by providing them technical assistance. Once a decision is not just your but theirs as well they start feeling much better :)
In short, this is all you need to make sure that you are never asked that silly question - "Why does testing take so long?!"
Thursday, November 26, 2009
21 methods to innovate
I couldn't help but to copy it from the source (http://feedproxy.google.com/~r/business-strategy-innovation/~3/dXCsA8Esff8/21-great-innovation-methods.html?utm_source=feedburner&utm_medium=email):
1. Copy someone else's idea. One of the best ways to innovate is to pinch an idea that works elsewhere and apply it in your business. Henry Ford saw the production line working in a meat packing plant and then applied to the automobile industry thereby dramatically reducing assembly times and costs.
2. Ask customers. If you simply ask your customers how you could improve your product or service they will give you plenty of ideas for incremental innovations. Typically they will ask for new features or that you make your product cheaper, faster, easier to use, available in different styles and colours etc. Listen to these requests carefully and choose the ones that will really pay back.
3. Observe customers. Do not just ask them, watch them. Try to see how customers use your products. Do they use them in new ways? This was what Levi Strauss saw when they found that customers ripped the jeans - so they brought a line of pre-ripped jeans. Heinz noticed that people stored their sauce jars upside down so they designed an upside down bottle.
4. Use difficulties and complaints. If customers have difficulties with any aspect of using your product or if they register complaints then you have a strong starting point for innovations. Make your product easier to use, eliminate the current inconveniences and introduce improvements that overcome the complaints.
5. Combine. Combine your product with something else to make something new. It works at all levels. Think of a suitcase with wheels, or a mobile phone with a camera or a flight with a massage.
6. Eliminate. What could you take out of your product or service to make it better? Dell eliminated the computer store, Amazon eliminated the bookstore, the Sony Walkman eliminated speakers and record functions.
7. Ask your staff. Challenge the people who work in the business to find new and better ways to do things and new and better ways to please customers. They are close to the action and can see opportunities for innovation. Often they just need encouragement to bring forward great ideas.
8. Plan. Include targets for new products and services in your business plan. Put it onto the balanced scorecard. Write innovation into everyone's objectives. Measure it and it will happen.
9. Run brainstorms. Have regular brainstorm meetings where you generate a large quantity of new product ideas. Use diverse groups from different areas of the business and include a provocative outsider e.g. a customer or supplier.
10. Examine patents. Check through patents that apply in your field. Are there some that you could license? Are some expiring so that you can now use that method? Is there a different way of achieving the essential idea in a patent?
11. Collaborate. Work with another company who can take you to places you can't go. Choose a partner with a similar philosophy but different skills. That is what Mercedes did with Swatch when they came up with the Smart car.
12. Minimize or maximize. Take something that is standard in the industry and minimise or maximise it. Ryanair minimized price and customer service. Starbucks maximised price and customer experience. It is better to be different than to be better.
13. Run a contest. Ask members of the public to suggest great new product ideas. Offer a prize. Give people a clear focussed goal and they will surprise you with novel ideas. Good for innovation and PR.
14. Ask - what if? Do some lateral thinking by asking what if…..? Challenge every boundary and assumption that applies in your field. You and your group will come up with amazing ideas once the normal constraints are lifted.
15. Watch the competition. Do not slavishly follow the competition but watch them intelligently. The small guys are often the most innovative so see if you can adapt or license one of their ideas - or even buy the company!
16. Outsource. Subcontract your new product development challenge to a design company, a University, a start-up or a crowdsourcing site like ive or NineSigma.
17. Use open innovation. Big consumer products companies like Procter and Gamble or Reckitt Benckiser encourage developers to bring novel products to them. They are flexible on IP protection and give a clear focus on what they are looking for. A large proportion of their new products now start life outside the company.
18. Adapt a product to a new use. Find an entirely different application for an existing product. De Beers produced industrial diamonds but found a new use for diamonds when they introduced the concept of engagement rings. It opened up a large new market for them.
19. Try Triz. Triz is a systematic method for solving problems. It can be applied in many fields but is particularly useful in engineering and product design. Triz gives you a toolbox of methods to solve contradictions e.g. how can we make this product run faster but with less power?
20. Go back in time. Look back at methods and services that were used in your sector years ago but have now fallen out of use. Can you bring one back in a new updated form? It has been said that Speed Dating is really a relaunch of a Victorian dance format where ladies had cards marked with appointments.
21. Use social networks. Follow trends and ask questions on groups like Twitter or Facebook. Ask what people want to see in future products or what the big new idea will be. Many early adopters are active on social network groups and will happily respond with suggestions.
1. Copy someone else's idea. One of the best ways to innovate is to pinch an idea that works elsewhere and apply it in your business. Henry Ford saw the production line working in a meat packing plant and then applied to the automobile industry thereby dramatically reducing assembly times and costs.
2. Ask customers. If you simply ask your customers how you could improve your product or service they will give you plenty of ideas for incremental innovations. Typically they will ask for new features or that you make your product cheaper, faster, easier to use, available in different styles and colours etc. Listen to these requests carefully and choose the ones that will really pay back.
3. Observe customers. Do not just ask them, watch them. Try to see how customers use your products. Do they use them in new ways? This was what Levi Strauss saw when they found that customers ripped the jeans - so they brought a line of pre-ripped jeans. Heinz noticed that people stored their sauce jars upside down so they designed an upside down bottle.
4. Use difficulties and complaints. If customers have difficulties with any aspect of using your product or if they register complaints then you have a strong starting point for innovations. Make your product easier to use, eliminate the current inconveniences and introduce improvements that overcome the complaints.
5. Combine. Combine your product with something else to make something new. It works at all levels. Think of a suitcase with wheels, or a mobile phone with a camera or a flight with a massage.
6. Eliminate. What could you take out of your product or service to make it better? Dell eliminated the computer store, Amazon eliminated the bookstore, the Sony Walkman eliminated speakers and record functions.
7. Ask your staff. Challenge the people who work in the business to find new and better ways to do things and new and better ways to please customers. They are close to the action and can see opportunities for innovation. Often they just need encouragement to bring forward great ideas.
8. Plan. Include targets for new products and services in your business plan. Put it onto the balanced scorecard. Write innovation into everyone's objectives. Measure it and it will happen.
9. Run brainstorms. Have regular brainstorm meetings where you generate a large quantity of new product ideas. Use diverse groups from different areas of the business and include a provocative outsider e.g. a customer or supplier.
10. Examine patents. Check through patents that apply in your field. Are there some that you could license? Are some expiring so that you can now use that method? Is there a different way of achieving the essential idea in a patent?
11. Collaborate. Work with another company who can take you to places you can't go. Choose a partner with a similar philosophy but different skills. That is what Mercedes did with Swatch when they came up with the Smart car.
12. Minimize or maximize. Take something that is standard in the industry and minimise or maximise it. Ryanair minimized price and customer service. Starbucks maximised price and customer experience. It is better to be different than to be better.
13. Run a contest. Ask members of the public to suggest great new product ideas. Offer a prize. Give people a clear focussed goal and they will surprise you with novel ideas. Good for innovation and PR.
14. Ask - what if? Do some lateral thinking by asking what if…..? Challenge every boundary and assumption that applies in your field. You and your group will come up with amazing ideas once the normal constraints are lifted.
15. Watch the competition. Do not slavishly follow the competition but watch them intelligently. The small guys are often the most innovative so see if you can adapt or license one of their ideas - or even buy the company!
16. Outsource. Subcontract your new product development challenge to a design company, a University, a start-up or a crowdsourcing site like ive or NineSigma.
17. Use open innovation. Big consumer products companies like Procter and Gamble or Reckitt Benckiser encourage developers to bring novel products to them. They are flexible on IP protection and give a clear focus on what they are looking for. A large proportion of their new products now start life outside the company.
18. Adapt a product to a new use. Find an entirely different application for an existing product. De Beers produced industrial diamonds but found a new use for diamonds when they introduced the concept of engagement rings. It opened up a large new market for them.
19. Try Triz. Triz is a systematic method for solving problems. It can be applied in many fields but is particularly useful in engineering and product design. Triz gives you a toolbox of methods to solve contradictions e.g. how can we make this product run faster but with less power?
20. Go back in time. Look back at methods and services that were used in your sector years ago but have now fallen out of use. Can you bring one back in a new updated form? It has been said that Speed Dating is really a relaunch of a Victorian dance format where ladies had cards marked with appointments.
21. Use social networks. Follow trends and ask questions on groups like Twitter or Facebook. Ask what people want to see in future products or what the big new idea will be. Many early adopters are active on social network groups and will happily respond with suggestions.
Tuesday, November 24, 2009
Wiki for requirement management... Why not?!
Today I had a conversation with one of project managers. They need a tool that will help capturing existing system behavior in form of product requirements. I suggested using one of of-the-shelf solutions but he argued that they have good reason to stay within Wiki used for documentation management at the project. I doubted that Wiki is the right place to do this because of its limited functionality. So, it made me go to the Google and seek for the answer.
The result was better than I expected. I found out that many people did this and succeeded. All we need to do is following simple recommendations:
1. Do not let it become a mess
If several people are asked to write comments, change requirements suggesting variants it will soon become a mess. In order to avoid it, there should be strict rules and authorities to changes the requirements clearly defined within the team.
2. Keep it organized
Within time, Wiki description of requirements may deteriorate into amorphous, unstructured document. Especially when there are several contributors, each having own opinion on what it should look like. My recommendation is to keep the structure clear and understood by all contributors, so new articles appear in right place and connected to right pages.
3. Update it often
Do not wait until there are tons of changes to be done. Do it in small steps, immediately after a change comes up.
Wiki is a great tool for the collaboration. But as any tool it should be used wisely. As they say, a fool with a tool is still a fool. Don't be foolish. Find out about the issues before jumping into applying a tool to the process for which it is not intended to be used. Using Wiki for RM... Why not? But let's find out how for the beginning!
Happy requirement management!
The result was better than I expected. I found out that many people did this and succeeded. All we need to do is following simple recommendations:
1. Do not let it become a mess
If several people are asked to write comments, change requirements suggesting variants it will soon become a mess. In order to avoid it, there should be strict rules and authorities to changes the requirements clearly defined within the team.
2. Keep it organized
Within time, Wiki description of requirements may deteriorate into amorphous, unstructured document. Especially when there are several contributors, each having own opinion on what it should look like. My recommendation is to keep the structure clear and understood by all contributors, so new articles appear in right place and connected to right pages.
3. Update it often
Do not wait until there are tons of changes to be done. Do it in small steps, immediately after a change comes up.
Wiki is a great tool for the collaboration. But as any tool it should be used wisely. As they say, a fool with a tool is still a fool. Don't be foolish. Find out about the issues before jumping into applying a tool to the process for which it is not intended to be used. Using Wiki for RM... Why not? But let's find out how for the beginning!
Happy requirement management!
Subscribe to:
Posts (Atom)