Agile Software Development

A general manifesto (Agile Manifesto) for "just-enough-process" Software Development methods.

Contra by Zed Shaw: http://programming-motherfucker.com/ We think the shit on the left, is really just the con in the middle, and that we really need to just do the thing on the right...Programming, Motherfucker.

http://www.martinfowler.com/articles/newMethodology.html

Good comparison of details of 4 agile methodologies. A Tour of Agile Software Development from Scrum to DSDM via XP and Crystal Orange.

Methodologies include:

See Jim Highsmith's Agile Software Development Ecosystems book which reviews the various Agile methodologies in depth, along with interviews with the appropriate gurus.

It's easier to follow agile practices with a Dynamic Language (Agile Programming Language).


Also title of book by Alistair Cockburn - WikiWikiWeb:TheBookAgileSoftwareDevelopment - which is mainly about his own ideas on Software Development As A Cooperative Game, plus Crystal Clear and other Crystal methodologies.)

Appendix B: Naur, Ehn, Musashi

Peter Naur and Pelle Ehn wrote the two most compelling and accurate accounts of software development I have yet seen. Neither is as well known as it needs to be, and Ehn’s book is out of print. I am happy, there- fore, to present extracts from their articles, for wider readership.

Peter Naur’s “Programming as Theory Building” neatly describes the mental activity of creating software and explains the “metaphor build- ing” activity in Extreme Programming (XP).

Pelle Ehn wrote the wonderful book Work-Oriented Design of Software Artifacts, in which he considers how Wittgenstein’s idea of language games informs our view of software development

Miyamoto Musashi, the 17th-century samurai champion, never wrote software. The competing schools of sword fighting in his day sound painfully like today’s schools of methodology. He admonishes people to avoid getting infatuated with tools and schools, to use different tools and strokes for different moments, and to just “cut off the opponent’s arm.” His admonitions apply directly to software development—if you realize that the opponent is the problem, not your office mate

  • PETER NAUR, PROGRAMMING AS THEORY BUILDING . . . 393
    • “Programming as Theory Building”. . . . . . . . . . . . . . . 393
    • Applying “Theory Building”. . . . . . . . . . . . . . . . . . . . . 405
  • PELLE EHN, WITTGENSTEIN’S LANGUAGE GAMES . . . . . 407
    • “On Participation and Skill” . . . . . . . . . . . . . . . . . . . . . 408
    • Reflections on Ehn’s Writing . . . . . . . . . . . . . . . . . . . . . 420
  • MUSASHI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
    • The Book of Five Rings. . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
    • Applying Musashi to Software Development. . . . . . . 423

Edited:    |       |    Search Twitter for discussion