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!
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 am managing a software project that is hot for the company in terms of it being one of the things that is their bread & butter and it is going well. I have another manager at the company interfering with my project and people. How does one get this interference to go away. One thought that he is not creative enough to create work, I mean there is a lot he can do in other aspects of the business that would make a huge impact. The other piece of this is tasking a person that for a lack of a better way to describe it doesn't actually produce or actually make anything. How does one handle or manage people that don't produce anything I guess is the question.
Would anyone have resource suggestions such as:
- Books
- Paid Training
- Others
Maybe this is not a topic for this forum. :) If so, suggestions for other forums would be greatly appreciated.
It happens a lot this kind of interference in the project. Your authority as a project manager depends upon the managerial structure in your company.
Some companies works only as functional teams and the project manager has little power and authority facing the different interests among the stakeholders. The PM is hierarchically under a functional area and reports to a functional manager instead of a program or portfolio manager.
On the other extreme side there is a project organizational structure, the project manager has control and authority on the project as well as on the teams.
The midst of these two structures is the matrix organization structure. In this case the project manager divides the responsibility to a functional manager.
I believe that your first step is to understand the power structure in your company works and how your hole is related to it. The next step is to assure exactly the role of the other manager who interferes in your management activities. Does he a client? Does he the sponsor? Or does he only a partner?
The stakeholder management is a daily activity in the PM job too. It is common to see this kind of interference from the stakeholders but always remember that the project manager is you.
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
Some friends of mine came up with an idea for a web application which we (so far) think could be great. I made the analysis and all the early stages of the development process and I'm about to start the coding. I'm talking about something that is barely a mid-level project, so I consider one developer (myself) should be enough.
The thing is that we are trying to assign roles to each one of us so we can be focused on our duties and have clear our responsibilities within the team. We are a crew of four people, three of us (my friends) are business people who would do the marketing, customer relationship, management and accounting stuff and I'm basically the developer. I have in mind to get them involved into the development process by giving them documentation to write and use them as testers, all of that besides the management duties they have.
Perhaps someone out there have been in the same situation, so I would appreciate if the experience is shared so we can effectively give ourselves positions in the project based on what I explained above. Which are the essential roles or the optimal team layout so the idea can be developed successfully? The question is not strictly about programming, but it's related to build a software entrepreneurship beyond the code, that is something that I'm sure plenty of us are looking.
Any help is really appreciated! Regards.
I think you're on the right track. What I tend to do is think about responsibilities in terms of "functional" vs "technical" and go from there. "Functional" responsibilities and requirements reflect the customer, the user, the stakeholders and are usually technology agnostic. "Technical" responsibilities and requirements translate the functional items into architectures, platforms, technical relationships, coding languages, etc.
Here are some possible functional roles your partners can fill to support your development role:
Project Manager: Ultimately responsible for timelines, budgets, and delivery of projects / sprints and product delivery.
Business Analysts: Collect customer requirements for the software. This role usually requires subject matter and market expertise or access to such expertise. They ultimately write the functional specs that your technical specs will be derived from.
Product Manager: This role compliments the marketing efforts by ensuring that first and all future iterations of the product are meeting market and customer needs. They have full responsibility for bridging that gap between functional and technical.
I think what you mentioned about also using them to write documentation and test is a great idea, as it will help them understand the development time and effort required from your job, and allow them to speak intelligently to the more technical aspects of the product, even if they are not techies themselves.
They could also play a big role in helping construct the user experience, by storyboarding and wire-framing.
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 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
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.