Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a How to be a good TFS Master
Semelhante a How to be a good TFS Master (20)
Mais de damovisa
Último
Último (20)
How to be a good TFS Master
- 1. How to be a good TFS Master (using a sprinkle of Scrum of course) Damian Brady http://www.damianbrady.com.au Twitter: @damovisa | #qalmug Delivering Awesome Web Applications
- 2. Agenda What is a TFS Master? Why TFS? More Pain for Better Results Scrum with TFS User Stories and the Backlog
- 3. What is a TFS Master? ? Ensure your team gets the most out of TFS http://brdy.in/sswtfsmaster
- 4. Why TFS? ? TFS is much more than just source control
- 5. Why TFS? 0% 100% Source control Continuous Build Lab Management Backlog Continuous Deployment
- 6. TFS for Source Control #1 reason to use TFS? Annotate http://brdy.in/sswannotate
- 12. More Pain for Better Results This is good pain
- 13. TFS for Source Control ? Check in regularly http://brdy.in/sswcheckin Only check in code that compiles and passes tests http://brdy.in/sswcheckin2
- 14. TFS for Source Control Shelvesets
- 17. Check-in Policies http://brdy.in/sswcheckinpolicy
- 18. Automated Builds in TFS ? Gate Gated Checkin Runs all unit tests CI Triggered after a checkin Runs all unit tests and all coded UI tests Nightly Triggered … nightly Run all unit tests, coded UI test, and load tests http://brdy.in/sswbuilds
- 21. Scrum with TFS ? ? TFS Scrum v2.0 will be the new default
- 23. User Stories in TFS ? INVEST Independent Negotiable Valuable Estimable Small Testable http://brdy.in/sswuserstory
- 25. Adding Backlog Items Excel Project TeamCompanion
- 26. Adding Backlog Items (in 2012) Excel Web Access Project TeamCompanion
- 27. Estimating Inestimable Tasks ? Tasks should be estimable Spikes can be used to estimate inestimable tasks http://brdy.in/sswestimate
- 28. Acceptance Criteria Positive Criteria Negative Criteria Gold Plating http://brdy.in/sswacceptance
- 30. Definition of Done ? We define: 7 levels of “Done” in software quality 3 levels of “Done” in communication http://brdy.in/sswdone
- 31. Summary TFS Master – get the most out of TFS TFS is more than just source control
- 32. Tips 1. Annotate not History 2. Shelve unfinished work 3. Check-in Policies 4. Automated Builds 5. Story Cards 6. Spiking 7. Acceptance Criteria 8. Definition of Done
- 33. 4 things… DamianBrady@ssw.com.au http://www.damianbrady.com.au @damovisa http://www.dddbrisbane.com
- 34. Thank You! Sydney | Melbourne | Brisbane | Adelaide info@ssw.com.au www.ssw.com.au Delivering Awesome Web Applications
- 35. Find me on Slideshare! http://www.slideshare.net/damovisa/
Notas do Editor
- TODO: Include text for first two pts
- Don’t delete –this is the version number for SlideShare
- Hadn’t heard of this term prior to SSWThere used to be a concept of a Code Master and Code Slaves – any big changes like function names were the responsibility of the Code Master and the Code Slaves (or code monkeys) just implemented the functions.Now we encourage teams to share the load – so why a TFS Master?If everybody is in charge, nobody is in charge.There are some areas where someone needs to be in charge – schema master, scrum master, and TFS master
- Why use TFS? Why not Git or Hg or SVN?The real power is in integrationIf you’re using TFS for source control only, you’re doing it wrong
- Most people only really use about 20% of the capabilities of TFSThere’s much more to it.
- ? What is your number one reason for using TFS?My number one favourite function in TFS is Annotate
- Let’s say you do a get latest, you compile, and you get a YSOD because the web.config is broken.You want to know who screwed this upThis is what most people do:Right-click on the file and choose History[explain]
- You can choose two versions and compare them…
- … to see what changes were made.It’s good, but it’s not the best way of attributing blame.
- A better way of finding out who is responsible for a bad piece of code is using Annotate:This tells you in one glance who made the most recent change to each part of the fileYou can see the name of the person who is responsible for each line, and the associated changeset
- If you click on the actual changeset you can see details about that particular checkin:Here you can see Sumesh only checked in the one file, and wrote acheckin commentIf you click on Work Items, you can see any work items associated with that checkin (we’ll get to that)We can see checkin notes (e.g. Code Reviewers) and whether any policies have been ignoredThis is GREAT for attributing blame? Is that cool? – Demo if interested
- I promised to show you how to increase developer pain for results.This is pain that I willingly inflict on myself, so it’s not bad.
- ? So let me give you a scenario – Friday afternoon, you’ve been working on a particularly involved piece of code on your laptop, it doesn’t compile, not working, and you’re heading to, like, the Vic – so there’s a 50% chance you’re going to lose your laptop.Would you check in your code or not?So we make two recommendations that at first glance are quite contradictoryDon’t check in code that will disrupt someone else’s work
- Shelvesets are an excellent way of saving code on the server without ruining the other dev’s dayTwo scenarios:You have a whole lot of code that doesn’t work and you don’t want to risk losing itYou’re halfway through something and you need to fix another bug
- Incidentally, there’s a great third-party tool to help out with … getting up your team when they do things wrong…Team Foundation Sidekicks:lets you identify files that haven’t been checked in for a while (we send an email)Also helps out with files checked out in other workspaces
- One of my pet hates is code changes with no good comments.Here’s the history of a file. What the hell is this – a checkin of a file with zero details of what was changed – I don’t want to have to examine the code to work out what you did.
- There are two you should enable in your project right now:Comments – you must include a description of what you’ve doneIf you’re using TFS for work items, Definitely, definitely enable the Work Items policy (arguably you don’t need the checkin comments then)There are other good ones available like code analysis, enforcing that certain tests pass before checking in (different from gated checkins), etc.
- ? Who here does builds with TFS? Are they automated builds? When do they run?We recommend three builds for any decent-sized projectGate should be a gated checkin – do not allow a checkin until tests have been run – you might not want to keep this buildCI runs after a checkin and runs all tests including coded UI tests - again, you might not want to keep this buildNightly is what it sounds like – do everything, even packaging and deployment if you want – ideally you’ll keep this oneIf questions: two bits of advice:Set these up as early in the project as you can – you’ll find it hard to get approval towards the endUse your common sense to expand and contract this list as appropriate
- You actually get a lot of control with these build definitionsIf there are particularly long-running tests or ones that rely on third parties (such as databases) you can prioritise them to include or exclude them from a build definitionKeep an eye on the time taken for the builds and be sensible
- The test settings let you change what data is collected when tests are run.You should have a local testsettings file for when you run them inside VS – enable some collection – Code Coverage, etc.Have a different testsettings file for when you run your big builds – great data for your CI build is Network Emulation, Event Log, etc.
- Who’s running Scrum?Who’s used TFS for project management?What template do you use? (MSF Agile, TFS Scrum 1.0, Scrum for Team System)
- Scrum 2.0 is the default for the next TFS
- What makes a good user story?Independentmeans you can reorder themNegotiable means you don’t need to set it in stone – it’s the essence, not the detailsValuable – what’s valuable to the developer does not always match what’s valuable to the customerEstimable means you can give an idea of how difficult it is – it doesn’t need to be perfect (spiking later)Small means it’s not an epic – small enough to do a few within a sprintTestable means it can be objectively evaluated as done or not done (acceptance criteria later)
- This is a great way of doing it – it’s a physical card you can give to your customer that lets them think in the correct way.I have a few of them here – feel free to take them – or just print them out by going to the website
- There are several ways to add Backlog Items to TFS and the most common are these:Excel – I’ve used this in projects and it’s quite quick and easy – good for BAs, project managers, even Scrum MastersProject – project managers love it because it lets them attach dollars, and it integrates quite well with TFSTeamCompanion – Adam Cogan loves it. It’s great for going from emails to TFS, but… I find it a bit clunky.
- Now, I’m reliably informed that in the next version of TFS, the UI for adding backlog items through Web Access is much, much better. Excel might no longer be the simplest way to add them.I will reserve judgement until I have a play with it.STOP – Spiking story!
- I was recently setting up a website using Orchard CMS. I hadn’t used it before, and there were some interesting requirements.One was that every page needed a little PDF icon which, when clicked, would generate a PDF version of the page.Keeping in mind I’d never used Orchard before – how do I estimate this? How would you estimate this?Spikes – the output of a spike story should be the decision and estimate for the original story.
- One thing that helps make a great User Story is Acceptance CriteriaClassic story of the client that says – in true User Story language, as a salesperson I want to search for a customer so I can call them, so you do that and return a grid of people. What they don’t tell you though, is that if you search for a person who has no phone number, they want to see an email address instead. Without a firm view of “this is what I consider as correct” from the client, you’re in danger of arguing about whether a story is finished.Adam Cogan has been pushing this for a while and he had a big win with the next TFS version.
- Acceptance criteria as part of the standard PBI work item!In preparation, I would suggest including Acceptance Criteria with stories now.
- ? When is a story done?We talk a lot about the definition of done at SSWImportant to have one
- TODO: Summary of