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

2. 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. © 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 Professional Scrum Developer.NET or Java Product Owners Executives Scrum Masters Architects Business Analysts DB Specialists Designers Developers Testers Everyone

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

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

6. #1 Write down your Definition of Done.

7. Definition of Done (DoD) = Everything it takes to say something is completely 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 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.

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 2012 Database Project.

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

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

28. User Interface (ASP.NET, XAML, WinForms, etc.) Presentation (MVC / MVVM) Domain Model / Service LayerRepository / Data Access The Relational Database (Tables, FKs, Views, Stored Proc's) The layers in your app.

29. User Interface (ASP.NET, XAML, WinForms, etc.) Presentation (MVC / MVVM) Domain Model / Service LayerRepository / Data Access The Relational Database (Tables, FKs, Views, Stored Proc's) 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’t gunna need it.)

35. Emergent Architecture. Build what you need. It’s a spectrum. Suicidal Non-Planning Sanity & Balance Big Design Up-Front

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

38. No one is as smart as you are.

39. Favor understandability over elegance.

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

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

51. ORM Object-Relational Mapper Entity Framework NHibernate LINQ-to-SQL (…and zillions of other ones)

52. Identify your Aggregate Roots.

53. Aggregates & Aggregate Roots “Domain-Driven Design” by Eric Evans page 112

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

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

56. 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?

57. http://tinyurl.com/ln248h

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

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

60. http://tinyurl.com/d7f3lh5

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

62. Minimize work in progress.

63. Put another way… don’t try to do everything at once.

64. If everyone on your team is working on separate PBIs, is the team really a team?

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

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

67. Be humble. Be honest. Be transparent.

68. Do yourself a favor and say “forecast” rather than “commitment”

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

70. Advertise data from TFS. Make data-driven predictions.

71. Once you’ve lost credibility, you’ll lose good will. You’ll always be behind from then on.

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

73. Thank you. www.benday.com | benday@benday.com