Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
I've sort of been trying EBS on my personal project tasks, but two things have come up a couple times I'm not sure how to handle.
1 - I find some hidden task(s). I thought it was going to be 6 hours to do task X, but turns out that requires a new Ant build task, which requires libray ZipBlahBoo, which I have then get into ivy, which requires some investigation into the XML parsing library versions each uses. I want to note these new tasks in my list, but that disrupts the estimation impact. I might have taken 6 hours for the actual original task, but there were another 8 hours in hidden tasks.
2 - I'll often have tasks that are mutually dependent. I need to update the Foolet service, but that also means updating the API, which means updating the Mock Foolet service used in unit tests. I've got each of those called out as 2 hour tasks, but I don't do them serially, I do them concurrently because the system won't work until it's all done. Let's say the set of tasks takes 15 hours and I know overall I took 13 hours, but I don't really know all that well how much of that 13 hours any of the specific tasks too. From an EBS point of view, how do I track the time it took to complete each task?
Any suggestions?
Evidence based scheduling should work best if you just charge all the hidden sub-task hours to the task that spawned them. This way, it will begin to transparently factor these occasional overruns into your overall expected performance and therefore produce better projections.
You're splitting too finely. Updating a test harness to account for an interface change shouldn't be a separate task from the interface change itself, unless the test harness is a separable product.
That's a case of not being good at foreseeing all the hidden tasks, so you should add all these hours. Basically, you do 14 hours for that, including the stuff you aren't foreseeing right now. Of course, you still estimate "6 hours", and then apply the multiplier computed from past evidence.
Well, that's tough. I suggest you either estimate, and live with that, or stop splitting such tasks.
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
What I mean is if I am breaking a programming project estimate down into tasks as much as possible would there be a good maximum to make the tasks. Meaning if I say the max is 4-6 then if any task is more hours than that it needs to be broken down into more tasks. I feel like there is a point where this becomes not much more useful though and think that a max of 10-12 hours is acceptable, the boss does not agree. The idea here is to be able to know as well as possible how much time is needed to complete the task but at the same time I think there is a point where too much breakdown is meaningless until you actually dive into the code. Any thoughts or common practice?
Make the breakdown structure detailed enough to allow you make a proper estimation, but not too detailed so you'll have trouble maintaining and tracking it later, when things change (not if things change, but when things change).
It doesn't really matter the number of hours a task in WBS is estimated.
When I was writing my own time breakdowns for a task, I found the most useful number to go with as a goal for a single task to be max'd at about 4 hours. Then, if it turned out to be really difficult and take a lot longer than I expected, it wasn't so terrible.
I don't think it is useful to actually hold any of these projects as meaningful unless:
1.) The person performing the task created the projection.
2.) The person creating the projection is familiar enough with the work.
At my last job, I didn't even start projecting tasks until I had been there for three months. After that, it was another month or two before my projections were meaningful.
I think that this is a very individual thing. If you are used to thinking about things at an extremely detailed level, it makes more sense to have lots of small tasks. If you like to think of things in more general terms, it makes sense to have a few big tasks. I believe if you and your boss try and enforce this sort of personal preference into task projection, you will find that your projections are meaningless at best and a creator of hostility at worst.
I hope my experiences and expression of them is useful to you.
-Brian J. Stinar-
What does a task look like?
write a document? Write a chapter of document? Write a sentence in a document?
Write a programme? Write a class? Write a method?
I think the following need to be true:
1). A task is big enough so that you know you've finished it. A single sentence or method doesn't stand alone. You typically can't deliver something that small in isolation, the receiver can't "test" it.
So, for example, you can unit test, document and check some code into an SCM that's a task.
I can't imagine tasks smaller than one hour, and typically for me they are half-days.
2). A task is small enough that you can be confident you can do it in the estimated time. You've analysed the problem well enough to understand the chunks.
People are not machines.
Having that said, the way I see it there are two main development modes:
develop
Maintain/fix
For the second one you can gain experience on how long tasks should take - the developer knows the code and most of the times he can give a good prediction what is wrong and what should be done to make it work (in that case tight monitoring + buffer to keep getting good cooperation is in order, if the developer can't get a good estimation - that is an indication of a very big problem)
For the first one - it's more complicated:
if this is hard labor job - one that requires no brain and just take the program from point a to point b than... you can define tight schedule.
If you need the developer to get creative, to think about good implementation etc... You can not wait forever for a masterpiece, yet you will not get much from a developer that have only survival thoughts :)
Learn about Agile -where the team leaders and the developers sets the goals together- the goals may be very demanding but within the development period the developer which feels as responsible as the manager... can manage his time.
So sometimes, with the correct management system - tasks can and perhaps should be a week long.
There is no magic number. Understand your type of programing and find an appropriate management management system.
Good luck
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
would like to explore what are the general practices in
dropping features
make a decision to delay the project schedule
design the features in a way that can be dropped with lesser pain
delay a project schedule with good estimation without re-delay again
preparation for project completion to avoid delay in schedule
Please note that it is not a question on schedule planning or management but more focus to time frame close to project completion.
I understand this is a question with no absolute answer.
If you get to this point and you don't have a plan, you're already in over your head. Most likely people are getting panicked and worked up and probably not thinking straight. That's also why people do fire drills. So that if the time comes to do it, they already have the process in place.
In this case, as soon as you start a phase of the project, you should have a prioritized feature/bug list in place. And then there should be two cutoffs to the list. The first one is the bottom of the list and includes everything. The second one is the minimum allowable for that deadline/release. And yes, they should be different. Think of them as the "must have" and the "nice to have" list.
Now that you have everything prioritized and you've set expectations that "if things run late, we start dropping things from the bottom", you'll have a much easier time in doing so if you have to. And of course, just because you drop it for the immediate deadline, doesn't mean you have to wait until the next big delivery for it... maybe a point release or an interim delivery is acceptable?
Or maybe the things that were dropped aren't all that important anyway? If that's the case, they may always stay at the bottom of the list and you may never get to them.
All of that said, it doesn't necessarily hurt to try to delay the date as long as you deliver what you have to. You can always ask and lay out your case and see what happens.
From the business perspective, you might have none, some or all of the above options available, e.g. if your contract says "by date X or you get no money", than you can only try adding resources or cutting requirements. Since you're close to project completion, adding more resources might be counter-productive.
Contract constraints aside, if you want to limit the scope, you should identify dependencies between features and have them prioritized by the user. It should go without saying that you do nothing unilaterally: whatever you do, make sure the customer is on board, even if he/she/they are not pleased by the situation (which is likely to be the case).
Delaying the delivery date is what happens most of the time: the best you can do is to react as soon as possible and keep the customer's expectations realistic. While this is painful, the customer is likely to appreciate the fact that he/she/they can adapt their own plans and avoid damage propagation (cancel or delay marketing plans etc.).
Estimates deserve to be mentioned separately. Estimates should have been available at every stage of the project. If you are not going to be on time, it is because you've spent more time than planned on completed tasks, because you feel the remaining tasks are more complex than anticipated or both. Update your estimates and let the customer know: use them to support your new proposed deadline. Including free support or an unplanned feature or two to make up for the delay might be easier to bear than transferring money, if the option is available.
It's a big subject: this just skims it.
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 12 years ago.
Improve this question
You work on an important project that contains 7 independent modules, and you do not have enough time to finish the project in time. In front of you is a choice: to complete 3 modules in full or to start work on all the 7 modules in parallel, but not complete any of them within the planned period. Which strategy you choose?
Explain the situation to the manager, let him decide. That's why he's there.
If you're in charge, then you need to consider all possibilities. I'd say, focus on what the customer will need in the first turn, and complete the second-priority functionality afterward. If possible, talk to them, explain and try to reach an agreement. The customer may have a different opinion on what he will need the most and give you direction to focus your efforts in.
Whichever is better for a customer/business. If it's possible to have all 7 "feature" in semi-complete state -- then go for it. If they prefer 3 polished "features", go this way.
It depends on what your customer values.
Are the modules really independent? Are they really needed in full, or can they provide value even if implemented partially?
A useful strategy is to implement vertical slices accross the system or even a module, not horizontal layers of modules. Implement one end-to-end feature/use case/user story at a time. It is these features that bring value to your customer, not modules (unless the customer is an odd one valuing modules and not features). This way you get something useful ready for testing and release, and your time is not spent on writing code that is not used by anyone. However, when adding new features, you need to keep on refactoring the codebase in order to avoid the stovepipe system anti-pattern.
In any case, implementing the 7 modules only halfway there is not the answer. Whatever you do, do it right the first time. ("Right" being of course context-dependent: different standards apply for throwaway prototypes, life-critical production code and everything in between.)
Complete the 3.
Then they can be released for testing to the client, and you can get to work on the other 4.
That very much depends on your development model and the customer requirements. In an agile environment I'd rather show the complete product (even with unfinished/mocked parts), so the customer gets an impression of it in its entirety and can give you early feedback on the unfinished modules.
If there are clear, precise specs however, then delivering the 3 finished modules is probably a better idea.
Client has a clear picture of exactly what he wants, and my job is to show him something that will attract his attention and give me additional time to complete the project.
Each module requires one month of work, but after three months the client decides whether to continue the cooperation or not.
The user interface is the only thing that interests him. I can not explain to him that I spent two months making engine if he does not see it on the screen.
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 4 years ago.
Improve this question
We have a pool of technical resources consisting of some front end developers, back end developers, graphic designers. Those resources are separated from clients directly by one or two account people per client.
Requests from clients come in through the account people and get sent to our synchronization manager. The synchronization manager keeps track of all client projects and has a basic idea of the workload for each resource. His job is to assign work to resources based on priority of the project and the resource's familiarity with the project (to some degree). Currently, the majority of this data/logic is handled in a complex excel spreadsheet. We revisit the schedule every week on Monday so that people have a clear idea of what lies ahead for them.
This type of system works ok for linear projects that have a longer duration, but starts to fail when there are lots of little projects/tasks happening concurrently. Many times, tech resources are "lost" when updates come to the schedule mid week. Not to mention when there are "urgent" requests that supersede the existing schedule.
How do you handle assigning workload when you work with multiple clients on a daily/weekly basis? Is there any software that you recommend to help with scheduling / determining resource availability? Please keep in mind that priorities and projects change frequently, with us not really knowing what is going to happen 1-2 weeks out from the present.
Sounds to me like the classic consulting conundrum: hitting that sweet spot where the fewest resources generate the most revenue.
The first question that comes to my mind is: how much pain is this causing? Grumbling from amongst the developers? Complaints from upper management? Furious clients? The solution should match the level of trouble caused.
The simple fact that you can't know the unknowable when it comes to schedule interruptions means that, in large part, there is no software fix to this problem. You have to build in enough room for those unexpected demands ahead of time and be ready to reassign on the fly.
It also bears mentioning that the seat-of-your-pants model, in which developers jump every time a client says boo, is a choice. It doesn't necessarily have to be that way if everyone is willing to consider other options.
Use an issue tracker such as JIRA
Personally I would take a look at using a Scrum board. This can be accomplished with a physical wall, PowerPoint slides, or Bugzilla.
Try the following:
1. Assign each tech to a cell
2. Assign each tech x amount of job/task give each job/task a priority level.
3. In the slide/wall create your different stages of To Do, Test, Very, Done and have the developers move them across the stages to give greater visibility of the tech and the projects.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
This is a software management questions. If i asked to measure a software project task for my every task assigned to me, means how can i do that? Would it be in percentage (or) out of 10 (or) in man hours?
Any suggestions please?
thanks.
I prefer the done/not-done approach. Either a task that is assigned to me is "done", meaning it's been implemented and tested, or it's "not done". If I'm asked how long I've been working on it, I do track man-hours, but it's not a measure of completeness at all.
Another approach that some people use is "in progress", "implemented", or "complete". "In progress" means that they are currently designing and/or implementing a solution, "implemented" means they are done with code and testing (or waiting on QA to validate the fix) and "complete" means it's all coded and tested.
The problem with percentages is the 80/20 rule. The first 80% of the work will take 20% of the time. The other 20% will take 80% of the time. If you have been working on something for 9 hours and are "90% done" implementing functionality, it doesn't mean you'll be 100% done in 1 hour.
If you are working on something (or have been assigned something), and someone asks how long it will take to finish, give your best estimate in hours, days, weeks...whatever. However, don't estimate too soon - take a look at the problem and requirements and never give an off-the-cuff estimate - it'll (almost) always be wrong. When you estimate, look at similar problems that you have solved in the past and use how long it took you to solve them as a guideline or basis for your estimate.
This idea comes from proxy-based estimating, which is part of the Personal Software Process. It's suitable if you are working on a task on your own. I'm not sure how well it will scale for a team.
What do you mean?
If you mean "My boss wants me to estimate how each task will take me." Then that should probably be done in hours.
If you mean something else, you'll have to clarify.
If you are talking about finished tasks, what you're probably being asked for is for the time (probably in hours) dedicated to each one of the tasks.
How do you know that? You should use some timetracking tool, so at the end of the project (or in any moment) you can know how much time you have dedicated to any of the tasks (and/or breaks, meetings...). If you haven't registered your times, you'll have to make up them, and pray :)
If the project is finished, and he needs to know how many hours were spent on a project to bill it to a customer or something, then you should be keeping very accurate track, maybe using a tool or something.
But he might be referring to how effective the task is. For Example, if he asked you to reduce the load on the foozit, then you should measure the load on the foozit before and after your fixes.
But I think what you're asking is "How do we measure tasks in software development?" And the only sensible way to measure a task is hours. Some people like to measure how many lines of code that have been written, how many bugs were found, or how many tests they've written, but in my opinion, those aren't things that should really be measured for most projects.