Welcome to TiddlyWiki created by Jeremy Ruston, Copyright © 2007 UnaMesa Association
There are a number of Agile development practices, for example XP, DSDM, Crystal, Scrum and others. They all share the same underlying principles expressed in the AgileManifesto, which emphasises working software, people, collaboration and responding to change.
Agile practices have been proved over the last five years in organisations to have considerable benefit in delivery. However there are still some AgileMyths which are aimed to be countered by the [[AgileCookbook]].
!Major benefits:
* business and customers have control over priorities
* faster delivery of business benefits
* reduce risk through more frequent delivery
* higher quality of deliverable through continuous testing
* greater visibility and more accurate reporting
!Fundamental Principles
* LoweringTheCostOfChange during the delivery life cycle in order to unlock greater value.
* Focusing on delivering WorkingSoftware delivered incrementally in every DevelopmentIteration
* Expressing requirements in UserStories each of which are tied to AcceptanceCriteria
* Promoting CollectiveOwnership and CommonVision within the entire project team throughout all the AgileRoles
!Key Messages
* Change will always happen as you cannot predict the future. Clairvoyant Engineering does not apply so work to minimise the cost of the change instead of enforcing a change control system that is designed to stop or resist changes.
* When changes come, do the analysis and identify trade-offs to meet the revised scope in the current dates. Identify what can be dropped from the scope.
* Requirements must be related to "User Stories". A UserStory is written from the viewpoint of a user of the system and shows what they need to do their job. You must also add the business priority for each user story either in monetary terms or MOSCOW priorities. This priority is used to manage scope and change.
* Do not try to predict all the problems. Do enough to deliver the user story. This will reduce the work done on the projects and will reduce costs. Often too many extras are added "in case" and turn out to be wasted.
* Focus on the highest value for the next iteration to feed the ROI. When completed, show it to the business user. Expect that there will be changes in scope as a result.
* This is not "anti-planning" as you need to ensure that the team are working on things that can be measured:
** What is delivered (working tested user stories)
** How much did it cost to get here = predictions for future iterations. So use this to improve your estimations
** Collect the statistics on what was done / tested to confirm status.
* Leads to a high degree of automated testing (metrics)
* This is a collaborative activity with Design+Analysis+Development+Test all together
* ContinuousIntegration (at least daily) within the system
Requirements in an Agile project are expressed as UserStories. Each UserStory is a small, atomic statement of requirements which has an associated BusinessValue and is also capable of being verified using AutomatedAcceptanceTests.
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/rollingplan.jpeg]]
A [[Showcase]] happens at the end of each DevelopmentIteration. It is the demonstration to the [[Customer]] of WorkingSoftware for sign-off.
Indication of the status of the project.
TODO
Hothousing is an "agile" development technique. It forms part of the overall [[TimeboxedDeliveryCycle]]. As part of that process the expectation is that each programme should hold a HotHouse event at the beginning of the cycle. That is not to say that the hothousing technique could not be used effectively at other times, but the general principle is that the cycle is "kick-started" by a hothouse.
The HotHouse is where development work to be produced over the next 90 days is prototyped and agreed, and following which targets and measures can be set.
Having defined the programme's initial 90-day objectives in the business case, programme directors and members of their team attend a hothouse along with their business partners.
The hothouse brings together all the key stakeholders to engage, build and refine prototypes and use these to agree on the next 90-day delivery so it's critical that it's given every chance of success. This means that all necessary participants attend from business partners and One IT delivery teams, to people from Operational Integrity and the PIR (post-implementation review) team.
Essential to every hothouse is the need to ensure that everyone who attends actively participates in the outcome of the session, and isn't just an observer or adviser. This is especially relevant to business partners, but it's also essential that we get the most out of the opportunity to maximise our own performance to benefit the business, too.
Depending on the type and size of the programme, and its objectives, some programmes may hold more than one hothouse for a 90-day cycle.
Once the hothouse has been completed, the programme then defines and agrees its PIR targets and measures for the 90-day cycle. These are captured in a "90-day targets document" within 10 days of the end of a hothouse, and agreed in a "handshake" session with the PIR team.
The purpose of the DailyStandUp is to bring the whole team together for a short period of time every day, to provide a forum for issues to be raised and for the team as a whole to be made aware of what each team member is working on. The reason it's called a ''stand-up'' is that typically it is conducted with everyone standing - thus helping to ensure that the meeting stays focused and brief.
!Who should be involved?
It's important that the whole team participate - and for that reason it is not the appropriate forum for lengthy discussions on specific issues. It's important that it's not used as a reporting tool for management. Open, honest communication should be encouraged as it is for the benefit of the developers to share information and progress.
!When should it be done?
As the name suggests - the DailyStandUp should be done every day. Generally it's better to hold the DailyStandUp in the morning, after leaving some time for people to check their email and get settled.
!What are the benefits?
Enhanced communication and a great way of quickly updating everyone on progress, plans and problems. By focusing the DailyStandUp on 48 hours work (what happened yesterday, what you plan to do today) it's a very quick way of aligning team effort. Team members can also quickly ask for and offer help on any issues being faced by the team. Be intrigued by anybody who is very quiet or vague as there may be underlying reasons for this.
!Are there any prerequisites?
Some way of bringing the entire team together for 15 minutes.
Where you have a DistributedTeam, the DailyStandUp may be conducted via phone or video conference.
!How has this been done elsewhere?
Many ThoughtWorks projects insist on a DailyStandUp as the first task of the day. This gives team members the opportunity to catch up on progress made by others in the team, and to raise any issues they might have. Often, a "speaking token" is passed around the team, ensuring that every team member has an opportunity to speak uninterrupted.
!Common pitfalls
Some team members use this time to enter into detailed discussions of specific problems. This tendency should be identified as early as possible, and those involved should continue their discussion elsewhere, after the meeting.
Facilitated by the ProjectManager, the IterationRetrospective is an opportunity for the team to reflect on what has been achieved.
The following activities should be included in an IterationRetrospective
* Present the results of the DevelopmentIteration to the whole team and any other stakeholders
* [[Showcase]] the work completed in the iteration
* Solicit feedback from the whole team regarding possible process improvements
* Report on process improvements implemented since the last IterationRetrospective
* Report on new, resolved and outstanding issues and risks
* Present the updated ProjectTracking report - showing progress to date and projected completion
They are the success criteria for the delivery of a [[UserStory]]. Ideally they should be expressed in a way that allows them to be made into [[AutomatedAcceptanceTests]].
The AcceptanceCriteria are a written description of the way in which a UserStory functionality can be tested. They should include the normal usage scenario, and any significant alternative scenarios.
!Who should be involved?
Generally these criteria are specified by the [[Customer]] or the CustomerProxy, the BusinessAnalyst, with some assistance from the [[Tester]].
!When should it be done?
AcceptanceCriteria should be specified for each UserStory prior to the DevelopmentIteration in which that UserStory is delivered.
!What are the benefits?
AcceptanceCriteria form a definitive measure of completion in a binary fashion. AcceptanceCriteria either pass or fail, thus providing a clear measure of progress.
AcceptanceCriteria form a contract between the [[Customer]] and the [[Developer]]. The [[Customer]] agrees that once the application satisfies the AcceptanceCriteria, the [[Developer]] has successfully delivered the [[UserStory]].
Generally, the [[Developer]] automates the AcceptanceCriteria into AutomatedAcceptanceTests prior to commencing work on the UserStory functionality, allowing the [[Developer]] to work in a TestDrivenDevelopment fashion. Automation saves the [[Developer]] time as they no longer have to manually check the [[AcceptanceCriteria]]. It also allows for better CollectiveOwnership, since if the work has to be handed over to another [[Developer]] they can simply run the AutomatedAcceptanceTests in order to see what remains to be done.
!Are there any prerequisites?
Requirements broken down into [[UserStories]].
Access to a [[Customer]] or CustomerProxy who can define the AcceptanceCriteria for each [[UserStory]].
!Common pitfalls
* Don't overcomplicate the [[AcceptanceCriteria]], they are not supposed to take the place of Sytem testing, but are intended to guide the [[Developer]].
The [[Designer]] is responsible for ensuring a coherent technical design with appropriate levels of quality, performance etc which satisfies the [[Customer]]'s requirements.
From the [[Designer]] point of view, the most significant difference between traditional and agile methodologies centres on the shift from providing detailed design documents towards providing ongoing expert guidance to the [[Developer]] team throughout the project. Traditional methodologies tend to be document centric, having a detailed, prescriptive design documents constructed in advance. Agile projects also engage in design, however these designs are adaptive rather than prescriptive, and benefit from continuous feedback from implementation being incorporated into future design effort. This difference can be summed up by saying that Agile methodologies favour the early delivery of WorkingSoftware, whereas traditional methodologies focus on the delivery of comprehensive documentation.
You may feel that less detailed upfront design leaves you with less control over the project (see AgileMyths), however experience shows that Agile methods give you finer grained control over the eventual implementation due to the increased levels of collaboration and feedback that they encourage. Probably the single most valuable benefit that the [[Designer]] derives from the Agile practices is the opportunity to improve their design and discover new designs throughout the course of the project, this is often referred to as [[EmergentDesign]].
The [[Designer]] may be considered to take the role of [[Customer]] in respect of the non-functional requirements of the system. These non-functional requirements may also be expressed as UserStories, and prioritised alongside the UserStories provided by the business [[Customer]]. This is achieved by the practice of TestDrivenDesign where the tests are focused on specifying non-functional requirements or the interfaces between systems, rather than on end user functionality.
In order to allow design improvement to continue throughout development, it is vital that the [[Designer]] assist the [[Developer]] team in LoweringTheCostOfChange by guiding them toward a [[SimpleDesign]]. The focus on delivery of WorkingSoftware from the first DevelopmentIteration also means that the [[Designer]] must prioritise design effort around the specific UserStories that are to be implemented in the coming [[DevelopmentIteration]].
There is a perspective shift for the [[Designer]] in an agile approach:
* supporting delivery of WorkingSoftware at the end of each DevelopmentIteration
* working collaboratively with the [[Developer]] team throughout the project
* from predictive upfront design to RespondingToChange by progressive elaboration of the system
* focusing on IndividualsAndInteractions over the production of detailed specifications
Things that are likely to be different:
* Iteratively evolving an EmergentDesign
* Focusing on SimpleDesign to enable LoweringTheCostOfChange
* Do the simplest thing that could possibly work to support the UserStories for the coming DevelopmentIteration
* Specifying design goals as tests - TestDrivenDesign
* Focus on the early delivery of WorkingSoftware over documentation
* Day to day interaction with [[Developer]] team
* Ability to steer development to achieve design goals
* Improved feedback through ongoing collaboration with the [[Developer]] team
Things that are likely to stay the same:
* The end goal that the [[Designer]] is working towards remains the same, even thought he means of achieving it is somewhat different.
* The responsibility and accountability of the [[Designer]] remain the same.
The DesignerWalkthrough provides more detail on activities of a [[Designer]] within an Agile team during the [[TimeboxedDeliveryCycle]].
PairProgramming is the result of taking the normal practice of [[Developer]] collaboration and discussion, and attempting to make that process as reliable and pervasive as possible.
The concept that "two pairs of eyes are better than one" is well accepted, and PairProgramming uses that principle to great effect.
!Who should be involved?
This is not a [[Developer]] only practice. Developers, Testers and BusinessAnalysts will likely find appropriate times to work together.
!When should it be done?
The only time that PairProgramming should not be done is when there is no added value having a second pair of eyes, and a second mind, working on the problem. The apparent 'wasted time' of having only one [[Developer]] typing at any given time is more than offset by the reduction in defects, improvement in CollectiveOwnership and knowledge of the code, and the lowering of the teams Bus Factor.
!What are the benefits?
Some development teams practice regular CodeReview. PairProgramming delivers the benefits of CodeReview on a constant basis.
Knowledge Transfer - avoid situations where individuals hold a monopoly on knowledge of the technical or business details on your project. This is an important part of CollectiveOwnership.
PairProgramming, particularly when there is a reasonable degree of movement between pairs, is an excellent way to achieve a CommonVision between the [[Developer]] team regarding the overall system design.
!Are there any prerequisites?
Some teams need to be encouraged to adopt PairProgramming, and it can take some time to become accustomed to the practice.
!How has this been done elsewhere?
Most Agile projects adopt PairProgramming to some extent. The degree of PairProgramming may vary from collaboration on UserStories that are considered to be challenging or risky, through to mandating that 'no production code will be written outside of a pair'.
A ThoughtWorks client recently introduced the AgilePractice of PairProgramming by encouraging the development team to pair for one hour a day. As the developers became accustomed to this, they increased the amount of time pairing, increasing the benefits.
!Common pitfalls
Some developers simply watch other developers working. This is not pairing. There needs to be constant interaction in order to experience the benefits of this AgilePractice.
LoweringTheCostOfChange is an underlying goal of many AgilePractices. Agile methodologies generally accept that change will happen, and instead of attempting to prevent it - they instead focus on allowing change to be accommodated with the lowest possible cost.
Specific practices that greatly assist with LoweringTheCostOfChange include:
* ContinuousIntegration - to ensure that any defects introduced as a result of changed requirements are detected early.
* AutomatedFunctionalTests - to detect unintended changes in delivered functionality.
* ElaboratingRequirements as late as possible - to avoid costly reworking of requirements documents.
* SimpleDesign - simpler designs are easier to understand and change, and avoiding speculatively implementing features in advance means that there is less to change.
* Iterative Development - Short [[DevelopmentIteration]]s allow for changes in priority to be accepted regularly, while still allowing a period of stability to permit the [[Developer]] team to work efficiently.
* ExternaliseDependencies using ServiceInterface and ServiceStub to allow early testing and to minimise the impact of delays in provision of external systems. This can apply just as well to systems under development so long as a testable InterfaceContract is available.
Traditional approach to the cost of change is that it increases throughout the software development lifecycle. This is often held to be a 'law of software development'.
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/costofChange1.jpeg]]
The Agile approach aims to break this law and lower the cost of change.
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/costofChange2.jpeg]]
A lower cost of change enables teams to:
* build only what is needed right now
* deliver scope / value incrementally
* commit capital incrementally
* accept change at any point
This results in an approach which releases valuable scope early at minimum possible cost. It also places active control back in the hands of the [[Customer]].
The entire team should meet periodically to review recent activity. Discussion is usually directed by asking four simple questions. What did we do well? What lessons have we learned? What should we do differently next time? What still puzzles us?
!Who should be involved?
All team members including the Customer or CustomerProxy. Many people find giving feedback to an independent facilitator easier than to the IterationManager or ProjectManager, so this is encouraged.
!When should it be done?
These should be conducted on a regular basis. An IterationRetrospective should be held at the end of each DevelopmentIteration, and another [[Retrospective]] at the completion of the project.
!What are the benefits?
Regularly considering the successes and failures of a team allows the team to learn, and implement a course of change.
!Are there any prerequisites?
A mechanism for bringing the team together must be available, in the case of a DistributedTeam - this might be tele or phone conferencing.
!How has this been done elsewhere?
The image below is an example of an artefact used to capture process improvement input during an IterationRetrospective. It was included in Powerpoint presentation which was posted to a ProjectWiki after the IterationRetrospective.
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/retrospective.jpeg]]
!Common pitfalls
Some people will see the [[Retrospective]] as an opportunity to claim credit for the successes and blame others for the failures of the project. A [[Retrospective]] is not a forum to assign blame to members of the team.
When retrospectives are held frequently, you will need to avoid allowing them to become long and pointless discussions. You will need to exercise discipline to keep them short and focused.
During the course of a DevelopmentIteration, it can be useful to track progress. Particularly where the team is new to Agile, keeping an eye on progress on a daily basis can help to avoid last minute surprises. However the tracking is done, it's important that it be focused on resolving issues and ensuring success - not on micromanagement of individuals.
One way of recording and communicating progress within a DevelopmentIteration is with a 'story wall' like the one shown below. As each UserStory progresses from analysis, through development to test and signoff, the numbered post-it is moved on the wall. For each team member, the post-its are arranged in priority order. In this case, the yellow post-its represent UserStories, while the pink represent defects being fixed.
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/storywall.jpeg]]
This simple device makes it easy to show the team and interested stakeholders how the DevelopmentIteration is going. Because of its simplicity, copies can even be maintained in several locations if the team is distributed.
The outcome of each DevelopmentIteration is used in ProjectTracking.
IterationPlanning is similar to ReleasePlanning except that instead of planning for the entire [[TimeboxedDeliveryCycle]], it focuses on the coming DevelopmentIteration. See IterationPlanningMeeting.
Changing the design of a piece of code in small steps, without changing its functionality, ensuring that the code continues to work after each step. A set of commonly applied transformations have been identified and developed into recognised [[Refactoring]] strategies (e.g. extract method) that can be used together to dramatically alter the design of code without compromising its integrity. Many Integrated Development Environments provide support for popular Refactorings.
!Who should be involved?
Each Developer pair should be familiar enough with the principles of Refactoring, to make small changes to any part of the system. If there is a larger series of Refactorings to undertake, one of the Developers might pair with a TechnicalLead for more guidance on architectural considerations.
!When should it be done?
AllTheTime. The principles of SimpleDesign should keep your system as simple as it can be at any one time, while providing all functionality required at that point. When a new requirement demands a more complex design, the original design must be modified to a point where it will support the new feature, while still supporting all previous features.
!What are the benefits?
The design of the code base will emerge as the necessary features are developed. This ensures that the design is only as complex as it needs to be, which makes it easier to maintain.
!Are there any prerequisites?
As the focus is on allowing change without forfeiting functionality, a suite of UnitTests is invaluable in this process. If I can determine in just a few seconds whether my code still does what it is intended to do, I will have greater confidence to make the changes my code needs, running all my tests after each small Refactoring. If verifying continued functionality takes several hours of manual testing, I am likely to leave the code as it is, even though it should be Refactored.
!How has this been done elsewhere?
[[Refactoring]] is widely practised, and many good books and articles are available on the subject:
* [[The Refactoring website|http://www.refactoring.com]]
* [[extremeprogramming.org|http://www.extremeprogramming.org/rules/refactor.html]]
*[[Refactoring to Patterns|http://www.industriallogic.com/xp/refactoring/]]
!Common pitfalls
Many teams do not consider [[Refactoring]] as part of the development process. They schedule [[Refactoring]] efforts as a separate task. This means that the design of the application degrades between [[Refactoring]] efforts, incurring "Technical Debt". Often, as projects progress, [[Refactoring]] is neglected until this "Technical Debt" begins to impact development. [[Refactoring]] as a normal part of the development process ensures that the design of the application is improved constantly.
/***
|''Name''|TiddlyWebAdaptor|
|''Description''|adaptor for interacting with TiddlyWeb|
|''Author:''|FND|
|''Contributors''|Chris Dent, Martin Budden|
|''Version''|0.10.5|
|''Status''|stable|
|''Source''|http://svn.tiddlywiki.org/Trunk/association/adaptors/TiddlyWebAdaptor.js|
|''CodeRepository''|http://svn.tiddlywiki.org/Trunk/association/|
|''License''|[[BSD|http://www.opensource.org/licenses/bsd-license.php]]|
|''CoreVersion''|2.5|
|''Keywords''|serverSide TiddlyWeb|
!Notes
This plugin includes [[jQuery JSON|http://code.google.com/p/jquery-json/]].
!Revision History
!!v0.1 (2008-11-10)
* refactoring of previous experimental efforts
!!v0.2 (2008-12-08)
* encapsulation of bag/recipe distinction
!!v0.3 (2009-01-23)
* implemented renaming via tiddler chronicles
!!v0.4 (2009-02-03)
* added support for importing TiddlyWiki documents
!!v0.5 (2009-02-06)
* keeping track of previous location when renaming/moving tiddlers
!!v0.6 (2009-03-15)
* refactored to take advantage of jQuery
* replaced JSON serialization with jQuery JSON plugin
!!v0.7 (2009-05-08)
* added support for TiddlyWeb differ plugin
!!v0.8 (2009-05-23)
* fixed ETag format
!!v0.9 (2009-08-17)
* fixed ETag handling for new tiddlers
!!v0.10 (2009-10-08)
* minor fixes
!To Do
* createWorkspace
* document custom/optional context attributes (e.g. filters, query, revision) and tiddler fields (e.g. server.title, origin)
!Code
***/
//{{{
(function($) {
var adaptor;
adaptor = config.adaptors.tiddlyweb = function() {}; //# set up alias
adaptor.prototype = new AdaptorBase();
adaptor.serverType = "tiddlyweb";
adaptor.serverLabel = "TiddlyWeb";
adaptor.mimeType = "application/json";
adaptor.parsingErrorMessage = "Error parsing result from server";
adaptor.locationIDErrorMessage = "no bag or recipe specified for tiddler"; // TODO: rename
// retrieve current status (requires TiddlyWeb status plugin)
adaptor.prototype.getStatus = function(context, userParams, callback) {
context = this.setContext(context, userParams, callback);
var uriTemplate = "%0/status";
var uri = uriTemplate.format([context.host]);
var req = httpReq("GET", uri, adaptor.getStatusCallback, context,
null, null, null, null, null, true);
return typeof req == "string" ? req : true;
};
adaptor.getStatusCallback = function(status, context, responseText, uri, xhr) {
context.status = status;
context.statusText = xhr.statusText;
context.httpStatus = xhr.status;
if(status) {
context.serverStatus = $.evalJSON(responseText); // XXX: error handling!?
}
if(context.callback) {
context.callback(context, context.userParams);
}
};
// retrieve a list of workspaces
adaptor.prototype.getWorkspaceList = function(context, userParams, callback) {
context = this.setContext(context, userParams, callback);
context.workspaces = [];
var uriTemplate = "%0/recipes"; // XXX: bags?
var uri = uriTemplate.format([context.host]);
var req = httpReq("GET", uri, adaptor.getWorkspaceListCallback,
context, { accept: adaptor.mimeType }, null, null, null, null, true);
return typeof req == "string" ? req : true;
};
adaptor.getWorkspaceListCallback = function(status, context, responseText, uri, xhr) {
context.status = status;
context.statusText = xhr.statusText;
context.httpStatus = xhr.status;
if(status) {
try {
var workspaces = $.evalJSON(responseText);
} catch(ex) {
context.status = false; // XXX: correct?
context.statusText = exceptionText(ex, adaptor.parsingErrorMessage);
if(context.callback) {
context.callback(context, context.userParams);
}
return;
}
context.workspaces = workspaces.map(function(itm) { return { title: itm }; });
}
if(context.callback) {
context.callback(context, context.userParams);
}
};
// retrieve a list of tiddlers
adaptor.prototype.getTiddlerList = function(context, userParams, callback) {
context = this.setContext(context, userParams, callback);
var uriTemplate = "%0/%1/%2/tiddlers%3";
var params = context.filters ? "?filter=" + context.filters : "";
var workspace = adaptor.resolveWorkspace(context.workspace);
var uri = uriTemplate.format([context.host, workspace.type + "s",
adaptor.normalizeTitle(workspace.name), params]);
var req = httpReq("GET", uri, adaptor.getTiddlerListCallback,
context, { accept: adaptor.mimeType }, null, null, null, null, true);
return typeof req == "string" ? req : true;
};
adaptor.getTiddlerListCallback = function(status, context, responseText, uri, xhr) {
context.status = status;
context.statusText = xhr.statusText;
context.httpStatus = xhr.status;
if(status) {
context.tiddlers = [];
try {
var tiddlers = $.evalJSON(responseText); //# N.B.: not actual tiddler instances
} catch(ex) {
context.status = false; // XXX: correct?
context.statusText = exceptionText(ex, adaptor.parsingErrorMessage);
if(context.callback) {
context.callback(context, context.userParams);
}
return;
}
for(var i = 0; i < tiddlers.length; i++) {
var t = tiddlers[i];
var tiddler = new Tiddler(t.title);
tiddler.assign(t.title, null, t.modifier, t.modified, t.tags, t.created, t.fields);
tiddler.fields["server.workspace"] = "bags/" + t.bag;
tiddler.fields["server.page.revision"] = t.revision;
context.tiddlers.push(tiddler);
}
}
if(context.callback) {
context.callback(context, context.userParams);
}
};
// perform global search
adaptor.prototype.getSearchResults = function(context, userParams, callback) {
context = this.setContext(context, userParams, callback);
var uriTemplate = "%0/search?q=%1%2";
var filterString = context.filters ? ";filter=" + context.filters : "";
var uri = uriTemplate.format([context.host, context.query, filterString]); // XXX: parameters need escaping?
var req = httpReq("GET", uri, adaptor.getSearchResultsCallback,
context, { accept: adaptor.mimeType }, null, null, null, null, true);
return typeof req == "string" ? req : true;
};
adaptor.getSearchResultsCallback = function(status, context, responseText, uri, xhr) {
adaptor.getTiddlerListCallback(status, context, responseText, uri, xhr); // XXX: use apply?
};
// retrieve a particular tiddler's revisions
adaptor.prototype.getTiddlerRevisionList = function(title, limit, context, userParams, callback) {
context = this.setContext(context, userParams, callback);
var uriTemplate = "%0/%1/%2/tiddlers/%3/revisions";
var workspace = adaptor.resolveWorkspace(context.workspace);
var uri = uriTemplate.format([context.host, workspace.type + "s",
adaptor.normalizeTitle(workspace.name), adaptor.normalizeTitle(title)]);
var req = httpReq("GET", uri, adaptor.getTiddlerRevisionListCallback,
context, { accept: adaptor.mimeType }, null, null, null, null, true);
return typeof req == "string" ? req : true;
};
adaptor.getTiddlerRevisionListCallback = function(status, context, responseText, uri, xhr) {
context.status = status;
context.statusText = xhr.statusText;
context.httpStatus = xhr.status;
if(status) {
context.revisions = [];
try {
var tiddlers = $.evalJSON(responseText); //# N.B.: not actual tiddler instances
} catch(ex) {
context.status = false; // XXX: correct?
context.statusText = exceptionText(ex, adaptor.parsingErrorMessage);
if(context.callback) {
context.callback(context, context.userParams);
}
return;
}
for(var i = 0; i < tiddlers.length; i++) {
var t = tiddlers[i];
var tiddler = new Tiddler(t.title);
tiddler.assign(t.title, null, t.modifier, Date.convertFromYYYYMMDDHHMM(t.modified),
t.tags, Date.convertFromYYYYMMDDHHMM(t.created), t.fields);
tiddler.fields["server.type"] = adaptor.serverType;
tiddler.fields["server.host"] = AdaptorBase.minHostName(context.host);
tiddler.fields["server.page.revision"] = t.revision;
tiddler.fields["server.workspace"] = "bags/" + t.bag;
context.revisions.push(tiddler);
}
var sortField = "server.page.revision";
context.revisions.sort(function(a, b) {
return a.fields[sortField] < b.fields[sortField] ? 1 :
(a.fields[sortField] == b.fields[sortField] ? 0 : -1);
});
}
if(context.callback) {
context.callback(context, context.userParams);
}
};
// retrieve an individual tiddler revision -- XXX: breaks with standard arguments list -- XXX: convenience function; simply use getTiddler?
adaptor.prototype.getTiddlerRevision = function(title, revision, context, userParams, callback) {
context = this.setContext(context, userParams, callback);
context.revision = revision;
return this.getTiddler(title, context, userParams, callback);
};
// retrieve an individual tiddler
//# context is an object with members host and workspace
//# callback is passed the new context and userParams
adaptor.prototype.getTiddler = function(title, context, userParams, callback) {
context = this.setContext(context, userParams, callback);
context.title = title;
if(context.revision) {
var uriTemplate = "%0/%1/%2/tiddlers/%3/revisions/%4";
} else {
uriTemplate = "%0/%1/%2/tiddlers/%3";
}
if(!context.tiddler) {
context.tiddler = new Tiddler(title);
}
context.tiddler.fields["server.type"] = adaptor.serverType;
context.tiddler.fields["server.host"] = AdaptorBase.minHostName(context.host);
context.tiddler.fields["server.title"] = title; //# required for detecting renames
context.tiddler.fields["server.workspace"] = context.workspace;
var workspace = adaptor.resolveWorkspace(context.workspace);
var uri = uriTemplate.format([context.host, workspace.type + "s",
adaptor.normalizeTitle(workspace.name), adaptor.normalizeTitle(title),
context.revision]);
var req = httpReq("GET", uri, adaptor.getTiddlerCallback, context,
{ accept: adaptor.mimeType }, null, null, null, null, true);
return typeof req == "string" ? req : true;
};
adaptor.getTiddlerCallback = function(status, context, responseText, uri, xhr) {
context.status = status;
context.statusText = xhr.statusText;
context.httpStatus = xhr.status;
if(status) {
try {
var t = $.evalJSON(responseText); //# N.B.: not an actual tiddler instance
} catch(ex) {
context.status = false; // XXX: correct?
context.statusText = exceptionText(ex, adaptor.parsingErrorMessage);
if(context.callback) {
context.callback(context, context.userParams);
}
return;
}
context.tiddler.assign(context.tiddler.title, t.text, t.modifier,
Date.convertFromYYYYMMDDHHMM(t.modified), t.tags || [],
Date.convertFromYYYYMMDDHHMM(t.created), context.tiddler.fields); // XXX: merge extended fields!?
context.tiddler.fields["server.workspace"] = t.bag ? "bags/" + t.bag : "recipes/" + t.recipe; // XXX: bag is always supplied!?
context.tiddler.fields["server.page.revision"] = t.revision;
context.tiddler.fields["server.permissions"] = t.permissions.join(", ");
}
if(context.callback) {
context.callback(context, context.userParams);
}
};
// retrieve tiddler chronicle (all revisions)
adaptor.prototype.getTiddlerChronicle = function(title, context, userParams, callback) {
context = this.setContext(context, userParams, callback);
context.title = title;
var uriTemplate = "%0/%1/%2/tiddlers/%3/revisions.json?fat=1";
var workspace = adaptor.resolveWorkspace(context.workspace);
var uri = uriTemplate.format([context.host, workspace.type + "s",
adaptor.normalizeTitle(workspace.name), adaptor.normalizeTitle(title)]);
var req = httpReq("GET", uri, adaptor.getTiddlerChronicleCallback,
context, { accept: adaptor.mimeType }, null, null, null, null, true);
return typeof req == "string" ? req : true;
};
adaptor.getTiddlerChronicleCallback = function(status, context, responseText, uri, xhr) {
context.status = status;
context.statusText = xhr.statusText;
context.httpStatus = xhr.status;
if(status) {
context.responseText = responseText;
}
if(context.callback) {
context.callback(context, context.userParams);
}
};
// store an individual tiddler
adaptor.prototype.putTiddler = function(tiddler, context, userParams, callback) {
context = this.setContext(context, userParams, callback);
context.title = tiddler.title;
context.tiddler = tiddler;
context.host = context.host || this.fullHostName(tiddler.fields["server.host"]);
if(!tiddler.fields["server.title"]) {
tiddler.fields["server.title"] = tiddler.title; //# required for detecting subsequent renames
} else if(tiddler.title != tiddler.fields["server.title"]) {
return this.moveTiddler({ title: tiddler.fields["server.title"] },
{ title: tiddler.title }, context, userParams, callback);
}
var uriTemplate = "%0/%1/%2/tiddlers/%3";
try {
var workspace = adaptor.resolveWorkspace(tiddler.fields["server.workspace"]);
} catch(ex) {
return adaptor.locationIDErrorMessage;
}
var uri = uriTemplate.format([context.host, workspace.type + "s",
adaptor.normalizeTitle(workspace.name),
adaptor.normalizeTitle(tiddler.title)]);
var etag = adaptor.generateETag(workspace, tiddler);
var headers = etag ? { "If-Match": '"' + etag + '"' } : null;
var payload = {
title: tiddler.title,
text: tiddler.text,
modifier: tiddler.modifier,
tags: tiddler.tags,
fields: $.extend({}, tiddler.fields)
};
delete payload.fields.changecount;
payload = $.toJSON(payload);
var req = httpReq("PUT", uri, adaptor.putTiddlerCallback,
context, headers, payload, adaptor.mimeType, null, null, true);
return typeof req == "string" ? req : true;
};
adaptor.putTiddlerCallback = function(status, context, responseText, uri, xhr) {
context.status = [204, 1223].contains(xhr.status);
context.statusText = xhr.statusText;
context.httpStatus = xhr.status;
if(context.status) {
context.adaptor.getTiddler(context.tiddler.title, context);
}
};
// store a tiddler chronicle
adaptor.prototype.putTiddlerChronicle = function(revisions, context, userParams, callback) {
context = this.setContext(context, userParams, callback);
context.title = revisions[0].title;
var headers = null;
var uriTemplate = "%0/%1/%2/tiddlers/%3/revisions.json";
var host = context.host || this.fullHostName(tiddler.fields["server.host"]);
var workspace = adaptor.resolveWorkspace(context.workspace);
var uri = uriTemplate.format([host, workspace.type + "s",
adaptor.normalizeTitle(workspace.name),
adaptor.normalizeTitle(context.title)]);
if(workspace.type == "bag") { // generate ETag
var etag = [adaptor.normalizeTitle(workspace.name),
adaptor.normalizeTitle(context.title), 0].join("/"); //# zero-revision prevents overwriting existing contents
headers = { "If-Match": '"' + etag + '"' };
}
var payload = $.toJSON(revisions);
var req = httpReq("POST", uri, adaptor.putTiddlerChronicleCallback,
context, headers, payload, adaptor.mimeType, null, null, true);
return typeof req == "string" ? req : true;
};
adaptor.putTiddlerChronicleCallback = function(status, context, responseText, uri, xhr) {
context.status = [204, 1223].contains(xhr.status);
context.statusText = xhr.statusText;
context.httpStatus = xhr.status;
if(context.callback) {
context.callback(context, context.userParams);
}
};
// store a collection of tiddlers (import TiddlyWiki HTML store)
adaptor.prototype.putTiddlerStore = function(store, context, userParams, callback) {
context = this.setContext(context, userParams, callback);
var uriTemplate = "%0/%1/%2/tiddlers";
var host = context.host;
var workspace = adaptor.resolveWorkspace(context.workspace);
var uri = uriTemplate.format([host, workspace.type + "s",
adaptor.normalizeTitle(workspace.name)]);
var req = httpReq("POST", uri, adaptor.putTiddlerStoreCallback,
context, null, store, "text/x-tiddlywiki", null, null, true);
return typeof req == "string" ? req : true;
};
adaptor.putTiddlerStoreCallback = function(status, context, responseText, uri, xhr) {
context.status = [204, 1223].contains(xhr.status);
context.statusText = xhr.statusText;
context.httpStatus = xhr.status;
if(context.callback) {
context.callback(context, context.userParams);
}
};
// rename an individual tiddler or move it to a different workspace -- TODO: make {from|to}.title optional
//# from and to are objects with members title and workspace (bag; optional),
//# representing source and target tiddler, respectively
adaptor.prototype.moveTiddler = function(from, to, context, userParams, callback) { // XXX: rename parameters (old/new)?
var _this = this;
var newTiddler = store.getTiddler(from.title) || store.getTiddler(to.title); //# local rename might already have occurred
var oldTiddler = $.extend(true, {}, newTiddler); //# required for eventual deletion
oldTiddler.title = from.title; //# required for original tiddler's ETag
var _getTiddlerChronicle = function(title, context, userParams, callback) {
return _this.getTiddlerChronicle(title, context, userParams, callback);
};
var _putTiddlerChronicle = function(context, userParams) {
if(!context.status) {
return callback(context, userParams);
}
var revisions = $.evalJSON(context.responseText); // XXX: error handling?
// change current title while retaining previous location
for(var i = 0; i < revisions.length; i++) {
if(!revisions[i].fields.origin) { // N.B.: origin = "<workspace>/<title>"
revisions[i].fields.origin = ["bags", revisions[i].bag, revisions[i].title].join("/");
}
revisions[i].title = to.title;
}
// add new revision
var rev = $.extend({}, revisions[0]);
rev.title = to.title;
$.each(newTiddler, function(i, item) {
if(!$.isFunction(item)) {
rev[i] = item;
}
});
rev.revision++;
rev.created = rev.created.convertToYYYYMMDDHHMM();
rev.modified = new Date().convertToYYYYMMDDHHMM();
delete rev.fields.changecount;
revisions.unshift(rev);
if(to.workspace) {
context.workspace = to.workspace;
} else if(context.workspace.substring(0, 4) != "bags") { // N.B.: target workspace must be a bag
context.workspace = "bags/" + rev.bag;
}
var subCallback = function(context, userparams) {
var rev = "server.page.revision";
newTiddler.fields[rev] = parseInt(newTiddler.fields[rev], 10) + 1; // XXX: extended fields' values should be strings!?
newTiddler.fields["server.title"] = to.title;
_deleteTiddler(context, userparams);
};
return _this.putTiddlerChronicle(revisions, context, context.userParams, subCallback);
};
var _deleteTiddler = function(context, userParams) {
if(!context.status) {
return callback(context, userParams);
}
context.callback = null;
return _this.deleteTiddler(oldTiddler, context, context.userParams, callback);
};
callback = callback || function() {};
context = this.setContext(context, userParams);
context.workspace = from.workspace || oldTiddler.fields["server.workspace"];
return _getTiddlerChronicle(from.title, context, userParams, _putTiddlerChronicle);
};
// delete an individual tiddler
adaptor.prototype.deleteTiddler = function(tiddler, context, userParams, callback) {
context = this.setContext(context, userParams, callback);
context.title = tiddler.title; // XXX: not required!?
var uriTemplate = "%0/%1/%2/tiddlers/%3";
var host = context.host || this.fullHostName(tiddler.fields["server.host"]);
try {
var workspace = adaptor.resolveWorkspace(tiddler.fields["server.workspace"]);
} catch(ex) {
return adaptor.locationIDErrorMessage;
}
var uri = uriTemplate.format([host, workspace.type + "s",
adaptor.normalizeTitle(workspace.name),
adaptor.normalizeTitle(tiddler.title)]);
var etag = adaptor.generateETag(workspace, tiddler);
var headers = etag ? { "If-Match": '"' + etag + '"' } : null;
var req = httpReq("DELETE", uri, adaptor.deleteTiddlerCallback, context, headers,
null, null, null, null, true);
return typeof req == "string" ? req : true;
};
adaptor.deleteTiddlerCallback = function(status, context, responseText, uri, xhr) {
context.status = [204, 1223].contains(xhr.status);
context.statusText = xhr.statusText;
context.httpStatus = xhr.status;
if(context.callback) {
context.callback(context, context.userParams);
}
};
// compare two revisions of a tiddler (requires TiddlyWeb differ plugin)
//# if context.rev1 is not specified, the latest revision will be used for comparison
//# if context.rev2 is not specified, the local revision will be sent for comparison
//# context.format is a string as determined by the TiddlyWeb differ plugin
adaptor.prototype.getTiddlerDiff = function(title, context, userParams, callback) {
context = this.setContext(context, userParams, callback);
context.title = title;
var tiddler = store.getTiddler(title);
try {
var workspace = adaptor.resolveWorkspace(tiddler.fields["server.workspace"]);
} catch(ex) {
return adaptor.locationIDErrorMessage;
}
var tiddlerRef = [workspace.type + "s", workspace.name, tiddler.title].join("/");
var rev1 = context.rev1 ? [tiddlerRef, context.rev1].join("/") : tiddlerRef;
var rev2 = context.rev2 ? [tiddlerRef, context.rev2].join("/") : null;
var uriTemplate = "%0/diff?rev1=%1";
if(rev2) {
uriTemplate += "&rev2=%2";
}
if(context.format) {
uriTemplate += "&format=%3";
}
var host = context.host || this.fullHostName(tiddler.fields["server.host"]);
var uri = uriTemplate.format([host, adaptor.normalizeTitle(rev1),
adaptor.normalizeTitle(rev2), context.format]);
if(rev2) {
var req = httpReq("GET", uri, adaptor.getTiddlerDiffCallback, context, null,
null, null, null, null, true);
} else {
var payload = {
title: tiddler.title,
text: tiddler.text,
modifier: tiddler.modifier,
tags: tiddler.tags,
fields: $.extend({}, tiddler.fields)
}; // XXX: missing attributes!?
payload = $.toJSON(payload);
req = httpReq("POST", uri, adaptor.getTiddlerDiffCallback, context,
null, payload, adaptor.mimeType, null, null, true);
}
return typeof req == "string" ? req : true;
};
adaptor.getTiddlerDiffCallback = function(status, context, responseText, uri, xhr) {
context.status = status;
context.statusText = xhr.statusText;
context.httpStatus = xhr.status;
if(status) {
context.diff = responseText;
}
if(context.callback) {
context.callback(context, context.userParams);
}
};
// generate tiddler information
adaptor.prototype.generateTiddlerInfo = function(tiddler) {
var info = {};
var uriTemplate = "%0/%1/%2/tiddlers/%3";
var host = this.host || tiddler.fields["server.host"]; // XXX: this.host obsolete?
host = this.fullHostName(host);
var workspace = adaptor.resolveWorkspace(tiddler.fields["server.workspace"]);
info.uri = uriTemplate.format([host, workspace.type + "s",
adaptor.normalizeTitle(workspace.name),
adaptor.normalizeTitle(tiddler.title)]);
return info;
};
adaptor.resolveWorkspace = function(workspace) {
var components = workspace.split("/");
return {
type: components[0] == "bags" ? "bag" : "recipe",
name: components[1] || components[0]
};
};
adaptor.generateETag = function(workspace, tiddler) {
var etag = null;
if(workspace.type == "bag") {
var revision = tiddler.fields["server.page.revision"];
if(typeof revision == "undefined") {
revision = "0";
}
etag = [adaptor.normalizeTitle(workspace.name),
adaptor.normalizeTitle(tiddler.title), revision].join("/");
}
return etag;
};
adaptor.normalizeTitle = function(title) {
return encodeURIComponent(title);
};
})(jQuery);
/*
* jQuery JSON Plugin
* version: 1.3
* source: http://code.google.com/p/jquery-json/
* license: MIT (http://www.opensource.org/licenses/mit-license.php)
*/
(function($){function toIntegersAtLease(n)
{return n<10?'0'+n:n;}
Date.prototype.toJSON=function(date)
{return this.getUTCFullYear()+'-'+
toIntegersAtLease(this.getUTCMonth())+'-'+
toIntegersAtLease(this.getUTCDate());};var escapeable=/["\\\x00-\x1f\x7f-\x9f]/g;var meta={'\b':'\\b','\t':'\\t','\n':'\\n','\f':'\\f','\r':'\\r','"':'\\"','\\':'\\\\'};$.quoteString=function(string)
{if(escapeable.test(string))
{return'"'+string.replace(escapeable,function(a)
{var c=meta[a];if(typeof c==='string'){return c;}
c=a.charCodeAt();return'\\u00'+Math.floor(c/16).toString(16)+(c%16).toString(16);})+'"';}
return'"'+string+'"';};$.toJSON=function(o,compact)
{var type=typeof(o);if(type=="undefined")
return"undefined";else if(type=="number"||type=="boolean")
return o+"";else if(o===null)
return"null";if(type=="string")
{return $.quoteString(o);}
if(type=="object"&&typeof o.toJSON=="function")
return o.toJSON(compact);if(type!="function"&&typeof(o.length)=="number")
{var ret=[];for(var i=0;i<o.length;i++){ret.push($.toJSON(o[i],compact));}
if(compact)
return"["+ret.join(",")+"]";else
return"["+ret.join(", ")+"]";}
if(type=="function"){throw new TypeError("Unable to convert object of type 'function' to json.");}
var ret=[];for(var k in o){var name;type=typeof(k);if(type=="number")
name='"'+k+'"';else if(type=="string")
name=$.quoteString(k);else
continue;var val=$.toJSON(o[k],compact);if(typeof(val)!="string"){continue;}
if(compact)
ret.push(name+":"+val);else
ret.push(name+": "+val);}
return"{"+ret.join(", ")+"}";};$.compactJSON=function(o)
{return $.toJSON(o,true);};$.evalJSON=function(src)
{return eval("("+src+")");};$.secureEvalJSON=function(src)
{var filtered=src;filtered=filtered.replace(/\\["\\\/bfnrtu]/g,'@');filtered=filtered.replace(/"[^"\\\n\r]*"|true|false|null|-?\d+(?:\.\d*)?(?:[eE][+\-]?\d+)?/g,']');filtered=filtered.replace(/(?:^|:|,)(?:\s*\[)+/g,'');if(/^[\],:{}\s]*$/.test(filtered))
return eval("("+src+")");else
throw new SyntaxError("Error parsing JSON, source is not valid.");};})(jQuery);
//}}}
Story points are a unit of measure in the estimation of [[UserStories]]. They are used to create a relative measure of difficulty/complexity for a story. So for example, a 2 point story should be considered twice as difficult/complex as a 1 point story. The scale used is less important than ensuring consistency in applying the numbers across cards. So if two cards have each been given an estimate of 2 points, then they should be be of equal difficulty.
One approach is to use the Fibonacci series (1, 2, 3, 5, 8...).
See also [[IdealDays]]
This is one of the four fundamental tenets of the AgileManifesto.
RespondingToChange is preferred over following a plan.
ReleasePlanning involves PrioritisingRequirements so that the most important BusinessValue is delivered early in the form of WorkingSoftware.
!When does this happen?
This should be the kick off session for a [[TimeboxedDeliveryCycle]].
!Inputs
The input to the Release Planning Session is the set of [[UserStories]] making up the project backlog (also referred to as the [[MasterStoryList]]).
!Roles & Responsibilities
* [[DeliveryManager]] / [[ProjectManager]]
** Facilitator of the Release Planning session.
* [[Customer]] or [[CustomerProxy]]
** To provide focus and vision for this release.
** Have [[UserStories]] ready to discuss with the team with appropriate [[BusinessValue]] and [[AcceptanceCriteria]]
** Present [[UserStories]] to teams
** Answer questions to clarify understanding.
** Prioritise user stories.
* Teams – [[Designer]]s, [[Developer]]s and [[Tester]]s
** To question and clarify understanding of [[UserStories]].
** To provide feedack on the testability of [[AcceptanceCriteria]]
** To provide estimates against [[UserStories]] presented
** To answer customers questions where technical input is required.
!Objectives
* To provide the focus and vison for this release
* To determine prioritised list of user stories that can be delivered in this release.
* To provide relative estimates for these user stories
* To determine any high risk stories and dependencies across teams
!Process
* The [[DeliveryManager]] will provide details of how the Release Planning meeting will run.
* The [[Customer]] will present the overview of their vision for this release
* For each user story
** The customer will provide an overview of user story
** The teams will ask clarification questions
** The teams will provide feedback the testability of the [[AcceptanceCriteria]] (How do we know when we're done?)
** Rough estimation by the team(s) who will be doing the work
** Next user story
* The customer and the team will collaborate in [[PrioritisingRequirements]] to create an order for the user stories.
* Initial Release Plan will be determined based on:
** Priority
** Estimates
** [[Velocity]] – what is the teams capacity to do work.
** Dependencies
** Risks
* Agreed release plan displayed..
!Output
* Initial [[ReleasePlan]]
* Placeholders for teams Iteration Plans
* Risk and dependancies highlighted
This is one of the four fundamental tenets of the AgileManifesto.
IndividualsAndInteractions are preferred over processes and tools.
|''Description:''|agilecookbook|
|''Type:''|tiddlywiki|
|''URL:''|http://wiki.osmosoft.com/alpha/agilecookbook/|
|''Workspace:''|Main|
One to three week period where scope is fixed, in which a number of UserStories are delivered. A DevelopmentIteration involves planning, initiation and reflection, provided by the IterationPlanningMeeting, IterationKickOff and IterationRetrospective respectively. Also a TeamRetrospective without ProjectManager or [[Customer]] appropriate at the end of an iteration.
As per the existing AccelerateFramework the [[TimeboxedDeliveryCycle]] is broken down into a series of iterations, sometimes referred to as time boxes. In this Cookbook these will be referred to as a DevelopmentIteration, to avoid confusion with other usages of the word Iteration.
DevelopmentIteration is one of the Agile CorePractices.
!Who should be involved?
The entire team and all the AgileRoles are involved in each DevelopmentIteration. It's important to note that there is parallel work going on at any given time, with the whole team coming together for the IterationKickOff and IterationRetrospective. The [[Developer]] team will be implementing the functionality for the current DevelopmentIteration, while the BusinessAnalyst team is elaborating the UserStories for the next DevelopmentIteration and the [[Tester]] team is assisting with defining AcceptanceCriteria for the upcoming DevelopmentIteration - and performing testing on the results of the previous one. This workflow is illustrated in the image below:
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/AnatomyOfAnIteration.jpeg]]
!When should it be done?
There are a number of [[DevelopmentIteration]]s which take place during the [[TimeboxedDeliveryCycle]].
!What are the benefits?
Breaking work down into smaller iterations provides:
* measurable data on progress at the end of each iteration which provide early feedback and the ability for the [[Customer]] to reprioritise in the PlanningGame
* allows [[Velocity]] to be measured
* demonstrate visible progress through WorkingSoftware
* allows ProgressiveSignOff from the [[Customer]]
!Are there any prerequisites?
The work must be able to be broken down into UserStories which can be completed during a single DevelopmentIteration.
!How has this been done elsewhere?
Iterative development is a common practice and a fundamental principle in agile development. Visit AnatomyOfAnIteration to see a graphical explanation of how iterations have been run in ThoughtWorks.
!Common pitfalls
* ''Iteration Length'' - The length of a DevelopmentIteration should generally be as short as is practicable, while understanding that it helps if your UserStories are sized such that the average developer can complete at least two per DevelopmentIteration. To illustrate this, imagine if your UserStories took on average 10 working days to complete, and your DevelopmentIteration was two weeks in length... there would be a strong possibility of finishing an iteration with no completed UserStories.
* ''Requirements Churn'' - It pays to fix the requirements within a DevelopmentIteration. This allows the team to focus on getting the work done. If there is a change to a UserStory that is under development, then unless it is a trivial one - it often pays to simply remove the UserStory from play, have it re-analysed and deal with it in the next DevelopmentIteration. This helps to prevent developers time being wasted, since they can go on with the next well-understood UserStory rather than wait around.
* ''Bonus Stories'' - a corollary to the above is that it pays to have slightly more UserStories available than you expect the team will be able to complete - that way if one gets pulled for clarification, you have something ready for the [[Developer]] to go on with. It also pays to have a variety of 'sizes' available so that you can give additional small UserStories to [[Developer]]s who finish early. Although you should use YesterdaysWeather to plan the expected throughput for the DevelopmentIteration, having some extra UserStories available allows you to increase throughput when possible.
A ReleasePlan is used to show how much work is planned to be included in your [[TimeboxedDeliveryCycle]]. It should include some degree of prioritisation of the work, and should indicate if there are any planned interim releases of subsets of functionality within the [[TimeboxedDeliveryCycle]]. The ReleasePlan may be included in a RollingPlan for the programme of work.
A ReleasePlan is an example of Adaptive Planning. It says what must be done in the current [[TimeboxedDeliveryCycle]], and includes a current view of the relative priority of the work. It doesn't attempt to specify who will work on any particular UserStory, and it doesn't attempt to say specifically when each UserStory might be developed. It's kept simple so that it is easy to change, and therefore doesn't become an impediment to change.
A ReleasePlan may be as simple as a set of index cards pinned to a wall, however it needs to be tightly coupled to your MasterStoryList as part of a [[OneTruthRepository]]. Therefore if you are using a Requirements Repository for your MasterStoryList then the ReleasePlan should be implemented as a view into that repository.
To get started with this workspace, you'll need to modify the following tiddlers:
* SiteTitle & SiteSubtitle: The title and subtitle of the site, as shown above (after saving, they will also appear in the browser title bar)
* MainMenu: The menu (usually on the left)
* DefaultTiddlers: Contains the names of the tiddlers that you want to appear when the workspace is opened when a user is logged in.
* AnonDefaultTiddlers: Contains the names of the tiddlers that you want to appear when the worksace is opened when a user who is not logged in. This should contain the login tiddler. [[Login]]
* You can change the permission of this workspace at anytime by opening the [[Manage Users]] and [[Permissions]] tiddlers.<<ccEditWorkspace>>
!Content
The material in the cookbook is presented as a network of linked topics on Agile Delivery. There is a narrative based on the AgileRoles that exist in a typical project that will take you through a sequence of [[AgilePractices]]. Each AgilePractice is described in a consistent form with references to case studies and further reading that is available outside the cookbook. Pick a role that you wish to understand and follow the topics to understand the impact for that role of the changes to Agile Delivery.
The CorePractices are the critical parts of the cookbook and will be used to judge the way that a project has adopted Agile Delivery.
!Format
This agile cookbook has been built using TiddlyWiki running on ccTiddly. ccTiddly is a serverside adaptation of TiddlyWiki which enables multi user collaboration.
In future version of the agile cookbook it will be able to take an entire copy of the file offline with you.
!Feedback
We value your feedback on the material in this cookbook. Please refer to the name of the section when providing your feedback so we can locate the right area. We prefer constructive feedback where possible so please try to suggest a better form of words or refer to some extra information that should be included.
There is a Google Group to discuss matters relating to the Agile Cookbook : http://groups.google.com/group/agilecookbook
!Navigation
Each topic is loaded into the central panel in the browser when you click on the link. As you click on more links, more topics are loaded. Unlike a standard form of browser content there is no concept of "going back". This may take a bit of getting used to at first but you can always return to the major headings on the left hand menu for specific starting topics for exploring the content.
The left hand menu also has some administrative features such as the current release notes, this help topic and also allows you to provide feedback on the material.
If you wish to search for something, on the top right hand side you can see a search box which will take you to all the sections that refer to the search string.
There is also a reference guide of all the topics in alphabetical order that is shown below the search window on the right hand side.
There are extra features on a menu that appears when you move your cursor over the topic header.
These allow you to:
* close all the open topics except the current topic
* close the current topic
* show all the other topics that refer to the current topic
We hope you find this cookbook helpful and please let us know if you need further help by using the [[Feedback]] available.
On an Agile project, requirements are not analysed in detail until they are just about to be developed. This avoids the costs associated with having to amend a large quantity of detailed documents when requirements change. Sometimes change is due to external factors, such as market conditions or legislative changes that affect the [[Customer]]. More often changes occur due to the [[Customer]] re-prioritising or discovering new requirements thought being actively involved in the Agile development process. In either case RespondingToChange allows the team to deliver greater business value, and not doing to much elaboration in advance means LoweringTheCostOfChange.
Another reason for late elaboration of requirements is that it allow the BusinessAnalyst team to learn throughout the project, via feedback from the [[Developer]] team and [[Tester]] team. As the project goes along, this feedback allows the BusinessAnalyst to create better UserStories and can lead to substantial efficiencies as the level of detail in the UserStories is adjusted based on experience.
Initially requirements start out as a prioritised MasterStoryList where each UserStory exists as a name and brief description. Many Agile practitioners create these initial UserStories on index cards, others use some means of electronic storage. The important thing is that at this stage the UserStory should be brief.
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/storycardexample.jpeg]]
As the each DevelopmentIteration approaches, the next highest priority group of UserStories is fleshed out in greater detail by the BusinessAnalyst team. By the time that a UserStory is presented to the [[Developer]] team in the IterationKickOff, it should be sufficiently detailed for a [[Developer]] to be able to begin working on it. One of the most important components of the UserStory at this stage is the AcceptanceCriteria, which will be automated by the [[Developer]] into one or more AutomatedAcceptanceTests for the UserStory.
This is the AgileCookbook version 2.1
Build : build.22.
Time: 2006-02-09.
Version 2.1 ( 09 Feb 2006 )
* fixed undefined tiddler problems
* tidied UserStory and CaseStudies tiddlers
Version 2.0 ( 30 Jan 2006 )
* Updates to UserStory and AgileOutsourcing tiddler
* fixed email address in [[Feedback]]
* updated the FAQ items
Version 1.2 ( 20 Oct 2005 )
* ContactUs routed via logical email address
* Updated AgileOutsourcing with revised Terms Sheet
* Incorporation of the AccelerateFramework
[[Testing]] is fundamental to Agile development.
UserStories are specified with AcceptanceCriteria which are turned into AutomatedAcceptanceTests.
TestDrivenDesign and TestDrivenDevelopment both specify tests prior to commencing development.
ContinuousIntegration uses AutomatedFunctionalTests and other regression tests to defend the code base against unintended changes.
Types of test include:
* Acceptance Test
* Unit Test
* Performance Test
* Integration Test
* Regression Test
All of which are automated and included in the ContinuousIntegration build where practicable.
text for agilecookbook.com entry
This is a walk through of an Agile project, from the ProjectManager perspective, detailing the activities that the ProjectManager will have a significant role in.
The HotHouse runs over days one to three of the [[TimeboxedDeliveryCycle]]. The focus of the AgileCookbook and this ProjectManagerWalkthrough is days four to ninety.
!After the HotHouse - IterationZero, day four
After the HotHouse, from day four, you may need to do some initial work in order to be able to move into the DevelopmentIteration cycle. This tends to be more likely if you're working on a new piece of software, in a new environment, or with a largely new team. Instead of allowing this 'start-up' work to affect your first DevelopmentIteration, you can schedule an IterationZero. Activities that the ProjectManager will be involved in at this stage are:
* Constructing the MasterStoryList, this will be the primary record for ScopeManagement. It is important that each UserStory should be decomposed until it could be developed within a period of a week if possible. It is very important that they all be of roughly similar estimate size - this allows very simple and accurate tracking and reduces the impact of poorly estimated stories.
* Determine a BaselineEstimate for each UserStory in the MasterStoryList, these are used for ProjectTracking and in conjunction with [[Velocity]] allow you a consistent base from which to predict delivery. It is possible to estimate only a representative sample and extrapolate over the rest - however this only works if all stories can be reasonably expected to be of similar size.
* Help the [[Customer]] in PrioritisingRequirements according to BusinessValue. At this stage you may not need to prioritise every UserStory, remember you only need to do enough planning in order to be able to start your first DevelopmentIteration and prepare a ReleasePlan.
* Prepare a ReleasePlan, showing how much you believe you can achieve within your [[TimeboxedDeliveryCycle]].
* Prepare an IterationPlan for your first DevelopmentIteration, your BusinessAnalyst team will begin ElaboratingRequirements during IterationZero so that each UserStory is ready for Development.
!Before each DevelopmentIteration
* Conduct an IterationPlanningMeeting
* Hold an IterationKickOff
!During each DevelopmentIteration
* DailyStandUp meeting
* Team morale
* Tuning the team - clearing roadblocks
* IterationTracking
* Promoting [[Communication]] and updating information radiators
* Verify that appropriate AgilePractices are being followed
* Incorporate feedback from the previous IterationRetrospective
!After each DevelopmentIteration
* Confirm that the iteration has delivered WorkingSoftware with passing AutomatedAcceptanceTests
* Ensure that the delivered UserStories have been Showcased to the [[Customer]] for sign-off.
* Calculate [[Velocity]]
* Update your ProjectTracking to include the work from the completed iteration.
* Hold an IterationRetrospective
!At the end of the [[TimeboxedDeliveryCycle]]
* Release the cumulative WorkingSoftware built up during previous iterations.
It is important to note that this final release is not a big bang release, as it is merely the results of the final iteration's work added onto the existing WorkingSoftware developed in previous iterations.
<link rel="alternate" type="application/atom+xml" title="Atom" href="/recipes/agilecookbook/tiddlers.atom?sort=-modified;limit=20" />
* The [[Customer]] or CustomerProxy who is responsible for defining the requirements, priorities and accepts delivery of the completed [[UserStories]].
* The ProjectManager who is responsible for delivering the completed system to the [[Customer]].
* The BusinessAnalyst (who often acts as a CustomerProxy) is responsible for ensuring that the requirements are fully formed into proper UserStories with accompanying [[AcceptanceCriteria]].
* The [[Designer]] is responsible for ensuring a coherent technical design with appropriate levels of quality, performance etc which satisfies the [[Customer]]'s requirements.
* The [[Developer]] is responsible for delivering software code which fulfils UserStories by meeting their [[AcceptanceCriteria]].
* The [[Tester]] is responsible for ensuring that the AcceptanceCriteria tests are run and that they pass. In addition they are responsible for ensuring the overall quality of the system.
!Other roles that are useful to consider when adopting AgilePractices
* The AgileCoach is an experienced Agile practitioner who is responsible for helping the team adopt [[AgilePractices]]. The AgileCoach may also take on the IterationManager role.
* The AgileEnablers who work within the team in specific roles. Agile favours learning via interactions between individuals, teams benefit greatly if they are seeded with experienced AgileEnablers in areas such as the [[Developer]], BusinessAnalyst and [[Tester]] teams.
* The BuildMaster, usually a [[Developer]] who has specific experience and skills in setting up and maintaining a ContinuousIntegration environment.
* The IterationManager who takes on the inward focusing parts of the ProjectManager role, specifically dealing with ensuring that the team is productive and that the iterative process is running smoothly.
* The TechnicalLead, usually a senior [[Developer]] working within the [[Developer]] team, who is responsible for ensuring that the technical CommonVision is maintained. The TechnicalLead works closely with the [[Designer]] in order to both communicate design goals to the team and to provide feedback to the [[Designer]] about implementation issues.
A ServiceInterface is an abstraction of an external service, which allows the use of either a real implementation of that service, or a ServiceStub where it is not possible or not efficient to use the real service. The underlying idea is to achieve a SimpleDesign and LoweringTheCostOfChange by reducing dependency on an external service. Another name commonly used for this pattern is Service Layer.
[[Domain - Driven Design: Tackling Complexity in the Heart of Software|http://www.amazon.com/exec/obidos/tg/detail/-/0321125215/ref=pd_sim_b_6/104-5429656-3021524?_encoding=UTF8&v=glance]], by Eric Evans uses this principle to simplify and abstract away the underlying persistence mechanism.
Note that this pattern is still useful when adopting a ServiceOrientedArchitecture, since the ServiceInterface provides a local abstraction of the possibly remote service interface.
The term CodeSmell refers to things that may indicate problems with the code base. For example, excessive CodeDuplication is a CodeSmell. More information can be found on the C2 wiki: http://xp.c2.com/CodeSmell.html
The MasterStoryList is the system of record for Project Scope and therefore is key to ScopeManagement.
The priority of requirements may change during an Agile project, indeed some requirements may be retired by the [[Customer]] and be replaced by higher value ones as the project progresses. ScopeManagement on an Agile project is therefore primarily concerned with managing the volume of work, rather than individual requirements. The sum of the BaselineEstimate for each UserStory is the volume of work.
Ideally the [[Customer]] is free to add new requirements so long as an equal volume of work is removed from scope. Practically, there is often a driver to add scope, rather than substitute - in that case the ProjectManager must consider the project [[Velocity]] to determine if the additional volume of work can be delivered.
Clearly, for volume based ScopeManagement to work, each new requirement must have a BaselineEstimate that is consistent with those of the original UserStories. The ProjectManager must also be able to calculate a [[Velocity]] for the team, which means that progress must be measured relatively frequently - another reason why DevelopmentIteration length should be in the range of 2-3 weeks.
Being able to quickly assess the likely cost of new requirements, and the impact on the project schedule allows the ProjectManager to have an informed discussion with the [[Customer]] regarding the practicality of including new requirements, and allows for informed prioritisation of requirements by the [[Customer]].
Experience shows that this leads to a collaborative approach to ScopeManagement, where the [[Customer]] understands the trade-offs that need to be made in order to deliver the highest value requirements at the end of the [[TimeboxedDeliveryCycle]].
It is imperative that an Agile team strives to maintain a CommonVision of the task at hand. This is not restricted to technical issues, but encompasses such things as the priority of requirements and the status of the project. Clearly the best mechanism for [[Communication]] of the technical vision may not be the same as that used to report on the project status.
Specific practices that greatly assist with sharing a CommonVision include:
* The adoption of CodingStandards, PairProgramming and SimpleDesign all help to share a common technical vision
* Having an OnSiteCustomer, using the PlanningGame and holding an IterationKickOff help to share a CommonVision of the requirements
* Conducting a DailyStandUp and maintaining a ProjectDashboard and OneTruthRepository keep the team aware of the project status and any issues
!Who should be involved?
The whole team is involved.
!When should it be done?
Anytime that an opportunity arises to share a CommonVision. Often the team will come up with new [[Communication]] mechanisms when a misunderstanding or miscommunication has been detected.
!What are the benefits?
Having a CommonVision helps to avoid misdirected effort, and improves [[Communication]] and CollectiveOwnership within the team.
!Are there any prerequisites?
Some way of communicating the CommonVision is necessary. It is important that this means of communication be simple and accessible - favour collaborative mediums like conversations, whiteboards, and ProjectWiki over command-and-control mediums like memo's, documents and Gantt charts.
!How has this been done elsewhere?
One device that ThoughtWorks has used successfully to communicate overall priorities of the project is shown below. The sliders are set during the inception of the project and are reviewed regularly. They guide the project in resolving issues where for example additional scope might impact delivery dates. In the real-world example below, the team would prioritise delivering on time over additional scope. Interestingly, although Team Satisfaction was the lowest slider - that team had the highest satisfaction in the department, indicating that in this case there was no trade-off required.
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/tradeoffsliders.jpeg]]
!Common pitfalls
In many cases, communication within the team fails to ensure that everyone is aware of the direction and priorities of the [[Customer]] and ProjectManager. This lack of CommonVision can lead to the development team investing their efforts in low-priority tasks.
A DailyBuild is an automated complete build of the entire source tree. It might include packaging and deployment, and could also include test execution. It can be the first step on the way to ContinuousIntegration.
From a [[Customer]]'s point of view, the most significant changes from a more traditional approach are the focus on each DevelopmentIteration, using UserStories to express requirements and a greater CustomerInvolvement in the project.
The [[Designer]] may be considered to take the role of [[Customer]] in respect of the non-functional requirements of the system. These non-functional requirements may also be expressed as UserStories, and prioritised alongside the UserStories provided by the business [[Customer]].
The [[Customer]], or more often a CustomerProxy in their place, is involved to a greater degree than traditionally. At first this may seem an additional overhead for the [[Customer]], but is essential and does provide a number of benefits:
* being able to reprioritise [[Requirements]] at the start of each DevelopmentIteration
* greater control of the direction of a project and the ability to fine tune the outcome and be a customer of a project which is RespondingToChange
* the right to Change Their Mind about requirements after seeing WorkingSoftware, rather than having requirements Set In Stone at the start of a project
* the right to see progress based on WorkingSoftware rather than 80 Percent Finished Estimates
* the right to cancel a project and be left with WorkingSoftware reflecting the investment to date.
Contrary to AgileMyths, a [[Customer]] has greater visibility and control over an Agile project.
However, a trade-off for this greater control and these benefits is that the [[Customer]] has to work more closely with the project and greater CustomerCollaboration is required.
Things that are likely to be different:
* greater involvement in the project at a number of stages
* expressing requirements in UserStories which have ascribed BusinessValue
* regularly seeing the delivery of WorkingSoftware which has been developed using TestDrivenDesign and AutomatedAcceptanceTests which leads to greater quality of software
* progress reporting based on ProjectTracking of UserStories
Things that are likely to stay the same:
* HotHouse session
* Issue and risk management
The CustomerWalkthrough provides more detail on activities of a [[Customer]] within an Agile team during the [[TimeboxedDeliveryCycle]].
Background: #fff
Foreground: #000
PrimaryPale: #8cf
PrimaryLight: #679DC2
PrimaryMid: #005B99
PrimaryDark: #014
SecondaryPale: #ffc
SecondaryLight: #fe8
SecondaryMid: #db4
SecondaryDark: #841
TertiaryPale: #eee
TertiaryLight: #ccc
TertiaryMid: #999
TertiaryDark: #666
Error: #f88
/***
|''Name:''|BTSkin |
|''Description:''|The basic BT theme |
|''Author:''|Phil Hawksworth - ph [at] osmosoft [dot] com |
|''Version:''|0.1|
|''Date:''|July 28th, 2008|
|''Comments:''|Please make comments at http://groups.google.co.uk/group/TiddlyWikiDev |
|''License:''|[[BSD License|http://www.opensource.org/licenses/bsd-license.php]] |
|''~CoreVersion:''|2.4.0|
|''~PageTemplate:''|##PageTemplate|
|''~ViewTemplate:''|##ViewTemplate|
|''~StyleSheet:''|##StyleSheet|
***/
!PageTemplate
<!--{{{-->
<div id='messageBar'><span id='messageArea'></span></div>
<div id='topMenu' refresh='content' tiddler='TopMenu'></div>
<div id='pageTitleSection' class='constrain'>
<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>
<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
</div>
<div id='mainMenu' refresh='content' tiddler='MainMenu'></div>
<div id='displayArea'>
<div id='tiddlerDisplay'></div>
</div>
<div id='footer' refresh='content' tiddler='Footer'></div>
<!--}}}-->
!ViewTemplate
<!--{{{-->
<div class='toolbar' macro='toolbar closeTiddler closeOthers +editTiddler > fields syncing permalink revisions references jump'></div>
<div class='title' macro='view title'></div>
<div class='viewer' macro='view text wikified'></div>
<div class='tagClear'></div>
<!--}}}-->
!StyleSheet
/*{{{*/
body { color:#333;}
a { color:#660099; text-decoration:none;}
a:hover {color:#660099; background-color:transparent; text-decoration:underline;}
h1,h2,h3,h4,h5,h6 {color:#444;}
/* Page Framework */
body {background-color:#fff; }
#displayArea { margin:0 2em 2em 220px;}
div.constrain {width:80%; margin:0 auto;}
/* message bar */
#messageBar {display:block; position:relative; width:100%; margin:0; background-color:transparent; height:1.6em; font-size:11px;}
#messageArea { position:absolute; top:0; left:0; padding:0; margin:0; border-style:none; background-color:transparent;}
#messageArea div { margin-left:20px; padding:3px 0 0 0;}
#messageArea div.messageToolbar { position:absolute; top:0; right:0; padding:0; margin:0;}
#messageArea a { color:#666; text-decoration:none; }
#messageArea a:hover { color:#777; text-decoration:none; }
#messageArea .button { float:right; background-color:#eee; color:#444; margin:0 0 0 1em; padding:3px 6px; }
#messageArea .button:hover {background-color:#ddd; color:#333;}
/* Header */
div.header {height:50px; margin:1em 2em 1em 2em; background-color:#fff; background:#fff url(images/bt_logo_static.jpg) no-repeat top left; text-align:right;}
#pageTitleSection {display:block; width:100%; margin:0; text-align:left; border-bottom:solid 1px #ccc; padding:1em 0; white-space:nowrap;}
#pageTitleSection span {color:#777; padding:0; margin:0; white-space:nowrap;}
#pageTitleSection span.siteTitle { margin-left:20px;}
#pageTitleSection span.siteSubtitle { margin-left:0.5em;}
/* search */
.searchButton {margin-right:0.5em;}
/* Top Menu*/
#topMenu { display:block; font-size:1.3em; height:auto; background-color:#aaa; text-align:center; }
#topMenu a { border-style:none; font-weight:normal; background-color:transparent; color:#fff; margin:0; display:inline; padding:0 1em; text-decoration:none;}
#topMenu a:hover { border-style:none; background-color:#f90; color:#fff;}
#topMenu a:active { border-style:none; background-color:#000; color:#fff;}
/* MainMenu */
#mainMenu { margin:2em 0 20px 20px; padding:0; text-align:left; width:200px;}
#mainMenu a { border-style:none; font-size:0.9em; font-weight:normal; background-color:transparent; color:#000; margin:0; display:block; padding:0 1em; border-left:solid 8px #E8D7F7;}
#mainMenu a:hover { background-color:transparent; color:#000; text-decoration:underline;}
#mainMenu a:active { background-color:transparent; color:#000; font-weight:bold;}
#mainMenu br { display:none;}
/* Footer */
#footer {clear:left; display:block; width:100%; margin:2em 0; text-align:right; border-top:solid 1px #ccc; padding:1em 0; }
#footer a {margin-right:2em; color:#6B4999; text-decoration:none;}
#footer a:hover {color:#6B4999; text-decoration:underline;}
/* Login Box */
.wizard, .wizardFooter, .wizardStep{background-color:transparent;border:0px;}
.viewer table, table.twtable {border:0px}
.viewer td, .viewer tr, .twtable td, .twtable tr {border:0px}
.wizard {background-color:#eee; border:9px solid #ddd; padding:10px}
.viewer .button {background-color:#660099; padding:5px; margin:5px; border:1px solid black; font-weight:bold; color:white}
.tiddler .title {color:#555;}
div.layoutTable table {border-style:none; margin:0;}
div.layoutTable tr {border-style:none; margin:0;}
div.layoutTable td {border-style:none; vertical-align:top; padding:1em 2em 0 0;}
div.layoutTable td strong {clear:left; font-weight:normal; float:left; margin-top:0.4em; color:#777;}
div.productsTable table {border-style:none; margin:2em 0;}
div.productsTable tr {border-style:none; margin:0 0 1em 0;}
div.productsTable td {border-style:none;}
div.productsTable td a.tiddlyLink {margin:0 5em 0 1em;}
div.contributorsTable table {border-style:none; margin:2em 0;}
div.contributorsTable tr {border-style:none; margin:0 0 1em 0;}
div.contributorsTable td {border-style:none; vertical-align:top; padding:1em 2em;}
/*}}}*/
This is a walk through of an Agile project, from the [[Designer]] perspective, detailing the activities that the [[Designer]] will have a significant role in.
The HotHouse runs over days one to three of the [[TimeboxedDeliveryCycle]]. The focus of the AgileCookbook and this DesignerWalkthrough is days four to ninety.
!After the HotHouse - IterationZero, day four
* Assist with determining a BaselineEstimate for each UserStory, providing insight into the system changes that would be required to implement the required functionality.
* Help the [[Customer]] with prioritisation of the UserStories, taking into account any technical constraints.
!Before each DevelopmentIteration
* Participate in the IterationPlanningMeeting to add design input to estimation and prioritisation decisions, and to identify up-coming design work or issues
* Attend the IterationKickOff to explain design issues relating to the UserStories scheduled for the DevelopmentIteration
!During each DevelopmentIteration
* Be available for collaboration with the [[Developer]] team on design issues
* Work on design input for the UserStories scheduled for the next DevelopmentIteration
!After each DevelopmentIteration
* Attend the IterationRetrospective to give and solicit feedback regarding design issues and solutions from the DevelopmentIteration
!At the end of the [[TimeboxedDeliveryCycle]]
Reporting on an Agile project tends to centre on the DevelopmentIteration.
At the conclusion of each DevelopmentIteration the amount of completed functionality is recorded (an Agile metric called [[Velocity]]), for the DevelopmentIteration).
The accumulated total represents progress to date when compared to the Project Scope. This may be represented as a burn-up or burn-down chart, an example of a burn-up chart is shown below:
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/releasetrackinggraph.jpeg]]
There are many indications that the best designs for complex systems are 'emergent', in that they derive from ongoing interaction with the complex system rather than from analysis performed outside the system.
An excellent example of EmergentDesign comes in the form of DesignPatterns, which distil design strategies that have emerged in many separate environments into a common form that can be re-used. In some sense, programming languages such as Java are the product of emergent design, with each successive version being improved through the feedback of those who are actually using it.
/***
|''Name''|RevisionsCommandPlugin|
|''Description''|provides access to tiddler revisions|
|''Author''|FND|
|''Contributors''|Martin Budden|
|''Version''|0.1.8|
|''Status''|@@beta@@|
|''Source''|http://devpad.tiddlyspot.com/#RevisionsCommandPlugin|
|''CodeRepository''|http://svn.tiddlywiki.org/Trunk/association/plugins/|
|''License''|[[BSD|http://www.opensource.org/licenses/bsd-license.php]]|
|''CoreVersion''|2.4.2|
|''Keywords''|serverSide|
!Usage
Extend [[ToolbarCommands]] with {{{revisions}}}.
!Revision History
!!v0.1 (2009-07-23)
* initial release (renamed from experimental ServerCommandsPlugin)
!To Do
* strip server.* fields from revision tiddlers
* resolve naming conflicts
* i18n, l10n
* code sanitizing
* documentation
* rename?
!Code
***/
//{{{
(function() {
if(!version.extensions.ServerCommandsPlugin) { //# ensure that the plugin is only installed once
version.extensions.ServerCommandsPlugin = { installed: true };
var cmd; //# alias
cmd = config.commands.revisions = {
type: "popup",
hideShadow: true,
text: "revisions",
tooltip: "display tiddler revisions",
revTooltip: "", // TODO: populate dynamically?
loadLabel: "loading...",
loadTooltip: "loading revision list",
selectLabel: "select",
selectTooltip: "select revision for comparison",
selectedLabel: "selected",
compareLabel: "compare",
revSuffix: " [rev. #%0]",
diffSuffix: " [diff: #%0 #%1]",
dateFormat: "YYYY-0MM-0DD 0hh:0mm",
handlePopup: function(popup, title) {
stripSuffix = function(type, title) {
var str = cmd[type + "Suffix"];
var i = str.indexOf("%0");
i = title.indexOf(str.substr(0, i));
if(i != -1) {
title = title.substr(0, i);
}
return title;
};
title = stripSuffix("rev", title);
title = stripSuffix("diff", title);
var tiddler = store.getTiddler(title);
var type = this._getField("server.type", tiddler);
var adaptor = new config.adaptors[type]();
var limit = null; // TODO: customizable
var context = {
host: this._getField("server.host", tiddler),
workspace: this._getField("server.workspace", tiddler)
};
var loading = createTiddlyButton(popup, cmd.loadLabel, cmd.loadTooltip);
var params = { popup: popup, loading: loading, origin: title };
adaptor.getTiddlerRevisionList(title, limit, context, params, this.displayRevisions);
},
displayRevisions: function(context, userParams) {
var callback = function(ev) {
var e = ev || window.event;
var revision = resolveTarget(e).getAttribute("revision");
context.adaptor.getTiddlerRevision(tiddler.title, revision, context,
userParams, cmd.displayTiddlerRevision);
};
removeNode(userParams.loading);
var table = createTiddlyElement(userParams.popup, "table");
for(var i = 0; i < context.revisions.length; i++) {
var tiddler = context.revisions[i];
var row = createTiddlyElement(table, "tr");
var timestamp = tiddler.modified.formatString(cmd.dateFormat);
var revision = tiddler.fields["server.page.revision"];
var cell = createTiddlyElement(row, "td");
createTiddlyButton(cell, timestamp, cmd.revTooltip, callback, null,
null, null, { revision: revision });
cell = createTiddlyElement(row, "td", null, null, tiddler.modifier);
cell = createTiddlyElement(row, "td");
createTiddlyButton(cell, cmd.selectLabel, cmd.selectTooltip,
cmd.revisionSelected, null, null, null,
{ index:i, revision: revision, col: 2 });
cmd.context = context; // XXX: unsafe (singleton)!?
}
},
revisionSelected: function(ev) {
var e = ev || window.event;
e.cancelBubble = true;
if(e.stopPropagation) e.stopPropagation();
var n = resolveTarget(e);
var index = n.getAttribute("index");
var col = n.getAttribute("col");
while(!index || !col) {
n = n.parentNode;
index = n.getAttribute("index");
col = n.getAttribute("col");
}
cmd.revision = n.getAttribute("revision");
var table = n.parentNode.parentNode.parentNode;
var rows = table.childNodes;
for(var i = 0; i < rows.length; i++) {
var c = rows[i].childNodes[col].firstChild;
if(i == index) {
if(c.textContent) {
c.textContent = cmd.selectedLabel;
} else {
c.text = cmd.selectedLabel;
}
} else {
if(c.textContent) {
c.textContent = cmd.compareLabel;
} else {
c.text = cmd.compareLabel;
}
c.onclick = cmd.compareSelected;
}
}
},
compareSelected: function(ev) {
var e = ev || window.event;
var n = resolveTarget(e);
var context = cmd.context;
context.rev1 = n.getAttribute("revision");
context.rev2 = cmd.revision;
context.tiddler = context.revisions[n.getAttribute("index")];
context.format = "unified";
context.adaptor.getTiddlerDiff(context.tiddler.title, context,
context.userParams, cmd.displayTiddlerDiffs);
},
displayTiddlerDiffs: function(context, userParams) {
var tiddler = context.tiddler;
tiddler.title += cmd.diffSuffix.format([context.rev1, context.rev2]);
tiddler.text = context.diff;
tiddler.fields.doNotSave = "true"; // XXX: correct?
if(!store.getTiddler(tiddler.title)) {
store.addTiddler(tiddler);
}
var src = story.getTiddler(userParams.origin);
story.displayTiddler(src, tiddler);
},
displayTiddlerRevision: function(context, userParams) {
var tiddler = context.tiddler;
tiddler.title += cmd.revSuffix.format([tiddler.fields["server.page.revision"]]);
tiddler.fields.doNotSave = "true"; // XXX: correct?
if(!store.getTiddler(tiddler.title)) {
store.addTiddler(tiddler);
}
var src = story.getTiddler(userParams.origin);
story.displayTiddler(src, tiddler);
},
_getField: function(name, tiddler) {
return tiddler.fields[name] || config.defaultCustomFields[name];
}
};
} //# end of "install only once"
})();
//}}}
A period of time at the beginning of the [[TimeboxedDeliveryCycle]], dedicated to preparing for commencing the first DevelopmentIteration.
When a team is separated by distance, for example a team split between London and Belfast.
The extreme example of this in an outsourcing project.
In Agile Outsourcing the AgileTeam are spread across several locations and also across more than one organisation. The same CorePractices are expected but the problems of building a collaborative team are that much greater.
This is a summary of our current status.
We have agreed a brief statement that will form part of the Terms Sheet for the contract discussions that are starting now with the suppliers.
The first step is to agree that there are two forms of contract for the placement of work, the Classic (waterfall) and the Agile.
Programme managers may choose either form when placing work and then adopt the most suitable form based on experience.
REVISED TERMS SHEET FOR AGILE DELIVERY
1. An Agile Delivery release is composed of short iterations, typically of 2-4 weeks each delivering a small vertical slice of the features that will be demonstrated to a customer to confirm progress and direction at the end of each iteration. The scope of the release is set at a release planning meeting which will set the dates and durations of each iteration and the initial scope of each iteration.
2. The scope of an Agile Delivery is defined as a set of user stories. The user stories contain the acceptance criteria that are used to define the completion of the work. The testing must be automated and evidence of regularly passed tests is the primary measure of progress.You must provide a ranking of the user stories so that the supplier will know what user story will bring the biggest benefit and must be delivered first.
3. Progress of an Agile Delivery is reported daily via a brief voice conference and (at least) weekly in a burn down chart showing completed tasks and estimates for remaining scoped work.
4. Deliverables from an Agile Delivery including the updated user stories and tasks will all be stored in a shared, single, version controlled repository. All deliverables including tests and test results must be available through the repository.
END - REVISED TERMS SHEET FOR AGILE DELIVERY
Changes needed to make this work include the importance of an effective "customer" located with the team. This is the CustomerProxy role that we have already identified.
In an Agile Delivery the team cannot wait for a long time to agree priority for the project and decisions need to be made quickly.
This is a walk through of an Agile project, from the TechnicalLead perspective, detailing the activities that the TechnicalLead will have a significant role in.
The HotHouse runs over days one to three of the [[TimeboxedDeliveryCycle]]. The focus of the AgileCookbook and this TechnicalLeadWalkthrough is days four to ninety.
!After the HotHouse - IterationZero, day four
After the HotHouse, from day four, you may need to do some initial work in order to be able to move into the DevelopmentIteration cycle. This tends to be more likely if you're working on a new piece of software, in a new environment, or with a largely new team. Instead of allowing this 'start-up' work to affect your first DevelopmentIteration, you may advise the ProjectManager to schedule an IterationZero. Activities that the TechnicalLead will be involved in at this stage are:
* Ensuring that the development environment is set up, so that the [[Developer]] team will be able to work productively from the first DevelopmentIteration. In particular the ContinuousIntegration and SourceControlRepository should be a focus for the TechnicalLead during IterationZero.
* Providing technical input and feedback in the construction of the MasterStoryList, particularly in assisting with sizing the UserStories. It is important that each UserStory should be decomposed until it could be developed within a period of a week if possible.
* Determine a BaselineEstimate for each UserStory in the MasterStoryList, these are used by the ProjectManager for ProjectTracking. It is possible to estimate only a representative sample and extrapolate over the rest - however this only works if all stories can be reasonably expected to be of similar size.
* Help the [[Customer]] in PrioritisingRequirements according to ensure that any technical considerations are taken into account. The priorities should be based on delivering BusinessValue as early as possible, so you may need to consider how you might evolve the design in order to allow early delivery of WorkingSoftware.
!Before each DevelopmentIteration
* Participate in the IterationPlanningMeeting as the representative of the [[Developer]] team. The TechnicalLead role in this meeting is to validate that the proposed UserStories will be able to be developed in the coming DevelopmentIteration. Having technical input at this stage of the process, before the UserStories are elaborated helps to avoid costly rework by the BusinessAnalyst team.
* Participate in the IterationKickOff along with the rest of the project team.
!During each DevelopmentIteration
* Attend the DailyStandUp meeting, specifically the TechnicalLead should be looking for any technical issues that are impeding development.
* Help the [[Developer]] team to resolve any design issues that may arise
* Verify that appropriate [[Developer]] specific AgilePractices are being followed
* Incorporate feedback from the previous IterationRetrospective
!After each DevelopmentIteration
* Confirm that the iteration has delivered WorkingSoftware with passing AutomatedAcceptanceTests
* Participate in the IterationRetrospective and encourage [[Developer]] team members to suggest process improvements
!At the end of the [[TimeboxedDeliveryCycle]]
* Release the cumulative WorkingSoftware built up during previous iterations.
http://osmosoft.com/ More info about osmosoft can be found here
Each UserStory has a BusinessValue assigned to it. This is the measure of the business benefit achieved by delivering the functionality of the UserStory in a piece of WorkingSoftware.
Ideally this would represent the expected ROI that would be added by the implementation of the UserStory. In practice this may be difficult to achieve and the best that can be done is to allocate relative weights to the UserStories. Both serve the purpose of giving some indication as to the expected value of the UserStory, and can therefore be used to assist with prioritisation decisions.
When a team is working at a SustainablePace, they will be able to maintain a consistent level of productivity over the lifetime of the project. If a team is working at a pace which is not sustainable, they may neglect important activities, which would impact productivity in the future.
!Who should be involved?
The whole team, including the [[Customer]] and the ProjectManager should work at a SustainablePace.
!When should it be done?
SustainablePace should be maintained throughout the project, however there may be short periods where more effort may be required. If these periods of increased effort become regular, it is a symptom that the project goals are too agressive.
!What are the benefits?
* The ProjectManager will be able to plan future DevelopmentIteration based on YesterdaysWeather. Confidence in plans will be increased as the team demonstrates this reliability.
!Are there any prerequisites?
!How has this been done elsewhere?
ThoughtWorks strongly encourages their clients to accept this practice. As one example: A large, London-based, financial services provider ensures that everybody observes a 40-hour week. This ensures that everybody is keen and motivated when they need to be.
This is discussed at [[Industrial XP|http://industrialxp.org/sustainablePace.html]]
!Common pitfalls
Team members who become accustomed to the benefit of fixed working hours, may be reluctant to "sprint" occasionally. They need to be aware that they are still responsible for delivering and need to make additional effort as required.
Automated tests which run with all the integration points hooked up.
Generally integration points are stubbed out (see ServiceStub) for other automated tests in order to speed test execution and avoid reliance on external systems.
Refers to the process of determining the high level requirements of the system. These are expressed in the form of high level UserStories.
!Accelerate - the new agile process
Accelerate - ac-cel-er-ate v. tr.:
To increase the speed of. To cause to occur sooner than expected.
To cause to develop or progress more quickly
An example iterative 90-day development process:
* Programmes (and projects within them) work in 90-day cycles.
Hot Houses may be held at the start of each cycle. They transform prioritised business problems into working prototypes that demonstrate a feasible solution. From the prototypes, a solution to be implemented is agreed. This solution must be compliant with known business constraints and able to be delivered by the committed level of resources within 90 days.
* Programmes and projects are accountable to deliver measurable business benefit within each iteration. The areas for improvement (the business problems) and the measures to be used for assessing the improvement are set before each iteration; the solution to be implemented in the iteration is agreed at the Hot House; the specific targets for improvement are set as soon as possible after the Hot House; the degree to which targets have been attained is assessed by the Post-implementation Review (PIR) of each iteration.
Development teams use agile working practices such as ContinuousIntegration, TestDrivenDevelopment, user involvement, and automated test. Early demonstration of functionality reduces the risk of inappropriate or unfeasible designs being discovered late in the cycle. Priority-based planning within 2-4 week timeboxes provides visibility of progress (measured in working functionality) and helps maintain delivery dates even when scope is changed.
//{{{
merge(config.macros.timeline,{
dateFormat: "DD MMM YYYY"});
config.macros.timeline.handler = function(place,macroName,params)
{
var field = params[0] ? params[0] : "modified";
//var tiddlers = store.reverseLookup("tags","excludeLists",false,field);
var tiddlers = [];
store.forEachTiddler(function(title, tiddler){
if (!tiddler.isTagged('excludeLists') && !tiddler.isTagged('systemConfig')) {
tiddlers.push(tiddler);
}
});
if (field) {
tiddlers.sort(function(a, b){
return a[field] < b[field] ? -1 : (a[field] == b[field] ? 0 : +1);
});
}
var lastDay = "";
var last = params[1] ? tiddlers.length-Math.min(tiddlers.length,parseInt(params[1])) : 0;
var dateFormat = params[2] ? params[2] : this.dateFormat;
for(var t=tiddlers.length-1; t>=last; t--) {
var tiddler = tiddlers[t];
var theDay = tiddler[field].convertToLocalYYYYMMDDHHMM().substr(0,8);
var ul = document.createElement("ul");
if (t % 2 == 0) {
ul.setAttribute('class','lineEven');
ul.setAttribute('className','lineEven');
}
else{
ul.setAttribute('class','lineOdd');
ul.setAttribute('className','lineOdd');
}
place.appendChild(ul);
createTiddlyElement(ul, "li", null, "listLink").appendChild(createTiddlyLink(place, tiddler.title, true));
span = createTiddlyElement(ul,"span",null,"timelineDetail");
span.innerHTML='last edited by ';
var name = tiddler.modifier.split("@");
span.innerHTML = span.innerHTML + name[0];
span.innerHTML = span.innerHTML + ' on ';
var Tdate = tiddler.modified;
span.innerHTML = span.innerHTML + tiddler.modified.formatString('ddd DD at hh:mm');
span2 = createTiddlyElement(ul,"span2",null,"preview");
var tText = tiddler.text;
var codePattern = /\{\{([^\}]*)\}\}\}/;
//var codePattern = /\{\{/;
tText = tText.replace(codePattern,'');
span2.innerHTML = '<br />' + tText.substring(0,45);
}
};
//}}}
From the BusinessAnalyst point of view, the most significant changes from a more traditional approach are the focus on progressively ElaboratingRequirements in each DevelopmentIteration, using UserStories to express requirements, and a greater level of direct interaction and feedback from the [[Developer]], [[Designer]] and [[Tester]] teams.
A BusinessAnalyst often acts as a CustomerProxy on an Agile project.
Things that are likely to be different:
* Progressively ElaboratingRequirements instead of detailed up-front analysis
* Decomposing requirements into UserStories
* Defining AcceptanceCriteria that can used to build AutomatedAcceptanceTests
* Ensuring that the inventory of detailed UserStories is kept as low as possible - thus LoweringTheCostOfChange
* Favouring RespondingToChange to maximise delivered BusinessValue over mandating Change Requests
* Working in short iterations, delivering UserStories for every DevelopmentIteration
* Acting as the CustomerProxy, doing ProgressiveSignOff of completed UserStories
Things that are likely to stay the same:
* Deep understanding of the business process and priorities
* Ability to act as a facilitator in dialogue between technical and business stakeholders
The BusinessAnalystWalkthrough provides more detail on activities of a BusinessAnalyst within an Agile team during the [[TimeboxedDeliveryCycle]].
!Project Team Focus
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/projectteamfocus.jpeg]]
!Anatomy of an Iteration
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/AnatomyOfAnIteration.jpeg ]]
!Iteration Planning
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/iterationplanning.jpeg]]
!Iteration Kick Off Meeting
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/iterationkickoff.jpeg]]
!Development Iteration
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/duringtheiteration.jpeg]]
!Iteration Close Meeting
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/iterationclosemeeting.jpeg]]
Test Driven development, where automated tests are written before application code. These tests are run by developers on their workstation as they complete tasks - this allows them to be confident that they have not inadvertently broken existing functionality.
The safety net of tests also allows large scale [[Refactoring]] of the application to be made with little risk if it is deemed necessary, allowing design improvements discovered late in the development process to be retrospectively applied with minimal cost;
The retrospective helps the team to reflect on the last iteration and to plan change for the next iteration. It is conducted without management being involved so that all participants can speak their mind -- critique of management is not uncommon. Any topic is applicable and being addressed by the team and it is decided how to handle it in the future. The main goal is to improve the team dynamics.
A Star Fish diagram is often used to classify proposed changes:
* Keep Doing -- Things that are going well
* Start Doing -- Things that should be given a try
* Stop Doing -- Things that should be avoided in the future
* Less Off -- Reduce the amount of work/time spent on
* More Off -- Increase the amount of work/time spent on
The following principles form the foundation of the AgileManifesto, and provide context for the practices outlined in this AgileCookbook.
* Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
* Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
* Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
* Business people and developers must work together daily throughout the project.
* Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
* The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
* Working software is the primary measure of progress.
* Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
* Continuous attention to technical excellence and good design enhances agility.
* Simplicity, the art of maximizing the amount of work not done, is essential.
* The best architectures, requirements, and designs emerge from self-organizing teams.
* At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
AutomatedAcceptanceTests are created from the AcceptanceCriteria for each UserStory and are used as a guide by the [[Developer]] to ensure that effort is focussed on only what is required to deliver the functionality for that UserStory.
AutomatedAcceptanceTests is one of the Agile CorePractices.
During an DevelopmentIteration, the UserStories selected for development in the next DevelopmentIteration will have their [[Narrative]] and AcceptanceCriteria elaborated by the BusinessAnalyst and [[Tester]] teams in collaboration with the [[Customer]]. The [[Customer]] specifies AcceptanceCriteria as scenarios to test when a UserStory has been correctly implemented.
A story can have one or many AcceptanceCriteria scenarios, whatever would be required for the [[Customer]] to 'accept' that the functionality has been delivered. The [[Customer]] or [[CustomerProxy]] manually verifies that each of the AcceptanceCriteria has been satisfied in the process of ProgressiveSignOff of the UserStories as they are delivered. A UserStory is not considered to have been successfully delivered unless it passes all of the AcceptanceCriteria.
AutomatedAcceptanceTests are created from the AcceptanceCriteria for each UserStory. This may be done by the [[Developer]] team at the very start of the DevelopmentIteration, as it can be quite valuable to have an automated test for the developer to use during development. In other cases the AutomatedAcceptanceTests are developed by the [[Tester]] team in parallel with development, and are executed at the end of the DevelopmentIteration. As with most feedback mechanisms, it's important that the feedback be delivered in a timely fashion. Acceptance tests which take months to be automated are much less effective in ensuring ongoing quality than tests which are able to be run during development of that functionality.
AutomatedAcceptanceTests can be included in the ContinuousIntegration build. Prior to the completion of a UserStory the corresponding test will of course not pass, since it's by definition testing functionality that is yet to be delivered. Because of this teams often run the AutomatedAcceptanceTests in a separate Test Suite which does not BreakTheBuild if it fails.
Once the UserStory has been completed, AutomatedAcceptanceTests are often re-used as AutomatedFunctionalTests in the ContinuousIntegration build. At this stage they serve a Regression Test function and should be moved into a Test Suite that does BreakTheBuild on failure.
Additional information appended to a story, or written on UserStory, which provides much more detail than the story itself. The following can be included in a [[Narrative]]. Note that some attributes are mandatory:
* AcceptanceCriteria (Mandatory)
* Screen shots
* Items out of scope
* Process Flows
* BaselineEstimate (Mandatory)
* Data Migration
* Non-functional requirements
Automated tests that confirm that the application fulfils its intent in terms of the delivery of function, and so value, to its users.
Prefix - Large projects with many developers should be broken down into sub-teams. Experience shows that these sub-teams are most effective where there are between 2 and 20 developers...todo - more here
An Agile Team would be composed appropriately for the task at hand. However a broad guideline used by ThoughtWorks is as follows:
* [[Developer]]: 2 - 20;
* BusinessAnalyst: 1 for every 3 Developers;
* [[Designer]]: 1 for every 10 Developers;
* TechnicalLead: 1 per team;
* [[Tester]]: 1 for every 3 Developers;
* IterationManager: 1 per team;
* ProjectManager: 1 (may be responsible for more than one team);
* [[Customer]]: 1 or more if possible (may be shared across teams);
Other roles that may be included, especially if the team is new to Agile are AgileCoach and AgileEnablers.
As a project progresses, the balance of roles on the team may need to be adjusted to improve efficiency. Typically the need for this rebalancing becomes apparent when one part of the process is not keeping up with the others. For example, if not enough [[UserStories]] are available for the IterationKickOff, then more [[BusinessAnalyst]]s may be required. An important alternative to consider is that possibly the [[BusinessAnalyst]]s are going into too much detail in elaborating the UserStories, and that it might be more efficient to allow less detail and thereby get a greater throughput. In either case - the rule is to make one process or team change at a time and observe the results.
The BaselineEstimate for a UserStory is used for ProjectTracking and to calculated [[Velocity]]. The most important characteristic of a BaselineEstimate is that it be consistent, allowing YesterdaysWeather to be used to extrapolate progress. For this reason it is important to derive a BaselineEstimate for any new UserStories by referring to the BaselineEstimate for similarly sized pieces of work.
The units of measurement of the BaselineEstimate are not important for the purpose of ProjectTracking, since what is tracked is the rate at which work is delivered per DevelopmentIteration. this is analogous to measuring fuel economy in miles/gallon or kilometres/litre, if your car made 10 the last three times you drove it then you can reasonably expect it will do 10 this time... the actual units of measure are not important for predicting so long as they are consistent.
Before the [[TimeboxedDeliveryCycle]] begins:
* "What is the problem we're trying to solve, and the business benefit we hope will result?" :- HighLevelStoryFinding
At the beginning of the [[TimeboxedDeliveryCycle]]:
* "What is the scope of the project?" :- MasterStoryList
* "What is the size of the project?" :- BaselineEstimate
* "What should we work on first?" :- ReleasePlanning
During the [[TimeboxedDeliveryCycle]]:
* "What will the Team be working on in the next DevelopmentIteration?" :- IterationPlanning
* "How does a DevelopmentIteration start?" :- IterationKickOff
* "How does a DevelopmentIteration end?" :- IterationRetrospective
At the end of the [[TimeboxedDeliveryCycle]]:
/***
|Name|SinglePageModePlugin|
|Source|http://www.TiddlyTools.com/#SinglePageModePlugin|
|Documentation|http://www.TiddlyTools.com/#SinglePageModePluginInfo|
|Version|2.9.6|
|Author|Eric Shulman - ELS Design Studios|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides|Story.prototype.displayTiddler(), Story.prototype.displayTiddlers()|
|Options|##Configuration|
|Description|Show tiddlers one at a time with automatic permalink, or always open tiddlers at top/bottom of page.|
This plugin allows you to configure TiddlyWiki to navigate more like a traditional multipage web site with only one tiddler displayed at a time.
!!!!!Documentation
>see [[SinglePageModePluginInfo]]
!!!!!Configuration
<<<
<<option chkSinglePageMode>> Display one tiddler at a time
><<option chkSinglePagePermalink>> Automatically permalink current tiddler
><<option chkSinglePageKeepFoldedTiddlers>> Don't close tiddlers that are folded
><<option chkSinglePageKeepEditedTiddlers>> Don't close tiddlers that are being edited
<<option chkTopOfPageMode>> Open tiddlers at the top of the page
<<option chkBottomOfPageMode>> Open tiddlers at the bottom of the page
<<option chkSinglePageAutoScroll>> Automatically scroll tiddler into view (if needed)
Notes:
* The "display one tiddler at a time" option can also be //temporarily// set/reset by including a 'paramifier' in the document URL: {{{#SPM:true}}} or {{{#SPM:false}}}.
* If more than one display mode is selected, 'one at a time' display takes precedence over both 'top' and 'bottom' settings, and if 'one at a time' setting is not used, 'top of page' takes precedence over 'bottom of page'.
* When using Apple's Safari browser, automatically setting the permalink causes an error and is disabled.
<<<
!!!!!Revisions
<<<
2008.10.17 [2.9.6] changed chkSinglePageAutoScroll default to false
| Please see [[SinglePageModePluginInfo]] for previous revision details |
2005.08.15 [1.0.0] Initial Release. Support for BACK/FORWARD buttons adapted from code developed by Clint Checketts.
<<<
!!!!!Code
***/
//{{{
version.extensions.SinglePageModePlugin= {major: 2, minor: 9, revision: 6, date: new Date(2008,10,17)};
//}}}
//{{{
config.paramifiers.SPM = { onstart: function(v) {
config.options.chkSinglePageMode=eval(v);
if (config.options.chkSinglePageMode && config.options.chkSinglePagePermalink && !config.browser.isSafari) {
config.lastURL = window.location.hash;
if (!config.SPMTimer) config.SPMTimer=window.setInterval(function() {checkLastURL();},1000);
}
} };
//}}}
//{{{
if (config.options.chkSinglePageMode==undefined)
config.options.chkSinglePageMode=false;
if (config.options.chkSinglePagePermalink==undefined)
config.options.chkSinglePagePermalink=true;
if (config.options.chkSinglePageKeepFoldedTiddlers==undefined)
config.options.chkSinglePageKeepFoldedTiddlers=false;
if (config.options.chkSinglePageKeepEditedTiddlers==undefined)
config.options.chkSinglePageKeepEditedTiddlers=false;
if (config.options.chkTopOfPageMode==undefined)
config.options.chkTopOfPageMode=false;
if (config.options.chkBottomOfPageMode==undefined)
config.options.chkBottomOfPageMode=false;
if (config.options.chkSinglePageAutoScroll==undefined)
config.options.chkSinglePageAutoScroll=false;
//}}}
//{{{
config.SPMTimer = 0;
config.lastURL = window.location.hash;
function checkLastURL()
{
if (!config.options.chkSinglePageMode)
{ window.clearInterval(config.SPMTimer); config.SPMTimer=0; return; }
if (config.lastURL == window.location.hash) return; // no change in hash
var tids=decodeURIComponent(window.location.hash.substr(1)).readBracketedList();
if (tids.length==1) // permalink (single tiddler in URL)
story.displayTiddler(null,tids[0]);
else { // restore permaview or default view
config.lastURL = window.location.hash;
if (!tids.length) tids=store.getTiddlerText("DefaultTiddlers").readBracketedList();
story.closeAllTiddlers();
story.displayTiddlers(null,tids);
}
}
if (Story.prototype.SPM_coreDisplayTiddler==undefined)
Story.prototype.SPM_coreDisplayTiddler=Story.prototype.displayTiddler;
Story.prototype.displayTiddler = function(srcElement,tiddler,template,animate,slowly)
{
var title=(tiddler instanceof Tiddler)?tiddler.title:tiddler;
var tiddlerElem=document.getElementById(story.idPrefix+title); // ==null unless tiddler is already displayed
var opt=config.options;
var single=opt.chkSinglePageMode && !startingUp;
var top=opt.chkTopOfPageMode && !startingUp;
var bottom=opt.chkBottomOfPageMode && !startingUp;
if (single) {
story.forEachTiddler(function(tid,elem) {
// skip current tiddler and, optionally, tiddlers that are folded.
if ( tid==title
|| (opt.chkSinglePageKeepFoldedTiddlers && elem.getAttribute("folded")=="true"))
return;
// if a tiddler is being edited, ask before closing
if (elem.getAttribute("dirty")=="true") {
if (opt.chkSinglePageKeepEditedTiddlers) return;
// if tiddler to be displayed is already shown, then leave active tiddler editor as is
// (occurs when switching between view and edit modes)
if (tiddlerElem) return;
// otherwise, ask for permission
var msg="'"+tid+"' is currently being edited.\n\n";
msg+="Press OK to save and close this tiddler\nor press Cancel to leave it opened";
if (!confirm(msg)) return; else story.saveTiddler(tid);
}
story.closeTiddler(tid);
});
}
else if (top)
arguments[0]=null;
else if (bottom)
arguments[0]="bottom";
if (single && opt.chkSinglePagePermalink && !config.browser.isSafari) {
window.location.hash = encodeURIComponent(String.encodeTiddlyLink(title));
config.lastURL = window.location.hash;
document.title = wikifyPlain("SiteTitle") + " - " + title;
if (!config.SPMTimer) config.SPMTimer=window.setInterval(function() {checkLastURL();},1000);
}
if (tiddlerElem && tiddlerElem.getAttribute("dirty")=="true") { // editing... move tiddler without re-rendering
var isTopTiddler=(tiddlerElem.previousSibling==null);
if (!isTopTiddler && (single || top))
tiddlerElem.parentNode.insertBefore(tiddlerElem,tiddlerElem.parentNode.firstChild);
else if (bottom)
tiddlerElem.parentNode.insertBefore(tiddlerElem,null);
else this.SPM_coreDisplayTiddler.apply(this,arguments); // let CORE render tiddler
} else
this.SPM_coreDisplayTiddler.apply(this,arguments); // let CORE render tiddler
var tiddlerElem=document.getElementById(story.idPrefix+title);
if (tiddlerElem&&opt.chkSinglePageAutoScroll) {
// scroll to top of page or top of tiddler
var isTopTiddler=(tiddlerElem.previousSibling==null);
var yPos=isTopTiddler?0:ensureVisible(tiddlerElem);
// if animating, defer scroll until after animation completes
var delay=opt.chkAnimate?config.animDuration+10:0;
setTimeout("window.scrollTo(0,"+yPos+")",delay);
}
}
if (Story.prototype.SPM_coreDisplayTiddlers==undefined)
Story.prototype.SPM_coreDisplayTiddlers=Story.prototype.displayTiddlers;
Story.prototype.displayTiddlers = function() {
// suspend single/top/bottom modes when showing multiple tiddlers
var opt=config.options;
var saveSPM=opt.chkSinglePageMode; opt.chkSinglePageMode=false;
var saveTPM=opt.chkTopOfPageMode; opt.chkTopOfPageMode=false;
var saveBPM=opt.chkBottomOfPageMode; opt.chkBottomOfPageMode=false;
this.SPM_coreDisplayTiddlers.apply(this,arguments);
opt.chkBottomOfPageMode=saveBPM;
opt.chkTopOfPageMode=saveTPM;
opt.chkSinglePageMode=saveSPM;
}
//}}}
The MasterStoryList is the primary record of Project Scope. It serves as the basis for a OneTruthRepository and will be regularly updated as the project progresses. The MasterStoryList should include the following for every UserStory that is included in the current [[TimeboxedDeliveryCycle]]:
* Number - It's good to use a number since the name may change and it saves space if you're using a Story Wall.
* Name -
* Description -
* BaselineEstimate -
* Completion indicator - this could be the DevelopmentIteration number in which the UserStory was delivered.
* Release tag - In case your MasterStoryList is going to be used across more than one [[TimeboxedDeliveryCycle]] (Release), you will want to be able to indicate which UserStories are assigned to each Release.
* Status tag - sometimes you will want to delete a UserStory, perhaps after splitting it, or if it becomes redundant. A separate status tag allows you to keep track of deleted or retired UserStories.
* Date added - New UserStories will be discovered during the project, it helps with ScopeManagement to record when this happens.
Providing free and open Access to Information through:
- Hold DailyStandUp meetings
- Practice whole team collaboration where possible
- Facilitate co-location with caves and commons
- Implement on-site customer
- Install information radiators
- Whiteboards
- Posters
- Bulletin Boards
On an Agile project the team practices CollectiveOwnership of all of the source code, goals, planning, in fact of the 'whole' project. CollectiveOwnership underpins other practices such as CommonVision and PairProgramming, as well as being the driver for continuous process improvement.
!Who should be involved?
The whole team is involved in CollectiveOwnership.
!When should it be done?
Ideally CollectiveOwnership should mean that anytime a team member sees an opportunity to improve the code, or the process or anything else - they should feel empowered to address it. In some cases this might mean fixing a defect, in other cases it might mean suggesting a design [[Huddle]]. Whatever the situation - if the response to an issue is along the lines of "That's Bob's code..." then you're looking at an absence of CollectiveOwnership.
!What are the benefits?
The ability to fix problems as they are found reduces the chance that further work is based on incorrect code or requirements.
Improves productivity as there is no need to wait for any individual to resolve a problem. If specific individuals are the sole repository of information, then those individuals represent a bottleneck. "Only Bob knows how that works... he'll be back on Thursday."
CollectiveOwnership helps to lower a project's BusFactor. "Silos" of information are less likely to form and therefore the team becomes independent of individuals with all the knowledge in certain areas.
Because there is less reliance on key individuals, it becomes much easier to manage leave requests and periods of sickness.
!Are there any prerequisites?
People need to be prepared to share knowledge and accept feedback.
Some means of sharing knowledge must be available, and feedback must be given as quickly as possible.
!How has this been done elsewhere?
As a general rule, if the ContinuousIntegration build is broken, then the team collaborates to fix it.
!Common pitfalls
When everybody is responsible for maintaining the code base, some may feel that nobody is responsible for maintaining the code base. See [[Tragedy of the Commons|http://en.wikipedia.org/wiki/Tragedy_of_the_commons]].
It is not uncommon for different development tasks to impact the same areas of code. Developers encountering these conflicts, may be frustrated. This can be easily avoided by good [[Communication]].
ContinuousIntegration refers to a fully automated build and test process that allows a team to build and test their software many times a day. The first step on the way to ContinuousIntegration is sometimes a DailyBuild.
!Who should be involved?
ContinuousIntegration is typically set up by developers before development commences, If you're planning an IterationZero then this is one of the tasks that should be done at that time. There will be ongoing work involved in keeping your ContinuousIntegration build running effectively.
!When should it be done?
As the name suggests - ContinuousIntegration should be done AllTheTime.
!What are the benefits?
The benefits of ContinuousIntegration depend on what is included in the build process.
Compile :-
* Early detection of coding errors.
* Allows CollectiveOwnership, since mutually incompatible changes will be detected.
UnitTests :-
* Early detection of unintended behavioural changes at the unit level.
Deploy :-
* Early detection of deployment issues.
* Side benefit is that you by default gain AutomatedDeployment.
AutomatedFunctionalTests :- Often these are composed of AutomatedAcceptanceTests for previously delivered functionality, re-run as regression tests.
* Early detection of unintended functional changes.
AutomatedIntegrationTests :- You can have some tests which run with all the integration points hooked up, these will typically be much more fragile than tests which rely on stubbed out integration points - so you may not want to break the build if they fail. Nonetheless, they do give you early warning of incompatibilities with external systems.
CodingStandards :-
* Automated enforcement of coding standards, which assists with CommonCodeOwnership.
A coincidental benefit of ContinuousIntegration is often improved application performance - since keeping the duration of the build as short as possible tends to drive the [[Developer]] team to detect and fix observable performance issues throughout the project. Some teams actually include specific timed tests in the ContinuousIntegration build to detect degradations in performance. This is an example of using ContinuousIntegration to assist with meeting a Non Functional Requirement.
!Are there any prerequisites?
* Some means of performing the CI build and notifying success or failure.
* An IDE independent build.
* One Source Control Repository, with __all__ source files, including data and configuration, kept in it.
* A dedicated CI environment, this is more to do with ensuring independence from developer machine configuration than processing power.
!How has this been done elsewhere?
Although ContinuousIntegration is a very common practice, used on projects large and small, the actual detail of the ContinuousIntegration process tends to be quite project specific. Tools like CruiseControl are quite mature, and so issues with ContinuousIntegration tend to be related to the underlying code base and the build script being used. Because these areas are best understood by the developers on the project, it's generally better to have the ContinuousIntegration process under the control of the project team. It can be valuable to have a BuildMaster who advises the team on initial setup, however centralising the ContinuousIntegration function has proven to be counterproductive due to a lack of intimate project specific knowledge.
Keeping your build environment independent of external resources is very important. It's better to stub out an external integration point and have a build that runs quickly and reliably, than to hook up the external system and have your build break randomly because of outages or connectivity issues. You may choose to include some AutomatedIntegrationTests which do connect to external systems, however you may want to reduce failures to the level of warning rather than fatal errors.
There is a lot of useful information around ContinuousIntegration available on the web. Some recommended sites are listed below:
The C2 wiki: http://c2.com/cgi/wiki?ContinuousIntegration
Martin Fowler: http://www.martinfowler.com/articles/continuousIntegration.html
For .Net: http://www.martinfowler.com/articles/continuousIntegration.html
For C++ and Com: http://www.martinfowler.com/articles/ciWithCom.html
!Common pitfalls
Sometimes the length of the build process increases to the point where feedback is no longer provided on a timely basis. This can be countered with constant effort from the whole team.
The AgileManifesto expressed the Agile values to be:
* IndividualsAndInteractions //over// processes and tools
* WorkingSoftware //over// comprehensive documentation
* CustomerCollaboration //over// contract negotiation
* RespondingToChange //over// following a plan
Typically this covers situations where an iterative approach is more difficult because:
* High cost of change.
* Task cannot be decomposed into iteration-sized pieces of work.
* External teams which are not involved in the same iterative cycle.
* todo - more to come...
- project as part of a program of work - releases, dependencies;
- decision maker involvement is key;
todo - add paragraph about non-development issues and activities - hardware prov, training, cutover, maintenance.
|''Description:''|Visual TW |
|''Type:''|tiddlywiki|
|''URL:''|http://visualtw.ouvaton.org/VisualTW.html|
|''Workspace:''|Main|
From a Developer's point of view, the most significant changes from a more traditional approach are the focus on SimpleDesign, communication, collaboration and delivering business value in each DevelopmentIteration in the form of [[WorkingSoftware]].
Developers only get to enjoy the benefits of agile projects if they take the responsibilities of:
* getting more involved in design. The specifications produced by BusinessAnalysts in an agile project will not be accompanied by the level of design detail usually prepared by a [[Designer]]. Each Developer needs to be aware of the architectural considerations of each UserStory.
* exercising CollectiveOwnership of the code base and the processes. All members of the team are expected to behave as Good Citizens.
* writing tests to prevent regression. The Automated Build and ContinuousIntegration will not provide the confidence they are intended to, if the tests do not verify that the software behaves as expected.
* implementing a SimpleDesign and [[Refactoring]] instead of trying to cater for all possible eventualities up front.
* communicating clearly with the other members of the team.
* writing clear, maintainable code. In traditional projects, code is never read after it is written, as all functionality has been built in up front. The iterative approach results in code being read often, as features are implemented incrementally. For this reason, care needs to be taken to write simple clear code that any Developer could understand.
Contrary to AgileMyths, developing with XP requires discipline, awareness and sensitivity.
Things that are likely to be different:
* Communication with the [[Customer]], ProjectManager, [[BusinessAnalyst]], [[Designer]] and [[Tester]]. Quality of communication is more important than quantity. Clear and timely communication as required is preferred to the mandatory documentation familiar to many projects.
* Executable specifications in the form of AutomatedAcceptanceTests as a means of communication to other developers.
* PairProgramming can be challenging to Developers accustomed to working alone. Many fear that pairing will be used as a means to assess their skills or knowledge.
* You will be able to take leave as a result of the lessened reliance on key individuals promoted by [[CollectiveOwnership]].
* Your team will work at a [[SustainablePace]]. This is the result of the team taking responsibility for estimates, instead of the individual.
* You will have more opportunity to learn through the collaborative process.
Things that are likely to stay the same:
* We struggled to find things that would stay the same, apart from the fact that you will still be coding.
The DeveloperWalkthrough provides more detail on activities of a Developer within an Agile team during the [[TimeboxedDeliveryCycle]].
todo: AgileDeveloperDay
When two or more people sit down with the intention of critically inspecting a piece of code.
In order to be effective, a CodeReview should be treated as an opportunity for learning and sharing experience, rather than a pass/fail test.
A ServiceStub is used to take the place of an external system to allow testing where the external system is unavailable. It can also be used to allow more efficient testing of dependent components without the overhead of calling out to the external system, or to allow the 'injection' of specific responses for the purpose of testing failure scenarios that are difficult to create in the live system.
A ServiceStub is usually hidden behind some sort of ServiceInterface, which abstracts the external system.
Examples of where a ServiceStub may be useful:
* Testing the system's handling of database exceptions, such as roll-back.
* Allowing development to continue while waiting for another external system to be delivered, so long as the ServiceInterface is well defined.
A common pitfall experienced when using ServiceStub is over-elaboration of the stub itself. The stub should be as 'dumb' as possible, to the extent of requiring its behaviour to be injected by an automated test, or at least a small pre-canned set of responses given known inputs. Coding logic that mimics the 'real' service is generally not a good idea. Firstly it implies that your application needs to know something about the implementation, which consequently implies that you haven't really isolated your code from the external system. Secondly, it's additional code that has to be maintained and fixed if it goes wrong - which works against LoweringTheCostOfChange.
The ServiceStub pattern is described in the book [[Patterns of Enterprise Application Architecture|http://www.amazon.com/exec/obidos/tg/detail/-/0321127420/ref=pd_sxp_f/104-5429656-3021524?v=glance&s=books]], by Martin Fowler et al.
/***
|''Name:''|DiffFormatterPlugin|
|''Description:''|Extension of TiddlyWiki syntax to support Diff text formatting|
|''Author:''|Martin Budden (mjbudden (at) gmail (dot) com)|
|''Source:''|http://www.martinswiki.com/#DiffFormatterPlugin |
|''CodeRepository:''|http://svn.tiddlywiki.org/Trunk/contributors/MartinBudden/formatters/DiffFormatterPlugin.js |
|''Version:''|0.0.3|
|''Date:''|Sep 11, 2009|
|''Comments:''|Please make comments at http://groups.google.co.uk/group/TiddlyWikiDev |
|''License:''|[[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]] |
|''~CoreVersion:''|2.1.0|
This is an early release of the DiffFormatterPlugin, which extends the TiddlyWiki syntax to support Diff
text formatting.
The Diff formatter is different from the other formatters in that Tiddlers are not required to be
tagged: instead the Diff format adds formatting that augments TiddlyWiki's format.
The Diff formatter adds the following:
# ^+ for added
# ^- for removed
# ^"""@@ """, """--- """ and """+++ """ for special markers
Please report any defects you find at http://groups.google.co.uk/group/TiddlyWikiDev
!StyleSheet
.viewer .removed { background: #fdd; }
.viewer .added { background: #dfd; }
!Code
***/
//{{{
// Ensure that the DiffFormatterPlugin is only installed once.
if(!version.extensions.DiffFormatterPlugin) {
version.extensions.DiffFormatterPlugin = {installed:true};
if(version.major < 2 || (version.major == 2 && version.minor < 1)) {
alertAndThrow('DiffFormatterPlugin requires TiddlyWiki 2.1 or later.');
}
diffFormatter = {}; // 'namespace' for local functions
diffFormatter.init = function() {
var stylesheet = store.getTiddlerText(tiddler.title + "##StyleSheet");
if(stylesheet) { // check necessary because it happens more than once for some reason
config.shadowTiddlers["StyleSheetDiffFormatter"] = stylesheet;
store.addNotification("StyleSheetDiffFormatter", refreshStyles);
}
};
diffFormatter.added = {
name: 'diffAdded',
match: '^\\+',
termRegExp: /(\n)/mg,
handler: function(w)
{
var e = createTiddlyElement(w.output,'span',null,'added');
w.subWikifyTerm(e,this.termRegExp);
createTiddlyElement(w.output,'br');
}
};
diffFormatter.removed = {
name: 'diffRemoved',
match: '^-',
termRegExp: /(\n)/mg,
handler: function(w)
{
var e = createTiddlyElement(w.output,'span',null,'removed');
w.subWikifyTerm(e,this.termRegExp);
createTiddlyElement(w.output,'br');
}
};
diffFormatter.charDiff = {
name: 'diffChars',
match: '^(?:@@|[+-]{3}) ',
lookaheadRegExp: /^(?:@@|[+-]{3}) .*\n/mg,
handler: function(w)
{
this.lookaheadRegExp.lastIndex = w.matchStart;
var lookaheadMatch = this.lookaheadRegExp.exec(w.source);
if(lookaheadMatch && lookaheadMatch.index == w.matchStart) {
w.nextMatch = this.lookaheadRegExp.lastIndex;
}
}
};
// add new formatters
diffFormatter.init();
config.formatters.push(diffFormatter.added);
config.formatters.push(diffFormatter.removed);
diffFormatter.replaceFormatter = function()
{
for(var i=0; i<config.formatters.length; i++) {
if(config.formatters[i].name == 'characterFormat') {
config.formatters.splice(i,0,diffFormatter.charDiff);
break;
}
}
};
diffFormatter.replaceFormatter();
}// end of 'install only once'
//}}}
The [[Customer]] in an Agile project is involved to a greater degree than in traditional projects. Although this may seem an overhead, there are a number of benefits around greater control that make this worth while.
It is also part of the greater CustomerCollaboration approach in an Agile project.
The PlanningGame is a time-boxed event where UserStories are confirmed, prioritised, estimated and planned.
!Who should be involved?
Everybody who has a direct involvement in the project. SubjectMatterExperts need to be there in order to provide sufficient information about the user stories that they can be understood and estimated. The customer or product owner needs to attend in order to confirm which user stories are more important, while the developers need to be there as they are the ones who will estimate the user stories and also commit to an iteration of work.
!When should it be done?
Before development commences, at the HotHouse. The PlanningGame should be repeated before each DevelopmentIteration as an IterationPlanningMeeting, and again at the IterationKickOff.
!What are the benefits?
Getting everyone together and explicitly confirming what the requirements are and how relatively important they are allows everyone to see the scope of the project. By everyone having an input face-to-face, increases the level of commitment throughout the team. By delegating responsibility for the estimation of the iteration to the developers, the project is getting the most realistic estimates it can.
!Are there any prerequisites?
Having the right people involved is of vital importance.
It helps to have the UserStories represented in some medium that allows team members to move them around - Index cards are excellent for this purpose.
!How has this been done elsewhere?
In this case - a picture says a thousand words:
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/planninggame.jpeg]]
!Common pitfalls
* Resist the temptation to have the ProjectManager do the estimation or prioritisation of UserStories. It's much more effective to have the [[Developer]] team estimate and the [[Customer]] prioritise.
* If the [[Developer]] team can't estimate a UserStory then maybe it is not explicit enough, or it could need further decomposition. Don't let one UserStory bog you down, put it aside and schedule some further analysis - remember, it's only a short time until the next iteration, so it can usually wait.
BusFactor is a term used to describe the degree to which a team depends on key individuals. It refers to the phrase "What would we do if ... was hit by a bus?".
There are a set of [[AgileRoles]] in an Agile Project.
[[Introduction]]
AgileOverview
CorePractices
AgileRoles
[[TimeboxedDeliveryCycle]]
FurtherReading
ReleaseNotes
[[Help]]
<<newTiddler label:"New Entry" text:"text for agilecookbook.com entry" title:"New Entry" tag:"">>
[[Recent Activity]]
<<search>>
[img[http://agilecookbook.com/TW.png][http://www.thoughtworks.com/]]
[img[http://agilecookbook.com/logo_75x36.gif][http://www.bt.com]]
[[Login|http://agilecookbook.com/challenge]]
This is one of the four fundamental tenets of the AgileManifesto.
WorkingSoftware is to be preferred over documentation.
The idea is that if you can demonstrate requirements fulfilled in working software (accompanied by passing AutomatedAcceptanceTests) then this is more valuable than producing documentation.
Indicates that the linked activity is considered a foundation practice of Agile, the AgilePractices.
This is one of the four fundamental tenets of the AgileManifesto.
CustomerCollaboration is preferred over contract negotiation.
<<timeline "modified" "10" "ddd, YYYY-0MM-0DD">>
This is a walk through of an Agile project, from the BusinessAnalyst perspective, detailing the activities that the BusinessAnalyst will have a significant role in.
The HotHouse runs over days one to three of the [[TimeboxedDeliveryCycle]]. The focus of the AgileCookbook and this BusinessAnalystWalkthrough is days four to ninety.
!After the HotHouse - IterationZero, day four
* Story finding, building MasterStoryList
* Facilitate further post-HotHouse requirements workshops
* Building a [[Narrative]] and AcceptanceCriteria for highest priority UserStories, for the first DevelopmentIteration
!Before each DevelopmentIteration
* IterationPlanningMeeting - Assist the [[Customer]] in a PlanningGame to determine which UserStories will be elaborated during the coming DevelopmentIteration
* IterationKickOff - present each UserStory, with [[Narrative]] and AcceptanceCriteria
!During each DevelopmentIteration
* Elaborate UserStories for the coming DevelopmentIteration
* Act as CustomerProxy to resolve issues for the [[Designer]], [[Developer]] and [[Tester]] teams
* Help to ensure that the CommonVision is maintained
* Validate the AutomatedAcceptanceTests created by a [[Developer]] from the AcceptanceCriteria
* ProgressiveSignOff of completed UserStories with or on behalf of the [[Customer]]
* Participate in the DailyStandUp to communicate progress and issues to the team
!After each DevelopmentIteration
* Validate that completed UserStories pass their AcceptanceCriteria, possibly raising as defects any minor issues
* Participate in the IterationRetrospective
!At the end of the [[TimeboxedDeliveryCycle]]
Most [[Developer]]s know a SourceControlRepository as a tool which allows a team to work safely on a set of source files.
For the [[Developer]] the SourceControlRepository provides a number of benefits irrespective of whether you're using AgilePractices or not.
* It provides a place to store your source code.
* It provides a historical record of what you have done over time.
* It can provide a way for developers to work on separate tasks in parallel, merging their efforts later.
* It can provide a way for developers to work together without getting in each others' way
On an Agile project, the SourceControlRepository is used to great effect - underpinning such AgilePractices as CollectiveOwnership, ContinuousIntegration, [[Refactoring]] and CommonVision.
We strongly recommend that you consider putting more than just your source code into the SourceControlRepository. Put your build script in, any supporting documents, your ProjectWiki - anything you rely on that would take time and cost money to replace should be in the SourceControlRepository. Even though binary files such as Word documents cannot be worked on by more than one person at a time, having them in your SourceControlRepository ensures that there is never any misunderstanding about which is the 'current' copy, and allows you to retrieve your 'last-best' version in case of accidental change or file corruption.
Some team members may be unused to working with a SourceControlRepository. It's important to recognise this and provide support - often the [[Developer]] team can assist with this.
This Cookbook was kept in a SourceControlRepository while under development - and it certainly saved a significant amount of rework on a number of occasions.
This is a Cookbook designed as a guide to applying Agile practices within the [[TimeboxedDeliveryCycle]]. Please ensure that you read the CorePractices as these are mandated for Agile Delivery in the 90 Day cycle.
It's important to be aware that there are many approaches to Agile software delivery, and that all of these emphasise the adaptation of process to suit the specific problem at hand. You should take the time to read the AgileManifesto, and the supporting AgilePrinciples to understand the context within which this guide sits.
The focus of the Cookbook is on days 4 to 90 of the [[TimeboxedDeliveryCycle]], effectively picking up directly after the end of the hothouse. The aim is to provide practical advice throughout the remainder of the delivery cycle. This advice is constructed to complement existing information about HotHouse, AccelerateFramework and [[Tools]].
The Cookbook is not intended to be a general survey or guide to Agile practices or methodologies, for that we suggest you look at [[FurtherReading]]. Rather it is an approach to implementing the principles described in the AgileManifesto.
The Cookbook will provide answers to the following questions:
* "What should I be doing?" :- Identifies how each [[AgilePractice]] should be undertaken at each stage - such as a focus on business value and a test-first approach. The minimum starting set of AgilePractices to be adopted when introducing Agile to your projects is described in [[CorePractices]].
* "How do I do it?" :- Provides pragmatic step-by-step advice to AgileRoles and the way of working across the [[TimeboxedDeliveryCycle]] and recommend Agile activities/devices which should be followed to help achieve success.
* "What do I bring to the process?" :- The cookbook is structured around each of the AgileRoles in the development process, and the activities in which they will be involved.
* "How has it been done elsewhere?" :- Provides supporting information/collateral such as CaseStudies from peer organisations to help explain the reasons for making the change to Agile and to demonstrate how to put Agile into practice.
* "How do I get help?" :- See the [[Help]] or visit the google group (http://groups.google.com/group/agilecookbook) where questions can be logged to be answered by peers who have experienced similar situations or by experienced moderators.
!Background
The material for the AgileCookbook has been seeded by BT and Thoughtworks.
The content is licensed under the [[Creative Commons Attribution 3.0 license][http://creativecommons.org/licenses/by/3.0/us/]]
[[DefaultTiddlers]]
CruiseControl is a framework for a continuous build process. It includes, but is not limited to, plugins for email notification, Ant, and various source control tools. A web interface is provided to view the details of the current and previous builds.
For further information on CruiseControl:
the original Java CruiseControl: http://cruisecontrol.sourceforge.net/
CruiseControl.Net: http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET
Agile development emphasises the regular delivery of WorkingSoftware that provides BusinessValue. In order to enable frequent delivery of BusinessValue, it is necessary to schedule frequent releases of the software. The [[TimeboxedDeliveryCycle]] and a DevelopmentIteration are both examples of ShortReleases.
!Who should be involved?
The whole team is involved in participating in ShortReleases as part of the DevelopmentIteration cycle.
!When should it be done?
The output of each DevelopmentIteration should be WorkingSoftware that could be released if required. In practice the overheads of actually deploying a new system into production generally mean that actual releases are scheduled somewhat less frequently - the [[TimeboxedDeliveryCycle]] culminates in the delivery of WorkingSoftware for release.
!What are the benefits?
Early delivery of BusinessValue means that the benefit is derived earlier.
!Are there any prerequisites?
Being able to decompose the problem into parts that could be delivered in ShortReleases.
!How has this been done elsewhere?
The ideal Agile project delivers WorkingSoftware into production at the end of each DevelopmentIteration. This is not an unnattainable goal, and is reasonably common in high-value systems like Investment Banking trading systems. It's also quite often achieved by teams maintaining systems which were developed using Agile methods and therefore have substantial ContinuousIntegration and automated test/deploy infrastructure to enable the confidence to allow such fast-paced delivery.
In practice, many types of systems are not delivered into production in this way. Particularly where the system is a new product which must have some minimum set of functionality before it can be deployed. However in all cases Agile projects deliver WorkingSoftware at least into some test environment at the end of each DevelopmentIteration. This regular delivery is vital if the [[Customer]] is to be confident of progress, and to solicit feedback and allow early detection of defects.
!Common pitfalls
Purpose: To ensure the success of the project has been evaluated and process improvements captured
When it should pass: by the end of the PIR (to be held as soon as possible after the 90-day Iteration)
What’s needed:
*System deployed to the agreed environment
*Metrics gathered on improvement
*Results compared with targets
*Lessons learned gathered
*Specific checklists will be programme/project dependent
This is a Cookbook designed as a guide to applying Agile practices within the [[TimeboxedDeliveryCycle]]. It is intended that this will become the primary source of practical and pragmatic advice for programmes taking on Agile delivery.
It's important to be aware that there are many approaches to Agile software delivery, and that all of these emphasise the adaptation of process to suit the specific problem at hand. You should take the time to read the AgileManifesto, and the supporting AgilePrinciples to understand the context within which this guide sits.
The focus of the Cookbook is on days 4 to 90 of the [[TimeboxedDeliveryCycle]], effectively picking up directly after the end of the hothouse. The aim is to provide practical advice throughout the remainder of the delivery cycle. This advice is constructed to complement existing information about HotHouse, AccelerateFramework and [[Tools]].
The Cookbook is not intended to be a general survey or guide to Agile practices or methodologies, for that we suggest you look at [[FurtherReading]]. Rather it is an approach to implementing the principles described in the AgileManifesto within the context of the [[TimeboxedDeliveryCycle]]. It is anticipated that the advice given here will be improved by feedback based on the practical application of this Cookbook.
The Cookbook will provide answers to the following questions:
* "What should I be doing?" :- Identifies how each [[AgilePractice]] should be undertaken at each stage - such as a focus on business value and a test-first approach. The minimum starting set of AgilePractices to be adopted when introducing Agile to your projects is described in [[CorePractices]].
* "How do I do it?" :- Provides pragmatic step-by-step advice to AgileRoles and the way of working across the [[TimeboxedDeliveryCycle]] and recommend Agile activities/devices which should be followed to help achieve success.
* "Why should I/we do it?" :- Why make the change to agile and what are the business benefits?
* "What do I bring to the process?" :- The cookbook is structured around each of the AgileRoles in the development process, and the activities in which they will be involved.
* "How has it been done elsewhere?" :- Provides supporting information/collateral such as CaseStudies from peer organisations to help explain the reasons for making the change to Agile and to demonstrate how to put Agile into practice.
* "How do I get help?" :- See the [[Help]] or visit the [[google group|http://groups.google.com/group/agilecookbook]] where questions can be logged to be answered by peers who have experienced similar situations or by experienced moderators.
!Background
The material for the AgileCookbook has been seeded by BT and Thoughtworks.
The content is licensed under the [[Creative Commons Attribution 3.0 license|http://creativecommons.org/licenses/by/3.0/us/]]
"Assume you'll do the same amount this DevelopmentIteration as you did the last DevelopmentIteration."
So, if the [[Velocity]] of your team was 20 last DevelopmentIteration, then you should reasonably expect that the team will be able to complete roughly 20 in the coming DevelopmentIteration. Notice that there is no mention of the unit of measure. That's because the unit of measure is irrelevant, so long as it is consistent.
In order to rely on YesterdaysWeather, it helps if your UserStories are sized such that the average developer can complete at least two per DevelopmentIteration.
To illustrate this point, imagine if your UserStories took on average 10 working days to complete, and your DevelopmentIteration was two weeks in length... there would be a strong possibility of finishing an iteration with no completed UserStories, which would not make for a very positive weather forecast.
Makes 8 -10 servings
!Ingredients
* 2 eggs
* 1 1/2 cups of sugar
* 1 1/2teaspoon of vanilla extract
* 1 1/2teaspoon of baking powder
* 1/4 teaspoon of salt
* 4 tablespoons of powdered cocoa
* 3/4 cup of milk
* 1 stick (8 tablespoons) of melted butter
* 3/4 cup of flour (add a bit more if the batter seems too thin)
!Method
# Butter a 9" round cake pan.
# Mix eggs and sugar and whip mixture until it has a fluffy consistency.
# Add the vanilla extract, baking powder and salt.
# Add the cocoa slowly (on low speed).
# Add the milk and the "cooled-down melted butter".
# Add the flour.
# Pour the batter into the cake pan and bake in the oven for approximately 30-35 minutes at 350? F. If you check the consistency with a toothpick, the toothpick should come out not completely "clean". This makes the cake a little bit more "moist".
Once the cake has cooled down, sift some powdered sugar over it. The cake can also be served with whipped cream and strawberries.
!Project Synopsis
This project is aimed at providing a suite of component web applications for the network and service operations teams in BT Global Services which present network and infrastructure physical and logical data and associated planned works and alarms.
It has a number of customers all with individual project objectives as well as the overall programme aim of achieving a single sign on toolkit for network teams to solve customer queries based on the information available to them.
!Project Relationships
The customers were widely dispersed throughout Global Services while the development team were focussed in Exeter and Bristol. Very early on, a central customer was identified as the focal customer contact point and product owner.
!Agile Practices Employed
* DailyStandUp – 15 minutes daily calls established with NSO team ([[Customer]]) invited to listen in on. Allows issues to be raised and taken offline to resolve quickly. Gives NSO visibility of what is happening on a daily basis.
* TestDrivenDesign – Dev team working closely with NSO to cut down testing to a minimal and tailor solution during the 30 day cycle, without jeopardising the deliverable.
* Iterations – Split into 30-day cycle to allow focus on key deliveries. Customer priorities regularly changing required flexibility which shortened delivery cycle provided. (see DevelopmentIteration).
!Retrospective
The project is still ongoing but so far the results have been positive. The project was originally failing but the process has allowed the higher priority work to rise to the top of the work stack, and deploy key deliveries which deliver the highest business benefit.
!Contact: Paul Goddard 0117 920 3062
For a national retail insurance company, ThoughtWorks was engaged to develop a web-based (J2EE), point of sale insurance origination system. This system replaces the previous manual processes used by the client to sell insurance through their retail channel.
The key business benefits provided by the software solution included:
* Maintenance of market leadership by providing a superior point of sale system to the retail agents.
* Cost savings resulting from automated underwriting at the point of sale;
* Elimination of delays involved in forwarding paper application forms from the retail agent;
* Elimination of printing costs involved in providing application forms and policy wording documents to retail agents;
Of these, the elimination of printing costs was a benefit that was not delivered by the original specified requirements, but was presented as a possibility by the project team midway through the project. This saving was of a similar order of magnitude to the entire business case benefit proposed in the initial requirements and so represented a very significant benefit to the client.
ThoughtWorks introduced agile practices which enabled the project to deliver working software from the first month of the 12 month project. The process innovation has been widely recognised by the client as being instrumental in delivering successfully on a project that had historically been regarded as a difficult one.
The development process used to deliver the project was based on an iterative approach introduced by [[ThoughtWorks]]. Key features of this approach are:
* Progressive Elaboration of Requirements, while there was a high level overview of the scope of the planned features; detailed requirements were worked up in the two weeks preceding an iteration. This just-in-time inventory of detailed requirements means that cost of change is kept to a minimum. A change to features not yet developed only impacts the one-line high level stories, not a large inventory of detailed requirements. A consequence of this approach is that test plans are also developed iteratively, with similar benefits in reduced re-work in case of changes to unimplemented features.
* Decomposition of work into tasks that can be completed by a single developer within a week. The project ended up including about 390 of these tasks, with an average size of 4.5 days to complete each one.
* Two week iterations for work scheduling and measuring visible progress. Phase 1 consisted of 20 such iterations, with several one-week iterations at the end during the pre-pilot testing period. Only tasks that have been tested and signed-off are considered completed - there's no such thing as 80% done;
* Test Driven development, where automated tests are written before application code. The project currently has 3374 automated tests including unit and functional regression tests. These tests are run by developers on their workstation as they complete tasks - this allows them to be confident that they have not inadvertently broken existing functionality. The safety net of tests also allows large scale 'refactorings' of the application to be made with little risk if it is deemed necessary, allowing improvements discovered late in the development process to be retrospectively applied with minimal cost;
* Testable requirements, analysts specify functional test cases which must succeed before the feature is considered code-complete. With the pace of development, it would be physically impossible for regression testing to be conducted manually. These 'acceptance' tests are automated by the developer and are added to the suite of functional regression tests once the task is complete;
* Progressive sign-off, a business representative is located full-time with the team and UAT tests each iterations delivered functionality as it is delivered. This gives a fast feedback mechanism to assist analysts and developers to ensure that they are meeting business expectations;
* Ongoing QA, from very early in the project the QA team were developing and executing test cases against delivered functionality. The ongoing involvement of QA ensures that any differences in interpretation of requirements between developers and QA are ironed out early in the process, reducing the cost of fixing bugs;
* Continuous Integration (CI), whenever a developer checks-in their work an automated CI build is triggered which builds the application and runs all (3374) automated tests. Every one of those tests has to pass for a build to be considered successful. The project has had 1984 such successful builds to date, almost 10 a day - or around 3.5 million test executions;
* Common Code Ownership, with very few exceptions every developer on the team worked on every area of the code base. This ensures that the project can absorb the absence of team members (a plus when applying for leave). The high degree of collaboration also meant that some team members with little previous java experience have gained substantial experience and capability through the life of the project;
* Coding Standards, helped by our automated build and a tool called Check Style, we've enforced a set of rigorous coding standards that assist greatly in ensuring that any team member can easily pick up code written by one of their peers, without being distracted unnecessarily by formatting and other cosmetic differences.
* Isolating External Dependencies, the system depended on a number of external systems to provide services to it. Some of those systems already existed, some needed configuration, and some were under (non-agile) development. By specifying abstracted interfaces to those external systems and writing stub implementations, we were able to move forward despite these dependencies. We developed a large number of automated tests against our stub implementations, with the result that when the actual systems were delivered we were able to detect and report all non-conformance to the specified interfaces immediately.
* Early Load and Performance Testing, we began performance testing the system well before the production hardware was available. Although the actual transaction durations were not production-like, with the addition of some profiling we were able to detect areas of relative non-performance. As a result our eventual formal performance and load testing, while it did find issues with the hardware and network, did not detect any significant performance or scalability issues.
The software went into pilot with no outstanding defects, and had no defects requiring intervention in over six months of production use. This represented a huge improvement over previous non-agile projects, which were plagued by production outages, and required in excess of 4 times the number of support staff to maintain.
!That Agile doesn't scale up to large projects...
Yes, it can! How? By decomposition and parallel effort
* Optimal team size proven over and over again to be 7-12 people
* Most large projects work in parallel decomposed teams regardless of process philosophy
* Control and oversight for large programs are accomplished by running a PMO that conducts conventional front-end planning, but monitors progress using Agile practices (stack-ranking features, the SCRUM burn-down chart, etc.) and reacts to change via adaptive planning
* As in any large program, best practices such as configuration management are required. Techniques such as continuous integration help teams realize additional value from these best practices.
!That Agile provides less visibility and control over a project...
* Absolutely the opposite is true. You get actual data about production ready code. Actual data allows stakeholders to make better informed decisions, and what's more you get the controls to implement those decisions. I.e. you get to steer the project in a small way every iteration and a larger way every release. Also the iteration tracking and reporting tools are usually very well received: "the project reporting systems are absolutely first rate, they gave us complete clarity on every aspect of the project."
* At the micro level, daily standups and bi-weekly customer acceptance demos create a very transparent environment giving substantive visibility into the inner workings of the team and the project. Iteration Planning Meetings which invite the customer to choose the stories for the next iteration (or at least reprioritise) gives them great control. However, time and again, I get the comment that what is missing are the schedules and the status reports/dashboards that customer project managers are used to (the macro level). Our successful response has been burn-down/up charts and release plans that are posted and kept up to date.
!That Agile project teams don't design their applications/do up-front design...
* Agile thinks that design is important, so it does it all the time. In particular it does it when it has the most information to inform that design i.e. not all at the beginning when you know the least. It also implicitly changes the view of an architect. Traditional projects see architects as in the construction industry, with developers as the construction workers. Agile sees developers as the architects with the compiler as the construction worker.
!That Agile project teams don't document their applications...
* They do if the documentation adds value to the business. Documentation can be part of the acceptance criteria for stories and a project deliverable.
* The Agile principle is 'just enough' documentation. It is up to the Customer to express their needs and work with the team to determine how much is just enough. None is too little. Method 1 is too much. The team should talk to the Customer and understand what their expectations and organisational needs are and ensure that documentation meets the expectations.
!That PairProgramming is only useful for senior/junior pairs...
* It's useful for that but also for avoiding key man risk, for knowledge sharing, for bringing new people into the team, for making people work hard, for avoiding silly bugs, for keeping design simple, for doing continuous code reviews, etc.
* Sr/Jr pairing has a different effect than peer/peer pairing. Sr/Jr maximizes mentoring and skill transfer and brings people up to speed faster. Peer/peer maximizes velocity while minimizing defects. Ideally, all pairs are peers and extremely senior, though in reality not all teams can be made of all the best people.
* Effective pairing is a skill that must be learned. The senior/junior pair is something that people have been practising all their lives. Every time someone lends someone else a hand with something, they are, in effect, pairing. Agile pairing adds another dimension to this simplistic case. Once you have learned to pair effectively, you realise that you can make far more use of it that just as a tool for mentoring.
!That PairProgramming is only useful for difficult parts of the code (or debugging)...
* The most difficult piece of code is the one that is holding up a build or the acceptance tests. Pairs are valuable here. The best way to reduce risk as well as difficulty quotient in code is to get a second pair of eyes on it. It has been well proven that code inspections produce better code than code reviews, due solely on their requirement for active participation. To follow this reasoning to its natural extension, active participation in continuous inspection produces the highest quality code. Some of the worst defects have been made in the simplest code: first, because it is so simple, it is not inspected (who could get it wrong) and second, because it was so simple, it is never re-inspected during the bug hunt (hey, who could have gotten it wrong). Review everything. Better yet, Inspect everything. Better yet, pair on everything!
* For me, realising that pairing was really useful in this area was the start of the realisation that pairing could be useful for all sorts of things. Then I started pulling in juniors, rather than seniors, to help with the hard bits and realised that they were almost as much help as the seniors!
!That PairProgramming means half as much work gets done...
* What is important is that the development team is at maximum output. The best way to achieve this from your team is to organise it in pairs. Individual productivity doesn't enter into it.
* Actually, the same amount of work is done, it is just that your initial velocity is lower. Typically, so is your defect rate. Pay now or pay later!
!That TestDrivenDevelopment replaces QA...
* Big mistake to make. TDD is a design process not a testing process. You get a set of unit tests as a by product but it's not about QA. You still need to do integration, system, OAT, UAT etc.
!That ContinuousIntegration is only useful for small projects...
* This may or may not be true - but if it is, it is all the more reason to do the build continuously. Maximize the number of builds by keeping them going. (Actually, if it does take all day to do the build, there may be a problem and it should be reviewed and assessed).
* This is because their build scripts tend to be monolithic. Modularise the code into more granular components that you can build individually and this problem with be dramatically reduced. Basically, this is yet another situation where good design pays off.
!That Agile is only for elite programmers...
* I think that the reason people form this view is that they think that adopting agile methods is like changing your shirt. You get up one morning, put on a new shirt and suddenly you're agile. In reality adopting agile methods requires the development team to learn a whole new set of skills. Until they have achieved a certain level of competence with these new skills, the net effect will be a loss of productivity. The more talented developers will pick up these skills more quickly than others, becoming productive sooner.
* Agility helps increase speed and quality. If your programmers are elite, it will make them superb. If they are middling, they may become elite. If they are poor, they may become passable. You should think of it as being an additive factor on their capability.
!That Agile == Good/Successful...
* It's a means to an end, not an end in itself. Many organisations have been very successful using Agile. We also know that Agile done badly, like any other method, leads to bad results.
* Once again, Agile is a set of skills that your team needs to learn. This set of skills is largely orthogonal to your traditional technical skills. If you add these skills to your existing skills, of course you will become a more effective team. However, you can't expect it to work like changing your shirt!
!That Agile project teams are undisciplined...
* Complete opposite of the truth. Keeping to the iteration structure requires immense discipline. Also keeping the code flexible so that you can accommodate change while at the same time keeping the design simple requires great discipline too.
* One of the points that was made when we did our CMMi assessment of the project team was that the rigor they employed was far and above that of comparable teams using other methodologies - this was from full SEI assessors (including Bill Curtis who was actually the author of the original CMM with Watts Humphrey). I have a hard time telling these people they are undisciplined. This is an urban legend that stems from all those hackers out there who misunderstand the agile practices and equate agile and light weight with none (no documentation, no process, no discipline).
* Here's an article from TickIT about discipline in Agile teams: [[http://www.tickit.org/ti2q04.pdf]]
!That Agile processes can't integrate with traditional processes...
* The integration points become constraints into which the iteration and release plans must be factored into. Not only can agile processes integrate, but they can run both in parallel and work products can be spliced in from one process stream to the other. One of the best ways to do this is to utilize critical chain scheduling (with buffers specified for critical deliverables, resources, and activities). I have seen very successful product development efforts undertake different processes simultaneously where part of the effort (typically the software) is done with an agile process and other parts (such as the pre-production prototypes for boards, housings, chip-sets, etc) are done with standard methods and then integrated together on the back end, on schedule, repeatedly.
!That Agile can't work when the team is distributed or work is outsourced or offshored...
Agile methods have been used successfully with distributed teams by many organisations. For an informative summary of lessons learned in distributed teams using agile, take a look at these articles: [[http://www.martinfowler.com/articles/agileOffshore.html]], [[http://www.informit.com/articles/article.asp?p=25929&seqNum=1]]
UnitTests are used to verify that 'units' of software behave as expected. In TestDrivenDesign they are written immediately before the unit of software, and are used to drive development and design.
AutomatedUnitTests is one of the Agile CorePractices.
A 'unit' of software in this case is generally considered to be the smallest piece of code that could be tested, in OO languages like Java, this is a class or method within a class.
Tests of any kind are more valuable if they pinpoint the source of an error. In the case of UnitTests this can be assured by testing units in isolation, rather than as a small part of a large assembly of co-dependent units. A great deal of effort is put into making UnitTests as free from external effects as possible. Ideally the only code that is 'exercised' by a test should be the code it is specifically intended to verify.
A very common 'external' component that causes difficulties with UnitTests is the database. UnitTests that rely on interaction by the class under test with a database are prone to spurious errors due to data issues, and tend to run orders of magnitude more slowly than UnitTests that are isolated from the database. This performance benefit is of great importance when AutomatedUnitTests are incorporated into your ContinuousIntegration build.
AutomatedUnitTests provide a significant part of the value delivered by ContinuousIntegration, by ensuring that any unintended changes in the behaviour of the software are identified and can be traced to very specific units of code.
Agile projects using TestDrivenDesign typically achieve levels of test coverage in excess of 80% from AutomatedUnitTests.
The TechnicalLead, usually a senior [[Developer]] working within the [[Developer]] team, is responsible for ensuring that the technical CommonVision is maintained. The TechnicalLead works closely with the [[Designer]] in order to both communicate design goals to the team and to provide feedback to the [[Designer]] about implementation issues.
From the TechnicalLead point of view, the most significant changes from a more traditional approach are the focus on EmergentDesign in each DevelopmentIteration, driving design changes incrementally through UserStories, and a greater level of direct interaction and feedback from the [[Developer]] team.
There is a perspective shift for the TechnicalLead in an agile approach:
* delivery of WorkingSoftware at the end of each DevelopmentIteration
* working in a more collaborative manner which leads to more collaboration [[Developer]]
* from predictive upfront design to RespondingToChange via EmergentDesign
* focusing on IndividualsAndInteractions.
Things that are likely to be different:
* Building the design of the system via EmergentDesign
* LoweringTheCostOfChange by striving for SimpleDesign and "Doing the simplest thing that could possibly work"
* Incorporating new insights into the code base by [[Refactoring]]
* Using TestDrivenDesign to focus on what needs to be done rather than on what might be useful
* Focus on WorkingSoftware over documentation
* Day to day interaction with [[Developer]] team
Things that are likely to stay the same:
* Responsibility for ensuring that design goals are communicated to the [[Developer]] team
* Collaborating with the [[Developer]] team to resolve technical issues
The TechnicalLeadWalkthrough provides more detail on activities of a TechnicalLead within an Agile team during the [[TimeboxedDeliveryCycle]].
Ideally, the [[Customer]] would be a Subject Matter Expert who is co-located with the team as an OnSiteCustomer. Often however it is not possible to achieve this and the [[Customer]] is either a business representative or a BusinessAnalyst who has strong domain knowledge - called a CustomerProxy.
In this case it is important to involve the real SubjectMatterExperts as effectively as possible, by including them in PlanningGame sessions or Analysis workshops.
The [[Designer]] may fill the role of Subject Matter Expert.
Purpose: To make sure the deployment is fit for purpose
When it should pass: before each deployment
What’s needed:
*Deployment environment available and consistent
*Issue resolution mechanism in place
*User feedback mechanism in place
*OI approved
*All ACF requirements met or consessions documented
Specific checklists will be programme/project dependent
The CustomerProxy makes decisions about priority and features etc. in the absence of a full time OnSiteCustomer.
This is usually the BusinessAnalyst, however it may also be another person from the organisation with business knowledge.
[[Velocity]] is either the number of UserStories completed in the DevelopmentIteration, or the sum of the UserStorySize for each completed UserStory.
* CodingStandards
* CollectiveOwnership
* CommonVision
* ContinuousIntegration
* OnSiteCustomer
* PairProgramming
* PlanningGame
* [[Refactoring]]
* [[Retrospective]]
* SafeDeployment
* ShortReleases
* SimpleDesign
* SustainablePace
* [[Testing]]
A wiki guide to Agile Delivery in the 90 Day Cycle
We value your feedback on the material in this cookbook. Please refer to the name of the section when providing your feedback so we can locate the right area. We prefer constructive feedback where possible so please try to suggest a better form of words or refer to some extra information that should be included.
There is a Google Group to discuss matters relating to the Agile Cookbook : http://groups.google.com/group/agilecookbook
During a DevelopmentIteration, UserStories will be completed by the [[Developer]].
To ensure the most timely feedback possible, the [[Customer]] or [[BusinessAnalyst]] should review each completed UserStory and verify that it meets the agreed AcceptanceCriteria.
This ProgressiveSignOff of completed functionality allows the [[Customer]] and ProjectManager to see progress within a DevelopmentIteration, and ensures that any issues are dealt with as soon as possible.
The ProgressiveSignOff of UserStories should be made visible to the whole team via some [[Communication]] mechanism. One way of doing this for a co-located team is shown in the picture below:
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/storywall.jpeg]]
The AgileCoach is an experienced Agile practitioner who is responsible for helping the team adopt AgilePractices. The AgileCoach may also take on the IterationManager role.
The approach described in this Cookbook is to break the [[TimeboxedDeliveryCycle]] down into a number of relatively short [[DevelopmentIteration]]s. Following an initial IterationZero, functionality is added incrementally as WorkingSoftware delivered at the end of each [[DevelopmentIteration]].
This Cookbook provides role-specific walkthroughs, which detail how each of the AgileRoles is involved throughout the [[TimeboxedDeliveryCycle]]:
* CustomerWalkthrough
* ProjectManagerWalkthrough
* DesignerWalkthrough
* DeveloperWalkthrough (and TechnicalLeadWalkthrough)
* TesterWalkthrough
* BusinessAnalystWalkthrough
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/90daystimeline.jpeg]]
SafeDeployment means that the software should be able to be reliably deployed into all test and production environments, preferably automatically.
Often the ContinuousIntegration build is used to produce tailored deployable versions of the application for each target environment, allowing deployment of new versions of the software into test without requiring interruption of the [[Developer]] team.
An IterationPlan shows what UserStories are scheduled for a particular DevelopmentIteration and the current status of each UserStory. What follows is an example of how this can be done in a ProjectWiki, taken from an actual project where this was done successfully over a period of 12 months. The content is not intended to be prescriptive, in fact it changed markedly over the lifetime of that project as the process was fine-tuned.
You'll notice some embedded ProjectWiki links in the tables - this is because the UserStories [[Narrative]] and AcceptanceCriteria were also stored in the ProjectWiki on that project.
!Example IterationPlan
The table below shows the supply of stories for this iteration in priority order. The top story in the list has the highest priority, the second from the top has the next highest priority, and so on. The stories having a developers initials in the Dev column are scheduled for completion in the current iteration.
__Iteration15__
|Story|Description|Status|Rev By|Base Est|Plan Est|Iter Est|BA OK|Dev OK|Test OK|Dev|Tech Design|Tech Review|
|[UC0596]|Dealer Enters Multiple Payment Details|__SignedOff__|-|3|3|1|AA|SB|RS|MC|-|-|
|[UC0601]|Dealer Enters Facility Configuration details|__SignedOff__|AM|2|2|3|-|-|-|LS|-|-|
|[UC0602]|Dealer Saves Facility Configuration|__SignedOff__|VC|3|3|0|-|-|-|TO|-|-|
|[UC0614]|Dealer enters ongoing fee on financed quote|__SignedOff__|TO|2|2|1.5|-|-|-|BS|-|-|
|[UC0196]|Dealer Reopens Saved Full Quote|InProgress|-|2|2|1|-|-|-|AM|SH|-|
|[UC0199]|Dealer Enters Policy Search Criteria|__SignedOff__|TO|0.5|0.5|0.5|AA|SB|RS|LS|AM|SH|
|-|-|-|-|-|-|-|-|-|-|-|-|-|
|Defect No.|Description|Dev|Status|Time Spent (Hrs)|Automated Regression Test|
|152|Invalid Postcode on Vehicle Selection screen|MC|DefectFixed|-|-|
|4|Data retained when canceling|AT|DefectFixed|20|Defect0004Test|
|-|-|-|-|-|-|
Indicates that the linked activity is performed constantly.
The Discussion Forums are not yet available.
AgileEnablers work within the team in specific roles to give hands-on assistance and guidance in implementing [[AgilePractices]].
Agile favours learning via interactions between individuals. Teams benefit greatly if they are seeded with experienced AgileEnablers in areas such as the [[Developer]], [[BusinessAnalyst]] and [[Tester]] teams.
The AgileCoach can derive a great deal of support in introducing AgilePractices if the team is seeded with [[AgileEnablers]].
ThoughtWorks is the original creator of the content to the Agile Cookbook. ThoughtWorks is a consultancy that helped pioneer Agile methodologies in the enterprise. See the [[ThoughtWorks Website|http://www.thoughtworks.com]]
When a team takes CollectiveOwnership of a code base, they may need to make some individual concessions to allow the team to work together smoothly. CodingStandards assist by specifying such technical detail as whether code will contain tabs or spaces, and how packages will be named and structured.
!Who should be involved?
Personal preferences are likely to differ within the [[Developer]] team, but minor concessions should allow a consensus to be reached fairly easily.
!When should it be done?
A first draft of the CodingStandards should be developed as development gets underway. It is possible to enforce some of these standards within the ContinuousIntegration build.
Many modern Integrated Development Environments support using templates for common code structures. Standardising on these templates can help prevent the introduction of different styles.
!What are the benefits?
Personal differences in style are not a hindrance. The whole team benefits from the good habits of each of the members.
!Are there any prerequisites?
Some standards (e.g. naming conventions) will be difficult to enforce, but many simple and useful standards (package dependencies, method length, brackets and braces) can be checked automatically in the ContinuousIntegration build.
!How has this been done elsewhere?
Many ThoughtWorks projects simply circulate IDE configurations.
There are tools to help programmers write Java code that adheres to a coding standard. They automate the process of checking Java code to spare humans of this boring (but important) task, and can be incorporated into the ContinuousIntegration build. This makes these tools ideal for projects that want to enforce CodingStandards.
!Common pitfalls
This is generally a good practice, and as long as it is simply defined, has mostly positive effects.
Not Started
Started
Complete
Agile strongly favours CustomerCollaboration in order to maximise the BusinessValue delivered in the form of WorkingSoftware. Because of the emphasis on IndividualsAndInteractions, this collaboration is generally recommended to take the form of continuous [[Customer]] involvement and in fact presence in the project team.
Business practicalities do often preclude the optimal degree of direct [[Customer]] participation, and the role of [[CustomerProxy]] is often used to compensate for this. However, wherever possible the team should attempt to have regular direct contact with the [[Customer]], certainly at least during the [[Showcase]] of completed WorkingSoftware that is given during the IterationRetrospective.
!Who should be involved?
Ideally the OnSiteCustomer should be a target user of the system under construction, with a good overall knowledge of the business requirements and priorities. If a CustomerProxy is used, then it is important that SubjectMatterExperts be available to support the CustomerProxy, and that appropriate [[Customer]] involvement is given during the IterationPlanningMeeting and IterationRetrospective to ensure priorities are correct.
The [[Designer]] may act as an OnSiteCustomer in respect of non-functional requirements of the system.
!When should it be done?
Ideally AllTheTime, or failing that - at minimum during the IterationPlanningMeeting and the IterationRetrospective.
!What are the benefits?
Having an OnSiteCustomer greatly increases the teams ability to deliver the greatest BusinessValue early, and facilitates RespondingToChange when business priorities or requirements change.
The improved turn-around time on important decisions improves productivity, since the OnSiteCustomer can circumvent the necessity for the team to wait for emails to be returned by making appropriate prioritisation decisions.
!Are there any prerequisites?
The [[Customer]] has to be sufficiently interested in the outcome of the project to become involved.
If the team is not co-located, then OnSiteCustomer may really mean availability of the [[Customer]] via alternative [[Communication]] mechanisms.
!How has this been done elsewhere?
From CaseStudy1: "Progressive sign-off, a business representative is located full-time with the team and UAT tests each iterations delivered functionality as it is delivered. This gives a fast feedback mechanism to assist analysts and developers to ensure that they are meeting business expectations;"
!Common pitfalls
DesignPatterns are somewhat out of scope for this Cookbook. If you want to learn more about DesignPatterns then you may like to take a look at this excellent introduction by Brad Appleton (http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html). The book [[Design Patterns: Elements of Reusable Object-Oriented Software; Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides|http://www.amazon.com/exec/obidos/ASIN/0201633612/ref=bxgy_cc_text_a/002-7900535-2845645]] is the most commonly referenced source.
Agile Delivery impacts on a number of other initiatives:
! PIR
Agile Delivery is being brought into the PIR process from the start of the next financial year. Details of the measures will be available soon, but the aim is to reward the steps being taken by programmes to implement agile recognising that each programme faces different challenges and will not be able to move at the same pace.
! QMS and ISO 9001
After a presentation to Lloyds on Agile Development, and the successful audit of an agile project Lloyds are happy now with the principles of the approach, being satisfied that Agile is not a free for all, nor a hackers' charter. They will want to audit more agile projects and will be expecting to see the momentum we have built up sustained.
!Sarbanes Oxley
Agile Development has been registered as one of the processes in use in One IT, and will be audited by the Sarbanes Oxley external auditors. With a satisfactory Lloyds report we are not anticipating any major problems with Sarbanes, but we will be looking to explain the approach to them prior to any audit.
!Join the Dots
As a central plank of One IT's transformation, Agile Delivery has been heavily involved in the Join the Dots programme, and will continue to be so until the programme has been completed.
TestDrivenDesign means using the creation of tests to drive development. Testing the smallest thing possible in isolation from other things in the system so that if the test fails you know exactly why it failed.
!Who should be involved?
The [[Developer]] team primarily, guided by the TechnicalLead. The [[Designer]] can use this technique very effectively when specifying interfaces between systems in the form of executable tests.
!When should it be done?
TestDrivenDesign should be done AllTheTime, over the entire code base. There may be some parts of the code base that are not able to be tested, however if a way to use TestDrivenDesign can be found then it should be.
!What are the benefits?
* High automated unit test coverage of the code
* Code that doesn't contain unnecessary stuff, it only exists because there is a test that means it has to exist. Necessary means "needed to pass a test".
* Higher quality code, simpler, smaller without being obscurely terse.
* The tests achieve the side effect of documenting the code
* Easier to add new functionality
* Obvious when new code breaks existing code because tests fail
* Supports collective code ownership, others can edit your code easily
* Provides confidence in the correctness of the solution
* Informs the developer when a task is complete
* Focus the developers on the small scale task at hand
* Drives the design of the solution (by making use of the code before you've even written it)
!Are there any prerequisites?
The code needs to be testable, preferably in isolation from other components.
!How has this been done elsewhere?
Many Open Source projects use TestDrivenDesign to convey the intent of the code. It also helps where there is a large, distributed team (as is often the case in Open Source projects), as the tests become a communication mechanism.
TestDrivenDesign is mandated within ThoughtWorks and other experienced Agile development organisations. On many ThoughtWorks projects, the tests are referred to as the living documentation. ThoughtWorks has found that using TestDrivenDesign helps new team members understand the code base, and gain confidence in making changes.
!Common pitfalls
In addition to their design and documentation role, tests are very useful as a means for early feedback. If the test suite takes too long to execute, this great benefit is compromised.
It is tempting for developers to write the tests after the code has been written. Although this might appear similar to TestDrivenDesign, it is likely that not all scenarios will be tested, and the benefit of EmergentDesign will be lost.
Open the [[Agile Cookbook|cookbook.html]] in a new window.
This is a walk through of an Agile project, from the [[Tester]] perspective, detailing the activities that the [[Tester]] will have a significant role in.
The HotHouse runs over days one to three of the [[TimeboxedDeliveryCycle]]. The focus of the AgileCookbook and this TesterWalkthrough is days four to ninety.
!After the HotHouse - IterationZero, day four
* Assisting the BusinessAnalyst in building a [[Narrative]] and AcceptanceCriteria for highest priority UserStories, for the first DevelopmentIteration
* Prepare appropriate Test Environments, remembering that they only need to be sufficiently mature to test the work completed in the first DevelopmentIteration at this stage. These environments will mature throughout the project as required.
!Before each DevelopmentIteration
* Prepare AcceptanceCriteria for each UserStory being played in the Iteration
!During each DevelopmentIteration
* Pair with the [[Developer]] team to present the AcceptanceCriteria as AutomatedAcceptanceTests.
* Ensure that all regression tests accumulated from previous [[DevelopmentIteration]]s are still passing in the ContinuousIntegration build.
* Proceed with parallel tracks of Performance and Integration Test
!After each DevelopmentIteration
* Validate that completed UserStories pass their AcceptanceCriteria, possibly raising as defects any minor issues
* Participate in the IterationRetrospective
!At the end of the [[TimeboxedDeliveryCycle]]
* Conduct pre-release System, Penetration, Performance and Load testing.
* Manage formal User Acceptance Testing
One of the key AgilePrinciples is the focus on NOT DOING as much as possible.
Assumptions about the size and nature of framework / foundation that will be required to develop a system often lead to designs more complex (and costly to maintain) than they need to be.
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/simpledesign.jpeg]]
!Who should be involved?
Developers need to avoid making assumptions about the amount of complexity required to accomplish the task at hand. As future cards are played, it is likely that complexity will be introduced, but not necessarily in the way we might predict up front.
!When should it be done?
!What are the benefits?
The effort required to understand the code /system will be reduced. The effort invested in [[Refactoring]] / maintaining code not actually required will be reduced.
!Are there any prerequisites?
!How has this been done elsewhere?
ThoughtWorks project teams do not have separate resources for "framework" and "application" development. Only as much framework as is required will be built along with the application. Additionally, the framework will not be locked down, and it evolves according to the requirements of the application.
!Common pitfalls
Many who try this fail to distinguish between 'Do The Simplest Thing That Will Work' from 'Do The Stupidest Thing That Will Work'. Making something simple can be more difficult than making something complicated. This practice does not encourage short-sightedness, but rather suggests that we cannot accurately foresee all requirements.
From the Project Managers point of view, the most significant difference between traditional and agile methodologies centres on plans and planning. Traditional methodologies tend to be plan centric, having a detailed, prescriptive plan constructed in advance. Deviations from the plan are generally treated as exceptions that need to be remedied. Agile projects also produce plans and engage in planning, however these plans are adaptive rather than prescriptive, and treat deviations as feedback to be incorporated into future plans. This difference can be summed up by saying that Agile methodologies favour RespondingToChange, whereas traditional methodologies resist change.
You may feel that adaptive planning leaves you with less control over the project (see AgileMyths), however experience shows that Agile methods give you finer grained control due to flexible plan and accurate [[ProjectTracking]]. There is a traditional role in Agile projects called the IterationManager in this Cookbook, also referred to as Tracker in XP or the Scrum Master in Scrum, which typically is responsible for providing accurate progress information to the [[ProjectManager]].
Agile techniques were developed in the context of software development. However the large majority of agile practices can be applied to the whole software delivery cycle and beyond. Although practices such as say PairProgramming are development centric, the general principles in the AgileManifesto are easily applied across the board. Examples of how agile principles may be applied to non-development elements of a project can be found here: ExtendingAgile
Key to the success of the adaptive plan is timely and accurate feedback. Agile projects tend to centre around the delivery of small discrete pieces of work (called a UserStory in this guide), generally in an iterative cycle. Large, long running tasks are very difficult to track, and tend to be "80 percent finished, 80 percent of the time". In contrast, a UserStory is either 100% complete and passes it's AcceptanceCriteria at the end of a DevelopmentIteration, or it's not counted as done. This rigorous approach to delivery allows accurate ProjectTracking and informed decision making based on the project status. Previously delivered functionality is protected by ContinuousIntegration incorporating AutomatedFunctionalTests, so that each additional UserStory adds to an accumulating volume of proven, and very importantly already accepted functionality.
There is a perspective shift for the ProjectManager in an agile approach:
* from tracking milestones to iterative ProjectTracking based on the delivery of WorkingSoftware at the end of each DevelopmentIteration
* from command and control to working in a more collaborative manner which leads to more CustomerCollaboration
* from predictive upfront planning using say Gantt charts to RespondingToChange via adaptive, iterative planning
* from maintaining a detailed plan to leaving the ProjectManager free to clear roadblocks and tune the team to maximise productivity by focusing on [[IndividualsAndInteractions]].
Because of a shift away from a more traditional command and control approach, it is important for the ProjectManager to enable open and honest [[Communication]] within the team.
What does a Project Manager do on an Agile Project? Well pretty much the same thing as they do on any other kind of project, but sometimes in a different way:
Things that are likely to be different:
* "How do I plan?" :- [[ProjectPlanning]], [[ReleasePlanning]], [[IterationPlanning]];
* "How do I know where we're up to?" :- [[IterationManager]], [[OneTruthRepository]], [[ProjectTracking]], [[ProjectDashboard]];
* "How do I report progress?" :- [[ProjectReporting]], [[IterationRetrospective]];
Things that are likely to stay the same:
* Issue Management
* Risk Management
The ProjectManagerWalkthrough provides more detail on the day-to-day activities of a ProjectManager within an Agile team.
config.options.txtTheme = "BTSkin";
There is a traditional role in Agile projects called the IterationManager in this Cookbook, also referred to as Tracker in XP or the Scrum Master in Scrum, which typically is responsible for providing accurate progress information to the ProjectManager.
On a smaller project, the ProjectManager may be able to fill both roles, however on larger projects the ProjectManager will typically not have enough time to do both. In a programme of work, or for a large project with more than one AgileTeam involved, there may be more than one IterationManager, perhaps one per team, reporting to the Project or Program Manager.
Specifically the Iteration Manager is generally responsible for:
* Conducting the IterationPlanningMeeting
* IterationTracking
* Conducting the IterationKickOff
* Conducting the IterationRetrospective
* Implementing process improvements based on feedback
* Providing appropriate Agile Metrics such as [[Velocity]] to the ProjectManager
The Iteration Manager may also be responsible for:
* Acting as the AgileCoach
* Implementing ScopeManagement
/***
|Name|SinglePageModePluginInfo|
|Source|http://www.TiddlyTools.com/#SinglePageModePlugin|
|Documentation|http://www.TiddlyTools.com/#SinglePageModePluginInfo|
|Version|2.9.6|
|Author|Eric Shulman - ELS Design Studios|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|documentation|
|Requires||
|Overrides||
|Description|Documentation for SinglePageModePlugin|
Normally, as you click on the links in TiddlyWiki, more and more tiddlers are displayed on the page. The order of this tiddler display depends upon when and where you have clicked. Some people like this non-linear method of reading the document, while others have reported that when many tiddlers have been opened, it can get somewhat confusing. SinglePageModePlugin allows you to configure TiddlyWiki to navigate more like a traditional multipage web site with only one item displayed at a time.
!!!!!Usage
<<<
When the plugin is enabled, only one tiddler will be displayed at a time and the browser window's titlebar is updated to include the current tiddler title. The browser's location URL is also updated with a 'permalink' for the current tiddler so that it is easier to create a browser 'bookmark' for the current tiddler. Alternatively, even when displaying multiple tiddlers //is// permitted, you can still reduce the potential for confusion by forcing tiddlers to always open at the top (or bottom) of the page instead of being displayed following the tiddler containing the link that was clicked.
<<<
!!!!!Configuration
<<<
<<option chkSinglePageMode>> Display one tiddler at a time
><<option chkSinglePagePermalink>> Automatically permalink current tiddler
><<option chkSinglePageKeepFoldedTiddlers>> Don't close tiddlers that are folded
><<option chkSinglePageKeepEditedTiddlers>> Don't close tiddlers that are being edited
<<option chkTopOfPageMode>> Open tiddlers at the top of the page
<<option chkBottomOfPageMode>> Open tiddlers at the bottom of the page
<<option chkSinglePageAutoScroll>> Automatically scroll tiddler into view (if needed)
Notes:
* {{block{
The "display one tiddler at a time" option can also be //temporarily// set/reset by including a 'paramifier' in the document URL: {{{#SPM:true}}} or {{{#SPM:false}}}. You can also use {{{SPM:expression}}}, where 'expression' is any javascript statement that evaluates to true or false. This allows you to create hard-coded links in other documents that can selectively enable/disable the use of this option based on various programmatic conditions, such as the current username. For example, using
{{{#SPM:config.options.txtUserName!="SomeName"}}}
enables 'one tiddler at a time' display for all users //other than// "~SomeName")}}}
* If more than one display mode is selected, 'one at a time' display takes precedence over both 'top' and 'bottom' settings, and if 'one at a time' setting is not used, 'top of page' takes precedence over 'bottom of page'.
* When using Apple's Safari browser, automatically setting the permalink causes an error and is disabled.
<<<
!!!!!Revisions
<<<
2008.10.17 [2.9.6] changed chkSinglePageAutoScroll default to false
2008.06.12 [2.9.5] corrected 'scroll to top of page' logic in auto-scroll handling
2008.06.11 [2.9.4] added chkSinglePageKeepEditedTiddlers option
2008.06.05 [2.9.3] in displayTiddler(), bypass single/top/bottom mode handling if startingUp. Allows multiple tiddlers to be displayed during startup processing (e.g., #story:DefaultTiddlers), even if single/top/bottom mode is enabled.
2008.04.18 [2.9.2] in displayTiddler() and checkLastURL(), handling for Unicode in tiddler titles (remove explicit conversion between Unicode and UTF, as this is apparently done automatically by encode/decodeURIComponent, resulting in double-encoding!
2008.04.08 [2.9.1] don't automatically add options to AdvancedOptions shadow tiddler
2008.04.02 [2.9.0] in displayTiddler(), when single-page mode is in use and a tiddler is being edited, ask for permission to save-and-close that tiddler, instead of just leaving it open.
2008.03.29 [2.8.3] in displayTiddler(), get title from tiddler object (if needed). Fixes errors caused when calling function passes a tiddler *object* instead of a tiddler *title*
2008.03.14 [2.8.2] in displayTiddler(), if editing specified tiddler, just move it to top/bottom of story *without* re-rendering (prevents discard of partial edits).
2008.03.06 [2.8.1] in paramifier handler, start 'checkURL' timer if chkSinglePageMode is enabled
2008.03.06 [2.8.0] added option, {{{config.options.chkSinglePageKeepFoldedTiddlers}}}, so folded tiddlers won't be closed when using single-page mode. Also, in checkURL(), if hash is a ''permaview'' (e.g., "#foo bar baz"), then display multiple tiddlers rather than attempting to display "foo bar baz" as a single tiddler
2008.03.05 [2.7.0] added support for "SPM:" URL paramifier
2008.03.01 [2.6.0] in hijack of displayTiddler(), added 'title' argument to closeAllTiddlers() so that target tiddler isn't closed-and-reopened if it was already displayed. Also, added config.options.chkSinglePageAutoScrolloption to bypass automatic 'scroll into view' logic (note: core still does it's own ensureVisible() handling)
2007.12.22 [2.5.3] in checkLastURL(), use decodeURIComponent() instead of decodeURI so that tiddler titles with commas (and/or other punctuation) are correctly handled.
2007.10.26 [2.5.2] documentation cleanup
2007.10.08 [2.5.1] in displayTiddler(), when using single-page or top-of-page mode, scrollTo(0,0) to ensure that page header is in view.
2007.09.13 [2.5.0] for TPM/BPM modes, don't force tiddler to redisplay if already shown. Allows transition between view/edit or collapsed/view templates, without repositioning displayed tiddler.
2007.09.12 [2.4.0] added option to disable automatic permalink feature. Also, Safari is now excluded from permalinking action to avoid bug where tiddlers don't display after hash is updated.
2007.03.03 [2.3.1] fix typo when adding BPM option to AdvancedOptions (prevented checkbox from appearing)
2007.03.03 [2.3.0] added support for BottomOfPageMode (BPM) based on request from DaveGarbutt
2007.02.06 [2.2.3] in Story.prototype.displayTiddler(), use convertUnicodeToUTF8() for correct I18N string handling when creating URL hash string from tiddler title (based on bug report from BidiX)
2007.01.08 [2.2.2] use apply() to invoke hijacked core functions
2006.07.04 [2.2.1] in hijack for displayTiddlers(), suspend TPM as well as SPM so that DefaultTiddlers displays in the correct order.
2006.06.01 [2.2.0] added chkTopOfPageMode (TPM) handling
2006.02.04 [2.1.1] moved global variable declarations to config.* to avoid FireFox 1.5.0.1 crash bug when assigning to globals
2005.12.27 [2.1.0] hijack displayTiddlers() so that SPM can be suspended during startup while displaying the DefaultTiddlers (or #hash list). Also, corrected initialization for undefined SPM flag to "false", so default behavior is to display multiple tiddlers
2005.12.27 [2.0.0] Update for TW2.0
2005.11.24 [1.1.2] When the back and forward buttons are used, the page now changes to match the URL. Based on code added by Clint Checketts
2005.10.14 [1.1.1] permalink creation now calls encodeTiddlyLink() to handle tiddler titles with spaces in them
2005.10.14 [1.1.0] added automatic setting of window title and location bar ('auto-permalink'). feature suggestion by David Dickens.
2005.10.09 [1.0.1] combined documentation and code in a single tiddler
2005.08.15 [1.0.0] Initial Release
<<<
The Tester's role in an Agile project differs from that in a traditional project in the increased focus on defining AcceptanceCriteria and creating [[AutomatedAcceptanceTests]]. Communication with the [[Developer]], [[Designer]] and the BusinessAnalyst is strongly encouraged, to ensure that a CommonVision is created and maintained.
AutomatedAcceptanceTests are specifically focussed on the functionality being delivered in a particular [[UserStory]]. There is still a need for scenario based AutomatedFunctionalTests which transcend the boundaries of the individual [[UserStory]].
The agile preference for collaboration over documentation means that you will not be creating test scripts based on a large document produced by the BusinessAnalyst and [[Designer]]. Instead you will be working with them before each DevelopmentIteration to ensure that UserStories have appropriate, testable [[AcceptanceCriteria]].
From very early in the project the [[Tester]] team are developing and executing test cases against delivered functionality. The ongoing involvement of the [[Tester]] ensures that any differences in interpretation of requirements between [[Developer]] and [[Tester]] are ironed out early in the process, reducing the cost of fixing bugs;
The iterative nature of agile leads to a need to automate as many of the tests as possible, as they will be run for each build emerging from development, not just once at the end of the project cycle. AutomatedFunctionalTests are included in a ContinuousIntegration build which is typically run several times a day, with new tests being added throughout the [[DevelopmentIteration]].
Things that are likely to be different:
* Tests are automated before code is developed, rather than afterward. These AutomatedAcceptanceTests act as a completion gate for the developer, and provide assurance that the UserStory has been delivered. This is often called [[TestDrivenDevelopment]].
* Rather than acting as a Quality Gate, the Tester acts more as a Quality Coach on an Agile project. Helping the [[Developer]] team to create better and more comprehensive automated tests.
* Agile teams tend to automate as much as possible, since the pace of development makes it impossible to perform repetitive tasks manually. Often the [[Developer]] team does a lot of the test automation work, relying on the [[Tester]] to ensure high quality tests.
* Defects found during testing are generally prioritised alongside UserStories and will be fixed during a [[DevelopmentIteration]]. As a result of the ongoing testing defects are found and fixed early in the project. This leads to a higher initial 'defect rate', but far fewer defects overall as the early fixes prevent defects being replicated.
* TestDrivenDevelopment applies especially well to defect fixes, in this case the [[Developer]] is required to write AutomatedUnitTests which expose the defect prior to fixing it. The inclusion of this automated test into the ContinuousIntegration build ensures that there will be no regression of the defect.
* ContinuousIntegration and SafeDeployment tend to mean that 'severity-one' defects which block testing are relatively rare. In particular it is much less likely that the [[Tester]] team will receive an application which fails to deploy into the test environment.
* Tests change throughout the development process as new UserStories are developed and impact existing functionality. Having your tests automated and part of the ContinuousIntegration build ensures that any conflict between new functionality and existing behaviour is detected early and can be resolved efficiently.
Things that are likely to stay the same:
* There will still be some more traditional 'gating' testing performed prior to the release of WorkingSoftware into pilot or production.
* Testing of non-functional requirements such as performance and load testing on production-like hardware is still required, although early indicative testing on more accessible hardware is strongly recommended.
* The [[Tester]] team will still need to maintain an appropriate set of Test Environments - the major difference being that these will need to be available from very early in the project.
* Defects may still be entered into a defect management tool, however due to being prioritised alongside UserStories the typical 'time-to-fix' metrics may not be applicable.
* Some of the traditional test automation tools, especially those that rely on recorded scripts tend to be quite fragile with respect to changes to the user interface. Automated testing begins very early on an Agile project, while the User Interface is still immature and prone to frequent change. Because of this there are a number of test-automation languages and tools that have been developed which are more resilient to change. It pays to investigate the use of such tools on your project since it can be impossible to keep up with the pace of change otherwise.
The TesterWalkthrough provides more detail on activities of a [[Tester]] within an Agile team during the [[TimeboxedDeliveryCycle]].
When one or more tasks fail in the ContinuousIntegration build, it is said to BreakTheBuild.
Because of the great importance of maintaining a ContinuousIntegration build, it is wise to fix the build prior to allowing new changes to be checked into the SourceControlRepository.
An InterfaceContract describes a published interface that one system guarantees to support when providing a service to another system. When several dependent systems are under concurrent development, specifying a simple InterfaceContract allows each team to implement an appropriate ServiceStub and to create AutomatedIntegrationTests that will validate their use of the other systems once the real implementations are available.
/***
|''Name''|TiddlyWebConfig|
|''Description''|configuration settings for TiddlyWebWiki|
|''Author''|FND|
|''Version''|0.7.4|
|''Status''|stable|
|''Source''|http://svn.tiddlywiki.org/Trunk/association/plugins/TiddlyWebConfig.js|
|''License''|[[BSD|http://www.opensource.org/licenses/bsd-license.php]]|
|''Requires''|TiddlyWebAdaptor|
|''Keywords''|serverSide TiddlyWeb|
!Revision History
!!v0.1 (2008-11-30)
* initial release
!!v0.2 (2009-01-15)
* removed obsolete dependencies
!!v0.3 (2009-03-16)
* sync username with server
!!v0.4 (2009-05-23)
* cache list of available login challengers
!!v0.5 (2009-07-10)
* disabled save and delete toolbar commands for unauthorized users
!!v0.6 (2009-08-15)
* disabled edit toolbar command for unauthorized users
!!v0.7 (2009-09-11)
* added revisions toolbar command
!Code
***/
//{{{
if(!config.adaptors.tiddlyweb) {
throw "Missing dependency: TiddlyWebAdaptor";
}
(function() {
if(window.location.protocol != "file:") {
config.options.chkAutoSave = true;
}
// initialize configuration
var adaptor = tiddler.getAdaptor();
var host = tiddler.fields["server.host"];
var recipe = tiddler.fields["server.recipe"];
var workspace = recipe ? "recipes/" + recipe : "bags/common";
config.defaultCustomFields = {
"server.type": tiddler.getServerType(),
"server.host": host,
"server.workspace": workspace
};
// modify toolbar commands
config.shadowTiddlers.ToolbarCommands = config.shadowTiddlers.ToolbarCommands.
replace("closeTiddler ", "revisions closeTiddler ");
config.commands.saveTiddler.isEnabled = function(tiddler) {
return hasPermission("write", tiddler);
};
config.commands.deleteTiddler.isEnabled = function(tiddler) {
return hasPermission("delete", tiddler);
};
// hijack Tiddler.prototype.isReadOnly to use permissions
var original = Tiddler.prototype.isReadOnly;
Tiddler.prototype.isReadOnly = function() {
var readOnly = original.apply(this, arguments); // global read-only mode
return readOnly || !hasPermission("write", this);
};
var hasPermission = function(type, tiddler) {
var perms = tiddler.fields["server.permissions"];
if(perms) {
return perms.split(", ").contains(type);
} else {
return true;
}
};
// retrieve server info
var statusCallback = function(context, userParams) {
if(context.serverStatus) {
// set username
if(context.serverStatus.username) {
config.macros.option.propagateOption("txtUserName",
"value", context.serverStatus.username, "input");
}
// retrieve challengers
if(context.serverStatus.challengers) {
config.adaptors.tiddlyweb.challengers = context.serverStatus.challengers;
}
}
};
adaptor.getStatus({ host: host }, null, statusCallback);
})();
//}}}
/***
|''Name:''|ValueSwitcherPlugin|
|''Description:''|Gather values from a definition tiddler, and present the user with a UI for setting a value from those available options as an extende field |
|''Version:''|0.2|
|''Date:''|25 Sept, 2007|
|''Source:''|http://www.hawksworx.com/playground/TeamTasks/#ValueTogglerPlugin|
|''Author:''|PhilHawksworth (phawksworth (at) gmail (dot) com)|
|''License:''|[[BSD open source license]]|
|''CoreVersion:''|2.3|
***/
//{{{
// Ensure that this Plugin is only installed once.
if(!version.extensions.ValueSwitcher)
{
version.extensions.ValueSwitcher = {installed:true};
config.macros.ValueSwitcher = {
handler: function(place,macroName,params,wikifier,paramString,tiddler) {
var fieldPrefix = "tt_";
var taskTiddler = story.findContainingTiddler(place);
if(!(taskTiddler && taskTiddler != 'undefined')) {
return;
}
var params = paramString.parseParams("anon",null,true,false,false);
var ctrlType = getParam(params,"type",null);
var id = taskTiddler.id;
var title = id.substr(7);
var tiddler = store.getTiddler(title);
// build a drop down control
if(ctrlType == 'dropdown') {
var valueSrc = getParam(params,"valuesSource", null);
if(!valueSrc) {
displayMessage("No definition tiddler defined for a TeamTasks dropdown.");
return;
}
var fieldName = fieldPrefix + valueSrc.toLowerCase().substr(0,valueSrc.length-11);
var selected = fieldName + '::' + store.getValue(tiddler,fieldName);
var values = this.getDefValues(valueSrc);
var options = [];
options.push({'caption': 'Please select', 'name': null});
for (var i=0; i < values.length; i++) {
options.push({'caption': values[i], 'name': fieldName + '::' + values[i]});
}
createTiddlyDropDown(place,this.setDropDownMetaData,options,selected);
}
// Build a free text box.
else if(ctrlType == 'freetext') {
var metaDataName = getParam(params,"metaDataName", null);
if(!metaDataName) {
displayMessage("No metaDataName defined for a TeamTasks free text box.");
return;
}
var fieldName = fieldPrefix + metaDataName.toLowerCase();
var text = store.getValue(tiddler,fieldName);
if(text == undefined) text = "";
var i = createTiddlyElement(place,"input",null,null,null,{"value":text, "type":"input", "ttname":fieldName});
i.onblur = config.macros.ValueSwitcher.changeFreetext;
}
/*
TODO: Build in deadline support
*/
},
//Get definition values for populating UI from definition tiddlers.
getDefValues: function(src) {
var text = store.getTiddlerText(src).split('\n');
var output = [];
for(var t=0; t<text.length; t++) {
//support calling the old TaskViewBuilder macro to list the tasks here too.
var blob = wikifyStatic(text[t],null,tiddler,null);
var linktitle = /tiddlylink="[^"]*"/mg;
var titles = blob.match(linktitle);
if(titles) {
for(var n=0; n<titles.length; n++) {
output.push(titles[n].replace(/tiddlylink="([^"]*)"/,'$1'));
}
}
else {
output.push(text[t]);
}
}
return (output);
},
// Ensure that changes to a dropdown field are stored as an extended field.
setDropDownMetaData: function(ev) {
var e = ev ? ev : window.event;
var taskTiddler = story.findContainingTiddler(this);
if(taskTiddler && taskTiddler != undefined) {
var title = taskTiddler.getAttribute('tiddler');
var tiddler = store.getTiddler(title);
var option = this[this.selectedIndex].value.split('::');
var extField = option[0];
var extFieldVal = option[1];
store.setValue(tiddler,extField,extFieldVal);
story.saveTiddler(title);
}
},
// Ensure that changes to a free text field are stored as an extended field.
changeFreetext: function(ev) {
var e = ev ? ev : window.event;
var ttField = this.getAttribute('ttname');
var value = this.value;
if(ttField) {
var t = story.findContainingTiddler(this);
var title = t.getAttribute('tiddler');
var tiddler = store.getTiddler(title);
store.setValue(tiddler,ttField,value);
story.saveTiddler(tiddler);
}
return false;
}
};
}
//}}}
The User Story is the basic unit of scope in an Agile project. During the project each UserStory is progressively elaborated from being little more than a one-line description through to a set of [[AcceptanceCriteria]]. For an overview of what happens to a UserStory over time take a look at [[UserStoryLifecycle]].
User Stories have these significant aspects:
* Describes a WHO, WHAT, and WHY scenario ( As a WHO, I want to WHAT, so that WHY ).
* Describes real business value
* Conversations in order to flesh out details of story
* AcceptanceCriteria that provide detail and can be used to determine when the story is complete
* Progress - The [[Customer]] accepts the story as a sign of progress toward their larger goal.
!Use of index cards
Index cards are particularly useful during interactive sessions such as the PlanningGame because they are tactile and can be re-arranged and viewed by all present (see section below).
The card is only the beginning of the process of defining the user story. The conversations to flesh out the detail of the story are the most important aspect of user stories.
!Why User Stories?
* Stories are concise and to the point, helping everyone to remain Focussed
* As a “promise for a conversation�, stories encourage customer collaboration and face-to-face conversations (Communication)
* Stories allow the Customer and development to discuss requirements over the project lifetime, helping us to collectively discover what is really required (Feedback)
* Stories require very little maintenance (Simplicity)
* Stories are a form of documentation that provide positive business value as their evolutionary creation means they are useful and relevant
!How to write a User Story
The main sections on the pre-printed index cards are:
* Title
User Story Title
* As a....
This describes who requires this story.
* I want to ...
A description of what is required. A statement of the problem (Opportunity) to be solved – not the solution
* So that.....
A description of why this story is needed. What is the business benefit if this problem is solved. It is imperative that this section of the card is completed so that we can focus the user on why they are asking for this feature/functionality.
On the back of the card :
* Acceptance Criteria
The AcceptanceCriteria describe the tests/conditions which need to pass in order to determine when the story is complete.
Other Boxes on the card:
* Size (Cost)
During the planning session the people who will be actually implementing the story estimate a size for the story to allow them to be allocated to a release or iteration.
The size does not have to be in days it can be a relative value. For example:
Ranking from 1-4, 1 being the smallest estimate and 4 being impossible to estimate with the currently available information. The size can then be associated with estimated number of days
** 1 = 1-2 days
** 2 = 3-4 days
** 3 = 5 days
** 4 = 99 (impossible to put realistic estimate on)
* Priority
Using both the business value defined by the customer and the size estimated by the development team the priority of the story can be determined. The business user places a priority on the story to allow stories in the release / iteration to be prioritised so that the most valuable story can be identified.
! Characteristics of a good UserStory
The following provides an easy way of remembering the characteristics of a good UserStory – INVEST.
!!Independent
Its easiest to work with stories that don’t overlap so that they can be independently prioritised and implemented in any order.
This is often difficult in practice
!!Negotiable
* It offers enough flexibility to allow the Customer and Development to work together to collectively discover what is really required at the time the story is being implemented
* It needs to capture the concept not the details (the problem, not the solution)
!!Valuable/Vertical
* Must be valuable to the customer.
* In order to be Valuable to the Customer, it usually needs to be a Vertical slice of a system.
!!Estimatable
* Understood well enough, and of an adequate size, to be estimated
!!Small
* This depends on what level your talking: Project, Release or Iteration level stories
* An Iteration story can usually be accomplished in days
* A Release story can usually be accomplished in weeks
* A Project story can usually be accomplished in months
!!Testable
You can write AcceptanceCriteria to assert the behaviour of the UserStory .
!More information
The book [[User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series); Mike Cohn|http://www.amazon.com/exec/obidos/tg/detail/-/0321205685/ref=pd_sim_b_1/002-7900535-2845645?_encoding=UTF8&v=glance]] is an excellent introduction and practical guide to getting the most out of UserStories .
!Example Card
An example of a UserStory written on an index card is shown below:
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/storycardexample.jpeg]]
This diagram illustrates how the UserStory is elaborated during the project, forming a [[Narrative]]. ElaboratingRequirements gives a description of the benefits of this approach.
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/userstoryelaboration.jpeg]]
The Delivery Manager manages a part of the delivery of the overall project, working to a [[ProjectManager]].
General online resources and books about Agile practices.
!Online Resources
[[The Agile Manifesto|http://www.agilemanifesto.org/]]
[[The Agile Alliance|http://www.agilealliance.org/home]]
[[Martin Fowler's website|http://www.martinfowler.com/]]
[[Agile Software Development on the C2 Wiki|http://c2.com/cgi/wiki?AgileSoftwareDevelopment]]
[[Scrum|http://www.controlchaos.com/]]
[[Extreme Programming|http://www.extremeprogramming.org/]]
[[Ron Jeffries' website|http://www.xprogramming.com/]]
[[Alistair Cockburn's Crystal Wiki|http://alistair.cockburn.us/crystal/wiki/FrontPage]]
[[David J. Anderson's website|http://www.agilemanagement.net/index.html]]
[[Scott W. Ambler's Agile Data website|http://www.agiledata.org/]]
[[Open Source Testing|http://opensourcetesting.org/functional.php]]
[[Bret Pettichord's Agile Testing website|http://www.pettichord.com/]]
!Books
[[Refactoring: Improving the Design of Existing Code; Martin Fowler et al|http://www.amazon.com/exec/obidos/tg/detail/-/0201485672/qid=1057861361/sr=1-1/ref=sr_1_1/002-7900535-2845645?v=glance&s=books]]
[[Test Driven Development: By Example; Kent Beck|http://www.amazon.com/exec/obidos/tg/detail/-/0321146530/ref=pd_sim_b_4/002-7900535-2845645?_encoding=UTF8&v=glance]]
[[Agile Software Development, Principles, Patterns, and Practices; Robert C. Martin|http://www.amazon.com/exec/obidos/tg/detail/-/0135974445/ref=pd_sim_b_3/002-7900535-2845645?_encoding=UTF8&v=glance]]
[[Agile and Iterative Development: A Manager's Guide; Craig Larman|http://www.amazon.com/exec/obidos/tg/detail/-/0131111558/ref=pd_sim_b_3/002-7900535-2845645?_encoding=UTF8&v=glance]]
[[Agile Project Management : Creating Innovative Products (Agile Software Development Series); Jim Highsmith|http://www.amazon.com/exec/obidos/tg/detail/-/0321219775/ref=pd_sim_b_2/002-7900535-2845645?_encoding=UTF8&v=glance]]
[[User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series); Mike Cohn|http://www.amazon.com/exec/obidos/tg/detail/-/0321205685/ref=pd_sim_b_1/002-7900535-2845645?_encoding=UTF8&v=glance]]
[[Agile Software Development with SCRUM; Ken Schwaber, Mike Beedle|http://www.amazon.com/exec/obidos/tg/detail/-/0130676349/ref=pd_sim_b_6/002-7900535-2845645?_encoding=UTF8&v=glance]]
[[Extreme Programming Explained: Embrace Change; Kent Beck|http://www.amazon.com/exec/obidos/ASIN/0201616416/ref=pd_sxp_elt_l1/002-7900535-2845645]]
[[Test-Driven Development in Microsoft .NET (Microsoft Professional); James W. Newkirk, Alexei A. Vorontsov|http://www.amazon.com/exec/obidos/ASIN/0735619484/qid=1086899062/sr=2-1/ref=sr_2_1/002-7900535-2845645]]
[[Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results; David J. Anderson|http://www.amazon.com/exec/obidos/tg/detail/-/0131424602/ref=pd_sxp_f/002-7900535-2845645?v=glance&s=books]]
[[Managing Agile Projects; Sanjiv Augustine|http://www.amazon.co.uk/exec/obidos/ASIN/0131240714/qid=1117730914/sr=1-3/ref=sr_1_8_3/026-3936900-4818849]]
[[Agile Software Development; Alistair Cockburn|http://www.amazon.co.uk/exec/obidos/ASIN/0201699699/qid=1117730770/sr=1-1/ref=sr_1_11_1/026-3936900-4818849]]
[[Agile Software Development Ecosystems; Jim Highsmith|http://www.amazon.co.uk/exec/obidos/ASIN/0201760436/qid=1117730850/026-3936900-4818849]]
[[Patterns of Enterprise Application Architecture; Martin Fowler et al|http://www.amazon.com/exec/obidos/tg/detail/-/0321127420/ref=pd_sxp_f/104-5429656-3021524?v=glance&s=books]]
[[Domain - Driven Design: Tackling Complexity in the Heart of Software; Eric Evans|http://www.amazon.com/exec/obidos/tg/detail/-/0321125215/ref=pd_sim_b_6/104-5429656-3021524?_encoding=UTF8&v=glance]]
[[Lessons Learned in Software Testing; Cem Kaner, James Bach, Bret Pettichord|http://www.amazon.com/exec/obidos/tg/detail/-/0471081124/ref=ase_bretpettichossof/102-6223347-9468143?v=glance&s=books]]
CommonCodeOwnership is a code-specific term for CollectiveOwnership
This is a walk through of an Agile project, from the [[Customer]] perspective, detailing the involvement that the [[Customer]] will have over the [[TimeboxedDeliveryCycle]].
The HotHouse runs over days one to three of the [[TimeboxedDeliveryCycle]]. The focus of the AgileCookbook and this CustomerWalkthrough is days four to ninety.
If the [[Customer]] has limited or no time, then they can nominate a CustomerProxy (often a BusinessAnalyst) to perform these roles on their behalf. The [[Customer]] will then receive updates from the CustomerProxy as an when are required.
!After the HotHouse - IterationZero, day four
After the HotHouse, from day four, there may need to be some initial work in order to be able to move into the first DevelopmentIteration cycle. This tends to be more likely with a new piece of software, in a new environment, or with a largely new team. Instead of allowing this 'start-up' work to affect the first DevelopmentIteration, the ProjectManager schedules an IterationZero. Activities that the [[Customer]] or the CustomerProxy may need to be involved in at this stage are:
* Constructing the MasterStoryList, this will be the primary record for ScopeManagement. It is important that each UserStory should be decomposed until it could be developed within a period of a week if possible. It is very important that they all be of roughly similar estimate size - this allows very simple and accurate tracking and reduces the impact of poorly estimated stories.
* PrioritisingRequirements according to BusinessValue. At this stage you may not need to prioritise every UserStory, remember you only need to do enough planning in order to be able to start your first DevelopmentIteration and prepare a ReleasePlan.
* Help the ProjectManager in preparing a ReleasePlan, showing how much can be achieved within the [[TimeboxedDeliveryCycle]].
!Before each DevelopmentIteration
The [[Customer]], or the CustomerProxy, should:
* Attend the IterationPlanningMeeting scheduled by the ProjectManager
* Attend the IterationKickOff scheduled by the ProjectManager
!During each DevelopmentIteration
The [[Customer]], or the CustomerProxy, should not be required during the DevelopmentIteration. However, in exceptional circumstances they may be called on to clarify UserStories. Although this usually points to a lack of completeness in an earlier stage. The OneTruthRepository should ideally be the source of clarifications.
!After each DevelopmentIteration
* Confirm that the iteration has delivered WorkingSoftware which satisfies their BusinessValue
* This WorkingSoftware is demonstrated to the [[Customer]] at a [[Showcase]]
* Sign-off the delivery
* Attend the IterationRetrospective scheduled by the ProjectManager
!At the end of the [[TimeboxedDeliveryCycle]]
* Accept the release of the cumulative WorkingSoftware built up during previous iterations.
It is important to note that this final release is not a big bang release, as it is merely the results of the final iteration's work added onto the existing WorkingSoftware developed in previous iterations.
The 'size' of a UserStory represents the estimated amount of effort required for the [[Developer]] team to delivery the functionality that it represents. The two methods used most frequently to estimate the size of stories are [[StoryPoints]] and [[IdealDays]].
The use of a [[wiki|http://c2.com/cgi/wiki?WikiWikiWeb]] provides an AgileTeam with an easily accessed and updated forum for communication and collaboration. It is particularly useful to a distrbuted team.
Many teams use a ProjectWiki to document:
* team member contact information
* design decisions
* ProjectTracking information
* team standards
* frequently asked questions
* release history
* details of testing environments available
* instructions for new team members
If you wish to contact the Agile Cookbook team then please email us on ((need something different here))
A [[Huddle]] is an informal meeting of a subset of the project team.
Often the [[Developer]] team will hold a short [[Huddle]] after the DailyStandUp meeting in order to talk through development specific issues that were raised during the DailyStandUp. A [[Designer]] may use a [[Huddle]] to collaborate with the [[Developer]] team on a design issue.
The AgilePractices listed here are what has been determined to be the core set of practices for the adoption of Agile. Programs which adopt all of these practices will be deemed to be practicing Agile.
!1) Iterative Development
Agile projects base delivery of software and other project outcomes around fixed periods of time called Iterations. Specifically, software is delivered in a series of [[DevelopmentIteration]]s of equal duration. Other non-software deliverables can benefit from an iterative approach to delivery. The necessary conditions being that each Iteration should deliver a measurable, concrete result - preferably with a clear associated [[BusinessValue]]. In some cases this may simply mean a phased implementation, however it is preferable to attempt to incrementally deliver testable working product at the end of each iteration in order to benefit from the associated early feedback and testing. Iterative delivery is based on the principles of Lean Manufacturing, as described in [[this article by Mary Poppendieck|http://www.poppendieck.com/lean.htm]] - and as such is very applicable to non-software projects.
* What is Good: Each DevelopmentIteration will be planned and reviewed separately allowing for frequent adaptation to changing priorities. All code written in an iteration will have been designed, tested and accepted by the end so, theoretically, the code could be released at the end of the iteration if required. An IterationPlanningMeeting, IterationKickOff and IterationRetrospective should be held for each [[DevelopmentIteration]].
* What is Excellent: In addition to the above, each DevelopmentIteration will deliver a "vertical slice" of the overall functionality. For example in an online banking scenario, iteration one may develop just the statements, iteration two may develop just the payments facility from front end to persistence. Each DevelopmentIteration should be no longer than two weeks in duration.
!2) Automated Testing
Automated testing is emphasised in Agile projects because of the rapid pace of change and the necessity to be able to deliver WorkingSoftware frequently. Practices such as TestDrivenDesign and TestDrivenDevelopment as well as ContinuousIntegration all benefit from automated tests. The underlying principle is the efficient delivery of timely feedback. In the case of hardware, the term 'smoke-test' is often used to describe powering up the device to see if it emits smoke - which would indicate a defect. Look for opportunities to provide feedback in cost-effective ways in all areas of your project, not just software development. For example the DailyStandUp meeting provides timely feedback to the whole team on progress and issues, for the cost of 10-15 minutes of time per day.
* What is Good: AutomatedUnitTests are written alongside code. AutomatedUnitTests are included in a DailyBuild and can be run by developers on their workstation prior to checking in code to prevent regression. AutomatedAcceptanceTests for the UserStories delivered in a DevelopmentIteration are completed by the end of the following DevelopmentIteration, and can be run against the code in a dedicated test environment.
* What is Excellent: AutomatedUnitTests provide greater than 80% code coverage. AutomatedUnitTests and AutomatedAcceptanceTests are included in the ContinuousIntegration build and run every time code is checked in.
!3) Continuous Integration
ContinuousIntegration refers to a fully automated build and test process that allows a team to build and test their software many times a day. The first step on the way to ContinuousIntegration is sometimes a [[DailyBuild]]. ContinuousIntegration underpins LoweringTheCostOfChange to allow late changes in requirements or structual improvements to be safely incorporated into the software. The underlying principle is that if the entire system is re-validated after every small change, then it is easy to identify the cause of any issue and resolve it. This principle can be applied to non-software development work wherever an opportunity to efficiently test after each change can be identified.
* What is Good: An automated, IDE independent DailyBuild incorporating (compile, test, build, deploy), running on a dedicated environment (not a developer workstation). The DailyBuild must be executed against the latest set of clean source code checked out from the [[SourceControlRepository]]. All source code must be stored in a SourceControlRepository, including build scripts, configuration files, test code, database setup scripts and anything else that would be required to build and install the software on a new environment. Any broken tests or other issues with the DailyBuild are addressed as a priority, ahead of implementing new functionality.
* What is Excellent: An automated, IDE independent ContinuousIntegration build incorporating (compile, test, build, deploy), which runs after each check-in to the [[SourceControlRepository]]. Any broken tests or other issues with the build are addressed as a priority, ahead of implementing new functionality. Developers run tests locally on their own workstations prior to checking in code to avoid breaking the build.
!4) User Stories
The UserStory is the basic unit of scope in an Agile project. During the project each UserStory is progressively elaborated from being little more than a one-line description through to a set of [[AcceptanceCriteria]]. UserStories are a very effective mechanism for decomposing requirements into prioritised, testable, estimatable bite-sized pieces of work. As such they can be used in many non-software development projects, in fact - they were used to drive the delivery of this Cookbook.
* What is Good: A user story is written in the context of the value a feature would give an end user of the system. A standard way of writing them could be… As [insert user] I need to [insert feature] so that [insert business value].
User stories are initially 1-2 lines long and contain enough detail to be testable, and provide an estimate and priority. Additional detail is added prior to the DevelopmentIteration in which the UserStory will be delivered. Each UserStory should be of a size that would allow it to be completed within the period of one [[DevelopmentIteration]].
* What is Excellent: In addition to the above, each UserStory should have predefined acceptance criteria which can be transformed into [[AutomatedAcceptanceTests]]. Each UserStory should be sized such that a [[Developer]] could complete two of them in a single [[DevelopmentIteration]]. Each UserStory should have a clear BusinessValue associated with it.
!5) Customer Involvement
Agile methods consitently emphasise ongoing involvment of the [[Customer]] or CustomerProxy with the delivery/development team throughout the iterations, providing constant input and feedback. This is consistent with project managment practices that span all types of delivery, from software through to tailoring a bespoke suit or designing an office building. Regular provision of deliverables that allow the [[Customer]] and other important stakeholders to give informed feedback is critical to the success of any project, preventing the product from diverging from the [[Customer]]s vision, and ensuring effort is directed at those areas giving the greatest return on investment.
Having close collaboration with an empowered [[Customer]] improves productivity, since the time spent waiting for decisions to be made or recovering from incorrect assumptions is greatly reduced.
* What is Good: The [[Customer]] will play an active part in the IterationPlanningMeeting, IterationKickOff and IterationRetrospective sessions, providing feedback on current development and re-evaluating priorities. Rather than attempting to produce an exhaustive requirements spec up front, the customer will commit to elaborating on requirements as and when necessary in conjunction with the developers.
* What is Excellent: An empowered [[Customer]] (or CustomerProxy) co-located with team and involved day-to-day. The [[Customer]] works closely with the BusinessAnalyst team to elaborate UserStories and set [[AcceptanceCriteria]].
The BuildMaster is usually a [[Developer]] who has specific experience and skills in setting up and maintaining a ContinuousIntegration environment.
In general the ContinuousIntegration build for a project tends to be quite specific to that project. However an experienced BuildMaster can greatly assist with advice and assistance on tools and techniques for introducing and improving build automation.
One of the distinct advantages of an iterative approach is that it provides excellent tracking data that can be used to project into the future. Each DevelopmentIteration provides a data point which allows projection of likely completion date from the second iteration, using the principle of YesterdaysWeather.
UserStories are used as the basis for providing the metrics. In the diagram below, the total scope is defined as the sum of the estimated sizes of the UserStories in the MasterStoryList at the start of each iteration. RespondingToChange means that this total scope will vary over the project.
Progress is measured through the achieved [[Velocity]] delivered in each DevelopmentIteration. UserStories are only counted if they pass their AcceptanceCriteria and therefore count as WorkingSoftware. Previously delivered UserStories are protected by AutomatedAcceptanceTests.
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/progressTracking.jpeg]]
[[Velocity]] can be used to extrapolate over future iterations to produce a burn-down or burn-up chart like the one shown below. These charts are used to track and predict how the project is performing against its target delivery date and scope.
[img[http://agilecookbook.com/uploads/workspace/default/releasetrackinggraph.jpg]]
This is a walk through of an Agile project, from the [[Developer]] perspective, detailing the activities that the [[Developer]] will have a significant role in.
The HotHouse runs over days one to three of the [[TimeboxedDeliveryCycle]]. The focus of the AgileCookbook and this [[DeveloperWalkthrough]] is days four to ninety.
!After the HotHouse - IterationZero, day four
* Prepare the development environment
** IDE independent Automated Build
** SourceControlRepository
* Configure the ContinuousIntegration environment
* Agree on initial CodingStandards
!Before each DevelopmentIteration
* Provide estimates for the cards in the IterationPlanningMeeting
* Validate and sign up for UserStories in the IterationKickOff
!During each DevelopmentIteration
* Convert AcceptanceCriteria into AutomatedAcceptanceTests
* Foster CollectiveOwnership by PairProgramming
* Use TestDrivenDesign to achieve a SimpleDesign, and LoweringTheCostOfChange
* Use [[Refactoring]] to improve the design of existing code
* Present the UserStory for ProgressiveSignOff when it meets the AcceptanceCriteria, evidenced by passing all AutomatedAcceptanceTests
!After each DevelopmentIteration
* Consider the progress made, in the IterationRetrospective
* Look for ways to improve the technical and process practices
* Monitor the performance of the ContinuousIntegration build. If this degrades, it has high impact on the team's productivity
!At the end of the [[TimeboxedDeliveryCycle]]
The AgileManifesto was the result of a meeting in 2001 between the signatories listed below. It succinctly expresses the core values upon which Agile practices and methodologies are founded. It is supported by a number of AgilePrinciples, which give context to the values.
''Manifesto for Agile Software Development''
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
* IndividualsAndInteractions //over// processes and tools
* WorkingSoftware //over// comprehensive documentation
* CustomerCollaboration //over// contract negotiation
* RespondingToChange //over// following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
The [[Customer]] is responsible for PrioritisingRequirements to ensure that the most important BusinessValue is delivered early. This is illustrated in the diagram below:
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/businessvalueprioritised.jpeg]]
PrioritisingRequirements is commonly achieved by reviewing the UserStories in the MasterStoryList and reordering these. It is also performed during the PlanningGame and at the IterationPlanningMeeting.
It is important to ensure that the person or body that can efficiently deal with questions of priority is well identified and known. At a project level, this should be the [[Customer]] - if you're using a [[CustomerProxy]] then priorities should be confirmed with the [[Customer]] regularly.
There are often cross-project or indeed cross-program prioritisation issues, and it is vital that there be a well defined and timely escalation path for these issues. A common approach used to facilitate this kind of issue resolution is to have a weekly or bi-weekly meeting between representatives of the projects or programs to decide questions of priority. It's important that these meetings include the [[Customer]] if at all possible. This group should delegate as much prioritisation authority as possible and act as a conflict resolver, rather than impose a control mechanism on all decision making.
Agility relies heavily on the capability to make timely decisions about priority, delays or indecision in this area can compromise productivity quite severely. Most teams will, if faced with inability to prioritise, go ahead with whatever seems appropriate - which can lead to wasted effort.
[img[http://agilecookbook.com/uploads/workspace/default/StoryLifecycle.jpeg]]
This morning i arrived at work around 08h30. After having a quick look through my new emails, I checked the state of the continuous integration build. "Build Failed", 3 test failures, not particularly good news. It's a shame to start the day tracking down the cause of a build failure, but it must be done. I found that someone had managed to BreakTheBuild last night, by checking in a change without changing the expectations in a test (they obviously didn't run all the tests before checking in). I fixed the failure, and organised my small stack of cards for the DailyStandUp as I waited for a new build.
The IterationManager started the stand up with a brief summary of progress this iteration. We signed up for 12 stories, and we have 4 not yet signed off. Looks like we are doing ok, as we are only half-way through the iteration. I guess the BAs will spend a little time making sure there are a few bonus-cards ready for development, just in case we finish early. We've got a small, stuffed toy fish we pass around the stand up, as a speaking token. We don't pass it in a predictable order, so you have to pay attention, or you'll drop the fish when it is passed to you. Dan, one of the developers asked for a pair to tackle a story in a part of the system I know quite well, so I offered to share some of my experience there. We agreed to do that straight after the standup. Another developer, Sam, asked if anyone knew about a problem he had been experiencing. I knew what he was talking about, and it was only a ten second answer, so I told him right there. That way, everyone else got to hear the simple version, and they know to ask me if they have the same problem. If it was going to take any longer, we would have scheduled to chat about it later. When My turn came, I flipped through the stack of cards in my hand. I gave a brief update of the status of each card I worked on yesterday: "234 - User name case sensitive: signed off", "241 - password can contain special characters: in integration testing". I then indicated what I intended doing today, and Sam agreed to pair with me after lunch.
As agreed in the stand up, I pulled up a chair next to Dan. I didn't take my laptop, as it would only provide distractions. We sat at his machine, and prepared to tackle the UserStory he had signed up for. As there might have been significant changes in the system since he had last checked in to the SourceControlRepository, our first move was to check out a clean version of the code. If we had begun working on an old version of the code, we would only have made it more difficult for ourselves. We started by writing the AutomatedAcceptanceTests as described in the AcceptanceCriteria, so that we would know when we were done. These are fairly high level tests that exercise the application and verify the features at a functional level. When we ran this, it failed, as the required feature had not yet been added (if it had passed, we would have saved ourselves the trouble of going looking for code to change - if it already works, leave it alone). Once we had the AutomatedAcceptanceTests in place, we could be sure that the feature we were resposible for implementing would exist in every future successful build (the build would be broken until it was added, and thereafter, it's regression would be prevented). And now that we knew what the first failure was, we could begin looking to make the required changes in the code.
We started drilling in to the code base to find the class we would be modifying. We then found the AutomatedUnitTests for that class and ran them once, just to be sure that all was working as expected. Then we added a test which we thought would fail (as we had not yet written the code). We were right. All this time, I had been "driving" the keyboard and mouse, with Dan gently pointing out my syntax errors and prompting me with suggestions. So I pushed the keyboard over to Dan, and told him it was his turn "to drive". He found the piece of code we needed to change, and made a very simple change to allow our new test to pass. He then ran all the tests again, and we had all passing tests. So we wrote another failing test exposing a missing piece of functionality, and made it pass. Then several more, until we were confident that the changes to that class would alter the behaviour of the system sufficiently to make the AutomatedAcceptanceTests pass. We ran them, and they passed. We checked the new tests and the changed code into the SourceControlRepository, but only after running a complete build on our development machine. This ensured that we had not unwittingly broken anything else. We waited a few minutes for our ContinuousIntegration build to complete successfully before handing over the card to the [[Tester]], and heading off for lunch.
After lunch, I responded to a few urgent emails, and then called Sam over to begin the PairProgramming on the UserStory I had signed up for. It all went well, writing tests and sharing the "driving", until we realised that the UserStory did not have enough detail about how the feature was expected to behave. So, we asked the BusinessAnalyst to explain the finer points of the requirements. Some of the scenarios we were catering for were complex, so we had a quick chat with the [[Customer]] and one of the SubjectMatterExperts until we all understood what was required. By the end of the afternoon we had captured all the requirements in test cases, and checked them into the SourceControlRepository. These tests will serve as specification for that feature.
As Sam was coding the solution to one of the failing tests, I noticed that the code he was writing was very similar to code I had seen elsewhere, so we had a look around, and identified the two pieces of duplicate logic. It was easy to extract a method from the one instance, and call that method from both places. I think that this small refactoring will save us time in future, as we have simplified the design, and any changes will only need to be made in the one place.
We finished adding the functionality, and ran a full build and test before trying to check in. Before checking in, we did an update, and found that another pair had worked on the same classes and we had a conflict. No big problem, though. We merged the changes to the code and the tests (very important to ensure that all the functioanlity is protected from regression), and ran another full build and test. No failures, so we checked in, and and handed it over to be tested.
It's just gone five, and I'll be leaving just as soon as the ContinuousIntegration build completes. I wouldn't want to be the one to leave the rest of the team with a broken build.
Supports the ability to provide one consistent answer to important questions about the project.
This isn't necessarily a single tool or repository. The SourceControlRepository should be the OneTruthRepository regarding which version of any artefact is the 'true' version. However, If the ProjectTracking was being performed in a spreadsheet, then that spreadsheet is the OneTruthRepository for project status (and should be checked into the SourceControlRepository to eliminate any question as to where to find the 'current' version of that spreadsheet).
To determine which UserStories will be scheduled for Analysis during the coming DevelopmentIteration. The BusinessAnalysts will be working on the UserStories for the subsequent iteration, while development proceeds on the current iteration. This meeting can also be an excellent opportunity to discuss any new requirements that have been discovered and prioritise them accordingly.
The IterationPlanningMeeting is an example of the PlanningGame.
!Who should be involved?
You should include at minimum the ProjectManager or IterationManager, the BusinessAnalyst team, the [[Customer]] and senior representatives of the [[Designer]], [[Developer]] and [[Tester]] teams. Ideally the whole team would be involved - however it may not be practical if your team is large.
The Customer is there to prioritise, the ProjectManager to manage scope, the BusinessAnalyst team to confirm understanding of the work to be done and the representatives of the [[Designer]], [[Developer]] and [[Tester]] teams to provide up-front input to improve the quality of the UserStories.
!When should it be done?
You should hold an IterationPlanningMeeting for each DevelopmentIteration, far enough in advance of the IterationKickOff that the BusinessAnalyst team will have time to prepare sufficient UserStories and AcceptanceCriteria to keep the [[Developer]] team busy.
When and how often you hold this meeting is not so important as the general principle that you should regularly meet with the [[Customer]] or CustomerProxy to confirm the priority of the remaining UserStories.
!What are the benefits?
* By regularly meeting to re-prioritise requirements, the team is able to ensure that they are always working on the most valuable requirements.
* By soliciting input from the [[Designer]], [[Developer]] and [[Tester]] teams prior to the UserStories being elaborated, you can resolve ambiguity and avoid technically infeasible, overly large or untestable UserStories being created. This results in far less splitting or rejection of UserStories at the IterationKickOff and consequently saves re-work by the BusinessAnalyst team.
!Are there any prerequisites?
There are no prerequisites for the IterationKickOff
!How has this been done elsewhere?
[img[http://agilecookbook.com/agilecookbook/uploads/workspace/root/iterationplanning.jpeg]]
!Common pitfalls
These meetings are often longer than strictly required. They need to be focused and time-boxed.
Configuration and deployment of the software onto a server often becomes a specialised and fragile task. Automating the process can be the most effective solution, especially when that automation is regularly tested by being part of a ContinuousIntegration build, or a DailyBuild. AutomatedDeployment can be set up for environments that support User Acceptance Testing, System Testing, and even in some cases for the Production environment.
Here are some examples of Agile in action.
!BT Case Studies
* CaseStudy2 - Use of Agile practices in BT Global Services - NSO Project
!External Case Studies
* CaseStudy1 - Introduction of Agile to an Organisation (Insurance, New Product Development)
Ideal Days are a unit of measure in the estimation of [[UserStories]]. They are used to estimate the amount of time, in days, that should be required to complete a story, if the developers had no other distractions. The time to actually complete the story is often referred to as a RealDay. The distinction between these two arose out of the recognition that developers will always face distractions, but are hard-pressed to be able to estimate those distractions accurately.
At the completion of a [[DevelopmentIteration]], the sum of the estimated ideal days for the completed cards is considered to be the achieved [[Velocity]]. Using the concept of [[YesterdaysWeather]] the team should choose no more than the achieved velocity for the subsequent iteration.
For initial planning, teams sometimes use a [[LoadFactor]] to estimate how many ideal days the team will be able to achieve within an iteration. This must be validated through the execution of actual iterations.
See also [[StoryPoints]]
/***
|''Name''|ServerSideSavingPlugin|
|''Description''|server-side saving|
|''Author''|FND|
|''Version''|0.5.3|
|''Status''|stable|
|''Source''|http://svn.tiddlywiki.org/Trunk/association/plugins/ServerSideSavingPlugin.js|
|''License''|[[BSD|http://www.opensource.org/licenses/bsd-license.php]]|
|''CoreVersion''|2.5.3|
|''Keywords''|serverSide|
!Notes
This plugin relies on a dedicated adaptor to be present.
The specific nature of this plugin depends on the respective server.
!Revision History
!!v0.1 (2008-11-24)
* initial release
!!v0.2 (2008-12-01)
* added support for local saving
!!v0.3 (2008-12-03)
* added Save to Web macro for manual synchronization
!!v0.4 (2009-01-15)
* removed ServerConfig dependency by detecting server type from the respective tiddlers
!!v0.5 (2009-08-25)
* raised CoreVersion to 2.5.3 to take advantage of core fixes
!To Do
* conflict detection/resolution
* rename to ServerLinkPlugin?
* document deletion/renaming convention
!Code
***/
//{{{
readOnly = false; //# enable editing over HTTP
(function($) {
var plugin;
plugin = config.extensions.ServerSideSavingPlugin = {};
plugin.locale = {
saved: "%0 saved successfully",
saveError: "Error saving %0: %1",
saveConflict: "Error saving %0: edit conflict",
deleted: "Removed %0",
deleteError: "Error removing %0: %1",
deleteLocalError: "Error removing %0 locally",
removedNotice: "This tiddler has been deleted.",
connectionError: "connection could not be established"
};
plugin.sync = function() {
store.forEachTiddler(function(title, tiddler) {
if(tiddler.fields.deleted === "true") {
plugin.removeTiddler(tiddler);
} else if(tiddler.isTouched() && !tiddler.doNotSave() &&
tiddler.getServerType() && tiddler.fields["server.host"]) {
plugin.saveTiddler(tiddler);
}
});
};
plugin.saveTiddler = function(tiddler) {
try {
var adaptor = this.getTiddlerServerAdaptor(tiddler);
} catch(ex) {
return false;
}
var context = {
tiddler: tiddler,
changecount: tiddler.fields.changecount
};
context.workspace = tiddler.fields["server.workspace"];
var req = adaptor.putTiddler(tiddler, context, {}, this.saveTiddlerCallback);
return req ? tiddler : false;
};
plugin.saveTiddlerCallback = function(context, userParams) {
var tiddler = context.tiddler;
if(context.status) {
if(tiddler.fields.changecount == context.changecount) { //# check for changes since save was triggered
tiddler.clearChangeCount();
} else if(tiddler.fields.changecount > 0) {
tiddler.fields.changecount -= context.changecount;
}
plugin.reportSuccess("saved", tiddler);
store.setDirty(false);
} else {
if(context.httpStatus == 412) {
plugin.reportFailure("saveConflict", tiddler);
} else {
plugin.reportFailure("saveError", tiddler, context);
}
}
};
plugin.removeTiddler = function(tiddler) {
try {
var adaptor = this.getTiddlerServerAdaptor(tiddler);
} catch(ex) {
return false;
}
context = { tiddler: tiddler };
context.workspace = tiddler.fields["server.workspace"];
var req = adaptor.deleteTiddler(tiddler, context, {}, this.removeTiddlerCallback);
return req ? tiddler : false;
};
plugin.removeTiddlerCallback = function(context, userParams) {
var tiddler = context.tiddler;
if(context.status) {
if(tiddler.fields.deleted === "true") {
store.deleteTiddler(tiddler.title);
} else {
plugin.reportFailure("deleteLocalError", tiddler);
}
plugin.reportSuccess("deleted", tiddler);
store.setDirty(false);
} else {
plugin.reportFailure("deleteError", tiddler, context);
}
};
plugin.getTiddlerServerAdaptor = function(tiddler) { // XXX: rename?
var type = tiddler.fields["server.type"] || config.defaultCustomFields["server.type"];
return new config.adaptors[type]();
};
plugin.reportSuccess = function(msg, tiddler) {
displayMessage(plugin.locale[msg].format([tiddler.title]));
};
plugin.reportFailure = function(msg, tiddler, context) {
context = context || {};
var desc = context.httpStatus ? context.statusText : plugin.locale.connectionError;
displayMessage(plugin.locale[msg].format([tiddler.title, desc]));
};
config.macros.saveToWeb = { // XXX: hijack existing sync macro?
locale: { // TODO: merge with plugin.locale?
btnLabel: "save to web",
btnTooltip: "synchronize changes",
btnAccessKey: null
},
handler: function(place, macroName, params, wikifier, paramString, tiddler) {
createTiddlyButton(place, this.locale.btnLabel, this.locale.btnTooltip,
plugin.sync, null, null, this.locale.btnAccessKey);
}
};
// hijack saveChanges to trigger remote saving
var _saveChanges = saveChanges;
saveChanges = function(onlyIfDirty, tiddlers) {
if(window.location.protocol == "file:") {
_saveChanges.apply(this, arguments);
} else {
plugin.sync();
}
};
// override removeTiddler to flag tiddler as deleted -- XXX: use hijack to preserve compatibility?
TiddlyWiki.prototype.removeTiddler = function(title) { // XXX: should override deleteTiddler instance method?
var tiddler = this.fetchTiddler(title);
if(tiddler) {
tiddler.tags = ["excludeLists", "excludeSearch", "excludeMissing"];
tiddler.text = plugin.locale.removedNotice;
tiddler.fields.deleted = "true"; // XXX: rename to removed/tiddlerRemoved?
tiddler.incChangeCount();
this.notify(title, true);
this.setDirty(true);
}
};
})(jQuery);
//}}}
CodeDuplication is generally considered a CodeSmell because it typically leads to higher maintenance cost since bugs will need to be fixed twice, more code needs to be tested, etc.
The IterationKickOff is intended to bring the team together and create a CommonVision for the work to be done in the coming DevelopmentIteration.
Often an IterationKickOff is held immediately following the IterationRetrospective for the preceding DevelopmentIteration.
A suggested format for an IterationKickOff is as follows:
* The BusinessAnalyst team present each UserStory scheduled for the coming DevelopmentIteration, along with it's AcceptanceCriteria.
* The [[Developer]] team provide an estimate for each UserStory. This may involve listing the tasks that would be involved in implementing the UserStory and summing the estimates for those.
* If the estimate for a UserStory indicates it might not be able to be completed within the DevelopmentIteration, then the UserStory may be split or referred for additional analysis.
* If the [[Developer]] team can't estimate a UserStory then it should be referred for additional analysis.
* The ProjectManager or IterationManager determine how much of the available work will fit into the coming DevelopmentIteration, using the principle of YesterdaysWeather.
* Each [[Developer]] signs up for the UserStories that they will work on during the DevelopmentIteration. Some teams have a [[Developer]] pair sign up for each UserStory, either method is acceptable.
* Once all of the UserStories have been dealt with, the IterationKickOff is complete.
It will often be the case that a few UserStories will not have been completed in the previous iteration. If you're consistently completing everything that was available then you're probably not working at full capacity. These partly completed UserStories will not have been counted in the previous iteration, even though a large proportion of the work may have been done, since they did not pass the AcceptanceCriteria. The BaselineEstimate used for ProjectTracking for these UserStories won't change. However the [[Developer]] team should give an estimate for the amount of work remaining to be done on each, so that the actual volume of work for this DevelopmentIteration can be derived.
!The Importance of Tools in Agile
One of the most common AgileMyths is that tools are not important in an agile project. This is normally due to the misinterpretation of the one of the agile guiding principals which states: “Individuals and interactions over processes and tools�. This does not intended to say that tools are not important, simply that individuals and interactions are more important. In reality tools are very important and in some cases critical.
The following page gives a high level overview of tools support against the Agile CorePractices followed by a slightly more detailed look at the supporting tools.
REFERENCE MATERIAL:
[[Borland Web Site| http://www.borland.com]]
!Tools & Agile CorePractices
1) Iterative Development
Iteration planning is focused on User Stories which are supported by Starteam
2) Automated Testing
Automated testing is supported by commercial tools such as those from Compuware & Mercury. Open source testing tools such as Selenium are also very popular.
3) Continuous Integration
Continuous integration depends on integration a good for the source control system, a continuous integration application and for build scripts under source control.
4) User Stories
Index cards are the most obvious tool for User Stories, but there are a variety of applications that can manage user stories for Agile projects.
5) Customer Involvement
While the ideal situation is to have continual face to face communication with the customer a variety of collaboration tools are also recommended below.
!Commercial Tools
!Borland Starteam
Starteam is an integrated application for source control from Borland. It promotes team communication and collaboration through centralised control of almost all project assets including files, user stories, changes, defects, risks & issues, releases, requests and builds.
!Borland Together – UML Design Tool
Borland Together is a standard UML design tool. UML is the industry standard for graphically representing designs. While agility will remove some of the formality of UML and the overhead of doing too much up front design, it is still essential for system level designs, sketching ideas, aiding memory and reducing the bus factor. Together provides many simple ways to maintain designs, in some cases totally automating the creation and maintenance of low level designs based on the source code.
Borland Together – Audits & Metrics
Together provides audits and metrics as quality assurance features to continually enforce company standards / conventions and capture real metrics during iterations. Typical audits include poor exception handling, inappropriate use of operators or even formatting issues. Typical metrics help quantify factors such as cohesion, encapsulation, inheritance and complexity.
Borland Together – Automated Documentation Generation
Together automates the creation of documentation including information from UML designs, audits, metrics, code comments or even Caliber requirements. This combined with Together’s ability to automatically maintain the low level UML designs can meet the need for documentation while avoiding unnecessary overhead on the project team.
Borland Together – Design Patterns
Design Patterns provide a proven & elegant way to reuse solutions to commonly encountered programming challenges. Together provides the functionality to implement and maintain patterns in both the design and the source code. It includes preloaded versions of the Gang or Four, Coad Components and many more including the ability to create custom patterns.
!Borland Optimizeit – Code Coverage
Borland Optimizeit Enterprise Suite is a Java profiling tool available from PD&B. It includes CPU and Memory Profiling, Thread Debugging, Application Server Profiling and Code Coverage. Code Coverage is particularly useful to measure the coverage of the unit tests and ensuring it doesn’t fall below a defined threshold.
!Cruisecontrol – Continuous Integration
Cruisecontrol is an open source framework for a continuous build process. It includes, but is not limited to, plugins for email notification, Ant, and Borland Starteam. A web interface is provided to view the details of the current and previous builds.
!Compuware Qacenter – Automated Testing
Compuware Qacenter delivers automated testing products and solutions designed to validate applications running in the full spectrum of environments, isolate and correct problems, and ensure that systems can handle anticipated load before applications go live.
!Mercury Quality Center – Automated Testing
Mercury Quality Center provides a web-based system for automated software quality testing across a wide range of IT and application environments. It is designed to optimize and automate key quality activities, including requirements, test and defects management, functional testing, and business-process testing.
!Open Source Testing Tools
Junit
A regression testing framework typically used by the developer who implements unit tests in Java. REFERENCE MATERIAL: [[Junit Web Site|http://www.junit.org/index.htm]]
Nunit
A regression testing framework typically used by the developer who implements unit tests in any of the .Net languages.
REFERENCE MATERIAL: [[Nunit Web Site|http://www.nunit.org/]]
Httpunit
Httpunit emulates the relevant portions of browser behaviour and allows Java test code (such as Junit) to examine returned pages to verify the functioning of a web site.
REFERENCE MATERIAL: [[Httpunit Web Site|http://httpunit.sourceforge.net/]]
Fitnesse
Fitnesse is an acceptance testing framework that enables customers, testers, and programmers to learn what their software should do, and to automatically compare that to what it actually does do. REFERENCE MATERIAL: [[Fitnesse Web Site|http://fitnesse.org/]]
Abbot
The Abbot framework is a Java library for GUI unit testing and functional testing.
REFERENCE MATERIAL: [[Abbot Web Site|http://java-source.net/open-source/testing-tools/abbot]]
Selenium
Selenium is a test tool for web applications including browser compatibility and system functionality testing.
REFERENCE MATERIAL: [[Thoughtworks Selenium Web Site|http://selenium.thoughtworks.com/index.html]]
!Araxis Merge – Source Code Merging Tool
Araxis Merge is a popular tool for merging and comparing different revisions of various text files, such as program source code, XML and HTML files. BT does not offer any official support for this tool.
REFERENCE MATERIAL: [[Araxis Web Site|http://www.araxis.com/merge/]]
!Database Tools
In an agile project the developer needs to be able to make quick changes to the development database. The following are popular database update tools, but BT does not offer any official support for them.
Aquadata Studio
Aqua Data Studio is a database query tool and administration tool that allows developers to easily create, edit, and execute SQL scripts, as well as browse and visually modify database structures.
REFERENCE MATERIAL: [[Aquafold Web Site|http://www.aquafold.com/]]
Toad
Toad is a powerful, low-overhead tool that makes database and application development faster and easier and simplifies day-to-day administration tasks. Whether you are a database developer, application developer, DBA or business analyst, Toad offers specific features to make you more productive than ever before.
REFERENCE MATERIAL: [[Toadsoft Web Site|http://www.toadsoft.com/]]
!Refactoring Tools
Refactoring provides the ability to improve the design and architecture of an existing code base. This allows rapid evolution of functionality while maintaining a strong design. When making significant change to design and architecture it is critical to use tool automation to do the tedious side of the changes.
Borland Studio for Java
Studio for Java is a tool provided by PD&B that provides various development, design and testing abilities for Java application development. One of the many features is the ability to refactor Java code.
Eclipse
Eclipse is universal tool platform which is probably most famous for it’s IDE functionality. PD&B already provide some support for Eclipse through Borland plugins and plan to extend this support in the future. The Eclipse IDE provides a variety of Java refactoring abilities.
REFERENCE MATERIAL: [[Eclipse Web Site|http://www.eclipse.org/]]
Borland Together
Borland Together is a design tool available from PD&B which provides refactoring abilities at both the source code and design levels.
REFERENCE MATERIAL:
[[Borland Web Site |http://www.borland.co.uk/together/index.html]]
[[Borland Documentation |http://info.borland.com/techpubs/together/]]
!Project Dashboard
Datamart is a PD&B service that is available for the Starteam and Caliber repositories. It can provide a variety of management reports that would facilitate a project dashboard.
!Collaboration Tools
The most popular collaboration tools are ones that are already commonly used such as email, phone calls and white boards.
If Live Meeting and Instant Messenger are not already being used then adoption is recommended because they quickly become critical in any agile project.
Wiki’s are a powerful utility providing careful consideration is given to their usage. The structure needs to be carefully controlled and they should only be used for collaboration purposes, not storing project artefacts.
The Starteam One Truth Repository is one of the first tools that an agile project needs to get up and running to facilitate many of the agile practices including collaboration.