"Mistakes are the portals of discovery."
- James Joyce
"Results? Why man, I have gotten a lot of results. I know 50,000 things that won't work."
- Thomas A. Edison
"There is no security on this earth: There is only opportunity."
- General Douglas MacArthur
"The trouble with most of us is that we would rather be ruined by praise than saved by criticism."- -Norman Vincent Peale
"Assume nothing, pursue everything."
- Kevin Riper
"The best preparation for tomorrow is to do today's work superbly well."
-Sir William Osler
"To find fault is easy: To do better may be difficult."
- Plutarch
”Coming together is a beginning.
Keeping together is progress.
Working together is success.”
- Henry Ford
”The ratio of We’s to I’s is the best indicator of the development of a team.”
- Lewis B. Ergen
”I am easily satisfied with the very best.”
- Winston Churchill
”The future belongs to those who see possibilities before they become obvious.”
- John Scully
”A championship team is a team of champions.”
- Unknown
Tuesday, June 17, 2008
Wednesday, June 11, 2008
Things a developer should never ignore
1: Clarifying user requirements
As you spend more time developing an application, you can sometimes predict some of the requests of your customers. Don’t take this for granted and assume you know more than your users do. When you receive the requirements, spend some time with them and review their specification to confirm you are on the same page. Not doing so can end up costing you time as you rework the application later on.
2: Collaborating
Call it brainstorming, call it peer code review, call it whatever you want — but just make sure you collaborate with those around you. Bouncing ideas off others will help you identify any holes in your potential solution and might even help you develop a solution better than your original design.
3: Version control
Anybody who has ever had his or her code stepped on or deleted knows the value of a good version control system. It doesn’t matter if its CVS, ClearCase, or even Visual Source Safe. Get it, learn it, and use it. You don’t want all your hard work to be blown away with a few mistaken keystrokes.
4: Basic system testing
Most developers don’t like to test. Or maybe I should say most developers hate testing. But it’s crucial for you to do your own testing before you release it to anybody else. Nothing will get your testing group upset and knocking on your door quicker than receiving code that doesn’t perform the basics. Make sure entry screens allow input, check that you can’t enter a letter where only numbers are allowed, verify that reports actually print information and that columns add up — the basic stuff.
5: Usability
Early in my career, I designed a screen for a group of data entry users. I thought my design was so slick. The system had all the bells and whistles they needed and then some. I was just about ready to install it when it was pointed out to me that the users almost never used a mouse. My design had added some buttons to the screen and had them lifting their hands from the keyboard over and over. Not efficient for them and very humbling for me. Spend some time to learn about the types of usability issues your customers may have and everybody will be happier.
6: System performance
In this era of instant gratification, it’s hard to satisfy end users. When they click on a button, they expect that the system will immediately respond. Or they may have the misconception that overnight processes really should take only an hour or two. When developing your application, ensure that you understand what type of response the users expect and require.
7: Comments in your code
Comments are the bane of many developers’ existence. We want to spend our time writing code not writing about code. But most of us have been tasked at some point with going in and maintaining somebody else’s work. If you’re like me, you may have sometimes found it so confusing that your first reaction was to rip it all out and start over. My experiences have taught me that even by adding some very basic commenting around sections of code and trying to use descriptive variable names and the like, you can have a significant positive impact on the next person who has to maintain your legacy.
8: Logging
When you’re developing applications (especially those without any type of user interface), make sure you build some helpful logging solutions into the code. There are few worse things for a developer to do than to try to debug an application with little visibility into what is going on when it is running.
It doesn’t have to be overly complex. Maybe just writing out some of the values of your variables or counters at certain places in the code or when it hits certain subroutines. You can set it up so it logs only when a particular environmental condition exists (maybe a specific text file exists in a directory). Trapping anything that is going to help you track down and resolve issues quickly is what you’re going for here.
9: Keeping your skills up to date
Still coding in something a few years old? Many people work for companies run by legacy applications that are past their prime. But that doesn’t mean you should ignore what’s going on in the world around you. A lot of the new technologies out there can be integrated and could provide a boost to you and your company. Take some time to try to understand them a bit, and who knows when you can use it to your advantage.
10: Taking pride in your work
One thing I always thought about and tried to pass along to my teams was the concept of having pride and ownership in the applications we were responsible for. I never wanted to hear that my applications weren’t working at their peak capabilities or that users were happy. And if we did hear about a problem, we would go out of our way to do everything we could to rectify the situation immediately.
It doesn’t matter if you are a head-down developer in a large organization, a systems designer, or a single jack-of-all-trades for your own company. Taking some of these ideas into consideration will not only help you produce a better end product but it will also allow you continue to evolve yourself and your career to the next level.
Source :Techrepublic Blogs and articles
As you spend more time developing an application, you can sometimes predict some of the requests of your customers. Don’t take this for granted and assume you know more than your users do. When you receive the requirements, spend some time with them and review their specification to confirm you are on the same page. Not doing so can end up costing you time as you rework the application later on.
2: Collaborating
Call it brainstorming, call it peer code review, call it whatever you want — but just make sure you collaborate with those around you. Bouncing ideas off others will help you identify any holes in your potential solution and might even help you develop a solution better than your original design.
3: Version control
Anybody who has ever had his or her code stepped on or deleted knows the value of a good version control system. It doesn’t matter if its CVS, ClearCase, or even Visual Source Safe. Get it, learn it, and use it. You don’t want all your hard work to be blown away with a few mistaken keystrokes.
4: Basic system testing
Most developers don’t like to test. Or maybe I should say most developers hate testing. But it’s crucial for you to do your own testing before you release it to anybody else. Nothing will get your testing group upset and knocking on your door quicker than receiving code that doesn’t perform the basics. Make sure entry screens allow input, check that you can’t enter a letter where only numbers are allowed, verify that reports actually print information and that columns add up — the basic stuff.
5: Usability
Early in my career, I designed a screen for a group of data entry users. I thought my design was so slick. The system had all the bells and whistles they needed and then some. I was just about ready to install it when it was pointed out to me that the users almost never used a mouse. My design had added some buttons to the screen and had them lifting their hands from the keyboard over and over. Not efficient for them and very humbling for me. Spend some time to learn about the types of usability issues your customers may have and everybody will be happier.
6: System performance
In this era of instant gratification, it’s hard to satisfy end users. When they click on a button, they expect that the system will immediately respond. Or they may have the misconception that overnight processes really should take only an hour or two. When developing your application, ensure that you understand what type of response the users expect and require.
7: Comments in your code
Comments are the bane of many developers’ existence. We want to spend our time writing code not writing about code. But most of us have been tasked at some point with going in and maintaining somebody else’s work. If you’re like me, you may have sometimes found it so confusing that your first reaction was to rip it all out and start over. My experiences have taught me that even by adding some very basic commenting around sections of code and trying to use descriptive variable names and the like, you can have a significant positive impact on the next person who has to maintain your legacy.
8: Logging
When you’re developing applications (especially those without any type of user interface), make sure you build some helpful logging solutions into the code. There are few worse things for a developer to do than to try to debug an application with little visibility into what is going on when it is running.
It doesn’t have to be overly complex. Maybe just writing out some of the values of your variables or counters at certain places in the code or when it hits certain subroutines. You can set it up so it logs only when a particular environmental condition exists (maybe a specific text file exists in a directory). Trapping anything that is going to help you track down and resolve issues quickly is what you’re going for here.
9: Keeping your skills up to date
Still coding in something a few years old? Many people work for companies run by legacy applications that are past their prime. But that doesn’t mean you should ignore what’s going on in the world around you. A lot of the new technologies out there can be integrated and could provide a boost to you and your company. Take some time to try to understand them a bit, and who knows when you can use it to your advantage.
10: Taking pride in your work
One thing I always thought about and tried to pass along to my teams was the concept of having pride and ownership in the applications we were responsible for. I never wanted to hear that my applications weren’t working at their peak capabilities or that users were happy. And if we did hear about a problem, we would go out of our way to do everything we could to rectify the situation immediately.
It doesn’t matter if you are a head-down developer in a large organization, a systems designer, or a single jack-of-all-trades for your own company. Taking some of these ideas into consideration will not only help you produce a better end product but it will also allow you continue to evolve yourself and your career to the next level.
Source :Techrepublic Blogs and articles
Tuesday, June 10, 2008
Few things to motivate your team.
#1: Believe in your team’s objectives
Do you believe in what you want the team to accomplish? Do you think your goals are realistic? If not, rethink your position, because your team will sense your uncertainty. You may say the right words, but your body language and overall demeanor will give you away. On the other hand, if you truly are dedicated and believe in your goals, your team will sense it and will react accordingly.
#2: Model the behavior you want from the team
Don’t be a hypocrite — lead by example. You want your team to interact courteously and professionally with others, but do you do so yourself? If you ask them to put in extra hours, are you there along with them? Country artist Rodney Atkins sings about how one day, his four-year-old son said “a four-letter word,” but how later that night, all by himself he got on his knees and prayed. What did the son say when asked about how he learned to do both things? “I’ve been watchin’ you.”
#3: Keep a positive attitude
Game 1 of the NBA Finals has just begun. Fifteen seconds into the game, one team connects on a field goal, making the score 2-0. The other coach slumps in his chair, puts his head in his hands, and yells, “@(*@&@, this series is OVER!!”
(On November 12, 1989): Person 1: “The Berlin Wall just came down!” Person 2: “Horrible! The guards are now out of a job!”
Don’t laugh. If you have these attitudes, how do you think your team will react? If you model a negative attitude, your team will pick it up. I know it sounds trite, but try to stay upbeat.
Doing so doesn’t mean being unrealistic. It does mean, however, that you try to look at the glass as being half full rather than half empty. Instead of saying, for example, “This project will never succeed because of issues 1, 2, and 3,” consider saying, “If we want this project to succeed, it’s critical that we resolve issues 1, 2, and 3.”
#4: Be clear about your goals
It’s hard for your team to accomplish its goals if those goals are unclear or unknown to them. More important, it’s hard to get them even to agree with those goals if they don’t know what they are. Make sure your team knows what you are expecting of them. If you can quantify your goals so that you can measure how well you did compared to what you expected, so much the better.
#5: Get feedback from the team members
Unless you hear from your team members, you may have little or no idea of how effective or clear you are. Few of us enjoy hearing bad news or criticism, but if there’s a problem in what we’re doing, it’s important that we hear it.
When discussing issues with the team, don’t shoot the messenger. When listening to a team member, try to separate the message and issue from the person. Similarly, when someone is offering suggestions or discussing issues, try to separate your own self and ego from the discussion. If you do shoot the messenger, all you will have done is make your team even more reluctant to talk frankly with you in the future.
#6: Set expectations
Make sure your team knows what to expect of you. If they do, there’s less chance that they’ll be unpleasantly surprised or disappointed.
Suppose, from the previous point, you had a discussion with a team member, who made a few suggestions. Some of them are workable (so that you could act on them), but others aren’t. Before having this discussion, it would be good to let your team know that while you will listen to them, you may or may not adopt all of their suggestions. One would hope they’d realize this already, but it’s best to be explicit. Furthermore, if you do adopt a suggestion, make sure everyone knows about it.
#7: Avoid mixed messages
Consultant and trainer Robert Mager, in his book Analyzing Performance Problems, discusses the uses of consequences and rewards in shaping human behavior. Specifically, he points out that to encourage desirable behavior, there must be positive rewards for it. Conversely, to discourage undesirable behavior, there must be consequences that result from it. Believe it or not, some people mix up these two points. Have you, as a parent, ever said to your child, “Any time you have problem, you can talk to Mommy or Daddy”? What happens when they do? You become irritated and yell at them, “Come back later! Can’t you see I’m busy?!” If you send similar mixed messages to your staff, you will make it harder for them to act the way you want.
#8: Know the difference between exhorting and belittling
It’s fine and good for you to want greater and higher quality results from your team. However, be aware of the line between exhorting someone to do better and belittling them because they aren’t right now. The latter might work, but the chances are greater that it might only create resentment and turn out to be counterproductive.
A couple of weeks ago, after a rehearsal of the choir I direct, I said to two young men, “I want to see confidence in your eyes when you’re singing.” I didn’t say to them, “You idiots, you don’t know the music.” In other words, in keeping with the positive/negative point discussed earlier, I focused on where I wanted them to be, rather than on the fact that they weren’t there right now.
#9: Correct in private
If personal issues of a team member are becoming a problem, address them with the person in private. Don’t embarrass the person by bringing it up in public. Such issues include attendance and punctuality, dress, and general professionalism.
What about a mistake involving work? Use discretion here. Using the choir example again: Suppose a person has an incorrect rhythm in a measure. I will just take a moment and work it out with that person in front of the group. If he or she gets it, fine. However, if he or she were consistently missing notes and rhythms, I would need to talk privately with that person to see what’s going on.
#10: Praise in public
When someone does something right, you probably are happy and want that person to continue doing it. You also probably want to make that person look good in front of the others, and for the others to be motivated to improve their own performance. For those reasons, recognize good work in public, rather than in private.
Other things being equal, of course, most people would prefer money and praise rather than praise alone. However, praise alone still can motivate, as long as you’re sincere and specific in what you’re praising. Generalities are unhelpful. Rather, focus on the specific action, and how it benefited the group.
In the case of the young men I mentioned earlier, I spoke to them again just a few days ago, after our last rehearsal, which went really well. I said to one of them, “Remember I told you I wanted to see confidence in your eyes? Well, I see it now.” To the other, I said, “You’ve been practicing, right?” When he nodded yes, I continued, “See what a difference it makes?”
#11: Believe in your team
England expects every man to do his duty.
The Battle of Trafalgar, in 1805, established British naval supremacy for decades afterward. In that battle, a fleet led by Admiral Lord Horatio Nelson defeated a combined French and Spanish fleet off the coast of southwest Spain, near Cape Trafalgar. As both sides were preparing for the battle, Nelson sent his now-famous message to his fleet. Sadly, Nelson suffered a mortal wound and did not live to see his ultimate victory.
People tend to live up, or down, to your expectations. If you expect high performance from them, and they realize it, you have a greater chance of getting such performance than if you expect low performance.
It can be rewarding to see a team come together and execute the way you want. It’s even more rewarding to see people develop the way you want. However, try to be realistic. The members of my choir are all teenagers and friends with my younger daughter, Rayna. One day, I asked her, “Rayna, do some people in the choir tell you how much I’ve influenced them?” At that, Rayna replied, “Daddy, don’t flatter yourself.”
Note:Source Techrepublic
Do you believe in what you want the team to accomplish? Do you think your goals are realistic? If not, rethink your position, because your team will sense your uncertainty. You may say the right words, but your body language and overall demeanor will give you away. On the other hand, if you truly are dedicated and believe in your goals, your team will sense it and will react accordingly.
#2: Model the behavior you want from the team
Don’t be a hypocrite — lead by example. You want your team to interact courteously and professionally with others, but do you do so yourself? If you ask them to put in extra hours, are you there along with them? Country artist Rodney Atkins sings about how one day, his four-year-old son said “a four-letter word,” but how later that night, all by himself he got on his knees and prayed. What did the son say when asked about how he learned to do both things? “I’ve been watchin’ you.”
#3: Keep a positive attitude
Game 1 of the NBA Finals has just begun. Fifteen seconds into the game, one team connects on a field goal, making the score 2-0. The other coach slumps in his chair, puts his head in his hands, and yells, “@(*@&@, this series is OVER!!”
(On November 12, 1989): Person 1: “The Berlin Wall just came down!” Person 2: “Horrible! The guards are now out of a job!”
Don’t laugh. If you have these attitudes, how do you think your team will react? If you model a negative attitude, your team will pick it up. I know it sounds trite, but try to stay upbeat.
Doing so doesn’t mean being unrealistic. It does mean, however, that you try to look at the glass as being half full rather than half empty. Instead of saying, for example, “This project will never succeed because of issues 1, 2, and 3,” consider saying, “If we want this project to succeed, it’s critical that we resolve issues 1, 2, and 3.”
#4: Be clear about your goals
It’s hard for your team to accomplish its goals if those goals are unclear or unknown to them. More important, it’s hard to get them even to agree with those goals if they don’t know what they are. Make sure your team knows what you are expecting of them. If you can quantify your goals so that you can measure how well you did compared to what you expected, so much the better.
#5: Get feedback from the team members
Unless you hear from your team members, you may have little or no idea of how effective or clear you are. Few of us enjoy hearing bad news or criticism, but if there’s a problem in what we’re doing, it’s important that we hear it.
When discussing issues with the team, don’t shoot the messenger. When listening to a team member, try to separate the message and issue from the person. Similarly, when someone is offering suggestions or discussing issues, try to separate your own self and ego from the discussion. If you do shoot the messenger, all you will have done is make your team even more reluctant to talk frankly with you in the future.
#6: Set expectations
Make sure your team knows what to expect of you. If they do, there’s less chance that they’ll be unpleasantly surprised or disappointed.
Suppose, from the previous point, you had a discussion with a team member, who made a few suggestions. Some of them are workable (so that you could act on them), but others aren’t. Before having this discussion, it would be good to let your team know that while you will listen to them, you may or may not adopt all of their suggestions. One would hope they’d realize this already, but it’s best to be explicit. Furthermore, if you do adopt a suggestion, make sure everyone knows about it.
#7: Avoid mixed messages
Consultant and trainer Robert Mager, in his book Analyzing Performance Problems, discusses the uses of consequences and rewards in shaping human behavior. Specifically, he points out that to encourage desirable behavior, there must be positive rewards for it. Conversely, to discourage undesirable behavior, there must be consequences that result from it. Believe it or not, some people mix up these two points. Have you, as a parent, ever said to your child, “Any time you have problem, you can talk to Mommy or Daddy”? What happens when they do? You become irritated and yell at them, “Come back later! Can’t you see I’m busy?!” If you send similar mixed messages to your staff, you will make it harder for them to act the way you want.
#8: Know the difference between exhorting and belittling
It’s fine and good for you to want greater and higher quality results from your team. However, be aware of the line between exhorting someone to do better and belittling them because they aren’t right now. The latter might work, but the chances are greater that it might only create resentment and turn out to be counterproductive.
A couple of weeks ago, after a rehearsal of the choir I direct, I said to two young men, “I want to see confidence in your eyes when you’re singing.” I didn’t say to them, “You idiots, you don’t know the music.” In other words, in keeping with the positive/negative point discussed earlier, I focused on where I wanted them to be, rather than on the fact that they weren’t there right now.
#9: Correct in private
If personal issues of a team member are becoming a problem, address them with the person in private. Don’t embarrass the person by bringing it up in public. Such issues include attendance and punctuality, dress, and general professionalism.
What about a mistake involving work? Use discretion here. Using the choir example again: Suppose a person has an incorrect rhythm in a measure. I will just take a moment and work it out with that person in front of the group. If he or she gets it, fine. However, if he or she were consistently missing notes and rhythms, I would need to talk privately with that person to see what’s going on.
#10: Praise in public
When someone does something right, you probably are happy and want that person to continue doing it. You also probably want to make that person look good in front of the others, and for the others to be motivated to improve their own performance. For those reasons, recognize good work in public, rather than in private.
Other things being equal, of course, most people would prefer money and praise rather than praise alone. However, praise alone still can motivate, as long as you’re sincere and specific in what you’re praising. Generalities are unhelpful. Rather, focus on the specific action, and how it benefited the group.
In the case of the young men I mentioned earlier, I spoke to them again just a few days ago, after our last rehearsal, which went really well. I said to one of them, “Remember I told you I wanted to see confidence in your eyes? Well, I see it now.” To the other, I said, “You’ve been practicing, right?” When he nodded yes, I continued, “See what a difference it makes?”
#11: Believe in your team
England expects every man to do his duty.
The Battle of Trafalgar, in 1805, established British naval supremacy for decades afterward. In that battle, a fleet led by Admiral Lord Horatio Nelson defeated a combined French and Spanish fleet off the coast of southwest Spain, near Cape Trafalgar. As both sides were preparing for the battle, Nelson sent his now-famous message to his fleet. Sadly, Nelson suffered a mortal wound and did not live to see his ultimate victory.
People tend to live up, or down, to your expectations. If you expect high performance from them, and they realize it, you have a greater chance of getting such performance than if you expect low performance.
It can be rewarding to see a team come together and execute the way you want. It’s even more rewarding to see people develop the way you want. However, try to be realistic. The members of my choir are all teenagers and friends with my younger daughter, Rayna. One day, I asked her, “Rayna, do some people in the choir tell you how much I’ve influenced them?” At that, Rayna replied, “Daddy, don’t flatter yourself.”
Note:Source Techrepublic
Thursday, June 5, 2008
What is CMM level
A maturity model is a structured collection of elements that describe certain aspects of maturity in an organization. A maturity model may provide, for example:
- a place to start
- the benefit of a community’s prior experiences
- a common language and a shared vision
- a framework for prioritizing actions
- a way to define what improvement means for your organization.
A maturity model can be used as a benchmark for comparison and as an aid to understanding - for example, for comparative assessment of different organizations where there is something in common that can be used as a basis for comparison. In the case of the CMM, for example, the basis for comparison would be the organisations' software development processes.
The levels are:Level 1 - Ad hoc (Chaotic)
It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events.Level 2 - Repeatable
It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule.
Level 3 - DefinedIt is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization. Projects establish their defined processes by applying the organization’s set of standard processes, tailored, if necessary, within similarly standardized guidelines.
Level 4 - Managed
It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.
Level 5 - Optimized
It is characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.
The CMMI contains several key process areas indicating the aspects of product development that are to be covered by company processes.
| Abbreviation | Name | Area | Maturity Level |
|---|---|---|---|
| REQM | Requirements Management | Engineering | 2 |
| PMC | Project Monitoring and Control | Project Management | 2 |
| PP | Project Planning | Project Management | 2 |
| SAM | Supplier Agreement Management | Project Management | 2 |
| CM | Configuration Management | Support | 2 |
| MA | Measurement and Analysis | Support | 2 |
| PPQA | Process and Product Quality Assurance | Support | 2 |
| PI | Product Integration | Engineering | 3 |
| RD | Requirements Development | Engineering | 3 |
| TS | Technical Solution | Engineering | 3 |
| VAL | Validation | Engineering | 3 |
| VER | Verification | Engineering | 3 |
| OPD | Organizational Process Definition | Process Management | 3 |
| OPF | Organizational Process Focus | Process Management | 3 |
| OT | Organizational Training | Process Management | 3 |
| IPM | Integrated Project Management | Project Management | 3 |
| ISM | Integrated Supplier Management | Project Management | 3 |
| IT | Integrated Teaming | Project Management | 3 |
| RSKM | Risk Management | Project Management | 3 |
| DAR | Decision Analysis and Resolution | Support | 3 |
| OEI | Organizational Environment for Integration | Support | 3 |
| OPP | Organizational Process Performance | Process Management | 4 |
| QPM | Quantitative Project Management | Project Management | 4 |
| OID | Organizational Innovation and Deployment | Process Management | 5 |
| CAR | Causal Analysis and Resolution | Support | 5 |
Source:WikiPedia
Subscribe to:
Posts (Atom)