If you are a ReSharper user (and you should be), check out the new dependency graph. It is awesome for easily getting a high level view of the dependencies between projects and layers in your solution.
Figure: ReSharper 8 introduces a dependency graph to its architecture tools.
Figure: I structure my solution to reflect the Onion Architecture. http://rules.ssw.com.au/SoftwareDevelopment/RulesToBetterMVC/Pages/The-layers-of-the-onion-architecture.aspx
I have layers for UI, Business Logic Interfaces, Repository Interfaces and the Domain Model. I then inject my dependencies into these layers.
I like to structure the dependencies under a different solution folder so as to emphasise that the dependencies exist outside of the application core.
Figure: R# now generates a dependency graph of your solution (or a selected part of your solution) and by default groups the projects by Solution folders.
I love this because with a few clicks I can get a very clear idea of the dependencies between the different layers in my solution, and see where references exist to dependency projects.
I unselected three items to remove noise from the diagram: the Solution Items folder (which contains the deployment project and documentation), the Common folder (which contains cross-cutting concerns) and the Dependency Resolver project which configures the IOC container.
Figure: I generated the ReSharper dependency diagram as preparation for the first Sprint Review meeting and immediately noticed a dependency from my Client (UI) layer to a ‘Dependency’ project.
No No No No No !!!
Figure: We refactored to inject the dependency into the application core and removed the reference to Data.FileStream from the UI Project.
The dependency graph now looks awesome ! There are no lines from the Clients window to the Dependencies window!
Figure: As a comparison, this is how the Visual Studio Dependency Graph looks when first created. I would usually then remove the outlined items to remove noise.
Figure: After removing the extra projects, my Visual Studio Dependency Graph is more readable, but I would love to see the ability to group projects by Solution Folder.
Figure: The Visual Studio architecture tools are more complete and advanced than the ReSharper ones at present and the Layer Diagram is an invaluable tool that allows you to specify all the layers of your solution, assign projects and classes to particular layers and then have the architecture validated when you build.
What I love about the ReSharper dependency graph is how easy it makes it to get a high level overview of my solution.
It also has the ability to track changes to your architecture as your project progresses, and to indicate metrics. I’ll let you know how these features work out for me as the project progresses.
The originators of Scrum, Ken Schwaber and Jeff Sutherland have released an updated version of the Scrum Guide.
Go here to get the latest version
Go here for their summary of the changes
Go here for a 17 min video of them discussing the changes.
Here are my key points taken from the video, and the summary page, and a few comments about them.
Interesting points on the uptake of Scrum
– two years ago the US Congress passed a law that all Department of Defence IT Projects must be agile
– this year.. the US embedded the Agile Manifesto in its government regulations
– The US post office has mandated Scrum everywhere in IT
– The Gartner group says ‘abandon waterfall.. get agile’
-Jim Johnson at the Stannis group repots: In a survey of 50-100,000 projects where success is defined as on time, on budget with happy customers (in itself a waterfall benchmark) –
The success rate in waterfall projects is 14%
The success in agile is 42% (Jeff believes this is not great.. but a conservative figure)
– The Forster report: next year there will be 3 trillion dollars spent on software
Ken: “our way of trying to narrow the gap between software that is needed and the available provisioning capacity is
– higher productivity
– higher value
– higher quality”
The 6 key changes to the 2013 Scrum Guide
1. Re-emphasising Transparency
A new section on Artefact Transparency has been added.
The key point made was that Ken and Jeff wanted to make it clear that if things are not visible to everyone, bad decisions can be made.
All of the Scrum artefacts should be transparent, and easily understood by everyone who is looking at them in order to maximise value and minimise risk.
2. Sprint Planning – One Section and a Sprint Goal
The sprint planning meeting is no longer divided into two sections.
The concept of the Sprint Goal was in the 2011 scrum guide, but it wasn’t clear enough and not enforced enough.
In the current edition, you must come out of sprint planning with a sprint goal.
The sprint goal should provide focus to the team.
3. Product Backlog – being ‘Ready’
The term ‘Grooming’ has been replaced with the term ‘Refinement’ (due to cultural sensitivity).
The ‘Ready’ state is being emphasised (as has previously been done with the ‘Done’ state)
Items that are ‘Ready’ are defined clearly enough and with enough detail to be able to be added to a sprint.
BEFORE the sprint planning meeting, PBIs that may be added to the sprint should be refined until they are ‘Ready’. This will accelerate the sprint planning meeting.
I think this is awesome. As a consultant, one of the issues I commonly find on Scrum teams is that the Sprint Planning meeting drags.
I always push back on Product Owners that if they want punchy Sprint Planning meetings, they should prioritise having a well groomed backlog with all of the BPIs likely to be included in the next sprint ready for estimation and inclusion.
4. Time Boxed Events
When you set the length of the sprint it does not change, but the meeting times specified are maximums.
(I don’t see this as a big change).
5. Daily Scrum – a Planning Event
The new guide reinforces the importance of the Daily Scrum as a PLANNING event, not just a status event.
It provides a great focus on each team member contributing and delivering value.
Ken: ‘It is about creating situations for the team to work together’
Every day the team should organise how they will work together to accomplish the sprint goal
The input to the meeting is how well the team is going.
The output from the meeting is a new or revised plan that optimises the teams efforts.
The three questions have been reformulated to emphasise the team over the individual.
a. What did I do yesterday that helped the Dev Team meet the Sprint Goal?
b. What will I do today to help the Dev Team meet the Sprint Goal?
c. Do I see any impediment that prevents me or the Dev Team from meeting the Sprint Goal ?
There is a greater focus on the sprint goal, rather than just on the status of what ‘I’ did.
Only tasks that contribute to the sprint goal are relevant.
A great example is given
– if a team member says ‘I spent the day writing this great report’ but the report does not contribute to the sprint goal
a. it should not have been included in the daily scrum (as it does not contribute to the sprint goal)
b. if they team member was busy, but did not contribute to the sprint goal, as far as the daily scrum is concerned… they did nothing
c. it could actually be considered an impediment as the team member is not focused on the sprint goal
6. Delivering Value
The concept of value is reinforced.
The product backlog should be prioritised by value.
At the end of the sprint review, one of the primary outputs should be a refined sprint backlog that will optimise the VALUE of the work the team is doing.
During the sprint review – the question is asked ‘based on what was done in the sprint what are the next things that could be done to optimise value ?’
The point is to maximise the value that the team delivers.
I say: Bravo !
Great quote: “We’ve got goals, we’ve got value, we’ve got transparency, we’ve got more teamwork ..it’s all good.”
The default Agile TFS template ships with three states: New, Active and Closed.
A common question that I am asked is how to add an extra stage to the TFS taskboard.
While this is not trivial in TFS 2012, it’s really not that hard once you know how, and is being made easier in newer versions of TFS.
Figure: We will demonstrate adding a ‘Testing’ column.
Step 1: Ensure that you are an administrator of the Team Project you are updating
Step 2: Download the Team Foundation Server 2012 Power Tools
– In Visual Studio select Tools, and then Extensions and Updates
Figure: Select Online from the left menu, enter Team Foundation 2012 in the search field, click the Download button on Microsoft Visual Studio Team Foundation Server 2012 Power Tools
Step 3: Export the Task Work Item Type
To add a new column to the task board, we need to add that status to the work item type definition.
Figure: From the Tools menu select, Process Editor, then Work Item Types and then Open WIT from Server
Figure: Expand the correct Team Project and select the Task work item type.
Step 4: Add the Testing state to the Task WIT
Figure: Select the Workflow tab. Open the toolbox and drag a State component onto the design surface. Right click on the new State, select Properties and set the Name property to Testing
Figure: Select the Transition Link component from the toolbox. Now click on the Active state and drag your mouse to the Testing state.
Figure: A transition will have been added from Active to Testing.
Figure: Right click on the Transition and choose Open Details. Go to the Reasons tab and Edit the reason value. Suggested test: ‘Ready for Testing’. You can click on the chevrons to expand the transition to be able to more clearly see the assigned properties.
Additional actions and Fields can also be specified but that is beyond the scope of this post.
Figure: Repeat the process above to add transitions from Testing to Complete (with a reason of ‘Testing Complete’) and from Testing back to Active (with a reason of ‘Failed Testing’).
Figure: Save the template to a known location on your hard drive so that it can be imported in the next step. E.g. c:\Temp\TeamProjectName_Task.wit
Step 5: Import the saved WIT
Figure: From the Tools menu select Process Editor, then Work Item Types and then Import WIT.
Figure: Browse to the location of the saved file, select the Team Project you wish to import the WIT into and click OK.
Figure: When you edit a task, the Testing status is now available. It is not yet however added to the board.
Step 6: Export the Process Template Config
This is the part that I always forget to do. After you have edited the Work Item Type, you still need to update the process template to include the State on the Task Board.
Figure: Open a command prompt, change to the Visual Studio IDE Folder and execute the following command
witadmin exportcommonprocessconfig /collection:CollectionURL /p:ProjectName /f:”DirectoryPath\CommonConfiguration.xml”
for our instance the command required was
witadmin exportcommonprocessconfig /collection:http://ourserver:8080/tfs/CollectionName /p:ProjectSparrow /f:”c:\Temp\CommonConfiguration.xml”
Step 7: Edit the Process Template Config
Figure: Edit the exported file. Find the section for TaskWorkItems and add the line highlighted above.
<State type=”InProgress” value=”Testing” />
Save the file.
Step 8: Import the Process Template Config
Figure: Execute the following command
witadmin importcommonprocessconfig /collection:CollectionURL /p:ProjectName /f:”DirectoryPath\CommonConfiguration.xml”
for our instance the command required was
witadmin importcommonprocessconfig /collection:http://ourserver:8080/tfs/CollectionName /p:ProjectSparrow /f:”c:\Temp\CommonConfiguration.xml”
Figure: View your task board and you will have your new column!