10 Ways to Get Your Project Started Right Benjamin Day Benjamin Day Consultant Coach Trainer Scrumorg Classes Professional Scrum Developer PSD Professional Scrum Foundations PSF TechEd VSLive ID: 762801
Download Presentation The PPT/PDF document "10 Ways to Get Your Project Started Righ..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
10 Ways to Get Your Project Started Right Benjamin Day
Benjamin DayConsultant, Coach, TrainerScrum.org ClassesProfessional Scrum Developer (PSD)Professional Scrum Foundations (PSF) TechEd , VSLive, DevTeach, O’Reilly OSCONVisual Studio Magazine, Redmond Developer NewsMicrosoft MVP for Visual Studio ALMTeam Foundation Server, TDD, Testing Best Practices,Silverlight, Windows Azurewww.benday.com/blogbenday@benday.com
Professional Scrum at Scrum.org Professional Scrum Product Owner Professional Scrum Foundations Professional Scrum Master Professional Scrum Developer .NET or Java Product Owners Executives Scrum Masters Architects Business Analysts DB Specialists Designers Developers Testers Everyone
Top 10 WaysWrite down your Definition of Done. Don't use a shared development database.Write unit tests. Design from the UI to the database.Keep it simple.Assume everything will change. Ask yourself if you really need that ORM. Create an automated build on day #1. Do less. Be humble and honest.
Top 10 WaysWrite down your Definition of Done. Don't use a shared development database.Write unit tests. Design from the UI to the database.Keep it simple.Assume everything will change. Ask yourself if you really need that ORM. Create an automated build on day #1. Do less. Be humble and honest.
#1Write down your Definition of Done.
Definition of Done (DoD) = Everything it takes to say something iscompletely done.
What is your DoD?Closest thing to a “silver bullet” in ScrumTechnical Debt will ruin you.Write it down. Review and discuss it regularly.
Consider firing anyone who says “Done vs. Done Done”
Sample DoDChecked in to source controlCompiled as part of an automated buildUnit tested with >75% code coverageAutomated build output is tested by someone who didn’t write the code No P1 or P2 bugsAutomated deployment scriptCode review
Do not relax your DoD.
Top 10 WaysWrite down your Definition of Done. Don't use a shared development database.Write unit tests. Design from the UI to the database.Keep it simple.Assume everything will change. Ask yourself if you really need that ORM. Create an automated build on day #1. Do less. Be humble and honest.
!(Shared Development Database)
Just say no.Fuzzy version control“What’s in production?”“Have we tested that?”Rots your brainBad unit tests Bad application architectureNo automated builds.Abysmal maintainabilityEveryone on top of each other
http://tinyurl.com/bqextsa
There’s no reason for it.
Use the Visual Studio 2012Database Project.
Top 10 WaysWrite down your Definition of Done. Don't use a shared development database.Write unit tests. Design from the UI to the database.Keep it simple.Assume everything will change. Ask yourself if you really need that ORM. Create an automated build on day #1. Do less. Be humble and honest.
What is Test Driven Development?Develop code with proof that it worksCode that validates other codeSmall chunks of “is it working?”Small chunks = Unit Tests“Never write a single line of code unless you have a failing automated test.” Kent Beck, “Test-Driven Development”, Addison-Wesley
Why Use TDD?High-quality code Fewer bugsBugs are easier to diagnoseEncourages you to think about… …what you’re building…how you know you’re done…how you know it worksLess time in the debuggerTests that say when something works Easier maintenance, refactoringSelf-documenting
Maximize Your QA StaffYou shouldn’t need QA to tell you your code doesn’t workUnit tests minimize the pointless bugs“nothing happened” “I got an error message” + stack traceNullReferenceException QA should be checking for:Stuff only a human can testUser Story / Product Backlog Item Bug assigned to you should add business value
How would you test this?
What is Design For Testability?Build it so you can test it. How would you test this? Do you have to take the plane up for a spin? http://www.flickr.com/photos/ericejohnson/4427453880/
Unit tests save huge amounts of time.
Easier to QA.
Easier to maintain.
Top 10 WaysWrite down your Definition of Done. Don't use a shared development database.Write unit tests. Design from the UI to the database.Keep it simple.Assume everything will change. Ask yourself if you really need that ORM. Create an automated build on day #1. Do less. Be humble and honest.
The layers in your app.
How people typically “architect” their app.
What do you show your customer?
If you’ve build n layers and they hate it…
…are you really going to throw it away?
Avoid BDUF.(Big design up-front.)
YAGNI.(You ain’t gunna need it.)
Emergent Architecture.Build what you need.It’s a spectrum.
Iterate the UI with your customer.Minimal to no implementation.Visual Studio 2012 PowerPoint StoryboardingIf you have to write code… Dependency InjectionInterface-driven programmingMock implementations
Top 10 WaysWrite down your Definition of Done. Don't use a shared development database.Write unit tests. Design from the UI to the database.Keep it simple.Assume everything will change. Ask yourself if you really need that ORM. Create an automated build on day #1. Do less. Be humble and honest.
No one is as smart as you are.
Favor understandability overelegance.
Top 10 WaysWrite down your Definition of Done. Don't use a shared development database.Write unit tests. Design from the UI to the database.Keep it simple.Assume everything will change. Ask yourself if you really need that ORM. Create an automated build on day #1. Do less. Be humble and honest.
It’s a metaphysical *certainty* that you’ll have to change stuff.
You *won’t* get your “requirements” right.
Your customers *will* change their minds.
Accept that you’ll have to change.
The Goal: Make refactoring painless.
Loose coupling.Code to interfaces.Use the Dependency Injection Pattern(Pass dependencies in on the constructor.)Consider an IoC FrameworkUse the Repository PatternRemember Single Responsibility Principle
Build for TestabilityUnit test, unit test, unit testUnit test != Integration TestTest one layer at a time in isolationNo database connections from a unit test Integration tests in a separate projectKeep yourself honest
For the love of all things precious & beautiful…
…DON’T USE A SHARED DEVELOPMENT DATABASE!!!!!!!!
Top 10 WaysWrite down your Definition of Done. Don't use a shared development database.Write unit tests. Design from the UI to the database.Keep it simple.Assume everything will change. Ask yourself if you really need that ORM. Create an automated build on day #1. Do less. Be humble and honest.
ORMObject-Relational MapperEntity FrameworkNHibernateLINQ-to-SQL (…and zillions of other ones)
Identify your Aggregate Roots.
Aggregates & Aggregate Roots“Domain-Driven Design”by Eric Evans page 112
Some definitions.Aggregate “a cluster of associated objects that we treat as a unit for the purpose of data changes.”Aggregate Root The object through which members of the aggregate are accessed.In a PKFK relationship, the root owns the PK
Example from DDDCar has an identity column, CarIDCarID is the Primary Key Car has a collection of Tire objects myCar.TiresTire objects have IDs, too.You’ll query Car objects by ID.You’ll never access Tire objects except via their Car.Car is the Aggregate Root.
If Car is the Aggregate Root…You only have to support query operations off of CarLess to write Less to testIs that ORM really buying you anything?
http://tinyurl.com/ln248h
Top 10 WaysWrite down your Definition of Done. Don't use a shared development database.Write unit tests. Design from the UI to the database.Keep it simple.Assume everything will change. Ask yourself if you really need that ORM. Create an automated build on day #1. Do less. Be humble and honest.
Eliminate the "works on my box" problem *early*. Set up automated builds from the very beginning. If you're using TFS, use Gated Check-in builds Deploy your database as part of your builds.Run your unit tests from the builds
http://tinyurl.com/d7f3lh5
Top 10 WaysWrite down your Definition of Done. Don't use a shared development database.Write unit tests. Design from the UI to the database.Keep it simple.Assume everything will change. Ask yourself if you really need that ORM. Create an automated build on day #1. Do less. Be humble and honest.
Minimize work in progress.
Put another way…don’t try to do everything at once.
If everyone on your team is working on separate PBIs, is the team really a team?
Finish one thing. Then do the next thing.Try to craft the work so that multiple people are working on related thingsComplete that thing. Move on to the next thing.Try to drive stuff to DoD early.
Top 10 WaysWrite down your Definition of Done. Don't use a shared development database.Write unit tests. Design from the UI to the database.Keep it simple.Assume everything will change. Ask yourself if you really need that ORM. Create an automated build on day #1. Do less. Be humble and honest.
Be humble.Be honest.Be transparent.
Do yourself a favor and say“forecast” rather than “commitment”
Use Team Foundation Server & ScrumCreate a Product Backlog of 2 – 3 months of workEstimate using Planning Poker & Story PointsEstablish a Velocity Update remaining hours on Tasks dailyUse the Burndown Chart
Advertise data from TFS.Make data-driven predictions.
Once you’ve lost credibility, you’ll lose good will.You’ll always be behind from then on.
Top 10 WaysWrite down your Definition of Done. Don't use a shared development database.Write unit tests. Design from the UI to the database.Keep it simple.Assume everything will change. Ask yourself if you really need that ORM. Create an automated build on day #1. Do less. Be humble and honest.
Thank you. www.benday.com | benday@benday.com