Taylor

Methodology

From Taylor

This section is currently UNDER CONSTRUCTION. However, it will continue to evolve from project to project. So, it is intended to be used as a continual reference. Use the History editing tool to see what is new.


Contents

The Taylor Approach

The Taylor Approach is the recommended methodology to follow when using Taylor on your projects. The best way to describe it is to start by discussing how it relates to other approaches. Then we will cover a new concept called Paired Modeling. And finally, a skeleton project plan is provided.

Comparisons

Agile

The Taylor Approach subscribes to all the philosophies of the Agile Manifesto. Of most importance is the focus on "working software over comprehensive documentation". Thus executable software is delivered continuously with limited focus on ceremony (i.e. documentation).

Model Driven

The Taylor Approach is focused on agile, iterative modeling. The model is the primary form of documentation. With each cycle the model evolves from an initial skeleton to eventually becoming a specification of the executing software. With each cycle the model is generated into working software that is deployed and used to elicit customer feedback. A by product of the generation process is also generated documentation. This is a form of automated ceremony.


Domain Driven

The Taylor Approach is focused on the business domain of the customer. All of the Taylor models are specified at the domain level. This helps facilitate communication by using the models to define a common vocabulary for the business domain.


Feature Driven

The Taylor Approach drives projects forward by managing them based on the ordered delivery of client-valued functionality (features). Features are derived from/uncovered during the modeling process and recorded in a software project management tracking system such as Taylor Tracker. The project plan is then organized by allocating features to releases and iterations and managed by tracking progress per iteration.


Scrum

As another agile project management method Taylor leverages the Scrum concepts of a feature backlog, daily progress updates, and end of iteration retrospectives as a feedback loop for improving the process.


Test Driven

The Taylor Approach leverages boiler-plate test cases that are generated from the model. With each iteration these test cases are refined and expanded to encompass and drive the feature that is under development. Testing is also automated and continuous and includes performance testing.

Also see Taylor Results

Agile Unified Process

The Unified Process tends to get a bad rap because it is perceived to be weighed down with ceremony (i.e. documentation and red tape). Agile UP addresses this by trimming and refining UP. Both are intended to be further tailored to suit your needs. The Taylor Approach is just such a tailored process for using Taylor. The Taylor Approach uses AUP Disciplines to help frame what kinds of activities may need to be performed throughout a project and uses AUP Phases to help frame to what extend the disciplines are performed over the life of a project. The AUP concept of Development and Production releases is also followed.

Project Management


Paired Modeling

Paired Modeling is a variation on the idea of paired programming which was popularized by extreme programming. Paired programming is the concept of placing two engineers together to work on the same code. One engineer might be writing a unit test while the other engineer thinks about how to write the code to satisfy the test. The engineers may have different skill levels, but they are both engineers.

In Paired Modeling the idea is to pair an Analyst with a Designer to collaborate on a model. The Analyst and the Designer have different backgrounds, functional and technical respectively, which are leveraged to compliment each other. The pair may work on the different parts of the model together on the same workstation or they can split them up and work next to each other on separate workstations. For example the Analyst may be working on a use case while the Designer identifies the domain entities in the use case and models them with a class diagram.

A generalization of this is Paired Development. The idea is to pair together functional and technical backgrounds across all of the AUP disciplines.

In its simplest form this is just 2 people working on a small project. The functional person wears the project mgt, analysis, and testing hats, while the technical person wears the architect, designer, and developer hats. On larger projects there will be one or two Project Manger/Architect pairs and many Analyst/Designer pairs based on the number of planned features and available resources. It is also preferable to have the Analyst/Designer pair carry on as the Tester/Developer pair for a given feature. It is important to note that this is realistic because in model driven development there is much less code to write.

Axioms

  • Divide and Concur
  • Practice the 80-20 Rule
  • Keep It Simple

Other


OLD - Skeleton Project Plan

RationalUnifiedProcess.png

NOTE: In AUP the Business Modeling, Requirements, and Analysis & Design disciplines are lumped into one Modeling discipline.

Milestones

  • Each iteration (aka development release) lasts 3 weeks
  • Start an iteration at the beginning of business week and stop it at the end of a business week
  • If the iteration encompasses a holiday then it will just be a couple days shorter, so reduce scope accordingly
  • A Production Release is divided into 6 iterations: 1 inception, 2 elaboration, 2 construction, 1 transition
  • This means there will be approximately 3 production releases per year (~every 4 months)
  • All milestones are time-boxed (fixed), only scope is variable

Inception (i0)

Identify the initial scope of the project and obtain stakeholder acceptance.

  • Modeling
    • Gather information about the customer's business: vision, mission, stakeholders, org chart, job descriptions, etc
    • Hold one or more Jad/Storming sessions w\ the stakeholders
    • Create high-level overall model
    • Identify all Actors (User Roles & External Systems)
    • Create skeleton use cases and activity diagrams
    • Create skeleton domain entity class diagrams w\ associations and important fields
  • Implementation
    • Generate and build skeleton application
  • Testing
    • Execute generated unit tests
  • Deployment
    • Demo generated application daily and get feedback
  • Environment
  • Project Management
    • Derive features from use cases and compile a complete feature list
    • Categorize features (e.g. by subject, by component)
    • Identify feature complexity and priority
    • Allocate features to releases and iterations
    • Perform retrospective
  • Configuration Management
    • Version control model and source code
    • Stand up Change Control Board

Elaboration (i1-i2)

The elaboration phases is usually intended for proving the architecture. But with Taylor the architecture is sufficiently understood going into the project. So with the Taylor Approach the focus during elaboration is on the high risk features that have been allocated to the current production release.

  • Modeling
    • Add meat to use cases, classes, business processes, and page flows for allocated features
  • Implementation
    • Add meat to the generated code and test cases
  • Test
    • Add automated functional and performance test cases for allocated features and execute continuously
  • Deployment
    • Demo generated application continuously
  • Environment
    • Basic operation and maintenance
  • Project Management
    • Refine feature list
    • Monitor progress on features
    • Adjust allocation of features to releases and iterations
    • Perform retrospective
  • Configuration Management
    • Version control model and source code
    • Change Control Board activity

Construction (i3-i4)

The focus during the construction phase is on stability and delivering the remaining features.

  • Modeling
    • The model should begin to stabilize.
  • Implementation
    • More focus on fixing defects
    • Create user documentation and self training material (should be generated from the model, i.e. design-by-users guide)
  • Test
    • Tests should become more complete and robust and include negative testing.
    • Start early user acceptance testing
  • Deployment
    • Same as above
  • Environment
    • Same as above
  • Project Management
    • Same as above, plus
    • Agile is all about embracing change late in the release cycle, but this requires balancing priorities and adjusting expectations to ensure that scope is controlled
  • Configuration Management
    • Same as above

Transition (i5)

The focus during transition is on deploying the system to production.

  • Modeling
    • Minimal
  • Implementation
    • Fix defects
    • Tune user documentation and self training material
  • Test
    • Continued user acceptance testing
  • Deployment
    • Deploy to production
    • Dry runs should start at the beginning of the iteration
  • Environment
    • Configure production environment
    • This should be very similar to the QA environment
  • Project Management
    • Same as above
  • Configuration Management
    • Same as above
Personal tools