seems to be relatively recent (at least, newer than other agile methods) type of software project management that emerged from a card system at toyota. or, as this decent summary article claims, is more of an overlay on top of other agile methods. focuses on evolutionary improvement with minimal organizational resistance. https://leankitkanban.com/ seems to be one of the prominent sites, not sure if they claim to be originators. but they do offer free trials of online kanban boards if i decide to try it.
'people do not resist change, they resist being changed.'
1. Visualize: Make invisible knowledge work, and make its flow visible.
2. Limit work-in-progress: Implement a kanban system to pull work through from initial idea to finished and delivered.
3. Manage flow: Observe work items to see if they are proceeding at an expected rate.
4. Make management policies explicit: Agree upon and post policies about how work will be handled, including guidelines of risk, governance and priorities.
5. Improve collaboratively using “safe to fail” experiments: Adapt the process experimentally through collaborative agreement on observed problems and the use of models to suggest changes.
Friday, October 26, 2012
nuitka
http://www.nuitka.net/pages/overview.html
interesting project that generates c++ from python. not sure if it's ready for me to grab and use, without becoming a dev. but it's one to keep an eye on and file away with numba, shedskin, cython, py2exe, etc.
interesting project that generates c++ from python. not sure if it's ready for me to grab and use, without becoming a dev. but it's one to keep an eye on and file away with numba, shedskin, cython, py2exe, etc.
Tuesday, October 16, 2012
agile software development
by alistair cockburn, 2002, 005.1 COC
much more philosophical than other dev and planning books i've looked at recently, from a higher-level perspective. maybe relevant for a longer term because of this. i actually like a lot of the earlier chapters' discussion of things like how people think, communicate, and learn, and how habits and mental models affect performance, etc. i especially like the way he characterizes three stages of behavior in learning, based on shu-ha-ri (learn, detach, transcend) in aikido: following, detaching, and fluent. (see www.aikidofaq.com/essays/tin/shuhari.html) nice little snippets giving examples of successes and failures.
much more philosophical than other dev and planning books i've looked at recently, from a higher-level perspective. maybe relevant for a longer term because of this. i actually like a lot of the earlier chapters' discussion of things like how people think, communicate, and learn, and how habits and mental models affect performance, etc. i especially like the way he characterizes three stages of behavior in learning, based on shu-ha-ri (learn, detach, transcend) in aikido: following, detaching, and fluent. (see www.aikidofaq.com/essays/tin/shuhari.html) nice little snippets giving examples of successes and failures.
agile and iterative development: a manager's guide
by craig larman, 2004 (8th printing in 2007) 005.1 LAR
from the series edited by alistair cockburn of 'agile software development' fame. haven't read it, really, though it looks not to be written for in-depth reading. gives a high-level view of a number of agile techniques, including iterative & evolutionary, agile, scrum, extreme programming, unified process, and evo. some evidence for what works, lots of 'harvard business school' plots to give the gist of the ideas. looks like a good reference to cram with when a team needs to stay on course.
from the series edited by alistair cockburn of 'agile software development' fame. haven't read it, really, though it looks not to be written for in-depth reading. gives a high-level view of a number of agile techniques, including iterative & evolutionary, agile, scrum, extreme programming, unified process, and evo. some evidence for what works, lots of 'harvard business school' plots to give the gist of the ideas. looks like a good reference to cram with when a team needs to stay on course.
refactoring to patterns
by joshua kerievsky, 2005 (8th printing 2009) 005.16 KER
nice view on a more practical side of design patterns. instead of just looking at an ideal abstraction, this looks at how you refactor toward or away from a particular design pattern, or how you can migrate gradually between them. makes a good point that you rarely are making a dp from a blank slate; even if you are the head project architect, you can only do that at the beginning. once things are underway, or if you're working with an existing codebase, you have to refactor rather than design from scratch. handy tables in the inside covers as a quick reference. i read through chapter 4, to the beginning of the catalog of patterns.
i think i looked into buying this directly from the author's site, and i think you get a complementary ebook when you buy the hard copy.
nice view on a more practical side of design patterns. instead of just looking at an ideal abstraction, this looks at how you refactor toward or away from a particular design pattern, or how you can migrate gradually between them. makes a good point that you rarely are making a dp from a blank slate; even if you are the head project architect, you can only do that at the beginning. once things are underway, or if you're working with an existing codebase, you have to refactor rather than design from scratch. handy tables in the inside covers as a quick reference. i read through chapter 4, to the beginning of the catalog of patterns.
i think i looked into buying this directly from the author's site, and i think you get a complementary ebook when you buy the hard copy.
Subscribe to:
Posts (Atom)
Posts
