Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 6 years ago.
Improve this question
Where I work we've recently put together what we call the Development Standards Committee which is tasked with improving our procedures, processes, methodologies, tools, standards, and whatever we think would help us become a more effective team.
We've got a spreadsheet of items that we've ranked and are going to start tackling from the top down. We've got things such as better source control (currently on SourceSafe), implement a bug tracker (such as Mantis of FogBugz), peer code review, move to .Net 3.5, possibly move to some form of Agile, do more actual team development rather than single developer per project type stuff, and some other things...
What do you think are some key things that can make or break a development team? What should we add to this list?
Some additional information: We have about 12 people on our windows team, and about fifty in development if you include all platforms. We want to improve as much as possible for everyone, but we're our biggest focus is the Windows team. All of us have been here for a couple of years at least, so most of us know each other and work together pretty well.
The number of people on your team is actually really important here. There are basic things that every team should implement (source code control, bug tracking, etc), but there are things that are different base don team size. Code reviews on a very small team, for instance, can be more informal.
Moving to Agile is a good idea, unless you're particular development environment makes it a bad idea. Also, you'll not be able to do this without support from the people who are using your software.
Consider doing things to ensure that communication between the team is easier and with less roadblocks - do all your members know each other pretty well? Can you work with each other? Do you understand each other's idiosyncracies? Learning to work as a team is much more important than any random process improvements you can make.
Require comments when you check in code (it's great if you can tie commits back to your bug tracker)
Maybe Static Code analysis, like what's built into Visual Studio
Continuous Integration like CruiseControl
Development teams really need good people to start with, that work well together, but this isn't really an item to add to the list. It does however affect my first recommendation, be pragmatic. If you're not encouraging your developers to think about how they work and can drive them selves to improve, it's really hard to lay down a development environment that will do it for them.
Mentor and Training: If you can't do XP, then at least hook up your Juniors with Seniors whenever you can. Not only will you share knowledge but you'll share the context around your projects you own.
Some sort of Continous Integration and regular, tested, working "releases" make wonders for quality.
as better source control (currently on SourceSafe)
If this is Visual SourceSafe -- you need to change this immediately. Try cvs, svn or even something paid like Perforce.
There exists something called Rational Unified Process that deals with your problem (and much more).
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Does anyone know ways to use GML programming skills to find or make work, such as freelance work using Game Maker?
I was thinking of doing freelance game prototyping work for people looking for a quick mock-up and getting the feel for their game, that can be done within a week or a few days.
If anyone has an idea, could someone please help me out? Thank you.
Personally, I started out using GameMaker as a hobby, and I've worked on some small projects for other people, but I eventually got hired as a website and database programmer rather than as a game programmer.
Unless you find a team that is already using GameMaker for its project(s), your experience with GML may not count for much on its own, as the language is only useful inside GameMaker itself. However, understanding GML means that you also have basic programming skills, and once you know one way of programming it goes much quicker to learn another.
GameMaker made programming easy and interesting for me, but other languages gave me the tools needed for non-game projects.
A company may not hire you based on the fact that you know GameMaker specifically, but it may hire you because you know programming. It could be wise to research other programming languages and learn the basics of how they work.
If you are to sell your skills to a client, they will likely care more about the end result than the exact road you took to get there. For example, if the job is to make a game that works on Android phones, that is something GameMaker can do, and by extension it is something you could do.
If GameMaker doesn't seem like the tool for the job, use what you learned from GameMaker to help you understand a different program/framework. Even if you focus on GameMaker, you may need other languages if you are to set up an online game server or scoreboard.
A lot of successful games have been made with GameMaker, so it's definitely possible to make a living by using it. The Showcase section on the official homepage shows us games like Hotline Miami and Undertale - big hits in the Steam store.
This article from GameMakerBlog.com lists a few people who's made it big. Most important, I would say, is "True Valhalla", who gives the community running updates on how his business is going. You can find his blog linked in the article. He has written a book about how to make money by selling apps and games, which could be well worth checking out.
If you wish to focus on freelance work using GameMaker alone, then make sure to understand the ins and outs of the program so that you can be as flexible as possible. Make sure that you understand how the movement functions work, how to do collision checking, how to work with data structures, how to work with views and surfaces, and so on.
The technical skill doesn't need to be perfect, but you need to have an idea of what to do and how in order to realize your ideas within a reasonable time frame. Practice until you feel comfortable taking a game from concept to demo in a short time, and build a collection of examples and engines that could be useful to you. If you can reuse a script, that's a lot better than writing it from scratch for every new game you make.
Finally: Marketing yourself. In order to become attractive to potential clients, it helps to demonstrate your expertise by publishing your work online. Make yourself visible. Post screenshots, videos, and playable versions of games you've made. You could blog about game development, or build up a small profile by helping people online and getting credit for it.
Any project you can point to and say "I worked on this" makes you a more credible developer. If you are just starting out you may not have any projects yet, so one suggestion would be to make a small mini-game and publish it in an app store. You may even publish it for free. For your first games, exposure could be as valuable as sales.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I've been in the business of developing hardware and software for 19 years now. In the earlier days the projects and teams I worked on were smaller, much more effective and more fun.
The effect of the input of one single developer to the final product and to its success was evident to everybody. We had direct contact to and feedback from the customers. This was rewarding for our work and a very effective way to improve the product.
With the years the complexity of hard and software increases and more and more people were needed to get things done on time. The downside of the trend to bigger teams for me is that the contribution of a single developer to the project success gets smaller and smaller. And we lose the contact to real world of the users and customers because of growing QA departments more and more.
I always enjoyed my work and kept in touch with latest technologies like OOP, UML, .NET, and whatever. I already worked a few years as a team leader but I didn't like it very much because I missed developing and coding.
I'm just frustrated about the fact that my piece of the whole "thing" we're working on gets smaller and smaller and I lose the overview about it and the contact to the ground. Please don't understand me wrong, I don't want to cry for the good old days but for me the work on more and more specialized sub modules of a giant system simply gets more and more boring.
I'm wondering if I'm alone feeling like that and maybe if you have some advice how to bring the fun back to my work. And sorry, no, I'm not interested in working on an open source project in my free time. Nine hours a day in front of a computer screen are enough, life is more than coding...
I also require interaction with and feedback from the customer. However, a customer can be many things. As long as I'm satisfying someone (end user, team leader, big boss, etc.) then that's enough for me. The interaction itself is the key factor.
As for the feeling of pride and ownership from having a large impact on the system, again it's a matter of focus. You are still creating something, even if it's a smaller piece of the whole.
I long ago realized that I'm a small fish in a big pond. Learning to feel happy about my place in that pond was the only solution.
IOW, it's all relative!
I guess it all depends, there is a degree of camaraderie that comes with smaller teams and a lesser chance of ego's colliding. I have experienced both and they both have their upsides and downsides. To be honest, while working on a larger team I learned so much from other programmers, you think you know a lot, but someone always knows more.
It all depends on the team and the egos of the individuals.
When working on a team with ego problems, it doesn't matter how cool the technology is or how much interaction you get with the customers. One bad apple can drain all of the fun out of working on an otherwise cool project.
On the other hand, if the team has gelled, it matters very little if the technology is out-of-date, or the business problem is boring. Working on an back-office accounting system using VI and 10-year-old beta C++ compilers can still be invigorating when you feel like your peers are in the same fight and have your back. When you learn from others and are listened to when you have some new approach to try. When the developers control the build/test/deploy process so that it's sane and improves the lives (and sleep patterns) of the support team. When your peers (and you them) are always willing to help with an obscure language issue or work through a maddening bug. That what makes programming fun and interesting regardless of everything else.
You may want to consider changing companies back to a smaller company where you had a broader set of responsiblities, for one idea. Also, what are changes in the process that would help with the points you don't like?
I do have the question of what you mean by large here? Would a team of 50 people in a project be large? Or is it more like 1,000 to be large? On one level I'm asking for scale as there are teams beyond large if one wants to look at all the developers that work on Microsoft's big products like Office and Windows while at the other end of the spectrum are the one person development teams that do it all.
I'd second Kelly's answer that it depends on the team and egos for another big factor in things. What do you consider fun? Is it finding more efficient ways to solve problems that have poor solutions? Is it conquering a Millenium puzzle? Or is seeing someone smile while using your software what makes it fun? Lots of different possible answers and while I can make suggestions, how good or bad they are is totally for you to interpret.
I don't think you're alone in disliking how as a company matures the process can change as new people in various roles are added with increased bureaucracy and losing agility as it may take more signatures to get a change to be allowed or developers lose that touch to the customer of their product. There is a spectrum of various ways to produce software and some places may have less process in place and be focusing on "just make it work" while other places may want the process to be much more formal and organized with 1,001 policies for every little thing. At which end do you want to be working?
To answer the question as it's asked in the title: No!
I feel very similar and talked to many others who think the same. From my experience small teams are much more fun to work with and by that (and some other reasons) they're much more effective.
Thank you all for your interesting and valuable answers (and for correcting grammar and spelling :-)
You gave me some big points to think about:
The missing interaction with custumers (whatever "customer" means)
The interaction and feedback inside the developer team
What means fun for me. I think its more the smile in the face of the user than the use of cutting-edge technology.
How to deal with the sometimes overwhelming processes.
Last but not least to find my comfortable place in the big pond. It may be not the one where I'm staying at the moment...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
After investigating a little bit scrum and kanban, I finally read this answer and decided to start using kanban, picking something from scrum (note that I'm working mostly by myself, and I do have read this question and its answers).
Now, my question is: which tool would be best to get started?
whiteboard and postit
agilezen.com
JIRA with greenhopper
a spreadsheet (possibly on Google Docs)
brightgreenprojects.com
Agilo
Target Process
something else (please specify)
Notes about each:
I would lean towards the whiteboard, but there are several drawbacks (e.g. cannot make automatic charts, time measurements, metrics, and sometimes I work from home - where I need it most - and it's not convenient to carry :-)
I don't want to remember another username/password (I promised to myself to signup only to OpenID-enabled services)
My employer has JIRA but my group doesn't use it - I might ask for an account (it shouldn't require another password) and maybe later involve the rest of the group. But I don't know if they are using greenhopper and if it's a big deal installing it.
I generally hate spreadsheets
maybe overkill?
I'd be happy to have a localhost instance, but it could be problematic to give access to the whole group (per network/firewalls) - not a deal-breaker but surely a concern
What I'd like to get from this?
being more productive
tracking how much time I spend in any given task, possibly discussing the issue with my supervisor
tracking what "blocks" me most often
immediately see where I am compared to my schedule
manage in a better way my long todo list (e.g. answering faster to the "what I should do next?" question)
Do you have any suggestion?
Note on the scrumish tag: read the Henrik Kniberg's PDF. He first introduced the definition of scrumish on page 9.
If I may, I think that you are on the wrong path. Anything else than 1. or 4. is overkill and pretty much useless for a non distributed team. So for a team of one person...
Seriously, if you can avoid using a web based application, just do it. First, unless you are already mastering Scrum/Kaban, you need to learn the process, not a tool. Don't let a tool dictate the process. Then most web based tools are just too much click intensive, less easy and fast to update, less transparent/visible than a spreadsheet and a physical board. They are really 2nd category options.
So, I'd go for a spreadsheet and a physical board combo. If you need some charts (I'm still wondering what kind of chart/metrics you want to generate and what value they provide), a spreadsheet is the ideal tool (but honestly, you don't need any tool to draw a burndown). If you need to work from home, take the spreadsheet (or use google docs) and post its with you. Let's be objective, the impediments you mentioned are actually not real.
Last thing, if you had chosen the simplest thing that can possibly work, you would already be doing Scrum, Scrumban or whatever. So, instead of looking for a tool, my advice would be to just start doing it.
agilezen.com seems like the ideal solution for you. I have used it in the past solo for myself and it is convenient. I would not let a prejudice against non-OpenID sites get in the way of making a good choice.
pick the tool you already have, and start using it; don't let the absence of the "perfect tool" become an excuse not to start
EDIT: pick the simplest thing that can possibly work. In your case that would be whiteboard and postit notes. These have almost no setup overhead and will provide a constant visual reminder of what you're supposed to be doing.
And I suggest that you get used to making decisions on your own, as you're going to have to be your own Scrum Master ;-)
In the interests of diversity ;-) www.kanbantool.com has just launched too. It's open beta and seems at first glance even more "lightweight" than agilezen.
Target process is good too
We've been using JIRA with Greenhopper for a few months, in an effort to go agile. I use it for both Scrum for development, as well as for my personal kanban. The software is pretty flexible, and I'm going to keep with it. The story/subtask management is really handy, and it's fairly easy to use. One thing I like is that you can add stories/cards quickly, and can customize the data. This allowed me to add definition of done fields, work order numbers, etc.
In short, we're happy with it.
Bright Green have just launched a free version of their tool. It looks good .. the free version is fully functional too: https://signup.brightgreenprojects.com/plan/Free
I've tried out another kanban product for personal use and am absolutely loving this one. Feels lightweight and simple but actually packs in a fair amount of functionality at the same time.
www.kanbanery.com (free for personal use)
A novel tool not mentioned before is getsmartQ (out of beta since Dec 2010)
Key characteristics: very intuitive, supports LWP, customizable forms, and task discussions
Pros
configurable workflow, mark overdue stories, mail notifications (e.g., for upcoming story deadlines), multiple story owners
Stories form completely customizable, per project workflow and story forms, different roles (people only creating stories)
very responsive GUI with partial updates
Apparently good support: I've asked a question and got a good answer within a few hours
Cons
no easy way to declare something as blocked or to distinguish type (feature/bug/..)
no API
no subtasks or story dependencies
In comparison to Agilezen it has a more sophisticated notification system, but apart from that still lacks important features (see cons above).
Note, getsmartQ is under active development and hence missing features mentioned above may have been implemented in the meantime.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 months ago.
Improve this question
.NET 3.5, .NET 4.0, WPF, Silverlight, ASP.NET MVC - there's really a lot of new Microsoft technology released / on the horizon to try out these days.
(The examples I gave is all Microsoft technology but this can apply to any language or platform). I am curious how this is handled in the company you work for. A few examples:
Do you have a CTO that determines what technology the company uses?
Are development teams free to choose what technology they use? For example: framework version, classic ASP.NET vs ASP.NET MVC, ADO.NET Entity Framework vs Linq2Sql or NHibernate? Or a mix of these?
What new technologies does the company you work for try out and why?
Does your company have dedicated resources (time) to try out WPF or whatever technology, just for research, or do you try things out in your spare time and try to introduce them to your company?
These are just examples to make my question clearer. To summarize, I'd like to know what this process looks likes, who is responsible, who makes the decisions. Does your company jump on the bandwagon, or is it reluctant to try new technologies? And are you comfortable with this situation?
At the company I work for, we still use .NET 2.0 (although we are now slowly switching to .NET 3.5), haven't seriously looked into ASP.NET MVC, haven't tried out WPF at all, etcetera. And, some find it pretty hard to convince people to do. Is it fair to expect otherwise?
At my company, we have an architecture group that determines which technologies are used. People are welcome to read up on alternative technologies and make suggestions, but at the end of the day, it's the architecture group that makes the decisions.
While this may seem restrictive, it does ensure that all of the development groups are using the same or similar technologies, and moving from one group to the next is fairly easy. As well, by having one group do all the research, you ensure that you don't waste time by having multiple groups duplicate the research effort.
Since I work in such a small company and am I typically either the only developer, or the lead developer in a very small group, I can usually convince my boss to use whatever I think would be the best for a given project/situation.
We stick to what we know for our major and key projects within the company.
For any new "mini" projects that come along, we take the hit on the learning curve to try and build them in the latest technologies if at all possible.
This enables us to get up to speed on these things to then comfortably and safely use these technologies in our major projects as we see fit.
Where I work there is an architect team which looks at technologies from a high level and makes recommendations to various actual teams. A subset of the architect team actually takes the technologies and experiments on them and out of the produces
Internal 1 hour overview sessions
Week long boot camps
Whitepapers/Posters
The more important the technology is the more of that list is produced. All of that just feeds to teams, which combined with customer requirements for technology actually make the decision for what that team should use.
I have a mix answer to this question. Where I work, lower level technical managers are usually the ones that chose a certain technology and sometimes even the developers have the freedom to try something new. For example, I really wanted to learn about JavaScript's Prototype while working on a web site. I made the case to my boss, he was reluctant first because nobody else knew it or had used it before, but gave me the go ahead. It was great for me to be able to learn Prototype and take advantage of it's many built in functionality. Other bigger projects come down from higher management and we don't really have much of a choice. Right now, my company is adopting SAP, so everything is moving into that direction. I don't necessarily want to become an SAP expert, but if I want to stay here, I'll need to at least learn how to work with it.
Every company has its own pace for innovation, and it's dependent first on the comfort level of the managers, and second on whether anybody actually does the work to research and propose using new things. When the managers start getting uncomfortable, innovation slows or stops until they get comfortable again. Some innovations they will never be comfortable with.
Keeping this in mind, I'm not sure how to answer your question about whether or not it's fair to expect more innovation than is happening. Certainly it's reasonable for you to want more; equally, once you've hit your organization's speed limit on innovation, it's not likely to change and, if it does change, it will probably take a long, long time.
I've been given rather large amounts of freedom to change things by various managers in my past, and I took advantage of it. I also ran into the limits on a regular basis, and finally dealt with my frustration by starting my own company. (This may be considered a somewhat drastic measure; certainly by doing do you reduce the time you have to research and develop the very things for which you started your company.)
These days I'm developing rather significant applications in Haskell, and I'm pleased as punch. After a year, I'm starting to get the hang of it, and I certainly have several more years ahead of me just learning what I can do with the tools I have now.
I suppose the summary of my response is: if you want to innovate more than those around you, you need to change your peer group.
I think any company that tries new technology for the sake of it, as its bleeding edge and 'innovative' is crazy. To have a formal 'lets play with new technology to try it out department' is just nuts.... unless they're in the business of providing technology consulting to other businesses.
For everyone else technology is there to help the business get things done. Not to help developers line their CV's with cool sounding TLA's.
The company I'm working at the moment is quite large and has a CTO that chooses 'strategic platforms'. But I've have to say, if you can pick a technology, they're probably using it. They're too big to beat everyone down with the corporate stick, but they try. If the technology will work in the project and bring it in on time, then it gets used.
We need solid and proven platforms for our stuff. And, we don't need anything fancy. Therefore we might go for .NET after 5-10 years or so, hope it's ready by then. On the other hand, Java is already mature enough, so we're using it alongside with C++ and some Jython scripting. These decisions are pretty much autonomous (we're a small shop).
I don't mean to mock bleeding edge developers, but whether you need solidity or newest features obviously depends on what you're working on. Many scientists are still happily using Fortran 77.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
What software do you use to manage Scrum software development ?
We've tried Tackle and VersionOne (both free) so far and they are good except for the fact that it's difficult to track work in progress. For example, if I have a task that I estimate will take me 8 hours to complete, I've done 4 hours of work with 4 hours remaining, the task is always reported as 8 hours remaining until it is marked complete, at which time it falls to zero.
I'd like to use a tool that will allow me to take an accurate work at the teams WIP at the end of each week and see how much impact that work has had towards a deadline along with completed tasks.
Thanks for your input!
I recommend a white board and excel spreadsheets. The whiteboard has story cards (index cards) , where the work in progress is tracked. The story card starts out with say 8 hours, and as the work progresses decrement the number on the card. At the end of the day, put the numbers in the cards to a spreadsheet.
The whiteboard is visible all the time, and gives the whole team visibility on how the work is progressing.
This question was asked recently:.
Everything from Excel to VersionOne to Scrumworks to BaseCamp was mentioned.
Personally, though, we use a heavily customized Excel sheet, whiteboards, index cards in a variety of colors and a large corkboard.
You also might want to check out Mingle. It's a tool developed by ThoughtWorks, a company that only does Agile.
We've looked at most of the tools out there and ended up with Scrumwise. We've been using it for a while now, and it's incredibly easy to use, and does what we need. It uses the remaining time on each task to compute the burndown etc.
I note that no one has pointed out the misunderstanding of WIP (work in progress).
In agile, “it is not done until it is done”.
While most people see work done as a good thing, it is not. WIP represents investment that can not yet be realised. This is an important part of Agile, but made more explicit in Lean/Kanban.
If you track work done you will encourage developers to work on several things at once, getting everything to “80%” complete. At the end of the project you will spend 4 times more (80% of your time) in “bug fixing”, doing the last 20%. You will look like you are ahead of schedule, but you will over-run.
Also after one sprint, if work packages are small (they will be if you are doing scrum), then the error from not adding part done work to work done is insignificant.
Therefore: Track WIP separately from work done and try to keep it low.
Compromise
As a compromise, you can track part completed with the following rules:
Only track one task per developer. (probably the biggest)
Add a cap, maybe 1/2 sprint.
Discount the rate, maybe 50%, if it is 80% done then report 40%. (tweak the discount rate when you have evidence but don't let it be as high as 100%)
OnTime recently added support for Scrum management (disclaimer: I work for them and helped build the product). :) We also put together an intro video for Scrum if you need more information: Video.
I've been working on an open source web based tool that you can install on site or use our hosted version. We've got sub-task tracking and a real time planning poker feature.
http://www.scrumdo.com/
I was looking up SCRUM software and found this old topic - just my two cents ....
I worked on a project in a healthcare domain for about a year and we used Version One. I am sorry to say, it was perhaps the most despised tool in the project. The testers especially, loathed it. Neither did we developers like it as it was pretty clunky/slow and generally pretty lethargic. We always had excellent customer Support from V1 but the tool just didn't cut it for us.
I am now working in a different project and we are using www.scrumwise.com - and so far so good....
VersionOne does let you change the estimates as you go - the burndown report wouldn't work otherwise. You may be hiding the estimate column or have it set to read-only - click the spanner on the right to list available columns and make sure that the estimate/ToDo column is editable.
We've found it to be rather good, though their odd insistence on customised controls breaks in Chrome.
I would suggest checking out OnTime's Planning board because using excel and an actual white board takes away from actual development time when you can automate the process with software..
I answered a similar question at https://stackoverflow.com/a/16667842/1810290 and I thought of sharing it here as well.
If you are looking for an online scrum tool, then you could have a look at Flying Donut. It is a new online product, and I've used it in my projects with great deal of success. There is a nice way of organizing your backlog, and its GUI is clean with quick response times. It provides different iteration views for planning, execution, and review.
Disclaimer: I have been using it for many months, since I helped building it.
ScrumWorks is nice for small teams. And free, too, for the basic version. We have about 30 developers with multiple projects/iterations/etc. Some basic burn-down charts, good for "yesterday's weather", etc.
Check it out at:
http://danube.com/scrumworks/basic
I think RallyDev might be worth checking out for you. Unless I'm mistaken the way that it tracks time will not cause the issue that you mentioned above.
We have been using it on our project for several months and have grown with it to where the team enjoys using the project.
We use Scrum for Team System which is excellent, but you do need to be using Visual Studio Team System to get it!
I've used this Index card generator, but I see now that there is a newer version link that only uses Excel
I also like their Planning Poker when trying to get estimates.
Just saw this, maybe in a another stackO q/a, https://scrumy.com/demo
Check out Scrum Pig at http://www.bellacode.com. It is a great Windows tool for teams collaborating together when using Scrum.
We use RallyDev for scrum management system. And I found it very much handy.
No-one has mentioned JIRA, is that a cost/OpenSource thing?
I've used JIRA for the last 3 years and have found it to be an excellent tool.
We also use a physical board with a google spreadsheet that serves as an online replica. It works really well and doesn't really add any overhead if everyone gets in the habit of maintaining both. I've blogged about it and included a sample spreadsheet:
http://www.littlebluemonkey.com/blog/online-scrum-tools-part-1-the-scrum-board/
We have used XPlanner. It's simple, but does it's job pretty well. Especially Developers get a nice overview for their current status.