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.
Friday, September 7, 2012
presenting science: a practical guide to giving a good talk
by cigdem issever (+unicode goodies...) and ken peach
decent book with pointers about what makes a good (and bad) presentation.
some tips:
produce a written set of notes for each slide -- you can give this to someone who couldn't attend, as well as use it for preparation and reference while speaking.
provide a link on the title slide to a paper or papers covering more detail.
the speaker is responsible for everything that appears, and does not appear, on each slide.
the structure and appearance of the presentation, as well as the content, are part of the communication process.
scoping
knowing your audience tells you where you start, and knowing your conclusions tells you where you finish.
find out who the audience is, why they might be interested, and exactly how much time you have.
then write the conclusions slide -- why are you giving the talk, what is the message, and what do you want them to do or change once they've heard you?
now write the contents slide, to map the route that takes the audience from their start to your finish.
writing process
can go beginning to end, or maybe end to beginning.
or, start with the key slide ('money slide') and go forward and backward from there.
like goodlad said, you need to tell them what they need to hear, not what you want to say.
decent book with pointers about what makes a good (and bad) presentation.
some tips:
produce a written set of notes for each slide -- you can give this to someone who couldn't attend, as well as use it for preparation and reference while speaking.
provide a link on the title slide to a paper or papers covering more detail.
the speaker is responsible for everything that appears, and does not appear, on each slide.
the structure and appearance of the presentation, as well as the content, are part of the communication process.
scoping
knowing your audience tells you where you start, and knowing your conclusions tells you where you finish.
find out who the audience is, why they might be interested, and exactly how much time you have.
then write the conclusions slide -- why are you giving the talk, what is the message, and what do you want them to do or change once they've heard you?
now write the contents slide, to map the route that takes the audience from their start to your finish.
writing process
can go beginning to end, or maybe end to beginning.
or, start with the key slide ('money slide') and go forward and backward from there.
like goodlad said, you need to tell them what they need to hear, not what you want to say.
Saturday, September 1, 2012
kindle hacking
nice links for cracking into those spare kindles:
http://www.youtube.com/watch?feature=endscreen&NR=1&v=uWvbaN-3q6I
http://www.mobileread.com/forums/showthread.php?p=1873256
http://www.youtube.com/watch?v=sNFXPDtg0xo
http://www.turnkeylinux.org/blog/kindle-root
http://www.mobileread.com/forums/showthread.php?t=128704
http://www.mobileread.com/forums/showthread.php?t=97745
http://wiki.mobileread.com/wiki/Kindle_Touch_Hacking
http://www.mobileread.mobi/forums/showthread.php?t=185837
http://www.youtube.com/watch?feature=endscreen&NR=1&v=uWvbaN-3q6I
http://www.mobileread.com/forums/showthread.php?p=1873256
http://www.youtube.com/watch?v=sNFXPDtg0xo
http://www.turnkeylinux.org/blog/kindle-root
http://www.mobileread.com/forums/showthread.php?t=128704
http://www.mobileread.com/forums/showthread.php?t=97745
http://wiki.mobileread.com/wiki/Kindle_Touch_Hacking
http://www.mobileread.mobi/forums/showthread.php?t=185837
Subscribe to:
Posts (Atom)
Posts
