Send the link below via email or IMCopy
Present to your audienceStart 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.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
Transcript of Agile Smells
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 email@example.com 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.