Transcript Session Title That is Really Long and Covers Two Lines

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]
Professional Scrum at Scrum.org
Professional
Scrum
Product Owner
Professional
Scrum Master
Professional
Scrum
Developer
.NET or Java
Product Owners
Executives
Scrum Masters
Professional Scrum Foundations
© 1993-2011 Scrum.org, All Rights Reserved
Architects
Business Analysts
DB Specialists
Designers
Developers
Testers
Everyone
Top 10 Ways
1.
2.
3.
4.
5.
Write 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.
9.
Assume everything will
change.
Ask yourself if you really
need that ORM.
Create an automated build
on day #1.
Do less.
10.
Be humble and honest.
6.
7.
8.
Top 10 Ways
1.
2.
3.
4.
5.
Write 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.
9.
Assume everything will
change.
Ask yourself if you really
need that ORM.
Create an automated build
on day #1.
Do less.
10.
Be humble and honest.
6.
7.
8.
#1
Write down your
Definition of Done.
Definition of Done (DoD) =
Everything it takes to say
something is
completely 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 Ways
1.
2.
3.
4.
5.
Write 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.
9.
Assume everything will
change.
Ask yourself if you really
need that ORM.
Create an automated build
on day #1.
Do less.
10.
Be humble and honest.
6.
7.
8.
!(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
http://tinyurl.com/bqextsa
There’s no reason for it.
Use the
Visual Studio 2012
Database Project.
Top 10 Ways
1.
2.
3.
4.
5.
Write 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.
9.
Assume everything will
change.
Ask yourself if you really
need that ORM.
Create an automated build
on day #1.
Do less.
10.
Be humble and honest.
6.
7.
8.
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 Ways
1.
2.
3.
4.
5.
Write 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.
9.
Assume everything will
change.
Ask yourself if you really
need that ORM.
Create an automated build
on day #1.
Do less.
10.
Be humble and honest.
6.
7.
8.
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.
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)
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.
Suicidal
Non-Planning
Sanity
&
Balance
Big
Design
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 Ways
1.
2.
3.
4.
5.
Write 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.
9.
Assume everything will
change.
Ask yourself if you really
need that ORM.
Create an automated build
on day #1.
Do less.
10.
Be humble and honest.
6.
7.
8.
No one is as smart as you are.
Favor understandability
over
elegance.
Top 10 Ways
1.
2.
3.
4.
5.
Write 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.
9.
Assume everything will
change.
Ask yourself if you really
need that ORM.
Create an automated build
on day #1.
Do less.
10.
Be humble and honest.
6.
7.
8.
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 Ways
1.
2.
3.
4.
5.
Write 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.
9.
Assume everything will
change.
Ask yourself if you really
need that ORM.
Create an automated build
on day #1.
Do less.
10.
Be humble and honest.
6.
7.
8.
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 PKFK 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 Ways
1.
2.
3.
4.
5.
Write 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.
9.
Assume everything will
change.
Ask yourself if you really
need that ORM.
Create an automated build
on day #1.
Do less.
10.
Be humble and honest.
6.
7.
8.
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 Ways
1.
2.
3.
4.
5.
Write 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.
9.
Assume everything will
change.
Ask yourself if you really
need that ORM.
Create an automated build
on day #1.
Do less.
10.
Be humble and honest.
6.
7.
8.
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 Ways
1.
2.
3.
4.
5.
Write 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.
9.
Assume everything will
change.
Ask yourself if you really
need that ORM.
Create an automated build
on day #1.
Do less.
10.
Be humble and honest.
6.
7.
8.
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 Ways
1.
2.
3.
4.
5.
Write 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.
9.
Assume everything will
change.
Ask yourself if you really
need that ORM.
Create an automated build
on day #1.
Do less.
10.
Be humble and honest.
6.
7.
8.
Thank you.
www.benday.com | [email protected]