Solutions: CHAPTER 4: AGILE DEVELOPMENT by mhf39s



4.1)   An agility principle noted in Section 4.2.1 is “Welcome changing
       requirements, even late in development”. Agile processes embrace
       change as essential to the customer's competitive advantage. Each of
       the process models presented in this chapter exhibits this principle.

4.2)   One more “agility principle” that would help a software engineering team
       become even more maneuverable would be, “A team should know
       whose skills suit a particular project, and get these people on their
       project, for software development to become more effective.” Another
       might be: ”Communication is the key, the consumer and developer
       should communicate regularly even if they are geographically

4.3)   The generic process framework can be applied to each agile process
       described in this chapter. The table should list all agile process models
       across the first row and all generic framework activities (communication,
       planning, modeling, construction, deployment) down the first column.
       Review each agile process description to select the name of the
       analogous process activity, e.g.,

       communication      XP: planning - user stories
       planning           XP: planning – commitment to a specific increment
       modeling           XP: design, spike solutions, refactoring
       Construction       XP: pair programming, unit testing
       Deployment         XP: acceptance testing, customer tests

4.4)   The software team manages change by focusing on an defined
       increment (i.e., the scope of the increment is defined) and postponing
       any changes until the next increment. All agile process models are
       iterative/incremental. For example, ASD uses an iterative process that
       incorporates adaptive cycle planning, relatively rigorous requirement
       gathering methods, and an iterative development cycle that incorporates
       customer focus groups and formal technical reviews as real-time
       feedback mechanisms. The Dynamic Systems Development Method
       (DSDM) defines three different iterative cycles—functional model
       iteration, design and build iteration, and implementation— preceded by
       two additional life cycle activities—feasibility study and business study.

4.5)   Agility can be applied to any software process. However, to accomplish
       this, it is essential that the process be designed in a way that allows the
       project team to adapt tasks and to streamline them, conduct planning in
       a way that understands the fluidity of an agile development approach,

       eliminate all but the most essential work products and keep them lean,
       and emphasize an incremental delivery strategy that gets working
       software to the customer as rapidly as feasible for the product type and
       operational environment.

4.6)   Each of the four values are commendable, but each can get a team into
       trouble. For example, people and their interactions are very important,
       but a complex project may fail because the technology brought to bear is
       insufficient (e.g., processes and tools are poor). Working software is,
       undoubtedly, the bottom line, but tell that to someone who must maintain
       an application three years after everyone on the team has moved on.
       Collaboration is commendable, but negotiation helps avoid unrealistic
       expectations and in the worst case, litigation. Responding to change is
       paramount, but a chaotic project environment (no plan) leads to failure in
       many cases.

4.7)   Requirements change so much because it is difficult to predict in
       advance which software requirements will persist and which will change.
       It is equally difficult to predict how customer priorities will change as the
       project proceeds. It is often difficult for people to verbalize their software
       needs until they see a working prototype and realize that they had
       forgotten to consider something important.

4.8)   Physical proximity is important. A question gets an immediate answer; a
       concern can be discussed without delay; negotiation occurs in
       unplanned (and therefore effective) personal communication. You can’t
       beat it! However, physical proximity is not always possible. Most agile
       process models recommend face-to-face communication. Today, this
       can be achieved with low-cost video conferencing, Web-based
       discussion groups and other electronic means. These are not as
       powerful as physical proximity but they can accomplish much the same

4.9)   Considering the seven traits noted in Section 4.2.3 the traits ordered
       from most important to least important based on one person’s perception
       might be:
       Competence. In an agile development (as well as software engineering)
       context, “competence” encompasses innate talent, specific software
       related skills, and overall knowledge of the process that the team has
       chosen to apply.
       Common focus. Although members of the agile team may perform
       different tasks and bring different skills to the project, all should be
       focused one goal.

        Collaboration. Software engineering (regardless of process) is about
        assessing, analyzing, and using information that is communicated to the
        software team;
        Mutual trust and respect. A jelled team exhibits the trust and respect
        that are necessary to make them “so strongly knit that the whole is
        greater than the sum of the parts.”
        Self-organization. The team should have control over its internal
        Decision-making ability. Any good software team (including agile teams)
        must be allowed the freedom to control its own destiny.
        Fuzzy problem-solving ability. Software managers must recognize that
        the agile team will continually have to deal with ambiguity and will
        continually be buffeted by change.
        It’s important to note that there is no “correct” answer here. Each person
        may perceive the importance of these traits differently.

4.10)   Example: Each Web site URL that I intend to revisit can be stored in a
        favorite places file. I should be able to name and group Web site URL by
        categories that I define, store a favorite place into a particular category,
        order the URLs in any way I like, and recall the favorite places file at any
        time from the browser menu. I should be able to list all favorite places as
        a categorized list in my browser window. I can select a favorite place
        using my mouse; once selected, the browser will establish a link to that
        URL and display the contents of the Web site.

4.11)   One web site to examine for AM principles might be

4.12)   XP encourages refactoring—a construction technique that is also a
        design technique. Refactoring is the process of changing a software
        system in such a way that it does not alter the external behavior of the
        code yet improves the internal structure. A central notion in XP is that
        design occurs both before and after coding commences. Refactoring
        means that design occurs continuously as the system is constructed a
        key concept during the coding activity is pair programming. XP
        recommends that two people work together at one computer workstation
        to create code for a story. This provides a mechanism for real-time
        problem solving (two heads are often better than one) and real-time
        quality assurance.

4.13)   Like other agile methods, the Crystal approach emphasizes collaboration
        and communication among people who have varying interest in the
        software project. The method is also tolerant of varying team cultures
        and can accommodate both informal and relatively formal software

        engineering approaches hence it is called” the family of agile methods”.
        Crystal family is actually a set of example agile processes that have
        been proven effective for different types of projects. The intent is to allow
        agile teams to select the member of the crystal family that is most
        appropriate for their project and environment.

4.14)   Example Scrum Pattern

        Pattern:           Scrum meeting
        Intent:            To answer three key questions using an abbreviated
                           meeting format that is conducted daily
        Type:              Task pattern
        Initial context:   (1) the project should have been initiated and a backlog
                           developed; (2) sprints should be underway; (3) All
                           members of the Scrum team should agree to meet in a
                           prespecified location each day for the scrum meeting; (4) a
                           team leader should be defined
        Problem:           It is often difficult for members of the team to
                           understand the status of the project and the status of
                           work being conducted by each members of the team.
                           When meeting are conducted they are often too time-
                           consuming and ineffective
        Solution:        See description of the Scrum meeting in Section
        Resulting Context:      At the conclusion of the meeting each person
                         has answered the questions noted in the Solution.
        Related Patterns: backlog preparation, conducting a sprint
        Known Uses/Examples: Scrum meetings are conducted throughout
                         every Scrum project and are an important element of

4.15)   The FDD feature template takes the form:
            <action> the <result> <by | for | of | to> a(n) <object>
                  specify a URL for a Web site
                  display the content of a Web site
                  fill-in the content of a Web form
                  show all URLs for favorite places

4.16)   If a difficult design problem is encountered as part of the design of a
        story, XP recommends the immediate creation of a operational prototype

of that portion of the design, called a spike solution, the design prototype
is implemented and evaluated. The intent is to lower risk when true
implementation starts and to validate the original estimates for the story
containing the design problem.


To top