10 ways to get your project started right
DESCRIPTION
10 Ways to Get Your Project Started Right. Benjamin Day. Benjamin Day. Consultant, Coach, Trainer Scrum.org Classes Professional Scrum Developer (PSD) Professional Scrum Foundations (PSF) TechEd , VSLive , DevTeach , O’Reilly OSCON Visual Studio Magazine, Redmond Developer News - PowerPoint PPT PresentationTRANSCRIPT
10 Ways to Get Your Project Started Right
Benjamin Day
Benjamin Day• Consultant, Coach, Trainer• Scrum.org Classes
– Professional Scrum Developer (PSD)– Professional Scrum Foundations (PSF)
• TechEd, VSLive, DevTeach, O’Reilly OSCON• Visual Studio Magazine, Redmond Developer News• Microsoft MVP for Visual Studio ALM• Team Foundation Server, TDD, Testing Best Practices,
Silverlight, Windows Azure• www.benday.com/blog• [email protected]
© 1993-2011 Scrum.org, All Rights Reserved
Professional Scrum at Scrum.org
Professional Scrum
Product Owner
Professional Scrum Foundations
Professional Scrum Master
Professional Scrum
Developer.NET or Java
Product OwnersExecutives Scrum Masters
ArchitectsBusiness Analysts
DB SpecialistsDesigners
DevelopersTesters
Everyone
Top 10 Ways1. Write down your
Definition of Done.2. Don't use a shared
development database.
3. Write unit tests. 4. Design from the UI to
the database.5. Keep it simple.
6. Assume everything will change.
7. Ask yourself if you really need that ORM.
8. Create an automated build on day #1.
9. Do less.10. Be humble and honest.
Top 10 Ways1. Write down your
Definition of Done.2. Don't use a shared
development database.
3. Write unit tests. 4. Design from the UI to
the database.5. Keep it simple.
6. Assume everything will change.
7. Ask yourself if you really need that ORM.
8. Create an automated build on day #1.
9. Do less.10. 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 Scrum
• Technical Debt will ruin you.
• Write it down.
• Review and discuss it regularly.
Consider firing anyone who says “Done vs. Done Done”
Sample DoD• Checked in to source control• Compiled as part of an automated build• Unit tested with >75% code coverage• Automated build output is tested by
someone who didn’t write the code• No P1 or P2 bugs• Automated deployment script• Code review
Do not relax your DoD.
Top 10 Ways1. Write down your
Definition of Done.2. Don't use a shared
development database.
3. Write unit tests. 4. Design from the UI to
the database.5. Keep it simple.
6. Assume everything will change.
7. Ask yourself if you really need that ORM.
8. Create an automated build on day #1.
9. Do less.10. Be humble and honest.
!(Shared Development Database)
Just say no.• Fuzzy version control
– “What’s in production?”– “Have we tested that?”
• Rots your brain– Bad unit tests– Bad application architecture– No automated builds.– Abysmal maintainability
• Everyone on top of each other
There’s no reason for it.
Use the Visual Studio 2012Database Project.
Top 10 Ways1. Write down your
Definition of Done.2. Don't use a shared
development database.
3. Write unit tests. 4. Design from the UI to
the database.5. Keep it simple.
6. Assume everything will change.
7. Ask yourself if you really need that ORM.
8. Create an automated build on day #1.
9. Do less.10. Be humble and honest.
What is Test Driven Development?• Develop code with proof that it works
– Code that validates other code– Small 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 bugs– Bugs are easier to diagnose
• Encourages you to think about…– …what you’re building– …how you know you’re done– …how you know it works
• Less time in the debugger• Tests that say when something works
– Easier maintenance, refactoring– Self-documenting
Maximize Your QA Staff• You shouldn’t need QA to tell you your code
doesn’t work• Unit tests minimize the pointless bugs
– “nothing happened” – “I got an error message” + stack trace– NullReferenceException
• QA should be checking for:– Stuff only a human can test– User 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 Ways1. Write down your
Definition of Done.2. Don't use a shared
development database.
3. Write unit tests. 4. Design from the UI
to the database.5. Keep it simple.
6. Assume everything will change.
7. Ask yourself if you really need that ORM.
8. Create an automated build on day #1.
9. Do less.10. Be humble and honest.
User Interface (ASP.NET, XAML, WinForms, etc.)
Presentation (MVC / MVVM)
Domain Model / Service Layer
Repository / Data Access
The Relational Database (Tables, FKs, Views, Stored Proc's)
The layers in your app.
User Interface (ASP.NET, XAML, WinForms, etc.)
Presentation (MVC / MVVM)
Domain Model / Service Layer
Repository / Data Access
The Relational Database (Tables, FKs, Views, Stored Proc's)
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.
SuicidalNon-Planning
Sanity &
Balance
BigDesign
Up-Front
Iterate the UI with your customer.• Minimal to no implementation.
• Visual Studio 2012 PowerPoint Storyboarding
• If you have to write code…– Dependency Injection– Interface-driven programming– Mock implementations
Top 10 Ways1. Write down your
Definition of Done.2. Don't use a shared
development database.
3. Write unit tests. 4. Design from the UI to
the database.5. Keep it simple.
6. Assume everything will change.
7. Ask yourself if you really need that ORM.
8. Create an automated build on day #1.
9. Do less.10. Be humble and honest.
No one is as smart as you are.
Favor understandability over
elegance.
Top 10 Ways1. Write down your
Definition of Done.2. Don't use a shared
development database.
3. Write unit tests. 4. Design from the UI to
the database.5. Keep it simple.
6. Assume everything will change.
7. Ask yourself if you really need that ORM.
8. Create an automated build on day #1.
9. Do less.10. 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 Framework
• Use the Repository Pattern
• Remember Single Responsibility Principle
Build for Testability• Unit test, unit test, unit test
• Unit test != Integration Test
• Test one layer at a time in isolation
• No database connections from a unit test
• Integration tests in a separate project– Keep yourself honest
For the love of all things precious & beautiful…
…DON’T USE A SHARED DEVELOPMENT DATABASE!!!!!!!!
Top 10 Ways1. Write down your
Definition of Done.2. Don't use a shared
development database.
3. Write unit tests. 4. Design from the UI to
the database.5. Keep it simple.
6. Assume everything will change.
7. Ask yourself if you really need that ORM.
8. Create an automated build on day #1.
9. Do less.10. Be humble and honest.
ORM• Object-Relational Mapper
• Entity Framework
• NHibernate
• LINQ-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 DDD• Car has an identity column, CarID
– CarID is the Primary Key
• Car has a collection of Tire objects– myCar.Tires– Tire 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 Car
• Less to write
• Less to test
• Is that ORM really buying you anything?
http://tinyurl.com/ln248h
Top 10 Ways1. Write down your
Definition of Done.2. Don't use a shared
development database.
3. Write unit tests. 4. Design from the UI to
the database.5. Keep it simple.
6. Assume everything will change.
7. Ask yourself if you really need that ORM.
8. Create an automated build on day #1.
9. Do less.10. 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 Ways1. Write down your
Definition of Done.2. Don't use a shared
development database.
3. Write unit tests. 4. Design from the UI to
the database.5. Keep it simple.
6. Assume everything will change.
7. Ask yourself if you really need that ORM.
8. Create an automated build on day #1.
9. Do less.10. 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 things
• Complete that thing. Move on to the next thing.
• Try to drive stuff to DoD early.
Top 10 Ways1. Write down your
Definition of Done.2. Don't use a shared
development database.
3. Write unit tests. 4. Design from the UI to
the database.5. Keep it simple.
6. Assume everything will change.
7. Ask yourself if you really need that ORM.
8. Create an automated build on day #1.
9. Do less.10. Be humble and honest.
Be humble.Be honest.
Be transparent.
Do yourself a favor and say“forecast” rather than “commitment”
Use Team Foundation Server & Scrum• Create a Product Backlog of 2 – 3 months
of work– Estimate using Planning Poker & Story Points
• Establish a Velocity
• Update remaining hours on Tasks daily
• Use 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 Ways1. Write down your
Definition of Done.2. Don't use a shared
development database.
3. Write unit tests. 4. Design from the UI to
the database.5. Keep it simple.
6. Assume everything will change.
7. Ask yourself if you really need that ORM.
8. Create an automated build on day #1.
9. Do less.10. Be humble and honest.
