# Wednesday, 18 July 2012

At a current client, there have been incidents where the running of an MTM Test manually changes the IE proxy settings, which means no more Google juice and no email – as they are running Office 365.

To check whether the proxy settings are being set – Open IE, tools, options, Connections Tab, LAN Settings, and you will see something like the shot below. Proxy is enabled, and no proxy server values.

clip_image001

This is due to the manual test settings having the ASP.NET Client Proxy for Intellitrace and Test Impact Diagnostic Adapter configured.

To change this:

Open MTM

In your current Test Plan, Go to the Plan, and select Properties, Check the test settings that you are using. The Default is to have certain data and diagnostics adapters set.

image

Either create a new Test Settings profile, or select the Local Test Run properties, and click on Open.

Go to the data and diagnostics section and make sure that the ASP.NET client proxy is cleared.

image

Click Finish

Save the Test Plan to set the default Test Settings.

Normal service should be resumed.

Technorati Tags: ,,,


.
Tags: Best Practice | MTM | VS2010

Wednesday, 18 July 2012 18:11:54 (GMT Daylight Time, UTC+01:00)  #    Comments [0]


# Tuesday, 03 July 2012

A tale of two error in the path to RC install.

I wanted to install the RC of TFS2012 to do some upgrade proving. To  keep up to date the target is Windows Server 2012, running SQL 2012, and TFS2012 on VMWare Workstation 8.0.

To keep it light to start with – no SharePoint.

So I rolled out my Windows 2012 Server Beta and got the error:

image

Digging through the logs it was failing at the .NetFX check. After a bit of thinking and checking that the latest version of .NET 4.5 was installed, it hit me that the TFS 2012 RC would not run on the Windows Server 2012 Beta.

OK. So I needed to install Windows Server 2012 RC. The Beta was not an issues, so I spun up a new VM pointing to the ISO and got the semi-infamous 0x0000005D error

image

So I Googled it with Bing, and got some hits. A great post by Pete Long here http://www.petenetlive.com/KB/Article/0000618.htm put me on the right path. Windows Server 2012 RC has a requirement for the Data Execution Prevention (aka No Execute Memory Protection) to be enabled.

To check if it is on your machine, follow the instructions here http://support.microsoft.com/kb/912923

This was drawing a blank, so I contacted the manufacturer of the laptop I use, and they pointed me to a BIOS update by Compal.

I needed a light boot from a USB flash drive, and found this page which has a light utility that will create a small footprint bootable USB http://www.biosflash.de/e/bios-boot-usb-stick.htm. Booting from that I simply ran the batch file provided from the Compal update which updated the BIOS of the machine (after a backup of the BIOS and key data for safety), and then installed Windows Server 2012.

TFS flew on, after doing the SQL install following Stuart Preston’s easy one-liner from http://stuartpreston.net/blog/2012/04/06/automated-installation-of-sql-server-2012-for-tfs-11-at-the-command-line/

Note: With VMWare workstation 8 – you must disable the VMware tools, and watch as it will try to install them, even though you have asked it not to! Cancel as soon as you see them pop up, or the VM will hang in an unknown state.

image

Now to get on and experiment with the working setup!



.
Tags: error | Simon Reindl | TFS2012 | Windows

Tuesday, 03 July 2012 19:12:50 (GMT Daylight Time, UTC+01:00)  #    Comments [0]


# Wednesday, 13 June 2012

Overview

There is a common misconception that there is no planning in Scrum. While there is nothing in the latest Scrum Guide (http://www.scrum.org/scrumguides/) specifying Release Planning, the omission is intentional. The guide is not definitive; it is the core outline of Scrum. It is more the poles of the tent than the canvas.

Release Planning is very critical for organisations in transition to a continuous delivery model (http://en.wikipedia.org/wiki/Continuous_Delivery). If you can release in to production smoothly every Sprint, the amount of work completed in a Sprint is a useful amount, there are no quality issues in production, and your business and engineering teams are working together to create well groomed independent Product Backlog Items – then you will probably not use release planning. You will release at the end of the Sprint.

If there is some issue that prevents this flow of change in to production, you will need to structure your release plan to fit with the business. This planning is necessary when you are trying to determine how much many long it will take to complete a set of features (Release by Feature), or how many features can be completed in a set time (Release by Time).

There are 2 main ways to plan a release

1. Release by Feature

2. Release by Time

Both are constrained by the engineering velocity - the number of Story Points that the engineering teams can complete within a Sprint. For this there will need to be a history of at least three sprints to give the metric. If this is the first time a specific team (if you change the people – the velocity will change) is working together you will need to estimate the team velocity. You should also be mindful of the lowest (worst case) and highest (best case) velocity. This will provide a Release forecast range.

Release by Feature

The focus in this pattern is to decide what group of PBIs has the optimal business value in a release. Once this has been determined, the velocities of the team(s) that will be working on the release are used to forecast the range of dates that the features will be complete.

Consider the Product Backlog below. The PBIs are ordered by Business Value, and the Team has worked together to groom the backlog with estimated sizes in Story points.

PBI Title

Size (Story Points)

A

5

B

3

C

2

D

8

E

3

F

5

G

3

H

2

I

5

J

8

K

13

L

8

M

13

N

13

The team has been working together for a while and has the following velocity statistics:

Lowest Velocity

13

Average Velocity

16

Highest Velocity

20

(If) All the PBIs up to N need to be completed to make the release commercially viable. There is a total of 91 story points in the Backlog.

Forecast

Estimate/Velocity

Estimated Sprints to Complete

Latest Release Forecast

91 / 13

7

Average Velocity Release Forecast

91 / 16

6 (5.7)

Highest Velocity Release Forecast

91 / 20

5 (4.5)

You can then have a predictive graph like:

image

The release will ship in 5 – 7 Sprints from the start of work, with the probability that it will ship after Sprint 6 (using the average velocity). There may need to be a further “Release Sprint” as the increment is promoted through the route to live in to production. You have to round up, as you need to use complete Sprints. It is not recommended to change a Sprint duration to accommodate a release – instead use the time to include another PBI. The team are working to 2 week sprints, so that is 12 weeks from the start of development.

Release by Time

The focus of this release pattern is to ship product increments at a regular cadence, or a specific deadline (regulatory work, peak trading period). This does not have to be fixed, as the ideal is to release to market as soon as possible. There are situations where the organisational mechanics require complex scheduling processes requiring a lot of different groups to be engaged to complete the delivery to production. There should be an action for the organisation to refine the delivery of software in to production that will reduce the size and complexity and cost of releasing code.

Consider the same backlog, using the following cadence: The organisational cadence is to release every 8 weeks, and requires a 2 week process to get code in to production. The team will then start to release after every 3 sprints, and every 4th sprint will have tasks to support the delivery in to production (the Release Sprint).

Sprint Velocity (Story Points)

Release Velocity (Story Points)

Lowest Velocity

13

39

Average Velocity

16

48

Highest Velocity

20

60

PBI Title

Size (Story Points)

Total

Release Forecast

A

5

5

 

B

3

8

 

C

2

10

 

D

8

18

 

E

3

21

 

F

5

26

 

G

3

29

 

H

2

31

 

I

5

36

Low

J

8

44

Average

K

13

57

High

L

8

65

 

M

13

78

 

N

13

91

 

So using the velocity metrics, the initial plan is that Items up to PBI I should definitely be delivered, probably PBI J, and possibly PBI K.

This is the initial plan, and will be adapted at the end of each Sprint based upon the learning, feedback and velocity. It is also highly likely that the PBIs that are to be completed will change as a response to business needs.

One of the features of a Product Backlog is that the precision reduces the further down the backlog you go. Given that the team will continuously keep grooming the backlog, the Product Backlog Items after PBI I should get decomposed in to smaller, better defined items. This will get a better granularity and understanding of what will be shipped.

In the Product Backlog grooming sessions, the Development Team, the Product Owner and the Scrum Master would collaborate to ensure that planned PBIs forecast for the release are delivering the maximum business value possible. This is where the Release Plan is adjusted.

Summary

The choice between the two release planning strategies should be determined by what provides maximum value to the business while delighting the customers. This will often be influenced by the organisational release mechanics. By working within Sprints a predicted cadence will provide less friction for the Scrum team. If there is a decision to change Release planning strategies, this can be done at Sprint boundaries, to minimise disruption.

Once a release planning strategy has been selected, it provides the Product Owner and the rest of the business a forecast of the Product Backlog Items that will be delivered in the release. The forecast will become more precise the closer it is to the release date, as the uncertainty is removed by completing work and continuous grooming of the Product Backlog.

.


Wednesday, 13 June 2012 17:23:06 (GMT Daylight Time, UTC+01:00)  #    Comments [0]