Tag Info

Hot answers tagged

23

One of the failings of most bug tracking approaches is they only deal with one side of the equation - the end user's view of the system. This is a critical bug to fix to this can wait a week (priority), this bug is painful to this is an s in a pluralization glitch (severity). A blog post describing multidimensional bug tracking looks at addressing this ...


19

these PMs, that are less technically capable people are ranked higher in org charts. Because at the higher ranks, it's much more about working with people and organizations, and making business decisions. Delegating, resolving conflicts, allocating resources, budgeting, company politics. A good manager really, really doesn't need to understand ...


19

Why should all the team work on a single story? Why not make stories small enough (and independent enough) so that one person (or better, one pair doing pair-programming) can work on a single story. This process also helps better define the requirements and think more both about the problem and the implementation. Estimates may also be become more ...


10

For these types of things, I recommend that you file a defect, issue or an enhancement request as appropriate so that it can be tracked, scheduled if need be, and not forgotten. Get your primary and most important work done before you start tackling the extra. Not only does this help ensure you hit your own deadlines, it also gives others a chance to ...


9

Avoid Task-Tags Using @todos or TODO: in-code task-tags is usually a bad idea, especially if you're part of a team, as they aren't always easy to detect and might require additional tooling (and not all team members might use the same tools). Plus after a few weeks (or days) you just forget about them until they come to bite you in the bottom later down the ...


7

Everyone organizes a project slightly different, so it's up to you to figure out what works best for your needs. Here's what I do, and hopefully that'll help you out. Write down EXACTLY what you want your project to accomplish. Think of it like a start-up pitch: clearly define the objectives of this project and how you're going to accomplish them. Draw out ...


7

Obviously, there are multiple ways to split a project into more manageable parts, but the one way that I find both easy and useful is to structure your project around the features that you plan to implement. First, define your use cases, and make a list of features that you plan to have in your product. Then prioritize the features that the product must ...


7

1. How to introduce QA into an organization. Quality Assurance happens at all levels of product development, from code quality to server environments to user experience. Introducing QA to an organization means looking at all the areas involved and seeing how QA processes and approach can improve the product quality. 2. How to break up QA into parts that ...


6

First off, I'd suggest that other that organizing when items need to be delivered, project managers should stay out of the business of telling the development team when to perform certain activities. The team should be able to figure out for themselves when they need to do what, based on the priorities the project manager makes. That said, meetings are ...


6

While this depends heavily on the size of the user story, in many cases only one developer should be assigned to a story to avoid having your developers step on each others toes. Though larger or very complex stories may require more developers, but it may also be possible to break those stories into many smaller stories that can be individually assigned.


4

You do not need to know the entire system to make changes. In fact, most systems are too large for one person to fully understand. I suggest you do your best to understand the impact of your changes -- your changes will only impact a small slice of the system. Creating tests will help ensure the correct functionality. Does it matter if you are ready for ...


4

You gave an estimate, your client agreed based on it, you got it wrong, you take the hit. It's a harsh lesson, and you did have the option of attempting to renegotiate the cost and or scope, but you got into one more day mode, there's always a price for that. Even if you succeeded in persuading your client to pay for your mistake, they are not going to be ...


4

I say it depends. If you are working on a small project which is indented to stay small, you might be good with a task list. I use Wunderlist for some stuff. Typical projects are things like creating blog systems which follow a "do this from a to z" approach. For projects of which I think (or hope) they become big I use an issue manager or Kanban styled ...


4

I would say that what you are referring to here could better be called 'complexity'. Of course, the more complex a change is the higher the 'risk' is that some new bug may be introduced by an inexperienced programmer. It is not a bad idea to introduce such a field if it is a real issue. However, judging from what you wrote you seem to have two issues: ...


3

I feel your pain and find myself in that situation a lot. I try and do that small stuff "as time allows", but that's very vague. To the question of how to approach the situation: Triage them is my approach. You take a quick look - very quick - and it gets classified as Emergency, Urgent, Routine or Minor. I often do this list/log in excel. Emergencies ...


3

I'd suggest to ask someone to be your mentor that could check what have you done this day/week. We should not be very involved in your development or quite familiar with the product. He can just ask you few questions about your work during 5-minute session: - What have you done since last check? - Are you satisfied with the result? - How can you improve ...


3

In short, it is a team work. Needs a collaboration to achieve the results. As my previous company logo was saying, "Results matter..." The developer and designer in your team need to learn how to work and make job done, rather shifting responsibilities from one to another.


3

Let them go. Concentrate on the bigger things. You'll end up wasting half your time on unimportant things. It's not a bad thing to work on a smaller issue itself, but it could be if you end up missing out on the more important stuff. Get comfortable with your own personality so that you are aware of this tendency. Don't beat yourself up about it, don't ...


3

I don't think there is a "good time" and a "bad time" for a specific type of task throughout the day for anybody that you could apply universally. For example I'm not much of a morning person but sometimes I wake up in the early morning and remote in because something's just clicked and I realised exactly what needed to be done. On most days, you really ...


3

A plain old text file used as a diary/journal works well for tracking both to-do items and anything else about a project that you want to remember. I try to add a line or two whenever I make a decision, notice something I want to get back to later, have an idea for an improvement, etc. Some items get called out with a first word like "BUG" or "TODO". I keep ...


3

IMO this question is more about organizing one's work efficiently than about TDD. I usually strive to organize my tasks to keep myself efficient and focused. So if I find other to-do tasks while working on a specific task, I usually make TODO notes to myself (either in the code or on a piece of paper) and keep the focus on my original task. Once I committed ...


2

Take the bullet points in your question, and make a manilla folder for each one. Put all of the manilla folders in one of those green hanging folders, and label the green folder with the project name. That's it.


2

A good PM shouldn't be a SME (Subject Matter Expert), but it needs to be able to understand one. In other words, a good PM doesn't need to be a strong technical person, but it has to have a minimal understanding. That's why I don't think that a PM can be a PM in any field. So now it depends if they have low or none at all technical knowledge. If they have ...


2

What you want your team to do is called swarming, but not every backlog item can be swarmed around by the whole team. Common thought is that swarming requires some pre-conditions: a cross functional, collocated team a non trivial story a definition of "done" that implies the involvement of the whole team When breaking a story into tasks, the team should ...


2

What we generally do is breakdown the stories into dev / infra / analyst subtasks. Generally anything thats more than a days work is a story. Once the tasks are broken down, one or max of two developers work on a story, depending on the no: of tasks at hand. Usually its one. We log the time spent, and update the remaining estimate at the end of the day ...


2

Your assignment1 is not a good one because it doesn't have any specific or measurable goals for success2. Once you've defined your goals the rest of the process falls into place. 1. How to introduce QA into an organization? [Choose Metrics] Here's the process to follow: Choose your goals (an improvement in some metric). Before you change anything, do ...


2

I depend heavily on my issue tracker, to stop people coming in and taking 10 minutes to explain a problem to me, which, when I have time to do something about it, I will have forgotten completely. By making them write it down, they can compose what they want to say, and the result tends to be more concise. It gives me all the outstanding problems in one ...


1

The thing about ADHD is that it's easy to get distracted and interrupted. So the hack is to use that to bring yourself back to what you should be working on. I set a timer to go off every hour during my work sessions that brings up a message that says "What are you supposed to be working on right now?". It doesn't always help, but lots of times it does. It ...


1

You need to make a generic wrapper for the TaskContext contents. As Thulasi says, use someone else's wrapper for this. JSON, XML, temp files if you have to, even a proper database, whatever. If you want to keep things light code reuse is the way to go. Once you have a task coordinator and a bunch of tasks running you'll no doubt want some kind of ...


1

I would go with the second approach. In my company we are two guys as well, and also use Redmine. We have a separate Redmine project for each project, and Redmine subproject when it has to be. We also have one or two Redmine projects for server/applications management (using the wiki project for documentation). So, our solution is your second approach and ...



Only top voted, non community-wiki answers of a minimum length are eligible