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 11 years ago.
I recently started using "Jira" with the "GreenHopper" plugin. However, I don't feel like this is really doing what I want. I saw a cool feature in "Scrumworks pro" where you can run the app as a desktop application. My requirements therefore include things like:
Must have a really easy UI for managing scrum tasks
Must preferably have a desktop version that plugs into web version
It DOES NOT have to be free, just as long as it rocks!
It must NOT be a butchered app, but rather something specifically designed for Scrum, with a good development team.
It would also be an extra plus if it can integrate with Subversion somehow.
It would ne another extra plus if the sprints could send summaries to business owners of the work that was completed. I.e. Custom reports.
Any suggestions?
You could try IBM Rational Team Concert.
Easy UI: Very, especially the Eclipse version.
Desktop: You can use web, VS add-in, or eclipse version, by team member preference. Like I said, I recommend Eclipse (but haven't really seen the VS add-in)
Price: I believe it's free up to 10 developers, then it's IBM pricing schemas. But if that's not an issue...
(non-)Butchered app: It's IBM, so it's not a hack; and it's built on Jazz, so there's some extra developer community juice there. While it's supposed to be able to support both traditional and Agile, in my experience it's strongest for Scrum. Also, the configuration is highly customizable.
SVN integration: While there's no official bridge for this, I'm pretty sure it's been done before (e.g. by Clearvision), and can be done again if need be. Also, RTC comes with its own SCM system - I don't know if that would work well enough for you to replace SVN altogether, but it might.
Reports: Lots of (somewhat) customizable dashboards and charts. If there's a way for it to send automated reports, I haven't seen it yet.
All in all this sounds fairly close to what you were describing.
EDIT: By popular demand, some screenshots... From my actual Production environment. This is going to be long.
This is the Work Breakdown view of my current sprint. You can see that you have user stories, tasks, you can have defects, ARs, risks, impediments, what have you. It's actually customizable so you can add additional object types, each with its own properties and state machine.
Each of the properties you see can be changed from this view - so it's very easy to just add a new task under a story, set its estimate and a brief title, and you're good to go. All in all maybe 10 seconds for creating a new task. Ctrl+S commits your changes (takes ~1-2s).
In fact, I almost never have to leave this screen during a sprint. You can assign work to someone by making the item under their name, dragging an existing item under their name, or right click -> assign to Owner -> their name. You can change states and set time spent (or time left, the view is customizable) from this screen as well.
Occasionally you want to open an item for individual editing, which you can do by right clicking any object. That opens it in a new tab.
You can see that each individual team member as well as the team as a whole has a work done vs. expected. This is based on the release dates I've set for the sprints and total work estimated. If you're doing Scrum correctly, then by the second-third day you've already assigned each story the vast majority of its tasks. You get a handy meter for how many items you have unestimated. In fact, you can even filter out estimated items so you can focus on estimating the remaining ones (which again is two clicks).
P.S. My teammates don't necessarily have good task breakdowns / estimates here. But you get the idea.
The views you can have are many, and can be customized. So if you like a sticky board for your tasks, you have...
I don't actually use this a lot, but it's there. You can either view it by bunched groups of in progress, resolved etc. (like the screenshot) which is good for viewing several different object types; or you can do it by a specific object type's state machine (so for defects you could have Resolved, WNF, etc.)
Speaking of defects, this can integrate with ClearQuest (though it's got bad limitations if you're using multi-site solution for CQ). I don't know if I'd let RTC completely replace a different defect tracking system, but you conceivably could.
BTW the taskboard is intuitive in the sense that you can drag a task from one state to the other and it would update its state, assuming that the state transition is allowed by the state machine you determined.
More views are possible. Another filter I use during sprint planning is "Execution items", which leaves me only the stories and epics - no clutter under them.
Speaking of "under them", you could have other types of relationships than parent-child, such as "related" or "blocking". To do those though I think you have to go into the specific object. Parent-child can be done that way too, but usually you just drag objects on to one another.
I'll add here a couple of side panel screenshots and then I think I'm done... Because you should get the idea.
Team Artifacts panel lets you browse the relevant objects. Generally for Scrum management that would be Plans, which is where you keep all your work items. The "Work Items" item actually a bit misleading in that regard, it lets you do queries (e.g. "Open assigned to me"), which then appear in a bottom panel. I personally prefer using the plans.
You can also see builds, source control in there - for some teams they are indispensable, for others (like mine) they aren't really used.
Last screenshot...
Actually got three areas in the Team Dashboard (four with "Builds" not presented here, which I don't use). "My Open Items" can actually display any query, by any order. This one uses priority. Hovering on any of these displays the relevant items (takes 0.5-1s to think about it), with F2 enlarging the tooltip. Clicking any of these columns retrieves the items for the bottom panel.
Event Log is what you'd expect, stuff your team has been doing. Likewise easy to expand, clicking on an item opens the corresponding work item in a new tab.
Then there's Team Load, which compares estimated assigned items to each team member's expected hours left to work in the iteration, as well as total. This draws from individual setting of work hours and planned absences (alas, absences don't seem to support any half-day scheduling, only full days).
By complete happenstance, I have one team member with no load, one with load exactly matching their expected hours, and one who apparently chewed more than he could swallow. Of course, he just needs to update his tasks, though in this particular case he really is overworked. This dashboard lets a Scrum Master identify this sort of situation quickly and try to resolve it before it's too late.
(Don't ask why that didn't happen in this case).
Performance is also surprisingly good. I'm not sure what they did in their architecture, but it's a lot smoother than other enterprise solutions I've used. By far.
Maybe I should make it clear that I'm not in any way affiliated with IBM, Jazz, RTC etc. I just think the tool is pretty nifty. I'm not yet done exploring it, actually, but for Scrum it seems pretty darn good and I'm happy to spread the word :)
Is this what you are looking for?
P.S. There are a ton of Agile tools out there, you could continue to look around. But if JIRA wasn't good enough for you, then that probably disqualifies maybe 90% of what's out there which is worse (e.g. Rally).
Pivotal Tracker: http://www.pivotaltracker.com/
No desktop version, but it pretty much rocks. Has many integrations and third-party tools.
VersionOne is very good. Free up to 10 users, nice web interface and rich plugin base.
We have been using Assembla (www.assembla.com) for more than a year. It is not free and does not have a desktop version but it definitely rocks.
Some things I love:
The UI is clean and simple being suitable for developers and business owners alike.
Tasks and commits are integrated from SVN and Github so it makes it easy to track code changes relating to tasks.
The Cardwall/Kanban tool is excellent at quickly tracking tasks.
It is being developed constantly with new features like code review and enhanced cardwall features.
I can't compare it functionality to all of the solutions out there but I can tell you that it works fine for our team, is much better than what our partners use and clients are happy with it.
As a Scrum Practitioner for 8 years and user of most of the above mentioned tool, I recommend nothing better than a simple white board and concentrate on your process.
But if you have to use a tool especially for distributed teams...
I recommend ScrumDo.com Fast, Easy to use.
Nice Kanban board, integrated planning poker, intuitive story management with drag-drop, great for distributed teams.
Also we like the easy source code and time management integrations.
The prices scale very well with our growing teams.
Also the open source version helps out security minded team to install within the firewall.
Scrumdo is highly recommended. Agile Project management made so easy. I am hoping that all the teams in our company will use Scrumdo!
Try AgileWrap. I am sure you would like it.
It has clean, lean and easy-to-use interface for managing scurm user stories, tasks, defects, iterations, releases and backlogs.
Integrates with Subversion and Gits. Has API/Web services.
Free for 5 users team. Very affordable for larger size teams. You can use on-demand or on-premise whatever suits your needs. It does not come in desktop version though.
You can create custom reports as well as use many standard charts - velocity graph, burn-down, burn-up, story cumulative flow etc.
Definitely take a look at OnTime by Axosoft. It fits your wish list to a tee, including Subversion integration (if you're using Visual Studio), desktop and web clients, etc. I've used OnTime for the last five years and highly recommend it.
Best of all, their site has tons of information so I don't have to spend an evening creating screenshots to match Polymeron's answer.
Related
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 5 years ago.
Improve this question
I have been trying to get our software department to adopt some kind development process methodolgy. We only have 9 developers, and about as many projects. Currently, we can only be described as chaotic. Or perhaps 'crisis driven development' as I've seen another SO user call it.
Using Kanban seems like a it could be a good fit for us. So I've discussed it with everyone else, everyone thought it sounded good. But when we discussed how the board(s) should be arranged, everyone wanted to do one board per person.
Now, I've never tried Kanban, or any methodology really, but it feels like having each person managed on their own board would negate the benefits a Kanban process is supposed to provide. This notion makes me sad, and want to say 'ho-hum let's scrap this whole idea.'
Do you think implementing a Kanban board per developer can be worthwhile?
If you must have a multitude of boards, wouldn't it be better to have a board per project rather than a board per developer ? Maybe in time some natural groupings of projects (and therefore consolidation of boards) will emerge, maybe not.
One purpose of the boards is to serve as "information radiators". A large number of project boards progressing at a snail's pace broadcasts the message "we are seriously overloaded" and/or "someone needs to set some priorities". A large number of per-developer boards just radiates the message "we don't do teamwork around here".
Kanban is actually as system for restricting flow through a system, which is why we have WIP (Work In Progress) limits on kanban boards, and as a person can do only one job at once I don't think this could work.
Having one board per developer really doesn't give any advantages (And I'd argue it's not really kanban). One board per project is a better idea.
Then if another developer joins in for some tasks you can still see the overall progress of the project.
I think it might be worthwhile to have another discussion with your group. Before adopting any kind of new technique/practice/methodology, one should be very eyes-open about why you want to adopt it, and what problem you're trying to solve. It almost sounds to me that you've stumbled upon Kanban Boards and want to adopt it without really knowing what problems you're tryying to solve.
My advice would be to try do some more thinking or analysis on the problems you see in your environment, do some root-cause analysis if you can (something like the 5-whys), and then try find some practice that will help you solve those problems.
The very fact that people in your group suggested using a board-per-developer implies to me that a. they don't understand the kind of problems they have, and that you're trying to solve, and b. they don't understand what Kanban boards are trying to achieve. I.e., your problems are such that using Kanban boards will not solve them.
It's not wrong to have a board per developer. The board is there to visualize the work. If the developers work on different projects, then it would be easier to visualize project-specific work with separate boards (which is usually the case). If your developers work on separate projects, then they work on separate projects. Technically, they're not really a single team, but more of a "practice". From that perspective, it might be a more natural approach to have them working separate boards.
When I work on personal projects on my own I still use a Heijunka Box - what software developers in the west often (mistakenly) call a "Kanban Board" - and I do this to visualize work, work scheduling, and to help limit the number of things I'm working on at once.
I've implemented Kanban for my team which does Operations Automation (more or less half Ops work and half Dev work). Here's what we found worked best for our team. We have a common column for INBOX/Backlog.. Then a 'in development' column broken down into 5 sections, one per developer, with a per-developer WIP Limit. Then another common column for 'to integrate', and finally a common column for 'release to production'.
The advantage of Kanban is that the WIP limit ensures developers can focus on what they are doing - in our case each developer is fairly autonomous in working on their project, but we have the common columns for INBOX where a developer can pull any new task, and for 'integration' / 'production' where the team-lead is involved in shepherding the change through the remaining steps.
So my recommendation is to have some common columns (perhaps your backlog and your release) and have some columns that are per developer (like 'in development'). That way each developer can manage what they are working on, and at the same time the board can help visualize the state of all work that is flowing through the pipeline.
The two most important reasons to apply Kanban to a process is to visualize that process and limit work in progress (WIP).
If you have one board per developer it's more of a personal kanban mechanism, and you get to visualize and limit WIP for one person at a time, but no overview at team level.
If you have one board per project or team it depends if there's shared resources, i.e., people working on more than one project or team. If so, you loose some overview and some of the benefits from limiting WIP if you have people working on stuff shown on more than one board. F.ex. bottlenecks are harder to see.
My feeling is that it might be better to use one Kanban board, with all the developer tasks on it, rather then one board per developer. Reason I think this is because the idea is that Kanban is a visual tool for all team members, and if each dev has their own board, then I think it misses the idea a bit.
Subnote
If you're using Microsoft TFS, then you could use use Telerik Work Item Manager. I've used this myself and it's great. Each developer runs a copy of the tool on their PC, and they can view their work items on a visual task board (with colour post-it's). This board can grouped and filtered by various ways, so a developer can see all their own tasks, but then they can change the filter to view all the tasks on the project.
(If you're not using TFS, apologies for the uninteresting subnote :)
Indeed, create at least 2 or 3 teams, affect only one project to each of them and so one board by project. Then an another board to manage projects status.
To resume: One by project with every tasks, one to follow project status it will help the developers and also you to communicate with the managers.
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 5 years ago.
Improve this question
For those of you who have implemented Scrum in your organizations, what were your biggest obstacles and if you did overcome them, how?
Background: In 2006 I contracted with a large company which had adopted Scrum cold turkey just months before I arrived. The company hoped Agile/Scrum would save their huge enterprise software product. Of the hundred or more programmers there, I worked closely with a team of about a dozen for a year, observing and participating in their Agile experiment.
Summary: I believe Agile helped more than it hurt. By the end of the year, the team could consistently estimate and produce features, whereas previously their productivity was rather erratic.
Implementation: Since this was a large organization and a large product, the project ran as a "scrum of scrums." There was one scrum master for about every 15-20 developers and these teams were often divided into smaller, closely working scrums of about 6-8 people for an iteration. Teams were largely independent, could adjust their own iteration frequency (1 month down to 1 week) and were given lots of flexibility to implement agile as they saw best. The company regularly brought in Agile coaches (such as Object Mentor) to help train the scrum masters, teams, and management.
Obstacles: Plenty. Some of them related to Agile, some not. In no particular order, here are some lessons learned:
The product backlog was revised way too often in the beginning. Eventually, the team and management took several days to go over all the features, estimate them, and prioritize them. It was a big hit, but it helped tremendously. Lesson learned: get your product backlog in order early and keep it maintained. Product owners must have a clear idea of what they want.
We lost time experimenting and dealing with fads and hype. When you start, you have no way of knowing if you're doing things correctly. There's temptation to constantly fiddle with the agile process taking the focus away from the product. Lesson learned: having an experienced Agile coach does help reduce this learning curve. There should always be someone pushing back on any experimentation. Limit the number of "spikes".
A good scrum master is invaluable. Certainly in the beginning, it's a full-time position.
It takes time. It took several months before the team started to be comfortable with the process.
Pick your battles. Some programmers will be understandably skeptical and others will outright dislike and flight the change. Allow for some flexibility. For example, enforce the use of a product backlog and iteration schedule, but don't require everyone use note cards. Be particularly sensitive to introducing tools and programming methodologies such as pair programming or test first development.
Finally, keep communication open and manage expectations.
Good luck!
While working as a Delphi developer a few years ago, I managed to get Scrum adopted by my development team for a time.
The whole process worked very well for us - having the team estimate prioritized tasks on a backlog gave us meaningful timeframes to target, and the whole "Managements job is to remove impediments" was great.
The biggest problem was that the process was always perceived - and referred to - as "Bevan's good idea".
While the team appreciated the value we gained, and were happy to continue with Scrum, the Team didn't take the scrum methodology on board as their own. After a while, I got tired of "pushing" and we "fell out" of following the Scrum approach.
Lesson: Make sure the team takes Scrum on board and owns the approach.
We do mostly scrum projects at the customer site. Hardest part in my experience is finding a good product owner in the customer organization:
Too many people think they should be the product owner,
The product owner has a hard time following the pace of the team
Product owner has a hard time getting all the detailed information the team needs
Moving items down the product backlog to add something with a higher priority is difficult
etc.
Training internal teams to use scrums is doable, bringing in your own scrum master is doable, but a good product owner should be part of the client organization. It's harder to train this external person.
Having a proxy product owner, who works together with the customer product owner does help a lot.
I moved from a company that adopted Agile to the tee to another company which follows the traditional methodologies.
Perhaps the biggest difference I have seen is that the second company struggles to prioritize. There is so much work on each person's plate that they fail to deliver on time. IMO, Agile brings about some transparency to the situation and lets the team as a whole prioritize.
A scrum master in the Agile world would take care of fire-fighting and be the voice of the (sprint) team. In fact, in the first company (where we had a separate scrum master and program manager), the scrum master would fight it out with the program manager when the latter makes false promises to the management. Meaning, the scrum master knows how much a team can produce/deliver after a few sprints, which helps her nail down on the predictability of a team.
I also noticed that the R&D resources have a sense of accomplishment at the end of each cycle, and are looking forward to the next one. But then, a good project manager could get this done in traditional scenarios as well.
The biggest issue, as already stated, that I too have experienced is the lack of buy in. It is very difficult to get people to truly become vested in the process.
The other issue, which is also one that directly contributes to the above issue, and also in a large part one of the founding causes of Agile is the lack of management to stick to the outlines of the manifesto of Agile.
In Scrum, Lean, or whatever version of Agile you are working with one cannot break from the manifesto points. If a process is being used to break away from those priorities then most likely the management is screwing up and the buy in will fall apart. The manifesto MUST be followed:
Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Some scenarios might be when a gantt chart appears from one of the above processes for whatever reason. Gantt charts can be useful, but if all of a sudden a developer is reviewing a gantt chart with management, the last point is broken. Responding to change has slowed because encouragement of the plan is being favored over change. Instead a board with stickies should be used, simplify what is on the board with only the current working items and back burner items. This makes changes easy. Once anything is solidified in a "tool" it slows responding to changes. Sure, management needs to record and track things in some ways, but pushing that onto development only slows the responding to change, and pushing tools onto developers (unless they want them for development and can utilize them appropriately) messes up the first point, of the individuals over tools and process.
In another way, don't stop development for the purpose of writing comprehensive documentation. Unless you only have a single developer, then someone should take the documentation load autonomously from the development role. Pushing these things together drastically slows development and for periods of time, can shut down any effort to actually get working software.
The last point, is to always, ALWAYS stay in contact in some way with the customer or prospective customer. Talk to them regularly about what they want. Talk to them daily and show them as much as you can of UI, or even data flow work. Anything that they would understand they should see. Talk to them, educate them about the architecture and ideas going into the application and never forget that you are building the application for them.
Summary:
Biggest issue is buy in. Second is management sticking to the manifesto guidelines.
If you can mitigate these two risks, you should be good to go. Anything else is cakewalk after getting buy in and getting management to understand that they'll need to be truly strong, and non-micro management managers. Specifically, managers might even need to become leads, or fill a different style of role.
...hope I didn't stray off point too much. :)
I have been running Scrum in several projects. The biggest problem, as I see it, is that not everybody in the organization is into the process. Everybody needs to be committed. Not only the team of developers. Often the managers are the persons that initialize the process and expect that things will change to the better without them doing anything.
My suggestion is that you run a workshop with the whole organization so everybody knows how the process works. Not only the developers. It's essential that you have a person that is really into the process. A person that can answer questions the team and organization have. A mentor.
Being agile is about welcoming change. You should not let the process gets in the way of sense. Do things that works for your organization, but you should try out the whole process before throwing something out.
We implemented Agile (set of SCRUM - management and XP - engineering practice) in an environment that was waterfall with large projects in an environment that was heavily integrated. The waterfall police were everywhere. As you can imagine, many projects failed. Having done Agile at a previous employer, we received permission to trial agile for the project.
Internal to the team, we used the Agile practice. Externally, we wrapped the agile practices with waterfall processes meaning primarily reporting. Thus, we looked from the outside like a waterfall project. However, there was a big difference, internally we were using agile and consequently we delivered, on time, within budget with high quality.
The critical success factors were embedded coaches (Iteration Manager Coach, Dev Lead Coach, Test Lead Coach and a Solution Analyst Coach). Securing commitment from dependent system in advance (required that we look ahead to identify depend systems and the work required from those systems) was a must in a heavily integrated environment. Prior to starting, we immersed the technical and business members of the team in an agile boot camp. This ensured that the key players (product owner and technical team) knew there roles and could execute effectively. Finally, the wrapping of the project with waterfall reporting enabled us to tie into all the existing reporting structure in the enterprise.
The net result is that the company is now moving waterfall projects to agile. This is all possible only because we have been able to deliver high quality software at a sustainable pace.
Where I work has been using Scrum for a while now but it seems to have gone through a few phases. In terms of obstacles, one part is to prevent putting in too much change at once and just introduce things slowly,e.g. put in a daily standup one week, a couple weeks later put in a story board, a couple weeks later bring in pair programming. This allows for the various tweaks that will happen to work and if the changes improve things then this can help build up some good momentum. Another point is to make sure that if there should be changes in how something is done that the person being corrected isn't belittled or mocked. At times this may mean that you interrupt someone or that you bring in a "Can we get back to basics?" or something similar to try to put things back on track rather than just yelling at someone or doing something else that is counterproductive.
Bringing in consultants was one of the best things done around here, IMO. Now, these guys came in to help evolve how development was done here. Bringing in pair programming, TDD, concepts like broken windows, organizing project folders, and bringing in mocking for tests, were all excellent additions that while we may have gotten there on our own, it may have taken a long time which wouldn't work out so well.
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 5 years ago.
Improve this question
In traditional Waterfall, requirements were gathered - typically in a MS-Word document - following an esoteric template. In a "strict" waterfall model, this document is frozen after the requirement phase and a Change Control / Change Management process is responsible for introducing controlled changes. (**) [Typically, the document is turned into a "living document" and eventually a "living nightmare"]
Currently, I've to lead a project that is a rewrite of an existing desktop application to web (from VB 6.0 to ASP.Net). The client has a baselined version of the application that he wants rewritten. [So requirments are frozen... No scope creep]. The data model to be reused as is. Only the front end/Business rules to be migrated. Looking at the application, I feel it's a at most 3/4 major screens and that's it.
Some of the team members want to document (old school of thought, in my opinion) the entire thing before they start on the new development. I & and some others feel, it shoud be relatively easy translate the UI to Web, to look up old code, write the business logic, do automated unit tests, proceed to integration tests and deliver screen by screen (or business function by function)
My question is:
In an Agile development how I do I remain "agile" if I were not to optimize this. My opinion is writing detailed documentation is anti-agile. What do you think? How would an agile guru approach the above problem (of rewriting an existing VB 6.0 app to ASP.Net)?
Disclaimer:
Creation of a 1000 page Functional Spec could possibly be to meet contractual obligations, a political necessity, the system could be genuinely complex (now, definition of "complexity" is a journey unto murky-land).
First, you can produce documentation and remain agile, if the customer or the Product Owner requests to have (read is ready to pay for) documentation.
Grow your documentation incrementally and iteratively, as you'll do with code. Test a little , code a little and ... document a little.
I see three ways of doing this : either include the time to write the documentation in the tasks estimation, create documentation specific tasks, or have documentation backlog items/stories.
The risk with the documentation stories is that they may be planned very late, a long time after that have been implemented, so I won't recommend this.
Documentation tasks have the advantage of being visible in the iteration planning, so they should not been forgotten or overlooked.
Agile does not mean "no specs." It mean test and release early and often (but not necessarily to production).
The backlog in Scrum is the "spec." If you don't actually write down and manage the list of features, you WILL lose features, and you will NEVER be able to figure out when the product will be released (won't be able to estimate amount of work left because you have no idea where you are or how much there is left to do). The list of features MUST be managed by someone. The easiest way to do that is to write down everything the product should do (you can get as intricate in the wording and definition as you want) and keep track of what has been completed and what is left to do. How else will you assign work to developers and report status to "management?
I've put a lot of thought on the subject - we work in a Scrum environment, and we've ended up having difficulties to organize the documentation.
What I'm heading to at the moment, though it's quite early so I don't know if it'll pass the long term test, is to use a wiki for the documentation.
Basically, the workflow is the following :
Stories come up in the backlog
Story gets picked up by a programmer
Programmer does the code, and in the DoD (Definition of Done), also has to write some tests against the new functionnality, and has to edit the wiki to add a page for the new functionnality.
The wiki is organized with mediawiki templates, pretty much inspired from mediawiki extensions doc pages, with the name of the functionnality, the version it has been introduced into, anything that can be usefull. The template adds pictos to distinguish between different kinds of features (and of their status).
At the end of the day, the wiki has the great advantage of letting you add the documentation page without being bothered about where or how to put it, but obviously regularly you need someone to come behind and organize the mess.
The important thing to keep in mind, whatever tool you use, is that the developper should write some doc just after the development has taken place (including technical aspects) - and not before, and not months after...
In my view the functional specification is necessary depending on how involved is the tech team with the product and how senior is the team. If the tech team is involved in the product definition you'll definitely need less documentation because there will be less room for assumptions. If you have a team of engineers that are juniors you need a stronger documentation or else things will not be done the way they were defined in the end of the sprints.
Also be aware that remote teams need more documentation in the form of functional specs due to the natural barrier of not being close to the stakeholders and product visionaries.
Having upfront functional specs is a feature of agile. I saw a lot of tech teams where the tasks where solely described by a user story and quite often I saw those teams failing to achieve the releases and meeting the stakeholder's expectations.
This subject is very broad and there are a lot of opinions but in my view this can be reduced to the fact that the developers should not have to guess the requirements.
In fact I believe that the success and quality of the deliverables is inversely proportional to the number of guesses/assumptions that the developers need to make. I think agility increases with how well specified is something because you will have less mistakes and will spend less time correcting those mistakes.
If creating a Function Spec is a contractual necessity you should think really carefully what goes in it. You could be refused payment if you fail to deliver what you promise in your functional spec.
Unfortunately you're not going to remain very agile if you adopt this process. Does the client really want the same functions for the re-written application? If yes, then why is it being re-written? I'm sure that there a features that are never used.
I would not bother to document the old version. You have a reference already, the application itself. There is no ambiguity in the software.
Document writing is not anti-agile. Designing something without prioritising and getting feedback from your customer is. An important aspect of agile is getting buy in from the customer. If they don't believe it, then the project will have a harder time than it should.
As already pointed out, Agile does not mean little to no documentation - "working software over comprehensive documentation".
The way I approach documentation is almost to flip things on its head and to consider just about everything part of documentation (including code and unit tests as technical specs). So, a story (or whatever other mechanism you use to divvy up work) describing a business/user requirement should be detailed enough to be estimated by the team doing the work; otherwise, it is incomplete and vague. Further, something I do in my own practice, if the story (or whatever) is estimated to take longer than one working day to fit the team's definition of "done" it should most likely be broken down (this atomizing then compiling eventually leads to pretty extensive documentation, but does not assume as many unknowns as not doing it will - and can lead pretty interesting reuse and pattern revelations).
Example using BDD style requirements:
Given I am working on a document
When I select "Save As..."
Then a menu should appear allowing me to choose a name,
and a file type,
and a location in the file system,
and a file should be created in the file system
We may need/want to add UI elements to accomplish this, menu items, storyboards, keyboard shortcuts, etc. to this description (we may have multiple variations on the same theme of "saving a file"). And so on.
All of these related artifacts can be attached onto the base story/requirement; resulting in more complete documentation. But, only add those stories you actually implement to your documentation of the web version of the software.
Here's where things get kind of flipped on their head and become more "Agile". During development, and after development, revisiting the documented requirement and adding changes/modifications/improvements made by the team edits are made (without having to go through a documentation-only CCB). The ability to edit/update the documentation and related assets without going through all the review boards and whatnot - or throwing the document "back over the wall" when we find out during development that the document is incomplete in some way makes us able to adapt to the unknowns - therefore, Agile.
This documentation should have some form of version control or history, which allows us to describe the system we desired, but also describe the system that was actually implemented - noting another answer/suggestions regarding documentation being part of the Definition of Done (something I also do). (Wikis are good for this; however, a fully integrated concept is a little more desirable - e.g., being able to relate a ticket to a file in trunk in the version control system would be nice.)
To kind of conclude. Creating exhaustive documentation up front, which cannot be altered during and/or shortly after the development effort, will keep you from being agile - able to quickly adapt to unknowns. However, to reference Leading Lean Software Development, wherein they mention that if policies do not allow for certain practices/processes to be used properly, then it doesn't matter if you say you are lean (or scrum, or agile).
One way to make sure you are not being overly exhaustive - probably could've used this mindset on this answer - is to only write what you need to when you need to (similar concepts exist in development in general). Another would be to get everyone to understand that you don't need to try and figure everything out up front (the biggest transition from Waterfall to Agile) - we will document every idea and it may or may not end up in a release. And, finally, deprecate (and remove) anything that no longer applies...I remember seeing documentation for a system once and, when I reviewed the system, half the document didn't actually apply to the system anymore.
Since you have a document describing what the product should do, I would use it as the initial backlog and start splitting the work in bite size pieces ordered from highest to lowest priority. Each set of pieces would then be handled during an iteration. In brief, use Scrum with your initial document as the backlog.
I would not go straight to the implementation without doing this prioritization work. It does not require a lot of writing but more referencing the pieces you want to tackle.
I would not document the whole thing upfront.
In addition, you will have some tasks directly related to the platform your tackling and those tasks need to be captured and added to the sprint backlog.
Also, you may realize that you don't want to implement all the requirements after a few iterations.
Agile has a Functional Specification document in the form of the agile Features list, Product Backlog and even as far into the sprint as tasks in the sprint Backlogs too. The fact they are not called documents doesn't make them any less. And the difference from the Functional Spec in waterfall?...Agile Functional Spec only contains what is required (lol) therefore is less voluminous, remember your "Working software over comprehensive documentation"?
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Several times now I've been faced with plans from a team that wants to build their own bug tracking system - Not as a product, but as an internal tool.
The arguments I've heard in favous are usually along the lines of :
Wanting to 'eat our own dog food' in terms of some internally built web framework
Needing some highly specialised report, or the ability to tweak some feature in some allegedly unique way
Believing that it isn't difficult to build a bug tracking system
What arguments might you use to support buying an existing bug tracking system? In particular, what features sound easy but turn out hard to implement, or are difficult and important but often overlooked?
First, look at these Ohloh metrics:
Trac: 44 KLoC, 10 Person Years, $577,003
Bugzilla: 54 KLoC, 13 Person Years, $714,437
Redmine: 171 KLoC, 44 Person Years, $2,400,723
Mantis: 182 KLoC, 47 Person Years, $2,562,978
What do we learn from these numbers? We learn that building Yet Another Bug Tracker is a great way to waste resources!
So here are my reasons to build your own internal bug tracking system:
You need to neutralize all the bozocoders for a decade or two.
You need to flush some money to avoid budget reduction next year.
Otherwise don't.
I would want to turn the question around. WHY on earth would you want to build your own?
If you need some extra fields, go with an existing package that can be modified.
Special report? Tap into the database and make it.
Believing that it isn't difficult? Try then. Spec it up, and see the list of features and hours grow. Then after the list is complete, try to find an existing package that can be modified before you implement your own.
In short, don't reinvent the wheel when another one just needs some tweaking to fit.
Programmers like to build their own ticket system because, having seen and used dozens of them, they know everything about it. That way they can stay in the comfort zone.
It's like checking out a new restaurant: it might be rewarding, but it carries a risk. Better to order pizza again.
There's also a great fact of decision making buried in there: there are always two reasons to do something: a good one and the right one. We make a decision ("Build our own"), then justify it ("we need full control"). Most people aren't even aware of their true motivation.
To change their minds, you have to attack the real reason, not the justification.
Not Invented Here syndrome!
Build your own bug tracker? Why not build your own mail client, project management tool, etc.
As Omer van Kloeten says elsewhere, pay now or pay later.
There is a third option, neither buy nor build. There are piles of good free ones out there.
For example:
Bugzilla
Trac
Rolling your own bug tracker for any use other than learning is not a good use of time.
Other links:
Three free bug-tracking tools
Comparison of issue tracking systems
I would just say it's a matter of money - buying a finished product you know is good for you (and sometimes not even buying if it's free) is better than having to go and develop one on your own. It's a simple game of pay now vs. pay later.
First, against the arguments in favor of building your own:
Wanting to 'eat our own dog food' in terms of some internally built web framework
That of course raises the question why build your own web framework. Just like there are many worthy free bug trackers out there, there are many worthy frameworks too. I wonder whether your developers have their priorities straight? Who's doing the work that makes your company actual money?
OK, if they must build a framework, let it evolve organically from the process of building the actual software your business uses to make money.
Needing some highly specialised report, or the ability to tweak some feature in some allegedly unique way
As others have said, grab one of the many fine open source trackers and tweak it.
Believing that it isn't difficult to build a bug tracking system
Well, I wrote the first version of my BugTracker.NET in just a couple of weeks, starting with no prior C# knowledge. But now, 6 years and a couple thousand hours later, there's still a big list of undone feature requests, so it all depends on what you want a bug tracking system to do. How much email integration, source control integration, permissions, workflow, time tracking, schedule estimation, etc. A bug tracker can be a major, major application.
What arguments might you use to support buying an existing bug tracking system?
Don't need to buy.Too many good open source ones: Trac, Mantis_Bug_Tracker, my own BugTracker.NET, to name a few.
In particular, what features sound easy but turn out hard to implement, or are difficult and important but often overlooked?
If you are creating it just for yourselves, then you can take a lot of shortcuts, because you can hard-wire things. If you are building it for lots of different users, in lots of different scenarios, then it's the support for configurability that is hard. Configurable workflow, custom fields, and permissions.
I think two features that a good bug tracker must have, that both FogBugz and BugTracker.NET have, are 1) integration of both incoming and outgoing email, so that the entire conversation about a bug lives with the bug and not in a separate email thread, and 2) a utility for turning a screenshot into a bug post with a just a couple of clicks.
The most basic argument for me would be the time loss. I doubt it could be completed in less than a month or two. Why spend the time when there are soooo many good bug tracking systems available? Give me an example of a feature that you have to tweak and is not readily available.
I think a good bug tracking system has to reflect your development process. A very custom development process is inherently bad for a company/team. Most agile practices favor Scrum or these kinds of things, and most bug tracking systems are in line with such suggestions and methods. Don't get too bureaucratic about this.
A bug tracking system can be a great project to start junior developers on. It's a fairly simple system that you can use to train them in your coding conventions and so forth. Getting junior developers to build such a system is relatively cheap and they can make their mistakes on something a customer will not see.
If it's junk you can just throw it away but you can give them a feeling of there work already being important to the company if it is used. You can't put a cost on a junior developer being able to experience the full life cycle and all the opportunities for knowledge transfer that such a project will bring.
We have done this here. We wrote our first one over 10 years ago. We then upgraded it to use web services, more as a way to learn the technology. The main reason we did this originally was that we wanted a bug tracking system that also produced version history reports and a few other features that we could not find in commercial products.
We are now looking at bug tracking systems again and are seriously considering migrating to Mantis and using Mantis Connect to add additional custom features of our own. The amount of effort in rolling our own system is just too great.
I guess we should also be looking at FogBugz :-)
Most importantly, where will you submit the bugs for your bug tracker before it's finished?
But seriously. The tools already exist, there's no need to reinvent the wheel. Modifying tracking tools to add certain specific features is one thing (I've modified Trac before)... rewriting one is just silly.
The most important thing you can point out is that if all they want to do is add a couple of specialized reports, it doesn't require a ground-up solution. And besides, the LAST place "your homebrew solution" matters is for internal tools. Who cares what you're using internally if it's getting the job done as you need it?
Being a programmer working on an already critical (or least, important) task, should not let yourself deviate by trying to develop something that is already available in the market (open source or commercial).
You will now try to create a bug tracking system to keep track of the bug tracking system that you use to track bugs in your core development.
First:
1. Choose the platform your bug system would run on (Java, PHP, Windows, Linux etc.)
2. Try finding open source tools that are available (by open source, I mean both commercial and free tools) on the platform you chose
3. Spend minimum time to try to customize to your need. If possible, don't waste time in customising at all
For an enterprise development team, we started using JIRA. We wanted some extra reports, SSO login, etc. JIRA was capable of it, and we could extend it using the already available plugin. Since the code was given part of paid-support, we only spent minimal time on writing the custom plugin for login.
Building on what other people have said, rather than just download a free / open source one. How about download it, then modify it entirely for your own needs? I know I've been required to do that in the past. I took an installation of Bugzilla and then modified it to support regression testing and test reporting (this was many years ago).
Don't reinvent the wheel unless you're convinced you can build a rounder wheel.
I'd say one of the biggest stumbling blocks would be agonising over the data model / workflow. I predict this will take a long time and involve many arguments about what should happen to a bug under certain circumstances, what really constitutes a bug, etc. Rather than spend months arguing to-and-fro, if you were to just roll out a pre-built system, most people will learn how to use it and make the best of it, no matter what decisions are already fixed. Choose something open-source, and you can always tweak it later if need be - that will be much quicker than rolling your own from scratch.
At this point, without a large new direction in bug tracking/ticketing, it would simply be re-inventing the wheel. Which seems to be what everyone else thinks, generally.
Your discussions will start with what consitutes a bug and evolve into what workflow to apply and end up with a massive argument about how to manage software engineering projects. Do you really want that? :-) Nah, thought not - go and buy one!
Most developers think that they have some unique powers that no one else has and therefore they can create a system that is unique in some way.
99% of them are wrong.
What are the chances that your company has employees in the 1%?
I have been on both sides of this debate so let me be a little two faced here.
When I was younger, I pushed to build our own bug tracking system. I just highlighted all of the things that the off the shelf stuff couldn't do, and I got management to go for it. Who did they pick to lead the team? Me! It was going to be my first chance to be a team lead and have a voice in everything from design to tools to personnel. I was thrilled. So my recommendation would be to check to the motivations of the people pushing this project.
Now that I'm older and faced with the same question again, I just decided to go with FogBugz. It does 99% of what we need and the costs are basically 0. Plus, Joel will send you personal emails making you feel special. And in the end, isn't that the problem, your developers think this will make them special?
Every software developer wants to build their own bug tracking system. It's because we can obviously improve on what's already out there since we are domain experts.
It's almost certainly not worth the cost (in terms of developer hours). Just buy JIRA.
If you need extra reports for your bug tracking system, you can add these, even if you have to do it by accessing the underlying database directly.
The quesion is what is your company paying you to do? Is it to write software that only you will use? Obviously not. So the only way you can justify the time and expense to build a bug tracking system is if it costs less than the costs associated with using even a free bug tracking system.
There well may be cases where this makes sense. Do you need to integrate with an existing system? (Time tracking, estimation, requirements, QA, automated testing)? Do you have some unique requirements in your organization related to say SOX Compliance that requires specific data elements that would be difficult to capture?
Are you in an extremely beauracratic environment that leads to significant "down-time" between projects?
If the answer is yes to these types of questions - then by all means the "buy" vs build arguement would say build.
If "Needing some highly specialised report, or the ability to tweak some feature in some allegedly unique way", the best and cheapest way to do that is to talk to the developers of existing bug tracking systems. Pay them to put that feature in their application, make it available to the world. Instead of reinventing the wheel, just pay the wheel manufacturers to put in spokes shaped like springs.
Otherwise, if trying to showcase a framework, its all good. Just make sure to put in the relevant disclaimers.
To the people who believe bug tracking system are not difficult to build, follow the waterfall SDLC strictly. Get all the requirements down up front. That will surely help them understand the complexity. These are typically the same people who say that a search engine isn't that difficult to build. Just a text box, a "search" button and a "i'm feeling lucky" button, and the "i'm feeling lucky" button can be done in phase 2.
Use some open source software as is.
For sure there are bugs, and you will need what is not yet there or is pending a bug fix. It happens all of the time. :)
If you extend/customize an open source version then you must maintain it. Now the application that is suppose to help you with testing money making applications will become a burden to support.
I think the reason people write their own bug tracking systems (in my experience) are,
They don't want to pay for a system they see as being relatively easy to build.
Programmer ego
General dissatisfaction with the experience and solution delivered by existing systems.
They sell it as a product :)
To me, the biggest reason why most bug trackers failed was that they did not deliver an optimum user experience and it can be very painful working with a system that you use a LOT, when it is not optimised for usability.
I think the other reason is the same as why almost every one of us (programmers) have built their own custom CMS or CMS framework at sometime (guilty as charged). Just because you can!
I agree with all the reasons NOT to. We tried for some time to use what's out there, and wound up writing our own anyway. Why? Mainly because most of them are too cumbersome to engage anyone but the technical people. We even tried basecamp (which, of course, isn't designed for this and failed in that regard).
We also came up with some unique functionality that worked great with our clients: a "report a bug" button that we scripted into code with one line of javascript. It allows our clients to open a small window, jot info in quickly and submit to the database.
But, it certainly took many hours to code; became a BIG pet project; lots of weekend time.
If you want to check it out: http://www.archerfishonline.com
Would love some feedback.
We've done this... a few times. The only reason we built our own is because it was five years ago and there weren't very many good alternatives. but now there are tons of alternatives. The main thing we learned in building our own tool is that you will spend a lot of time working on it. And that is time you could be billing for your time. It makes a lot more sense, as a small business, to pay the monthly fee which you can easily recoup with one or two billable hours, than to spend all that time rolling your own. Sure, you'll have to make some concessions, but you'll be far better off in the long run.
As for us, we decided to make our application available for other developers. Check it out at http://www.myintervals.com
Because Trac exists.
And because you'll have to train new staff on your bespoke software when they'll likely have experience in other systems which you can build on rather than throw away.
Because it's not billable time or even very useful unless you are going to sell it.
There are perfectly good bug tracking systems available, for example, FogBugz.
I worked in a startup for several years where we started with GNATS, an open source tool, and essentially built our own elaborate bug tracking system on top of it. The argument was that we would avoid spending a lot of money on a commercial system, and we would get a bug tracking system exactly fitted to our needs.
Of course, it turned out to be much harder than expected and was a big distraction for the developers - who also had to maintain the bug tracking system in addition to our code. This was one of the contributing factors to the demise of our company.
Don't write your own software just so you can "eat your own dog food". You're just creating more work, when you could probably purchase software that does the same thing (and better) for less time and money spent.
Tell them, that's great, the company could do with saving some money for a while and will be happy to contribute the development tools whilst you work on this unpaid sabbatical. Anyone who wishes to take their annual leave instead to work on the project is free to do so.
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 years ago.
Improve this question
Has anyone used both FogBugz and Axosoft's OnTime and care to offer an opinion? AxoSoft has a big feature comparison chart but I'm also interested in more subjective thoughts on things like ease of use and stability.
I've used both from a project lead perspective and a team member, to manage parallel projects and teams.
OnTime has a big feature matrix, but that doesn't translate into more value in an organization. For ease of use, OnTime fails. OnTime does NOT have a well designed interface, so for me, it does not stand out in the crowd. FogBugz, on the other hand, is pleasant to use, and I found myself "happier" to login every morning.
For me, the most important "feature" is: How well the tool presents and tracks issues and simplifies participation by team members. If it does this poorly, most of the other features fade. If it does this well, then some missing features can be forgiven.
On this one point, I find OnTime particularly inadequate and FogBugz particularly superior.
OnTime is loaded with different tabs in which information becomes lost or difficult to track. Teams and individuals often use different tabs for different purposes. I have to click around or I might miss something.
FogBugz tracks the issue with minimal clutter, like a discussion thread. When updates are made to the issue, all parties are notified via email, and no information is visually lost. At a glance, I always know what is going on with FogBugz.
OnTime 2009 also doesn't allow us to assign and track issues with multiple team members in parallel. You simply assign to a single person. No way to CC others. Big deficiency for team work.
Also, when performing a project review, we often take down a lot of fast issues as the customer speaks. With FogBugz I can use the quick mode to punch the issue in as fast as I can type descriptions, and return later to flesh it out. We cannot do this with OnTime, with its various required fields. Besides that, OnTime is just sluggish, taking 5-6 seconds just for the defect window to popup. I need to be able to enter issues during a meeting as fast as I can type it into Excel. The total time & clicks to create an issue in any tool is a key benchmark.
In short, with customers who use OnTime I see people constantly fallback to email for discussions, and I also see degraded communication (someone enters notes that others never see). I do not see this trend with FogBugz.
Feature matrixes look good on paper, but it is difficult enough to keep teams using a tool properly without the tool adding more difficulty. FogBugz makes it as simple as you want, while allowing you to drill down as needed.
OnTime, however, feels like a very detailed tracking database with quick WinForms app thrown on top.
The downside for me with FogBugz is price for upgrades. Yearly maintenance is steep at 50% of the original cost. I could not justify upgrades, in part because we are happy with FogBugz 6, but in part because I could not see what I was getting for my yearly maintenance fees. FogCreek wasn't very flexible on licensing discounts for us, after all they need to make a living, so we just decided to stick with v6 forever.
UPDATE 2014: A year or so after I wrote this, FogCreek sent me a free upgrade to v7 to fix a security bug. Just this year, they did the same thing again. They are the only company I've ever deal with to give me a free upgrade just to fix a bug, even without maintenance. A top-notch company with good people.
I'd still spend my money again on FogBugz without a second thought.
I actually encouraged the company I work for to begin tracking bugs with software (specifically FogBugz) and have been very pleased with FogBugz.
We blindly let our customers send bug requests into FogBugz through email, which has it's advantages and disadvantages. But we really haven't had any problems integrating FogBugz into a team that was totally unfamiliar with any bug tracking software. Overall, I'd rate FogBugz about a 9 on ease of use and stability.
I've used both extensively in production software development environments.
OnTime isn't bad - once you set it up to handle support tickets sent to an email, it has all the daily activities of software developers pretty well integrated.
I personally prefer FogBugz, because of the predictive estimation stuff that it includes. Being able to pick a due date, and then getting a likelihood of hitting that date based on your past performance is pretty awesome. I also think in general FogBugz is faster to use and organize your features/defects, and I like how it tracks time better.
One area where OnTime wins out is that it is much easier to make reports against OnTime. It stores everything in a SQL server so it is easy to access (granted if you get the non-hosted FogBugz maybe you could do this too). Also, it includes a report designer so you can get to your data. FogBugz has the weakness that while you can track and enter the time you spent per item for the purposes of its experienced-based scheduling, it doesn't give you an easy way as a manager to look at how much time a given employee spent on what things that week. Hopefully they will add that in the near future.
OnTime is more an ALM tool - it's trying to do everything.
FogBugz just deals with bugs (and feature requests) and at that it's excellent. I'm not sure about some of the newer extensions (like discussions), but for bugs it's really good.
There's lots of stuff that I'd add to it in terms of better reports, searching and the like, but I can definitely recommend FogBugz.
I've used OnTime for a few years now. It's actually a very easy tool to use and not just a bug tracking tool as was suggested. Where it falls down for me is the slowdown I've experienced as the volumes of Features / Defects/ Tasks have grown. Also, the web client tries too hard to be a parallel of the winform version and can be flaky as a result.
I have not tested the OnTime thing, but keep in mind that both FogBugz and OnTime have free versions as well, Axosoft for 1 user and FogBugz for 2 Users, although it's the hosted version. (Check my answer here to see how to sign up for the free FogBugz version)
So you can have some real first-hand experience on both systems.
Are you bug tracking or project planning?
FogBugz has better bug tracking features. FogBugz has better e-mail integration, state tracking and triggers. FogBugz is easier to drill down to an individual task without needing to apply a lot of filters.
For project planning, however, OnTime is the superior tool. The monte carlo estimation feature in FogBugz is cool--don't get me wrong--but honestly, getting the project entered into FogBugz so you can actually use the estimator is such a pain in the rear it can be downright frustrating. The scrum planning board in OnTime is really sexy. If you're used to using whiteboards or sticky notes, it's a breeze to enter and visualize.
OnTime provides better project overview information and custom reporting; this is better for managers.
FogBugz provides better drill-down information; this is better for implementers.
FogBugz has more features; this is better for tech-centric users.
OnTime is more graphical; this is better for non-engineers (project planners, artists and other people who often have to use scheduling tools).
Other factors: Some people have mentioned speed issues. I haven't noticed speed issues with either, but my only experiences have been local installs. OnTime is expensive for mid-sized teams; it's free for a single user and by the time you get to 10+ users the price is average, but for 3-6 man teams it's expensive especially if you want the pivot charts.
Quite honestly if you can afford it, it would not be stupid to consider both. Use OnTime for writing quotes, and FogBugz for tracking defects. They are radically different tools, and neither one excels in all areas but both are very good at select tasks.
I haven't worked with FogBugz, although I recently recommended our company goes with that.
OnTime is what the company decided to use and I personally don't like OnTime because of slowness and badly organized GUI. We opted to host it ourselves, but I don't think the machine is slow. The web app doesn't really look like a web app, more like it copies a windows app, just as Brian Scott said in his answer. And don't try using the windows app over Internet (over VPN). It's awfully slow. I suppose it could be due to our Internet connection latency.
Of course, my experience might be different than other people's, I could be having network issues. Someone else will have to confirm my claims of slowness. :)