SharePoint 2010: Prepare your team
Selecting and creating the proper development team structure is critical for successful SharePoint solution development.
Steve Wright and Corey Erkes
Adapted from “Pro SharePoint 2010 Governance” (Apress, 2012)
One of the more flexible aspects of SharePoint as a collaboration platform is the ability to prepare and deploy custom business applications. This can be a complex process. There are many differing opinions on the most efficient and effective size and structure of your SharePoint solution development team.
Proponents of Agile solution development prefer smaller teams because regular one-on-one communication is considered an essential aspect of the process. For large development projects, a single smaller team may not provide enough capacity to satisfy the need for new functionality. In this case, assigning multiple small teams is usually more effective than a single increasingly large team.
Planning for and assigning a division of labor between multiple teams becomes essential. There are three primary ways to structure multiple teams for SharePoint solution development:
- Parallel team structure
- Linear team structure
- Component-based team structure
Remember that in SharePoint, a solution package is the unit of deployment. While you and your teams can create a single massive solution package for a large application, it’s usually preferable to break it up into several related packages you can test and version individually.
Parallel team structure
The first team structure is one in which different teams work in parallel to create a set of solution packages that make up the final release. Each team is responsible for one or more solution packages. Features within these packages may depend on one another, but they shouldn’t depend on packages produced by another team.
A parallel structure works best when you can break the application’s functionality into more or less independent sub-applications. Each team creates and unit tests their own components and checks them into source control. The automated build process then combines the packages from various teams into a single release. This process lets your teams work independently of one another most of the time with a minimum amount of coordination required between teams during development.
Linear team structure
The next structure you might consider is a linear, or layered, team structure. In this case, each team is responsible for developing functionality at one layer of the application. For example, you might have three teams developing solution packages that will be layered together. Team 1 creates the bottom framework layer and checks it into source control. Team 2 retrieves the solutions from Team 1 and uses them as a framework or toolkit for building the next layer up the stack. Team 2 then passes the second layer of components to Team 3.
A linear structure is best suited to situations where an application is built in layers of abstraction or frameworks. SharePoint itself is a good example of this type of design. The features that make up SharePoint Foundation create a layer of tools that other SharePoint-based applications can use.
One example of an application built using this toolkit is SharePoint Server 2010. The server product is really just a set of components built on top of the foundation provided by SharePoint Foundation. Microsoft Project Server and Microsoft CRM are other examples of solutions built with this development process.
When developing solutions in layers, each layer will usually be dependent on features provided at lower levels in the stack. These dependencies can be declared in the solutions and features that are developed to ensure that all prerequisites are met when activating a feature in a SharePoint site.
Component-based team structure
Whereas the parallel and linear approaches separate development by assigning solution packages to different teams, there are cases where this just isn’t possible. In this case, you and your teams might need to take a component-based approach. This type of structure assigns components such as Web Parts, forms, workflows and the like to various teams. These are independently tested and checked into source control. Only then are the components packaged for delivery.
This type of structure is very flexible because you can move components from one team to another as needed without affecting the packaging of the application. Unfortunately, this also makes the various teams interdependent.
Teams working on the same solution packages need to be sure that any changes that may affect components developed by other teams are clearly communicated. Integration testing based on running the final packages is critical in this type of environment. The most likely source of bugs in any system is at each boundary between components developed by different teams.
Team development strategy
There are several other considerations to keep in mind when mapping out your team development strategy:
- Will each team have a separate automated build schedule?
- Will each team have a separate integration test farm, or will they all share a single farm?
- How will you plan releases to allow each component to be completed in the order needed by other teams that depend on it?
- How much communication is required within and between teams?
- Will all teams be in the same physical location?
- Who is responsible for integration testing the final release prior to delivery for acceptance testing?
Of course, as applications become larger and more complex, it’s likely that no single team structure will be sufficient. A hybrid approach using a combination of parallel, linear and component-based teams will become the norm in large organizations.
The governance team should ensure that all teams understand their assigned responsibilities. They must ensure that the teams perform rigorous testing on the solutions prior to deploying them on SharePoint.
.jpg "Steve Wright")
Steve Wright is a senior manager in business intelligence management for Sogeti USA LLC in Omaha, Neb. Over the last 20-plus years, Wright has worked on air traffic control, financial, insurance and a multitude of other types of systems. He has authored and performed technical reviews for many previous titles covering Microsoft products including Windows, SharePoint, SQL Server and BizTalk.
.jpg "Corey Erkes")
Corey Erkes is a manager consultant for Sogeti USA LLC in Omaha, Neb. Erkes has worked with a wide range of companies at different points in the lifecycles of their SharePoint implementations. He is also one of the founding members of the Omaha SharePoint User Group.
©2012 Apress Inc. All rights reserved. Printed with permission from Apress. Copyright 2012. “Pro SharePoint 2012 Governance” by Steve Wright and Corey Erkes. For more information on this title and other similar books, please visit apress.com.