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!
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 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 8 years ago.
Improve this question
I'm looking for some references or best practices with regard to the proportion of different skill sets that needs to me on a typical medium sized software development team.
Assuming 40 development staff, what proportion should be SQA, UI designers, project managers, data specialists etc?
The problem domain is general engineering. I realize this is seems like a vague question but the correct answer will provide references to industry standards and best practices as opposed to a bunch of numbers.
Opinions and words of wisdom also appreciated! Regards.
You may want to consider the "controversial" Surgical Team structure, first proposed by Harlan Mills, and described in detail by Fred Brooks in The Mythical Man Month.
The Surgical Team structure is led by one chief-person performing the most critical work himself while directing his team to assist with or overtake other important but less critical parts.
Books defines the surgical team as in the following summary:
The Surgical Team http://img705.imageshack.us/img705/1599/image022b.gif
The surgeon is the chief programmer of the whole team. He produces all the specifications, codes the entire system the team is responsible for, tests it, and drafts its supporting documentation.
The copilot is the surgeon’s right-hand man. His main purpose is to share in the thinking about design issues. The copilot represents the team in meetings with other teams. He knows the code intimately, and serves as insurance in case of disaster to the surgeon.
The toolsmith supports the surgeon and builds specialized utilities and tools as may be required by his surgeon. Each team has its dedicated toolsmith in addition to any central services provided by the rest of the project infrastructure.
The tester is responsible for maintaining test cases for testing the surgeon’s work as he writes it. He is both an adversary who devises test cases to measure against the formal specs and devises test data to be used in debugging.
The language lawyer, which can serve several surgeons, is a widely consulted specialist who delights in the mastery of the intricacies of the programming languages and the operating systems upon which the software must perform.
The administrator handles money, people, space, and machines. The surgeon is the ultimate boss, with the last word on all these issues, but the day to day management of the issues and interfacing with the administrative machinery of the project is the role of a professional administrator. One administrator may serve more than one team.
The editor edits and revises the documentation as drafted or dictated by the surgeon and oversees the mechanics of its production.
The program clerk, trained as a secretary, is responsible for maintaining all the machine-readable and human-readable technical records generated by the team. All the filing and indexing is the responsibility of the program clerk.
The secretaries handle the project correspondence and non-project files.
Sources and Further Reading (Pro and Against):
Organization and Team Patterns
Surgical Team or Motley Crew of Adventurers?
The Mythical Surgical Team
Stack Overflow - The Ideal Development Team
Stack Overflow - What methodology is closest to the Surgical Team in The Mythical Man-Month?
Stack Overflow - How much of the Mythical Man Month still applies?
10x Software Development