This presents a great challenge for many IT venders. From
contract point of view, we are doing some kind of fix scope, fix budget, fix
duration project. From delivery point of view, we are required to provide interim
feature releases. We, IT vender, need to stand up to this challenge to delivery
high quality IT solution for our clients.
This is what happens In a typical RUP project:
We get all use cases
documented and bring them to design phase. In design phase, we take in all
use cases as input together with all non-functional requirements and produce a holistic
design for the system. The output of the design phase includes package diagrams,
component diagrams, class diagrams sequence diagrams and wireframes in conjunction with supplementary design
documents in various levels. Then we bring all these design artifacts into construction phase. In
construction phase, we assign WBS (Work Breakdown Structure) to each
development team member, then track them in MS Project or in a Excel file. More
than often, these are in the detail level of “develop a method in a specific
class”. When all WBS are completed, the
team start to do Integration Test and resolve all identified defects in stabilization
phase. After that, the system goes to production and Production
Support phase gets started. Some time, a new project aim further enhance the
product gets kicked out when current version of the system is in product
support phase.
In this process, there are a few important characteristics. First
of all, there are exit criteria defined for
each phase, at end of each phase, some kind of sign off need to happen. Once a
specific artifact is signed off, any further change will go through change
control process. Secondly, the transformation from use case to component design
is done in the design phase. When the programmers are given a WBS to work on,
that is not directly related to one specific use case, instead it is directly
related to a specific part of a component.
It is imperative that the team executes each phase in
accordance to the exit criteria defined. Requirement review, design review and
code review need to be conducted to ensure there is nothing missed before
moving on to the next phase.
However, I have seen many failed project making the following
common mistakes:
1.
Due to lack of visibility, most of ( if not all)
parties have difficult in visualize the envisioned solution. Hence the reviews
of these produced artifacts become less meaningful.
2.
In order to secure client sign off on these
artifacts, the team spent too much time on documentation, the visual format of
these artifacts. So much so that, they eats in the time and budgets allocated to
construction phase and stabilization phase.
Which in turn directly result in poor quality of the final product.
3.
Due to the rigid change process, even the team produced
documented system, it is less useful to the business due to mistakes made in these signed off artifacts and the change in
business operation.
This is what happens In a typical Agile project:
The contract is usually signed as “Time and Material “
based. In each iteration, user oriented
features are put in development. A project architect works with the development
team providing architecture guidelines, principles, sometime even get involved in
detail design of the user oriented feature.
One of most important characteristics is that when the team
is working on a feature in current iteration, it is very well possible that the user
community is still working on the business requirement of another feature. But the development team does not have visibility
to what are in the pipeline. As the result of it, the team could not come out with a
holistic design before the first line of the code is written. More than often,
in order to have seamless design for both features, change in the formal design
is needed. It is not correct to say “ in agile, they do not do design, or
design is not needed”. In the reality in
a success Agile project, the team are doing design all the time and change the
design all the time.
Due to the limited visibility in requirement, It is imperative
that the all team members are encourage to do refactoring throughout the
project duration from first iteration to the last when they are given a new
feature to development.
In this ever changing code base, it is imperative to
implement automat unit test and continuous integration build process to safeguard
the produced features when the new features are been developed.
However, I have seen some failed projects making some kind
of common mistakes which contributed to the failure of the project:
1.
They totally eliminated design element from the
project, the codebase become disorganized collection of code blocks. So much so
that the team has to start over again.
2.
They do not dare to do refactoring existing code
as new features are put in development. Which result in repetition, confuted,
un-maintainable code base
3.
To “save” time, the team decide not to engage in
automated unit test authoring. As the team
doing refactoring, the stability of the codebase are greatly comprised.
The other common mistakes I have seen in projects using the disconnect
between the development community and the rest of the project team and
individuals are given the task to do what they are not equipped to do.
The disconnection is reflected in following symptoms:
1.
The user / business analysis do not read the design document
2.
architect / designer do not read the requirement
document
3.
architect / designer do not read the code
4.
developers/ programmers do not read the design document
The justifications cited are often “ there are too much documentation,
I simply do not have time to read them. If I read them all, I would not have time
to do my work.” The result of this symptoms is that there are contradicting
among these artifacts, more than often the
discrepancy between the requirement and the code written is largest among all.
Skill and task mismatch is reflected in following symptoms
1.
involving user and business analysis in design
activities under the name of JDS ( Join Design Session) . In these produced High Level Design Document (HLD), the design decisions made by non-professional designer are documented as requirements. On the other
hand, because it is “high level” by definition,
it lack of business requirement details.
2.
The team is constantly under pressure to meet delivery
timelines. To meet the changeling timelines, the team is forced or choose to cut
Connors and take up technology debts. These Connors cutting and technology
debts taking produce long lasting impact in overall project health, which costs
much more to recover from at the later time of the project. I have seen many projects
failed because of just that.
Okay, if you are
still reading, you must eager to know what is my solution for all these. May be
you have seen some project failures like I have. Let me get to that.
1.
Regardless how the project is structured in the contractual
expect, if you go with RUP process, execute it as it should be done, if you go
with Agile process, execute it as it should be done. The worse case is that you
give up the principles of RUP process with the reason that client wants to have
interim delivery, and you give up the principles of Agile process because the
client wants to have a fix bid project. That
is the best recipe for failure. If you call it hybrid, that is not the hybrid you
want to have in your project.
2.
If you want to directly put use case / requirement
into development process, you are doing agile. So refractory, unit tests, continuous
build are your best friend.
3.
If you want to have holistic design in place
before the development effort is started, you are doing URP. So exit criteria, review process need to be formalized.
Change control needs to be both formalized and flexible enough.
4.
In any case, let SMEs provide the requirement,
let the professional designer / architects do the design and let the developers
do the development. In another word “let the people do what they do the best”. In agile process, all development team members are
both designers and developers, they need to be equipped with the skill to do the
job. To address that, pair programming would be a great help as a form of OJT
(On Job Training), The overall cost of pair programming is much smaller than
most people thought to be.
5.
In any case, if your team have some talking
heads, remove them from the project. They are over-head cost to the project
without adding value. When I said “talking head”, I refer to these who are involved
everywhere but are not good anywhere. Specifically,
they talk a lot project management terms but does not carry PM responsibility;
they talk a lot business terminologies
but do not carry BA responsibility; they talk a lot technology terms but not equipped
with the technical skills in the specific platform the envisioned system is to
be built on to be effective either as architect or developer.
6.
In any cases, integrated ALM implementation with
IDE will greatly improve your chance of success.
7. In any case, an individual is capable
or not to take up a specific task is not based on who he or she is rather than
based on what skills he or she possesses. give them the task they can perform is better than give them the task they are suppose to perform based on their title or role in the project.
No comments:
Post a Comment