Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am currently working on company which has several products with the same release cycle.
The problem that i got is i will need to create release file which include all files released and what the change for. And there are number of occasions where clients pullback from the change close to the release date.
The difficulty that i got is every time i create the release file, i have to got through all changed file and determine what the change is for and rollback the change if the client decide to pullback.
Do anyone know better solutions for change management that i can offer to management?
Thank you very much
Ps. I try to look at scrum already but i am not sure that it able to address my difficulty.
Version Control
Having a version control system is good, bug using it effectively is better. There are several ways to branch and merge effectively, two that might work for you are "per-feature" and "per-client".
Per Feature
In this setup, you create a copy of the main code (the trunk) for each new feature that you implement. Once the feature is complete, merge it back into the trunk. If you update the trunk before the feature is complete, or you complete a different feature, it is possible to merge those changes from the trunk into all of the branches.
Per Client
Same as per-feature, but each client gets their own branch, so that a feature rolled back for one is not removed from another. To combine the two, you might structure your repository like this:
Repos
+---Core
| +---branches
| +---tags
| \---trunk
+---Client1
| +---branches
| +---tags
| \---trunk
\---Client2
+---branches
+---tags
\---trunk
Project Managemet
Now, to address your actual question. I can't really say much about this from experience, but I am planning to add Trac to my project soon, because it looks simple to use, and it's free. You can see from their site how Trac's developers use their own application to set milestones and organize issues. If you want to look into more possibilities, then Wikipedia has a few lists.
You're probably best using a source code repository such as Git, Subversion, Mercurial etc.
Which one to use depends heavily on your needs and platform, however you're probably new to SCM tools so I'd recomment subversion with TortoisSVN.
There is a solution to your problem using ]project-open[, but it's not an easy one:
]po[ includes a ticket tracker that you can use for tracking your customer's change requests.
After implementing a change request, you need to include the #ticket_id in your commit comments, so that ]po[ can associate commits with change tickets. You need to have the ]po[ package intranet-cvs-integration installed and configured correctly for this purpose. The package name includes "CVS", but it can also integrates with SVN and GIT.
Finally, you have to create a script that applies the commits selectively to your code baseline, depending on the status of each change ticket.
This way you can automatically produce your release files, depending on the status of your change tickets.
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 3 years ago.
Improve this question
I hope that somebody with more experience (bad or good) can help me out here: I am setting up a project tracked in JIRA. The whole process with user stories, documentation, sprints, workflows, bamboo and fisheye integration, etc. is set up. But now I have a rather administrative question:
Where should developers log their work in meetings, such as stand-ups and retrospectives and for writing specifications (detailed descriptions of user stories to come)? I really cannot see what makes sense here, as I need the developers (obviously) to track this work, too. As far as I can see, the possibilities are:
Separate PROJECT-ADMIN JIRA project with simple, non-agile issues
Separate and parallel sprint with admin tasks
Administrative tasks for each sprint
Other versions??
Option 2 seems very hackish, as parallel sprints are just in a beta-stage for the JIRA agile (former Greenhopper) module. Option 3 seems a bit much work to setup for each sprint, and I am not sure, how this influences my velocity (ideally, I want to see the possible amount of story points that can be achieved in a sprint). Option 1 seems the most reasonable to me, but others have advised against it, unfortunately, without offering a solution. I haven't really looked into option 4, as IMHO this is very similar to option 2.
I couldn't see any best practices anywhere, so I would very much welcome any advice from more experienced people. Thank you very much.
We use Tempo to log our billable work against JIRA issues, whether a single Epic for a small project or individual tasks for a larger project. For non-billable work we have a single project where people can optional log work, and we also use it for planning our time. So option 1 is the closest there. We could also have categories for different work logged in Tempo and handle this case that way.
So I face this exact issue with my team and this is what is working for us (for now) YMMV.
Our current structure is that we have a Roadmap type project (call this Planning) where all issues come into at first. Thereafter we create issues in related product projects (call this Product).
In the beginning of the lifecycle, any meetings, scoping, etc will have sub-tasks created and the time will be tracked on Planning. Once scoped and scheduled for work a new issue is created on Product and linked to this original issue.
Once the Product issue is assigned and the dev is called to any meetings whilst this issue is in a sprint we will create a sub-task on Product and assign the time. If the issue is not in a sprint we go ahead and create a new sub-task in Planning and assign the time there.
When then also have a project where we do Housekeeping type work. So if we need changes to JIRA, Stash, Confluence we will create the issues here. We will then create a new issue on Planning, link the issue and schedule that accordingly.
We have a meta project that acts as a bucket for anything that doesn't fall into the other categories which we sift through every now and again to identify if we need to create separate projects.
I have created a custom field that rolls up all the times of any linked issues found on the Planning board
Have a look at the Twitter blog Visualizing Epics and Dependencies in JIRA by Nicholas Muldoon maybe this can help you in some way too.
One caveat we are still exploring the best way to do this. Each environment is different and what works for us might not work for you.
I have faced the same issue trying to track team member hours that are unrelated to the project or related to the project but not to a specific story or task.
Initially we went with option 3 & had several administration tasks that persisted across sprints. While this was relatively easy to implement it failed for us as we had team members that sat across multiple projects & as a result these administrative tasks that resided in each project were impossible to manage / report on for these team members.
In the end we went with what you have described as option 1. By creating a separate project with "non task related" issues such as Planning Meetings, Technical Issues & Client work then installing the JIRA Misc Time Log & Report Extensions plugin we could provide users with an easy means of logging times without having to change projects or boards (since the plugin adds a dropdown menu to the top navigation).
The plugin then allowed us to get reports on where team members we logging time off project regardless of how many projects they worked on concurrently.
I was having the same issue, and I know some time has passed since the moment this question was posted but maybe this is useful for a lot of people:
Tempo has a dedicated feature for that thing you want to achieve and is called Internal Issues. not to be confused with Internal activities.
You can go there by navigating to Config>System and then click on the add-ons tab. Then scroll down to the Tempo section in the menu on the left bar and there you'll find a link that reads Internal Issues. There you can create the issues. Please keep in mind that before creating internal issues you have to create the tasks, for instance "Sprint Planning" or "Retrospective" in the project without assigning to anyone, just to the project.
When your users go to log their time for those "Internal Issues" they go to Tempo > Timesheets and then click in the upper right button that reads log work. There, in the right menu they'll see the "internal issue" option where they can pick those internal issues you previously created and log the time that the team spend on SCRUM Ceremonies.
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 9 years ago.
Improve this question
Do you need a project management system if you work alone? I mean a project management system that includes issue tracking, wiki, etc.
Currently I keep my issues in a very good organizer software and I keep project documentation in Word files (and of course I have a version control system), so I am not really sure if I need a project management software, because I work alone.
One useful thing, I can think of, that project management system can additionally give me is linking issues with commits (UPDATE: I've found this feature useful enough: for example, right now I am creating documentation for the new release of my project and I consequently open every issue with "Pending for release" status, then I read the issue's description and then I can quickly view the diff of the commit for this issue - this helps me to see details and write better documentation).
Another one - sharing issues so your users or your employer can view or manage them.
What am I missing? Is project management software necessary when working as the only programmer?
UPDATE: I've thought up another useful thing: In comments we can give a link to an issue or a wiki article with detailed information about the code being commented.
You say you use some organizer software that helps you managing issues. So you already have your custom project management system. Just keep it.
Project management systems does not have to be big, support sharing data or other kinds of documentation. As a programmer you are supposed to use one to make your work organized, but it doesn't matter which one. You can happily use plain text files if they work for you.
Still, if there is even a slight chance that you'll be cooperating with someone, you should try something that allows cooperation... just to know how they work.
Do you need a project management system if you work alone?
Yes.
Currently I keep my issues in a very good organizer software and I keep project documentation in Word files (and of course I have a version control system).
See. You have a project management system. Why ask?
project management system can additionally give me is linking issues with commits.
That's not necessarily project management. You can easily do that with you version control software.
Read this: http://tortoisesvn.tigris.org/issuetrackers.html
sharing issues so your users or your employer can view or manage them.
That means you're not working alone, if you're sharing something. What are you asking for here? How to share?
When working alone is the key thought to pursue here. When you are alone, you don't have the luxury of having someone else to keep you on your toes. A good "system" is essential therefore in order to help you manage your projects. As to which system to employ, that all comes down to your individual needs, and how much time you want to spend maintaining such a system.
If there is any possibility that you will need to involve someone else, then you need to decide if the system you use will scale to meet your changing requirements. This is also true if you continue to work alone and your workload changes.
As for software, that is almost another question entirely. I personally prefer to use a software tool to track all of my tasks, and to help me to collate data that helps me to determine priorities and task scheduling. That is in a nutshell what project management is all about. When working at home on my own projects, I use a simple Redmine configuration to manage different types of projects. Planning for programming projects, working out the logistics for my wedding, even managing my house renovations. All have been added to my private Redmine setup because I'm too lazy to try and keep paper-diary styled systems updated. At work, I have a more complex configuration to manage the myriad of programming projects we have here, and to manage the dependencies between them.
I've found though, that the most important thing is to ensure that the processes are streamlined, and that the supporting tool can be configured to match the processes. You don't want to have to change your processes because the tool isn't up to par. Also, the tool should not become the sole focus of all of your efforts, therefore it should be configured to reduce the "red-tape" side of things. You only want to capture enough information to describe your tasks, and to determine when they need to be done, who will do them, and when they are completed. Yes, your needs may require more information to be captured, but always try to minimise this, as you don't want to feel like you are always updating your project management tool when you'd rather be working on that latest killer algorithm you've been looking forward to doing! ;-)
I would not want to work without a system like trac anymore, even if I'm the only one working on the project. You should use a version control system of course, no question about that. Then there are two or three things coming up, you also mentioned.
First is documentation. There are lots of different possibilities and a wiki is just one of it. I personally use the wiki mostly for ideas, thoughts and notes. It's easy to put drawings in it, link to ressources in the web and really quickly edit. This can not replace in code documentation you do with source comments or tools like doxygen. And this can also not replace a manual, if the project requires one.
The second thing you'll come across is some kind of todos, let it be bug reports (even from yourself), feature requests, things like that. You can put them as comments in your code or use a list in a text file or your PIM system, but you can also use a ticket system, just to keep track of what you want to or have to do in the project in the future. You can not do everything just now.
Third is the bigger plan, this is not just atomic todos but things trac calls milestones. This has to be written down somewhere.
The great thing about trac now is, you can integrate all these thing you have to do anyway in one tool and even cross link between all the parts. Link to code lines from a ticket, reference tickets in a commit message, use ressources from your repository in the wiki, automatically build doxygen and integrate it and so on. You must decide if you want to use trac for all the things around your project or something else, but you have these things anyway so why not use a system integrating it all? ;-)
I mean a project management system that includes issue tracking, wiki, etc.
I don't use an Issue Tracker, but I practice continuous (not "big bang") integration, and I test (look for bugs) early and often, and I fix any bugs as soon as I find them, so that list of known Issues remains small.
I also have a lot of structure in the source code (e.g. separate projects/assemblies for separate components), so I try to have "the code is the documentation".
The table at What Types of Documents Should You Create? implies that you may not need documentation (e.g. a wiki), unless you're working with other people: e.g. with a manager, testers, and/or end-users.
You may be the only programmer now but will it stay that way forever? I often work alone on development projects but I still track the "to do" list and issues in a simple Access database. Makes it much easier if you need to expand/hand over a project.
You absolutely do, at least for a bigger projects that take a few months. For the past years I tried :
eclipse notepad plugin - just text file - effective
eclipse mylyn tasks - better, enough for one-man-show, but I was still having issues with migration between eclipse instances
youtrack is free and it's like a JIRA but more simple and practical for an individualist
With notepad I was able to focus on current task, but I wasn't able to maintain long term iterations, because without issue tracker I was loosing discipline, dealing with 3 tasks at the same time, not finishing them, etc.
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'm not sure if this an appropriate question for stack overflow. If not, I apologize.
I was wondering if there is any tool for keeping track of different uncompleted tasks in different modules of a project. I'm currently interning at a company and I feel like everytime something cannot be solved immediately, someone asks me to put a 'todo comment', and that task eventually gets forgotten. I was wondering if there's a better way to keep track of stuff like this.
Thanks.
Trac is an issue tracking system that you can use for this purpose, but you have to enter manually each ticket into the system, but once you're get used to it, it is very useful and effective.
Any issue tracker system also works.
Eclipse will keep track of comments with // TODO in it. There is a "tasks" window which will list them all.
I suggest you to use Post-Its for each Task. You can also use Kanban to manage those tasks. It's very easy to learn and adapt to your needs.
You can split a whiteboard into some sections like Backlog (for pending and new tasks), Work in Progress (you limit the number of possible concurrent tasks), Deliver/Deploy (almost done), Done.
If you want a computer tool, there are lots of them. Just google for Kanban software.
http://www.infoq.com/articles/hiranabe-lean-agile-kanban
Lots if IDEs will keep track of // TODO comments if that's the route you want to take.
To keep track of todo items outside of and IDE, you can try ToDoList
It's free.
Pivotal Tracker looks quite nice as project management tool.
Here's the CodeProject link to AbstractSpoon's ToDo List
It sounds like whichever system you're using at the moment (if you're using one at all) does not make to-do lists a priority or put to-dos/tasks in your view every morning that you log in.
Sounds like you need something that:
Allows you to assign different tasks/to-dos to different modules of a project
Keeps an organized view of which task/to-do has been assigned to which project
Sets alerts for each separate to-do/task (due date, percent completed, etc)
Keeps the tasks/to-dos easily viewable (from the dashboard, or put in a prioritized view as soon as you open a project)
A company that I do contract work with, WORKetc, can do all of this. On top of this, they have a huge amount of other project management features, to name a few:
Collaboration on all aspects of a project
Unlimited sub projects
Gantt charts
Project dependancy
Timesheet/milestone billing
To-dos, tasks, easily assignable to specific people/specific projects/specific sub projects, with necessary alerts
The cool thing about WORKetc is on top of being a project managemement tool, WORKetc also has CRM and billing features. It is essentially a total business management platform and that way if you're using other CRM or billing software you can get rid of it entirely, and not have to worry about integrating seperate projects. Even if you don't use these features, I bet its still a better bargain than the majority of the other ones you'll see!
Pricing/website link: http://www.worketc.com/sign_up
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
My company has been using JIRA as a requirements tracking tool as well as a bug tracker, and it's been working pretty well while we've been working on one project at a time.
We now have a scenario where we have three different project proposals whose requirements partially overlap (e.g. requirement 1 applies to projects A and B, requirement 2 applies to projects B and C, etc.). I'd like to be able to enter a single JIRA issue for each requirement, but that doesn't appear to be possible since JIRA issues and projects have a one-to-one relationship.
Has anyone found a way to do this in JIRA, or maybe with some other tool that integrates with JIRA ?
While there's no single correct answer, I can offer an idea. I don't have enough information about your work process, but you mention that you have project proposals. So I'm assuming projects A, B and C are in early stages. Requirements gathering and such, no bugs yet.
Set up a single JIRA project, say, "Early Requirements". Put all the requirements for projects A, B and C into that JIRA project. To allow many-to-many relationship between requirements and real projects, set up a custom field of type "multiple checkboxes" or equivalent, and configure "project A", "project B" and "project C" as its values. For any requirement you can check which project it applies to.
Now - and I am making more assumptions here - let's say some proposals move on and some die away. You will need a process to a) extract all the requirements for real project A into a newly created JIRA project for A - this can be done via search & bulk clone issue; b) purge all requirements that have no live project associated with them - search & bulk delete.
Caveats: if you need to share requirements with different customers, it will get tricky. Permissions are configured per JIRA project & issue type.
Having said all that, JIRA lacks features for decent requirements management, such as baselines and traceability. But it may be ok for just collecting data for further work.
We use the "duplicates" or "relates to" function of jira.
So you raise an issue in each project, but you relate them together. That way you can have one issue "owned" by a project and you can close out all related projects once the changes are tested on each.
You could even use depends on linkage if this makes sense in your project setup.
We have the same problem. In the case where you have an issue (a bug or new feature) which involves multiple products and that have dependencies between them. (As an example lets say we have a server, a connection api and a client application). If there is a new idea about extending the client application in a certain way, it is quite possible that also the connection api and server need some kind of extension. Probably they are developed by different teams... So not handled in the same sprint / iteration, but as a product owner you want to keep track of all these new features as a group.
What we did was actually created a few custom fields. The first field we introduced was a 'Cascading Select', as 'Program' and 'Phase'. This gives the product owners the possibility to group the issues under a program and do some rough long term planning (several iterations).
Then we added another field (Text Field) for 'Epic' (or 'Theme') this bundles the issues related to a certain Epic / Theme. The idea is to use 'Epics' within a 'Program'. In case of an larger 'Program', you can probably separate it into different parts, which then get reflected in these 'Epics'. (A kind of storyline. A group of stories (which can spread over multiple products) which add value as a hole to the series of products).
Both fields make it now easy to filtering out issues, that cross multiple products, based on Program (with or without its Phase) and the Epic.
Indeed with linking enabled, you can now also create dependencies between the different issues, in the different products. And it is completely separated from default Jira product versioning. Which is great, so the normal release process stays as it is.
Another idea I'm thinking about to introduce is the field 'Iteration'. When going into the planning session (or just after it). This field could be updated with the name of that sprint (Jira is great in multiple issue editing / updating). Which then makes it easy to filter out all the issues for that sprint.
What I like most about using Jira also as a Scrum planning / Sprint tracking tool, is that you do not have a separate planning and backlog tool. Bugs are more visible. No double administration of bugs into planning tool and or planning items into Bug tracking tool (for the correct cvs/svn/etc commit numbers). Or the generation of release notes.
You're probably better of using confluence in addition to jira, in this case.
Use Jira for what it's best at, and use Confluence for everything else.
Divide your various projects into shared "sub modules" if you feel that is useful, however I would be inclined to suggest using Jira mostly for tracking actual implementation and associated bugs.
Another approach is create a multi-select custom field with hyper links (like 'XYZ-123') to issues as options.
Better way is to distinguish issues used for development tracking and requirements that often are the same at 80% for all your projects.
Solution exists: Rmsis a JIRA plugin:
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
I am using subversion as an RCS and Bugzilla for issue tracking. And i just ask myself how to create automatic change logs for the users?
I already tried the "svn2cl" tool. But the change logs it creates are to technical for me (e.g. no user want's to know that developer XY changed 20 files yesterday to fix a memory leak). A user wants a change log which contains something like this:
Version 1.0- Added feature 1Version 1.1- fixed bug #4711- added feature 2...
Does anybody know a tool, addon or script to create change logs from my bugzilla entries? Or is there an good way to do this?
I know trac supports the creation of change logs, but i don't like trac very much.
Update
Wrote my own little tool for this job. You can get it at ChangelogGenerator.
There is a sourceforge project called Bugzilla Changelog which generate this log as HTML or Wiki - text.
See: Bugzilla Changelog Project
Using a custom tool which logs in a database changes per project, module etc. these changes are then exportable to files using a custom addin for finalbuilder for readme production, or exportable to a webservice which imports them into a local db for the webserver so users can view/search online what's changed per module.
i think you can have Bugzilla generate it for you.
Use the Advanced Bug Search screen, filter on the milestone / version, on the status and resolution.
Then you can export it as CSV format and work on it in Excel
Excel? :)
I'm assuming for each version you first create a list of features to implement, changes to make, bugs to fix etc. Somewhere the status of these must be tracked so you know what is complete, what has been pushed to a later version and so on, and when it's time to test and ship.
This information in your tracking document pretty much contains everything you need.