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 5 years ago.
Improve this question
While doing planning sessions using Rapid Board what are some reasonable ways to make sure each person on the team has a decent enough amount of work for the length of the sprint?
e.g. if you have 10 people on the team, how can you quickly see if 1 person only has 2 hours worth of work? Are you supposed to wait for them to speak up or can this be done through Greenhopper somehow?
The best way to make sure that everybody has work to do throughout the sprint, is to let them sign up for work every time they complete the previous task. This means that the members will be "pulling" work, rather than having their work "pushed" onto them.
If you conduct a daily scrum - daily - you will find out pretty quickly that someone is not signing up for new work - that he's either stuck on what he has, or not picking new work. Essentially, if you break up your work into small enough tasks, you will know what is going on within a day.
All this will work for you regardless of which software tool you use to track your sprint.
If you are using Jira, (and your project can afford it) I would suggest looking into the add-on "Green Hopper." It is also made by Atlassian and does a lot of what you are asking for. You can view individuals and see how much work they have as well as how much free time is remaining.
You can also drag the stories (Jira issues represented as virtual index cards) into different iterations (sprints) and onto different people. As well, it will help you to run your daily standup (using it as the scrum board), however YMMV.
m
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'm in my first development job out of college and have been handed a (solo) project that is completely outside the range of my skills/experience both in terms of the technologies being used and the sheer scope of the thing.
I've spent the last 6 months or so basically completely retraining myself and then starting to do the thing, and although I did very well at college and I think that I'm on track for delivery, I've had zero feedback on what I've been doing and I'm suddenly starting to feel very much out of my depth.
My direct supervisor, while a nice guy and I think a competent coder, doesn't have the best communication skills and basically told me to "read a book" when I asked him for a bit of guidance, which is not really what I was hoping for!
Am I just being unrealistic about the amount of support I can expect as a junior developer? It seems to me that ignoring the issue and ploughing ahead runs the risk of a failed project which is to no-ones benefit. I could take my request for guidance a step higher to the head of development, but I don't want to sound like I'm saying I can't do the job nor do I want to make my supervisor look bad.
Can anyone suggest a good approach for saying "help!" without making myself or my supervisor look bad?
This is a great question, and I think a fairly common situation. Basically, I think what you're asking for is guidance on how to communicate with your boss, and the other people in your organization.
This might be a good time to look into the scrum framework, and take from it what seems applicable to your environment.
In particular, you mention that you might be in over your head. Or, there is an (implicit) expectation that you'll need to finish this project "tomorrow," when you really don't know how long it will take.
I suggest starting with a list. Write down everything you need to do. Include non-coding activities, like "research technology X for doing Y," and give each task a basic time estimate like "1" for short, "2" for medium, "3" for long. Then put the things in an order that you think makes sense.
Then meet with your boss, once a week, for like 20 minutes, to discuss what you did, and what you're going to do next week. Out of this discussion, you'll both see what's going on, and adjust expectations (and the list) accordingly. When conflicts of expectation come up, talk it out.
Regarding the amount of support to expect as a junior developer, this really depends on your organization, and your supervisor's opinion. As software engineering is still a relatively young profession, there isn't much in the way of industry-standard mentoring programs.
I suggest trying the list + meeting thing for a couple months, and observe how your opinion of the support situation changes. Then, go to a large conference as soon as possible; spend the money if you need to. You'll see who is struggling with similar situations, and also who is not, and you'll create your own, more-informed model of "how the industry is supposed to work."
Regarding a good approach to communicating, I (seriously) suggest The Seven Principles for Making Marriage Work by John Gottman, which has a lot of examples of what works and doesn't work when communicating with people.
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
In a big corp, they often ask developers to fill in a matrix of what skills they have at what level. It's generally seen as a bit of a pain but is it actually useful, or another way for bureaucrats to try and reduce developers to a bunch of numbers on a spreadsheet?
Skills matrix are only partially helpful, they are good at giving you a general picture of your current "experience".
However these skills matrix does not include the most important aspect, the ability to learn.
This is the most important skill in IT in my view. And everyone learns at different speeds.
Eg. Throwing guy A into a new technology stack, and how long before he/she is productive?
Since IT/software development is a very wide field I regard skill sheets as quite useful. I used to be a Linux expert and my skill sheet reflected that. Then I shifted into iOS/Mac development and my now-employer asked me to fill out a skill sheet tuned to Mac... and I immediately noticed that I was novice in this field back then ;-) Vice versa, they were able to see whether I can fit into the company and where (in which team).
So of course they can be harmful if you lack the skills, but I think they make choices for employers easier (and I regard a big skill sheet in my CV as the most important part of the CV, even more so than the list of projects done).
The usefulness is totally dependent on what is being assessed. I work in an insurance company and this was done for all staff here. There was no category that I fit into and all the criteria were irrelevant.
I can see the benefit of assessing relevant criteria, it can identify weaknesses and target training, but those criteria need to be defined by someone who knows what you might not know.
Most of all, don't berate the bureaucrat for simplifying a complex object into a manageable set of information. As a programmer that's what you should be doing every day.
I think it is appropiate on big corps, but for small and specialized consultancies I would make a personal interview.
In big corporations if you dont fit in one place you may fit in other... in small teams I rather do personal assessment .
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
we have a number of functional deliverable planned for 2010 but we also have a technology agenda (architectural refactorings, consolidation, upgrade a platform). any suggestions on the best way to include these in a roadmap to help the business understand why they are important.
one option is just saying trust us as this is the right thing to do to keep everything healthy but i would like some better visualization if possible
Being a bit cynical about it, I would say phrase every thing in terms of money. If you can't re-write your technical agenda in terms of money made or money saved, then why are you doing it at all?
Also, there is an article on "technical debt in financial terms" that I found very useful at:
http://forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
One of the more interesting points, to me, is "One of the important implications of technical debt is that it must be serviced, i.e., once you incur a debt there will be interest charges."
There is a brief follow up at
http://forums.construx.com/blogs/stevemcc/archive/2007/12/12/technical-debt-decision-making.aspx
Show how support time, time between failures, number of problems should go up if you won't do the change.
Each technology has it's time limits, end of support from the manufacture, and regular life cycle.
Example - if you use MFC - you can show that programming a simple task in MFC is 3 times slower than in winforms. so after x months, the benefit from not upgrading will be lost.
with equipment it is even easier, as the older the equipment gets, the more mal-functions there are and it is easy to show (usually after the 3 years covarage everything starts to break, and I think it's planned like this. it didn't use to be but these days it does).
with infrastructure - again - if you have oracle 7.6 - show how much more time (money) you spend on administration and how less will be spent in 11g.
ect. ect. ect.
eventually manager wants to see ROI... TCO... BLA BLA BLA so you need to give them that.
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 5 years ago.
Improve this question
When working on a project - I always estimate my tasks and calculate how long it will take me to finish. So in the end I get a time-span in which the project should be finished (it rarely is).
My question is - do you record your data and assumptions use in your estimates during a project and use them for later projects or refined estimates on the same project?
If so - how do you record such data and how do you store them?
I used an excel-sheet - but somehow (cannot imagine how that happened ;)) I tend to forget to fill in new assumptions or gained information. On the other hand it is not really readable or useful for evaluating my predictions after finishing the project - to learn from it for the next project.
Sounds like what Joel wrote FogBugz for.
I had a discussion with a friend recently about a pragmatic variation of this, more specifically, the feasiblity of using the coarse level evidence of when code is checked in.
Provided you work in a reasonably cohesive manner, your checkins can be related, at least through the files involved, to some work units and the elapsed time used to determine an average productivity.
This fits well with the Evidence-based Scheduling approach included in FogBugz. If you happen to have been spending time on other things to an unusual degree, then in future you will be more productive than the checkin rate suggests. Any error is on the safe side of over-allocating time.
The main flaw, for me, in an approach like this is that I typically interweave at least two projects, often more, in different repositories and languages. I would need to pull the details together and make a rough allocation of relative time between them to achieve the same thing. In a more focused team, I think repository date stamps may be good enough.
Isn't that what project managers are for? ;)
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
As a project manager, you are required to organize time so that the project meets a deadline.
Is there some sort of equations to use for estimating how long the development will take?
let's say the database
time = sql storedprocedures * tables manipulated or something similar
Or are you just stuck having to get the experience to get adequate estimations?
As project manager you have to remember that the best you will ever we be able to do on your own is give your best guess as to how long a given project will take. How accurate you are. depends on your experience and the scope of the project.
The only way I know of to get a reasonably accurate estimate that is it to break the project into individual tasks and get the developer who will be doing the actual work to put an estimate on each task. You can then use an evidence based algorithm that takes the estimation accuracy of each developer into account to give you the probability of hitting a given deadline.
If the probability is too low, you have two choices: remove features or move the deadline.
Further reading:
http://www.joelonsoftware.com/items/2007/10/26.html
http://www.wordyard.com/2007/10/11/evidence-based-scheduling/
http://en.wikipedia.org/wiki/Monte_Carlo_method
There's no set formula out there that I've seen that would really work. Fogbugz has its monte carlo simulator which has somewhat of a concept for this, but really, experience is going to be your best point of reference. Every developer and every project will be different!
There will be such a formula as soon as computers can start generating all code themselves. Until then you are stuck with human developers who all have different levels of skill and development speed.