This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
What type of skills do you need to be effective at agile development processes
such as Extreme Programming (XP), Feature Driven Development (FDD), Agile Modeling
(AM) or SCRUM? From a personal point of view, should you specialize and become
expert at a single activity or become a jack-of-all-trades generalist who knows
a little about a lot? From a management point of view, if you're forming a team,
what type of people should you strive to include?
To address the complexity of software development, the first reaction of many
organizations is to build a team of specialists, assuming that because specialists
are proficient at a specific task, they are therefore more efficient; therefore,
the optimal organization involves a team of specialists who hand off their work
to other specialists. This "assembly-line" school of thought may be
appropriate for prescriptive software processes, but it's clearly not appropriate
for agile processes. Furthermore, a specialist-focused approach is geared toward
larger teamsif there are X distinct tasks required to develop software, you
need at least X specialists following this approach. How big is X? Twenty? Fifty?
One hundred? Depends on how finely you define the specialties, doesn't it? Considering
that most agile development methodologies are aimed at small teams of developers,
the specialist approach isn't likely to work well.
Specialists often have difficulties working with others: Either they lack the
humility to recognize that other people have something of value to offer, or
they are so narrowly focused that they may not realize that their work may cause
someone else to do significant rework later on.
Despite their name, specialists' skills may not be up to snuff, even in their
own specialty. The high rate of technical change within the IT industry provides
an environment in which developers can work with a new technology for several
months, become reasonably familiar with it and claim to be experts because of
the lack of competition. All these factors contribute to the hazards of building
a team of people who are only specialists.
So how about a team of only generalists? Everyone would have a fairly good
understanding of how to develop software, but unfortunately may not possess
the detailed knowledge required to get the job done. Your project will need
people intimately familiar with the techniques and technology you're using.
If you're working with Enterprise JavaBeans (EJB), you want developers with
expertise in Java programming as well as in EJB development. A team working
with Oracle on the back end will also want someone with Oracle database administration
experience, and a team developing software for a brokerage will want people
who understand the nuances of stock and bond trading.
Clearly, neither extreme works wellinstead, what you want is something
in the middle. One approach is to build a combined team of generalists and specialists.
The generalists provide the glue, focusing on the bigger picture, while the
specialists deal with the project's detailed complexities. This works well because
the generalists' strengths balance the specialists' weaknessesand vice versa.
An even better approach is to build a team comprised of people who are generalists
with one or two specialties. For example, I'd claim that I'm a generalist. I
have a pretty good handle on how the software process fits together, yet I have
specialties in business application software modeling, object persistence and
Java programming. One of my current coworkers is a generalist with specialties
in modeling, EJB development and testing, whereas another is a generalist with
specialties in telecommunications networking and Java programming. The advantage
of building teams from generalists who have one or more specialties is that
they quickly find common ground with their coworkersafter all, they're generalists,
with the necessary background to appreciate the importance of other specialties.
The main disadvantage is that these people are often very senior, and thus are
difficult to findit can easily take ten to 20 years to gain sufficient experience
to become a generalist.
There's never a perfect solution. I advise developers to continue learning
new skills, particularly a wide range. Have some technical as well as "soft"
people skills. Take on diverse roles on projects, and try to work on different
types of projects in various domains. The more you know, the more valuable you
become, and being valuable is always a good career strategy.
Recently on the Agile Modeling Mailing List:
Misconceptions regarding Agile Modeling (AM). This was a conversation that
I began when I became concerned with the misconceptions regarding Extreme
Programming (XP) that came up on newsgroups such as comp.object and comp.software-eng.
These misconceptions include the idea that you can't use CASE tools with AM,
that you can't review agile models and that positions such as "business
analyst" are disallowed.
The notion of primary keys. We had several discussions regarding key strategies
within physical data models, an important modeling consideration that affects
both your data schema as well as your source code. The relative merits of
surrogate keys and natural keys were discussed in detail, each strategy having
its own backers.
Use case modeling issues. A conversation that began on the Rational Unified
Process users group spilled over onto the AM mailing list when someone needed
help trying to understand the appropriate use of the <<include>>
and <<extend>> stereotypes. My rule of thumb is that when you
know the exact step where another use case needs to be invoked, then <<include>>
is likely what you want, whereas if a use case may be invoked any time during
a range of steps, then <<extend>> is your better option. I like
to think of <<include>> as a function call and <<extend>>
as a hardware interrupt.
Currently we allow the following HTML tags in comments:
Single tags
These tags can be used alone and don't need an ending tag.
<br> Defines a single line break
<hr> Defines a horizontal line
Matching tags
These require an ending tag - e.g. <i>italic text</i>
<a> Defines an anchor
<b> Defines bold text
<big> Defines big text
<blockquote> Defines a long quotation
<caption> Defines a table caption
<cite> Defines a citation
<code> Defines computer code text
<em> Defines emphasized text
<fieldset> Defines a border around elements in a form
<h1> This is heading 1
<h2> This is heading 2
<h3> This is heading 3
<h4> This is heading 4
<h5> This is heading 5
<h6> This is heading 6
<i> Defines italic text
<p> Defines a paragraph
<pre> Defines preformatted text
<q> Defines a short quotation
<samp> Defines sample computer code text
<small> Defines small text
<span> Defines a section in a document
<s> Defines strikethrough text
<strike> Defines strikethrough text
<strong> Defines strong text
<sub> Defines subscripted text
<sup> Defines superscripted text
<u> Defines underlined text
Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.
This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!