Crystal Methodologies - Project | DCS 801, Study Guides, Projects, Research of Computer Science

Material Type: Project; Class: Software Design and Implementation I; Subject: Doctoral Computing Studies; University: Pace University-New York; Term: Unknown 2007;

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 08/09/2009

koofers-user-2q5
koofers-user-2q5 🇺🇸

8 documents

1 / 5

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Crystal Methodologies
Crystal Methodologies is a family of methodologies developed by Alistair Cockburn.[1] The
word “Crystal” refers to the degree of hardness and the different colors of the methodology in
much the same way that a crystal can have various degrees of hardness and variety of colors.
The degree of hardness pertains to the use of rigor and ceremony i.e. as the hardness increases
the amount of required documentation, processes and procedures increases.[6] The color is
concerned with the “heaviness” of the project; the lighter the color the fewer the number of
people on the project whereas the darker the color indicates the requirement for more resources.
[1]
There are two “core" elements of the Crystal philosophy. The first core element is that software
development can be viewed as a game of invention and communication with the main goal being
to develop useful, working software. The second element is the setup for the next game to
follow. Members of the Crystal methods share values and principles and on-the-fly tuning.[1] All
of the Crystal methods are highly people and communication centric and recognize the varying
human cultures.
The two rules that are common to all the Crystal methods are as follows:
1. The project must use incremental development with increments of four months or less with a
string preference of one to three months
2. The team must hold both pre- and post- reflection with a strong preference for mid-project
reflection workshops [1]
One of the restrictions of the Crystal methods is that they only address collocated teams. Thus,
the Crystal methods would not apply to distributed or offshore teams for which Cockburn offers
no recommendation other than to locate the team together at one location.
As was previously mentioned the Crystal methods are denoted by colors. The color of the
methods as follows: Clear, Yellow, Orange, Orange Web, Red, Magenta, and Blue. Only three of
the methods – Crystal Clear, Orange and Orange Web - have been constructed and actually used
on projects. The Crystal methods can actually be considered to be a sort of family and visually
arranged in a cube as illustrated in Figure 1. [5]
1
pf3
pf4
pf5

Partial preview of the text

Download Crystal Methodologies - Project | DCS 801 and more Study Guides, Projects, Research Computer Science in PDF only on Docsity!

Crystal Methodologies Crystal Methodologies is a family of methodologies developed by Alistair Cockburn.[1] The word “Crystal” refers to the degree of hardness and the different colors of the methodology in much the same way that a crystal can have various degrees of hardness and variety of colors. The degree of hardness pertains to the use of rigor and ceremony i.e. as the hardness increases the amount of required documentation, processes and procedures increases.[6] The color is concerned with the “heaviness” of the project; the lighter the color the fewer the number of people on the project whereas the darker the color indicates the requirement for more resources. [1] There are two “core" elements of the Crystal philosophy. The first core element is that software development can be viewed as a game of invention and communication with the main goal being to develop useful, working software. The second element is the setup for the next game to follow. Members of the Crystal methods share values and principles and on-the-fly tuning.[1] All of the Crystal methods are highly people and communication centric and recognize the varying human cultures. The two rules that are common to all the Crystal methods are as follows:

  1. The project must use incremental development with increments of four months or less with a string preference of one to three months
  2. The team must hold both pre- and post- reflection with a strong preference for mid-project reflection workshops [1] One of the restrictions of the Crystal methods is that they only address collocated teams. Thus, the Crystal methods would not apply to distributed or offshore teams for which Cockburn offers no recommendation other than to locate the team together at one location. As was previously mentioned the Crystal methods are denoted by colors. The color of the methods as follows: Clear, Yellow, Orange, Orange Web, Red, Magenta, and Blue. Only three of the methods – Crystal Clear, Orange and Orange Web - have been constructed and actually used on projects. The Crystal methods can actually be considered to be a sort of family and visually arranged in a cube as illustrated in Figure 1. [5]

Alistair Cockburn ©Humans and Technology, Inc., 1998-9 (^) Slide 11 Number of people involved

C riticality

(d efects c au se lo ss o f. ..) Comfort (C) Essential money (E) Life (L) +20%

... (^) Prioritized for Legal Liability 1 - 6 - 20 - 40 - 100 - 200 - 500 - 1, C6 C20 C40 C100 C200 C500 C D6 D20 D40 D100 D200 D500 D E6 E20 E40 E100 E200 E500 E L6 L20 L40 L100 L200 L500 L Prioritized for Productivity & Tolerance Choose a Methodology according to (project size, system criticality, teampriorities) Discretionary money (D) Figure 1 The Crystal Methods (fr: The Crystal Methods or How to make a methodology fit Alistair Cockburn, Agile Development Conference, 2003) In Figure 1, moving to the right on the X axis the number of the people on the project increases which result a decreased amount of face-to-face communication among team members. This also means that a heavier methodology must be used. The Y axis denotes the system’s potential for causing damage and range from loss of comfort to loss of life. In terms of the crystal analogy this means that the degree of “hardness” of the project increases as one move up the Y-axis. The outside world dictates the required elements in the methodology and the resulting deliverables for projects in the upper range of the Y-axis. Projects of this type include medical projects regulated by the FDA, projects for aircraft and air traffic control regulated by the FAA, etc. The Z-axis reflects the different priorities such as time-to-market, cost reduction or legal liability. The boxes on the grid indicate the class of projects in which the size, criticality and objectives intersect. In terms of the “color” metaphor, the C6 and D6 boxes are named for Crystal Clear, although admits that it could be stretched to include the E6 box. The C20, D20 and E20 boxes are grouped under Crystal Yellow, the C40, D40 and E40 boxes are grouped under Crystal Orange and C100, D100 and E100 are grouped under Crystal Red. Crystal Magenta and Crystal Blue would encompass even larger projects. Crystal Clear Crystal Clear is for projects in the C6 to D6-category in Figure 1 but can be stretched to include projects in the E6 box. In Crystal Clear there is only one team of six people or less located in one office or adjoining offices on a non-critical project. There are four roles in a Crystal Clear project that include sponsor, senior designer-programmer, designer-programmer and user (at least part-time). The essential work products are the release sequence, schedule of user viewings and deliveries, use cases, design sketches, screen drafts, common object model, running code, migration code, test cases and a user manual. There is also a set of policy standards that includes incremental delivery every two or three months, some automated testing, direct user involvement, two user reviews per release and methodology tuning workshops. The only

 This category includes processes for developing “bug free’ code.

  1. A community, aligned in conversation  This category is aimed at the long-term target of the company. All roles in the company should participate in cross-functional teams to maximize the effects of conversations around delivering initiatives across specialty boundaries. [6]

References

  1. Cockburn, Alistair, Agile Software Development, Addison-Wesley, September 2004.
  2. Cockburn, Alistair, Crystal Clear A Human-Powered Methodology for Small Teams, Addison-Wesley, October 2004.
  3. Cockburn, Alistair, People and Methodologies in Software Development, Ph.D. thesis, University of Oslo, Norway, 2003. Retrieved from http://alistair.cockburn.us/crystal/books/pamisd/peopleandmethodologiesinsoftwaredevelopm ent.pdf
  4. Cockburn, Alistair, The Crystal Methods or How to Make a Methodology Fit, Agile Development Conference, 2002.
  5. Eberlein, Dr. Armin, Muarer, Dr. Frank, Paetsch, Frauke, Requirements Engineering and Agile Software Development, Proceedings of the Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’03), 2003.
  6. Highsmith, Jim, Agile Software Development Ecosystems, Addison-Wesley, March 2002.