Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Mike Bria on Jun 03, 2008
I'm now convinced that if we want things to change, we have to think about scaling down our tools and techniques to fit novices' heads. In particular, any tool that can't be learned in a one-hour tutorial, or that doesn't pay its way in the first assignment it's used on, [is likely to be tossed aside and largely ignored by most students].Wilson concludes his initial post with his thoughts on requirements for a tool to be suitable for students:
The early responses consist of an interesting, but somewhat tangent, conversation triggered by Ward Cunningham, expert in (among others) the XP and Automated Testing Tools communities. In it Ward poses a polite but pointed challenge to Wilson's apparent motive:
- Must be comprehensible to a second-year Computer Science major who's running a C+ average after a one-hour tutorial.
- Must make students who are time-slicing assignments from four or five courses more productive within one month of adoption (i.e., after five to ten hours of use spread over two weeks).
- Must be platform-neutral (some courses uses Java, others use Python or C, and of course there's the Windows/Linux/Mac issue).
- Must be useful in courses other than the one where it's taught (i.e., databases, compilers, graphics, etc.). This is actually our measure of success: after introducing version control in second year, we see a lot of students setting it up and using it in third- and fourth-year courses without being told to.
- Must be (relatively) process neutral: I believe a good solution would be as usable in RUP as in XP (just as version control and unit testing are).
I'm not sure product-quality code should be the goal of an undergraduate education.In essence, while it appears Ward does not oppose Wilson's efforts to improve student's ability to come out of school with a more solid grasp of the tools and technique's used by professional Agile practitioners, he sees this not necessarily as a great contributor to improving student's appreciation for "product-quality software". To gain that, Ward asserts, takes experience with real products.
...
[As an undergraduate student,] I was on to two streams of knowledge: lots of big organizing ideas from my professors, and lots of handy technique from my own exploration. There was still a third stream, product-quality, that I had yet to tap.
Case Study: IBM's Agile Transformation
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
The problem is that automated FUNCTIONAL level testing is not a clear "win" in all situations. It's not a slam dunk that this is the right thing to do on a project. And I say this as a veteran of many agile projects. Automated UNIT testing, yes. Automated functional testing, nope.
To me, testing is mostly about economics. Complete testing is usually economically unrealistic for most projects. Fortunately, it's also not usually necessary. Automated testing has a much larger up front cost than manual testing and you have to think carefully about your ability to see a return on investment in the long term before simply jumping in.
I would settle for undergrads being exposed to unit testing and testing techniques in general. Forget about automation, just teach new programmers how to test. Once that is learned moving to automation, if feasible, should be relatively easy.
Seriously. If the goal is to learn, then the best "lean"
tool for the job is an editor with syntax highlighting for the language in question. Some of the macros and automation can be added on with the modern variations and adaptations (e.g. GVIM, XEmacs). As the Pragmatic Programmer guys suggest, pick an editor and learn it well. IDE's can be a crutch that removes you from the development process if handed to developers who are still trying to learn a language and platform. While they're great for developers who already have gone though the process of learning and understanding the language statically and at runtime, they tend to obscure too much of what's going on and some aspects of a language may end up being "that magic the IDE does for me".
Being 10 years out of school, I'd have to say: "Here's a nickel, kid. Go download yourself a free programming editor";)
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
2 comments
Watch Thread Reply