3 ms·

This is very insightful feedback. Thank you for that! One thing people tell us they like about Kitemaker is the ability to have a historical view of things. Be

by kevsim 4y ago

This is very insightful feedback. Thank you for that! One thing people tell us they like about Kitemaker is the ability to have a historical view of things. Because all of those extra edge cases that pop up get captured right in the same work item (and because we have an activity and history view on the work item), it becomes a pretty good place to explore the history of how you ended up where you did instead of a bunch of disconnected design docs and tasks in an issue tracker. Thank being said, your comment has my gears turning on how we could do an even better job of it.

ivan_gammel 4y ago
Well, having it on a work item is a "no go" for me, it is an approach that solves one job by sacrificing many others. As a scaler CTO, I always think about how this information can be discovered and used after the work is done, maybe in 2-3 years, in bigger and more structured team, by different people. Recording it with the work means that you can never be sure, that there's no overlap with some other unit of work elsewhere, which could have made some parts of spec obsolete or replaced. Finding connections to other cases recorded in other units of work is also difficult. For those reasons I always define requirements in a wiki or documentation management system, where you can look at all current requirements at glance and, if system supports versioning (it must), at all requirements at any given moment of time too (audit, incident investigation). From the requirements we can go into tasks and related code, if needed, but for product development it is more important to be able to see the full picture than when it was done. Implementation tickets just link the relevant parts of the spec, but never quote it or substitute it. Good referencing model of course helps to navigate in reverse direction too, enabling engineers to understand the context of certain parts of the code.

by kevsim 4y ago

ivan_gammel 4y ago

Well, having it on a work item is a "no go" for me, it is an approach that solves one job by sacrificing many others. As a scaler CTO, I always think about how this information can be discovered and used after the work is done, maybe in 2-3 years, in bigger and more structured team, by different people. Recording it with the work means that you can never be sure, that there's no overlap with some other unit of work elsewhere, which could have made some parts of spec obsolete or replaced. Finding connections to other cases recorded in other units of work is also difficult. For those reasons I always define requirements in a wiki or documentation management system, where you can look at all current requirements at glance and, if system supports versioning (it must), at all requirements at any given moment of time too (audit, incident investigation). From the requirements we can go into tasks and related code, if needed, but for product development it is more important to be able to see the full picture than when it was done. Implementation tickets just link the relevant parts of the spec, but never quote it or substitute it. Good referencing model of course helps to navigate in reverse direction too, enabling engineers to understand the context of certain parts of the code.