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.
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 5 years ago.
Improve this question
I understand that it is better to discover requirements through iterative approaches in Agile, however I often hear of people rejecting projects on the basis that they are given up-front requirements.
Why is this the case? Why can't up-front requirements just be taken as-is, e.g. just added to a product backlog and then prioritized and implemented?
There's nothing wrong with up-front requirements. In fact it helps to know where you're heading before you set sail!
Agile is a lot about being able to be adaptable, so that should requirements change you're not locked into something you don't want.
The kind of up front requirements that would cause a developer to think twice about a project, would be those which indicate that the client are likely to be a nightmare to work with:
an obsession with one particular, unsuitable technology or presentation style
insisting on 'security' with glaringly obvious vulnerabilities
In an agile project, it's good to show a client the current state of the partially working system at an early stage, and get feedback, using this information to help design the subsequent parts of the system. If a client is too fixed on ideas of the final product then they might not be able to give useful feedback at this stage, and the final product may be not as good as it could have been.
This something that can be quite problematic with Agile. Some teams will use it as an excuse to not have a plan as they want to be 'adaptable'. Requirements can help to focus on the software architecture, which is something else that is not always given much focus in some Agile teams. It is points like these that lead me to believe that Agile should just be principles but not a methodology. Digital Animal wrote an interesting article about how Agile can be used in such a way that it stops being effective. For some teams, it is better to learn from what is great about Agile and use it to build a methodology that works for them. http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/?AT=CZcb6f
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 currently trying to write up some software specs for a large-ish project that I'd like to bid out on oDesk (maybe 3k-6k). I have a classical education in computer science, but minimal work experience and I've never worked in a corporate environment.
I've written up 15 pages of project specs for an API that I want to run on Google App Engine. I'm finding the subtleties difficult with issues such as: where to draw the line on what to specify and what not to; how to break the project up into pieces so that if one part goes wrong, other parts can still be used; where and how to set milestones; and how to screen for a candidate who has the skills to properly implement the specs.
I asked a friend what issues I should watch out for and he said:
Make sure specs do not have contradictory information
Make sure specs are not unnecessarily specific because this will turn off more skilled developers
What other pitfalls and common mistakes should I look out for while drawing up project specs?
While it is important to focus on the functionality of what you want to achieve, also keep in mind the non-functional requirements as well. Think about how you want it to perform, security considerations, etc.
One to add to the list
Make sure the specs are unambiguous. (Can only be interpreted one way...Hopefully)
I think these two links will help:
On Reqs And Specs: http://www.pragmaticmarketing.com/publications/topics/02/0204sj
Painless Functional Specifications - Part 2: What's a Spec?: http://www.joelonsoftware.com/articles/fog0000000035.html
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 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).