3 ms·

The fun comes in separating the project in one-man-sized blocks (which won't be the same size). Indeed, you can track progress by seeing how many features are

The fun comes in separating the project in one-man-sized blocks (which won't be the same size). Indeed, you can track progress by seeing how many features are coming along, but I believe you can't predict a delivery date accurately because of the variance - but you can give a ballpark estimate (days, weeks, months, years, age of the universe). Agree with giving each developer a separate brick, but on the Kanban approach I was recently introduced to, if someone is stuck, the idea is to "swarm" him and help him/her.

raganwald 15y ago
There’s something subtle but important your comment raises. Feature are not bricks! The brick metaphor is about assigning chunks of implementation that have a possibly many to many relationship with units of business value (call them features). Dividing up a project by feature and/or tracking progress on a project by feature is very different from tracking project by brick.
- nodemaker 15y ago
  Yes I forgot to point that out.....The blocks are not directly related to individual features....For example one block can deal with Network Requests and it can use another smaller block to cache data....One block for managing thread pools. But I guess one could create a mapping between the set of blocks and the set of features.A feature then would be complete when all its mapped blocks satisfy their test cases.But I am yet to see a project management system based on this approach.
- GFischer 15y ago
  Sorry, what I had in mind was the Work Breakdown Structure advocated in the "traditional" (PMI/Pmbok), and the lowest divisions as "bricks", or the agile approach of separating a project into User Stories. http://en.wikipedia.org/wiki/Work_breakdown_structure http://en.wikipedia.org/wiki/Work_breakdown_structure http://en.wikipedia.org/wiki/User_story http://en.wikipedia.org/wiki/User_story It's not what you were talking about. Your points at the end of the article are pretty similar to what I was taught in a short agile project management seminar this week, if it helps :)
deleted 15y ago
[deleted]

raganwald 15y ago

There’s something subtle but important your comment raises. Feature are not bricks! The brick metaphor is about assigning chunks of implementation that have a possibly many to many relationship with units of business value (call them features). Dividing up a project by feature and/or tracking progress on a project by feature is very different from tracking project by brick.

nodemaker 15y ago
Yes I forgot to point that out.....The blocks are not directly related to individual features....For example one block can deal with Network Requests and it can use another smaller block to cache data....One block for managing thread pools. But I guess one could create a mapping between the set of blocks and the set of features.A feature then would be complete when all its mapped blocks satisfy their test cases.But I am yet to see a project management system based on this approach.
GFischer 15y ago
Sorry, what I had in mind was the Work Breakdown Structure advocated in the "traditional" (PMI/Pmbok), and the lowest divisions as "bricks", or the agile approach of separating a project into User Stories. http://en.wikipedia.org/wiki/Work_breakdown_structure http://en.wikipedia.org/wiki/Work_breakdown_structure http://en.wikipedia.org/wiki/User_story http://en.wikipedia.org/wiki/User_story It's not what you were talking about. Your points at the end of the article are pretty similar to what I was taught in a short agile project management seminar this week, if it helps :)

deleted 15y ago

[deleted]