Page 83 - DCAP405_SOFTWARE_ENGINEERING
P. 83

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
   78   79   80   81   82   83   84   85   86   87   88