Page 83 - DCAP405_SOFTWARE_ENGINEERING

Software Engineering

Notes among teams, a Product Owner must fight the urge to micro-manage. At the same time,
Product Owners must be available to answer questions from the team.
2. ScrumMaster: The ScrumMaster acts as a link between the Product Owner and the team.
The ScrumMaster does not manage the team. Instead, he or she works to remove any
impediments that are obstructing the team from achieving its sprint goals. In short, this
role helps the team remain creative and productive, while making sure its successes are
visible to the Product Owner. The ScrumMaster also works to advise the Product
Owner about how to maximize ROI for the team.
3. Team Member: In the Scrum methodology, the team is responsible for completing work.
Preferably, teams consist of seven cross-functional members, plus or minus two individuals.
For software projects, a typical team comprises a mix of software engineers, architects,
programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is
responsible for determining how it will achieve the work to be completed. This grants
teams a great deal of autonomy, but, similar to the Product Owner’s situation, that liberty
is accompanied by a responsibility to meet the goals of the sprint.

5.2.5 Crystal

The Crystal method is one of the mainly lightweight, adaptable approaches to software
development. Crystal is really comprised of a family of methodologies (Crystal Clear, Crystal
Yellow, Crystal Orange, etc.) whose unique characteristics are driven by several factors such as
team size, system criticality, and project priorities. This Crystal family addresses the realization
that each project may require a slightly tailored set of policies, practices, and processes in order
to meet the project’s unique characteristics.
Several of the key tenets of Crystal comprise teamwork, communication, and simplicity, as well
as reflection to frequently adjust and improve the process. Like other agile methodologies,
Crystal promotes early, ordinary delivery of working software, high user involvement,
adaptability, and the removal of bureaucracy or distractions.

5.2.6 Feature-Driven Development (FDD)

FDD was initially developed and articulated by Jeff De Luca, with contributions by M.A.
Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first personification of
FDD occurred as a result of collaboration between De Luca and OOD thought leader Peter Coad.
FDD is a model-driven, short-iteration process. It begins with found an overall model shape.
Then it carry on with a series of two-week “design by feature, build by feature” iterations. The
features are small, “useful in the eyes of the client” results. FDD designs the rest of the development
process around feature delivery using the following eight practices:
1. Domain Object Modeling
2. Developing by Feature
3. Component/Class Ownership

4. Feature Teams
5. Inspections
6. Configuration Management

7. Regular Builds
8. Visibility of progress and results

76 LOVELY PROFESSIONAL UNIVERSITY