Section 6 is all about Weak and Strong Points. This is about finding the places where you can attack an enemy, or to see where the mistakes are going to be, in project parlance this would be equivalent to checking for failures. A good thing for a person in QA, or QC, for that matter. It also ties in to the other sections which focused on offense and defensive postures (Section 4), Energy (or direct/indirect measures) (Section 5) and now when there is an understanding of how to position yourself and probe for weakness – you need to strike. At least in a military sense.
Sun Tzu said: Whoever is first in the field and awaits the coming of the enemy, will be fresh for the fight; whoever is second in the field and has to hasten to battle will arrive
Exhausted.
A pretty easy one for any person coming onto a project, if you come in from the beginning then you are able to handle the work and can do it at your own pace, come in with 4 weeks remaining to do a whole project-ful of work and you will rush and exhaust yourself. In one respect this is a good way to think of when QA should be brought into a project, come in at the beginning and you have a grasp of the overview and the work necessary to be completed. Documentation, or any necessary items that must be done, can be handled with enough time to meet deadlines, or aid in the planning of the project. Come in late in the project and its all catch-up. QA available and involved at the beginning can generate a Test Strategy, Plans, Cases, Scripts or whatever is needed; come in just before a release build is made and it’s a rush to get things in place. Make sure you have the time and resources available and be able to learn about the project, getting thrown in will assure that you will be exhausted at the end, and regardless of all the Herculean tasks accomplished by others, and you may find that it was not your best work or at all something you want to be associated with after.
Therefore the clever combatant imposes his will on the enemy, but does not allow the enemy's will to be imposed on him.
Another reason why QA should be involved at the beginning, or in some cases the way to be sure that you have input into the project and not let the project have input into you. Impress QA on the project; do not have the project impressed on QA, which will always be a losing battle. Just as the armies of centuries ago positioned themselves to the place of greatest advantage, putting QA in a position where it is overwhelmed only leads to failure. As has been said, be aware of the layout of the field, the position of your opponent and see the strong and weak points in order to predict the work that will come.
Appear at points which the enemy must hasten to defend; march swiftly to places where you are not expected.
Think ahead. Not much more to add to that. Might be a good thing to keep on my white board, but never let the current situation focus you only on the moment, be aware of what is around you and coming. That is what separates the men from the boys, so to speak. Its also what makes a great manager as opposed to a bad one, knowing what is coming into the department after the current project and keeping your team apprised of it while making sure they can do the current work makes their lives easier. When your team is happy you are happy, and when you are happy then work is a much nicer place to be.
Hence that general is skillful in attack whose opponent does not know what to defend; and he is skillful in defense whose opponent does not know what to attack.
Basically the Art of War in one sentence. It’s also a way to think of planning, as I have mentioned previously be aware of all the needs, this reinforces the way to anticipate changes in the project. Just as there is the need to “think out of the box” for determining a bug, so planning requires similar thinking. I am a big fan of planning, but its also the process in which the planning is done, I document a lot of the process but this is one area I am always bad in documenting, because I know how I would plan a task, but its not always the same as someone else so why document my personal method? Because someone may actually be able to improve their own by knowing what I do, but by the same token I am now skillful in planning when the project I am on doesn’t know the plan; or in some cases if the PM is lacking I look better in comparison.
Knowing the place and the time of the coming battle, we may concentrate from the greatest distances in order to fight.
Knowing when the final test effort will be, no matter how long, gives the time to plan. Prepare ahead of time, everything you need, and keep an eye on those resources. Plenty of times I have had to pitch in on an emergency situation because the main project is running and something came up but I cannot take a resource away; I’ve also tested multiple builds with different bugs to verify at the same time but I don’t suggest that. Knowing when you are due for a release and how much work is left, keep milestones along the way; its a good way to have an idea of what is going on, will help in being able to say at any time – we can ship on that date. I always try and keep a pulse on where things are and how they are going so if I am asked I can give a status, or at least know who needs to give me an update. Knowledge is a powerful thing.
All men can see the tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved.
At the end of a project everyone can see the result, but not the path you walked on to get there. That path may be a tough thing, and while its great historical data, knowing how many bugs were closed when does not always give you a good idea of resource allocation in testing and its results; I distrust pure numbers in a field where Risk Mitigation often involves some sort of feel for where the project is.
Do not repeat the tactics which have gained you one victory, but let your methods be regulated by the infinite variety of circumstances.
…also…
He who can modify his tactics in relation to his opponent and thereby succeed in winning, may be called a heaven- born captain.
The five elements (water, fire, wood, metal, earth) are not always equally predominant;
Be flexible, the project plan that worked for the last release may not work for the next, be aware you will need to change strategy at some point. Just as I said history will not always give you good numbers, so you should be able to look back and still be able to see what worked and what did not. Did doing piece A before piece B give the result we wanted? Was there a need that came up for automation that took up time? These sorts of things should come out in a retrospective or a post mortem, in order to improve the process, but more often than not most companies just jump into the next release. Being a believer in the power of history its worth taking some time to discuss the project, not with heated emotions but a little dispassionately, to get what worked and what did not out in the open. Advocate for what is needed after the discussion, but let everyone have a say as to what they thought went well or not, you might be surprised at what some people come up with.
Oh yeah..almost halfway done! 6 down.
Thanks for reading!
No comments:
Post a Comment