|
| |
Project Lead/Management FAQ
How to understand the project requirement or pass on the project
requirements to technical team?
UML- Universal Mark Up Language is the universal language spoken by both
technical and non technical people for communicating project requirement. Usually business analysts and project managers fail to communicate the
project project requirement as they can not understand UML. You don't have to
read big books on UML. Just refer to
this small PDF to
understand exactly what you need to know about UML for communicating project
requirements.
What is the magic formula for project team formation for success?
There are mainly two types of team formation in projects. Flat model, where
there is no hierarchy in terms of responsibilities. There is another model,
which is hierarchy based. Read pros and cons of both
model here, before forming your team/organization model.
I have got comments from the technical architect about the existing
code or product. Is it advised to allot team hours to modify a working code?
To refractor existing follow these guidelines.
How to efficiently manage rapidly changing requirements?
This is an usual
challenge faced by almost every IT department. These issues are more
predominant where marketing and engineering team
works in their own caves and marketing keeps on changing the requirements for
a new product spec. The scientific way to deal such risks are to use the right
tools to control the changes. Some development teams rely heavily on so called
software engineering process to save their back. Here are some tips from real
world, which not only helps you to protect your commitment but also adds to the
overall value of the deliverables:
- The management mantra - "The only constant in software development is
change". Anticipate and precipitate change. In other words welcome change or
be prepared for change at several stages of development. But depending on the
current situation either accept, filter or postpone change requests.
- Use a tool to start the change request process.
http://office.microsoft.com/en-us/templates/TC011417251033.aspx?pid=CT101481361033
- Use a tool to track scope change from
http://office.microsoft.com/en-us/templates/TC011429471033.aspx?pid=CT101440991033
- Depending on the stage where the project is currently in, every change has
a cost associated to it. The cost of change request increases exponentially
from inception to elaboration to construction to transition. Too many change
requests at a later stage of the project shows the deficiency of the business
analyst or the architect at the requirement gathering phase.
- Finally learn to live with pending change requests even at the time of GA
release. A super duper product delayed after its actual need is worse than
reasonable, well built software at the right time.
How to efficiently manage teams located in different geographical region?
There is always some challenges when teams are geographically dispersed.
The challenges are mainly in terms of ethnic differences, time zone differences,
difference in management style and configuration management of source and
deliverables.
What are the most common issues faced by software projects ?
The most common issue faced by any software project are non technical and
human centric. Technical issues could be resolved by either choosing the right
technology or the right skilled people. However human issues needs to be
escalated and resolved using the best practices. Here are some tools which
will be helpful:
-- It's all team work. Define a project team communication plan using
http://office.microsoft.com/en-us/templates/TC011455851033.aspx?pid=CT101172331033
-- Gather project feedbacks and take corrective actions at regular
intervals internally and with client.
http://office.microsoft.com/en-us/templates/TC011437401033.aspx?pid=CT101438151033
-- Record the lessons learned from each project to utilize your past
experience.
http://office.microsoft.com/en-us/templates/TC011417221033.aspx?pid=CT101438521033
-- For technical issue tracking use your existing bug tracking system or
use this access template
http://office.microsoft.com/en-us/templates/TC012186931033.aspx?pid=CT101426031033
-- Acknowledge each individual strengths and reward them. Similarly identify
individual bottlenecks and avoid them.
What is CMM and what the various levels of it?
These are the five canonical Levels of Software Process Maturity of the
Software Engineering Institute's Capability Maturity Model:
Level 1: The Initial Level
The benefits of good software engineering practices are undermined by
ineffective planning and reaction-driven commitment systems. During a crisis,
projects typically abandon planned procedures and revert to coding and
testing.
The organization typically does not provide a stable environment for
developing and maintaining software. When an organization lacks sound
management practices, the benefits of good software engineering practices are
undermined by ineffective planning and reaction-driven commitment systems.
During a crisis, projects typically abandon planned procedures and revert to
coding and testing. Success depends entirely on having an exceptional manager
and effective software team. Occasionally, capable and forceful software
managers can withstand pressures to take shortcuts in the software process;
but when they leave the project, their stabilizing influence leaves with them.
Even a strong engineering process cannot overcome the instability created by
the absence of sound management practices.
The software process capability of Level 1 organizations is unpredictable
because the software process is constantly changed or modified as the work
progresses (i.e., the process is ad hoc). Schedules, budgets, functionality,
and product quality are generally unpredictable. Performance depends on the
capabilities of individuals and varies with their innate skills, knowledge,
and motivations. There are few stable software processes in evidence, and
performance can be predicted only by individual rather than organizational
capability.
Level 2: The Repeatable Level
Disciplined Process. Policies for managing a software project and procedures
to implement those policies are established. An effective process can be
characterized as practiced, documented, enforced, trained, measured, and able
to improve.
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking and oversight
Software project planning
Requirements management
Policies for managing a software project and procedures to implement those
policies are established. Planning and managing new projects is based on
experience with similar projects. An objective in achieving Level 2 is to
institutionalize effective management processes for software projects, which
allow organizations to repeat successful practices developed on earlier
projects, although the specific processes implemented by the projects may
differ. An effective process can be characterized as practiced, documented,
enforced, trained, measured, and able to improve.
Projects in Level 2 organizations have installed basic software management
controls. Realistic project commitments are based on the results observed on
previous projects and on the requirements of the current project. The software
managers for a project track software costs, schedules, and functionality;
problems in meeting commitments are identified when they arise. Software
requirements and the work products developed to satisfy them are baselined,
and their integrity is controlled. Software project standards are defined, and
the organization ensures they are faithfully followed. The software project
works with its subcontractors, if any, to establish a strong customer-supplier
relationship.
The software process capability of Level 2 organizations can be summarized as
disciplined because planning and tracking of the software project is stable
and earlier successes can be repeated. The project is under the effective
control of a project management system, following realistic plans based on the
performance of previous projects.
Level 3: The Defined Level
Standard, consistent process. The standard process for developing and
maintaining software across the organization is documented. The software
process capability of Level 3 organizations can be summarized as standard and
consistent because both software engineering and management activities are
stable and repeatable.
Peer reviews
Intergroup coordination
Software product engineering
Integrated software management
Training program
Organization process definition
Organization process focus
The standard process for developing and maintaining software across the
organization is documented, including both software engineering and management
processes, and these processes are integrated into a coherent whole. This
standard process is referred to throughout the CMM as the organization's
standard software process. Processes established at Level 3 are used (and
changed, as appropriate) to help the software managers and technical staff
perform more effectively. The organization exploits effective software
engineering practices when standardizing its software processes. There is a
group that is responsible for the organization's software process activities,
e.g., a software engineering process group, or SEPG. An organization-wide
training program is implemented to ensure that the staff and managers have the
knowledge and skills required to fulfill their assigned roles.
Projects tailor the organization's standard software process to develop their
own defined software process, which accounts for the unique characteristics of
the project. This tailored process is referred to in the CMM as the project's
defined software process. A defined software process contains a coherent,
integrated set of well-defined software engineering and management processes.
A well-defined process can be characterized as including readiness criteria,
inputs, standards, and procedures for performing the work, verification
mechanisms (such as peer reviews), outputs, and completion criteria. Because
the software process is well defined, management has good insight into
technical progress on all projects.
The software process capability of Level 3 organizations can be summarized as
standard and consistent because both software engineering and management
activities are stable and repeatable. Within established product lines, cost,
schedule, and functionality are under control, and software quality is
tracked. This process capability is based on a common, organization-wide
understanding of the activities, roles, and responsibilities in a defined
software process.
Level 4: The Managed Level
Predictable process. The standard process for developing and maintaining
software across the organization is documented. The software process
capability of Level 3 organizations can be summarized as standard and
consistent because both software engineering and management activities are
stable and repeatable.
Software quality management
Quantitative process management
The organization sets qualitative quality goals for both software products and
processes. Productivity and quality are measured for important software
process activities across all projects as part of an organizational
measurement program. An organization-wide software process database is used to
collect and analyze the data available from the projects' defined software
processes. Software processes are instrumented with well-defined and
consistent measurements. These measurements establish the quantitative
foundation for evaluating the projects' software processes and products.
Projects achieve control over their products and processes by narrowing the
variation in their process performance to fall within acceptable quantitative
boundaries. Meaningful variations in process performance can be distinguished
from random variations (noise), particularly within established product lines.
The risks involved in moving up the learning curve of a new application domain
are known and carefully managed.
The software process capability of Level 4 organizations can be summarized as
predictable because the process is measured and operates within measurable
limits. The level of process capability allows an organization to predict
trends in process and product quality within the quantitative bounds of these
limits. When these limits are exceeded, action is taken to correct the
situation. Software products are of predictably high quality.
Level 5: The Optimizing Level
Continuously improving process. The standard process for developing and
maintaining software across the organization is documented. The software
process capability of Level 3 organizations can be summarized as standard and
consistent because both software engineering and management activities are
stable and repeatable.
Process change management
Technology change management
Defect prevention
At the Optimizing level, the entire organization is focused on continuous
process improvement. The organization has the means to identify weaknesses and
strengthen the process proactively, with the goal of preventing the occurrence
of defects. Data on the effectiveness of the software process is used to
perform cost benefit analyses of new technologies and proposed changes to the
organization's software process. Innovations that exploit the best software
engineering practices are identified and transferred throughout the
organization.
Software project teams in level 5 organizations analyze defects to determine
their causes. Software processes are evaluated to prevent known types of
defects from recurring, and lessons learned are disseminated to other
projects.
The software process capability of Level 5 organizations can be characterized
as continuously improving because Level 5 organizations are continuously
striving to improve the range of their process capability, thereby improving
the process performance of their projects. Improvement occurs both by
incremental advancements in the existing process and by innovations using new
technologies and methods.
--------------------------------------------------------------------------------
After the publication of the SEI's CMM, Internet wags facetiously added the
following classifications. It turns out that they were not so far off the
mark: such organizations do exist.
Level 0: The Clueless Level
Undisciplined. Software development is ad-hoc, undisciplined, and without
plan.
Software development is ad-hoc, undisciplined, and without plan. Individual
engineers in a Level 0 organization are often brilliant and highly capable
when working on individual projects, but generally have little or no
experience in working as part of a team and have no knowledge of formal
software engineering processes. Defect-free software is expected to arise
naturally out of the capabilities of the programmers, and the presence of bugs
invariably creates an emergency. Management has little or no understanding of
engineering issues.
The transition to Level 1 can be accomplished through appropriate training of
engineers and managers. Properly handled, education about process and quality
can appeal to engineers' pride and result in a successful transition to a
quality-conscious software development organization. However, if process is
imposed without consideration for the engineers' needs, there is the danger of
the organization turning to Level -1 instead.
Level -1: The Resistant Level
Active Opposition. Key personnel actively oppose the establishment of
formal software engineering processes.
Key personnel, though brilliant and successful contributors to the
organization's fundamental technologies, actively oppose the establishment of
formal software engineering processes. Writing specifications and test plans
is viewed as a waste of time and money. Code reviews are seen as affronts to
the dignity and pride of the engineers. Quality Assurance is viewed as the
Enemy. Users are rarely considered; errors are invariably caused by them and
not by the design. Software occasionally demos nicely but often falls apart
under close scrutiny. Management views the establishment of procedures and
infrastructure as a waste of time, money, and resources.
The next stage of such an organization's development must be Level 1, for the
Level -1 organization is aware of formal processes but refuses to implement
them. Thus the transition to Level 1 is likely to be difficult.
Level -2: Fanatic
Fanatical Support of Process. Managers and development team leaders stress the
importance of following the process to the expense of actually ever shipping
product.
Process rules. To change a single line of code it must be entered in the
bugbase by a user or QA engineer, validated by a second engineer, approved by
the QA manager, reviewed by the bug scrub committee, assigned by the
development manager, performed by a development engineer, reviewed by three
other engineers, regressed by another QA engineer, and documented by a writer.
Following the process is more important than actually getting any work done.
Shipping a profitable or usable product is secondary to satisfying the
customer's process requirements. As long as yards and yards of documentation
notebooks can be delivered it is unimportant whether there is any software to
accompany them.
Reaching any positively numbered stage can be achieved only by a massive
fundamental change in the entire department or company's development
philosophy. Fear of reaching this state is the reason most commonly given by
people at Level -1 to not implementing any formal processes.
What is lean development methodology?
Lean Development focuses on the creation of change-tolerant software. This
methodology embodies the notion of dynamic stability which can be thought of
as similar to how Scrum embraces controlled chaos. Bob Charette, the
originator, writes that the measurable goal of LD is to build software with
one-third the human effort, one-third the development hours and one-third the
investment as compared to what SEI CMM Level 3 organization would achieve.
There are 12 principles of Lean Development:
- Satisfying the customer is the highest priority.
- Always provide the best value for the money.
- Success depends on active customer participation.
- Every LD project is a team effort.
- Everything is changeable.
- Domain, not point, solutions.
- Complete, don't construct.
- An 80 percent solution today instead of 100 percent solution tomorrow.
- Minimalism is essential.
- Needs determine technology.
- Product growth is feature growth, not size growth.
- Never push LD beyond its limits.
What is extreme programming?
The main goal of XP is to lower the cost of change in software
requirements. With traditional system development methodologies, like the
Waterfall Methodology, the requirements for the system are determined and
often "frozen" at the beginning of the development project. This means that
the cost of changing the requirements at a later stage in the project --
something that is very common in the real-world -- can be very high.
- Interaction between developers and customers is good. Therefore, an XP
team is supposed to have a customer on site, who specifies and prioritizes
work for the team, and who can answer questions as soon as they arise. (In
practice, this role is sometimes fulfilled by a customer proxy.)
- If learning is good, take it to extremes: Reduce the length of
development and feedback cycles. Test early.
Simple code is more likely to work. Therefore, extreme programmers only
write code to meet actual needs at the present time in a project, and go to
some lengths to reduce complexity and duplication in their code.
- If simple code is good, re-write code when it becomes complex.
Code reviews are good. Therefore XP programmers work in pairs, sharing one
screen and keyboard (which also improves communication) so that all code is
reviewed as it is written.
- Testing code is good. Therefore, in XP, tests are written before the
code is written. The code is considered complete when it passes the tests
(but then it needs refactoring to remove complexity). The system is
periodically, or immediately tested using all pre-existing automated tests
to assure that it works. See test-driven development.
XP has been used successfully on teams of over a hundred developers. It is not
that XP doesn't scale, just that few people have tried to scale it, and
proponents of XP refuse to speculate on this facet of the process.
What is agile software development?
Agile software development is a conceptual framework for undertaking
software engineering projects.
Most agile methods attempt to minimize risk by developing software in short
timeboxes, called iterations, which typically last one to four weeks. Each
iteration is like a miniature software project of its own, and includes all
the tasks necessary to release the mini-increment of new functionality:
planning, requirements analysis, design, coding, testing, and documentation.
While an iteration may not add enough functionality to warrant releasing the
product, an agile software project intends to be capable of releasing new
software at the end of every iteration. At the end of each iteration, the team
reevaluates project priorities.
Agile methods emphasize realtime communication, preferably face-to-face, over
written documents. Most agile teams are located in a bullpen and include all
the people necessary to finish the software. At a minimum, this includes
programmers and the people who define the product such as product managers,
business analysts, or actual customers. The bullpen may also include testers,
interface designers, technical writers, and management.
Agile methods also emphasize working software as the primary measure of
progress. Combined with the preference for face-to-face communication, agile
methods produce very little written documentation relative to other methods.
|
