In almost every software company it is always expected and
sometimes demanded for quick output from a newly joined team member. But in
realty how easy/difficult it is for anybody? I have seen this couple of times
and still trying to find a satisfied answer for "making the life of new
team members smooth and productive".
What should be the best approach for any project team
to provide the ready made track to the new member and make him/her understand
quickly for their duty towards the team.
The smooth the road map is the best the quality output will be.
When ever we join a team, the
first thing we look for some end-to-end document which says about the project
and team. Documentation not only helps us to find helpful information but it
also helps to correlate them with current software. Most importantly we try to
simulate or try to visualize the document into running application.
The kind of information we look
for is mostly related to our roles into that team, for example:
-SA/BA would be looking for BRD, SRD, CR or Flow Diagram/Documents etc.
-Project managers would be interested to know the nature of application, domain
of the application and different stack holders that are involved in the
application etc.
-Team Leads/Project Leads would be more interested for knowing the technology
and all the layers that are supporting the application.
-Solution Architects would be looking for high level architecture and uses of
various technologies for building the application etc.
-Developers/QMG will be more inclined to find out the flow diagrams and try to
relate them with current application.
Some of the companies do maintain proper project/organization level
documentation for employees but it is still very difficult that an application
development team keeps track of all their development.
When the project is in infant
state or grooming to a matured level, providing documentation about all the
classes,functions, methods, libraries etc would be easier. But as the
project grows, the interest of injecting comments for
every code change reduces. And at some times providing comment about each(minor
or major) development does not seem to be necessary. And the problem
starts here.
I agree that the higher level
documentation about the code, packages, classes etc should be the trigger
point for the developer. But how easy it would be for new
developer when he was asked for a hot fix and given
very less time to fix and deliver.It would be difficult for him to find
the place for code change and analyze the impact of this change to other
flows.
Also during QM cycle, it will
difficult to test all the flow. Ultimately it will be risky
for the application to deliver fix in such
conditions. This is one type of scenario for development team, there could be
some wired situation could come for other roles as well.
From development point of view, I
strongly follow the following:
-Add some developers note about the kind of changes done on the code base.
-Adding answers to the "why" and "what type" code changes
in the comment.
-Add Date/Time in the Comment
I am sure there are many who are
using best practices/methodology to keep track of all the contributions.
Feel free to drop your
suggestions/recommendations for any points which could be helpful for any team
to make the life of new team member smooth and more productive.
Comments
Post a Comment