Each SharePoint development
project is made up of a unique team of talented individuals, each with
their own preferences, code patterns, preferences, and style of working.
This section covers a number of important areas:
- Selecting software development methodology
- Setting development standards and best practices
- Managing, tracking, and recording key design decisions
- Planning for regular code reviews
- Large project considerations
- Large project life-cycle models
- Departmental teams
- Offshore teams
It is fundamental to set up the development team properly to ensure your SharePoint 2013 project will be successful.
Selecting Software Development Methodology
Usually, SharePoint projects are based
on Agile development methodologies. Development occurs iteratively, and
deliverables are divided into a smaller set of entities, which can then
be delivered at different times. These methodologies are popular
because they provide visible progress on the project. By splitting
projects into smaller iterations, you can track the individual tasks
more easily and follow up on the overall progress of your project.
The selection of a software development
methodology may also be influenced by whether the project is in-house,
offshore, or a partner lead delivery. In-house or partner-led
deliveries will more than likely use a methodology the team has already
adopted and can understand. Although offshore development and test
teams may use an Agile or Scrum-orientated approach, they benefit
greatly from an onshore waterfall process that require rock-solid
requirements, technical specifications, and as little ambiguity to
ensure the business or supplier receives the level of quality the first
time around. Using the incorrect methodology with an offshore team may
decrease the commercial viability of using an offshore team.
One of most well-known methodologies or
frameworks for iterative projects is Scrum. Scrum can be a useful model
for development but requires adequate resources to use effectively. The
core plank of Scrum is to develop in iterations and have regular
follow-up meetings on progress and next tasks. If the development team
does not have good development leadership, or individual team members
cannot plan their work adequately, this strict methodology can cause
additional resource requirements and confusion for the project team
members.
The software development methodology must include
activities and processes that ensure and maintain the highest level of
security. Retrofitting security into existing solutions is more costly
to introduce, it increases the cost of ongoing maintenance, and it
increases the likelihood of vulnerabilities being introduced when
subsequent changes are made.
SharePoint solutions, in my experience, do not
often start out as business critical solutions, but they always
invariably end up as business critical. As a rule, never accept a
portal deployment or custom development into a production that cannot
show it has strived for and adheres to security best practices. This
includes ensuring your team members have the training and support to
produce code that is secure and is not vulnerable to standard attacks.
Regardless of the methodology employed, each
member should always have clear responsibilities, estimate accurately,
and report risks and issues early to the development lead and project
manager. Development teams must be able to break their work into tasks
that can be managed against a project schedule. Methodologies can help
projects move forward, as long as project members realize that
methodology is not the objective of the project, and they concentrate
on the deliverables. Unfortunately, for some projects, intense focus is
placed on following a methodology rigidly, which can be a detriment to
the project delivery and real business value.
Lastly, using a methodology provides an
industry-proven process and team structure, with clear guidelines,
responsibilities, and activities. This is highly beneficial to managing
scope, avoiding cost, and schedule overruns.
Setting Up Development Standards and Best Practices
It is vital that the SharePoint
architect, technical architect, or development lead plan document and
share a set of development team standards and best practices. As a
Microsoft Gold Partner or supplier, always attempt to understand if the
customer has existing policy documentation related to acceptable
development standards, and make sure your team adheres to these
standards.
Development standards include the following areas:
- Plan a consistent set of development environments for your development team.
- Develop a code project solution organization and management of the code project structure.
- Plan and set up your application life cycle management tools such
as Team Foundation Services (TFS). This includes configuration of the
source code control system to set up versioning (numbering), branching
policies, and any add-on packs required to support your development
methodology; for example, Scrum or Agile add-on packs.
- Plan your build process for development and integration builds on the build server.
- Configure TFS to kick off builds on the build server on check-in of
any source code. In addition, ensure developers are alerted to any
failed builds so that they can fix them as quickly as possible.
- Decide on the level of automation required for your project. For
example, mature development teams deploy nightly builds to a
snapshotted SharePoint 2013 environment and kick off a batch of tests
for developers and testers to review in the morning.
- Plan and ensure quality of source code commenting and code style
using source and style analysis tools available for Visual Studio and
TFS.
- Set out a consistent set of patterns you want developers to follow
relating to the development of common SharePoint 2013 customizations.
Consistent code patterns drive high quality and reduce your bug count.
- Think about the level of code layering you require for your
project. Do you plan to interface directly with the SharePoint object
model or abstract some of the direct interaction to the manager and
entity classes?
- Set out the types of unit tests, mocks, or coded UI tests you expect the development team to create.
- Plan up front what type of documentation is required by the
customer and the deployment team to support, deploy, and maintain any
code solutions in the production environment. This may include use
cases, use case realizations or technical specifications, component
maps, application architecture document, readme, and deployment
configuration guides.
- Set out what coding standards should be adhered to. Examples
include namespaces, exception handling (no empty try catches!), and
user interface logic. Ensure the build process performs SPDisposeCheck!
Managing, Tracking, and Recording Key Design Decisions
Each key design decision should be
tracked in a SharePoint list or Excel spreadsheet. The same applies to
key software and infrastructure design decisions. Without a formal
process, the same decision tends to get rehashed over and over again.
When a key decision is made, it must be documented. This ensures
traceability back to the original decision. When future projects occur
and people ask why the architect designed the solution in a certain
way, often the information and clear-headed reasoning is lost in the
shifting sands of foggy memory.
