Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Agile Smells

No description

Chris Lilley

on 3 August 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Agile Smells

Agile Smells Code Smells... 1. Everything is priority #1 2. Your plan is made in isolation 3. Do not talk to the Users 4. Testing is separate 5. 50% of your code is unused 6. Lessons learned at the end... The 90 day iteration "Your software will be delivered at 10.34am on 4th September" "Our showcases need to be elaborately stage managed" Testing is fundamental to the design "I've never been to MoSCoW..." All about Capacity Estimation is all relative Voyeurism Vs. Participation "We use TDD so we're safe, right?" Requirements have a half life Seek out change Retrospectives every iteration Duplicated Code Contrived Complexity Methods too long "Taller than Me" principle Photo Credits:
http://secret.extrarisk.com/baby-panda-first-90-days-part-1.html Anti-patterns
Contra-indicators Something fishy... Other things to keep a nose out for:

Frequency of status updates increases
Individual "Velocity" metrics
Technical debt ignored at all costs
Pairing is "too expensive"
Developer churn rates ...but some things smell good: Kanban Flu Cross-functional socials Product Owners run the Kick off's Adam Wright adam.wright@blackpepper.co.uk www.blackpepper.co.uk Kent Beck: Smells smells are Common code smells

Duplicated code: identical or very similar code exists in more than one location.
Long method: a method, function, or procedure that has grown too large.
Large class: a class that has grown too large. Also a God object.
Feature envy: a class that uses methods of another class excessively.
Inappropriate intimacy: a class that has dependencies on implementation details of another class.
Refused bequest: a class that overrides a method of a base class in such a way that the contract of the base class is not honored by the derived class.
Lazy class / Freeloader: a class that does too little.
Contrived complexity: forced usage of overly complicated design patterns where simpler design would suffice.
Excessively long identifiers: in particular, the use of naming conventions to provide disambiguation that should be implicit in the software architecture.
Excessive use of literals: these should be coded as named constants, to improve readability and to avoid programming errors. Additionally, literals can and should be externalized into resource files/scripts where possible, to facilitate localization of software if it is intended to be deployed in different regions.
Full transcript