2011年6月5日日曜日

97 things Every Project Manager Should Know を読んでみた(2)

Avoid Whack-a-Mole Development

モグラたたき開発から逃げろ


開発する早さの評価に関するエッセイ。
日本のSIerではバーニーさんの方が評価される傾向にありますね。
ものづくり日本という標語が盛んに叫ばれたりしています。
でも、なんか年末になるといらない工事とかがあったりして、
作りっぱなし日本という標語が適切な気がしなくもないです。
だからこそ、読んでほしい一節です。

ちなみに、前回と同じく、翻訳の詳しいところはいい加減です。
翻訳はノリが大事です。
多分怪しいところは満載なので、ツッコミ歓迎です。
それと、オレには突っ込まないけど、オレだけ知ってウッシッシな人はGoogle 翻訳にでもかけてください。

SOFTWARE PROJECT MANAGERS faces a lot of pressure to deliver fast. Time is of the essence. How can you get things done fast?



Imagine you have two programmers on your team, Bernie and Rob. Both are capable, have the same amount of domain knowledge, and have equal language skills. During development, you find that Bernie finishes his feature implementations much faster than Rob.



While Bernie focuses on getting the code completed quickly, Rob spends time writing code and then refactoring it. He names the variables and methods better. Once he gets things working, he breaks the code into smaller pieces. Now he writes tests to make sure each piece of his code does what he meant it to do. When he's reasonably satisfied, he declares the coding of that functionality done.




But assume you don't know these details. If you only look at the speed with which the functionalities are declared done, clearly Bernie is the better man, right?



A few weeks go by, and you demonstrate the features to your customer. As usual, the customer loves your completed features, but now wants you to change and improve them. You ask your developers to make those code alterations. When you take the new and improved functionality back to your customer, they try out the features that Rob implemented and are pleased with the changes.



Unfortunately, they discover something odd with the features that Bernie implemented. While Bernie has programmed in the new functions fine, now a few things that worked before don't work anymore. The customer marks these as defects, and you ask Bernie to fix them. The customer tests the features again. Now even newer, stranger things seem to be broken. What's going on here?



If you have a child, you know what is happening. Bernie has created a Whack-A-Mole application. Whack-A-Mole is a toy. Kids are given a wooden hammer to strike moles that pop up at random. It's fun for them to be surprised by which mole pops up next. However, fixing applications with broken code popping up at random places is not fun. It is frustrating, unpredictable, and it slows your product development. Bernie was sprinting initially, but he was running in the wrong direction.



While Rob appeared slower at the outset, he was actually creating superior code. His pace proved sustainable. The better quality of his initial code helped him make workable changes quickly. Plus, the test he wrote in the beginning gave him instant feedback regarding whether or not his new code was compatible with other parts of the application where the code was used.



When measuring time for a feature implementation, do not consider only the time it takes to write it in the first place. Add the time it takes to enhance, fix, and improve the code. Writing good quality code and tests takes time. It appears to be a short-term loss. However, it comes with a long-term gain.

Ask yourself if you want speed, or if you want to savor sustainable progress.



ま、このブログを読む人なんて、えらいプロジェクトマネージャーなんかいないだろうけどね。
それと、お客さんに同じ機能のテストをさせるなんて、どう考えたってムダでしかない。
ソフトウェアを作りっぱなしで、お客さんになんども同じことをさせるのはどうかと思う。

0 件のコメント:

コメントを投稿