📄 lib0064.html
字号:
<html>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<head>
<title>Common Mistakes</title>
<link rel="STYLESHEET" type="text/css" href="images/xpolecat.css">
<link rel="STYLESHEET" type="text/css" href="images/ie.content.css">
</head>
<body>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td><div STYLE="MARGIN-LEFT: 0.15in;"><a href="toc.html"><img src="images/teamlib.gif" width="62" height="15" border="0" align="absmiddle" alt="Team LiB"></a></div></td>
<td align="right"><div STYLE="MARGIN-LEFT: 0.15in;">
<a href="LiB0063.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0065.html"><img src="images/next.gif" width="41" height="15" border="0" align="absmiddle" alt="Next Section"></a>
</div></td></tr></table>
<br>
<div class="chapter">
<a name="ch09"></a>
<div class="section">
<h2 class="first-section-title"><a name="289"></a><a name="ch09lev1sec3"></a>Common Mistakes</h2><a name="290"></a><a name="IDX-116"></a>
<p class="para">
<b class="bold">Going straight to code.</b> Many developers are impatient with design. They view object-modeling and data-modeling activities as boring compared with coding. I've seen many projects proceed to coding without doing enough modeling to figure out what the target is first. Although most of those projects eventually were finished, they usually used more resources than was necessary. Sometimes, targetless efforts can use two to four times the required resources.</p>
<p class="para">A good analogy is residential construction. When contractors build houses, they create the blueprints first to avoid costly mistakes and rework. Object models and data models are effectively blueprints for J2EE applications.</p>
<p class="para">
<b class="bold">Permitting a moving target.</b> Once scope is decided for the project (e.g., it has been decided which use cases will be implemented, and the content of those use cases has enough detail from which to design), discourage or even outlaw scope increases. I know this is easier said than done. <a href="LiB0065.html#295" target="_parent" class="chapterjump">McConnell (1998)</a> suggests installing a change control board, which is charged with reviewing and authorizing all change requests once a project has progressed passed analysis and high-level design. The existence of a change control board effectively discourages scope increases by creating bureaucratic red tape.</p>
<p class="para">If you can't avoid adding something to a project late in the game, make sure the additional activities, time, and costs get added to the project plan. Also, make sure that the revised project plan reflects the fact that the time spent on analysis and design for the new features zapped time from what you were supposed to be doing (making it late, too). If the new feature causes rework on tasks already completed, make sure that those costs are also documented for all to see.</p>
<p class="para">Think of the residential construction analogy again. Changes in homebuyer wants and desires cause rework and impact the delivery date.</p>
<p class="para">
<b class="bold">Not correcting personnel assignment mistakes.</b> Of course, it's best to avoid making mistakes in the first place. But when mistakes happen, your best course of action is to recognize and fix them rather than ignore them. The most damaging mistakes in large projects are in the areas of personnel task assignment. This type of mistake is so damaging because most managers are unable to gather the courage to correct the mistakes, thus allowing them to continue.</p>
<p class="para">Although the project manager traditionally handles personnel assignments, the architect (with more knowledge of technical skill sets) should at <a name="291"></a><a name="IDX-117"></a>least serve in an advisory role. <a href="LiB0065.html#293" target="_parent" class="chapterjump">DeMarco and Lister (1999)</a> make some interesting observations:</p>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">The best person on the team outperforms the worst by 10:1.</p>
</li>
<li class="listitem">
<p class="first-para">The best performer on the team is about 2.5 times better than the average.</p>
</li>
</ul>
<p class="para">In addition, people generally are extremely good at some tasks but poor at others. Good project managers learn to recognize the difference and adjust assignments appropriately. For example, someone might be a whiz when it comes to coding the presentation tier but a complete dud at coding architectural components. Some people can perform testing with ease but are poor at coding.</p>
<p class="last-para">
<b class="bold">Saving integration testing activities until the end of the project.</b> Analysis and design mistakes and omissions often aren't visible until construction begins. Integration testing the application makes analysis and design mistakes visible even if the application is only partially functional. Finding these mistakes earlier in the project gives you a chance to correct the error with fewer effects to the project timeline.</p>
</div>
</div><br>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td><div STYLE="MARGIN-LEFT: 0.15in;"><a href="toc.html"><img src="images/teamlib.gif" width="62" height="15" border="0" align="absmiddle" alt="Team LiB"></a></div></td>
<td align="right"><div STYLE="MARGIN-LEFT: 0.15in;">
<a href="LiB0063.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0065.html"><img src="images/next.gif" width="41" height="15" border="0" align="absmiddle" alt="Next Section"></a>
</div></td></tr></table>
</body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -