Lunch and Learn I did on some general Agile and other practices that can make developers more productive.
Most of the content was in the speech though unfortunately.
2. Traditional Big „A‟ Agile
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
3. Traditional Big „A‟ Agile
Agile Modeling
Agile Unified Process (AUP)
Dynamic Systems Development Method (DSDM)
Essential Unified Process (EssUP)
Extreme Programming (XP)
Feature Driven Development (FDD)
Open Unified Process (OpenUP)
Scrum
Velocity tracking
6. Little „a‟ agile
1. Can you react immediately and without
panic if external constraints on your
project change?
2. Do you review your process frequently
and regularly to make sure the answer to
the first question is always yes?
7. How can we do this in
waterfall or constrained
environments?
14. What Git is about
1. Use CVS as an example of what NOT to
do.
2. Support a distributed workflow
3. Strong safeguards against corruption,
PEBKAC or malicious
4. High Performance
Horse: http://www.flickr.com/photos/cristic/265149677/ CC Attribution 2.0 Generic (CC BY 2.0)Bunny: http://squeak.preeminent.org/orgBlog/C244531379/E20051003220643/Media/trojanBunny.jpg Fair Use
http://lostechies.com/wp-content/uploads/2011/03/pablos_solid_ebook.pdfSingle responsibility principlethe notion that an object should have only a single responsibility.Open/closed principlethe notion that “software entities … should be open for extension, but closed for modification”.Liskov substitution principlethe notion that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”. See also design by contract.Interface segregation principlethe notion that “many client specific interfaces are better than one general purpose interface.”Dependency inversion principlethe notion that one should “Depend upon Abstractions. Do not depend upon concretions.”Dependency injection is one method of following this principle.
PIE – Program Intently and ExpressivelyBaby Steps – Don’t try to do the whole thing in once giant leap, cut off small pieces, work on them, test them, rinse, repeat. Keep this cycle tight so you know exactly when/where you messed something up.KISS – Don’t build a space shuttle, a bottle rocket would probably do.YAGNI – THROW AWAY CODE IF ITS COMMENTED OUT OR NOT IN USEDRY – Smack yourself if you copy paste code more than once. Move to method is great here, start with procedural then move to more genericized code.Boy Scout Rule – Leave it cleaner than you found it – renaming variables helps muchoGood Neighbor Rule – Cut your grass, make tests, automate things so you don’t leave a mess for your coworkers.
http://en.wikipedia.org/wiki/Git_(software)
Explain story with flaky VPN.Don’t have to be connected to the server to branch, merge, swap changes with coworkers.http://nvie.com/posts/a-successful-git-branching-model/- creative commons