Crystal Methodology

asim741 7,483 views 24 slides Feb 14, 2016
Slide 1
Slide 1 of 24
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24

About This Presentation

This presentation focuses on all the crystal methodologies thoroughly.
Provides a perceptive outline.


Slide Content

Prepared by: Muhammad Asim PH#  +923066010010

Crystal Methodology

Crystal: Derived from gemstones Lightweight Methodologies Non-jealous

Crystal: Crystal methods are part of the crystal family developed by Alistair Cockburn in the mid-1990’s Based on o bservations of many teams that did not follow formal methodologies yet had successful projects

Crystal: Crystal methods focus on: People Interaction Community Skills Talents Communications

What is Crystal Methodology? It is a subset of agie methodology because use iteration and incremental development same as agile model

Crystal family: Crystal clear lightweight, not critical Crystal Yellow Crystal orange Crystal orange web Crystal Red Crystal Maroon Crystal Diamond Crystal Sapphire heavy, critical

Crystal clear: Lightest weight methodology Supports fixed price contracts Requires documentation Focus on people,not process or artifacts Project safety Small teams

Crystal Yellow: 7 to 20 team members Easy communication Clear owner ship of code areas Feedback Mission statement Monthly improvements

Crystal Orange: Incremental development The idea is for agile development New release after 3-4 months Each released is called “increment” Designed for medium size projects

Crystal Orange web: Used in projects that have a continually evolving code base that is being used by the public Used for category D40 projects Used in teams with 21-40 members

Crystal Orange web: Consists of a set of conventions grouped into five categories: Regular heartbeat with learning Basic process Maximum progress , minimum distractions Maximally defect free A community , aligned in conversation

Crystal Properties: Frequent delivery Reflective improvement Close or osmotic communication Personal safety Focus Easy access to expert users Automated tests ,configuration management , frequent integration

Frequent Delivery Iteration release regularly Delivery cycle shouldn’t be more than four months so problem find and fix early Customer ensure The team gets to debug their development and deployment processes

Reflective Improvement Developer dedicate time Reflection Workshop held every weak Iterations help process is working or feedback at the end of iteration

Osmotic Communication Developer team must be in same room Aids communication Information flow quickly Communication overhead reduce

Personal Safety Team members speak freely share their views without thinking about what others think about their views .

Focus Focus on a task long enough for progress Clear definition and goals of the project

Easy access to expert users Developer work with experts Improvement base on experts Communication 2 hours in one weak and reachable by phone

Automated tests ,configuration management , frequent integration Support Errors and problems Done regularly configuration management system and run automated system tests

Comparison: Crystal Crystal is much tolerant More likely to followed Crystal end-users participate in all of the incremental releases Face-to-face meetings happen in Crystal Extreme programming Xp is much disciplined Productive End user actively involved in XP informal daily stand up meetings happen in XP

Advantages: Effective team communication and this facilitates learning amongst team members from each other This methodology can be adjusted as per project type and team size Crystal Clear is an agile methodology for projects with small teams, less than about 10 people in size . It supports fixed price contracts Crystal Clear is not mutually exclusive with other methodologies

Disadvantage: The planning & development are not depended on requirements  May not work well for distributed teams . Moving from one flavor of Crystal to another in mid project doesn't work Crystal was not designed to be upward or downward compatible. varying by project size and criticality