10 Software Process Management Best Practices
By
·
·
Interview
Likes
(0)
Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!
Comment
Save
45.8K Views
Join the DZone community and get the full member experience.
Join For FreeRegardless of
software process management type (waterfall, scrum, iterative etc.),
there are some main rules which should be considered about software
process management. In this post we will mention most important of these
practices theorically:
1. Define roles and tasks of team members:
For productivity,
roles of team members should be defined clearly. These roles may be
project manager, team lead, develeoper, tester etc. Furthermore,
authorizations and responsibilities of these roles should be defined
very clearly. Task-assignment based development should also be applied
for avoiding redundant effords and chaos.
2. Define meeting types:
2. Define meeting types:
Meetings are very
important if we are talking about software process management and should
be defined in detail (meeting participants, context, average duration
etc.). Team members should also obey meeting rules. This will bring more
productive meeting and development process, and will avoid losing time
unnecessarily.
3. Define documentation strategy:
3. Define documentation strategy:
Every single
software process has a documentation strategy, even agile or extreme
methods (backlogs, lessons learned info, bug items etc.). These
documentation types should be defined clearly (document physical
properties, standard sections, document update period, version numbering
etc.) for consistency, understandability and more effective software
production.
4. Define software quality metrics and measure them:
4. Define software quality metrics and measure them:
There are so many
metric types (line of code, cyclomatic complexity etc.) in software
world. According to the properties of your software type, some of these
should be chosen to measure quality and growth of code. These info may
be discussed periodically and production quality will be increased
after assessments.
5. Perform issue/requirement tracking:
Requirement
management or issue tracking is one of the key points in software
development. They determine the scope of software, also supports a
traceability base for functional tests. Those issues/requirements are
preferred to be saved and managed with useful tools which have more
features than text editing.
6. Perform version controlling:
Version controlling
is also crutial in production. This should include code and other
documents. It will support co-working on code, returning to older
versions of code and will ease versioning and dependency management.
Versioning strategy (version numbering,versioning periods etc.) should
also be determined clearly to obtain consistency.
7. Perform testing:
Testing is one of
the main phases of software development. Unit testing must be performed
for every type of software, except a few exceptions like some user
interface code. Other testing types (system, user, integration etc.)
should be defined clearly and applied consistently as defined. This will
increase quality of production and decrease bugs.
8. Perform dependency management:
As software
projects grow, more external libraries (jar, dll, ...) or projects
(external projects or internal company projects) are included. If those
items are added to projects imprecisely, later updates or version
changes will bring chaos and so much time consumption. Dependency
management strategies and tools should be used for efficient
productivity.
9. Perform code reviews frequently:
Code review brings
high quality code. First of all it enforces developer to produce better
code, because it will be controlled by others. Besides, a junior
developer will learn better coding quickly by corrections of senior
developers. So, code review is a partial type of pair programming and it
enhances productivity.
10. Save "lessons learned" info for your projects:
Even if there are
experienced staff in projects, there may be unforeseen events which may
obstruct or retard development process. This can be a complex item
configuration, error, production experience etc. Those happenings are
highly preferred to be written in "lessons learned" documents and shared
in public locations. This will avoid recurrence of time loss and
provide more productive software process management.
Software
Published at DZone with permission of Cagdas Basaraner. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments