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
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 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 a lot of articles/books etc about PM for medium or big projects. All articles which I found describes how to manage a project with at least few people involved.
In my case that is totally different, so this is my specific case:
I have a small team (4-6 developers) and we do small short-term projects. Usually one or sometimes two persons per project. Project's lifetime is about 1-2 month in general (but can be 6 months in case of customer related issues). All projects are customer related, quite often there are some breaks in the projects because of lack documentation from customer or lack of hardware etc, so one person quite often handle 2-3 projects with different priorities at the time.
My question is: can any "popular" modern methodology be tailored to suite this types of tasks? What could you recommend (methodology/pm tools).
May be someone can give a link to an article about this type of software pm?
Cheers!
In my opinion, any project management tool could be adapted to your team and you should first choose what type of project management methodology you want to follow. Personally i think Kanban could be a good fit as there are no specific deadlines or cut off for projects, just tasks. It also allows you to prioritize tasks and carry out several projects at once.
This is the methodology we use and we do have similar uncertainties when it comes to the length of the projects. The tool we have been using is Eylean, it allows us to follow the methodology and have the updated status of the tasks at all times.
I'm a fan of Crystal Clear, which is Cockburn's method focused on smaller team work. http://alistair.cockburn.us/Crystal+Clear+distilled
Any methodology can be scaled, provided you don't fall for the dogma and consider it to be the "Best" or "Only" way, or that you need to follow all the principles completely.
That said, I'm a big fan of Extreme Programming myself.
However, in practice, on our projects, we "officially " use a Waterfall methodology, but within each phase our methods are more in line with Agile methodologies, and our official stance is that each PM will use whatever tools he or she needs, so long as the project is moving along, we are meeting our deadlines, and most importantly, the customer is getting what they need when they expect it.
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
Which is a good Project Managment Method to Develop a Website?
XP? The Waterfall Model?
Anything but waterfall....
But keep in mind that saying you are agile and being really agile are two different things.
For agile to really work over an extended period one has to also be doing several technical things well.
http://ayende.com/Blog/archive/2010/02/20/nice-process-but-what-about-the-engineering-bits.aspx
http://davybrion.com/blog/2010/02/youll-never-get-sustainable-progress-for-free/
Agile/XP would be best.
Waterfall would be the worst choice in my opinion.
It depends on who the customer is. If you are your own customer, then definately Agile.
If your aren't your own customer then you will have to negotiate with your customer on your development method. If your customer wants a fixed bid project and a hard deadline, then you will be best served by the waterfall method.
If your customer is willing to be an active participant in the development process and doesn't have a hard deadline and fixed budget then you could do Agile/XP.
It always depends on the type of the website you are developing, how many developers you got, what is the timeline, expectation for delivery time. But definitely Agile or prototype-iterative method will work fine for website development. To complete the development in different phases, and enhancing in the chucks, as an when identifying the strong and weak areas.
As well you can check the factors like target audience, maximum used sectors of the site and prioritize the development of those pieces first.
Always consider to go with standard framework, that will make life easier in long run with the future developments.
I find that waterfall fits some web site projects fairly well. Get the requirements, wireframe a design, do the graphic design, convert the graphic designs to HTML/CSS/JS, then fill out the content of the site. Client signs off at each stage. If the site is large the last stage ("fill out content") is probably more work than all the preceding ones and you'll want to use iterative methodologies for it, not waterfall.
Waterfall tends to not fit web applications very well. Those are software, treat them as such.
Use waterfall! But:
Set duration of the project to 1 month.
Then repeat this project until customer is happy!
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 am the sole software developer in a company and I answer directly to the owner of the company. We also use the services of an outside developer. The owner isn't a developer but 'wrote software in qbasic' many years ago. He has reasonable abilities to spec projects. The outside developer doesn't answer directly to me, and my boss is really a micro-manager and wants to keep it that way.
The outside developer likes to use layers of abstraction (frameworks and wrapper classes), but has implemented them when I was stuck on months-long projects. When I return, the boss now wonders why it is so time consuming for me to do maintenance on projects (including one that I initial wrote from scratch).
I'm unhappy reverse engineering his code and I'm having trouble articulating the fact that I must learn a complete different interface from code that looks alot different than what I wrote in the first place. At the same time, the outside developer looks like a hero. Suggestions on how to articulate this to a technical/yet non-technical boss and how to put a lid on this happening in the future?
At the risk of sounding patronising, be careful that it is not just your perception of what you think your boss is thinking, which may be quite far from the reality.
Your boss may be wanting you to explain the situation not because he does not trust you, doubts your competency, or wishes to belittle you; but rather to understand where the difficulties are so that he can make an informed business decision on whether it is worth you reverse engineering this code- or perhaps be better to leave it as is and move on, on different aspects of the project.
Being honest and explaining that you have limited experience with these frameworks/wrapper classes may "buy" you time to not only learn these frameworks (which will hopefully benefit you greatly in the future), but may also mean that you are appearing to embracing and extend upon the other developers code, which is good team spirit if nothing else.
At very least, ask your boss to ask you if there are aspects of your explanation that he needs further clarification on. Keeping nice clear lines of communication will help everybody move forward faster.
Hope that helps!
Gav
I don't know if you can get away with this with your boss.. I could with mine, but not everyone can.
First, this has to be done respectfully, and the suggestion I'm about to give should be within the scope of a longer discussion. When it comes to the point of having to explain the difficulty of working with this developer's code...
Type up a paragraph in English, have someone type up the same sentence in some language your boss does not know. (Chinese, Spanish, Klingon, whatever.) Give your boss a (language) - to - English dictionary and explain that while you are technically capable of translating this outside developer's code into something useful, it takes time, just like it would take him time to translate from (language) to English using the dictionary.
Perhaps this would work best in the context of trying to establish standards for working with outside agents and potential new hires.
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 9 years ago.
Improve this question
Does anyone know of any software or a good way for developers to build up a knowledge base of business rules that are built in to the software for help desk to use?
We already have a helpdesk software but we are not looking to replace this.
A wiki is definitely the way to go. Processes change, sometimes frequently, and in a fast-paced environment like a help desk a tool that allows quick, easy access and management of that type of content is extremely important to allow people to do their jobs effectively.
One of the greatest benefits I've found is the heiarchical sturcture of many wikis, allowing employees to find the correct content from a number of different customer angles.
Can you be more specific?
This may fall under "policies and procedures" management software. Here are some:
http://www.softscout.com/software/Human-Resources/Policy-and-Procedures.html
I'd like to find one that's more wiki-like or easier to integrate into a a website serving as a more general company knowlege base.
I would recommend a wiki wiht a "Wiki Gardener" role- someone who cleans up the duplicate entries and sorts.
Wiki technology with a Rich Text Editor option would useful if your Support Desk are not totally technical.
Having some structure is imperative, developing something in any Wiki that makes sense to the general editing populace, and has a low threshold to get from reading to editing. You will also possibly need a migration strategy for taking hundereds of little notes into something more readable and searchable.