We're using Redmine to log and track all of our tasks, bugs, and features. We have a one month release cycle and it's important to ensure that the order of the items in Redmine corresponds to the relative priority of each item, so that people are not working on less important stuff.
Currently to achieve this we created a custom field in Redmine called 'rank' and assigned each items a integer from 1-1000. This works initially but re-ranking items and reordering is just painful because the same item ends up being edited many times to get it in the correct place on the priority list. Is there any way to be able to drag and drop items to reorder them? I doubt we have a unique requirement, there must be some way other people are doing this??
Thanks for the help in advance,
Max
Have you looked at the Stuff To Do plugin from Eric Davis? It may be close to what you're looking for -
http://www.redmine.org/projects/redmine/wiki/PluginStuffToDo
https://github.com/edavis10/redmine-stuff-to-do-plugin
It doesn't look like there is an existing plugin to do this. It has been raised on the Redmine forums, but nothing seems to have come of it:
http://www.redmine.org/issues/9183
Thats right, There is no existing plugin to do that. Stuff_to_do is user-level organization of tasks assigned to him and drag-and-drop to recoorganize the tasks from/to 'current working list', 'recommended list of tasks' and 'available list of tasks'.
I kinda feel there should be an alternative to your requirement. Why should we rank the tasks? We should probably conduct scrum/stand-ups and assign list of tasks to each person and reorganize the order in the stuff_to_do plugin so that the developer checks off the tasks in his list.
Also you can group the related tasks together using 'Related Tasks' option in each issue. Add an issue to be a 'follower'/'predecessor' to an other issue.
Use better reporting using 'custom queries'
Use Redmine_whining plugin to remind developers.
These are just my view based on the exposure I got in the area of Agile Product Management and Redmine plugins
Related
I'm starting a new software proyect and I wanted to use trac to manage it. Mostly because I love it's wiki and I love the way django use it.
One thing I'd like to avoid is to pollute the development board with bug reports and viceversa. A quick round on google left me bare handed so I'd like to ask if any of you have experience setting up trac with different boards, one for regular planning and other for bug tracking.
Opinions?
It's up to you to organise it and there are several possible ways. In my opinion the best is to define two different ticket type groups (see http://{yourTrac}/admin/ticket/type), one for the plan and the other for bug handling:
plan:
'workpackage' for grouping
'enhancement'
'modification'
'task'
=> insert tickets of type enhancement, modification and task as children to tickets of type workpackage (e.g. using MasterTicketsPlugin)
bug tracking:
'bug'
Then use the Trac query language all over your ticket queries and Trac plugins to separate by ticket type, and insert them separated in your wiki pages and milestone wiki-language descriptions, e.g.:
[[TicketQuery(group=type,format=progress,type=enhancement|modification|task)]]
[[TicketQuery(group=type,format=progress,type=bug)]]
[[BurndownChart(milestone=v1.0,label=Plan,startdate=2014-10-20,enddate=2015-05-25,type=enhancement|modification|task)]]
[[BurndownChart(milestone=v1.0,label=Bugs,startdate=2014-10-20,enddate=2015-05-25,type=bug)]]
[[WorkloadChart(milestone=v1.0,type=enhancement|modification|task)]]>
[[WorkloadChart(milestone=v1.0,type=bug)]]
[[TracJSGanttChart(milestone=v1.0,type=workpackage|enhancement|modification|task)]]
[[TracJSGanttChart(milestone=v1.0,type=workpackage|bug)]]
One approach is to add the bug tickets as child tickets to the appropriate tickets of the plan if they are the result of the development and fall out during the testing period.
If your goal is to keep the list of tickets that represent your development plan for forthcoming release(s) separate from the untidy thicket of tickets that represent issues being encountered by users of the current release, how about using ticket "milestone"? So, "bug" reports would be opened in the "current" milestone, task planning (for potentially multiple future releases) would be associated with non-current milestone(s). I assert this allows for clearer description of items in both the current and the forthcoming release.
Someone opens a ticket complaining about how things work right now. If you decide you should address it for current users, you leave it in the current milestone (though you might reclassify it a "task" or an "enhancement"). If you decide it must wait for another release, you move it into a forthcoming milestone, but can choose to leave it called a "bug", it doesn't have to be reclassified as a "task".
Likewise, when you're testing the unreleased code and find a problem, you can call it a "bug", but in the forthcoming milestone; again, it doesn't have to be a "task" just to be considered part of the development plan.
is it incorrect practice to add additional states and time tracking to the feature work item types? I read that the time tracking fields are available in tasks, i don't see anyone trying to add it to features. Our BA and Dev find that time tracking at the task level to be overkill. i presume additional states is fine, but maybe we are not thinking of features in the right way.
I was reluctant to post this question at first as it seems like functionality that could be pretty fundamental to the way in which TFS manages work items, but I cannot find anything documented that covers it; how do I categorise TFS work items (more specifically, new tasks)?
I've created a bunch of tasks. Some may fall under 'solution setup', others fall under 'core development' for example. How do I represent this categorisation in TFS? Is it something I need to consider when I'm creating the new tasks? Or are the work items brought back in this way during the query?
There are a handful of ways that people typically categorize/organize their Tasks:
Group tasks by User Story. This is done by linking the WI's, and this information will show up in WI Queries, and on the Task Board (task board only available in tfs 2012 and up).
Use the Area field and Area hierarchy to categorize your Tasks. The Area hierarchy is typically used to represent a functional breakdown of your application, then applied to WI's to categorize them based on which functional area they affect.
Activity Field. There is a field on Task work items called Activity that by default that has the values: Deployment, Design, Development, Documentation, Testing, Requirements. This list can be customized by editing the Work Item Type Definition.
Surprisingly difficult to find anything on this. I was already using 'linked item' as I should, the problem was the query. I created a new query and set the type to 'Tree...' so that the hierarchical structure was pulled back in away that mimicked a tasks and sub-tasks structure.
I was thinking that I’d rather only use the Task Work Item and ignore the Bug Work Item. This is my thinking as I set things up for my team. I’m on a quest to see why I shouldn’t do this. From my perspective a Task is either a new item or a bug item. There is no need to use two distinct Work Item Types. To make this happen in TFS I’ll start with the Bug Work Item and create a custom field (“Item Type”) to distinguish the two task types: new/bug. Both new tasks and bugs will share the same fields. Anyone see any major drawbacks to this approach?
The main reason Tasks/Issue/Bugs/etc are different work items are because the individual fields of each work type can be configured differently.
For example, by default, Bugs have a Triage property, Issues have Due date, Tasks have a Discipline. The States of a Bug (Active/Closed/Resolve) are different from an issue (Active/Closed).
By merging them into a single work item type you would loose the ability to configure each one uniquely.
Also, the rules followed when a Bug and Task are closed, for example, are generally different. Segregating them into work items allows a simpler rules set.
Work item type is also a standard column in all queries.
Overall, it depends on how extensively you are using Team Foundation. If your project is small, and the above don't matter, it's not going to hurt. Though I don't see much gain either.
I would suggest keeping Bug and dropping Task if you want to merge them. By default when you check in code and Resolve with a bug, it sets the status to Resolved and assigns it to whoever created it - usually a tester, but in your case possibly a PM. That person can then test to confirm the work is done and close it. You can set up alerts on their work items so they get an email and know that progress has happened. Alternatively if you use Task, when you Resolve at check in it is just closed. No alerts, no further testing. YMMV but on some of our projects we use Bug for things like "user would like to add a new report" and it fits our process well. (For others we keep the distinction for reporting purposes.)
It all boils down to 3 things:
Creation / prioritization
Reporting / Notifications
Completion workflow
Typically creation of a Task involves different fields than a Bug. For a bug you'll want to know things like environment found in, who notified you, severity, priority, etc.
For tasks you usually want to know the requestor, reason behind it, business unit impacted and iteration it is scheduled for. Tasks might be long term goals that result in new or enhanced functionality.
Reporting and Notifications of the two are generally different as well. PM's are going to track tasks to ensure deliverables are met, your tech support area is going to track bugs.
Next, bugs will generally result in hotfixes and service packs. Depending on severity this this might involve a high priority push through QA and release as quickly as possible. Tasks are more laid back and will go through all forms of regression and regular testing with a period of acceptance by the impacted business unit.
Finally, bugs may impact previous versions of your software. Tasks will almost always be for either the version currently under development or the one after that.
In short, they are fundamentally different things. They might share most fields in common, however by combining them you are restricting yourself in both reporting and workflows. Today this might be okay; however within the next month or next year this could seriously restrict you.
Considering that maintainence of work item types is an incredibly easy thing there is almost no benefit to merging them.
It happens sometimes that one feature seems to belong to more than one place.
Trivial example, let's say I've got the following menus :
File
Pending orders
Accepted orders
Tools
Help
I've got a search feature, and the same search window work for both pending and accepted orders (it's just an 'order status' combo you can change)
Where does this search feature belongs?
The Tools menu seems to be a good choice, but I'm afraid the users may expect the search accepted orders to be in the accepted orders menu, which would make sense
Duplicating the menu entry in both pending and accepted order seems wrong to me.
What would you do? (And let's pretend we cannot merge the two orders menu into one single menu)
I think the problem you've run into is that you're thinking like a programmer. (code duplication bad). I'm not faulting you for it, I do the same thing. Multiple paths to the same screen, or multiple ways to handle the same process can actually be extremely beneficial. I would guess that more than one person is going to use your program and each probably have slightly different job functions. In essence, they have different needs for the application and will approach using it different ways. If you stick to the all items have one way of being accessed, some people will find the application beneficial and others won't. Sure all people can learn to do a task a certain way, but it won't make sense to some users. It's not intuitive (read familiar) to they way they are used to processing information, which means the application will ultimately be less beneficial to them. When people find a process (program etc.) frustrating, they won't adopt it. They find reasons why the process will need to be changed or abandoned.
An excellent example of the multiple approaches to a problem is with Adobe Photoshop. Normally there are at least 2 different ways to access a function. Most users only know of one, because that's all they are concerned with, but most users are really comfortable with using one, because it makes the most sense to them. With a little extra work, Adobe scored a huge win, because more people find their product intuitive.
Having a feature in multiple locations is not a bad thing. Consider the overall workflow for viewing both pending orders and accepted orders, and think of your new feature as a component, rather than a one-off entity.
After you map out exactly what tasks a user completes in the pending and accepted order viewing process, see where having the ability to search would provide value (by shortening the workflow or otherwise). This is where your search component belongs.
The main thing to remember about UI is that all that really matters in the end is whether your design makes using your application or site a better experience for your users.
In the search example you list above you'll commonly see apps take two approaches:
Put the search feature in a single location and allow the user to filter the search by selecting pending or accepted, or
Put the search feature in both menus, already configured for the type of search to be done based on the menu it was launched from.
If you repeat the above choice for a number of factors you'll see a much more advanced (aka 'complicated') search interface for number one, and a much simpler (aka 'restrictive') search interface for number two.
Which one is best completely depends on your users. This is why many general applications have a simple search by default and a link to a more advanced search for those that want or need the additional capabilities; they're attempting to make everyone happy. There is absolutely nothing wrong with that if you're writing for a wide variety of people with different needs. If you're writing for a set of users with a restricted set of needs however, you can make some better choices.
In my experience your best bet is to work with one or two of your primary users and map out all of the steps they need to take to get each of the tasks the application will be helping them with accomplished. If there aren't a lot of branching points in that sequence of steps there shouldn't be a lot of choices or settings to make in the application; otherwise the users may feel that the app is harder to work with than it needs to be.
For the search example above, if the user has already navigated into the Pending Orders menu, the likelihood that they'll want to launch a search for Accepted Orders is very small and having to make that choice, or go elsewhere to do the search, will be an extra decision or action they'll need to take. Basic principle is if your user has already made a decision, use it; don't make them tell you again.
Use the UI you come up with as a first cut. Let your users, or a subset of them, try it out and make suggestions. If you have the option, watch them use it. You'll learn far more about how to improve the interface by seeing how they work with it than you will from what they tell you.
Generally you do not want the same menu item appearing in different menus. It adds complexity and clutter to the menu, and users will wonder if the two menu items are really the same or not. When it appears that a menu item belongs in two places, then you may have a more basic problem with your menu organization.
For instance, your example shows a menu bar that is organized by the class or attribute of the object the commands within act on. In general, the menu bar should be organized by category of action not type of object. For example, you could have a Retrieval menu for commands like Search and other means of displaying orders, and a Modify menu for processing the orders (e.g., updating, accepting, forwarding). Both menus would have menu items that apply to both types of objects, although some commands may apply to only one.
Organizing commands by object type is actually a good idea but it is better accomplished with a context menu (right click) than the menu bar.
I would try the search in both the Accepted Orders and Pending Orders menus. However, user testing will show if this is a good idea or not. But it also depends on your user base.
You are doing user testing right?
...you may already know this, but this is a good place to use the command\action pattern IMHO.
So to answer your question: IMO, yes, it is ok :) This situation is definitely warranted.
Just put it under both menus and have it open your search window, pre-configured for the order type who's menu it was launched from. Name them accordingly and voila they're actually two different actions - even though they use the same code/component.
Keep the user-selectable "status combo you can change" in the search window active though so the user still can adjust the settings without relaunching it from the other menu... and then perhaps rethink the structure, see some of the great answers in here for ideas ^^