OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/openup_basic/guidances/guidelines/staffing_project.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>\openup_basic\guidances\guidelines\staffing_project.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: staffing_project.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_Jq64EJjsEduad8I_c-ogIA CRC: 1011265541 -->Staffing a Project<!-- END:presentationName,_Jq64EJjsEduad8I_c-ogIA -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_Jq64EJjsEduad8I_c-ogIA CRC: 2223451649 -->Advice for how to staff a software development project.<!-- END:briefDescription,_Jq64EJjsEduad8I_c-ogIA -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-HYO1lwAFOxlT7ncq8EjSng CRC: 1232202130 --><p>
     Good software development teams are made up of a collection of people who collaborate effectively. How the project team
     is staffed, by either adding or removing people, will greatly impact the team's productivity.
 </p>
 <p>
     When staffing a development project, consider the following advice:
 </p>
 <ol>
     <li>
         Include people who fit into the existing team culture. Good teams don't just appear magically one day, but instead
         are grown and nurtured over time. Invite people onto the team who will add value and furthermore who will not be
         disruptive. Similarly, you may need to invite someone to leave the team if they do not fit well with the existing
         team and they don't seem to be able to change.
     </li>
     <li>
         People should want to be on the team. People are far more productive when they're working on a project that they
         believe in and want to see succeed.
     </li>
     <li>
         Build your team with "generalizing specialists". A generalizing specialist is someone with one or more technical
         specialties who actively seeks to gain new skills in both their existing specialties as well as in other areas,
         including both technical and domain areas. Generalizing specialists add value to the team because they have
         specialized skills that you need while at the same time appreciate the full range of issues that a general
         understanding of the software development process and the business domain offers.
     </li>
     <li>
         Include stakeholders. Stakeholders, including business stakeholders such as end users and technical stakeholders
         such as operations staff, can add significant value to your team. Instead of just interviewing them to gain
         information from them, or asking them to review your work, why not include them as active participants on the team?
     </li>
     <li>
         Include specialists for short-term, specialized work. Specialists can still add value on an agile development team,
         particularly when they have specific skills and experience which existing team members do not have. It can often be
         more effective to bring a specialist into the team for a short period of time to help with a specific task, such as
         installation and setup of an application server, the development of an architectural spike, or simply taking part
         in a review.
     </li>
     <li>
         Give people opportunities to evolve their skills. At the beginning of a project the team may not have the full
         range of skills that it needs, or perhaps a few individuals may not have the skills required to fulfill the roles
         they are filling. This is a very common risk taken on by the majority of project teams for the simple reasons that
         you often can't find the perfect combination of people and even if you could you still want to provide people with
         opportunities to grow as professionals.
     </li>
     <li>
         Remember Brook's Law. Adding people to a late project will only make it later [<a class=""
         href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
         guid="_9ToeIB83Edqsvps02rpOOg">BRO95</a>]. The corollary is that removing people from a late project may speed
         things up [<a class=""
         href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
         guid="_9ToeIB83Edqsvps02rpOOg">AMB04</a>].
     </li>
 </ol>
 <p>
     Sometimes you will need to go against some of this advice due to environmental constraints. Perhaps only specialists
     are available (although there's nothing stopping a specialist from becoming a generalizing specialist), perhaps there
     aren't as many opportunities for people to try new things as they would like, or perhaps the stakeholders aren't
     available to be active members of the team. The advice above is designed to lead to as high-performing a team as
     possible, but even partial adherence to this guideline will improve the team.
 </p><!-- END:mainDescription,-HYO1lwAFOxlT7ncq8EjSng -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>\openup_basic\guidances\guidelines\staffing_project.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: staffing_project.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_Jq64EJjsEduad8I_c-ogIA CRC: 1011265541 -->Staffing a Project<!-- END:presentationName,_Jq64EJjsEduad8I_c-ogIA -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_Jq64EJjsEduad8I_c-ogIA CRC: 2223451649 -->Advice for how to staff a software development project.<!-- END:briefDescription,_Jq64EJjsEduad8I_c-ogIA -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-HYO1lwAFOxlT7ncq8EjSng CRC: 1232202130 --><p>
	Good software development teams are made up of a collection of people who collaborate effectively. How the project team
	is staffed, by either adding or removing people, will greatly impact the team's productivity.
	</p>
	<p>
	When staffing a development project, consider the following advice:
	</p>
	<ol>
	<li>
	Include people who fit into the existing team culture. Good teams don't just appear magically one day, but instead
	are grown and nurtured over time. Invite people onto the team who will add value and furthermore who will not be
	disruptive. Similarly, you may need to invite someone to leave the team if they do not fit well with the existing
	team and they don't seem to be able to change.
	</li>
	<li>
	People should want to be on the team. People are far more productive when they're working on a project that they
	believe in and want to see succeed.
	</li>
	<li>
	Build your team with "generalizing specialists". A generalizing specialist is someone with one or more technical
	specialties who actively seeks to gain new skills in both their existing specialties as well as in other areas,
	including both technical and domain areas. Generalizing specialists add value to the team because they have
	specialized skills that you need while at the same time appreciate the full range of issues that a general
	understanding of the software development process and the business domain offers.
	</li>
	<li>
	Include stakeholders. Stakeholders, including business stakeholders such as end users and technical stakeholders
	such as operations staff, can add significant value to your team. Instead of just interviewing them to gain
	information from them, or asking them to review your work, why not include them as active participants on the team?
	</li>
	<li>
	Include specialists for short-term, specialized work. Specialists can still add value on an agile development team,
	particularly when they have specific skills and experience which existing team members do not have. It can often be
	more effective to bring a specialist into the team for a short period of time to help with a specific task, such as
	installation and setup of an application server, the development of an architectural spike, or simply taking part
	in a review.
	</li>
	<li>
	Give people opportunities to evolve their skills. At the beginning of a project the team may not have the full
	range of skills that it needs, or perhaps a few individuals may not have the skills required to fulfill the roles
	they are filling. This is a very common risk taken on by the majority of project teams for the simple reasons that
	you often can't find the perfect combination of people and even if you could you still want to provide people with
	opportunities to grow as professionals.
	</li>
	<li>
	Remember Brook's Law. Adding people to a late project will only make it later [<a class=""
	href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
	guid="_9ToeIB83Edqsvps02rpOOg">BRO95</a>]. The corollary is that removing people from a late project may speed
	things up [<a class=""
	href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
	guid="_9ToeIB83Edqsvps02rpOOg">AMB04</a>].
	</li>
	</ol>
	<p>
	Sometimes you will need to go against some of this advice due to environmental constraints. Perhaps only specialists
	are available (although there's nothing stopping a specialist from becoming a generalizing specialist), perhaps there
	aren't as many opportunities for people to try new things as they would like, or perhaps the stakeholders aren't
	available to be active members of the team. The advice above is designed to lead to as high-performing a team as
	possible, but even partial adherence to this guideline will improve the team.
	</p><!-- END:mainDescription,-HYO1lwAFOxlT7ncq8EjSng -->
	</body>
	</html>