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.
We use Trac as our bug tracking / development / wiki system and I was wondering if anyone has experience and uses some of the Trac Agile/Scrum plugins or functionalities? Anything you'd recommend?
Or would it be better to duplicate Trac tickets as dead-tree user story index cards and a hand-drawn burndown chart?
Note that I found a similar question here. Though it's specifically about Scrum. They recommend Agilo. Has anyone tried Agilo yet?
With a collocated team, I'd always duplicate user stories on index cards. A wall of cards is much more collaborative and simple to use than any software tool. And what's most important, it's in your face.
The same is true for a burn chart. In my experience, a software chart gets online looked at by a small number of people, and typically is a pull medium. A big, handdrawn poster (that changes regularly) gets noticed by everyone, and serves as an incubator for ad hoc discussions.
It's also quite valueable to be able to point at them during your daily scrum meeting.
This is how we use Trac for our scrum like sprints:
We use the milestones in Trac to identify sprints.
There is a default Backlog milestone where we gather all new tickets.
Before each sprint we move tickets from the backlog the current release.
On the milestone page, we can add retrospectives and other info about the sprint using wiki syntax.
So just the default Trac functionality without any plugins for now to keep it lightweight. As we get better we may add features like burndown charts or maybe switch to another tool, but we want to get the proces in place first.
Answering late, but this more of sharing my experience with Trac+Agilo so far.
To quickly answer your question, perhaps Agilo is the best option available for Agile development with Trac.
Now comes to install and usining install was just very easy. We used their latest release 0.7.3.3. It installs flawless on Trac 0.11 and Python 2.5. Don't forget to install libjpeg and python imaging library. It would be useful to note that we used virtualenv which took a made things easier.
Further usage is very simple. For wiki I kind of prefer Trac's old clean look over Agilo's customization. Other than that all things just works.
On thier mailing list I have noticed that they are planning to offer multi-project support in future. In all I recommend Agilo plugin for Trac.
Yep, I installed Agilo on our Trac installation.
Seems very cool, includes nice burndown charts.
Unfortunately I left the company where I installed it before I could get any serious usage out of it.
Installation was a pain (Ubuntu Ibex) - I documented precise steps on the Agilo Google Group.
The problem (as always) is integration into the business end of things that PMs and CEOs like to see (e.g. estimated vs actual hours). There are (as has been mentioned) other products out there that cover this off (FogBugz covers this off I believe), but I (and the team) love Trac so we worked around this.
Oh, one more thing; it looks like it introduces quite a lot of overhead (i.e. you have to spend more time in trac to get the most out of it), but like I say I didn't have an opportunity to really use it in anger.
We used Trac before with a burndown plugin then went to Redmine. We've found Redmine to be miserable for repository viewing and the issue interface. We're actually looking to move back to Trac again.
Bitten is a Trac plugin for continuous integration that can be harnessed to do automatic builds on check-in, which provides a critical part of the Agile process (rapid feedback). I haven't used any other plugins for Trac personally, so I can't comment on them. However, the native Trac functionality of milestones could be leveraged fairly easily, I suspect, to be used as iteration markers (where each milestone represents the end of an iteration). Since milestones can be used to mark a 'due date' for features already, you shouldn't need much in the way of modification to use them as such.
From there, using tickets as user stories, and tying them to milestones (I'm sure this can be done manually at worst) would give you a basic method of tracking velocity and keeping the team aware of progress (and changes that need to be made as well).
We use the Trac wiki for:
List of requirements for each feature
List of technical specs (if any) for the features
List of Releases and their features
Deployed environments, with links to all instances
There's a macro for making web requests, so we can list which version, etc. each env have
(there's a GraphViz plugin which is quite helpful for simple drawings)
There's also a ticket in the ticketing system for each "feature", for keeping a gross backlog and the current/next sprint planned.
Then we write a bunch of cards during sprint planning for each feature.
There's also a more operational side to things. We keep one person each sprint on Ops, so we have one person who's dedicated to be interrupted by people outside the team. The rest of the team can focus on delivering features.
Each bug/ops task gets a ticket, but as soon as we start working on it, it gets a card and starts moving across the board. That way it gets visibility and we don't forget to involve the testers, etc.
Scrum is pretty tactile, so I don't think it would work great to put too much stuff outside of the physical working environment. But in the end your team needs to find a balance that works.
For something completely different, the best way to do Agile Development with Trac may be to simply migrate everything to Redmine. It supports Trac's core features with some extras including multiple projects, Gantt charts, forums, DCVS, etc. though it looks like it's not completely there yet. Some good things in the pipeline.
Daniel Srb (in the comments) has a redmind agile plugin he's been working on that looks promising. You may be able to contact and see if he's planning to release it (was a long time ago).
We've had success using two products in concert in the past, Trac for tickets, xplanner for planning.
Agilo for Scrum rocks, the latest versions are using client side generated charts, so there is no dependency anymore, much easier to install :-) agile42 just release a Pro version that enriches the Agilo experience with a nice and intuitive Planning Board, very cool screencast :-)
We recently started using Scrumban.
Basically a Kanban board, with the daily stand-up meetings covering the classic Agile Scrum questions - what did you work on the previous day? what do you plan to work on today? do you have any blockers?
We do this around a physical Kanban board, it is great for visualizing the work flow and for team synergy, but we also wanted a digital form of our Kanban board to be able to double check trac usage vs. the physical board.
In search for something that would work, I found this clever post on re-creating a digital version of the Kanban board in trac.
It is very straight forward and simple, I was able to easily manipulate this approach for our work flow, and you could probably tailor it to your Agile Scrum iterative approach (or if your able to ditch the time boxed approach, give Scrumban a try).
Related
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 9 years ago.
First off please have patience for this long winded post. I wanted to get all the pertinent information (as I see it) out to you.
I have a decision to make and would like your input. I have recently taken on the task of taking over my daughter's skating club's website. They have a custom site written in asp pages and don't have anyone to support it. I want to move their site to a CMS system so it doesn't take a developer to maintain or make changes to it. We also want to add some custom pieces to it like a registration form for the club and some other custom pieces around marking down scores and viewing stats and such.
I am a .Net developer and have been developing in SharePoint for some time, but don't feel that SharePoint is a very good fit for them. Our current web host is GoDaddy. I don't yet have the details of the contract with them yet so can't comment on the service we have with them.
I have been looking at three CMS's at the moment. DotNetNuke, Umbraco, and Orchard. All are good and all have pros and cons as far as I can see. I am currently leaning towards DotNetNuke for the following reasons:
Umbraco appears to be a "create from scratch" system with no templates to apply (I apologize if this is incorrect, but it is based on the information I received). I am not a guy to develop the visual aspects of a site, so would rely heavily on templates and such.
Orchard sounds like it might be a good fit, however I have never developed in MVC before. Most of my .NET has been straight ASPX. I am not opposed to learning MVC and have had it on my list for a while, but I don't know if I have the time to learn and port over the current site.
Orchard also appears to be a bit heavy for a normal user (explaining content types and such). I want something others can take up when I pass on the responsibility.
So I am wondering what you all think. Even with learning MVC would Orchard be the best platform for us based on the information I have provided? Should I stay with DotNetNuke as my choice? I would like to mention that I did consider Sitefinity and would have had it at the top of my list, except we are a non-profit and don't necassarily have the budget for a paid CMS.
Thanks again and I look forward to your thoughts.
Well, the ultimate choice will vary on your business need. They all do the same thing, but how they achieve the goal is quite different.
Umbraco - It utilizes the Model, View, Controller (MVC) methodology. This obviously presents an assortment of benefits. However, the methodology to build a product can be quite extensive and even the layout to modify data can be quite cumbersome.
DotNetNuke - Uses a more familiar technology, Web-Forms. This has an assortment of benefits that go a long with it. Including a market, documentation, permission, and ease.
I've never used Orchard so I can't comment- but I can comment on the other two. To show you how I came to my conclusion to use which Content Management System hopefully it will point you in the best direction.
My project that I worked on required a lot of non-technical people to utilize our new product. It has a lot of functionality and features that were required; the biggest however was ensuring the following:
Ease
Intuitive
Control
Speed
Those were our four primary categories. I'll attempt to outline what each area means-
One of the largest pitfall of a Content Management System is that they tend to do more then you require. So the question becomes which product will bend while maintaining my core goals be. For that reason our company chose DotNetNuke because by nature DotNetNuke isn't a Content Management System it is a very powerful Framework.
What this particular product does is focus on a lot of key aspects so a developer doesn't have to waste a lot of time in maintaining but rather in developing.
Ease - A non-technical user is able to view a page; then edit the content in place on that page. Which allows you to incorporate a What you see, is what you get mentality. For the non-developer they get the all familiar Email or Word Editor.
Intuitive - In DotNetNuke 7 they've modified the menu structure for editing. You can actually disable other users to make it actually show less, do less, and still maintain the highest level of control. The user won't get lost in editing the page.
Control - Now this is what is nice, you can regulate each and every control for your user. So you can allow certain content to be regulated and other data not to be.
Speed - It has a market, so you can implement other developer modules. But it also includes a lot of documentation- it may appear cumbersome at first but is quite easy to pick up. Which makes the initial start time relatively painless.
But what do all of those mean to you?
Simple, it means you can develop a beautiful elegant page quite quickly. But since you can restrict several tiers of access you can ensure the page content can be edited by someone other then you- But it won't jeopardize any of your development / content. As you control whom and what is modified.
If your familiar with Microsoft .Net then it will be quite easy to learn; I'm sure other products can accomplish those same goals. But DotNetNuke did it easier which met our goals. It allowed us to not worry about excessive issues or support to enter our company; as the user understood it in such a way that issues don't arise.
That is why we chose DotNetNuke it will boil down to your preference. My experience with the product, community, and marketplace have made me love this product and not chose another. As I can leverage the Core API when needed; so Development, Maintenance, Administration became a breeze for whatever my imagination may produce. But should a developer ever not be present the site and it's quality will not hinder when I leave.
There is a selection of starter kits available in the package repository on the community website and also a few of them can be applied directly during installation of Umbraco. Also in the package repository you will find a wide selection of other packages which you can use on your site to enhance and add additional functionality.
It is true that Umbraco does not come pre-installed with "themes" as such like some other CMS's but this is the beauty of Umbraco, you have a clean slate to work from if you choose. It enforces no requirements on your markup or styling so there is absolutely nothing to stop you using a free or purchased template from any one of the template libraries online such as Creative Market, Template Monster etc etc.
Umbraco has an incredibly friendly, helpful and active community on both the forums and Twitter.
I work with all three and would tell you to use DotNetNuke over the other 2. The primary reason is that if you are developer, Orchard and Umbraco are fine... but you may or may not be the final or future content manager in the future of the club and want to be able to hand the site off to someone. DotNetNuke has the larger community and would be easier for the future admins to learn as well as get support for.
DNN will give you the development options you want, but give the content editors the easier system to work work... and keep you from having to support the site if you ever move on.
don't forget that Sitefinity does have a free community edition: http://www.sitefinity.com/try-now/free-asp-net-cms
it does have limitations, but for simple sites like this it might be just what you need, plus if they ever get a budget someday they could upgrade to the Small Business Edition by just buying a license and get more features and less limitations on the content and page limits.
worth a look.
otherwise, in my opinion your choice depends on who is going to be maintaining the site. If that is you and you'll always be in charge, pick whatever platform works best for you as a developer.
If on the other hand you have to make it drop-dead easy, pick the platform that is best for end users, that based on your knowledge of the user, would require the least amount of training (Sitefinity CE has my vote on that one!)
I hope this is helpful!
I would highly recommend going with DotNetNuke for the sheer reason that the community and available modules for the platform far surpasses any of the other options.
If you want to do MVC style development, you can with DNN using the WebAPI approach for services, but if you don't want to, you can skip that altogether.
The amount of Free and Paid extensions for DNN grows on a daily basis, available in the Store or Forge. You can also search both of these locations right from within the product itself.
I'm considering moving my open-source project Flyway from Google Code to GitHub.
One of the features I really like in Google Code's Issue Tracker is the ability to vote and sort issues by the number of votes. This has allowed me to get a good feel of where current pain points lie and what the community feels needs attention or further work.
How can I achieve something similar on GitHub? Is there a way to maintain a democratic approach to Issue Tracking?
There is no built-in ability to do so. Technically speaking, you can only manage issues by
assignee
tags (called labels at github)
milestones
While you can define label systems for lots of differentation criteria like
bug/feature request/...
prio high/low/...
status verified/unverified
it is simply not possible to have something that accumulates votes. So typically you will see "+1" postings as in good old mailing lists. I've seen people using external voting systems (like Google moderator) for issues on github, but that doesn't make a good user experience either.
If you're willing to use a third-party system that integrates with GitHub, you can try GitPoll.
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.
What is the best support for Scrum in Redmine?
Best practices?
Plugin support?
All plugins I've tried are either not that active anymore and/or not up to the task of managing a major project using Scrum.
I've googled to no avail...
Thought I'd make mention of the Redmine Backlogs plugin again. It's been getting some TLC lately. product backlog view, taskboard view, real-time updates, reports, task colors unique to the user's preference, etc.
http://www.redminebacklogs.net
I don't really know Redmine but it looks like the Scrum Alliance Development Team has several Scrum plugins for it. Others potentially useful plugins are the Scrum dashboard plugin, the Todo Lists plugin, the Backlogs plugin but I can't say if they conflict or overlap with the Scrum Alliance plugins. This requires IMO some further investigations and testing.
My advices:
If the team is collocated, don't use a web based tool, use sticky notes on a wall and a spreadsheet.
If there are good reasons to use a web based tool, don't use Redmine if it's not satisfying.
You don't need a scrum tool to use redmine in a scrum way, however, it can at least help with acceptance. Redmine Backlogs isn't too bad. I have evaluated it and the product backlogs screen is a little raw, but useful. The task board is good. I recommend you take a look at it.
Redmine Backlogs
Redmine_scrummer is a plugin developed by BadrIT to facilitate scrum processes, it easy to use and follows the all practices you apply while in a scrum process i.e. scrum board, burning charts, etc..
Scrum PM is a decent, current Scrum plugin for Redmine. It's fairly basic, and the UI leaves something to be desired, but it works.
It has a Backlog where you can create stories, and a Dashboard where you can drag and drop tasks for stories through status to done.
Redmine Issues are Tasks, and Versions are Sprints. There is no strong correlation between tasks and stories, and there are a few (non-blocking) bugs, but it's the best scrum plugin for Redmine I've seen.
try Redmine Scrumbler
https://github.com/256MbTeam/Redmine-Scrumbler
Scrum best practice is to avoid using too many tools.
Agile methods put individuals and interactions first. Tools aren't important. Read this page to see what the real background of scrum is: http://agilemanifesto.org/
Read this to see more about Scrum. http://www.controlchaos.com/old-site/Scrumo.htm
Note that tools aren't really necessary.
Scrum is a series of sprints (managed with a simple backlog and burndown chart).
Scrum is a daily stand-up meeting (managed with no tools at all).
We are a small Microsoft shop with 4 developers. We like the idea to have everything integrated and under the same SQL database but not to deal with too many features or a complexity we don't need.
The other option would be to use two distinct third party tools. We also wonder if VS2010 version control and bug/issue tracking capabilities are comparable with the best third party tools on the market.
With TFS 2010, there is a TFS Basic version/configuration options. You can use SQL Server Express as the database, the install is simple and quick and you can install it on a client OS. It includes version system, work items and build system (no sharepoint, reporting...). Price should not be high, the target users for TFS Basic are those used to use SourceSafe. Also if you have MSDN, there is a change that it goes with it, so you would not have to pay extra.
Some thoughts on TFVC in general -- note that I've never used TFVC specifically, but I've been in a similar situation a couple times. My main concern is that it's too little.
TFVC (Team Foundation Version Control) appears to be a client-server version control system. I don't know anybody who hasn't upgraded to DVCS yet. I've never used TFVC but I can't imagine what benefits it'd offer to outweigh the architectural disadvantage. (And before you ask: I only use it from my workstation in the office, where the network has never gone down, but I still use its distributed features every day.)
I also work at a small Microsoft shop with 4 developers and we have never once regretted using Mercurial. It's one of the few decisions we made that everybody seems to have loved. It's one of those moves, like switching to a language with GC, that you never want to even think about reversing.
In terms of support, I hope you found some way to get great support from Microsoft. Things will come up with any VCS and it looks like community support is a couple orders of magnitude worse than Hg or Git.
I can't say much about bug trackers -- I think they're all pretty much the same these days. I've installed a couple open-source ones in an afternoon, even with no experience. The major difference seems to be, if you go with a big-name one, you'll be able to find lots of tools and extensions that work with it. For example, there are a million and one extensions for reporting/testing/etc. for Bugzilla. TFS probably has similar things, for enough money.
Two other things I'd keep in mind:
First, even if you only want these 2 features today, you will want other features in the future, and it will be (sooner or later) something Microsoft doesn't offer. So it's best to make peace with 3rd-party tools ASAP.
Second, unless you miraculously happen to pick the perfect set of tools for your company's future growth for all time, you will at some point want to migrate away from whatever solution you pick today. So make sure it either provides a way to do a full export, or is popular enough that other projects are falling over themselves to write importers for it.
I guess this all sounds kind of negative for TFS. I didn't really mean it that way -- I'm sure it does some things really well. But unless you're rolling in dough already, save your money.
Good luck with whatever you choose!
TFS work ittm tracking is awesome. Whatever your workflow is and the information you want to gather, you can do it easily with TFS.
Most expect TFS to do what they do out of the box as if it were omniscient. Unfortunately, you do things slightly differently than me and I from everyone else. The key is making it easy for the many different roles in your organization to get and input information into whatever your work tracking system is.
There is a plateau you will reach with custom, cobbled together tools that you won't get from cross referencing information along the product development process. TFS removes that barrier. The second barrier is knowing how to consume the information and that takes training and experience in effectively managing projects.
TFS Version control is certainly the low point when compared to the industry right now. DVCS popularity exploded about the time TFS came out. That said, Brian Harry has stated that TFS "fully expect that we will be adding distributed version control to TFS." http://blogs.msdn.com/bharry/archive/2010/01/27/codeplex-now-supports-mercurial.aspx
Take that as you will.
TFS is a great system but after having deployed and used it for some time I realize that the TCO is just too high to justify for a small team.
We have a small 3 developer team that is currently using Subversion for our source control. We expect the team to group to 8 members within the next 6 to 12 months. We are considering changing our source control to either TFS or Mercurial for improved branching. I know TFS is overkill for just branching, but that is the immediate need, and the other features of TFS could aid our team. One of our main concerns with TFS is we've heard that there is a lot of overhead deploying it, especially on a small team. I'm hoping to get some community insight into just how much overhead there may be involved, suggestions to make the process easier, and anything else the community may feel is useful in making the decision to implement.
In my experience, TFS works really well, even for small teams. If your total number of developers is five or less, you can use the relatively affordable Workgroup edition: above that, you'll have to pony up for the real thing, pricing for which is definitely in the 'Enterprise' realm...
The biggest hurdle to starting to use TFS is installing the darn thing: this process seems to be designed for maximum aggravation. (The extent to which the 'designers' of the 2005-to-2008 upgrade 'process' despise their users even manages to go beyond that: fortunately, you'll be able to start with TFS2008 and won't have to worry about upgrading for a while).
If you follow the instructions exactly, you should manage in 2-3 tries, though, and the hardware requirements aren't as bad as they seem. My 3-developer TFS setup runs quite comfortable on a previous-generation Dell laptop with 4GB of RAM.
One of the big advantages of TFS is the VS integration: this works just really, really well, and shelving and branching are implemented in a more straightforward way than with any other systems I've seen.
The process guidance and support in TFS are a bit less polished, but still quite usable. The pluggable support for several development methodologies is quite nice, and several third-party add-ons (for example for Scrum) are available already.
All in all, it definitely won't hurt to try TFS: if you have a MSDN subscription, you probably already have the Workgroup edition as well as a trial of the full version: otherwise, you can downloaded the latter from Microsoft as well.
UPDATE, April 12th, 2010: With the release of Team Foundation Server 2010, the installation and upgrade procedures have improved a lot. A new TFS2010 install shouldn't take you more than a few minutes (assuming you already have an instance of SQL Server 2008 up and running) and even an in-place upgrade of my TFS2008 setup proved to be entirely painless.
Setup of TFS is not too complicated, when you exactly follow the given guide step by step. We are using it on a small team for about one year now and i don't want to miss it any more.
Especially when you use more than one part of tfs like version control and work item tracking and maybe even teambuild, your team will benefit of the tight integration of the seperate parts.
For example, you can link to workitems when checking in code changes.
Then you run an automated build with teambuild and it will automatically update your workitems with the build number.
So afterwards you can see for example in a bug workitem the buildnumber which contains the bugfix.
We also use the sharepoint wiki for documentation and planning although i'm not the biggest sharepoint fan...
The main point is the great integration into the IDE and for workitem tracking the Teamsystem Web Access which allows you to control at least your workitems over a webinterface.
It's been awhile, but I'm thinking that it takes about a half-day to get setup, plus some time reading the manuals beforehand to make sure you know what you're doing. Configuration doesn't take too long -- you need to add all of your developers in as licensed users. Setting up projects is not too hard. I usually set up AD groups to map on the project roles and add those groups to the appropriate roles. I set up a new project in about 1/2 hour.
Note: I don't use any of the features of TFS except source control. If you plan to item tracking, use the project sharepoint site, etc., your mileage will vary quite a bit. I've found that on our projects (2-3 developers) a wiki works just as well for project management.