10 Ways to Get Your Project Started Right Benjamin Day.
-
Upload
kerry-byrd -
Category
Documents
-
view
223 -
download
3
Transcript of 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 Ways
1. 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 Ways
1. 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 your DoD?
• Closest thing to a “silver bullet” in Scrum
• Technical Debt will ruin you.
• Write it down.
• Review and discuss it regularly.
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
Top 10 Ways
1. 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.
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
Top 10 Ways
1. 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
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/
Top 10 Ways
1. 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.
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 Ways
1. 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 Ways
1. 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.
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
Top 10 Ways
1. 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)
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?
Top 10 Ways
1. 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
Top 10 Ways
1. 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.
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. 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.
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
Top 10 Ways
1. 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.