Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I was organizing the team to do parallel development of next version of the product. I grouped the team by
Client specific
Feature specific
Handling the cross-functional issues by assigning that task to specific individual.
Would like to know what other ways project managers/ leads group teams?
It doesn't matter so much how you do your split but there are pitfalls when splitting a development team that you need to be aware of.
The level of integration determines how much risk you have. Separate software products that happen to share some libraries have very little risk. Highly integrated runtime components pose significantly more risk.
The worst possible situation that you can find yourself in is where there is a dependency between teams to deliver a feature but no clear ownership. For example, team A is waiting on team B for a "back end service" but team B argues that the service is complete. Team A says the service does not meet all the requirements. But team B has moved on to new features. And so on....
I've seen this us vs. them attitude literally grinding development to a halt. To combat this behavior, encourage cross team pairing and shared code ownership. Rotate team members from time-to-time. Make sure there is a single responsible person who will make a feature happen end-to-end.
A team dedicated to developing reusable modules usually doesn't work. It because a collection of modules of dubious value and a governance nightmare. The best reusable modules comes from teams who deliver similar features and identify overlap themselves.
We group people by product specific in our organization. Each team writes code for a specific product. When features of a product intersects with another product, sometimes they collaborate on that feature. We do a lot of compartmentalizing, so its possible.
Write plenty of reusable modules. Thats the key.
My organization also does client specific work only for large clients.
I am a firm believer of pair programming, I would team such that one pair would manage and write test cases (tdd) while other one would code it. I would build up a team based on the same theme.
If your product involves more than one technology then, You can group teams techno wise
skillsets
The key is to allow each team to follow the same standards, but be able to work as independently (decoupled) as possible.
If its the same code base across your clients you probably don't want to split the team by client specific needs since it could lead to more overlapping of changes.
If features cross system functional (AR, security, reporting, etc.) areas you probably want to split by functional areas.
Other ways to split teams:
front end (design implementation) and business logic and database/datastorage
new development and maintenance (newer/more jr people on maintenance)
core functionality and addon modules (if component based)
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I work for an IT services company that develops products as enablers for further services consulting. We have technical consultants/developers that need to be able to develop remotely and when back in the office "on the bench".
What methodology/process/tools support development by consultants when they are remote, or "on the bench", in particular how to support the management of the deliverables.
I have looked at DVCS systems, along with KanBan board tools, but I'd like to get opinions in the best way to handle this style of product development when it's not a traditional back room development situation.
Here's my TFS pitch.
Your developers/consultants need to be able to work in house, remotely or offline. That means local workspaces. TFS 2012 has that.
With the high rate of turnover, you need managers to be able to easily and quickly assign specific tasks to developers. With TFS you can create work items, break them into subtasks and easily assign them to any team member. When the developer begins working, you'll be able to see it and any check ins can be quickly associated (semi-automatically) with the subtask. So you'll know who did what task, and be able to see the exact code they implemented to accomplish it.
If you have managers maintaining the product backlog, all a developer needs to do is select one of the tasks assigned to him, get the latest from the source and start developing. Minimal overhead for him/her.
With Web Access you can see/edit your entire product backlog, get burndown charts (and other reports), see who completed what and when, assign tasks to team members, change team members, etc. All without VS installed, so no need to have a license for a manager if they don't develop.
Finally, fully integrated automated builds will allow you to ensure that consultants don't break your source. Gated check ins are great for this kind of team. The changeset is stored, and a build is ran. If the changeset would break the build, the check in is denied. You can also automate builds on the other side, post check in.
Any file created outside of VS can be easily added to source control. Once the file is added, TFS monitors the file for changes and you can easily add the changes to a changeset. Once in source control, its fully in source control and available to everyone.
You never really mentioned any database requirements, but the new SSDT is awesome for declarative SQL development. So far, I've not had to write a single ALTER script, which makes me very happy.
There is also fully integrated support for code reviews, build verification tests, automated deployments, architecture tools (with rules that can be enforced) and more. The rabbit hole goes pretty deep, but if you don't need it, none of it is forced on you.
So, the methodology I would suggest is a KanBan style set up, with managers pushing tasks rather than developers pulling them. This way you can reduce the impact of your high turnover rates without overly micromanaging your consultants. You'll be able to easily give them a task, let them accomplish it, and have complete visibility of the work they perform. I'm not sure how you gather your requirements, and how much input in the dev process your customers have, so its hard to go into more detail. TFS supports storyboards associated with work items, so you can give detailed specs to your developers. Also the Feedback Manager can facilitate in getting feedback on working software from product owners.
You could go Scrum with defined sprints, but I think a lot of the overhead of sprint reviews and sprint planning may be a waste for you, if you consultant turnover rate is high, and/or you don't need/want a lot of input from your consultants on user story breakdowns/requirements gathering.
There are several leaders in the ALM space, including VersionOne, Rally, ThoughtWorks Studios Mingle + Go + Twist, Jira Greenhopper, and others. These are all fundamentally iterative in nature, supporting Scrum+XP. There is a new crop of tools coming up that support Kanban, if that's your preference.
The key, though, is to decide what approach you plan to take. Iterative or flow?
Beyond that, if you're using a continuous integration server - whether open source like Jenkins or commercial like Go - then that combined with an SCM system (git, for instance) gives you visibility into what's been produced and the ability to distribute that work.
Back to your specific challenge, it seems to me that iterative wouldn't suit you, since you have people coming and going as they enter and leave the bench. Mingle supports this quite nicely, as do a few of the others. In fact, I'd suggest that the leading methodologies don't really lend themselves to your situation, as you will have neither iterations nor flow, most likely.
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
Web development is a mess.
This is because we have to interact with a lot of people.
Businness, Designers, Developpers, Leads, etc...
A website is a mixture of a lot of skills which involves programmers, designers, seo experts, business persons, ergonomists, etc...
So, the question is, how do you work to make all those people understand themselves, interact together.
How could I decompose the severals steps leading to a website ?
Because a lot of enterprise sales a design at first, how could you then add the right functionnalities ?
For example, we can decompose a project like this :
Functional scopes (CRUD, Resources, ACL)
Designing the interface
Start development
Write xhtml/css according to the interface with the functionnal requirements
I may have forgotten steps, or disordered them.
EDIT :
For example, here is how I do :
I write a short overview about the project, what is the main goal ?
I try to know which resources (users, articles, products, etc..) are involved.
I write a short CRUD list for each resources which help me to have an overview about the features
I start to design the database (with mysql Workbench for example)
That done, i try to know if there are roles and privileges to rely them with the resources
I start development (+ testing)
Then i insert xhmtml code to respect W3C & web semantic.
I start to insert visual design with CSS
So what about you ? what are you steps to be efficient ?
I would say:
Overall Site Intent
User Analysis (Determine site/application Demographics, User Groups, etc.)
Conceptual Design
Graphic Design
Functional Scope
Interface Design (Prototype, Wireframes, etc.)
Interface Mockups
Development/Unit Testing
User Acceptance Testing
...pick and choose the parts you need. Doing all of them may be overkill, but probably not if you're working on a large team with many groups giving their input. Making sure you don't miss steps gives a chance for everybody to give their input and decide on a course of action.
Web development is different from other types of software development because frequently
there aren't any users among the development personnel. For example, "users" are absent from your list of people involved.
The users exist as a notional bunch of faceless people who are out there (we hope, because that's what the business plan is predicated on). Requirements are gathered and design decisions taken on the basis of assumptions about what the putative users might like or want.
So in many ways web development more resembles opening a restaurant or launching a new political party than rolling out an ERP system.
I don't think there's actually anything unique about web-development here compared to regular software development (with the exception of seo, which is just another technical challenge). I don't think there's anything inherently more "messy" about web-development. Read through the terms in your question again - do any of the terms (excluding seo as mentioned) not apply to general software development (substitute "xhtml/css" for "frontend development")?
Personally, I think any software engineering methodology which you've found works for your team-size/work environment/colleagues/etc is applicable to web-development.
There's nothing magical about the fact that the end-product runs in a browser.
XP and Agile methodologies look at creating teams whose members have all the skills needed for the project, such as Project Manager, developer, business anylist, designer, tester etc.
Having teams means there is better comunication between everyone involed including the client.
The subject is massive so do some google searches on XP, agie, scrum, kanban.
Yup dear you are right, there are several steps in developing a dynamic website however you want to develop a static site then its easy.
the only designing is needed for it and some functionality is added by a designer like email and so on.
but if you are going to develop a dynamic website then its accomplished by these steps.
1. First you make sure about the requirement.
2. Then you decide about its interface and layout.
3. Designer designed all the Form the are needed
4. Then the developer./ programmers will add functionality on froms .
5. After Completing the coding part the project goes to Testing for erros.
6.if any error occurs then it rectified by programmer again it goes to testing this process will going on until all error has not been removed.
7. Finally the web site publishes and then hosted on a server.
A website is a mixture of a lot of skills which involves programmers, designers, seo experts, business persons, ergonomists, etc...
If you're really lucky you will have a team of talented multidisciplinarians who can take on more than one role.
That's when you tend to get the best web products.
Design by committee, which you will always get if everyone only gets to 'wear one hat', rarely produces kick-arse products.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Let's say I have my vision and now my product backlog of items. That part is in writing and ready to be used. I am about to create my sprint(s). I am curious. When does a programming team sit down and say "let's use this platform, this framework, and language" and things like "We need a class here," or "I see a way we can use an Interface with that" and so on. When is that kind of talk going on?
Are there meetings that come before the sprint where someone decides for all teams - "We are going to use Linux, MySQL, PHP and CodeIgniter" and then one of the teams has a sprint to implement that infrastructure, while other teams wait for completion to start the other sprints (team A2 build a ui or security model and the features of it from the product backlog)?
Is this also where tools like trac would be used at the team level, when the sprints first begin?
Sorry if I'm all over the place with this. I've just never seen it done and just when I think I understand it I think of a new question.
Also it's beside the point but what do you name your teams? Bob's team, Smith's team, something more colorful?
Thank you.
Short answer is "It depends" as for the first part there could be other teams that dictate those kinds of terms to some extent. For example, on my current project some things are almost a given,e.g. IDE=Visual Studio, Bug tracking=HP Quality Center, Version Control=Subversion, O/S for developers XP Professional,etc.
There can be a Sprint 0 where some infrastructural elements are handled like a CI server, wiki for the team, making sure everyone has accounts in SVN, and other administrative things to get handled.
Team names like code names can come up at anytime though they can have different meanings as what someone can use for a team name in one place may not be so good somewhere else,e.g. Team Voltron may not go over well for those completely unfamiliar with the term.
Some teams start their projects with a Sprint Zero, where they refine the vision, define the global architecture (choices of platform, language, not class or interfaces), the definition of "done"...
This Sprint is special, it's about preparation and, unlike the other sprints, might not lead the team to deliver any working software..
If you are part of an agile-scrum team, chances are there your company
already has defined patterns and
architectures.
In my opinion scrum-teams are not responsible for design, There are separate design-teams who are responsible for overall design and integration-plan of any ongoing projects.
The design-team does the strategic part of projects development phase which is architecture, design and integration plan. These teams may have their own scrum sprints.
Scrum-master along with team-leads are responsible for tactics of implementing projects as per design.
programmers, testers and QA engineers have operational responsibility of writing and testing code.
I would split it into few parts.
Things like choosing tools/platforms (Linux, MySQL, PHP etc) I'd have agreed before even starting sprint 0. I consider sprint 0 more like setting vision and high-level architecture which, to some point, is dependent on tools/platforms of your choice. People you'd like to have in the team will also be different for ASP.NET project than for PHP project.
Another thing is moving to discussions like "I need a class here and interface there." This level of details can't be really decided up front during sprint 0. We just go with these decisions all along the way. This mean we're changing our architecture rather often but it's a rare situation when changes are deep. And almost always when we change something it is well-grounded decision.
To summarize: key technology decisions before you start, high-level architecture during sprint 0, lower-level design decisions whenever needed (during sprints).
"Sprint 0" is the standard approach to starting up. For ongoing major architecture decisions (switch toolkit, language, platform), a series of investigation spike stories have worked well if they are as small and focused as possible. The story is to address a specific question or prove a concept. Infrastructure questions can -- and I'd argue must -- be broken down into small stories or you may wander off the map.
Smaller infrastructure changes have sometimes worked well as a "tax" to other stories, sometimes not. (E.g. research and add a dependency injection tool, switch to generic hibernation tool) Taxing stories requires excellent communication between product and development. It presumes that some eager dev has already done some late night homework on the infrastructure.
Without success, we've tried hoping major architecture decisions will happen over the course of normal work. This fails because scrum keeps you too focussed.
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
As a professional programmer I work daily with a species known as the "PM". While they usually go by that common acronym, it seems there are actually several discrete varieties: product managers, project managers, and program managers. There may be other species yet undiscovered. Through years of close observation and study, the subtleties of their differentiation elude me. I have only been able to determine their common responsibly: to communicate to me, the programmer, in the vaguest possible terms, what it is they think they want built. I then tell them, in the vaguest possible terms, when I think it will be delivered, and they go away.
So my question for the stackoverflow crowdsourcing juggernaut is this: please explain the differences between the product managers, project managers, and program managers. Please do so with out waving your hands, as I can not see them, and it doesn't help anyway.
I'll attempt to explain them as I've worked with them. Please do understand that the definitions can be murky and change from organization to organization.
Project Manager: Responsible for coordinating the schedule of the project within the engineering. This should be the one single person that management can go to in order to know the current status of the committed work for a given release. This person is typically hip deep in spreadsheets, Gantt charts and status meetings.
Product Manager: Responsible for the deciding which user-visible features will be on the plate for consideration in a given release. This person should be well versed in what the customer is attempting to use the software for and be able to act as a developer's resource for understanding what to build from a functionality point of view.
Program Manager: Essentially a project manager responsible for coordinating the release across the different disciplines in a company. This is the person who makes sure that marketing has the press release ready at the same time as engineering is ready to ship and that sales have been trained on the product.
These are how the last couple of companies I have worked for have defined the roles, but you will certainly see many variations.
Project Manager a person responsible for managing project, specifically its scope, quality of deliverables, deadlines, time spent, and budget. PM bears responsibility for all project deliverables. See my other answer for a drill down on PM responsibilities. On small projects PM wears multiple hats, but during bigger ventures may have others to help her (or him), such auxiliary jobs might carry the titles of:
Project Co-ordinator is someone who co-ordinates project work between various parties involved and individual stakeholders.
Project Administrator keeps reporting up to date, including project status, does all kinds of other administrative tasks.
Project Expeditor does exactly what the title says: chases everyone up, removes obstacles from the project team’s path and makes sure there is always steady progress.
Product Manager takes responsibility for a product and full product lifecycle. The products are normally created and evolved through a series of projects. The relationship between products and projects is many-to-many. A single project may contribute to many products’ evolution and a single product requires several projects to keep carrying it from one lifecycle stage to another. It’s also important that product lifecycle constitutes a series of states (such as “shipping the product” or “supporting the product”) that are usually carried on as processes and state changes done as projects. Read on the difference between a project and a process.
Program Manager manages a series of interdependent projects aimed towards a common end. Some of the projects are executed in parallel, some sequentially. Program Management is fairly similar to project management, where individual tasks are replaced by entire projects. Think in terms of the space exploration program.
Obviously these titles are not set in stone and companies would often attribute a somewhat different meaning or completely redefine them. The definitions I’ve given are generally accepted within the management community.
Rather than focussing on subjective definitions of each of these roles (yes, they are subjective and you’ll get 10 different answers from 10 different people), I would focus more on the task responsibilities of the individuals. A tool to help you with this is a RACI matrix (aka responsbility assignment matrix) which makes it clear who is responsible and accountable for activities.
This industry will go on creating new “manager” titles forever and a day. As far as I’m concerned, just tell me what they actually do upfront in the project then we’ll refer back to that whenever there is ambiguity.
I read in the book (the title eludes me, but it has "Management Anti-Patterns" somewhere in it) that PM are usually developers elevated to a manager role, but who has no idea how to manage. And still developers want that role because that is one step up the hierarchy (and a higher pay bracket).
A good developer does not necessary means a good manager, and once you become manager, you got pressures coming from your peers and from the top, and some cannot cope with it. Some companies are 'enlightened' enough to develop a separate career track for developers and have their pay match those of the managers.
I'm sure you come across one of the more introvert species of PM. The last time I was in a mock PM situation (it's a software engineering module which we have to do paperwork, like SCRUM) I was chasing my team-members for updates every week and doing code reviews. So that's one perspective for you.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
We have a four person development team that is in need of a formalized project management system. I have a general understanding of Scrum and Kanban but it's hard to truly understand until it's been tried. We don't have the luxury of trying one for a few weeks and then switching to another so I was hoping that someone out there in a similar situation might have thoughts on which worked better for them and why. Also, any other systems for managing development that worked would be great to hear about.
Another note: there's the possibility of the team growing, of course, so we would need a system that scaled well.
Yet another note: We work on three separate software applications in Windows all of which are based on a central library which we also wrote (so i guess you could say four projects)
Both Scrum and Kanban are really process "skeletons". Neither is specific to software development. Scrum was popularised by software development organisations but is positioned as general management technique rather than a software project management technique. Kanban emerged from manufacturing and has been adapted to software development, initially by maintenance teams. Both Scrum and Kanban aim to manage the flow of units of work through the team that is doing that work, measure how fast work flows so that estimates can be made more and more accurately, and make bottlenecks highly visible so that they can be addressed.
Because neither is specific to software development, teams using Scrum and Kanban add software development practices to the process to help them incrementally and iteratively release and improve the software. Most teams, whether working within a Scrum or Kanban process, adopt the technical practices of XP and reflective practices of Crystal.
XP is basically Scrum applied to a single team plus guidelines about what makes code "high quality" and how programmers can achieve that. Crystal Clear also applies to small co-located teams but is more flexible about programming practices although it also recommends the XP practices (the book describing the process is excellent and full of invaluable advice, whatever process you decide to go with). Scrum teams also usually adopt the reflective practices of Crystal: regular "heart-beat" retrospectives and larger retrospectives after every major milestone. Kanban requires continual reflection and improvement but some teams use retrospectives too.
If you want to start applying an incremental/iterative process in a small programming team, then I think XP is a good process to start with because it sets the bar pretty high for technical capability and is very well documented. How continuous-flow and Kanban best applies to different areas of the software development industry is still being debated on the kanban-dev mailing list and elsewhere.
I would recommend also performing regular retrospectives to improve the process and adapt it to your specific situation.
The most important part is to have a reflection/retrospective mechanmism in place which facilitates continuous improvement. Start with some process model and evolve it over time for your needs. Stop doing things that are not worth doing. Keep on doing things that bring in high value. Try new things that you think could be valuable or address specific problems.
I think Scrum works for small to medium team. Compared to XP it leaves out some details, so you can borrow from XP or do something that makes sense. Either methodology you pick, you have to consider the role of chickens(customers/managers/stakeholder/domain experts) role. Sometimes you have to play the roles yourself, but many agile methodologies work because there's external pace car with grounded knowledge of the domain.
Other key aspects are the communication level among your team and some form of quality assurance mechanism. It's hard to do pair programming if you are not located in the same building. Scrum tries to get a feature to acceptance within a sprint cycle, and XP tries to get the feature integrated within the day using unit tests, code review, and continuous integration.
*) Sprint can range from 15-30 days.
What is you question ? Is it which methodology would be most suitable ?
You don't get much benefit from all the overhead that a formallised system will impose with that size of team. Instead, try a good management technique to make sure everyone is listening to each other and blocks are removed.
I've worked with a team of that sice and even bigger on two teams that shared some common libraries. Scrum worked well for us. Now I work with a team with 6 members and we use XP and I think it works as well. The first team developed a product and the influences from 'the outer space' were not that big. So longer iterations worked fine. No we develop a customer project and therefore shorter release cycles are better for us.
But SCRUM and XP are more than that. Now we use TDD and Pair-Programming (both more from the XP world). We also have daily standup meetings that are more SCRUM like. So we adoped XP and SCRUM to work for our project and our situation.
I would start with short cylces (1 week) and reviews of this cycle. It will take some time to adopt a new methodology in your team but if the members are willing to learn and change it will work.