10 Ways to Get Your Project Started Right

1. 10 Ways to Get Your Project Started Right Benjamin Day

2. 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 • benday@benday.com

3. Professional Scrum at Scrum.org Professional Scrum Product Owner Professional Scrum Master Professional Scrum Developer .NET or Java Product Owners Executives Scrum Masters Architects Business Analysts DB Specialists Designers Developers Testers Professional Scrum Foundations Everyone

4. Top 10 Ways • 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. • 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.

5. Top 10 Ways • 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. • 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.

6. #1Write down your Definition of Done.

7. Definition of Done (DoD) = Everything it takes to say something iscompletely done.

8. 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.

9. Consider firing anyone who says “Done vs. Done Done”

10. 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

11. Do not relax your DoD.

12. Top 10 Ways • 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. • 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.

13. !(Shared Development Database)

14. 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

15. http://tinyurl.com/bqextsa

16. There’s no reason for it.

17. Use the Visual Studio 2012Database Project.

18. Top 10 Ways • 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. • 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.

19. 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

20. 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

21. 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

22. How would you test this?

23. 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/

24. Unit tests save huge amounts of time.

25. Easier to QA.

26. Easier to maintain.

27. Top 10 Ways • 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. • 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.

28. The layers in your app.

29. How people typically “architect” their app.

30. What do you show your customer?

31. If you’ve build n layers and they hate it…

32. …are you really going to throw it away?

33. Avoid BDUF.(Big design up-front.)

34. YAGNI.(You ain’tgunna need it.)

35. Emergent Architecture. • Build what you need. • It’s a spectrum.

36. 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

37. Top 10 Ways • 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. • 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.

38. No one is as smart as you are.

39. Favor understandability overelegance.

40. Top 10 Ways • 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. • 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.

41. It’s a metaphysical *certainty* that you’ll have to change stuff.

42. You *won’t* get your “requirements” right.

43. Your customers *will* change their minds.

44. Accept that you’ll have to change.

45. The Goal: Make refactoring painless.

46. 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

47. 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

48. For the love of all things precious & beautiful…

49. …DON’T USE A SHARED DEVELOPMENT DATABASE!!!!!!!!

50. Top 10 Ways • 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. • 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.