Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Concepts
-
Часть 8
-
One of the few books to show deliverables and their standards is Developing Object-Oriented Software (OOTC 1997), which was prepared for IBM by its Object-Oriented Technology Center in the late 1990s and was then made public.
Remove the technique guides
Rather than trying to teach the techniques by providing detailed descriptions of them within the methodology document, let the methodology simply name the recommended techniques in the methodology, along with any known books and courses that teach them.
Techniques-in-use involve tacit knowledge. Let people learn from experts, using apprenticeship-based learning, or let them learn from a hands-on course in which they can practice the technique in a learning environment.
Where possible, get people up to speed on the techniques before they arrive on the project, instead of teaching the technique as part of a project methodology on project time. The techniques will then become skills owned by people, who simply do their jobs in their natural ways.
Organize the text by role
It is possible to write a low-precision but descriptive paragraph about each role, work product, and milestone, linking the descriptions with the Role-Deliverable-Milestone chart. The sample role descriptions might look something like these:
Executive Sponsor. A person who acts in the capacity to support and monitor the progress of an approved project. Responsible for scoping, prioritizing, and funding at the project level. Cross-team Lead. A person who is responsible for the progress of multiple teams, for uniting the efforts of these teams, for establishing priorities across teams, and for allocating resources (people) across teams.
Team Lead. A person who is responsible for the direction and progress of one team. Developer. A technical person who develops the software product. This may include UI, business classes, infrastructure, or data. Writer. A person who publishes technical communication about various subjects through media such as manuals, white papers, shared drives, intranet, or Internet. Rollout. One or more persons who communicate and coordinate field technicians and customer representatives and who roll out the products. External Tester. One or more persons who perform QA-related test functions outside of the development groups.
Maintainer. A person who makes necessary changes to the product after it ships.
For the work products, you need to record who writes them, who reads them, and what they contain. A fuller version would contain a sample, noting the tolerances permitted and the milestones that apply. Here are a few simple descriptions:
Overall Project Plan
Writer: Cross-team Lead.
Readers: Executive Sponsor, Team Leads, newcomers.
Contains: Across all teams, what is planned to be in the next several releases, the cross-team dependencies between their contents, the planned timing of development.
Dependency Table
Writer: Team Lead.
Readers: Team Leads, Cross-team Leads. Contains: What this team needs from every other team, and the date each item is needed. May include a fallback plan in case the item is not delivered on time.
Team Status Sheet
Writer: Team Lead.
Readers: Cross-team Lead, Developers. Contains: The current state of the team: rolled up list of things being worked on, next milestone, what is holding up progress, and stability level for each.
For the review milestones, record what is being reviewed, who is to review it, and what the outcome is. For example:
Release Proposal Review
Reviewers: Application Team Lead, Cross-team Lead, and Executive Sponsor.
Purpose: Basically a scope review. Reviewing: Use case summary, use cases, actors, external system description, development plan. Outcome: Modifications to scope, priorities, dates, possibly corrections to actor list or external systems.
Application Design Review
Reviewers: Team Lead, related Cross-team Leads, Cross-Team Mentors, Business experts. Purpose: Check quality, correctness, and conformance of the application design. Reviewing: Use cases, actors, domain class diagram, screen flows, screen designs, class tables (if any), and interaction diagrams (if any). Outcome: Factual corrections to the domain model, to the screen details. Suggestions or requirements for improved UI or application design, based on either quality or conformance considerations.
With these short paragraphs in place, the methodology can be summarized by role (as the following two examples show). The written form of the methodology, summarized by role, is a checklist for each person that can be fit onto one sheet of paper and pinned up in the person’s workspace. That sheet of paper contains no surprises (after the first reading) but serves to remind team members of what they already know.
Here is a slightly abridged example for the programmers:
Designer-Programmer
Weekly status sheet
Source code
Release notes. ..
Reads:Actor descriptions
UI style guide. ..
Application design review
Application. configuration
Declares: UI Stable
You can see that this is not a methodology used to stifle creativity. To a newcomer, it is a list outlining how he is to participate on the team. To the ongoing developer, it is a reminder.
Using the Process Miniature
Publishing a methodology does not convey the visceral understanding that forms tacit knowledge. It does not convey the life of the methodology, which resides in the many small actions that accompany teamwork. People need to see or personally enact the methodology.
My currently favorite way of conveying the methodology is through a technique I call the Process Miniature.
-
Закладки
1. Project name, job of person interviewed (the interviewee…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
Using the planning game in this way, the sponsors can properly…
While writing, reading, typing, or talking, we pick up traces…
After much coaching for six months, his programs still looked…
In arguing for the Theory Building View, the basic issue…
Agility implies maneuverability, a characteristic that is…
13. (FIRST TECHNIQUE). .. your sword now having bounced…
The third problem is absence of feedback from the downstream…
The industry is littered with projects whose sponsors did…
Crystal Clear is the most tolerant, low-ceremony small-team…
The group of 17 quickly agreed on those value choices. Developing…
The complete discussion about when and where to apply concurrent…
The chart shows the state of the user stories being worked…
Types of Methodologies Rechtin (1997) categorizes methodologies…
It follows that on the Theory Building View, for the primary…
On a new project, I would use Crystal Orange as a base…
The main question is, if you were funding this project, which…