|
Jan 2009 - Pragmatic Software Newsletters |
|
Tools for Managing the Software Development
Lifecycle |
Sponsored
Link |
www.SoftwarePlanner.com
Software Planner is an
award winning web-based
application lifecycle management (ALM) solution. Tracks requirements, defects, test cases, support tickets, and allows
document sharing. Provides project management, with
importing/exporting from Microsoft Project®,
customizable dashboards and Microsoft Outlook®
Synchronization. Integrates with most major
automated testing tools. |
|
|
|
The Seven Habits of Highly Effective Developers |
Published in 1989,
The
Seven Habits of Highly Effective People,
written by Stephen R. Covey has helped millions
establish great habits for achieving true
interdependent effectiveness in their life and their
jobs. This article discusses the 7
habits, framing the habits for highly
effective developers. Below are the 7
habits:
- Be Proactive
- Begin with the End in Mind
- Put First Things First
- Think Win/Win
- Seek First to Understand, Then to be
Understood
- Synergize
- Sharpen the Saw
Habit 1 - Be
Proactive
A developer's goal in any
software project is to ensure that the software is
developed to a requirement that meets the customer
need and one that produces software that is reusable
and maintainable. Below are some
ideas for being proactive on software projects:
- Be Responsible for Great
Requirements - Don't blame others for
poor
requirements. Instead, work with the
team to fully analyze the requirements to ensure
they are complete, accurate and meet the needs
of the customer.
- Analyze Reusability during Design -
When creating a design, many developers look no
further than the current requirement for their
design. When creating a
detailed design for the requirement, the
developer should approach it to be used in other
ways than fill the existing design need.
For example, if you are designing a new system
and it has 20 listing screens and 20 edit
screens, it would be better to design a single
listing and a single edit screen that can
accommodate all 20 needs. The screens can
look and feel different if needed, but you can
still use the same code base by deploying
"behaviors" that dictate how the screen
operates. By making the screen reusable,
you can then build additional listing and edit
screens quickly because you are not re-writing
code from scratch. It also helps in
maintainability because if a major screen flaw
is found, you are only fixing a single screen
rather than 20 distinct screens.
- Communicate Effectively -
During development, it is imperative that everyone
knows the status of the development effort.
Communicate daily status via email or a
discussion forum. Discuss any impediments
that are keeping you from making progress.
Discuss (briefly) what code modules you worked
on for the day -- this allows others to know
what areas you are working in and can
proactively alert them if they are also working
in an area that might causes issues based on the
work you are doing.
Below is an example of how a developer logged
his status using
Software Planner (but you can
use any discussion tool you desire), notice that
the developer identified the defect numbers he
fixed, a general description of the fix and the
source code that was affected:

- Review Test Plans before Coding
Begins
- A great way to be proactive in decreasing QA
time is to have your QA team publish
test cases
before coding begins. You should require
that your developers review the test cases
before beginning coding and that they run the
test cases prior to shipping the code to QA for
testing. This reduces QA time by
validating that the test cases have good
coverage for the requirement and by bringing to
light things that the testers are expecting you
to code for (validation issues, bounds, etc.).
For this to be effective, you must build time
into the project plan for the developers to do
this. A good rule of thumb is to build 10%
extra time into the project plan for this
activity (if the coding is estimated at 200
hours, build 20 hours in for this activity).
By doing this, you can expect a 30% decrease in
QA time because you will minimize re-work, so
the effort is worth the investment.
Habit 2 - Begin with
the End in Mind
Your end goal for a software project
should be to deliver high quality software that
meets the needs of the client using reusable and
maintainable code. Before coding
begins, you should make a list of success criteria
that you judge the project on. For example,
your success criteria may be that the software
produces specific results, has no known defects (or
a small number of low severity defects), is
reusable, is maintainable, is well
documented, is easy to use, etc. By defining
the success criteria up front, you can objectively
evaluate whether the project met the criteria or
not. Solicit help from all team members
(project managers, product managers, testers,
automation engineers, other developers, documentation
specialists, etc.) when defining the success
criteria. By getting a team perspective of the
success criteria, you will have better and more
measurable criteria and you will get much better
buy-in from the team.
Habit 3 - Put First
Things First
Prioritizing your work effort is critical.
You must apply effort to the most important things
first, followed by less important things. For
example, everyone will generally agree that creating
reusable and easily maintainable code is important.
However, in an effort to do this, developers have a
tendency to "gold plate". "Gold plating" is
when a developer adds bells and whistles to the
feature that were not asked for and can easily
increase the complexity and estimated hours needed
to deliver the work. Be very careful with
this. It is great to create reusable
code, but it does not have to handle every future
scenario that you can dream up. Instead, stick
with the stated features needed but organize the
code in a way that makes it easy to extend and
improve in future releases. As you
develop the code, do team code reviews to identify
how to better reuse code, to spot troubled code and
to reorganize for maximum maintainability.
Habit 4 - Think Win/Win
In many
organizations, development and testing teams play a
blame game and create tension between the teams.
This can be very disruptive and can greatly affect
the quality of the software project and the user
experience. The development and testing
teams should have a common goal -- to ensure that
the client receives the software with the highest of
quality. If this is a unilateral goal of the
team, it makes sense for all team members to provide
help and encouragement to each other so that when
the software is shipped with high quality and the
client is happy, everyone on the team basks in the
joy of a happy client. If you want to
encourage an environment of trust, respect and
foster an win/win team, here are a few tips:
- Share Knowledge - Don't
hold your knowledge to yourself, share it with
others.
- Socialize - Eat lunch with
members in different roles in your company.
Learn more about them, take a general interest
in their hobbies and personal goals.
- Encourage Others -
Offer congratulations and compliments to team
members that you see are doing a great job.
Tell your (and their) manager how well you think
they are doing. Tell them how much you
appreciate their efforts.
- Help Struggling Team Members
- If you see team members struggling,
jump in and offer to help. If you offer,
follow through and ensure they get the help they
need. You may need help in the future so
offering help can foster a win/win relationship
for you in the future.
Habit 5 - Seek First to
Understand, Then to be Understood
Many of
us have a bad habit of blocking out a conversation
and not listening because we so desperately want our
opinion to be heard. Every developer and
team member has a different experiences, different
perspectives and motivations.
Before
you can solve any problem, it is important to first
listen intently and diligently to fully understand
the problem. Once you feel you have all
the facts, solicit ideas for multiple solutions.
Having several options can provide better
discussions and allows team members to tweak initial
solutions into solutions that are more far reaching
and solve the problem in a more direct way.
If you disagree with an approach, don't attack the
person that offered the approach. Instead,
explain based on your past experiences why you think
there might be a better approach. To get
started with this, schedule time weekly for code
reviews. Code reviews allow people with
different experiences and skill levels to
objectively evaluate your coding structure and style
and make recommendations for maximum reuse and
maintainability. You also will learn a lot in
the process and allow yourself to approach
challenges in a different way.
Habit 6 - Synergize
Team
collaboration is the key to a synergized team.
A synergized team is made up of divergent team
members that have different strengths, different
backgrounds and different perspectives.
Encourage these differences but provide your team
with
tools that allow you maximize their
effectiveness. Highly collaborative teams
communicate with each other by
sharing their
calendars, posting their statuses into
discussion
forums so that everyone is aware of what the other
is doing and accomplishing. These teams keep
track of all tasks they work on each day, the number
of hours worked, the number of hours remaining and
variances to plan. They also
share documents
that illustrate best practices and produce white
papers that teach others what they have learned.
Habit 7 - Sharpen the
Saw
Productive developers see the need to continue honing
their skills and love learning new techniques, best
practices and approaches. They have a thirst
for knowledge, reading every development book they can
get their hands on.
They also know when to have fun. They recharge
their batteries by taking great vacations and by
having outside hobbies and activities. Here
are a few of our favorite development books:
- Agile Project Management with Scrum - by Ken
Schwaber, Microsoft Press
- The Enterprise and Scrum - by Ken Schwaber,
Microsoft Press
- Code Complete - by Steve McConnell,
Microsoft Press
- Rapid Application Development, by Steve
McConnell, Microsoft Press
|
|
Helpful
Resources
Below are some helpful
resources and templates to aid you in developing software
solutions:
|
About the Author
Steve Miller is the President of Pragmatic Software
(http://www.PragmaticSW.com).
With over 24 years of experience, Steve has
extensive knowledge in project management, software
architecture and test design. Steve publishes a
monthly newsletter for companies that design and
develop software. You can read other newsletters at
http://www.PragmaticSW.com/Newsletters.asp.
|
|
Note:
This newsletter is never sent unsolicited, it was
opted into from our website. If you wish to
unsubscribe,
click here. |
|
|