|
feedmegin posted:The places I've used it, it's basically a task tracker with (physical or virtual) cards. 'Here's what needs to be done on the left, here's what I'm working on right now in the middle, once it's done it goes over to the right in the 'done' column'. Mostly used during standups for discussing what you did yesterday/will do today. It actually works quite well, in my experience. Another quick summary of Kanban: you have a board with a series of columns in them, each representing a state that a task can be in. For example, "Ready for Development", "In Development", "Ready for QA", "In QA", "Ready to Demo", and "Complete". Tasks are represented by cards (or some equivalent). When you are ready to change a card from one state for another (for example, you as a developer are ready to start work on a new card), you pull the top card from the column and move it over. So, in that example, a developer is ready to start work. She pulls the top card from "Ready for Development" and moves it to "In Development". Then she works on it. When she thinks she's done, she moves the card to "Ready for QA". Then, whenever a QA person is available to do something, he pulls the top card from "Ready for QA" and moves it to "In QA". If it passes QA, it moves to "Ready to Demo", otherwise it gets rejected back to "Ready for Development". There are, of course, a million variants on this. You can limit the number of cards in any state, have various states, have "swim lanes", which are ways of grouping cards together as they march across the board, and so on. Handling defects vs. rejections can sometimes take discussion, but the QA involved would generally talk with the dev involved, and they would make a decision. One of the benefits of Kanban is that it is very visual. You can look at a Kanban board for your team and get a pretty good idea of what people are currently working on, and what is highest priority to do next (assuming somewhere along the line you have someone manage that priority). I'm sure it can be done poorly, but in my experience, it does a pretty good job of empowering a team to manage their work and avoiding bureaucratic overhead while getting things done. Some people get their panties wet over metrics you can supposedly gleam from it, but in my experience, developers usually couldn't care less.
|
#
¿
Oct 2, 2015 03:38
|
|
|
|
| # ¿ May 10, 2024 16:56 |
|
|
NovemberMike posted:That's not actually kanban. Kanban is about inventory management. ... Fair. I should have been more clear that I was discussing what's called Kanban in the software development world. Unfortunately, I don't have a particularly better term for it.
|
|
#
¿
Oct 2, 2015 14:56
|
|
|
spacebard posted:The way I've nipped this in the bud is to suggest (or ask if I'm the one having issues) to stick around after the stand-up to discuss them with whomever they need help from. It's worked really well to get some decisions made about technical approaches when you don't feel like bothering someone during the day directly. I've seen success with "can we discuss this after standup?" a lot. Though what tended to happen was we'd go through standup, everyone would say "We have a topic for post-standup discussion" and then after the 5 minute stand up, we'd all sit down in our chairs and talk for an hour about all our different issues 
|
|
#
¿
Feb 22, 2016 03:46
|
|