Practices of an Agile Developer - PowerPoint PPT Presentation

1 / 58
About This Presentation
Title:

Practices of an Agile Developer

Description:

Don't use your old language tools at all while you're transitioning. ... The all-nighter. The pick-up game. Pair programming. 57. 45. Keep Others Informed. ... – PowerPoint PPT presentation

Number of Views:103
Avg rating:3.0/5.0
Slides: 59
Provided by: nith9
Category:

less

Transcript and Presenter's Notes

Title: Practices of an Agile Developer


1
Practices of an Agile Developer
  • Written by
  • Venkat Subramaniam
  • Andy Hunt

2
Contents
  • Agile Software Development
  • Beginning Agility
  • Feeding Agility
  • Delivering What Users Want
  • Agile Feedback
  • Agile Coding
  • Agile Debugging
  • Agile Collaboration
  • Moving to Agility

3
Agile Software Development
4
Agile Concept
  • Software development
  • Dynamic process.
  • The spirit of agility
  • Lightweight processes.
  • People, collaboration, responsiveness, and focus
    on demonstrable.
  • Development is continuous and feedback is
    continuous

5
Agile Practice and Tool
  • The Practice of Agility
  • Agile teams is small or broken up to small.
  • Work processes in iterations.
  • An Agile Toolkit
  • WikiWikiWeb
  • Version control
  • Unit Testing
  • Build automation

6
Beginning Agility
7
1. Work for outcome.
  • Blame doesnt fix bugs.
  • Feels like the team is working together, not
    blaming each other.

8
2. Quick Fixes Become Quicksand.
  • Quick fix is a very seductive proposition.
  • Dont code in isolation.
  • Use unit tests.

9
3. Criticize Ideas, Not people.
  • Negativity kills Innovation.
  • Some techniques
  • Set a deadline.
  • Argue the opposite.
  • Use a mediator.
  • Support the decision.
  • Take pride in arriving at a solution.

10
4.Damn the Torpedoes, Go Ahead.
  • Have the courage to communicate the truth.
  • The only way to remove obstacles.

11
Feeding Agility
12
5. Keep up with change.
  • How to keep up with changing
  • Learn iteratively and incrementally.
  • Get the latest buzz.
  • Attend local user groups.
  • Attend workshop or conferences.
  • Read voraciously.
  • You dont have to become an expert at everything,
    but stay aware of where the industry is headed.

13
6. Invest in Your Team.
  • A well-educated team is a better team.
  • Set up Brown-bag session.
  • Raise the industry awareness of the whole team.
  • Feel likes everyone get smarter.

14
7. Know When to Unlearn.
  • Dont use your old language tools at all while
    youre transitioning.
  • Unlearn any old habits that might hold you back.

15
8. Question Until You Understand.
  • Why? is a grate question.
  • Keep questioning until you understand the root of
    issue.
  • Feel that you understand the real problem.

16
9. Feel the Rhythm.
  • Agile projects have rhythms and cycles.
  • Edit, run tests and review, over a consistent
    iteration length, and ten release.

17
Delivering What Users Want
18
10.Let Customers Make Decisions.
  • Decide what you shouldnt decide
  • Shouldnt business decision
  • Business applications are developed as
    partnership
  • Keep record of decisions

19
11. Let Design Guide, Not Dictate.
  • Design is an essential step in development
    process to understand
  • Interrelationships between parts and subsystems.
  • Details of systems.
  • Direct you toward an implementation.
  • Design should be only as detailed as needed to
    implement.
  • Two levels of Design Strategic and Tactical.
  • Good design is a map.

20
12. Justify Technology Use.
  • Choose technology based on need.
  • Identify what problem you are to solve and
    consider
  • Does it really solve the problem?
  • Will you be tied to this technology?
  • What about maintenance cost?

21
13. Keep It Releasable.
  • Checked-in code is always ready for action.
  • Dont check in broken code.
  • Run your local test.
  • Check out the latest source.
  • Check in.

22
14. Integrate Early, Integrate Often.
  • Dont stay isolate too long.
  • Should integrate your code several times a day,
    never go longer two or three days.

23
15. Automate Development Early.
  • Give QA team a chance to test deployment.

24
16. Get Frequent Feedback Using Demos.
  • Requirements are fluid as ink, you cant freeze
    requirements.
  • Consult your customers frequently, getting input
    as you develop. ? get feedback often.

25
17. Use Short Iteration, Release in Increments.
  • Iteration development carry out the tasks of
    development in small, repetitive cycle.
  • Set a milestone in the end of each Iteration.
  • An increment of the product is complete when you
    are ready to release product.

26
18. Fixed Prices Are Broken Promises.
  • Estimate base on real work.
  • Estimate will change throughout the project.
  • Plan-based development nonagile environment.

27
Agile Feedback
28
19. Put Angles on Your Shoulders.
  • Agility is all about managing change, and the
    code is the one thing that change the most.
  • Run the unit tests every time you compile or
    build.

29
20. Use It Before You Build It.
  • Write tests before writing code.
  • Using TDD Test driven development.

30
21. Different Makes a Difference.
  • Run unit test on each supported platform and
    environment.
  • Hardware is cheaper than developer time.

31
22. Automate Acceptance Testing.
  • Create tests for core business logic.
  • Using FIT Framework for Integration Testing.
    (www.fit.c2.com)

32
23. Measure Real Progress.
  • Use backlog to measure progress.
  • Backlog is a list of tasks that still need to be
    completed.
  • Focus on functionality, not the calendar.

33
24. Listen to Users.
  • Find the truth and fix the real problem.

34
Agile Coding
35
25. Program Intently and Expressively.
  • Readable code.
  • Reduce unnecessary comments.

36
26. Communicate in Code.
  • How to comment
  • Purpose
  • Pre-conditions
  • Post-conditions
  • Exceptions

37
27. Actively Evaluate Trade-Offs.
  • Consider performance, convenience, productivity,
    cost and time.
  • No best solution.

38
28. Code in Increments.
  • Code in short cycle.
  • Run a build/test cycle after writing a few lines
    of code.

39
29. Keep It Simple.
  • Develop the simplest solution.
  • Easy to follow and correct.
  • Simple and readable code.

40
30. Write Cohesive Code.
  • Cohesion a measure of functionally related the
    members of a component are.
  • MVC -- Model -View- Controller.

41
31. Tell, Dont Ask.
  • Command-query separation.

42
32. Substitute by Contract.
  • Use inheritance for is-a.
  • Use delegation for has-a or uses-a.

43
Agile Debugging
44
33. Keep a Solution Log.
  • Day log
  • Date of problem
  • Short description of issue
  • Detail description of solution
  • Reference to articles, URL.
  • Any code segments, setting, est.

45
34. Warnings Are Really Errors.
  • Treat warnings as errors.

46
35. Attack Problems in Isolation.
  • Separate the component or module that has the
    problems.

47
36. Report All Exceptions.
  • Write your code with exception,
  • Determining who is responsible for handling is
    part of design.

48
37. Provide Useful Error Messages.
  • Provide users with a clean, high-level exception.
  • Provide an easy way to find the details of
    errors.
  • Ex. File Not Found
  • -gt Cant open /andy/project/main.yaml

49
Agile Collaboration
50
38. Schedule Regular Face Time.
  • Use Stan-up meeting to get the team together.
  • Keep meeting focus in three question
  • What did I achieve yesterday?
  • What am I planning to do today?
  • Whats in my way?

51
39. Architects Must Write Code.
  • Architect person who design and guide,not a
    person who just draws pretty pictures, speak
    jargon, uses a lot of patterns.
  • Good design develop from active programmers.
  • Dont let anyone design in isolation.

52
40. Practice Collective Ownership.
  • Rotate developer across different modules and
    tasks in different areas of systems.
  • Have to be more careful if know others are
    watching.

53
41. Be a Mentor.
  • Knowledge when given.
  • Use Bag Brown session.
  • Great way to invest your team.

54
42. Allow People to Figure It Out.
  • Give the others chance to solve problems.
  • Answer the question with another question.

55
43. Share Code Only When Ready.
  • Never check-in code that doesnt ready for others.

56
44. Review Code.
  • How to review
  • The all-nighter
  • The pick-up game
  • Pair programming

57
45. Keep Others Informed.
  • Give the others know your progress.
  • Use information radiator use poster on the wall
    or website or wiki to broadcast their status.

58
Moving to Agility
  • Just One New Practice.
  • It made a huge difference to a team.
  • Rescuing a Failing Project.
  • Introducing Agility The Managers Guide.
  • Introducing Agility The Programmers Guide.
  • The End? www.pragmaticprogrammer.com
Write a Comment
User Comments (0)
About PowerShow.com