i started an opensource project, just for fun
it’s called band-aid, and it’s a tool for garage band that helps them preparing shows playlists choosing tracks among a registry and former shows.
i generated my last friday show playlist with it, it’s starting to work :)
it’s hosted @codeplex, you can find it here
tfs without data is useless.
collecting data from people is the real challenge, because providing data into an informative system is boring. there are two main approaches to how collect data: real-time (you say when you start a thing and when you finish it) or timesheet table (at the end of the day you say what you’ve done).
i decided to follow the real time way, so i needed something to track people work on assigned task, with the less effort possible.
this is how i came across TfsWorkingOn by Matthew Rowan:
http://www.codeplex.com/TFSWorkingOn
it’s an open source small system tray app that uses tfs SDK, which simply asks you every time “what are you doing?”, tracking down the time you spend on every task.
of course it’s more complex than this, and it have some nice advanced features (auto stop on pc idle time, link to tfs queries, etc)
it also features a pre made Excel spreadsheet to use as a BI cube for effort tracking, that covers all the basic needs you may have.
we’re actually using it since may 2009 and it worked pretty well (except for the fact that if you put your computer to sleep state without stopping the clock on a task it will continue the whole day)
thank you Matthew for your software
once you’re amazing system is up and running, and people has been persuaded to use it, you real work can start :). now you can get paid for all your work, retrieving data in a structured way, to take decisions and gain control on what happens (yes, all that fatigue for a such ’simple’ result).
to do that TFS provides you an entire data warehouse to mine. the datawareshouse is given in two flavour: an analysys service OLAP cube and a straight database.
the OLAP cube is more powerful (and a little bit complex to use), while the database is simpler. with both of them (or even the combination of them) you can do reporting services reports or whatever else you may need.
what about you workitem custom fields? that’s the core point: when you create a workitem there’s a field to decide if it goes to the datawarehous and on which one. this field is the Reportable one, and it has this possible values:
* none: the field will be not reported in the datawarehouse
* detail: the field will be exported to the sql datawarehouse only
* dimension: the filed will be exported to the sql datawh and to the cube as a dimension to perform queries
* measure: the field will be exported to the sql datawh and to the cube as a measure to count
be careful! once you decided the reportable field for a workitem custom field YOU CAN’T CHANGE IT! so plain it in advance!
keeping in mind this simple trick will let you get rid of any reporting need you may ever have
i’ve been pretty busy (see lazy) lately with, you know, life. this is why i neglected the blog, during the last months. I’m sure that all my gazilion fans got through this long blackout pretty well, but I promise i’ll come out with a new article within the next week. stay tuned (or stay quite far, if you prefer :) )
the question is: how could a developer, an helpdesk operator, a system administrator, a marketing operator, an accounting operator and Da Boss work with your shiny new TFS?
the answer is: the same way as everything happens, through explanations, bribing, intimidation and a lot of hard work :)
to be more precise, the core point is that all the people involved in the production cycle has different roles (obviously), different minds, different skills and tools and, lastly, different leverages to use on them too :)
as we know TFS has several way to access its data (Visual Studio integration, web access, excel and project integration, and easy-to-use API for access workitem from your own software [yes, i’ll talk about that too, in a further post]), but choose the right one for every person in your organization is a real pain in the ass: everyone has his point of view and needs, so how decide? is better a uniform platform for everybody or let everybody choose?
in my opinion the main thing to understand is: are the user smart enough to appreciate the different approaches you’re offering? if the answer is no, then let them use the portal (or another way) and prepare yourself for a lot of problems and complaints, but consider that you would had complaints and problems anyway, because the problem is not in the tool, but in the the people. sad but true.
i’ve been luck enough to have TFS delivered to a somewhat skilled audience, so i chose the choose-the-way-you-prefer approach, and I must say it worked pretty good. among helpdesk people, some use the portal, some Excel, project admins use a combination of excel/project and portal, sales people prefer spreadhseets, and so on. obviously you must tailor this configuration around the process of life cycle you’ve built [yes, i’ll talk about that too, sooner or later].
the main hint i can give is: don’t categorize, talk person per person. if your idea is to assign to each division the same tool to use, then perhaps is better to adopt the same for everybody, because you’re gonna loose that feature of freedom of use that is so strong into TFS. what i found is that people itself will choose (unbelievably for the best) its own tool, and you will reach almost the same result (each division with a tool) naturally, not by imposing it, but because that tool is the best to use for the job to accomplish.
if you let them choose and believe in them, they’ll be more happy and they’ll be forced to understand the process they’re into, that will result in a better work environment.
after this unbelievable i-believe-in-users post, i’m gonna take the blue cinism pill and return to the day-to-day work.. see you next time
