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
Our current project has a large team, and we have come near the end of the project
Like most end of projects, dozens of dependencies are popping up - everyone is waiting on someone else to complete a task. What is the best strategy for dealing with this.
I have thought of scaling the size of the team down, so the depenencies can be done in parallel by the remaining members of the team, but I'm looking for ideas that will include keeping everyone on the team still.
The only way I know how to handle this is to split the team in two. If you're lucky you can set the other half up to work with the next release. The message to BOTH teams is that the release version has priority over work on the next version. So the people who're working on the release version can enlist people from the "next" version as long as there is a reasonable need (this is normally related to different areas of expertise, who worked on the code in question).
Normally we only let the team working on the release version get advice from the people working on the next version, so the people working on the next version will typically give up an hours work without any discussion. If they should be pulled back into developing the feature we normally let that be a managerial decision. Most of the time these things are just obvious.
It's the ole' line them up and knock them down approach. Make sure you're really at the end of the project and not uncovering any missing deliverables, prioritize the deliverables and based on the top priority items determine the remaining work, dependencies, etc. Priority could be based on most value of the deliverable, most costly resource or resources likely to move on sooner then later. If people are waiting and have nothing to do, it's time to delegate end-of-project documenting tasks...(someone has to do it).
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 came to a successful project with 4 years old, it is already in the production.
The problem is that, the project is not documented anymore, it depends on 2 senior developers only, they know the system, they test, they handle change of requests..
I need to know what is the best practice, or what are the main steps that I have to do in order to document all the modules starting from high level design through component analysis & design, code comments, till the configuration management.
The traditional project management processes don't give me a clear idea of how to take the control back of a an old project.
Thanks.
Senior developers will easilly get bothered if you make them write docummentation all day long so you may lose them at the end.
I would hire a technical writer / junior developer if I were you and give him or her this as a first task. I would also make him or her work closelly with the senior guys, without taking too much from their time (like aggregating questions and have a one hour session dailly or something like that).
It will probably hurt in the beginning but if properly executed should prove a good choice at the end.
Note: The level of cooperation between your senior guys and the new guy that will be doing the documentation may vary depending on some internal "political" things like if the developers feel threatened by the fact that you are trying to make them less critical to the project, how overwhealming the new guy / gal is to them and so on. So answer those questions before going for it.
Once again - it is my personal opinion on the given topic and its success will definatelly depend on various factors. So you should decide if it is a good way to go or not.
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 a very very simple project-management/bug-tracking system, and i want to display the status ("horrible as hell" to "nice like a butterfly" ) of a project on its summary page.
The problem i have - how to determine said status, i thought about the quotient of solved/resolved issues, but this quotient is going to 0 as more and more isses are resolved. I also thought about issues/files, but then i have to monitor the count of files (whats gonna be hard b/c theres binary files i have to monitor so a svn or git binding is not possible).
sorry if i posted on wrong site - don't sure if this belong to meta
This is highly subjective, but here's my two cents worth after managing hundreds of projects.
Each project is so unique that you won't find a suitable "automated" way of measuring the health of a project in the way you are asking. The best you can do is to display such metrics as-is.
For an overall project health status, the project manager should be responsible for analyzing the metrics you are providing and manually determining the health of the project.
Again, I know it's subjective, but project management is as much art as it is science, and no software is ever going to be able to be able to nicely summarize the project status as well as a competent project manager. Even an incompetent project manager should be able to give a better status report than the computer. All the computer do is spit out stats. It takes someone who knows how to interpret the stats to put the stats in a nice "executive-level" summary.
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 5 years ago.
Improve this question
There are lots of texts on how to plan software projects (with user stories, etc), but they usually assume you have a large budget, liberal timeframes and/or a real dev team available. While they sound fantastic, they never seem to account for solo devs working on a short deadline.
There is also a lot of talk about test-based methodologies where you write a test case for every method before you implement it, but I feel that these are difficult to impossible to apply if your software is GUI-focused (e.g. (server-side) web programming or Flash/ActionScript).
Although I try to make heavy use of refactoring to improve my code whenever I have finished a section of it, last minute hacks and additions tend to make this incredibly frustrating and I often feel that there should be a way I can utilise at least some of the planning theory that's apparently meant to help large dev teams and developers of software libraries first and foremost.
What is The Right Way to go about writing small-ish applications as a solo dev and how do you prevent last minute changes from making your code worse?
There is no "Right Way" unfortunately, however, there are a lot of better ways. I think there is no real distinction between small and large projects - the same kind of things need to happen, it's just the depth of those things that changes.
In your situation - working to a short deadline, preventing last minute problems - the same old tried and true methods are going to work:
Use source control effectively, develop last minute changes in a separate branch so you can drop them easily if required.
Test, test, test. If your tests cover the intent of what you were trying to achieve properly then last-minute changes can be measured.
I suspect you need to look seriously at some different types of testing and tools - there are plenty around that will help you manage these issues.
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
Its a common thing to see that most of the project gets lost in-between the development due to many reasons, some which can be fixed and some which cannot. Can you please share various indicators that would point to this and feel free to share your experience that may help.
Thanks in advance.
When unpaid overtime, especially weekend working, becomes Standard Operational Procedure.
One indicator is when lot of issues start coming up in the team meetings that contradict the SRS.
Another indicator is when the TL and the PM start explaining the same requirement differently... which clearly shows that the requirement has either have not been correctly understood or mis-interpretation of it
A good link is here
One of the tell-tale signs a project is heading in the wrong direction is when the project no longer becomes a project. The definition of a project is:
The project has a well defined objective
The project has specific start and end time
The project has a customer
If any of these are not present or if they change and become no longer a project then things are heading the wrong direction. This happened to me when I was the sole developer on a project. Nobody noticed that we lost our clear objective when one of our assumptions proved to be incorrect. My work shifted from development to maintenance. It was a nightmare.
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 11 years ago.
Improve this question
What is the best way to retire a currently active project? I've been working on this one for a while now and I think its time to let go. Without going into too much detail, there are other projects and technologies that are way ahead now and I don't see much value in investing in it any further.
What have you done to retire a project and what is the process like?
As operating systems, compilers, etc. change, it can be difficult to rebuild old projects.
Consider creating a virtual machine that is configured to build it again, in case you need to update it for some reason in the future. Archive that VM along with the source code, etc.
Personally, I've done this before, and put up on the homepage of the project
"I no longer wish to maintain this project - if you're interested in taking it over, then feel free to email me (email#address)"
And then let someone take it over.
Is this a personal, community, or commercial/professional project?
I have had a professional prject go sour due to lack of feedback form the client. Bascially they were going at a slower pace than they should have and it got to a point where the software would be more expensive to contine than to get a prebuilt alternative. In that case i just brought in the data to show the client where their saving are and recommend to abondon. Its hard to swallow, but after a while they realize it was for the best.