Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 2. Individuals Working Better in Some Ways than Others
-
Часть 4
-
After much coaching for six months, his programs still looked like the user interface or the relational database.
What could be done with these people, instead? On the first project, the person was too high on the project ladder to be replaced, and so the project continued to suffer. On the second project, the person was eventually replaced with someone who had good communication skills, who taught the novice programmers basic OO design skills.
On the third project, we were luckier. The person was spectacularly good at defining requirements, where his careful thinking and attention to detail paid off. In exchange for his working on the requirements, he continued doing OO design and programming on sections of the system where the quality of the design was not a critical issue. Everyone benefited: He had fun doing the programming, and the project was safer due to the high quality of his requirements work.
The best programmers on the team may be legalbook.ru so much better than the rest that just a few of the best programmers can put out more than all the rest combined. eBucks. com Goes Live
The top programmer at a consortium of banks, called the First Rand Group, in South Africa managed to get the company's new eBucks system out in just three months. I asked him how he managed that feat. He said that he and one other person had personally programmed it.
I nodded as I heard this. "The old solution. Get the best two programmers to sit together and program it up rather than coordinate 20 people through a fancy methodology. ” But that left an open question. I knew that he had many other duties and would have to attend so many meetings that he couldn't possibly concentrate enough to program. I asked him about that.
He answered, "I attended meetings until 5 p. m. or so and then wrote code from 6 p. m. until 2 a. m. each day. "
Oh. Another far-too-obvious solution. Have the two best people work back-breaking hours for several months. Painful, but effective. This combination of talent and practiced skill I call "personal prowess. " Although a manager can increase the skill of the team members by encouraging them to learn and sending them to courses, he can't change the talent level of the team. A talented designer will still outperform an average designer with good skills.
John Wooden, the famously successful college basketball coach, considers talent such a key issue that he labeled his first coaching secret, "Secret #1: The team with the best players almost always wins. " (Hill 2001, p. 63)
Rewards that Preserve Joy
Inventing reward structures is tricky. I recently got tripped up on this myself, in what I thought was a simple work-reward situation: Picking Dandelions
Dandelions were beginning to clutter our back yard. Having three children aged 10 –and under, I concocted a brilliant solution: I offered them one cent per yellow flower and ten cents for any dandelion in the seeding stage. For five to ten dollars a year, I thought, we'd get rid of dandelions in a few years. The kids brought in bags of dandelions, and I paid out the cash.
On the third year, I commented to my now 12-year-old, Cameron, that it looked like we had more dandelions than the previous year. He said, "Sure. Last year I ran around, dancing and waving all the white dandelions around. When Sean asked why I wasn't just putting them into the bag, I said, 'I'm planting money for next year! '"
If I had that much trouble with that simple situation, how much harder is it to find an appropriate reward for creating software? Should you reward
· Lines of code sent to the test department?
· Low defect rates delivered to the test department?
· Function points delivered each month?
· Number of lines reused from a corporate library? In a Dilbert cartoon, the manager offers rewards related to the number of program bugs discovered. A programmer immediately announces: "I'm writing myself a minivan this afternoon! " (How like the dandelions! )
Even if you can name an appropriate reward structure, what does the organization actually reward? Is it aligned with what is most important for the company? Lines-of-Code-Based Pay
A large company I dare not name ran an initiative to encourage reuse. Programmers' performance, however, was evaluated based on the number of lines of code sent to the test department each month. One person I knew incorporated components from the company's reuse library, as encouraged. She was, however, only given credit for the lines she wrote herself, not those she reused. As a result, she received a low evaluation for her programming performance.
Programmers detect the mismatch and sometimes find subtle ways in which to retaliate. Goldplating
A team leader in a small start-up company complained to me that one of the programmers was adding unnecessary complexity to his design—"goldplating" it—to make it more "interesting" for himself.
When we looked at the matter together, we saw that this person was earning a small, fixed salary in a high-risk position in a start-up company. His risk exposure for working there was high, his reward low. He had evidently made his own self-reward scheme, inventing "cool" code that either would make his daily life interesting or would enhance his employability for the next job.
-