Showing posts with label TFS. Show all posts
Showing posts with label TFS. Show all posts

Monday 27 April 2020

Azure DevOps/TFS Basics


Overview:  There is a lot you can do with Azure DevOps to monitor your projects.  A couple of simple charts can be used to motivate (or demotivate) your team.  Start simple and build...









Wednesday 28 March 2018

TFS Scrum for SharePoint Projects

Great information on TFS for Scrum, Agile & CMMI from Microsoft.  My preference is to use Scrum with a couple of twists from Agile and external tooling.
https://docs.microsoft.com/en-us/vsts/work/work-items/guidance/choose-process

Tip:  I use User Stories extensively in SCRUM and with TFS all the testing and automation fits in brilliantly.  CI/CD is a choice between TFS build and TeamCity.  Also, my acceptance criteria are always written using gherkin language to ensure consistency.

Below are a few posts that are a couple of years old outlining Agile and Scrum for SharePoint projects:
Agile for SharePoint
Scrum for SharePoint - Part 1
Scrum for SharePoint - Part 2
Scrum - Part 3 - Scaling Scrum

Tuesday 23 January 2018

Basic Branching Strategy for TFS and GIT



  • The main difference between standard TFS branching strategy is that you branch more often for shorter time periods and check in small code change units into the "Development" branch.
  • Delete the black line once the feature is complete and checked back into the Development branch.  Can easily start a new functional local GIT branch to amend the next feature.
Note: Easy to also grab a GIT local branch from the Main branch (inline with you production code base), make changes and then when checked back in they hot-fix goes into both the Main and Development code branches.

Choosing the branching strategy is normally: Release, patch or feature driven.

Visual Studio 2019, Commit code to GIT repository

Wednesday 30 October 2013

Issues Generating wsp's using MSBuild in TFS2012

Problem: I am using a Build Definition within TFS2012 to try create a WSP package.  I am building a solution that contains multiple projects.  1 project needs to generate the wsp from it.  I have made minor customisations such as:
My Custom Build Definition
My environment is TFS 2012, VS2012 & SharEPoint 2013.

 Tip:  To clone Build Definitions you need to add the VSIX "Team Foundation Server PowerShell Tools 2012".

When I run the build I get the following error:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets (387): The "ValidatePackage" task failed unexpectedly.System.InvalidOperationException: The project service does not contain the specified project: 17939c4e-xxec-xxxx-xxxx-e18209d495db. at Microsoft.VisualStudio.SharePoint.Tasks.ValidatePackage.OnCheckParameters() at Microsoft.VisualStudio.SharePoint.Tasks.BuildTask.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() at Microsoft.Build.BackEnd.TaskBuilder.d__20.MoveNext()
Exception Message: MSBuild error 1 has ended this build. You can find more specific information about the cause of this error in above messages. (type BuildProcessTerminateException)Exception Stack Trace: at System.Activities.Statements.Throw.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocal


Resolution:
Install Microsoft Office Developer Tools for Visual Studio 2012 - RTM on the build controller (In my case I have TFS and I have a seperate Build Controller on my CI box so I install MS Developer Tools for VS 2012 - RTM on the CI box.

More Info:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/dc6e39e6-331d-42b2-ac16-b530ccb74d46/tfs-build-and-creating-a-sharepoint-2013-app-file



Tip: Another Point Worth Noting is the build definition can have problems if files names/locations are tool long created by the build controller.
   Tip: When setting up Visual Studio, shorten the length/location where the project/workspace is held locally as shopwn below:
 
 

Generating WSP's in CI for SP2013

There are some comprehensive blog posts on setting up Build automation.  This post is a short summary of creating SharePoint wsp files from a Visual Studio 2012 solution within TFS2012.

Prep Steps:
  1. TFS2012 containing source files.
  2. Need a build controller and a build agent, this can be on the TFS server or a separate server, in my case it is separated out.
  3. On the Server holding the build controller, you need the SP binaries.
  4. Install "Microsoft Office Developer Tools for Visual Studio 2012 - RTM"
  5. Create a new template or clone the default template and adjust it as shown below (You will need the VS extension (VSIX) "Team Foundation Server PowerShell Tools 2012" to clone an existing Build Template):
 
Add the Packaging switch under the advanced Tab in the Process tab

More Info:
http://msdn.microsoft.com/en-us/library/ff622991.aspx

Friday 7 June 2013

Why I like VS/TFS 2012 no I mean VS/TFS 2013


Visual Studio (VS) 2013 and Team Foundation Server (TFS) 2013 is being released in the next few weeks - that was quick.  I'm just getting comfortable with VS 2012 and the announcement comes that VS 2013 is being released later this month.

http://blogs.msdn.com/b/bharry/archive/2013/06/03/visual-studio-2013.aspx

So, this is going to be a blog on VS 2012 with TFS, my number 1 favourite new feature in VS 2012 is local workspaces.  Pre VS2012 all workspaces were Server based workspaces.  "Local" workspaces differ in that when you go offline you have version control on your local machine.  You can rollback/compare to an old version.  So for me and my laptop on client sites I find it a big improvement.  Very simply this is how GitHub works (from my extremely limited knowledge of GitHub).  You have local version control and this is synced up with the central source control repository.

Another feature worth looking at will be Release Management.  I am working with TeamCity to build my Infrastructure (PowerCli for VMware and Powershell to build SQL Server.  Autoinstaller runs the SP part).
TFS 2012 - Scrum template home page

Team Rooms are already on TFSPreview, seems like a nice idea - not sure how the takeup will be from devs.

Sunday 7 April 2013

Agile Software development for SharePoint


Overview

SharePoint 2013 brings new software development challenges to organizations.  Anyone architecting solutions involving SharePoint is faced with more critical decision points than ever before.  Traditional approaches to requirement gathering used on SharePoint projects, often include a long winded structure analysis phase.  It is expensive and difficult to get the relevant analysis clarified and Agile offers a different approach to working out what you are trying to achieve. 

The familiar IT Project Management Triangle gives one a clear visual representation of the constraints facing projects.  By using Agile management of projects can remove beaurocrartic redundant steps and focus on delivering what the customer is looking for.  This post provides an overview of using Agile methodologies such as SCRUM to help alleviate some of the problems we face when working with SharePoint 2013 development projects.


IT Project Management Triangle.
I am looking at SCRUM and Agile practices from a practical SharePoint delivery perspective.  SCRUM, like all methodologies, has it’s time and place.  SharePoint 2013 has many visual quick win so it is easy to get visual ideas in front of the end client very quickly in an iterative approach.

Supplementing project management with Agile practices and techniques to move a project towards successful delivery should overrule any historic dogmatic approaches.  

Methodologies

For simplicity, I break down the various software development methodologies into two main camps:

• The traditional approach that the Systems Development Life Cycle (SDLC) falls under and
• Agile Methodologies (SCRUM being the most common framework of Agile, other frameworks include Agile Kanban, Extreme Programming). 

SharePoint projects are all too often run using traditional approach that can result in “analysis paralysis”.

Agile methodology is implemented normally using an Agile Framework such as SCRUM which is by far the most popular framework.  As with anything, context is all-important.  The approach and techniques need to make sense to your organization and the project.  A good technical lead or Solutions Architect picks and borrows specific parts of different framework or methodologies when providing SharePoint solutions in order to give the best return for effort. 

Agile Manifesto, know the four values and 12 principles. 

4 Values:

  1. individuals and interactions over processes and tools;
  2. working software over comprehensive documentation;
  3. customer collaboration over contract negotiation; and
  4. responding to change over following a plan.

12 Principles:

  1. Satisfying customers through early and continuous delivery of valuable work.
  2. Breaking big work down into smaller tasks that can be completed quickly.
  3. Recognizing that the best work emerges from self-organized teams.
  4. Providing motivated individuals with the environment and support they need and trusting them to get the job done.
  5. Creating processes that promote sustainable efforts.
  6. Maintaining a constant pace for completed work.
  7. Welcoming changing requirements, even late in a project.
  8. Assembling the project team and business owners on a daily basis throughout the project.
  9. Having the team reflect at regular intervals on how to become more effective, then tuning and adjusting behavior accordingly.
  10. Measuring progress by the amount of completed work.
  11. Continually seeking excellence.
  12. Harnessing change for a competitive advantage.


SCRUM however, is gaining momentum as the defacto project management framework and should be a tool in your arsenal for SharePoint development.  Agile principles tend to skip some of the more formalized phases of SDLC and I am not suggesting that planning is superfluous; the trick for the technical development team is do not let process get in the way of building your product.

Experience has shown it is likely that you will face significant challenges in trying to implement SCRUM.  The team stakeholders may resist, your organization may resist, and the techniques may not be appropriate.  A simple and practical tip for overcoming these challenges is to try to find someone that can work you through the SCRUM process on suitable projects.  By bringing Agile practices to SharePoint development projects you can aim to reduce time, deliver what the client really needs and make software development more rewarding.  You don’t need to use every facet of a methodology, start with the easier options that will immediately add value.  As your SCRUM team maturity evolves add more pieces. 

Tip:  Microsoft Team Foundation Server (TFS) 2012 has 3 project management templates, one of which is the SCRUM template and this is a good place to start with minimal project management overhead.  The nice thing about TFS 2012 is you can easily amend these templates to suit your needs as your experience grows. 

Traditional approaches such as the SDLC often have a lengthy requirements gathering phase.  This long winded analysis phase is often ingrained into IT folks psyche that people find hard to break away from.  Projects involving a lengthy requirement gathering phase can easily suffer from excessive documentation if there is poor governance.  This documentation can be erroneous, contradictory, outdated, incomplete, challenging to follow and result in documentation overload. 
As a metaphor, SharePoint analysis is like the children’s game “Chinese whispers” or “Telephone” where one person whispers a message to another person, which is passed through a succession of people until the last player announces the message to the entire group.  This lost-in-translation is all too common as excessive noise in documentation or the analysts gloss over the expert’s main point.  Whereas a developer performing analysis generally picks up when something needs detailed explanation as they are “solutioning” the project as they directly communicate with the expert.
The more people in the chain, the more potential for errors in the relayed messages. Moreover, these business processes are often extremely complex, so that the actual intended meaning of the relayed message is lost.  SharePoint is a complex platform and even on the biggest of projects, the success of the technical delivery will often come down to a few key individuals.  Increasing team sizes does not often help and after a certain size becomes a real hindrance.  Agile teams work best when they are relatively small (SCRUM recommends team between 5-9 team members).  If the project is too big, get better quality people; don’t make the commonplace management mistake of adding more resources blindly.

Not all projects or SharePoint teams are ready to work within Agile methods however current commonplace SDLC approaches have problems we hear about repetitively such as change to software cost money and the SDLC is extremely inflexible, Agile based projects lend themself to change. 

Another argument is that that traditional methodologies can be used to give you fixed price quotes.  Vendors operating on a fixed price basis tend to promise the world and try cut every corner to deliver on time (and I hear the vendors screaming already “that is how the other vendors work not us”). 

Nevertheless, many of us realize that software consultancies operate work on the simple maxim ‘sell high, ship quickly’.  Once a software consultancy is in, the inevitable changes that will need to be made will cost the earth.  SCRUM can also run away but with the demonstrable iterations it quick to identify when you are off track and remedy the situation.  Agile methodologies use a time and material model whereas most financial budget decision makers prefer a fixed price (despite this being almost always wrong and they don’t seem to learn).     

Internal software teams often run over in time, deliver the wrong product and buggy solutions due to promises made based on poor initial guestimates.  SDLC can work if managed properly, Agile allows for better feedback controls to verify you are going in the right direction.

SharePoint projects often lend themselves to a ‘time-and-materials’ model as opposed to the ‘fixed-cost’ approach.  If you are unhappy with a project’s development, remove the vendor without the full budget being used up before discovering this project will be successful.  With SCRUM the team have to show you the deliverable product at the end of each sprint (2-4 week delivery phase) and replacing a team members is possible between sprints.

ALM for SharePoint 2013

SharePoint’s developer tooling has matured throughout the iteration of SharePoint.  Tooling is primarily based on Visual Studio and TFS.  ALM covers many roles with the team including project managers, testers, architects and stakeholders.  In this section I mainly focus on ALM for the developer.  Third-party tools assist with building the solution, communication within the team and technical guidance that easily plug into TFS and VS.  An example is CKSDev for Visual Studio.

Tip:  Visual Studio 2012 and TFS 2012 have a large number of purposes.  Always start with the basics of ALM and continue adding the more sophisticated features as your ALM maturity increases.   Source control is definitely the first important feature of TFS.  The next step would be bug tracking.  Build automation is about when you know you are really starting to get going properly with ALM.  With builds your developer isolate code is now integrated into the solution allowing verification of that the individually developed parts fit together.

TFS 2012 comes in 2 on-prem. varieties, don’t bother with the express edition.  It is free but limited to 5 users, if you are this small rather get a hosted TFS 2012 solution or use TFS preview.  TFS has an excellent web user interface portal, which is user friendly for team members that don’t necessarily use Visual Studio to enter Product Backlog Items (PBI’s).  TFS contains the following key components: source control, work items (PBI’s, tasks and bug tracking in SCRUM terminology), build automation and reporting. 

Visual Studio 2012 comes in 4 flavours as a developer you can use the Ultimate, Premium or Professional edition.  Depending on your MSDN subscription use the most feature rich edition you have available.  There is also a Test edition version of Visual Studio 2012 that is not suitable for development.

A good opinion on development machines is that each developer must have a completely standalone environment hosted on visualized PC/laptop infrastructure.  VMware workstation is a good option to provide this virtualized environment to developers.  The chapter in this book on DTAP and automation strongly examines setting up the SharePoint developers’ development environment.  Using automation builds are triggered by developers or are schedules using FSP policy, these builds can include smoke test or full testing scenario allowing for high levels of confidence in that the build work correctly.

Microsoft tooling for SharePoint is good and wide ranging.  Starting with Visual Studio 2012 there are item templates for achieving common tasks.  The community writes many Visual Studio Extensions such as CKSDev.  Consider adding this to the developer machine base builds so when the image is rebuild or the images are distributed the developers are up and running quickly.
Code needs to be in a source code repository such as TFS 2012, using the SCRUM template is the good option.  At the most basic level it allows for easy management of the project using the SCRUM template with the appropriate reports with a source code repository and bug tracking facility.
Assembling all the constituent parts of your SharePoint project using the build functionality available through TFS allows you to have confidence that it all works together and can be deployed into production accurately. 

Build tab within the SCRUM template.
 Build process templates are used for automating the build in TFS.  The figure below shows the default templates.

Built in Build Process Templates
Daily automated builds are a good idea to ensure code is working against your automated tests.

Tip: Don't build your daily automated SharePoint 2013 environment from scratch. Rather use snapshots or cloned images for the base images and merely deploy and test your code through automation.  Chris O’Brien has good information on Continuous Integration for SharePoint check out his blog. 

PowerShell is your friend.  Automate everything in the build.  This allows team members to get the latest code and setup the appropriate databases quickly - the invested time pays for itself almost immediately.  The developers will often use a baseline content database so they know that they have the correct test data.

ALM allows for easy migration onto your Development, Testing, Acceptance and Production (DTAP) environments.  Automated of deployment pieces bring efficient delivery through to the production environment.  I can't stress enough that you need more environments than development and production.  Even the smallest project should have at least three separate environments and remember to keep the production and staging (also referred to as pre-production or acceptance testing) in sync.

Summary

SCRUM is a commonly used Agile framework for delivering projects.  SCRUM lends itself well to a lot of SharePoint projects as it allows for focused collaboration.  Product feedback is on-going and the team demonstrates the project sprints in multiple short iterations to the business which ensures the projects direction is focused.  SharePoint 2013 is a complex product and having smaller teams with superior resources can greatly improve returns. Agile does not mean no documentation, it advocates using a bottom-up self-managing team that is organized.  Agile is not anarchy but allows us to focus on business problems creatively utilizing all team members aiming to work together to manoeuvre SharePoint to meet business needs.  Agile and SCRUM try move away from overdrawn project analysis phases.

Microsoft has a 1st class stack of ALM tools for SCRUM comprising of Visual Studio 2012 and TFS2012 that hook nicely into SharePoint 2013 development projects.  TFS is not just for developers, it can be used by the whole team.  TFS has source control for your code as well as a plethora of features to help your SCRUM based projects such as the SCRUM template, reporting/ project management, requirements and acceptance gathering artifacts, the ability to automate your solution via the build process templates and testing.

Agile for SharePoint (This post)
Scrum for SharePoint - Part 1
Scrum for SharePoint - Part 2
Scrum - Part 3 - Scaling Scrum
Scrum - Part 4 - Kanban and Scrum
Scrum - Part 5 - Certification PSM 1

Monday 10 September 2012

Scrum for SharePoint - Part 2

See Part 1

Technology: I am using Team Foundation Server 2012 Release Candidate.  I believe the best tools for the scrum team are offered through Visual Studio. VS 2012 has all the features and VS2010 can't do specific tasks such as create projects however I've found using VS2010 to work well.  The template used in TFS is the Visual Studio Scrum 2.0 template.   Also see http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DEV212

Ways to work for TFS:  VS has the most comprehensive feature set for working with TFS 2012.  You can also use the TFS web UI, the SharePoint Foundation UI that is hooked up to TFS or excel and then import the data.


Creating PBI's: The screen shots use TFS2012 RC & VS2010.  I have annotated the screenshot to help with input of PBI's.  Not the priority is set from 1-1000 (default is 1000 which is the lowest priority).  I like to use Mike Cohan's planning poker (uses a relative Fibonacci sequence number to assign relative effort weight).  The scrum team vote on estimated effort after an understanding of the user story is complete.  Optional. Free tool to use for planning poker   Try this, a friend of mine built this while playing around for Scrum Poker Planning. 

The scrum master has to accept the PBI and for me to do this I need 3 pieces of information namely: the user story, acceptance criteria & additional detail short clear information such as an annotated Balsamiq mock-up.  Obviously the product owner  may negate the need for additional information but often they need to get this information from someone else in the business and I find mock-ups invaluable for clarifying to all people visual requirements.  Lastly, ensure that the team understand INVEST principles for  (Independent, Negotiable, Valuable, Estimat-able, Small, and Testable) for each User Story/Requirement.

Acceptance criteria is needed for each PBI.  This would be good to have in the Sprint planning meetings.  This is the format I recommend (gherkin language).
Scenario:
  Given
  When
  Then

An example I have is
Scenario: Employee requests leave
  Given an employee has sufficient leave available in the year
  When the employee schedules leave (holiday)
  Then the employee is informed his request is valid and his manager is informed of the request.

Acceptance Criteria – “What is Acceptance Criteria? Put simply, it's the criteria that defines what "Done" means for each PBI. Acceptance Criteria is critical to the success of a Scrum team, as it becomes the handshake between the Product Owner and the team -- it helps define what the team is committing to.”  http://www.nomad8.com/files/acceptance_criteria.php
"Pre-established standards or requirements a product or project must meet" Google's definition of acceptance criteria.
Normally acceptance criteria focuses on functional user stories but you also need to cover NFR's such as performance.  Negative acceptance criteria is often overlooked when creating AC's and do the AC's before development starts, you can always change them later.
An alternative to Gherkin for writing the acceptance criteria is to use checklists to ensure the User Story does what the business stakeholder wants and the developer has developed it correctly.

(Story Board)

The TFS 2012 Scrum template provides a good overview of the current sprint.  Team favorites are dropped from TFS queries to provide useful insights into the project.


Key Meetings:

1. Daily Stand-up (max 15 minutes):  I like to perform these at about 10:00 every day in the morning.  Each person tells the group: done/achieved in the past 24 hrs, what they are doing in the next 24 hours and brings up any blockers/obstacles/impediments.  I like to take notes as the scrum master and as the team falls into place.  I let team members run the daily stand-up scrum meeting in random turns once we all know how to do them and it seems to work well with communications in the team and I take summarized notes and I use the format:  Date, Time, Attendees, Each attendee summary & general meeting notes:  e.g. Adam and Paul were late for the meeting, blockers were not recorded, Kanban board was not updated....
Rules: Start at 10:00, be concise (part items that are taking to long and get the people to talk after the meeting), all participants to stick to the format: last day, today and blockers.  It always ends at 10:15 and leave the area.  Listen to the appoint meeting scrum master and they need to stop ongoing discussions.

2. Demo Meetings:  Date, time, attendees & roles, problems & suggestions.  Do at the end of sprint, tend to be 30 minutes to 90 minutes per demo each sprint. 

3. Sprint Review Meeting: Done at the end of a sprint cycle after the sprint is over.  Ensure each PBI is reviewed.  Often used with demos to validate each PBI and this allows the Product Owner to evaluate the PBI's fulfillment and make changes if necessary.  Important but can be skipped by the whole team as long as the PO does it and is happy.

4. Sprint Retrospective Meeting: Optional meeting to identify improvements that can be made.  I use this meeting after the Sprint Review at the end of the 1st 2 or 3 sprints and then only periodically as the project progresses.  Tip: Use the format: Glad, sad, bad game.  https://app.scatterspoke.com for managing Retrospectives.  An alternative is to the approach: What went well, What didn't and What needs to happen.


I've seen many different formats for running retrospectives, and a good default option for me is "mad, glad, sad". I also like the Danish baking Retrospective that I saw recently.  
Azure Devops Danish Baking Retrospective Board

A nice feature I was shown recently was to "Include a Team Assessment".  I'd use it every 3-4 sprints assuming we are using 2 week sprints, the results are a great indicator of confidence and the teams position.
Team Assessment in DevOps Retro board 

5. Sprint Planning Meeting:  Have a sprint goal.  Done at the start of the sprint cycle.  The scrum team and the product owner identify items from the product backlog to go into the sprint.  The last part of the meeting is to create a sprint backlog to implement each item selected from the product backlog.  I also like to have a grooming of stories in the previous sprint to ensure the whole team know what is likely to come along and tech can feedback to the PO/stakeholders.

Agile for SharePoint
Scrum for SharePoint - Part 1
Scrum for SharePoint - Part 2 (This Post)
Scrum - Part 3 - Scaling Scrum
Scrum - Part 4 - Kanban and Scrum
Scrum - Part 5 - Certification PSM 1

Sunday 1 July 2012

Scrum for SharePoint - Part 1 Introduction

Overview: Scrum is an Agile methodology that is useful for SharePoint projects as it allows for discovery/refinements of requirements as opposed to formally knowing all the functional requirements of a system upfront.  Each project lends itself to specific methodologies however, an Agile approach is often more suitable for SharePoint projects.  For larger, more formal projects I like MSF but traditional SDLC methodology run projects also work well.  Scrum is one Agile methodology and probably the most commonly used.  As with all projects I recommend following a methodology but lend from other and take out what isn't working to get the optimal process.

Scrum for Dummies:  Scrum consists of 3 types of team roles: the product owner/s, scrum master and the rest are team members.  Tam sizes should be less than 7-8 people (if bigger use scrum of scrums).
1.) The Product Owner is responsible for creating user stories.  These are specified in the form: As the <role> , I want to <feature> so that <benefit>.
2.) From the User stories I create Product Backlog Items (PBI's), Scrum is broken up into sprints (usually 2-4 weeks).  The sprint kicks off with a Sprint planning meeting that involves the entire team.  PBI's are broken down into tasks, tests and bugs.  During the sprint planning, the team members commit (renamed to forecasting in 2016) to the PBI's in the sprint and creates a "Sprint Goal".  I usually set apart 3-4 hrs to complete the Sprint Planning session at the start of each sprint.
3.) Daily scrum meeting takes 15 minutes facilitated by the scrum master.  Each team member states what they accomplished in the last day, what they will be working on in the next day and any blockers.  When the team members start a discussion, shelve it and they can have a separate meeting outside the scrum to avoid over running on the scrum meeting.  Do scrum meetings standing it helps make the sprint/team finish on time.
4.) At the end of each sprint, there must be a potential deployment.  Hold a scrum retrospective, this is to work out the team velocity (are the PBI's and features being achieved) and work out how productivity can be improved.
5.) Documentation:  Scrum is not document intensive but aims to get features right not finish at a specific point.  The documents generated by scrum are:
5.1) User Stories and corresponding Acceptance Criteria
5.2) Meetings (Daily scrum minutes/decisions, sprint planning agreements/outcomes & retrospective minutes)
5.3) Whiteboards (architecture diagrams and user story refinement)
5.4) TFS recorded data 
5.5) Communications (emails about decisions, supporting information, this could also include pptx from presentations, user reviews).

TFS:
  • SharePoint has a lot out of the box and using Scrum allows for better technical decisions whereby team members often identify OOTB solutions which hopefully eradicates the common developer mentality of using .NET to do existing SP functionality.
  • There are Templates for Scrum download and base your project off them.
  • Microsoft offer a great free services called TFSPreview (http://www.tfspreview.com/) which is a SaaS offering TFS 2010, doesn't have all the features but it is amazing and best of all it has a built in Scrum template so I'd always start with this and if you feel you are being to restricted you can always go for a on premises option. VSTS (cloud service) is the current name for TFS preview Oct 2017.

Agile for SharePoint
Scrum for SharePoint - Part 1 (This post)
Scrum for SharePoint - Part 2
Scrum - Part 3 - Scaling Scrum
Scrum - Part 4 - Kanban and Scrum
Scrum - Part 5 - Certification PSM 1

Saturday 31 July 2010

Best Practice Sharepoint 2010 coding tips

1.> SharePoint Dispose Checker Tool - Run the SP Dispose Checker Tool on all custom code you write.
SPSite & SPWeb object has a big load and we need to ensure dispose is always called. 2 easiest ways to ensure Site and web objects are always disposed are shown below:
SPSite site;
try
{
site = new SPSite("http://demo1"); // Create the SPSite object
...
}
finally
{
if (site != null) // Check if the SPSite object exists
{
site.Dispose(); // Clean up the SPSite object as it has not be disposed of
}
}

Alternatively I prefer to use using statements
using (SPSite site = new SPSite(http://demo1/))
{

.... // SPSite.Dispose method will be called always
}
Run the SPDisposeCheck tool on all code before deploying outside of you development environment, this can be automated into VS 2010.
2.> Have at least 3 environments i.e. don't send code from the developers machine straight into production. Sandboxed solutions alleviates this risk to some degree but use a UAT, pre-prod, QA environment. Your deployment environment must mimic production as closely as possible i.e. ensure there is a separate SQL DB, all versions of software are identical, load balancing is setup. Have documented change control. Try perform changes through scripts not manual changes if possible. Web.config changes need to be replicated to all servers on the farm so doing the change manually is not the best option. Change the web.config via code to ensure it is done through the configuration database so they are changed on all web.config's in the farm.
3.> Error handling, catch errors as specifically as possible, die gracefully and appropriately, log the errors, check the production error logs periodically.
4.> Deploy code using wsp solutions. Ensure code is not in debug mode when compiled, it runs slower and potentially can crash/holdup your production environment. Implement CAS, deploy to bins if possible and apply CAS security policies to custom coding. Perform peer code reviews, it ensures coding standards are being followed, developers learn from each other, bugs are often picked up pre-testing and it increases team members knowledge that reduces maintenance costs.
5.> Develop using source control no matter how smal the dev project is. Preferably TFS 2010 but VSS 2005 is even fine, failing this use CVS, IMB/rationals ClearCase for source control. Also have bug tracking with TFS the integration is excellent between the bugs and the source control. I.e. use TFS if possible.
6.> SharePoint projects are often very good candidates to SCRUM or other agile methodologies. Use them if it's appropriate. Traditional formal SDLC / waterfall approaches tend to work well on the larger SharePoint projects.
7.> Use the developer dashboard.
8.> Unit testing - don't test SharePoints API, test your custom code. In MOSS Type Mock isolator was a great product for SharePoint I presume this is still the way to go. Andrew Woodward is a good blogger on SP unit testing.