Working with WCSF in a project group

Topics: Web Client Software Factory, Project Management Forum, UIP Application Block discussion, User Forum
Jun 17, 2008 at 1:31 PM
Hi

Does anyone have any experience working in a team with two or more project members?

As I know WCSF is very suited for this kind of projects, but how do you people do this in practice?

Developers should be able to work with separate modules and have all available services at their disposal. But they may not need to have the base architecture at their disposal. What about shared UserControls, DLLs and Server Controls? Right now I have some Server and User controls in the App_code folder, they must be moved into DLLs then?

Some tips and guidance would be very helpful right now.
Jun 18, 2008 at 8:46 PM


RightCoder wrote:
Hi

Does anyone have any experience working in a team with two or more project members?

Some tips and guidance would be very helpful right now.

My current team works all tiers and layers; the key to our success lies in source control and coding standards (naming conventions, properly implementing MVP per P&P, etc).  We also do a lot of peer programming because of the varying skill levels, which as a team is evolving us to a point where we can't really tell who wrote the code; it all looks the same.   Code reviews are common outside of a peer programming session.  When we aren't in sprints (where we have meetings everyday) we take the time to communicate with each other before starting new requirements to brain-storm the best possible solutions.   Whenever data structure changes are required (SQL Server) we come to the table, designate an ORM person (who will convert our final thoughts into a Visio document), hash out the details and walk away with an agreed upon plan.  Collectively we as a team are on the same page.

As to what assembly to place code in, because we write/support WCSF, SCSF and now WSSF we have to discern where to put code and shared components - a question mostly answered by the developer coding the use case/requirement.  For example a member of our team is doing magical stuff with importing/exporting data between SQL data and Excel; his prototype started in one of our WinForm modules, and because he has the time and "we" (the team) could see the value for our WCSF solution, he refactored it into a service class in a Shared Library.  We can use his service in our WCSF/SCSF/WSSF solution by simply establishing the service dependency (interface), mapping it to the applicable class and calling a line of code with the applicable parameters.







Jul 8, 2008 at 3:50 PM
Ok. What do you mean when you say that your success lies in source control? This is the things I would like to hear more about....

Do the programmers work with their local installation of WCSF and create modules and business logic that when implemented and tested is merged into the main application web site?

I guess you only share the common GUI components like custom server controls and user controls? And of course CSS etc.

Any tips on how to manage this is much appreciated!
Jul 21, 2008 at 4:30 AM


RightCoder wrote:
Ok. What do you mean when you say that your success lies in source control? This is the things I would like to hear more about....

Do the programmers work with their local installation of WCSF and create modules and business logic that when implemented and tested is merged into the main application web site?

I guess you only share the common GUI components like custom server controls and user controls? And of course CSS etc.

Any tips on how to manage this is much appreciated!


Sorry about the delay - I was experiencing one of those OT to meet our deadline moments (actually lasted a few weeks but we did it ;) 

We have a small team and have projects that cross over into SCSF, WCSF and WSSF; I'm now introducing Unity (for our Windows Services).   Each team member gets an opportunity to complete new requirements on any of our completed applications.   Everyone has access to the complete codebase and we have a general rule of thumb that says to check-in code as frequently as possible after ensuring affected areas continue to work.  Where team members specialize in certain areas, such as SQL Server (DBA), architecture and infrastructure design it really helps that everyone can work on any new requirement (on any platform).

I've worked on larger teams (Fortune 1000 company) where we had at least 8 developers to a team - with multiple teams, in that scenario I was on the team that maintained the Presentation tier and the middle tier was a black-box to us (new requirements moved slow and it wasn't always evident to us what we had available - even with the excellent inter-team communication that we had).   After working on both sides of the fence I must admit I love the ability to have access to all tiers, all layers, so that we (as a team) can meet user requirements immediately and efficiently.

Back in the day... I worked on a large team without source control - you end up with versioning issues across each developers machine that can affect the production application (something is missing in production that the developer had on his machine).   It can be a nightmare for deployments and adversely affect user confidence in the team.   With everyone having the same exact code base, up to date with the most current "working" version from everyones machine, everyone has an opportunity to see how their new code interacts with other developers updates.   When the sprint is over and it comes to deploy there are less (if any) nasty surprises.