Agile-пасьянс
Материал из AgileWiki
Содержание |
Cockburn-Boehm Levels of Developer's Competencey
While this measurement index is incomplete, it is a good starting point for creating a way to measure the competency of the developers not in terms of a set of generic skills, but in terms of their understanding of how to approach object oriented porgramming. Bellow you can see the characteristics expected from developers at each of the Cockburn-Boehm Levels.
Level 3: Able to revise a method (break it's rules) to fit an unprecedented new situation
Level 2: Able to tailor a method to fit a precedented new situation
Level 1A: With training, able to perform discretionary method steps (e.g., sizing stories to fit increments, composing, patterns, compound refactoring, complex COTS integration). With experience can become Level 2.
Level 1B: With training, able to perform procedural method steps (e.g. coding a simple method, simple efactoring, following coding standards and CM procedures, running tests). With experience can master some Level 1A skills.
Level -1: May have technical skills, but unable or unwilling to collaborate or follow shared methods.
Cards
Red
Test Driven Development (TDD)
Involves repeatedly writing a test case first, and then implementing only the code necessary to pass the test. The developer creates one test to define some small aspect of the problem at hand. Then s/he creates the simplest code that will make that test pass. Then s/he creates a second test. Now the programmer adds to the code they just created to make this new test pass, but no more! Not until they have yet a third test. S/he continues until there is nothing left to test.
Lower process ceremony
Process ceremony is the level of paperwork involved with a process. For example, an organization with high process ceremony would require that change requests be signed by at least three levels of management.
Ideal physical setup for Agile
Many different physical setups are suitable for agile development. The key to most of these physical setups is to have the whole team together in one room with no cubicles or dividers. This helps establish the right environment for the agile software development to thrive in.
Paired programming
Paired programming is an agile practice that requires two software engineers to participate in a combined development effort at one workstation. Each member performs the action the other is not currently doing; for example, while one types in unit-tests the other thinks about the class that will satisfy the test.
Development team has a minimum number of Cockburn-Boehm level-1 or 1B people
Cockburn's people levels are directly related to the amount of experience the developer has. Alistair Cockburn has identified three levels of understanding people have when they approach new material. Barry Boehm adapted the Cockburn levels to be reflective of people's competence levels within the software domain.
Refer to the Cockburn-Boehm reference card for more information about the characteristics expected from developers at Level -1 and 1B
Frequent face-to-face iteration between developers and customers
In addition to having the developers co-located, this practice encourages to have the customer(s) or users with the development team in the same room. The ideal situation is to have as many stakeholders co-located as possible.
Agile project estimation
Project estimates are done using techniques that are flexible and do not jeopardize accuracy. Agile Project estimation can be done in various ways; two of the most popular are story points and ideal days.
Purple
Smaller and more frequent releases (4-8 weeks)
This practice encourages organizations to keep the timeframe for the releases small and limit them to 8 weeks. This practice focuses on the timeframe for each release, not each iteration. Usually building a release will include multiple iterations.
Agile documentation
This practice does not encourage total elimination of documentation, but warns from writing unnecessary requirements, design or management documents.
Daily progress tracking meetings
The team has a means by which they can stay informed, on a daily basis, about the status of the iteration. During these meetings,. team members discuss what they did the day before, what they will do today and discuss any factors that might affect their progress.
Continuous customer satisfaction feedback
Any mechanism to elicit continuous customer satisfaction feedback about the product. This is important to ensure that the customer is satisfied with what is being developed, and that it meets their business needs and expectations. This is contrary to the practice of gathering feedback after the product is completely developed.
"Crack" customer immediately accessible
A "CRACK" customer refers to a customer who is collaborative, representative, authorized, committed and knowledgeable. The concern is not where this customer is located, but how responsive they are. The team must have quick and easy access to a CRACK customer to address all their questions and concerns as they arise.
Client-driven iterations
The client determines the choice of features for the next iteration. This makes the client in control and able to change the system based on whatever they perceive as the highest business value to them.
Adaptive Planning
Adaptive planning delays developing iteration details until immediately before the following iteration, and therefore incorporates all the feedback obtained including what is learned from the previous iteration. Adaptive planning helps organizations embrace change because the focus shifts from adapting to a plan (which makes people less embracing of change) to continuously planning based on the latest feedback obtained (which inherently promotes the culture of welcoming change).
Contact revolves around collaboration and commitment not requirements
Usually the customer contract contains a list of features or requirements that one must deliver or risk non-payment and/or legal issues. This causes organizations to "not welcome change" and just deliver what is in the contract. With this agile practice, the customer agrees to contract the degree and amount of collaboration, not the list of requirements or features.
Yellow
Reflect and tune process (Retrospectives)
Holding retrospectives at regular intervals within the development process to reflect and tune the process.
Task volunteering
Once the list of tasks have been generated, the project manager encourages people to volunteer and commit to tasks that they choose based on their preference rather than have the manager assign the tasks to them.
Knowledge sharing tools
Knowledge sharing tools could be wikis, blogs or they could be simple whiteboards or walls. The objective is to have some media for knowledge to be shared among stakeholders
Empowered and motivated teams
Supervisors empower and equip their teams with the authority to make decisions on their own. This authority helps motivate the team members, who believe that they can solve any problem the team faces.
Customer commitment to collaborate with developing team
Customer makes a commitment at this level to work with the development team. Some customers are reluctant to exert additional effort and expect the contractor to provide the majority of the project's effort without any collaboration efforts.
Collaborative teams
Team members cooperate with each other and with other teams. Collaboration is always encouraged.
Collaborative planning
All stakeholders (customers, developers and management ...etc) in the project come together during the planning activities of the project
Coding standards
A "common language" relative to the code syntax between all the developers. These coding standards include naming conventions, formatting issues, and other best practices.
Green
Tracking iteration progress
The team has a means by which they can measure the progress of the development effort within each iteration. No particular is method for tracking is emphasized.
Software configuration management (SCM)
Software configuration tools help control and manage the different versions and iterations of the software being developed.
Planning at different levels
The project teams maintain a plan for both the overall product development lifecycle and the individual iterations. Usually two levels of planning occur in agile projects: Release planning (dealing with the overall product) and iteration planning (dealing with current iteration).
No Big Design Up Front (No BDUF)
No "big" design is created before coding and testing takes place, as in a typical waterfall development process. The product's design was developed using an evolutionary approach.
Evolutionary requirements
Not all requirements are gathered at the beginning of the project; they evolve and change over the life cycle of the product. Requirements iteratively evolve instead of being fully developed in one major specification effort at the beginning of the project.
Continuous delivery
This practice goes against the "Big Bang" development theory by dividing the development effort into releases and each release into iterations. Continuous delivery promotes delivering the product in small iterations at regular intervals.
Customer contract reflective of evolutionary development
The customer understands the evolutionary nature of the development process and does not constrain the contract by milestones related to the different phases such as (Milestone 1 is reached when the requirements are gathered and Milestone 2 is reached when the design documents are completed)
Blue
Unit tests
Unit tests are code procedures used to validate that individual units of source code are working properly. A unit of source code is the smallest testable part of an application. For example, in procedural programming a unit may be a function or procedure, while in object-oriented programming, the smallest unit is usually a class.
Self-organized teams
Self-organizing teams are empowered by management to make decisions on their own without waiting for management's approval. When the team is given a task, it becomes the responsibility of the whole team, collectively, to finish it, not a specific person, or a specific role on the team. Management treats self-organizing teams as one entity without distinguishing between the individuals of the team.
Risk-driven iterations
The development team tackles the riskiest elements in the earliest iterations possible. Mitigating those risks early ensures that the project team does not spend a considerable amount of time building a system that they cannot complete.
Continuous improvement (Refactoring)
Refactoring involves rewriting the code to improve its structure, while explicitly preserving its behavior, and is sometimes informally referred to as "cleaning up the code".
30% of the development team should be Cockburn-Boehm Level 2 or Level 3
Cockburn's people levels are directly related to the amount of experience the developer has. Alistair Cockburn has identified three levels of understanding people have when they approach new material. Barry Boehm adapted the Cockburn levels to be reflective of people's competence levels within the software domain.
Refer to the Cockburn-Boehm reference card for more information about the characteristics expected from developers at Level 2 and Level 3
Planning features not tasks
The customer usually expresses their needs as features in terms of the customer's domain vocabulary (e.g. an electronic shopping cart). Tasks, on the other hand, are usually expressed in the developer's terms and are not understandable to the customer (e.g. build an interface).
Frequent face-to-face communication
This practice emphasizes that the development team have frequent face-to-face communication with each other.
Continuous integration
The practice encourages members of the development team to integrate their work frequently. It is preferred that each integration is verified by an automated build tool in order to detect any integration errors as quickly as possible.
Maintaining a list of all features and their status (Backlog)
A product backlog is a list of the business and technical requirements for the system being built or enhanced based on the current knowledge of the system. This practice includes the tasks for creating the backlog, and controlling it consistently during the process by adding, removing, specifying, updating, and prioritizing the backlog items.
Activity Catalog
Welcome to Industrial Logic's Activity Catalog, a resource of technical and non-technical activities for programmers, testers, customers and managers. This catalog allows us to collaborate with you to discover which of our services best matches your varying needs.
Activities in the catalog come in various flavors, which are assembled to define a variety of workshops and experiences. We hope you find this catalog useful and welcome your questions or feedback.
Testing
Test-Driven Development
Test-Driven Development (TDD) is a practice for efficiently evolving useful code. While its name implies that it's mostly about testing, test-driven development is primarily about design: it keeps programmers focused on exactly what they need to build and helps them avoid over-engineering. Using this technique, programmers write a failing test, write code to pass the test, refactor the code and repeat. TDD offers a rhythm of development that simplifies how programmers evolve lean, useful, fully tested software.
Storytest-Driven Development
Storytest-Driven Development involves determining if features of a system work according to a customer's expectations. There are many ways to implement Storytest-Driven Development, including using XML, Excel or simple languages. A typical challenge is to empower customers with tools that let them define Storytests (a.k.a. Acceptance Tests) without working with programmers. Another challenge is to practice Storytest-Driven Development, in which Storytests are specified before code is written.
Unit Testing Legacy Code
To refactor legacy code, you need good unit tests. To write good unit tests, you need to refactor your legacy code. How do you get out of such a mess? First, you isolate what it is you would like to unit test and refactor. Next, you use whatever language is simplest to produce coarse-grained tests for that area of code. Once you've written enough of the coarse-grained tests, you'll be able to implement coarse-grained refactorings, without fear of breaking your code.
Mock Objects
When writing test and production code, it's useful to know when to introduce Mock Objects. This activity will help you understand what Mock Objects are, how they function at runtime, common implementation variations and usage patterns.
Unit Testing Tool
Learn the basics of a unit testing tool, including how to write and organize tests, which assert methods may be called, exception handling within tests, test naming conventions and ways to use the unit testing tool in an integrated development environment (IDE).
Test-Driven HTML
Test-Driven Development (TDD) is extremely useful in designing Web-based systems that use HTML for their interface. Unit-testing tools and strategies are available for HTML, XML, XSL, JavaScript or JScript, JSPs or ASPs and so forth. Using an effective unit-testing strategy with your Web-based technologies will help you efficiently produce dependable systems.
Test-Driven Management
Senior managers frequently fail to communicate their organizational intentions and business objectives to XP teams. This means that while Release Planning helps elucidate what features are needed for a given project, it falls short when it comes to explaining why. As a result, an XP team can create finely crafted, fully tested software that fails to meet unspoken organizational or financial objectives. Test-driven management addresses this problem by means of Management Tests. Managers on XP projects use test-driven management to clearly articulate and assess organizational intentions and business objectives for their projects and teams. (see Joshua Kerievsky's SD Magazine cover story, Right Game, Wrong Team, http://www.sdmagazine.com/documents/s=7839/sdm0303a/sdm0303a.htm)
Testing & Refactoring Adoption
The workshop coaches engage participants in a dialogue on adopting Testing & Refactoring in their workplace, including the following questions: What technical practices will be most difficult to accomplish at our company? How will we test or refactor specific code? Should we test or refactor our legacy code? What is the best way to transition to these new practices? How will our new practices integrate with other teams? What role will documentation or testing folks play?
Refactoring
The Refactoring Challenge
The best way to improve your refactoring skills is to practice cleaning up poorly designed code. And we've got just the thing: code we custom-designed to reek of over 90% of the code smells identified in the refactoring literature. This poorly designed code functions correctly, which you can verify by running a full suite of tests against it. Your challenge is to identify the smells in this code, determining which refactoring(s) can help you clean up the smells and implement the refactorings to arrive at a new, well-designed version of the code that continues to pass its unit tests. This exercise takes place using our popular class fishbowl. There is a lot to learn from this challenge, so we recommend that you spend as much time on it as possible.
Code Smells
Code smells identify common design problems in object-oriented code. This interactive lecture provides a good overview of code smells defined by Martin Fowler & Kent Beck in their book "Refactoring: Improving the Design of Existing Code." In addition, you'll learn about some new smells that have been categorized by Joshua Kerievsky and his colleagues.
Refactoring to Patterns
Patterns are undeniably useful design aids and a cornerstone of object-oriented programming. Yet with the emergence of agile methodologies like Extreme Programming, our motivation for using patterns has changed. Today, we use patterns when they can help us reduce or remove duplication, simplify the complex, or make our code better at communicating its intent. In other words, we refactor to patterns for the same reason we refactor in general: to improve the design of our code. But since the motivation for using a pattern, according to the published literature, rarely resembles the motivation to refactor, it is easy to misapply patterns or over-engineer solutions using patterns. In this activity, we will study numerous real-world refactorings to patterns and examine the refactoring roots of patterns, the role of patterns in evolutionary design and common motivations for refactoring to patterns.
Refactoring War
What's the fastest way to learn Martin Fowler's classic catalog of 74 foundational refactorings? It's called "Refactoring War," an educational game we invented to help groups rapidly learn a large number of refactorings. The game is played in teams and involves viewing refactoring cards, comparing the usefulness of the cards and deciding on which card is most useful. The team with the most refactorings at the end of the game wins.
Testing & Refactoring Adoption
The workshop coaches engage participants in a dialogue on adopting Testing & Refactoring in their workplace, including the following questions: What technical practices will be most difficult to accomplish at our company? How will we test or refactor specific code? Should we test or refactor our legacy code? What is the best way to transition to these new practices? How will our new practices integrate with other teams? What role will documentation or testing folks play?
Ваши предложения
Responsibility-Driven Design
Responsibility-Driven Design offers techniques that fit with and complement agile practices. Our emphasis is on software responsibilities. Following this approach, you start with rough ideas and refine them. You add as much precision as you need in your design work. Initially, you identify candidate objects, characterize them, assign them responsibilities, and develop an understanding of your application's control style.
Burndown Diagram
Agile sandbox
Agile архитектура на салфетках (MindMap)
