feat(guide): Import guide in to the client app

This commit is contained in:
Bouncey
2018-10-04 14:47:55 +01:00
committed by Stuart Taylor
parent 2723a943c9
commit 6e728ce16d
4338 changed files with 148283 additions and 4200 deletions

4
.gitignore vendored
View File

@ -15,5 +15,5 @@ node_modules
.DS_Store
curriculum/dist/
client/static/js/frame-runner*.js
curriculum/dist
client/static/js/frame-runner*

View File

@ -1,16 +1,19 @@
import React from 'react';
import React, { Component } from 'react';
import PropTypes from 'prop-types';
import { Provider } from 'react-redux';
import { createStore } from './src/redux/createStore';
import AppMountNotifier from './src/components/AppMountNotifier';
import GuideNavigationContextProvider from './src/contexts/GuideNavigationContext';
const store = createStore();
export const wrapRootElement = ({ element }) => {
return (
<Provider store={store}>
<GuideNavigationContextProvider>
<AppMountNotifier render={() => element} />
</GuideNavigationContextProvider>
</Provider>
);
};

View File

@ -1,6 +1,6 @@
const path = require('path');
const { buildChallenges$ } = require('./utils/buildChallenges');
const { buildChallenges } = require('./utils/buildChallenges');
module.exports = {
siteMetadata: {
@ -28,20 +28,21 @@ module.exports = {
resolve: 'fcc-source-challenges',
options: {
name: 'challenges',
source: buildChallenges$
source: buildChallenges
}
},
{
resolve: 'gatsby-source-filesystem',
options: {
name: 'introductions',
path: path.resolve(__dirname, './src/introductions')
path: path.resolve(__dirname, './src/pages')
}
},
{
resolve: 'gatsby-transformer-remark',
options: {
plugins: [
'gatsby-remark-fcc-forum-emoji',
{
resolve: 'gatsby-remark-prismjs',
options: {
@ -70,6 +71,46 @@ module.exports = {
]
}
},
{
resolve: 'gatsby-remark-node-identity',
options: {
identity: 'guideMarkdown',
predicate: ({ frontmatter }) => {
if (!frontmatter) {
return false;
}
const { title, block, superBlock } = frontmatter;
return title && !block && !superBlock;
}
}
},
{
resolve: 'gatsby-remark-node-identity',
options: {
identity: 'blockIntroMarkdown',
predicate: ({ frontmatter }) => {
if (!frontmatter) {
return false;
}
const { title, block, superBlock } = frontmatter;
return title && block && superBlock;
}
}
},
{
resolve: 'gatsby-remark-node-identity',
options: {
identity: 'superBlockIntroMarkdown',
predicate: ({ frontmatter }) => {
if (!frontmatter) {
return false;
}
const { title, block, superBlock } = frontmatter;
return title && !block && superBlock;
}
}
},
'fcc-create-nav-data',
{
resolve: 'gatsby-plugin-manifest',
options: {

View File

@ -1,14 +1,26 @@
require('dotenv').config();
const { createFilePath } = require('gatsby-source-filesystem');
const { dasherize } = require('./utils');
const { blockNameify } = require('./utils/blockNameify');
const { createChallengePages, createIntroPages } = require('./utils/gatsby');
const {
createChallengePages,
createBlockIntroPages,
createSuperBlockIntroPages,
createGuideArticlePages
} = require('./utils/gatsby');
exports.onCreateNode = function onCreateNode({ node, actions }) {
const createByIdentityMap = {
guideMarkdown: createGuideArticlePages,
blockIntroMarkdown: createBlockIntroPages,
superBlockIntroMarkdown: createSuperBlockIntroPages
};
exports.onCreateNode = function onCreateNode({ node, actions, getNode }) {
const { createNodeField } = actions;
if (node.internal.type === 'ChallengeNode') {
const { tests = [], block, title, superBlock } = node;
const slug = `/learn/${dasherize(superBlock)}/${dasherize(
block
)}/${dasherize(title)}`;
@ -18,22 +30,11 @@ exports.onCreateNode = function onCreateNode({ node, actions }) {
}
if (node.internal.type === 'MarkdownRemark') {
// console.log(node);
const {
frontmatter: { block, superBlock }
} = node;
let slug = `/${dasherize(superBlock)}`;
// Without this condition the slug for superblocks ends up as something like
// "/apis-and-microservice/undefined" and what we want instead is just
// "/apis-and-microservice"
if (typeof block !== 'undefined') {
slug = slug + `/${dasherize(block)}`;
}
let slug = createFilePath({ node, getNode });
if (!slug.includes('LICENSE')) {
createNodeField({ node, name: 'slug', value: slug });
}
}
};
exports.createPages = ({ graphql, actions }) => {
@ -44,7 +45,9 @@ exports.createPages = ({ graphql, actions }) => {
resolve(
graphql(`
{
allChallengeNode(sort: { fields: [superOrder, order, suborder] }) {
allChallengeNode(
sort: { fields: [superOrder, order, challengeOrder] }
) {
edges {
node {
block
@ -56,10 +59,9 @@ exports.createPages = ({ graphql, actions }) => {
order
required {
link
raw
src
}
suborder
challengeOrder
superBlock
superOrder
template
@ -77,7 +79,12 @@ exports.createPages = ({ graphql, actions }) => {
superBlock
title
}
html
htmlAst
id
excerpt
internal {
identity
}
}
}
}
@ -94,9 +101,34 @@ exports.createPages = ({ graphql, actions }) => {
);
// Create intro pages
result.data.allMarkdownRemark.edges.forEach(
createIntroPages(createPage)
);
result.data.allMarkdownRemark.edges.forEach(edge => {
const {
node: {
internal: { identity },
frontmatter,
fields
}
} = edge;
if (!fields) {
return null;
}
const { slug } = fields;
if (slug.includes('LICENCE')) {
return null;
}
try {
const pageBuilder = createByIdentityMap[identity](createPage);
return pageBuilder(edge);
} catch (e) {
console.log(`
ident: ${identity} does not belong to a function
${frontmatter ? JSON.stringify(edge.node) : 'no frontmatter'}
`);
}
});
return;
})

View File

@ -5,10 +5,16 @@ import { Provider } from 'react-redux';
import headComponents from './src/head';
import { createStore } from './src/redux/createStore';
import GuideNavigationContextProvider from './src/contexts/GuideNavigationContext';
const store = createStore();
export const wrapRootElement = ({ element }) => {
return <Provider store={store}>{element}</Provider>;
return (
<Provider store={store}>
<GuideNavigationContextProvider>{element}</GuideNavigationContextProvider>
</Provider>
);
};
wrapRootElement.propTypes = {

7808
client/package-lock.json generated

File diff suppressed because it is too large Load Diff

View File

@ -0,0 +1,55 @@
const crypto = require('crypto');
const path = require('path');
const commonREs = require('../../utils/regEx');
const readDir = require('../../utils/readDir');
const { isAStubRE } = commonREs;
const pagesDir = path.resolve(__dirname, '../../src/pages/guide');
function withGuidePrefix(str) {
return `/guide${str}`;
}
exports.createNavigationNode = node => {
const {
fileAbsolutePath,
frontmatter: { title },
internal: { content },
parent
} = node;
const nodeDir = fileAbsolutePath.replace(/\/index\.md$/, '');
const dashedName = nodeDir.split('/').slice(-1)[0];
const [, path] = nodeDir.split(pagesDir);
const parentPath = path
.split('/')
.slice(0, -1)
.join('/');
const categoryChildren = readDir(nodeDir);
const navNode = {
categoryChildren,
hasChildren: !!categoryChildren.length,
dashedName,
isStubbed: isAStubRE.test(content),
path: withGuidePrefix(path),
parentPath: withGuidePrefix(parentPath),
title
};
const gatsbyRequired = {
id: fileAbsolutePath + ' >>> NavigationNode',
parent,
children: [],
internal: {
type: 'NavigationNode',
contentDigest: crypto
.createHash('md5')
.update(JSON.stringify(navNode))
.digest('hex')
}
};
return { ...navNode, ...gatsbyRequired };
};

View File

@ -0,0 +1,77 @@
const path = require('path');
const { expect } = require('chai');
const { createNavigationNode } = require('./create-navigation-node');
describe('fcc-create-nav-data', () => {
describe('create-vanigation-node', () => {
const mockNode = {
internal: {
content:
'---\ntitle: File Writing\n---\n## File Writing\n\nThis is a stub.' +
" <a href='https://github.com/freecodecamp/guides/tree/master/src/" +
"pages/php/functions/files/writing/index.md' target='_blank' " +
"rel='nofollow'>Help our community expand it</a>.\n\n<a href=" +
"'https://github.com/freecodecamp/guides/blob/master/README.md' " +
"target='_blank' rel='nofollow'>This quick style guide will help " +
'ensure your pull request gets accepted</a>.\n\n<!-- The article ' +
'goes here, in GitHub-flavored Markdown. Feel free to add YouTube ' +
'videos, images, and CodePen/JSBin embeds -->\n\n#### More ' +
'Information:\n<!-- Please add any articles you think might be ' +
'helpful to read before writing the article -->\n'
},
frontmatter: {
title: 'File Writing'
},
fileAbsolutePath: path.resolve(
__dirname,
'../../src/pages/guide/php/functions/files/file-writing/index.md'
)
};
const result = createNavigationNode(mockNode);
it('should return an object', () => {
expect(result).to.be.an('object');
});
it('node.children should be an array', () => {
expect(result.categoryChildren).to.be.an('array');
});
it('node.dashedName should equal the containing folder name', () => {
expect(result.dashedName).equal('file-writing');
});
it('node.path should equal the file path from pagesDir, prefixed with `/guide`', () => {
expect(result.path).to.equal('/guide/php/functions/files/file-writing');
});
it('node.parentPath should equal the path of the parent page, prefixed with `/guide`', () => {
expect(result.parentPath).to.equal('/guide/php/functions/files');
});
it('node.title should equal srcNode.frontmatter.title', () => {
expect(result.title).to.equal(mockNode.frontmatter.title);
});
it('node.isStubbed should be a boolean', () => {
expect(result.isStubbed).to.be.a('boolean');
});
it('node.isStubbed should be true for a stubbed article', () => {
expect(result.isStubbed).to.equal(true);
});
it('node.isStubbed should be false for a non-stubbed article', () => {
const notAStub = {
...mockNode,
internal: {
content: 'this is not a stub article. Infact, it is very informative'
}
};
const result = createNavigationNode(notAStub);
expect(result.isStubbed).to.equal(false);
});
});
});

View File

@ -0,0 +1,13 @@
const { createNavigationNode } = require('./create-navigation-node');
exports.onCreateNode = ({ actions, node }) => {
const { internal: {type, identity}} = node;
if (type === 'MarkdownRemark' && identity === 'guideMarkdown') {
if (node.fileAbsolutePath.includes('LICENSE.md')) {
return null;
}
const { createNode } = actions;
return Promise.resolve(createNavigationNode(node)).then(createNode);
}
return null;
};

View File

@ -0,0 +1,12 @@
{
"name": "fcc-create-nav-data",
"version": "0.0.1",
"scripts": {
"test": "mocha -R spec \"./{,!(node_modules)/**/}*.test.js\"",
"test:watch": "mocha -R spec \"./{,!(node_modules)/**/}*.test.js\" --watch"
},
"dependencies": {
"chai": "^4.1.2",
"mocha": "^5.0.5"
}
}

View File

@ -0,0 +1,170 @@
# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1
assertion-error@^1.0.1:
version "1.1.0"
resolved "https://registry.yarnpkg.com/assertion-error/-/assertion-error-1.1.0.tgz#e60b6b0e8f301bd97e5375215bda406c85118c0b"
balanced-match@^1.0.0:
version "1.0.0"
resolved "https://registry.yarnpkg.com/balanced-match/-/balanced-match-1.0.0.tgz#89b4d199ab2bee49de164ea02b89ce462d71b767"
brace-expansion@^1.1.7:
version "1.1.11"
resolved "https://registry.yarnpkg.com/brace-expansion/-/brace-expansion-1.1.11.tgz#3c7fcbf529d87226f3d2f52b966ff5271eb441dd"
dependencies:
balanced-match "^1.0.0"
concat-map "0.0.1"
browser-stdout@1.3.1:
version "1.3.1"
resolved "https://registry.yarnpkg.com/browser-stdout/-/browser-stdout-1.3.1.tgz#baa559ee14ced73452229bad7326467c61fabd60"
chai@^4.1.2:
version "4.1.2"
resolved "https://registry.yarnpkg.com/chai/-/chai-4.1.2.tgz#0f64584ba642f0f2ace2806279f4f06ca23ad73c"
dependencies:
assertion-error "^1.0.1"
check-error "^1.0.1"
deep-eql "^3.0.0"
get-func-name "^2.0.0"
pathval "^1.0.0"
type-detect "^4.0.0"
check-error@^1.0.1:
version "1.0.2"
resolved "https://registry.yarnpkg.com/check-error/-/check-error-1.0.2.tgz#574d312edd88bb5dd8912e9286dd6c0aed4aac82"
commander@2.11.0:
version "2.11.0"
resolved "https://registry.yarnpkg.com/commander/-/commander-2.11.0.tgz#157152fd1e7a6c8d98a5b715cf376df928004563"
concat-map@0.0.1:
version "0.0.1"
resolved "https://registry.yarnpkg.com/concat-map/-/concat-map-0.0.1.tgz#d8a96bd77fd68df7793a73036a3ba0d5405d477b"
debug@3.1.0:
version "3.1.0"
resolved "https://registry.yarnpkg.com/debug/-/debug-3.1.0.tgz#5bb5a0672628b64149566ba16819e61518c67261"
dependencies:
ms "2.0.0"
deep-eql@^3.0.0:
version "3.0.1"
resolved "https://registry.yarnpkg.com/deep-eql/-/deep-eql-3.0.1.tgz#dfc9404400ad1c8fe023e7da1df1c147c4b444df"
dependencies:
type-detect "^4.0.0"
diff@3.5.0:
version "3.5.0"
resolved "https://registry.yarnpkg.com/diff/-/diff-3.5.0.tgz#800c0dd1e0a8bfbc95835c202ad220fe317e5a12"
escape-string-regexp@1.0.5:
version "1.0.5"
resolved "https://registry.yarnpkg.com/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz#1b61c0562190a8dff6ae3bb2cf0200ca130b86d4"
fs.realpath@^1.0.0:
version "1.0.0"
resolved "https://registry.yarnpkg.com/fs.realpath/-/fs.realpath-1.0.0.tgz#1504ad2523158caa40db4a2787cb01411994ea4f"
get-func-name@^2.0.0:
version "2.0.0"
resolved "https://registry.yarnpkg.com/get-func-name/-/get-func-name-2.0.0.tgz#ead774abee72e20409433a066366023dd6887a41"
glob@7.1.2:
version "7.1.2"
resolved "https://registry.yarnpkg.com/glob/-/glob-7.1.2.tgz#c19c9df9a028702d678612384a6552404c636d15"
dependencies:
fs.realpath "^1.0.0"
inflight "^1.0.4"
inherits "2"
minimatch "^3.0.4"
once "^1.3.0"
path-is-absolute "^1.0.0"
growl@1.10.3:
version "1.10.3"
resolved "https://registry.yarnpkg.com/growl/-/growl-1.10.3.tgz#1926ba90cf3edfe2adb4927f5880bc22c66c790f"
has-flag@^2.0.0:
version "2.0.0"
resolved "https://registry.yarnpkg.com/has-flag/-/has-flag-2.0.0.tgz#e8207af1cc7b30d446cc70b734b5e8be18f88d51"
he@1.1.1:
version "1.1.1"
resolved "https://registry.yarnpkg.com/he/-/he-1.1.1.tgz#93410fd21b009735151f8868c2f271f3427e23fd"
inflight@^1.0.4:
version "1.0.6"
resolved "https://registry.yarnpkg.com/inflight/-/inflight-1.0.6.tgz#49bd6331d7d02d0c09bc910a1075ba8165b56df9"
dependencies:
once "^1.3.0"
wrappy "1"
inherits@2:
version "2.0.3"
resolved "https://registry.yarnpkg.com/inherits/-/inherits-2.0.3.tgz#633c2c83e3da42a502f52466022480f4208261de"
minimatch@^3.0.4:
version "3.0.4"
resolved "https://registry.yarnpkg.com/minimatch/-/minimatch-3.0.4.tgz#5166e286457f03306064be5497e8dbb0c3d32083"
dependencies:
brace-expansion "^1.1.7"
minimist@0.0.8:
version "0.0.8"
resolved "https://registry.yarnpkg.com/minimist/-/minimist-0.0.8.tgz#857fcabfc3397d2625b8228262e86aa7a011b05d"
mkdirp@0.5.1:
version "0.5.1"
resolved "https://registry.yarnpkg.com/mkdirp/-/mkdirp-0.5.1.tgz#30057438eac6cf7f8c4767f38648d6697d75c903"
dependencies:
minimist "0.0.8"
mocha@^5.0.5:
version "5.0.5"
resolved "https://registry.yarnpkg.com/mocha/-/mocha-5.0.5.tgz#e228e3386b9387a4710007a641f127b00be44b52"
dependencies:
browser-stdout "1.3.1"
commander "2.11.0"
debug "3.1.0"
diff "3.5.0"
escape-string-regexp "1.0.5"
glob "7.1.2"
growl "1.10.3"
he "1.1.1"
mkdirp "0.5.1"
supports-color "4.4.0"
ms@2.0.0:
version "2.0.0"
resolved "https://registry.yarnpkg.com/ms/-/ms-2.0.0.tgz#5608aeadfc00be6c2901df5f9861788de0d597c8"
once@^1.3.0:
version "1.4.0"
resolved "https://registry.yarnpkg.com/once/-/once-1.4.0.tgz#583b1aa775961d4b113ac17d9c50baef9dd76bd1"
dependencies:
wrappy "1"
path-is-absolute@^1.0.0:
version "1.0.1"
resolved "https://registry.yarnpkg.com/path-is-absolute/-/path-is-absolute-1.0.1.tgz#174b9268735534ffbc7ace6bf53a5a9e1b5c5f5f"
pathval@^1.0.0:
version "1.1.0"
resolved "https://registry.yarnpkg.com/pathval/-/pathval-1.1.0.tgz#b942e6d4bde653005ef6b71361def8727d0645e0"
supports-color@4.4.0:
version "4.4.0"
resolved "https://registry.yarnpkg.com/supports-color/-/supports-color-4.4.0.tgz#883f7ddabc165142b2a61427f3352ded195d1a3e"
dependencies:
has-flag "^2.0.0"
type-detect@^4.0.0:
version "4.0.8"
resolved "https://registry.yarnpkg.com/type-detect/-/type-detect-4.0.8.tgz#7646fb5f18871cfbb7749e69bd39a6388eb7450c"
wrappy@1:
version "1.0.2"
resolved "https://registry.yarnpkg.com/wrappy/-/wrappy-1.0.2.tgz#b5243d8f3ec1aa35f1364605bc0d1036e30ab69f"

View File

@ -11,13 +11,14 @@ that delivers challenge files to the plugin
const { createNode } = actions;
const { source } = pluginOptions;
return source().subscribe(
challenges =>
return source()
.then(challenges =>
challenges
.filter(challenge => challenge.superBlock !== 'Certificates')
.map(challenge => createChallengeNodes(challenge, reporter))
.map(node => createNode(node)),
e =>
.map(node => createNode(node))
)
.catch(e =>
reporter.panic(`fcc-sourec-challenges
${e.message}

View File

@ -0,0 +1,30 @@
const visit = require('unist-util-visit');
const emojiRE = /^:[a-z_]+:$/;
function markdownToHTML(node) {
const { url, title, alt } = node;
const html = `
<img
alt="${alt}"
class="forum-image"
src="${url}"
title="${title}"
>
`;
return Object.assign(node, {
type: 'html',
value: html
});
}
module.exports = ({ markdownAST }) => {
visit(markdownAST, 'image', imageNode => {
if (emojiRE.test(imageNode.title)) {
return markdownToHTML(imageNode);
}
return imageNode;
});
};

View File

@ -0,0 +1,5 @@
{
"name": "gatsby-remark-fcc-forum-emoji",
"description": "A plugin to help fix the styling of forum emoji in the Guide",
"main": "index.js"
}

View File

@ -0,0 +1,16 @@
exports.onCreateNode = ({ node, reporter }, { predicate, identity }) => {
if (typeof predicate !== 'function') {
reporter.panic(
'Please supply a predicate function to `gatsby-plugin-identity`'
);
}
if (typeof identity !== 'string' || identity.lenght === 0) {
reporter.panic(
'`gatsby-plugin-identity` requires an identify string to add to nodes ' +
'that match the predicate'
);
}
if (predicate(node)) {
node.internal.identity = identity;
}
};

View File

@ -0,0 +1 @@
{"name": "gatsby-plugin-node-identity", "version": "0.1.0"}

View File

@ -132,7 +132,7 @@ class ShowCertification extends Component {
</Col>
</header>
<section className='information'>
<main className='information'>
<div className='information-container'>
<h3>This certifies that</h3>
<h1>
@ -147,7 +147,7 @@ class ShowCertification extends Component {
{completionTime} hours of coursework
</h4>
</div>
</section>
</main>
<footer>
<div className='row signatures'>
<Image

View File

@ -175,6 +175,7 @@ function ShowSettings(props) {
<title>Settings | freeCodeCamp.org</title>
</Helmet>
<Grid>
<main>
<Spacer size={2} />
<FullWidthRow>
<Button
@ -250,6 +251,7 @@ function ShowSettings(props) {
/>
<Spacer />
{/* <DangerZone /> */}
</main>
</Grid>
</Layout>
);

View File

@ -17,6 +17,7 @@ function ShowUnsubscribed({ unsubscribeId }) {
<title>You have been unsubscribed | freeCodeCamp.org</title>
</Helmet>
<Grid>
<main>
<FullWidthRow>
<Spacer />
<Spacer />
@ -38,6 +39,7 @@ function ShowUnsubscribed({ unsubscribeId }) {
</Button>
</FullWidthRow>
) : null}
</main>
</Grid>
</Layout>
);

View File

@ -103,6 +103,7 @@ class ShowUser extends Component {
this.setNavigationTimer();
return (
<Layout>
<main>
<FullWidthRow>
<Spacer />
<Spacer />
@ -127,6 +128,7 @@ class ShowUser extends Component {
</Panel.Body>
</Panel>
</FullWidthRow>
</main>
</Layout>
);
}

View File

@ -149,13 +149,13 @@ class DefaultLayout extends Component {
]}
/>
<Header disableSettings={disableSettings} />
<main className={landingPage && 'landing-page'}>
<div className={landingPage && 'landing-page'}>
<OfflineWarning isOnline={isOnline} isSignedIn={isSignedIn} />
{hasMessages ? (
<Flash messages={flashMessages} onClose={removeFlashMessage} />
) : null}
{children}
</main>
</div>
</Fragment>
);
}

View File

@ -0,0 +1,99 @@
import React from 'react';
import PropTypes from 'prop-types';
import { StaticQuery, graphql } from 'gatsby';
import { Col, Row } from '@freecodecamp/react-bootstrap';
import { NavigationContext } from '../../contexts/GuideNavigationContext';
import DefaultLayout from './Default';
import SideNav from './components/guide/SideNav';
import Spacer from '../helpers/Spacer';
import 'prismjs/themes/prism.css';
import './guide.css';
const propTypes = {
children: PropTypes.any,
data: PropTypes.shape({
allNavigationNode: PropTypes.shape({
edges: PropTypes.arrayOf(
PropTypes.shape({
node: PropTypes.shape({
dashedName: PropTypes.string,
isStubbed: PropTypes.bool,
path: PropTypes.string,
title: PropTypes.string
})
})
)
})
}),
location: PropTypes.object
};
const Layout = ({ children }) => (
<StaticQuery
query={graphql`
query LayoutQuery {
allNavigationNode {
edges {
node {
dashedName
hasChildren
isStubbed
parentPath
path
title
}
}
}
}
`}
render={data => {
const { edges } = data.allNavigationNode;
const pages = edges.map(edge => edge.node);
return (
<NavigationContext>
{({
toggleDisplaySideNav,
displaySideNav,
expandedState,
toggleExpandedState
}) => (
<DefaultLayout>
<Spacer size={2} />
<Row>
<Col
md={4}
smHidden={!displaySideNav}
xsHidden={!displaySideNav}
>
<SideNav
expandedState={expandedState}
pages={pages}
toggleDisplaySideNav={toggleDisplaySideNav}
toggleExpandedState={toggleExpandedState}
/>
</Col>
<Col
className='content'
md={8}
smHidden={displaySideNav}
xsHidden={displaySideNav}
>
<main className='main' id='main' tabIndex='-1'>
{children}
</main>
</Col>
</Row>
</DefaultLayout>
)}
</NavigationContext>
);
}}
/>
);
Layout.displayName = 'Layout';
Layout.propTypes = propTypes;
export default Layout;

View File

@ -12,7 +12,7 @@ function LearnLayout({ children }) {
return (
<Fragment>
<DefaultLayout>
<div id='learn-app-wrapper'>{children}</div>
<main id='learn-app-wrapper'>{children}</main>
</DefaultLayout>
<DonationModal />
</Fragment>

View File

@ -0,0 +1,29 @@
import React from 'react';
import PropTypes from 'prop-types';
import Link from 'gatsby-link';
const propTypes = {
isStubbed: PropTypes.bool,
path: PropTypes.string,
router: PropTypes.object,
title: PropTypes.string,
toggleDisplaySideNav: PropTypes.func.isRequired
};
function NavItem(props) {
const { isStubbed, path, title } = props;
return (
<li>
<Link data-navitem='true' onClick={props.toggleDisplaySideNav} to={path}>
<span className={'navItemTitle' + (isStubbed ? ' stubbed' : '')}>
{title}
</span>
</Link>
</li>
);
}
NavItem.displayName = 'NavItem';
NavItem.propTypes = propTypes;
export default NavItem;

View File

@ -0,0 +1,106 @@
import React, { Component } from 'react';
import PropTypes from 'prop-types';
import { Panel } from '@freecodecamp/react-bootstrap';
import { navigate } from 'gatsby';
const propTypes = {
children: PropTypes.any,
dashedName: PropTypes.string,
handleClick: PropTypes.func.isRequired,
hasChildren: PropTypes.bool,
isExpanded: PropTypes.bool,
path: PropTypes.string,
title: PropTypes.string,
toggleDisplaySideNav: PropTypes.func.isRequired
};
function NoArticles() {
return (
<li>
<span>
No articles yet.
<br />
Could you&nbsp;
<a
href={
'https://github.com/freeCodeCamp/guides/blob/master/README.md' +
'#freecodecamp-guide'
}
rel='noopener noreferrer'
target='_blank'
>
write one?
</a>
</span>
</li>
);
}
class NavPanel extends Component {
constructor() {
super();
this.renderHeader = this.renderHeader.bind(this);
this.handleHeaderClick = this.handleHeaderClick.bind(this);
this.renderBody = this.renderBody.bind(this);
}
handleHeaderClick() {
const { path, handleClick } = this.props;
handleClick(path);
navigate(path);
}
renderHeader() {
const { isExpanded, title, toggleDisplaySideNav } = this.props;
return (
<div className='title' onClick={this.handleHeaderClick}>
<span
className={
'caret ' + (isExpanded ? 'caretStyle expanded' : 'caretStyle')
}
/>
<span onClick={toggleDisplaySideNav}>{title}</span>
</div>
);
}
renderBody() {
const { hasChildren, children, isExpanded } = this.props;
const childrenWithChildren = children.filter(child => child.props.children);
const uniqueChildren = children.filter(
child =>
!childrenWithChildren.some(
(potentialDupe, index) => index > 0 && potentialDupe.key === child.key
)
);
return (
<div className={isExpanded ? 'body' : ''}>
<ul className='navPanelUl'>
{hasChildren ? uniqueChildren : <NoArticles />}
</ul>
</div>
);
}
render() {
const { isExpanded, dashedName } = this.props;
return (
<Panel
bsClass='panelStyle panel'
collapsible={true}
expanded={isExpanded}
id={`${dashedName}-panel`}
role='listitem'
>
<Panel.Heading>{this.renderHeader()}</Panel.Heading>
{isExpanded ? <Panel.Body>{this.renderBody()}</Panel.Body> : null}
</Panel>
);
}
}
NavPanel.displayName = 'NavPanel';
NavPanel.propTypes = propTypes;
export default NavPanel;

View File

@ -0,0 +1,103 @@
import React, { Component } from 'react';
import PropTypes from 'prop-types';
import PanelGroup from '@freecodecamp/react-bootstrap/lib/PanelGroup';
import NavPanel from './NavPanel';
import NavItem from './NavItem';
const propTypes = {
expandedState: PropTypes.object,
pages: PropTypes.arrayOf(PropTypes.object),
parents: PropTypes.arrayOf(PropTypes.object),
toggleDisplaySideNav: PropTypes.func.isRequired,
toggleExpandedState: PropTypes.func.isRequired
};
function parentFilter(node) {
return node.path.split('/').filter(Boolean).length === 2;
}
class SideNav extends Component {
constructor(...props) {
super(...props);
this.renderChildren = this.renderChildren.bind(this);
this.renderPanels = this.renderPanels.bind(this);
this.renderParent = this.renderParent.bind(this);
}
renderPanels(parents, pages) {
if (!parents) {
return 'No Parents Here';
}
return parents.map(parent => this.renderParent(parent, pages));
}
renderParent(parent, pages) {
const childrenForParent = pages.filter(
page => page.parentPath === parent.path
);
const { path } = parent;
const isExpanded = !!this.props.expandedState[path];
const [category] = pages.filter(page => page.path === path);
const { title, hasChildren, dashedName } = category;
const children = this.renderChildren(childrenForParent, pages);
return (
<NavPanel
dashedName={dashedName}
handleClick={this.props.toggleExpandedState}
hasChildren={hasChildren}
isExpanded={isExpanded}
key={parent.path}
path={parent.path}
title={title}
toggleDisplaySideNav={this.props.toggleDisplaySideNav}
>
{isExpanded ? children : null}
</NavPanel>
);
}
renderChildren(children, pages) {
return children.map(child => {
if (child.hasChildren) {
return this.renderParent(child, pages);
}
return (
<NavItem
isStubbed={child.isStubbed}
key={child.path}
path={child.path}
title={child.title}
toggleDisplaySideNav={this.props.toggleDisplaySideNav}
/>
);
});
}
render() {
const { pages, expandedState } = this.props;
const parents = pages.filter(parentFilter);
const panels = this.renderPanels(parents, pages);
return (
<nav className='sideNav' id='side-nav'>
<PanelGroup id='guide-navigation-side-panel' role='list'>
{!parents || !expandedState ? (
<NavPanel
title='No Parents Here'
toggleDisplaySideNav={this.props.toggleDisplaySideNav}
/>
) : (
panels
)}
</PanelGroup>
</nav>
);
}
}
SideNav.displayName = 'SideNav';
SideNav.propTypes = propTypes;
export default SideNav;

View File

@ -0,0 +1,319 @@
/* globals */
.colourDarkGrey {
color: #444;
}
.colourGreen {
color: #006400;
}
.pointer {
cursor: pointer;
}
:global body {
font-family: 'Lato', sans-serif, 'FontAwesome';
font-size: 16px;
}
:global h1,
:global h2,
:global h3,
:global h4,
:global h5,
:global h6 {
/* Bootstrap sets weight to 500, we don't have that */
font-weight: 700;
}
:global h2:first-child {
margin-top: 0;
}
:global td,
:global th {
border-bottom: 1px solid rgba(0, 0, 0, 0.12);
padding: 10px;
}
/* Breadcrumbs */
.breadcrumb {
display: inline-block;
padding: 5px 10px;
margin-bottom: 5px;
opacity: 0.8;
transition: opacity 0.1s ease-out;
}
.breadcrumb:hover {
opacity: 1;
}
.breadcrumb > li a {
color: #006400;
}
.breadcrumb > li + li:before {
content: '\203A';
color: #555;
}
.breadcrumb > .active {
color: #555
}
/* Layout */
.content {
overflow-y: auto;
height: 92vh;
}
.content img {
max-width: 100%;
display: block;
}
.content img.forum-image {
display: inline-block;
width: 20px;
height: 20px;
}
/* Search */
.fcc_searchBar {
width: 100%;
}
.fcc_searchBar .ais-Hits {
background-color: white;
width: 60%;
}
@media (max-width: 400px) {
.fcc_searchBar .ais-Hits {
width: 80%;
}
}
/* NavBar */
.navBar {
background: #006400;
display: flex;
align-items: center;
min-height: 38px !important;
max-height: 38px;
border: none;
border-radius: 0;
}
.main {
outline: 0;
}
.navContainer {
display: flex;
align-items: center;
width: 100%;
margin: 0 auto;
padding: 0 15px;
}
@media (min-width: 992px) {
.navContainer {
width: 970px;
}
}
@media (min-width: 1200px) {
.navContainer {
width: 1170px;
}
}
/* Navbar logo */
.logo-glyph {
height: 30px;
width: auto;
}
.logo {
display: none;
}
.logoContainer {
margin-right: 10px;
}
@media (min-width: 992px) {
.logo-glyph {
display: none;
}
.logo {
display: block;
}
.logoContainer {
margin-right: 50px;
width: 25%;
}
}
/* Navbar Toggle */
.navbar-toggle {
border: 1px solid #fff;
margin-left: 10px;
margin-right: 0px;
}
.navbar-toggle .icon-bar{
background-color: #fff;
}
@media (max-width: 992px) {
.navbar-toggle {
display: block;
}
}
/* 404 */
.flexWrapper {
align-items: center;
display: flex;
flex-direction: column;
height: 50vh;
justify-content: center;
}
.verticalAlign {
align-items: center;
display: flex;
flex-direction: column;
justify-content: center;
vertical-align: middle;
}
.button {
color: #006400;
background: #fff;
border-color: #006400;
}
.button:hover {
color: #fff;
background: #006400;
border-color: #fff;
}
/* SideNav */
.body {
overflow-y: hidden;
}
.caretStyle {
border-top: 8px dashed;
border-right: 6px solid transparent;
border-left: 6px solid transparent;
color: darkgray;
margin-right: 5px;
transform: rotate(-90deg);
transition: transform 150ms ease;
}
.caretStyle.expanded {
transform: rotate(0deg);
}
.navItemTitle {
color: #006400;
cursor: pointer;
}
.navPanelUl {
list-style: none;
margin-bottom: 0px;
}
.panelStyle {
border: none !important;
border-radius: 0px;
box-shadow: none;
color: #006400;
padding: 0;
}
.sideNav {
overflow-y: scroll;
max-height: 90vh;
position: relative;
}
@media (max-width: 992px) {
.sideNav {
overflow-y: auto;
max-height: none;
}
}
.stubbed {
color: #777;
}
.stubbed::after {
content: 'stub';
background-color: #aaa;
color: #fff;
border-radius: 3px;
padding: 0 4px;
margin-left: 5px;
line-height: 1;
}
.title {
background-color: white;
border: none;
border-radius: 0px;
cursor: pointer;
}
.bodyContainer {
--h: 100vh;
margin-top: 55px;
height: calc(var(--h) - 55px);
}
@media (max-width: 992px){
.content {
overflow-y: hidden;
height: 100%;
}
}
.skip-link {
background-color: white;
left: 0;
padding: 5px 10px;
top: 0;
z-index: 9;
}
.skip-link:focus {
position: absolute;
}
.article {
outline: 0;
}

View File

@ -0,0 +1,96 @@
import React, { PureComponent, createContext } from 'react';
import PropTypes from 'prop-types';
import Media from 'react-media';
const noop = () => {};
const initialState = { displaySideNav: false, expandedState: {} };
const { Provider, Consumer } = createContext({
...initialState,
toggleDisplaySideNav: () => {
console.warn('no method from provider');
},
toggleExpandedState: () => {
console.warn('no method from provider');
}
});
const propTypes = {
children: PropTypes.any
};
class NavigationContextProvider extends PureComponent {
constructor(...props) {
super(...props);
this.state = { ...initialState };
this.toggleSideNav = this.toggleSideNav.bind(this);
this.toggleExpandedState = this.toggleExpandedState.bind(this);
}
componentDidMount() {
if (typeof window !== 'undefined') {
const pathMap = window.location.pathname
.slice(1)
.split('/')
.slice(0, -1)
.reduce((map, current, i, pathArray) => {
const path =
i !== 0 ? map[pathArray[i - 1]] + `/${current}` : `/${current}`;
return {
...map,
[current]: path
};
}, {});
return Object.keys(pathMap)
.map(key => pathMap[key])
.forEach(path => {
this.toggleExpandedState(path);
});
}
return null;
}
toggleExpandedState(path) {
return this.setState(state => ({
...state,
expandedState: {
...state.expandedState,
[path]: !state.expandedState[path]
}
}));
}
toggleSideNav() {
return this.setState(state => ({
...state,
displaySideNav: !this.state.displaySideNav
}));
}
render() {
const { children } = this.props;
const { displaySideNav, expandedState } = this.state;
return (
<Provider
value={{
displaySideNav,
expandedState,
toggleDisplaySideNav: noop,
toggleExpandedState: this.toggleExpandedState
}}
>
{children}
</Provider>
);
}
}
NavigationContextProvider.displayName = 'NavigationContextProvider';
NavigationContextProvider.propTypes = propTypes;
export const NavigationContext = Consumer;
export default NavigationContextProvider;

66
client/src/pages/guide.js Normal file
View File

@ -0,0 +1,66 @@
import React from 'react';
import Helmet from 'react-helmet';
import Layout from '../components/layouts/GuideLayout';
function Index() {
return (
<Layout>
<Helmet>
<title>Guide | freeCodeCamp.org</title>
<meta
content='Short, concise guides and how-tos for the busy developer.'
name='description'
/>
</Helmet>
<h2>freeCodeCamp Guide</h2>
<p>
{'This website is full of articles about all things related to ' +
'programming. You can use the search bar above to find something ' +
'you would like to learn about, or use the navigation to explore ' +
'the content.'}
</p>
<p>There are articles on:</p>
<ul>
<li>SQL</li>
<li>Mathematics</li>
<li>JavaScript</li>
<li>Bootstrap</li>
<li>Git</li>
<li>and a whole lot more</li>
</ul>
<h3>Not sure where to start?</h3>
<p>
{"If you want to learn programming but you're not sure where to " +
'start, check out '}
<a
href='https://freecodecamp.org'
rel='noopener noreferrer'
target='_blank'
>
freeCodeCamp.org
</a>
{'. It has a curriculum that starts from zero and helps you learn' +
' to code.'}
</p>
<h3>Contribute to the Guide</h3>
<p>
{'This site and the articles on it are '}
<a
href='https://github.com/freeCodeCamp/guides'
rel='noopener noreferrer'
target='_blank'
>
open source
</a>
{'. Your help in making it better is greatly appreciated!'}
</p>
<hr />
<p>Happy coding!</p>
</Layout>
);
}
Index.displayName = 'IndexPage';
export default Index;

View File

@ -0,0 +1,401 @@
Attribution-ShareAlike 4.0 International
=======================================================================
Creative Commons Corporation ("Creative Commons") is not a law firm and does not
provide legal services or legal advice. Distribution of Creative Commons public
licenses does not create a lawyer-client or other relationship. Creative Commons
makes its licenses and related information available on an "as-is" basis.
Creative Commons gives no warranties regarding its licenses, any material
licensed under their terms and conditions, or any related information. Creative
Commons disclaims all liability for damages resulting from their use to the
fullest extent possible.
Using Creative Commons Public Licenses
Creative Commons public licenses provide a standard set of terms and conditions
that creators and other rights holders may use to share original works of
authorship and other material subject to copyright and certain other rights
specified in the public license below. The following considerations are for
informational purposes only, are not exhaustive, and do not form part of our
licenses.
Considerations for licensors: Our public licenses are
intended for use by those authorized to give the public
permission to use material in ways otherwise restricted by
copyright and certain other rights. Our licenses are
irrevocable. Licensors should read and understand the terms
and conditions of the license they choose before applying it.
Licensors should also secure all rights necessary before
applying our licenses so that the public can reuse the
material as expected. Licensors should clearly mark any
material not subject to the license. This includes other CC-
licensed material, or material used under an exception or
limitation to copyright. More considerations for licensors:
wiki.creativecommons.org/Considerations_for_licensors
Considerations for the public: By using one of our public
licenses, a licensor grants the public permission to use the
licensed material under specified terms and conditions. If
the licensor's permission is not necessary for any reason--for
example, because of any applicable exception or limitation to
copyright--then that use is not regulated by the license. Our
licenses grant only permissions under copyright and certain
other rights that a licensor has authority to grant. Use of
the licensed material may still be restricted for other
reasons, including because others have copyright or other
rights in the material. A licensor may make special requests,
such as asking that all changes be marked or described.
Although not required by our licenses, you are encouraged to
respect those requests where reasonable. More_considerations
for the public:
wiki.creativecommons.org/Considerations_for_licensees
=======================================================================
Creative Commons Attribution-ShareAlike 4.0 International Public License
By exercising the Licensed Rights (defined below), You accept and agree to be
bound by the terms and conditions of this Creative Commons
Attribution-ShareAlike 4.0 International Public License ("Public License"). To
the extent this Public License may be interpreted as a contract, You are granted
the Licensed Rights in consideration of Your acceptance of these terms and
conditions, and the Licensor grants You such rights in consideration of benefits
the Licensor receives from making the Licensed Material available under these
terms and conditions.
Section 1 -- Definitions.
a. Adapted Material means material subject to Copyright and Similar Rights that
is derived from or based upon the Licensed Material and in which the Licensed
Material is translated, altered, arranged, transformed, or otherwise modified in
a manner requiring permission under the Copyright and Similar Rights held by the
Licensor. For purposes of this Public License, where the Licensed Material is a
musical work, performance, or sound recording, Adapted Material is always
produced where the Licensed Material is synched in timed relation with a moving
image.
b. Adapter's License means the license You apply to Your Copyright and Similar
Rights in Your contributions to Adapted Material in accordance with the terms
and conditions of this Public License.
c. BY-SA Compatible License means a license listed at
creativecommons.org/compatiblelicenses, approved by Creative Commons as
essentially the equivalent of this Public License.
d. Copyright and Similar Rights means copyright and/or similar rights closely
related to copyright including, without limitation, performance, broadcast,
sound recording, and Sui Generis Database Rights, without regard to how the
rights are labeled or categorized. For purposes of this Public License, the
rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.
e. Effective Technological Measures means those measures that, in the absence of
proper authority, may not be circumvented under laws fulfilling obligations
under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996,
and/or similar international agreements.
f. Exceptions and Limitations means fair use, fair dealing, and/or any other
exception or limitation to Copyright and Similar Rights that applies to Your use
of the Licensed Material.
g. License Elements means the license attributes listed in the name of a
Creative Commons Public License. The License Elements of this Public License are
Attribution and ShareAlike.
h. Licensed Material means the artistic or literary work, database, or other
material to which the Licensor applied this Public License.
i. Licensed Rights means the rights granted to You subject to the terms and
conditions of this Public License, which are limited to all Copyright and
Similar Rights that apply to Your use of the Licensed Material and that the
Licensor has authority to license.
j. Licensor means the individual(s) or entity(ies) granting rights under this
Public License.
k. Share means to provide material to the public by any means or process that
requires permission under the Licensed Rights, such as reproduction, public
display, public performance, distribution, dissemination, communication, or
importation, and to make material available to the public including in ways that
members of the public may access the material from a place and at a time
individually chosen by them.
l. Sui Generis Database Rights means rights other than copyright resulting from
Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996
on the legal protection of databases, as amended and/or succeeded, as well as
other essentially equivalent rights anywhere in the world.
m. You means the individual or entity exercising the Licensed Rights under this
Public License. Your has a corresponding meaning.
Section 2 -- Scope.
a. License grant.
1. Subject to the terms and conditions of this Public License,
the Licensor hereby grants You a worldwide, royalty-free,
non-sublicensable, non-exclusive, irrevocable license to
exercise the Licensed Rights in the Licensed Material to:
a. reproduce and Share the Licensed Material, in whole or
in part; and
b. produce, reproduce, and Share Adapted Material.
2. Exceptions and Limitations. For the avoidance of doubt, where
Exceptions and Limitations apply to Your use, this Public
License does not apply, and You do not need to comply with
its terms and conditions.
3. Term. The term of this Public License is specified in Section
6(a).
4. Media and formats; technical modifications allowed. The
Licensor authorizes You to exercise the Licensed Rights in
all media and formats whether now known or hereafter created,
and to make technical modifications necessary to do so. The
Licensor waives and/or agrees not to assert any right or
authority to forbid You from making technical modifications
necessary to exercise the Licensed Rights, including
technical modifications necessary to circumvent Effective
Technological Measures. For purposes of this Public License,
simply making modifications authorized by this Section 2(a)
(4) never produces Adapted Material.
5. Downstream recipients.
a. Offer from the Licensor -- Licensed Material. Every
recipient of the Licensed Material automatically
receives an offer from the Licensor to exercise the
Licensed Rights under the terms and conditions of this
Public License.
b. Additional offer from the Licensor -- Adapted Material.
Every recipient of Adapted Material from You
automatically receives an offer from the Licensor to
exercise the Licensed Rights in the Adapted Material
under the conditions of the Adapter's License You apply.
c. No downstream restrictions. You may not offer or impose
any additional or different terms or conditions on, or
apply any Effective Technological Measures to, the
Licensed Material if doing so restricts exercise of the
Licensed Rights by any recipient of the Licensed
Material.
6. No endorsement. Nothing in this Public License constitutes or
may be construed as permission to assert or imply that You
are, or that Your use of the Licensed Material is, connected
with, or sponsored, endorsed, or granted official status by,
the Licensor or others designated to receive attribution as
provided in Section 3(a)(1)(A)(i).
b. Other rights.
1. Moral rights, such as the right of integrity, are not
licensed under this Public License, nor are publicity,
privacy, and/or other similar personality rights; however, to
the extent possible, the Licensor waives and/or agrees not to
assert any such rights held by the Licensor to the limited
extent necessary to allow You to exercise the Licensed
Rights, but not otherwise.
2. Patent and trademark rights are not licensed under this
Public License.
3. To the extent possible, the Licensor waives any right to
collect royalties from You for the exercise of the Licensed
Rights, whether directly or through a collecting society
under any voluntary or waivable statutory or compulsory
licensing scheme. In all other cases the Licensor expressly
reserves any right to collect such royalties.
Section 3 -- License Conditions.
Your exercise of the Licensed Rights is expressly made subject to the following
conditions.
a. Attribution.
1. If You Share the Licensed Material (including in modified
form), You must:
a. retain the following if it is supplied by the Licensor
with the Licensed Material:
i. identification of the creator(s) of the Licensed
Material and any others designated to receive
attribution, in any reasonable manner requested by
the Licensor (including by pseudonym if
designated);
ii. a copyright notice;
iii. a notice that refers to this Public License;
iv. a notice that refers to the disclaimer of
warranties;
v. a URI or hyperlink to the Licensed Material to the
extent reasonably practicable;
b. indicate if You modified the Licensed Material and
retain an indication of any previous modifications; and
c. indicate the Licensed Material is licensed under this
Public License, and include the text of, or the URI or
hyperlink to, this Public License.
2. You may satisfy the conditions in Section 3(a)(1) in any
reasonable manner based on the medium, means, and context in
which You Share the Licensed Material. For example, it may be
reasonable to satisfy the conditions by providing a URI or
hyperlink to a resource that includes the required
information.
3. If requested by the Licensor, You must remove any of the
information required by Section 3(a)(1)(A) to the extent
reasonably practicable.
b. ShareAlike.
In addition to the conditions in Section 3(a), if You Share
Adapted Material You produce, the following conditions also apply.
1. The Adapter's License You apply must be a Creative Commons
license with the same License Elements, this version or
later, or a BY-SA Compatible License.
2. You must include the text of, or the URI or hyperlink to, the
Adapter's License You apply. You may satisfy this condition
in any reasonable manner based on the medium, means, and
context in which You Share Adapted Material.
3. You may not offer or impose any additional or different terms
or conditions on, or apply any Effective Technological
Measures to, Adapted Material that restrict exercise of the
rights granted under the Adapter's License You apply.
Section 4 -- Sui Generis Database Rights.
Where the Licensed Rights include Sui Generis Database Rights that apply to Your
use of the Licensed Material:
a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract,
reuse, reproduce, and Share all or a substantial portion of the contents of the
database;
b. if You include all or a substantial portion of the database contents in a
database in which You have Sui Generis Database Rights, then the database in
which You have Sui Generis Database Rights (but not its individual contents) is
Adapted Material,
including for purposes of Section 3(b); and
c. You must comply with the conditions in Section 3(a) if You Share all or a
substantial portion of the contents of the database.
For the avoidance of doubt, this Section 4 supplements and does not replace Your
obligations under this Public License where the Licensed Rights include other
Copyright and Similar Rights.
Section 5 -- Disclaimer of Warranties and Limitation of Liability.
a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE EXTENT
POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS AND AS-AVAILABLE, AND
MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE LICENSED
MATERIAL, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT
LIMITATION, WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE
PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT KNOWN OR DISCOVERABLE. WHERE
DISCLAIMERS OF WARRANTIES ARE NOT ALLOWED IN FULL OR IN PART, THIS DISCLAIMER
MAY NOT APPLY TO YOU.
b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE TO YOU ON ANY
LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, NEGLIGENCE) OR OTHERWISE FOR ANY
DIRECT, SPECIAL, INDIRECT, INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR
OTHER LOSSES, COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR
USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR DAMAGES. WHERE A LIMITATION OF
LIABILITY IS NOT ALLOWED IN FULL OR IN PART, THIS LIMITATION MAY NOT APPLY TO
YOU.
c. The disclaimer of warranties and limitation of liability provided above shall
be interpreted in a manner that, to the extent possible, most closely
approximates an absolute disclaimer and waiver of all liability.
Section 6 -- Term and Termination.
a. This Public License applies for the term of the Copyright and Similar Rights
licensed here. However, if You fail to comply with this Public License, then
Your rights under this Public License terminate automatically.
b. Where Your right to use the Licensed Material has terminated under Section
6(a), it reinstates:
1. automatically as of the date the violation is cured, provided
it is cured within 30 days of Your discovery of the
violation; or
2. upon express reinstatement by the Licensor.
For the avoidance of doubt, this Section 6(b) does not affect any
right the Licensor may have to seek remedies for Your violations
of this Public License.
c. For the avoidance of doubt, the Licensor may also offer the Licensed Material
under separate terms or conditions or stop distributing the Licensed Material at
any time; however, doing so will not terminate this Public License.
d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License.
Section 7 -- Other Terms and Conditions.
a. The Licensor shall not be bound by any additional or different terms or
conditions communicated by You unless expressly agreed.
b. Any arrangements, understandings, or agreements regarding the Licensed
Material not stated herein are separate from and independent of the terms and
conditions of this Public License.
Section 8 -- Interpretation.
a. For the avoidance of doubt, this Public License does not, and shall not be
interpreted to, reduce, limit, restrict, or impose conditions on any use of the
Licensed Material that could lawfully be made without permission under this
Public License.
b. To the extent possible, if any provision of this Public License is deemed
unenforceable, it shall be automatically reformed to the minimum extent
necessary to make it enforceable. If the provision cannot be reformed, it shall
be severed from this Public License without affecting the enforceability of the
remaining terms and conditions.
c. No term or condition of this Public License will be waived and no failure to
comply consented to unless expressly agreed to by the Licensor.
d. Nothing in this Public License constitutes or may be interpreted as a
limitation upon, or waiver of, any privileges and immunities that apply to the
Licensor or You, including from the legal processes of any jurisdiction or
authority.
=======================================================================
Creative Commons is not a party to its public licenses. Notwithstanding,
Creative Commons may elect to apply one of its public licenses to material it
publishes and in those instances will be considered the “Licensor.” The text of
the Creative Commons public licenses is dedicated to the public domain under the
CC0 Public Domain Dedication. Except for the limited purpose of indicating that
material is shared under a Creative Commons public license or as otherwise
permitted by the Creative Commons policies published at
creativecommons.org/policies, Creative Commons does not authorize the use of the
trademark "Creative Commons" or any other trademark or logo of Creative Commons
without its prior written consent including, without limitation, in connection
with any unauthorized modifications to any of its public licenses or any other
arrangements, understandings, or agreements concerning use of licensed material.
For the avoidance of doubt, this paragraph does not form part of the public
licenses.
Creative Commons may be contacted at creativecommons.org.

View File

@ -0,0 +1,178 @@
---
title: Accessibility Basics
---
> "The Dark Arts are many, varied, ever-changing, and eternal. Fighting them is like fighting a many-headed monster, which, each time a neck is severed, sprouts a head even fiercer and cleverer than before. You are fighting that which is unfixed, mutating, indestructible."
>
> --Professor Severus Snape, Harry Potter Series
In this day and age, more and more new technologies are invented to make the life of developers, as well as users easier. To what degree this is a good thing is a debate for another time, for now it's enough to say the toolbox of a developer, especially a web developer, is as ever-changing as the so called "dark arts" are according to our friend Snape.
One tool in that toolbox should be accessibility. It is a tool that should ideally be used in one of the very first steps of writing any form of web content. However, this tool is often not all that well presented in the toolbox of most developers. This could be due to a simple case of not knowing it even exists to extreme cases like not caring about it.
In my life as a user, and later a developer, who benefits from accessibility in any form of content, I have seen both ends of that spectrum. If you are reading this article, I am guessing you are in one of the following categories:
* You are a novice web developer and would like to know more about accessibility
* You are a seasoned web developer and have lost your way (more on that later)
* You are reading this while hearing an ominous humming noise in the background and are being forced at lightsaber point to read this, because you just don't care but have to know about it for your boss.
If you fall outside these rather broad categories, please let me know. I always like to hear from the people who read what I write about.
## So, what is accessibility anyway?
Accessibility in itself is a bit of a misleading term sometimes, especially if English is your second language.
If your site is on the Internet, reachable by anyone with a web browser, in one sense that website is accessible to everyone with a web browser.
But, is all content on your website actually readable, usable and understandable for everyone? Are there no thresholds that bar certain people from 'accessing' all the information you are exposing?
You could ask yourself questions like the following ones:
* If you add information that is only contained in an audio file, can a deaf person still get that information?
* If you denote an important part of your website with a certain color, will a colorblind person know about it?
* If you add images on your website that convey important information, how will a blind person know about it?
* You can even go as far as saying, if your website is very resource-heavy, will someone on a bad mobile 3G connection be able to read your content?
This is where accessibility comes into play. Accessibility basically entails making your content as friendly, as easy to 'access' as possible for the largest amount of people. This includes people who are deaf, blind, dyslexic, mute, on a slow connection, colorblind, suffering from epilepsy etc.
## Why implement accessibility?
You may think that accessibility doesn't apply to you or to your users, so why implement it? What would a blind person do with a photo editing tool?
The truth is, you're right to a certain degree. If you have done meticulous user research and have excluded any chance of a certain group of people visiting your website, the priority for catering to that group of people diminishes quite a bit.
However, doing this research is key in actually defending such a statement. Did you know there were <a href='http://audiogames.net' target='_blank' rel='nofollow'>blind gamers?</a> and even <a href='http://peteeckert.com/' target='_blank' rel='nofollow'>blind photographers?</a>. Perhaps you knew <a href='http://mentalfloss.com/article/25750/roll-over-beethoven-6-modern-deaf-musicians' target='_blank' rel='nofollow'>musicians can be deaf</a>?
If you did, good for you. If not, I guess this drives my point home all the more.
The picture gets even more complicated when we look at legislation that actually forces you to make certain websites and web apps accessible. A prime example is the US-based <a href='http://jimthatcher.com/webcourse1.htm' target='_blank' rel='nofollow'>section 508</a>. Right now, this law mainly refers to government organizations, public sector websites etc. However, laws change.
Last year, airline websites were included in this list which meant that even here in Europe, airline website devs scrambled to make their content accessible. Not doing so can get your company a fine of literally tens of thousands of dollars for each day the problem isn't fixed.
There's variations on this legislation all over the world, some more severe and all-encompassing than others. Not knowing about that fact doesn't make the lawsuit go away, sadly.
## Ok, so accessibility is a big deal. Now how do we implement it?
That question, sadly, is harder to answer than it may seem. The Harry Potter quote at the top is there for a reason, and its not my being an avid Fantasy reader.
As I stated above, accessibility is important for a large group of different people, each with their own needs. Making your website work for literally everyone is a large, on-going task.
To bring a bit of a method to the madness, the Web Content Accessibility Guidelines or <a href='https://www.wuhcag.com/web-content-accessibility-guidelines/' target='_blank' rel='nofollow'>WCAG</a> were composed. This document contains a number of criteria you can use to check your website. For now, I will cover some of the most important basics here. I will point you at the low-hanging fruits, so to speak. In subsequent articles, I will discuss more advanced techniques like [WAI-ARIA] which is important for JavaScript-based apps.
### Talk like the natives
The HTML specification is a document that describes how the language should be used to build websites. Assistive technologies, like screen-readers, speech recognition programs etc. are aware of this document. Web developers however, often are not, or at least not enough, and think something like this is ok:
```html
<div class="awesome-button"></div>
<span><strong>Huge heading I will style with CSS later</strong></span>
<span class="clickable-with-JavaScript">English</span>
```
Guess what? All three of these elements break several criteria of WCAG and therefore are not accessible at all.
The first element breaks the so-called 'name, role, value'-criterium, which states that all elements on a web page should expose their name, their role (like button) and their value (like the contents of an edit field) to assistive technologies. This div actually doesn't provide any of the three, rendering it invisible to screen-readers.
The second element looks like a heading visually after styling it with CSS, but semantically is a span. Therefore, assistive technologies won't know its a heading. A screen-reader will read this as regular text, instead of a heading. Screen-readers often have a hotkey to quickly jump to the nearest heading, this heading will not be included in that scope.
The third element could for example be an element a user can click to change the language of the website. Maybe a fancy animated menu of languages will expand when it is clicked. However, this is also a span and does not expose its role (link, or button), making assistive technologies think this is just the word English with some styling.
Spans and divs are non-elements. They are meant to contain other elements, not to be elements themselves. You can fix these in two ways:
* You can manually add ARIA-attributes to the elements above. This is an advanced topic and outside the scope of this article.
* Or, you can simply do this:
```html
<button>This is a button</button>
<h2>Here's a heading level two</h2>
<a href="JavascriptThing">English</a>
```
Boom. Suddenly, all these elements are now perfectly accessible, just by using native HTML. HTML the way it was meant to be used, in other words.
### A foundation cannot stand without structure
A bit earlier, I touched upon a screen-reader's hotkeys to jump from heading to heading. There are in fact many hotkeys like this to quickly jump to the nearest table, form field, link etc. Making sure these headings are actually in logical places is therefore a good practice and really decreases your assistive technology users' stress levels, which is good if you want visitors to keep coming back to your website.
Also remember that headings are hierarchical. If you use an h2, make sure the h3's that follow it actually have something to do with that h2\. Don't put an h3 for contact details under your h2 for recent blog posts. A good analogy here is a book with chapters, that have subsections. You wouldn't put a section on baking cookies in the middle of a chapter on preparing vegetables ...or ...you wouldn't... right?
### What's the alternative?
Images on a website are great. They add a new layer to your content, can really make the experience your site visitors have way more emersive and generally just look good among all that text. A picture can say more than a thousand words, right?
Certainly. That is, if you can see them. In the HTML5-specification, an img-attribute must always have an alt-attribute. This attribute is meant as an alternative to the image in case it can't be seen. This would be true for blind visitors to your website, but also when your image can't be loaded for some reason. Not adding an alt-tag to an img-attribute is therefore not only breaking accessibility, but going against the HTML5-spec.
I implore any web developer who catches themselves doing this to eat their programmer's hat and work on Windows 95 exclusively for a week. After the time is up, write an essay on what you have learned from this ordeal so I can have a laugh during my afternoon coffee.
Now, there is one caveat here. Alt-attributes are mandatory according to the HTML5-spec, but it's not mandatory to actually fill them in. `<img src="awesome-image.jpg", alt="">` is therefore legal HTML5 code.
Should you therefore fill in alt-tags for all images? It depends on the image, really. For background images, the answer is usually no, but you should use CSS for those anyway.
For purely decorative images that have no information in them at all, you're basically free to choose. Either put in something useful and descriptive or nothing at all.
For images that contain information, like a brochure, a map, a chart etc., not adding alt text breaks WCAG unless you provide a textual alternative. This is usually an alt-attribute, but can also be a block of text right below or next to the image.
For images of text, the text can either be included in the alt-attribute or offered in some alternative manner. The problem is that adding the textual alternative on the same page would basically make the same content show twice for people who can see the image, which is why the alt-attribute is better in this case.
### I can't read your scrawl, son
Even people who don't wear glasses and have no problem with their eyesight at all benefit from an easy to read font and proper contrast. I'm sure you would cringe if you had to fill in a form where light yellow, hopelessly loopy letters are placed on a white background. For people who's eyesight is not as good, like your grandma for example, this becomes hopelessly worse.
The WCAG has contrast ratios for smaller and larger letters and there's plenty of tools out there to check if the contrast ratios are strong enough. The information and tooling is there, go use it.
A good place to start checking color contrast is by using the [WebAIM](https://webaim.org/resources/contrastchecker/) color contrast checker.
### What does this button do?
While we are on the topic of forms, let's quickly glance at the <code>input</code> tag. This little guy is kinda important.
When you put some input fields on a web page, you can use labels to ...well ...label them. However, putting them next to each other is not quite enough. The attribute you want is the for-attribute, which takes the ID of a subsequent input field. This way, assistive technologies know what label to associate with what form field.
I guess the best way to illustrate this is by giving an example:
```html
<label for='username'>
<input type='text' id='username'>
```
This will make for example a screen-reader say "username, text edit field", instead of just reporting' text edit field' and requiring the user to go look for a label. This also really helps people who use speech recognition software.
### That's a tall order
Let's take a small break. I want you to go look at a really well-designed web page. It can be any page. Go on, I'll wait.
Back? Ok, great. Now, look at the page again but disable all CSS. Does it still look good? Is the content on the page still in a logical order? If so, great. You found a page with decent HTML structure. (One way to easily view a page without CSS is to load the site in WebAIM's <a href='http://wave.webaim.org' target='_blank' rel='nofollow'>WAVE Web Accessibility Evaluation Tool</a>. Then click on the "No Styles" tab to see it without styles.)
If not, great. Now you get an impression of what I have to deal with on a daily basis when I come across a badly structured website.
Full disclosure: I tend to curse when this happens. Loudly. With vigor.
Why is this such a big deal? I'll explain.
_spoiler alert!_ To those who have only covered the HTML/CSS curriculum so far, we're going to skip ahead a little.
Screen-readers and other assistive technologies render a top-to-bottom representation of a web page based on your website's DOM. All positional CSS is ignored in this version of the web page.
DOM stands for Document Object Model and is the tree-like structure of your website's HTML elements. All your HTML elements are nodes that hierarchically interlink based on the HTML tags you use and JavaScript. Screen-readers use this DOM tree to work with your HTML code.
If you put your element at the top of your element, it will show up at the top of your DOM tree as well. therefore, the screen-reader will put it at the top as well, even if you move it to the bottom of the page using CSS.
So a final tip I want to give you all is to pay attention to the order of your HTML, not just your finished website with CSS added in. Does it still make sense without CSS? Great!
Oh ... it doesn't? In that case ..you might one day hear a muffled curse carried to you on a chilly breeze while walking outside. That will most likely be me, visiting your website.
In that case I really only have two words for you. Often have I heard those same two words directed at me when I wrote some bad code and it is with great pleasure that I tell you: "go fix!"
### Color Contrast
Color contrast should be a minimum of 4.5:1 for normal text and 3:1 for large text. “Large text” is defined as text that is at least 18 point (24px) or 14 point (18.66px) and bold. [Contrast Checker](https://webaim.org/resources/contrastchecker/)
## Conclusion
I have told you about accessibility, what it is, what it's not and why it's important.
I have also given you the basics, the very basics, of getting accessibility right. These basics are however very powerful and can make your life a lot easier when coding for accessibility.
If we talk in FCC terms, you should keep these in mind while doing the HTML/CSS curriculum as well as the JavaScript curriculum.
In subsequent articles, I will touch on a number of more notch topics. A number of questions I will answer are:
* Adding structured headings sounds like a good idea, but they don't fit in my design. What do I do?
* Is there a way for me to write content only screen-readers and other assistive technologies see?
* How do I make custom JavaScript components accessible?

View File

@ -0,0 +1,54 @@
---
title: Accessibility Examples
---
## Accessibility Examples in Practical Application
I am writing this short guide to provide practical examples of how to implement accessibility in websites. Accessibility was not emphasized during school nor is it being emphasized enough in the real world of web development. It is my hope that this article, along with many others, will encourage developers to create accessible sites from now on. It has always helped me to get practical hands on examples for how to do things. So this guide will focus on real world examples that I have encountered in my day to day life as a web developer.
### Skipping Navigation
In order to give non-sighted users a pleasant experience on your website they need to be able to get to content quickly and efficiently. If you have never experienced a website through a screen reader I recommend doing so. It is the best way to test how easily a site can be navigated for non-sighted users. NVDA is a very good screen reader application that is provided free of charge. But if you use the screen reader and find it helpful consider making a donation to the development team. The screen reader can be downloaded from [nvaccess.org](https://www.nvaccess.org/download/).
To allow non-sighted users to skip to the main content of a site and avoid tabbing through all the main navigation links:
1. Create a "skip navigation link" that lives directly underneath the opening <code>body</code> tag.
```html
<a tabindex="0" class="skip-link" href="#main-content">Skip to Main Content</a>
```
<code>tabindex="0"</code> is added to ensure the link is keyboard focusable on all browsers. Further information about keyboard accessibility can be found at [webaim.org](https://webaim.org/techniques/keyboard/tabindex).
2. The "skip navigation" link needs to be associated with the main html tag in your webpage document using the ID tag.
```html
<main id="main-content">
...page content
</main>
```
3. Hide the "skip navigation" link by default.
This ensures that the link is only visible to sighted users when the link is in focus.
- Create a class for the link that can be styled with CSS. In my example I have added the class <code>skip-link</code>.
```css
.skip-link {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
-webkit-clip-path: inset(50%);
clip-path: inset(50%);
border: 0;
}
.skip-link:active, .skip-link:focus {
position: static;
width: auto;
height: auto;
overflow: visible;
clip: auto;
white-space: normal;
-webkit-clip-path: none;
clip-path: none;
}
```
These CSS styles hide the link by default and only display the link when it is receiving keyboard focus. For more information visit the [a11yproject](http://a11yproject.com/posts/how-to-hide-content) and this [blog post](http://hugogiraudel.com/2016/10/13/css-hide-and-seek/).
### Accessible Tables
### Accessible Tabs

View File

@ -0,0 +1,46 @@
---
title: Accessibility Tools for Web Developers
---
## Accessibility Tools for Web Developers
There are many tools and online resources that can help you to ensure that your web application meets all of the accessibility requirements.
1. **<a href='https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en' target='_blank' rel='nofollow'>Accessibility Developer Tools</a>**
This is a Google Chrome extension that will add a new Accessibility sidebar pane in the Elements tab to the Chrome Developer tools. This new pane will display any properties that are relevant to the accessibility aspect of the element that you are currently inspecting. This extension also adds an accessibility audit that can be used to check whether the current web page violates any accessibility rules.
2. **<a href='https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US' target='_blank' rel='nofollow'>aXe</a>**
This Google Chrome extension can find accessibility defects on your web page.
3. **<a href='http://colorsafe.co' target='_blank' rel='nofollow'>Color Safe Palette Generator</a>**
This website can help you to create a color palette that is based on the WCAG guidelines for text and background contrast ratios.
4. **<a href='http://www.checkmycolours.com' target='_blank' rel='nofollow'>Check My Colours</a>**
A website for checking if your existing website meets the accessibility requirements for color and contrast.
5. **<a href='http://colororacle.org' target='_blank' rel='nofollow'>Color Oracle</a>**
An application that simulates color blindness. It is available on Windows, Mac and Linux.
6. **<a href='http://khan.github.io/tota11y/' target='_blank' rel='nofollow'>tota11y</a>**
An accessibility visualization toolkit that checks how your website performs with assistive technologies.
7. **<a href='https://www.accesslint.com' target='_blank' rel='nofollow'>AccessLint</a>**
A GitHub app that checks your pull requests for accessibility issues.
***
#### More Reources
You can find many more tools for accessible web design on <a href='http://www.d.umn.edu/itss/training/online/webdesign/tools.html' target='_blank' rel='nofollow'>this list</a> made by the University of Minnesota Duluth.

View File

@ -0,0 +1,13 @@
---
title: Automated Accessibility Testing Tools
---
## Automated Accessibility Testing
This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/accessibility/automated-testing/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->

View File

@ -0,0 +1,39 @@
---
title: Accessibility
---
## Accessibility
<strong>Web accessibility means that people with disabilities can use the Web</strong>.
More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can
contribute to the Web. Web accessibility also benefits others, including [older people](https://www.w3.org/WAI/bcase/soc.html#of) with changing abilities
due to aging.
Web accessibility encompasses all disabilities that affect access to the Web, including visual, auditory, physical, speech, cognitive, and neurological
disabilities. The document [How People with Disabilities Use the Web](http://www.w3.org/WAI/intro/people-use-web/Overview.html) describes how different
disabilities affect Web use and includes scenarios of people with disabilities using the Web.
Web accessibility also **benefits** people *without* disabilities. For example, a key principle of Web accessibility is designing Web sites and software
that are flexible to meet different user needs, preferences, and situations. This **flexibility** also benefits people *without* disabilities in certain
situations, such as people using a slow Internet connection, people with "temporary disabilities" such as a broken arm, and people with changing abilities
due to aging. The document [Developing a Web Accessibility Business Case for Your Organization](https://www.w3.org/WAI/bcase/Overview) describes many
different benefits of Web accessibility, including **benefits for organizations**.
Web accessibility should also include the people who doesnt have access to internet or computer.
A prominent guideline for web development was introduced by the [World Wide Web Consortium (W3C)](https://www.w3.org/), the [Web Accessibility Initiative](https://www.w3.org/WAI/)
from which we get the [WAI-ARIA](https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics), the Accessible Rich Internet Applications Suite.
Where WAI tackles the sementics of html to more easily nagivate the DOM Tree, ARIA attempts to make web apps, especially those developed with javascript and
AJAX, more accessible.
The use of images and graphics on websites can decrease accessibility for those with visual impairments. However, this doesn't mean designers should avoid
using these visual elements. When used correctly, visual elements can convey the appropriate look and feel to users without disabilities and should be used
to do so. In order to use these elements appropriately, web designers must use alt text to communicate the message of these elements to those who cannot see
them. Alt text should be short and to the point--generally [no more than five to 15 words](https://www.thoughtco.com/writing-great-alt-text-3466185). If a
graphic is used to convey information that exceeds the limitations of alt text, that information should also exist as web text in order to be read by screen
readers. [Learn more about alt text](https://webaim.org/techniques/alttext/).
Copyright &copy; 2005 <a href="http://www.w3.org" shape="rect">World Wide Web Consortium</a>, (<a href="http://www.csail.mit.edu/" shape="rect">MIT</a>, <a href="http://www.ercim.org" shape="rect">ERCIM</a>, <a href="http://www.keio.ac.jp" shape="rect">Keio</a>,<a href="http://ev.buaa.edu.cn" shape="rect">Beihang</a>). http://www.w3.org/Consortium/Legal/2015/doc-license
### More Information:
<a href='https://www.w3.org/WAI/intro/accessibility.php' target='_blank' rel='nofollow'>w3.org introduction to accessibility.</a>
<a href='http://a11yproject.com/' target='_blank' rel='nofollow'>The A11Y Project</a>

View File

@ -0,0 +1,24 @@
---
title: Acceptance Criteria
---
## Acceptance Criteria
The User Story, as an item in your backlog, is a placeholder for a conversation. In this conversation,
the Product Owner and the Delivery Team reach an understanding on the desired outcome.
The Acceptance Criteria tells the Delivery Team how the code should behave. Avoid writing the **"How"** of the User Story; keep to the **"What"**.
If the team is following Test Driven Development (TDD), it may provide the framework for the automated tests.
The Acceptance Criteria will be the beginnings of the test plan for the QA team.
Most importantly, if the story does not meet each of the Acceptance Criteria, then the Product Owner should not be accepting the story at the end of the iteration.
Acceptance criteria can be viewed as an instrument to protect the Delivery Team. When the Delivery Team commits to a fixed set of stories in the Sprint planning they commit to fixed set of acceptance criteria as well. This helps to avoid scope creep.
Consider the following situation: when accepting the user story the Product Owner suggests adding something that was not in the scope of the User story. In this case the Delivery team is in the position to reject this request (however small it might be) and ask the Product owner to create a new User story that can be taken care of in another Sprint.
#### More Information:
Nomad8 provides an [FAQ on Acceptance Criteria](https://nomad8.com/acceptance_criteria/)
Leading Agile on [Acceptance Criteria](https://www.leadingagile.com/2014/09/acceptance-criteria/)

View File

@ -0,0 +1,130 @@
---
title: Acceptance Testing
---
## Acceptance Testing
Acceptance testing, a testing technique performed to determine whether or not the software system has met the requirement specifications. The main purpose of this test is to evaluate the system's compliance with the business requirements and verify if it is has met the required criteria for delivery to end users.
There are various forms of acceptance testing:
->User acceptance Testing
->Business acceptance Testing
->Alpha Testing
->Beta Testing
#Acceptance Criteria
Acceptance criteria are defined on the basis of the following attributes
->Functional Correctness and Completeness
->Data Integrity
->Data Conversion
->Usability
->Performance
->Timeliness
->Confidentiality and Availability
->Installability and Upgradability
->Scalability
->Documentation
#Acceptance Test Plan - Attributes
The acceptance test activities are carried out in phases. Firstly, the basic tests are executed, and if the test results are satisfactory then the execution of more complex scenarios are carried out.
The Acceptance test plan has the following attributes:
->Introduction
->Acceptance Test Category
->operation Environment
->Test case ID
->Test Title
->Test Objective
->Test Procedure
->Test Schedule
->Resources
=>The acceptance test activities are designed to reach at one of the conclusions:
Accept the system as delivered
Accept the system after the requested modifications have been made
Do not accept the system
#Acceptance Test Report - Attributes
The Acceptance test Report has the following attributes:
->Report Identifier
->Summary of Results
->Variations
->Recommendations
->Summary of To-DO List
->Approval Decision
=======
Acceptance Testing focuses on checking if the developed software meets all the requirements. Its main purpose is to check if the solution developed meets the user expectations.
<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
Acceptance Testing is a well-established practice in software development. Acceptance Testing is a major part of Functional Testing of your code.
An Acceptance Test tests that the code performs as expected i.e. produces the expected output, given the expected inputs.
An Acceptance Test are used to test relatively bigger functional blocks of software aka Features.
### Example
You have created a page that requires the user to first enter their name in a dialog box before they can see the content. You have a list of invited users, so any other users will be returned an error.
There are multiple scenarios here such as:
- Every time you load the page, you need to enter your name.
- If your name is in the list, the dialog will disappear and you will see the article.
- If your name is not in the list, the dialog box will show an error.
You can write Acceptance Tests for each of these sub-features of the bigger dialog box feature
Aside from the code that handles the infrastructure of how the test will be executed, your test for the first scenario could look like (in pseudocode):
Given that the page is opened
The dialog box should be visible
And The dialog box should contain an input box
And The input box should have placeholder text "Your name, please!"
### Notes
Acceptance Tests can be written in any language and run using various tools available that would take care of the infrastructure mentioned above e.g. Opening a browser, loading a page, providing the menthods to access elements on the page, assertion libraries and so on.
Every time you write a piece of software that will be used again (even by yourself), it helps to write a test for it. When you yourself or another makes changes to this code, running the tests will ensure that you have not broken existing functionality.
It is usually performed by the users or the Subject Matter Experts. It is also called as User Acceptance Testing (UAT). UAT involves most common real life scenarios. Unlike system testing, it does not focus on the errors or crashes, but on the functionality. UAT is done at the end of the testing life-cycle and will decide if the software is moved to the next environment or not.
A good way of defining which acceptance tests should be written is to add acceptance criteria to a user story. With acceptance criteria, you can define when a user story is ready to deploy and the issue completed to your wishes.
In an Agile project it is important for the team to have acceptance criteria defined for all user stories. The Acceptance Testing work will use the defined criteria for evaluating the delivered functionality. When a story can pass all acceptance criteria it is complete.
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
- International Software Testing Qualifications Board (http://www.istqb.org/)

View File

@ -0,0 +1,53 @@
---
title: Actual Time Estimation
---
## Actual Time Estimation
Actual Time Estimation is the process of predicting the most realistic amount of effort (expressed in terms of person-hours or money) required to develop or maintain software based on incomplete, uncertain and noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes and bidding rounds.
### State-of-practice
Published surveys on estimation practice suggest that expert estimation is the dominant strategy when estimating software development effort.
Typically, effort estimates are over-optimistic and there is a strong over-confidence in their accuracy. The mean effort overrun seems to be about 30% and not decreasing over time. For a review of effort estimation error surveys, see. However, the measurement of estimation error is problematic, see Assessing the accuracy of estimates. The strong overconfidence in the accuracy of the effort estimates is illustrated by the finding that, on average, if a software professional is 90% confident or “almost sure” to include the actual effort in a minimum-maximum interval, the observed frequency of including the actual effort is only 60-70%.
Currently the term “effort estimate” is used to denote as different concepts as most likely use of effort (modal value), the effort that corresponds to a probability of 50% of not exceeding (median), the planned effort, the budgeted effort or the effort used to propose a bid or price to the client. This is believed to be unfortunate, because communication problems may occur and because the concepts serve different goals.
### History
Software researchers and practitioners have been addressing the problems of effort estimation for software development projects since at least the 1960s; see, e.g., work by Farr and Nelson.
Most of the research has focused on the construction of formal software effort estimation models. The early models were typically based on regression analysis or mathematically derived from theories from other domains. Since then a high number of model building approaches have been evaluated, such as approaches founded on case-based reasoning, classification and regression trees, simulation, neural networks, Bayesian statistics, lexical analysis of requirement specifications, genetic programming, linear programming, economic production models, soft computing, fuzzy logic modeling, statistical bootstrapping, and combinations of two or more of these models.
The perhaps most common estimation methods today are the parametric estimation models COCOMO, SEER-SEM and SLIM. They have their basis in estimation research conducted in the 1970s and 1980s and are since then updated with new calibration data, with the last major release being COCOMO II in the year 2000. The estimation approaches based on functionality-based size measures, e.g., function points, is also based on research conducted in the 1970s and 1980s, but are re-calibrated with modified size measures and different counting approaches, such as the use case points or object points in the 1990s and COSMIC in the 2000s.
Actual time estimation is a time-based method of estimating development work.
It is critically important to be able to estimate the time-to-completion of an Agile project, unfortunately, it is also one of the most difficult parts of planning an Agile project.
Its intent is to best approximate the amount of time required to complete a given development task.
One technique you may use is to estimate the time it will take to complete user stories. When you are doing this, remember to consult with other members of your agile team. For each user story, make sure that you estimate a time that is realistic and feasible, yet not so much that the client is overcharged for simple work. Consult members of your team so that you may be able to leverage their expertise to be able to understand how much work is required and how long it will take. When you have a consensus for each user story, you can add up the times to come up with a time estimation.
As the requirements of the project change over time, you can update the estimate. If a project loses some resources originally allocated to it, you may need to cut user stories to be able to complete them in the same amount of total time. Similarly, if you want to improve the quality of the app, you may need to allocate more time to each user story to make sure your team has time to finish the app with the desired quality.
Generally, these estimates are calculated using ideal engineering hours.
Examples:
**This task will be complete in 10 days.**
Or…
**This task will be complete by January 10th.**
Or…
**This task will require 25 development hours for completion.**
### More Information:
- [Agile Constraints](http://www.brighthubpm.com/agile/50212-the-agile-triangle-value-quality-and-constraints/)
- [How do you estimate on an Agile project?](http://info.thoughtworks.com/rs/thoughtworks2/images/twebook-perspectives-estimation_1.pdf)

View File

@ -0,0 +1,15 @@
---
title: Alignment
---
## Alignment
This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/agile/alignment/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->

View File

@ -0,0 +1,26 @@
---
title: Application Lifecycle Management
---
## Application Lifecycle Management
Application Lifecycle Management (ALM), while commonly associated with Software Development Lifecycle (SDLC) is a broader perspective that aligns better with the concept of Product Lifecycle. The development (SDLC) is only a portion of the Application's Lifecycle and therefore is represented as part of the ALM.
ALM can be divided into three distinct areas: Governance, Development, and Operations:
Governance: Encompasses all of the decision making and project management for this application, extends over the entire existance of the application.
Development: Process (SDLC) of actually creating the application. For most applications, the development process reappears again several more times in the applications lifetime, including bug fixes, improvements and new versions.
Operations: Work required to run and manage the application,typically begins shortly before deployment, then runs continuously until application retirement. Overlaps at times with Development.
Tools can be used to manage ALM; some of the more popular options include:
* Atlassian [JIRA](http://atlassian.com/software/jira)
* CA Technologies [Rally](http://ca.com/us.html)
* [Thoughtworks](http://thoughtworks.com/products)
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
InfoQ - Gartner and Software Advice examine [Agile Lifecycle Management Tools](http://www.infoq.com/news/2015/02/agile-management-tools/)

View File

@ -0,0 +1,6 @@
---
title: Architectural Runway
---
The architectural runway is setting everything up the program would need before the project is started. This allows developers to hit the ground running.

View File

@ -0,0 +1,20 @@
---
title: Backlog Emergence and Refinement
---
## Backlog Emergence and Refinement
Product backlog refinement is an on going process that needs to be in sync with the product discovery process. Generally, a Scrum team will collaboratively refine product backlog items for the next two to three sprints.
A product owner (individual responsible for clarifying a sprint's goal) defines the scope of the upcoming sprints by identifying and triaging the most valuable user stories in the product backlog. A product owner is more than a glorified project manager of the product backlog, and performs more roles than simply user stories on behalf of stakeholders.
From the Scrum Guide:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised.
The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owners discretion. The objective of refinement is to have enough Product Backlog items "Ready" for the next Sprint's Sprint Planning. Generally, a scrum team will collaboratively refine product backlog items for the next two to three sprints.
Backlog emergence and refinement are essential tasks for every scrum team. The Product Owner defines the scope of the upcoming sprints by identifying and triaging the most valuable user stories in the product backlog. Although the Product Owner is in charge of keeping the product backlog at peak value delivery, they need the assistance of the entire Scrum Team to do so. Changing the Sprint Backlog is part of the ongoing Sprint and is not considered Refinement.
#### More Information:
- [Optimizing Product Backlog Refinement](https://www.scrum.org/resources/blog/optimizing-product-backlog-refinement)
- Scrum Guide (http://www.scrumguides.org/)

View File

@ -0,0 +1,15 @@
---
title: Backlog Item Effort
---
## Backlog Item Effort
This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/agile/backlog-item-effort/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->

View File

@ -0,0 +1,51 @@
---
title: Behavior Driven Development
---
## Behavior Driven Development
Behavior Driven Development (BDD) is a software development process that emerged from ![Test Driven Development (TDD)](../test-driven-development/index.md).
Behavior Driven Development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.
Although BDD is principally an idea about how software development should be managed by both business interests and technical insight, the practice of BDD does assume the use of specialized software tools to support the development process.
Although these tools are often developed specifically for use in BDD projects, they can be seen as specialized forms of the tooling that supports test-driven development. The tools serve to add automation to the ubiquitous language that is a central theme of BDD.
BDD focuses on:
- Where to start in the process
- What to test and what not to test
- How much to test in one go
- What to call the tests
- How to understand why a test fails
At the heart of BDD is a rethinking of the approach to the unit testing and acceptance testing that naturally arise with these issues.
For example, BDD suggests that unit test names be whole sentences starting with a conditional verb ("should" in English for example) and should be written in order of business value.
Acceptance tests should be written using the standard agile framework of a user story: "As a _role_ I want _feature_ so that _benefit_".
Acceptance criteria should be written in terms of scenarios and implemented as classes: Given _initial context_, when _event occurs_, then _ensure some outcomes_.
Example
```
Story: Returns go to stock
As a store owner
In order to keep track of stock
I want to add items back to stock when they're returned.
Scenario 1: Refunded items should be returned to stock
Given that a customer previously bought a black sweater from me
And I have three black sweaters in stock.
When he returns the black sweater for a refund
Then I should have four black sweaters in stock.
Scenario 2: Replaced items should be returned to stock
Given that a customer previously bought a blue garment from me
And I have two blue garments in stock
And three black garments in stock.
When he returns the blue garment for a replacement in black
Then I should have three blue garments in stock
And two black garments in stock.
```
## More Information
* Wiki on <a href='https://en.wikipedia.org/wiki/Behavior-driven_development' target='_blank' rel='nofollow'>BDD</a>
* A well-known Behavior Driven Development (BDD) framework is [Cucumber](https://cucumber.io/). Cucumber supports many programming languages and can be integrated with a number of frameworks; for example, [Ruby on Rails](http://rubyonrails.org/), [Spring Framework](http://spring.io/) and [Selenium](http://www.seleniumhq.org/)

View File

@ -0,0 +1,24 @@
---
title: Build Measure Learn
---
## Build Measure Learn
The Build-Measure-Learn loop is a method used to build the right product. Coined in the "Lean Startup" book by Eric Reis, the loop enables rapid experimenting, in the sole purpose of achieving market fit. In other words, it is a powerful system to validate assumptions concerning a product you set out to deliver. Breaking down the loop, it consists of the following parts:
![build-measure-learn-loop](https://steveblank.files.wordpress.com/2015/05/ideas-build-code-measure.jpg)
### Idea
Each loop starts with an idea that will supply business value to some users. Such idea must be consisted of a vision for a product - which will direct you at what to build, and a metric that will point out to whether your assumptions about the business value were correct.
### Build
To validate your idea, you set out to build a Minimal Viable Product (MVP), combined with predefined metrics (one is preferred), whose purpose is to validate your theory, and help you decide whether you should preserve or pivot.
### Measure
This stage is focused on collecting data & metrics from the MVP.
### Learn
Next, using the data collected, a decision has to be made, whether or not your product is used by users and so you should preserve, or whether users are not interested in the product, and as such you must pivot. The learn phase is therefore ending with an idea (either how to expand the product, or how to pivot from the original product), applicable for the next Build Measure Learn loop.
#### More Information:
[Why Build, Measure, Learn isnt just throwing things against the wall to see if they work the Minimal Viable Product](https://steveblank.com/2015/05/06/build-measure-learn-throw-things-against-the-wall-and-see-if-they-work/)
[The Build-Measure-Learn Feedback Loop](https://www.mindtools.com/pages/article/build-measure-learn.htm)

View File

@ -0,0 +1,23 @@
---
title: Burndown Charts and Burnup Charts
---
## Burndown Charts and Burnup Charts
Burndown and burnup charts are used to measure progress of a project-- usually a development sprint under the Agile methodology. Both charts visually represent work versus time.
Burndown charts show how much work is left to be done versus the amount of time remaining. The Y axis represents work left to be done-- usually relating to a time estimate assigned to each task, e.g. story points-- and the X axis represents time left. Two lines are used; the first-- "Ideal Work Remaining Line"-- represents an ideal burndown, where each day an amount of work proportional to the total amount of time is completed, resulting in a straight line. The second "Actual Work Remaining Line" is used to plot actual progress as taks move through development to a done state. An example of a burndown chart is shown below.
![alt text](https://upload.wikimedia.org/wikipedia/commons/8/8c/Burn_down_chart.png "Image Source: Wikipedia")
Many Scrum Teams use burndown charts in order to see how they are doing during the sprint. Having an even and steady burndown might be an indicator that the stories are small and manageable. If a team notices in the middle of a sprint that the "Actual Work Remaining Line" is above the "Ideal Work Remaining Line" they can make adjustments to the scope: stories can be taken out of the sprint or the scope of stories can be made smaller. Looking at the burndown during the retrospective in the end of the sprint might spark some interesting discussions and result in process improvements.
Burnup charts are very similar, but they show the work that has been completed versus the total amount of work and time remaining. Three lines are used-- an ideal line, a completed work line, and a total work line. In this chart, the total work line should be somewhat steady across the top of the chart, and is a good representation of scope change. The completed work line should move steadily up towards the total work line for the amount of time in the project-- its ideal trajectory is shown by the ideal line. An example is shown below.
![alt text](https://media.licdn.com/mpr/mpr/shrinknp_800_800/AAEAAQAAAAAAAAljAAAAJGQ1ZDI2NzRkLWExYTQtNGI2OS1hZmZjLTM1NGMzYTk1NTEyNg.png "Image Source: Ala'a Elbeheri, LinkedIn")
#### More Information:
<a href='https://en.wikipedia.org/wiki/Burn_down_chart' target='_blank' rel='nofollow'>Burndown Charts- Wikipedia</a>
<a href='https://www.linkedin.com/pulse/burn-up-vs-down-chart-alaa-el-beheri-cisa-rmp-pmp-bcp-itil/' target='_blank' rel='nofollow'>Burn up vs burn down chart- LinkedIn</a>

View File

@ -0,0 +1,10 @@
---
title: Business Value
---
## Business Value
Business Value is the focus of agile delivery. The agile team is charged with evaluating the business value of all work.
Business value describes what the customer will get for a specific piece of work.
This value is discovered through conversations with the customer and analysis of the work involved. Business stakeholders may have data that quantifies the value of a given feature that has been requested. A product owner will use the various sources of information available and devote significant time to understanding, evaluating, and prioritizing the value the customer will receive for a given piece of work.

View File

@ -0,0 +1,24 @@
---
title: Chickens Versus Pigs
---
## Chickens Versus Pigs
"Chickens versus Pigs" refers to a story about a chicken and a pig, where the chicken proposes they open a restaurant called "Ham-n-Eggs".
The pig refuses, because while the chicken just needs to lay eggs, the pig has more at stake.
In an Agile software development project, the software developer is the pig. If you fail to complete the job, or fail to do it well,
you have a lot at stake. This could be your reputation, or maybe even your position. Other team members might also be considered pigs,
depending on how much they have at stake.
On the other hand, many team members are chickens. For example, the client or a high-level project manager would not really be impacted
by the failure of the project. They are interested in its success, and might make contributions, but have lower stakes and thus
have significantly less commitment to the project.
You should strive to be a pig rather than a chicken. You can benefit from (but should not rely on) the chickens in order to minimize risk and
guarantee the project is delivered as efficiently as possible.
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
<a href='http://www.agilejedi.com/chickenandpig'>Agile Jedi: The Story of the Chicken and Pig</a>
<a href='https://en.wikipedia.org/wiki/The_Chicken_and_the_Pig'>Wikipedia: The Chicken and the Pig</a>

View File

@ -0,0 +1,20 @@
---
title: Code Smells
---
## Code Smells
A Code Smell in computer programming is a surface indication that there might be a problem regarding your system and the quality of your code. This problem might require refactoring to be fixed.
It is important to understand that smelly code works, but is not of good quality.
#### Examples
1. Duplicated code - Blocks of code that have been replicated across the code base. This may indicate that you need to generalize the code into a function and call it in two places, or it may be that the way the code works in one place is completely unrelated to the way it works in another place, despite having been copied.
2. Large classes - Classes having too many lines of code. This may indicate that the class is trying to do too many things, and needs to be broken up into smaller classes.
#### More Information:
* _Refactoring: Improving the Design of Existing Code - Kent Beck, Martin Fowler_
* _Clean Code: A Handbook of Agile Software Craftsmanship - Martin, Robert C. (2009)._
* [Code Smells on Wikipedia](https://en.wikipedia.org/wiki/Code_smell)
* [Code Smells on Jeff Atwood's Blog (Coding Horror)](https://blog.codinghorror.com/code-smells/)
* [Code Smells on Ward Cunningham's C2 Wiki](http://wiki.c2.com/?CodeSmell)
* [Martin Fowler - Code Smell](https://martinfowler.com/bliki/CodeSmell.html)

View File

@ -0,0 +1,10 @@
---
title: Collocation Vs Distributed
---
## Collocation Vs Distributed
- Co-located refers to a team that sits together; same office. Ideally, everyone sitting together in adjacent offices or an open workspace.
- Distributed team members are scattered geographically; different buildings, cities, or even countries.
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->

View File

@ -0,0 +1,11 @@
---
title: Continuous Delivery
---
## Continuous Delivery
Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.<sup><a href='https://en.wikipedia.org/wiki/Extreme_programming' target='_blank' rel='nofollow'>1</a></sup>
It aims at building, testing, and releasing software faster and more frequently. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery. Continuous delivery means that the team ensures every change can be deployed to production but may choose not to do it, usually due to business reasons

View File

@ -0,0 +1,14 @@
---
title: Continuous Deployment
---
## Continuous Deployment
Continuous Deployment is a modern software engineering process which is considered part of a DevOps environment. It involves teams of developers producing, updating and releasing code in very short cycles. This means developers commit smaller amounts of code, much more often.
The goal of Continuous Deployment is to have code in a constant reliable and deployable state to enable this code to be released at any time. This process aims to release code more quickly. To achieve continuous deployment, a development team relies on infrastructure that automates and instruments the various steps leading up to deployment. This is quite often called Infrastructure as Code (IaC).
Two main benefits of Continuous Deployment include an earlier return on investment for each feature after it is developed due to the lower release times as well as earlier feedback on new features.
Other benefits to Continuous Deployment include improved code quality due to less bugs making it to production, more reliable code releases and a much lower time to market.

View File

@ -0,0 +1,56 @@
---
title: Continuous Integration
---
## Continuous Integration
At it's most basic, continuous integration (CI) is an agile development methodology in which developers regularly merge their code directly to the main source, usually a remote `master` branch. In order to ensure that no breaking changes are introduced, a full test suite is run on every potentiual build to regression test the new code, i.e. test that the new code does not break existing, working features.
This approach requires good test coverage of the code base, meaning that a majority, if not all, of the code has tests which ensure its features are fully functional. Ideally continuous integration would be practiced together with full <a href='https://guide.freecodecamp.org/agile/test-driven-development' target='_blank' rel='nofollow'>Test-Driven Development</a>.
### Main Steps
The following basic steps are necessary to do the most standard current approach to continuous integration.
1. Maintain a central repo and an active `master` branch.
There has to be a code repository for everyone to merge into and pull changes from. This can be on Github or any number of code-storage services.
2. Automate the build.
Using NPM scripts or more complex build tools like Yarn, Grunt, Webpack, or <a href='https://guide.freecodecamp.org/developer-tools/gulp' target='_blank' rel='nofollow'>Gulp</a>, automate the build so that a single command can build a fully functional version of the product, ready to be deployed in a production environment. Better yet, include deployment as part of the automated build!
3. Make the build run all the tests.
In order to check that nothing in the new code breaks existing functionality, the full test suite needs to be run and the build needs to fail if any tests within it fail.
4. Everyone has to merge changes to `master` every day.
5. Every merge into `master` has to be built and fully tested.
### Best Practices
There are further best practices that make the best use of what CI has to offer and the challenges it presents, such as:
1. Keep the build fast, so that lots of developer time isn't wasted waiting for a build.
2. Test the build in a full clone of the production environment.
If you have, for example, an app deployed on something like Heroku or Digital Ocean, have a separate test deployment there that you can deploy test builds to, to make sure they work not just in tests but in a real production environment. This test environment should be functionally identical to the actual production environment, in order to ensure the test is accurate.
3. Make it easy to stay up to date.
Coders should pull regularly from the `master` branch to keep integrating their code with the changes from their team. The repo should also be made available to stakeholders like product managers, company executives, or sometimes key clients, so that everyone is easily able to see progress.
4. Keep records of builds, so that everyone can see the results of any given build, whether it succeeded or failed, and who or what introduced new changes.
5. Automate deployment.
Keep your app fully up-to-date with any new changes by automating deployment in the production environment as the final stage of the build process, once all tests have passed and the test deployment in the production environment clone has succeeded.
### CI Services
Lots of services exists to handle the process of continuous integration for you, which can make it a lot easier to establish a solid CI pipeline, or build process. When evaluating these, take into account factors like budget, build speed, and what kind of project you're working on. Some services, like <a href='https://travis-ci.org' target='_blank' rel='nofollow'>Travis CI</a> offer free services for open-source projects, which can make them an easy choice for projects like that, but they might have slower builds than other services, like <a href='https://circleci.com/' target='_blank' rel='nofollow'>Circle CI</a> or <a href='https://codeship.com/' target='_blank' rel='nofollow'>Codeship</a>, to name just a few.
#### More Information:
The Wikipedia entry on <a href='https://en.wikipedia.org/wiki/Continuous_integration' target='_blank' rel='nofollow'>Continuous Integration</a>.

View File

@ -0,0 +1,42 @@
---
title: Cross Functional Teams
---
## Cross Functional Teams
A cross-functional team is a group of people with different functional expertise working toward a common goal.
Typically, it includes employees from all levels of an organization. Members may also come from outside an organization (in particular, from suppliers, key customers, or consultants). Cross-functional teams often function as self-directed teams assigned to a specific task which calls for the input and expertise of numerous departments.
Assigning a task to a team composed of multi-disciplinary individuals increases the level of creativity and out of the box thinking.
Each member offers an alternative perspective to the problem and potential solution to the task. In business today, innovation is a leading competitive advantage and cross-functional teams promote innovation through a creative collaboration process. Members of a cross-functional team must be well versed in multi-tasking as they are simultaneously responsible for their cross-functional team duties as well as their normal day-to-day work tasks.
### Common Goal
* Better for the team , better for the individual
* improve co-ordination and integration
* work accross orgnisational boundaries
* improve efficiency of the team by increasing productivity
* Achieve customer satisfaction by working for the same goal
Some researchers have viewed cross-functional interactions as cooperative or competitive in nature, while others have argued that organizations functional areas are often forced to compete and cooperate simultaneously with one another (“coopetition”) and it is critical to understand how these complex relationships interplay and affect firm performance.
### Cross Functional Team Skill Composition
One common challenge of composing Cross Functional Teams is the thought that every technical member on the team is required to have all the technical skills necessary to perform any of the work. It helps that team members can perform more than one technical skill but it is still okay to have specialists. It is just best when not all members of the team are specialists.
#### More Information:
* [17 PROVEN WAYS TO BENEFIT FROM A CROSS-FUNCTIONAL TEAM](https://www.scoro.com/blog/improve-cross-team-collaboration/)
* [11 Reasons to Use Cross Functional Teams](https://blog.kainexus.com/employee-engagement/cross-functional-collaboration/cross-functional-teams/11-reasons)
* [Cross-Functional Scrum Teams](https://www.scrumalliance.org/community/articles/2014/june/success-story-cross-functional-scrum-teams)
* [Cross Functional Doesnt Mean Everyone Can Do Everything](https://www.mountaingoatsoftware.com/blog/cross-functional-doesnt-mean-everyone-can-do-everything)
* [Cross functional teams](https://dzone.com/articles/cross-functional-scrum-teams)

View File

@ -0,0 +1,15 @@
---
title: Crystal
---
## Crystal
This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/agile/crystal/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->

View File

@ -0,0 +1,15 @@
---
title: Customer Units
---
## Customer Units
This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/agile/customer-units/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->

View File

@ -0,0 +1,24 @@
---
title: Daily Stand-Up and Daily Scrum
---
## Daily Stand-Up and Daily Scrum
The Daily Stand-Up (DSU) or Daily Scrum meeting is one of the integral parts of scrum methodology.
As the name suggests, you hold the meeting daily, at the same time and, for a co-located team, in the same location. The meeting should be brief, finished in less than 15 minutes.
Only members of the Development team are required to attend the Daily Stand-up. Typically, the Scrum Master and Product Owners will also attend, but they are not required.
The standard agenda for each person is:
* What have you done since the last DSU
* What are you doing after this DSU
* What are the major obstacles that are stopping your progress, and where do you need help
Team members are to listen carefully to each other's contributions and attempt to identify areas where they can assist each other's progress. The standup meeting will also surface more lengthy topics of discussion that need to take place between different members of the team. These lengthier discussions that arise should then be halted and taken outside of the standup, involving only the relevant participants, and not the entire team.
### Example of Stand-up Meeting
https://www.youtube.com/watch?v=_3VIC8u1UV8
### More Information:
Stand-up meeting: <a href="https://en.wikipedia.org/wiki/Stand-up_meeting" target='_blank' rel='nofollow'>Wikipedia</a>

View File

@ -0,0 +1,20 @@
---
title: Delivery Team
---
## Delivery Team
A scrum team is made up of the Product Owner (PO), the Scrum Master (SM), and the Delivery Team.
The delivery team is everyone but the PO and SM; the developers, testers, system analysts, database analysts, UI / UX analysts, and so on.
For a scrum delivery team to be effective, it should be nimble (or agile!) enough for decisions to be agreed upon quickly while diverse enough so the vast majority of specalities required for software development can be covered by the entire team. Idealy, a team between 3 and 9 people generally works well for a scrum development team.
The team must also foster mutual respect througout every member of the team. An effective scrum team will be able to share the workload and put the accomplishments of the team ahead of the accomplishments of the individual.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
Atlassian's primer article on Scrum [here.](https://www.atlassian.com/agile/scrum)
<!-- Please add any articles you think might be helpful to read before writing the article -->

View File

@ -0,0 +1,30 @@
---
title: Design Patterns
---
## Design Patterns
A design pattern is a common design solution to a common design problem. A collection of design patterns for a related field or domain is called a pattern language. Note that there are also patterns at other levels: code, concurrency, architecture, interaction design ...
In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.
Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Patterns that imply mutable state may be unsuited for functional programming languages, some patterns can be rendered unnecessary in languages that have built-in support for solving the problem they are trying to solve, and object-oriented patterns are not necessarily suitable for non-object-oriented languages.
Design patterns may be viewed as a structured approach to computer programming intermediate between the levels of a programming paradigm and a concrete algorithm.
The book that popularised the field is Gang of Four's (GoF) **Design Patterns: Elements of Reusable Object-Oriented Software** (1994). It present a series (23) of patterns for an conventional (C++) OO language classified in three types:
* **Creational** (to create objects): abstract factory, builder, factory method, prototype, singleton.
* **Structural** (to compose objects): adapter, bridge, composite, decorator, facade, flyweight, proxy.
* **Behavioral** (to communicate between objects): chain of responsibility, command, interpreter, iterator, mediator, memmento, observer, state, strategy, template method, visitor.
Patterns can be used for multiple objectives (learning, communication, improving your tooling) but in agile they should be refactored from code with technical debt and not just added at the start (emergent design/architecture) as initially you don't have enough knowledge about the (future) system that is going to evolve. Note that what requires a pattern in a language or tool may not be needed or already be part of another language or tool. A framework is a set of cooperating classes that make up a reusable design for a specific type of software and are typically pattern-heavy.
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
- [Wikipedia on Design Patterns](https://en.wikipedia.org/wiki/Software_design_pattern)
- [Wikipedia on GoF Book](https://en.wikipedia.org/wiki/Design_Patterns)
- [Design Patterns by Source Making](https://sourcemaking.com/design_patterns): list of well known patterns available online
- [Game Programming Patterns](http://gameprogrammingpatterns.com/): book about Design Patterns commonly used in Game Development, available to be read online for free
- [Object Oriented Design](http://www.oodesign.com/)
- [A Beginners Guide to Design Patterns](https://code.tutsplus.com/articles/a-beginners-guide-to-design-patterns--net-12752)
- [From design patterns to category theory](http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory/)

View File

@ -0,0 +1,32 @@
---
title: DSDM
---
## DSDM
DSDM stands for Dynamic Systems Development Method. It is an Agile rapid development methodology, and aims to address the ongoing problem of the length of time it takes to develop information systems. DSDM is more of a framework than a tightly-defined method, and much of the detail of how things should actually be done is left to the software development organisation or individual to decide. DSDM adopts an incremental approach and uses the RAD (rapid application development) concept of timeboxing. It also emphasizes the key role of people in the development process and is described as a user-centred approach.
DSDM has 9 core principles, as follows:
1) Active user involvement is imperative.
2) Teams must be empowered to make decisions. The four key variables of empowerment are: authority, resources, information, and accountability.
3) Frequent delivery of products is essential.
4) Fitness for business purpose is the essential criterion for acceptance of deliverables.
5) Iterative and incremental development is necessary to converge on an accurate business solution.
6) All changes during development are reversible (ie you do not proceed further down a particular path if problems are encountered; you backtrack to the last safe or agreed point, and then start down a new path).
7) Requirements are baselined at a high level (ie the high-level business requirements, once agreed, are frozen). This is essentially the scope of the project.
8) Testing is integrated throughout the life cycle (ie test as you go rather than testing just at the end where it frequently gets squeezed).
9) A collaborative and co-operative approach between all stakeholders is essential.
The 5 main phases of the DSDM development cycle are:
1) Feasibility study.
2) Business study.
3) Functional model iteration.
4) System design and build iteration.
5) Implementation.
#### More Information:
You can read the following links to find out more.
- <a href='https://www.agilebusiness.org/what-is-dsdm'> Agile Business - What is DSDM?
- <a href='https://en.wikipedia.org/wiki/Dynamic_systems_development_method'> Wikipedia - Dynamic Systems Development Method

View File

@ -0,0 +1,10 @@
---
title: Epics
---
## Epics
A large story or scenario that guides the creation of the software product. Epics usually cover a particular persona and give an overall idea of what is important to the user. An epic can be further broken down into various user stories that show individual tasks that a persona/user would like to perform.
### Epic Example
In an application what helps freelance painters track their projects, a possible epic could be.
Paul the Painter would like an easier way to manage his projects and provide his client with accurate changes and also bill them.

View File

@ -0,0 +1,15 @@
---
title: Extreme Programming
---
## Extreme Programming
Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.<sup><a href='https://en.wikipedia.org/wiki/Extreme_programming' target='_blank' rel='nofollow'>1</a></sup>
The basic advantage of XP is that the whole process is visible and accountable. The developers will make concrete commitments about what they will accomplish, show concrete progress in the form of deployable software, and when a milestone is reached they will describe exactly what they did and how and why that differed from the plan. This allows business-oriented people to make their own business commitments with confidence, to take advantage of opportunities as they arise, and eliminate dead-ends quickly and cheaply.<sup><a href='http://wiki.c2.com/?ExtremeProgramming' target='_blank' rel='nofollow'>2</a></sup>
-- Kent Beck
<a target="_blank" title="By DonWells (Own work) [CC BY 3.0 (http://creativecommons.org/licenses/by/3.0)], via Wikimedia Commons" href="https://commons.wikimedia.org/wiki/File%3AXP-feedback.gif"><img width="256" alt="XP-feedback" src="https://upload.wikimedia.org/wikipedia/commons/4/44/XP-feedback.gif"/></a>
#### More Information:
<a href='http://www.extremeprogramming.org/rules.html' target='_blank' rel='nofollow'>Rules of Extreme Programming</a>

View File

@ -0,0 +1,15 @@
---
title: Feature Based Planning
---
## Feature Based Planning
**Feature Based Planning** is a planning methodology that can be used to decide when to release software based on the features that will be delivered to the customers, rather than an arbitrary deadline based release.
In this method of release planning, teams decide what feature/features should be prioritised. Based on the scope of these features the team can then predict when the next release can be deployed.
#### More Information:
[Feature-driven development](https://en.wikipedia.org/wiki/Feature-driven_development)

View File

@ -0,0 +1,29 @@
---
title: Five Levels of Agile Planning
---
## Five Levels of Agile Planning
A product owner needs to be familiar with the five levels of agile planning:
- Defining the product vision
- Defining the product roadmap
- Release planning
- Sprint planning
- Accounting for the outcome of daily scrums
Agile planning is always continuous and should be revised at least every three months.
## Brief Synopsis of the Five Levels of Agile Planning
1. Product Vision: What (Summary of the major benefits & features the product will provide), Who (Stakeholders), Why (Need & Opportunity), When (Project scheduling & time expectations), Constraints and Assumptions (impacts risk & cost).
2. Product Roadmap: Releases - Date, Theme/Feature Set, Objective, Development Approach.
3. Release Planning: Iteration, Team Capacity, Stories, Priority, Size, Estimates, Definition of Done.
4. Sprint Planning: Stories - Tasks, Definition of Done, Level-of Effort, Commitment
5. Daily Planning: What did I do yesterday? What will I do today? What is blocking me?
#### More Information:
<a href='https://www.scrumalliance.org/why-scrum/agile-atlas/agile-atlas-common-practices/planning/january-2014/five-levels-of-agile-planning' target='_blank' rel='nofollow'>Five Levels of Agile Planning</a>

View File

@ -0,0 +1,13 @@
---
title: Functional Managers
---
## Functional Managers
A functional manager is a person that have management authority over group of people. That authority comes from the formal position of that person in the organization (eg. director of the department, quality department manager, development team manager). Role of functional managers is different then Project Managers or ScrumMasters and is not project based.
In more agile organizations different models exists. Functional manager often are responsible for developing people in their groups, securing budgets and time for people.
However there are also some Agile company models where functions usually assigned to functional managers are distributed to other roles within organization (eg. Spotify model with Tribes, Guilds, Chapters, Squads).
Out in the traditional world of work companies organize people into a hierarchy. People with similar work roles are grouped into functional areas and led by a Functional Manager. The functional manager is generally responsible for the guidance and well-being of the employees who report directly to her.
Agile project teams will often work with functional managers who control the resources the team needs to get work done. An example would be working with a functional manager in procurement to assign a person to work with the team to procure software licenses.

View File

@ -0,0 +1,18 @@
---
title: Agile
---
## Agile
Agile software development is a collection of methodologies used to manage teams of developers. It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. People and communication are considered more important than tools and processes.
Agile emphasizes asking end users what they want, and frequently showing them demos of the product as it is developed. This stands in contrast to the "Waterfall" approach, specification-driven development, and what Agile practitioners call "Big Up-Front Design." In these approaches, the features are planned out and budgeted before development starts.
With Agile, the emphasis is on "agility" - being able to quickly respond to feedback from users and other changing circumstances.
![A comic from Commitstrip.com showing a product manager explaining to a developer that they are switching to agile, but then asking the developer to plan everything up front](https://www.commitstrip.com/wp-content/uploads/2017/01/Strip-Budegt-fixe-pour-projet-flexible-english650-final.jpg)
There are many different flavors of agile, including Scrum and Extreme Programming.
### More information
[Agile Alliance's Homepage](https://www.agilealliance.org/)

View File

@ -0,0 +1,20 @@
---
title: Integration Hell
---
## Integration Hell
Integration Hell is a slang term for when all the members of a development team goes through the process of implementing their code at random times with no way to incorporate the different pieces of code into one seamless sring of code. The development team will have to spend several hours or days testing and tweaking the code to get it all to work.
In practice, the longer components are developed in isolation, the more the interfaces tend to diverge from what is expected. When the components are finally integrated at the end of the project, it would take a great deal more time than allocated, often leading to deadline pressures, and difficult integration. This painful integration work at the end of the project is the eponymous hell.
Continuous Integration, the idea that a development team should use specific tools to "continously integrate" the parts of the code they are working on multiple times a day so that the tools can match the different "chunks" of code together to integrate much more seamlessly than before.
Code Repositories, like Git (and it's open source interface we all know and love, GitHub) allow development teams to organize their efforts so that more time can be spent coding and less time on worrying if the different parts of the code will all integrate.
<a href='https://guide.freecodecamp.org/agile/continuous-integration/'>Continuous Integration</a> is the Agile antidote to this problem. Integration is still painful, but doing it at least daily keeps interfaces from diverging too much.
#### More Information:
- <a href='https://tobeagile.com/2017/03/08/avoiding-integration-hell/'>Avoiding Integration Hell</a>
- <a href='http://wiki.c2.com/?IntegrationHell'>Integration Hell</a>
- <a href='https://www.apicasystems.com/blog/top-5-tips-avoid-integration-hell-continuous-integration/'>Top 5 Tips to Avoid “Integration Hell” with Continuous Integration</a>
- <a href="https://dzone.com/articles/continuous-integration-how-0">D-Zone article on Integration Hell and how Continous Integration has help make it almost a thing of the past</a>

View File

@ -0,0 +1,34 @@
---
title: INVEST
---
## INVEST
**I** | **independent**
----- | -----
**N** | **negotiable**
**V** | **valuable**
**E** | **estimable**
**S** | **small**
**T** | **testable**
When you are refining and sizing the User Stories in the backlog, the INVEST mnemonic can help you determine if they are ready
- Independent
- The story is as distinct as possible from the other stories. Avoid "2-stories in one".
- Negotiable
- As a part of the conversation between the Product Owner and the Delivery Team during grooming, the details for the story can be discussed, refined, and improved. The acceptance criteria can be adjusted based on the ebb and flow of customer need and technical capability.
- Valuable
- There is a value to the customer. Money earned, time saved, efficiency gained, loss stopped, etc. by the implementation of the story.
- Estimable
- During grooming, the description and conversation for the story have addressed enough of the questions from the Delivery Team that they can confidently and comfortably Size the story.
- Small
- You can complete the story within the established iteration.
- Testable
- The story includes acceptance criteria you will use to confirm that the code meets the customer's needs.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
<a href='https://www.google.com/search?q=agile+invest+negotiable&ie=utf-8&oe=utf-8' target='_blank' rel='nofollow'>Lots on Google</a>

View File

@ -0,0 +1,15 @@
---
title: Kano Analysis
---
## Kano Analysis
This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/agile/kano-analysis/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->

View File

@ -0,0 +1,35 @@
---
title: Lean Software Development
---
## Lean Software Development
### Introduction
Lean Software Development is the process of building software with the focus on using techniques which minimize extra work and wasted effort. These techniques are borrowed from the Lean manufacturing movement and applied to the context of software development.
### Key Concepts
There are seven principles within the methodology which include:
1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole
### Metaphors
The act of programming is viewed as an assembly line, where every feature or bug fix is called a "change request". This assembly line of "change requests" can then be considered as a "value stream" with the goal being to minimize the time that each "change request" is on the line prior to being delivered.
Software which is not yet delivered is considered as "inventory" since it has not yet provided value to the company or the customer. This includes any software which is partially complete. Therefore to maximize throughput it is important to deliver many small complete working pieces of software.
In order to minimize the "inventory" it is important to secede control to the "workers" who would be the software developers, as they would be best equipped to create automated processes to "mistake proof" the various parts of the assembly line.
### References
The original source of written documentation on the Lean techniques is the book Lean Software Development, An Agile Toolkit by Mary and Tom Poppendieck.
Additional books by the author(s) include:
- Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck
- Leading Lean Software Development: Results Are not the Point by Mary Poppendieck

View File

@ -0,0 +1,15 @@
---
title: Meta Scrum
---
## Meta Scrum
This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/agile/meta-scrum/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->

View File

@ -0,0 +1,27 @@
---
title: Minimum Marketable Features
---
## Minimum Marketable Features
A Minimum Marketable Feature (MMF) is a self-contained feature that can be developed quickly and gives significant value to the user.
**It is important to note:** Minimum Marketable Feature is not the same as the Minimum Viable Product (MVP). They are different concepts. However, both are essential to supporting the idea that Developers should strive for minimum functionality in order to accomplish any given outcome.
Break down MMF to its core components:
**Minimum** - the absolute smallest set of functionality. This is essential for getting any given feature to market quickly
**Marketable** - Selling the end user or organization that the feature has significant value
**Feature** - The percieved value by the end user. What does it give me? Brand recognition? More Revenue? Help cut costs? Does it give me a competative advantage?
<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
### Sources
<sup>1.</sup> [https://www.agilealliance.org/glossary/mmf/ Accessed: October 25, 2017](https://www.agilealliance.org/glossary/mmf/)
<sup>2.</sup> [https://www.prokarma.com/blog/2015/10/23/minimum-marketable-features-agile-essential Accessed: October 25, 2017](https://www.prokarma.com/blog/2015/10/23/minimum-marketable-features-agile-essential)

View File

@ -0,0 +1,14 @@
---
title: Minimum Viable Product
---
## Minimum Viable Product
The idea is to rapidly build a minimum set of features that is enough to deploy the product and test key assumptions about customers interactions with the product.
#### A Minimum Viable Product has three key characteristics:
- It has enough value that people are willing to use it or buy it initially.
- It demonstrates enough future benefit to retain early adopters.
- It provides a feedback loop to guide future development.
Learn more about MVP:
<a href='https://youtu.be/MHJn_SubN4E' target='_blank' rel='nofollow'>what is a mvp?</a>

View File

@ -0,0 +1,44 @@
---
title: Moscow
---
## Moscow
## MoSCoW Method
One of the meaning of this word is the MoSCoW method - a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement - also known as MoSCoW prioritization or MoSCoW analysis.
## Prioritization of MoSCoW requirements
All requirements are important, but they are prioritized to deliver the greatest and most immediate business benefits early. Developers will initially try to deliver all the Must have, Should have and Could have requirements but the Should and Could requirements will be the first to be removed if the delivery timescale looks threatened.
The plain English meaning of the prioritization categories has value in getting customers to better understand the impact of setting a priority, compared to alternatives like High, Medium and Low.
The categories are typically understood as:
## Must have
Requirements labeled as Must have are critical to the current delivery timebox in order for it to be a success. If even one Must have requirement is not included, the project delivery should be considered a failure. MUST can also be considered an acronym for the Minimum Usable SubseT.
## Should have
Requirements labeled as Should have are important but not necessary for delivery in the current delivery timebox. While Should have requirements can be as important as Must have, they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back until a future delivery timebox.
## Could have
Requirements labeled as Could have are desirable but not necessary, and could improve user experience or customer satisfaction for little development cost. These will typically be included if time and resources permit.
## Won't have
Requirements labeled as Won't have have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, Won't have requirements are not planned into the schedule for the next delivery timebox. Won't have requirements are either dropped or reconsidered for inclusion in a later timebox.
MoSCoW is a coarse-grain method to prioritise (categorise) Product Backlog Items (or requirements, use cases, user stories ... depending on the methodology used).
MoSCoW is often used with timeboxing, where a deadline is fixed so that the focus must be on the most important requirements.
The term MoSCoW itself is an acronym derived from the first letter of each of four prioritization categories (Must have, Should have, Could have, and Won't have):
* **Must have**: Critical to the current delivery timebox in order for it to be a success. It is typically part of the MVP (Minimum Viable Product).
* **Should have**: Important but not necessary for delivery in the current delivery timebox.
* **Could have**: Desirable but not necessary, an improvement.
* **Won't have**: Least-critical, lowest-payback items, or not appropriate at this time.
By prioritizing in this way, a common definition of the project can be reached and stakeholders' expectations set accordingly. Note That MoSCoW is a bit lax about how to distinguish the category of an item and when something will be done, if not in this timebox.
#### More Information:
[Wikipedia](https://en.wikipedia.org/wiki/MoSCoW_method)

View File

@ -0,0 +1,26 @@
---
title: Nonfunctional Requirements
---
## Nonfunctional Requirements
A non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors (a functional requirement). Non-functional requirements are often called "quality attributes", "constraints" or "non-behavioral requirements".
Informally, these are sometimes called the "ilities", from attributes like stability and portability. NFRs can be divided into two main categories:
* **Execution qualities**, such as safety, security and usability, which are observable during operation (at run time).
* **Evolution qualities**, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system
Usually you can refine a non-functional requirement into a set of functional requirements as a way of detailing and allowing (partial) testing and validation.
### Examples:
* The printer should print 5 seconds after the button is pressed
* The code should be written in Java
* The UI should be easily navigable
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
* [Wikipedia article](https://en.wikipedia.org/wiki/Non-functional_requirement)
* [ReQtest](http://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/) Explains the difference between functional and nonfunctional requirements
* [Scaled Agile](http://www.scaledagileframework.com/nonfunctional-requirements/) Works through the process from finding to testing nonfunctional requirements

View File

@ -0,0 +1,11 @@
---
title: Osmotic Communications
---
## Osmotic Communications
**Osmotic Communications** is one of the important factors of a successful agile project.
In agile project, team members usually co-located, any discussion among some of the team members will flow to other team members. They can then pick up relevant information and join in discussion wherever necessary.
#### More Information:
https://www.projectmanagement.com/wikis/295442/Osmotic-Communications
http://agilemodeling.com/essays/communication.htm

View File

@ -0,0 +1,12 @@
---
title: Pair Programming
---
## Pair Programming
Extreme Programming (XP) recommends that all production code be written by two programmers working at the same time at the same computer, taking turns on the keyboard. Several academic studies have demonstrated that pair programming results in fewer bugs and more maintainable software. Pair programming can also help spread knowledge within the team, contributing to a larger <a href='http://deviq.com/bus-factor/' target='_blank' rel='nofollow'>Bus Factor</a> and helping to promote <a href='http://deviq.com/collective-code-ownership/' target='_blank' rel='nofollow'>Collective Code Ownership</a>.
#### More Information:
- <a href='http://bit.ly/PS-PairProgramming' target='_blank' rel='nofollow'>Pair Programming Fundamentals (training course)</a>
- <a href='https://www.versionone.com/agile-101/agile-software-programming-best-practices/pair-programming/' target='_blank' rel='nofollow'>Agile Software Programming Best Practices</a>

View File

@ -0,0 +1,13 @@
---
title: Parallel Development
---
## Parallel Development
Parallel Development stands for the development process separated into multiple branches, to provide a versatile product with stable releases and new features. In a more common straightforward software development process you have only one branch with bug fixes and improvements, alongside with new features. In parallel development multiple branches can coexist.
Usually parallel development contains a main, "master" branch which is the most stable and contains important fixes for existing code. From the main branch, more branches are created to add new "paths" to the existing code. These branches provide new features, but do not include fixes, applied in the mean time from the master branch. Clients know about these releases and have special equipment, or test machines to be able to test the new features. When QA tests are passed, side branch can be merged with the main branch to introduce new features to the release version.
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->

View File

@ -0,0 +1,24 @@
---
title: Pirate Metrics
---
## Pirate Metrics
Dave McClure identified five high-level metric categories critical to a startups success:
Acquisition, Activation, Retention, Revenue, Referral.
He coined the term “Pirate Metrics” from the acronym for these five metric categories (AARRR).
In their book Lean Analytics, Croll and Yoskovitz interpret these metrics visually as a funnel:
![Lean Analytics Figure 5.1](https://github.com/yunChigewan/storage/blob/master/figure_5_1.jpg?raw=true)
Lean Analytics, 2013
And with more pointed explanations as a table:
![Lean Analytics Table 5.1](https://github.com/yunChigewan/storage/blob/master/table_5_1.jpg?raw=true)
Lean Analytics, 2013
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
- Original Pirate Metrics Slideshow (McClure) https://www.slideshare.net/dmc500hats/startup-metrics-for-pirates-long-version
- Lean Analytics Book Website http://leananalyticsbook.com/
- Notion has a really good guide on Pirate Metrics (including Team measures) on their [website](http://usenotion.com/aarrrt/)

View File

@ -0,0 +1,34 @@
---
title: Planning Poker
---
## Planning Poker
### Introduction
Planning poker is an estimation and planning technique in the Agile development model. It is used to estimate the development effort required for a [user story](../user-stories/index.md) or a feature.
### Process
The planning poker is done for one user story at a time.
Each estimator holds an identical set of poker cards consisting of cards with various values. The card values are usually from the Fibonacci Sequence. The unit used for the values can be the number of days, story points, or any other kind of estimation unit agreed on by the team.
The product owner (PO) or stakeholder explains the story that is to be estimated.
The team discusses the story, asking any clarifying questions that they might have. This helps the team get a better understanding on *what* the PO wants.
At the end of the discussion, each person first selects a card (representing their estimate for the story) without showing it to the others. Then, they reveal their cards at the same time.
If all the cards have the same value, the value becomes the estimate for the story. If there are differences, the team discusses the reasons for the values that they have chosen. It is of high value that the team members who gave the lowest and highest estimates provide justifications for their estimates.
After this discussion, the process of picking a card in private and then revealing it at the same time is repeated. This is done until there is a consensus on the estimate.
Because planning poker is a tool to moderate a *joint* expert estimation, it leads to a better common understanding and perhaps even refinement of the feature request. It is of high value even when the team is operating in a No-Estimates mode.
A moderator should try to avoid confirmation bias.
Things worth mentioning:
- Estimations are not comparable between teams, as every team has its own scala.
- Estimations should include everything that needs to be done in order for a piece of work to be done: designing, coding, testing, communicating, code reviews (+ all possible risks)
- The value of using planning poker is in the resulting discussions, as they reveal different views on a possible implementation
### More Information:
- Planning poker video: <a href='https://www.youtube.com/watch?v=MrIZMuvjTws' target='_blank' rel='nofollow'>YouTube</a>

View File

@ -0,0 +1,52 @@
---
title: Product Management
---
## Product Management
Product Management is an organisational function that assumes responsibility for the entire lifecycle of the products that are being sold. As a business function, Product Management, is held accountable for creating customer value and measurable benefits to the business.
There are a few core responsibilities common to most product management roles inside both established enterprise companies and at startups. Most often product management is responsible for understanding customer requirements, defining and prioritizing them, and working with the engineering team to build them. Setting strategy and defining the roadmap is often considered to be inbound work and bringing the product to market is often considered to be "outbound."
It is important to understand the differences between inbound and outbound product management because a great product manager has the diverse set of skills to do both well.
Difference between Product Management and Project Management is, the scale and life cycle. Project Managers ensure multiple products/services/projects are delivered to a customer, while Product Managers go beyond development and work towards longjevity and operation of a product/service.
In Game development we can see the clear shift from Projects to Products due to games having more detailed post launch plans and monetization strategies.
### Inbound Product Management
Inbound product management involves gathering customer research, competitive intelligence, and industry trends as well as setting strategy and managing the product roadmap.
Product Strategy and Definition (Inbound)
- Strategy and vision
- Customer interviews
- Defining features and requirements
- Building roadmaps
- Release management
- Go-to-resource for engineering
- Sales and support training
### Outbound Product Management
Outbound product management involve product marketing responsibilities such as: messaging and branding, customer communication, new product launches, advertising, PR, and events. Depending on the organization these roles can be performed by the same person or two different people or groups that work closely together.
Product Marketing and Go-to-Market (Outbound)
- Competitive differentiation
- Positioning and messaging
- Naming and branding
- Customer communication
- Product launches
- Press and analyst relations
### Product Manager
Product management continues to expand as a profession. Demand for qualified product managers is growing at every level. There are a variety of roles and responsibilities depending on experience level. Opportunities range from an Associate Product Manager all the way to CPO.
Most Product Managers have been in different roles earlier in their careers. Very often software engineers, sales engineers or professional services consultant grow into the role of Product Manager. But in some companies (e.g. Google, Facebook, ...), junior Product Managers are recruited straight out of school, supported by career programs to teach them on the job.
#### More Information:
Wikipedia page: https://en.wikipedia.org/wiki/Product_management

View File

@ -0,0 +1,33 @@
---
title: Product Owners
---
## Product Owners
Product Owners lead the product vision and release planning. They are in charge of defining the features, the release date, and the content that makes up a shippable product. The goal of a Product Owner is to build the right thing quickly and correctly.
At a high-level, the Product Owner is responsible for the following:
* Owner of the product vision
* Leads release planning
* Defines features and content of the release
* Manages team's understanding of the release
* Creates and curates the product backlog
* Prioritizes the product backlog
* Guides team through the release cycle
* Makes trade-off decisions
* Accepts or rejections work
The Product Owner creates a backlog of items that they think would make a good product. This knowledge is based on their understanding of the market, user testing, and market projection. Product Owners adjust the long-term goals of the product based on the feedback they receive from users and stakeholders. They also act as the point of contact with stakeholders and manage scope and expectations.
Once the Product Owner has received feedback from the various stakeholders, they then refine the backlog to add as much detail as possible in order to create a Minimum Viable Product (MVP)for that release.
The Product Owner then prioritizes the workload to ensure that the stories that are completed address both business value and user goals. Also, if there are risks associated with certain stories, the Product Owner puts those at the top of the backlog so that the risks are addressed early.
Working with the team and the Scrum Master, the Product owner attends sprint planning meetings to loop groomed stories into the sprint. Throughout the sprint, the Product Owner ensures that the team completes the work according to the Definition of Done (DoD), answers any questions that may arise, and update stakeholders.
When the sprint is complete, the Product Owner participates in the Sprint Review along with other stakeholders. Making sure that each story meets the DoD, the Product Owner prepares for the next sprint by gathering feedback and prioritizing work based on what was completed.
### More Information:
- Agile Product Ownership in a Nutshell video: [YouTube](https://www.youtube.com/watch?v=502ILHjX9EE)

View File

@ -0,0 +1,22 @@
---
title: Rapid Application Development
---
## Rapid Application Development
Rapid Application Development (RAD) was devised as a reaction to the problems of traditional software development methodologies, particularly the problems of long development lead times. It also addresses the problems associated with changing requirements during the development process.
The main principles of RAD are as follows:
1) Incremental development. This is the main means by which RAD handles changing requirements. Some requirements will only emerge when the users see and experience the system in use. Requirements are never seen as complete - they evolve over time due to changing circumstances. The RAD process starts with a high-level, non-specific list of requirements which are refined during the development process.
2) Timeboxing. With timeboxing, the system is divided up into a number of components or timeboxes that are developed separately. The most important requirements are developed in the first timebox. Features are delivered quickly and often.
3) The Pareto principle. Also known as the 80/20 rule, this means that around 80% of a system's functionality can be delivered with around 20% of the total effort needed. Therefore, the last (and most complex) 20% of requirements take the most effort and time to deliver. So, you should choose as much of the 80% to deliver as possible within the first few timeboxes. The rest, if it proves necessary, can be delivered in subsequent timeboxes.
4) MoSCoW rules. MoSCoW is a method used for prioritising work items in software development. Items are ranked as Must Have, Should Have, Could Have or Would Like to Have. Must Have items are those which must be included in a product for it to be accepted into release, with the other classifications in descending priority.
5) JAD workshops. Joint Application Development (JAD) is a facilitated meeting where requirements gathering is carried out, in particular interviewing users of the system to be developed. The JAD workshop usually takes place early on in the development process, although additional meetings can be organised if required later in the process.
6) Prototyping. Building a prototype helps to establish and clarify the user requirements, and in some cases it evolves to become the system itself.
7) Sponsor and champion. An executive sponsor is someone within the organisation who wants the system, is committed to achieving it and is prepared to fund it. A champion is someone, usually at a lower level of seniority than an executive, who is committed to the project and is prepared to drive it forward to completion.
8) Toolsets. RAD usually adopts toolsets as a means of speeding up the development process and improving productivity. Tools are available for change control, configuration management and code reuse.
#### More Information:
- https://en.wikipedia.org/wiki/Rapid_application_development - Wikipedia article on RAD
- https://www.tutorialspoint.com/sdlc/sdlc_rad_model.htm - TutorialsPoint tutorial on RAD

View File

@ -0,0 +1,15 @@
---
title: Rational Unified Process
---
## Rational Unified Process
This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/agile/rational-unified-process/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->

View File

@ -0,0 +1,15 @@
---
title: Release Planning
---
## Release Planning
This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/agile/release-planning/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->

View File

@ -0,0 +1,20 @@
---
title: Release Trains
---
## Release Trains
The Release Train (also known as the Agile Release Train or ART) is a long-lived team of Agile teams, which, along with other stakeholders, develops and delivers solutions incrementally, using a series of fixed-length Iterations within a Program Increment (PI) timebox. The ART aligns teams to a common business and technology mission.
## Details
ARTs are cross-functional and have all the capabilities—software, hardware, firmware, and other—needed to define, implement, test, and deploy new system functionality. An ART operates with a goal of achieving a continuous flow of value.
ARTs include the teams that define, build, and test features and components. SAFe teams have a choice of Agile practices, based primarily on Scrum, XP, and Kanban. Software quality practices include continuous integration, test-first, refactoring, pair work, and collective ownership. Hardware quality is supported by exploratory early iterations, frequent system-level integration, design verification, modeling, and Set-Based Design.
Agile architecture supports software and hardware quality. Each Agile team has five to nine dedicated individual contributors, covering all the roles necessary to build a quality increment of value for an iteration. Teams can deliver software, hardware, and any combination. And of course, Agile teams within the ART are themselves cross-functional.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
<a href='http://www.scaledagileframework.com/agile-release-train/' target='_blank' rel='nofollow'>Scaled Agile</a>.

View File

@ -0,0 +1,45 @@
---
title: Retrospectives
---
## Retrospectives
The Sprint Retrospective can really be the most useful and important of the scrum ceremonies.
The concept of *"Inspect and Adapt"* is crucial to creating a successful and thriving team.
The standard agenda for the retrospective is:
* What do we keep doing?
* What do we stop doing?
* What do we start doing?
* Who do we want to say thank you to? (Not necessary but good practice)
And from this discussion, the team creates a list of behaviors that they work on, collectively, over time.
When commiting to action items, make sure you focus on 1 - 3. It is better to get a couple done, than commiting to more and not doing them. If it is difficult to come up with actions, try running experiments: Write down what you will do and what you want to achieve with that. In the following retro check if what you did achieved what you had planned. If it did not - you can learn out of the experiment and try out something else.
A good approach to find out which topics should be discussed is *"Discuss and mention"*. It consists on a board with as many columns as people in the team (you can use something like Trello or just a regular whiteboard) and two more for the things to "discuss" and those to be "mentioned". Everybody has 10 minutes to fill their column with things from the last sprint they want to highlight (these are represented with cards or Post-it's). Afterwards, each team member explains each of their own items. Finally, each team member chooses which topics they think should be mentioned or discussed, by moving the card/post-it to the respectively column. The team then decides which topics should be discussed and talk about them for about 10 minutes.
Invite the scrum team only to the Retrospective. (Delivery Team, Product Owner, Scrum Master). Discourage managers, stakeholders, business partners, etc. They are a distraction and can hinder the sense of openness the team needs.
When conducting a retrospective make sure that in the first 5 - 10 minutes everyone says at least a couple of words. When team members speak up in the beginning of the meeting, it is more likely that they contribute during the whole meeting.
During the retrospective it is important that the team stays productive. A simple way to keep people in a positive mood is to focus on what is in the control of the team.
- For a co-located team, index cards and post-its work great for this process.
- For distributed teams, there are a variety of online tools and apps to facilitate the discussion
- https://www.senseitool.com/home
- http://www.leancoffeetable.com/
Action items should be notated on a board to make tracking progress visual and more distinguishable. Every new retrospective should start with reviewing the status of the action items decided upon during the *previous* restrospective.
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
- Inspirations for preparing a retrospective:
- https://plans-for-retrospectives.com/en/
- http://www.funretrospectives.com/
- How to run experiments with the popcorn flow:
- https://www.slideshare.net/cperrone/popcornflow-continuous-evolution-through-ultrarapid-experimentation

View File

@ -0,0 +1,38 @@
---
title: SAFe
---
## SAFe
SAFe stands for "Scaled Agile Framework" and is an agile software development framework that is designed for large-scale agile development involving many teams.
The main website (<a target='_blank' rel='nofollow' href="http://www.scaledagileframework.com/">http://www.scaledagileframework.com/</a>) is an freely available online knowledge base on implementing SAFe.
## Principles
There are nine, underlying principles for SAFe
1. **Take an economic view** - evaluate economic costs of decisions, developments, and risks
2. **Apply systems thinking** - development processes are interactions among the systems used by workers and thus need to view progress with systems thinking
3. **Assume variability; preserve options** - requirements change, be flexible, and use empirical data to narrow focus
4. **Build incrementally with fast, integrated learning cycles** - fast, incremental builds allow rapid feedback in order to change the project if necessary
5. **Base milestones on objective evaluation on working systems** - objective evaluation provides important information such as financials and governance as feedback
6. **Visualize and limit WIP, reduce batch sizes, and manage queue lengths** - do these to achieve continuous flow to move quickly and visualize progress; WIP = work-in-progress
7. **Apply cadence, synchronize with cross-domain planning** - cadence is setting dates when certain events happen (e.g. release weekly) and synchronizing makes sure everyone has the same goals in mind
8. **Unlock the intrinsic motivation of knowledge workers** - people work better when you make use of their personal motivations
9. **Decentralize decision-making** - allows faster action, which may be not the best solution, but allows faster communication among teams; centralized decision-making may be necessary for more strategic or global decisions
## Configurations
There are four variations of SAFe, varying in complexity and needs of your project:
1. Essential SAFe
2. Portfolio SAFe
3. Large Solution SAFe
4. Full SAFe
#### More Information:
- <a href="https://en.wikipedia.org/wiki/Scaled_Agile_Framework" target="_blank" rel="nofollow">Scaled Agile Framework</a>
- <a href="http://www.scaledagileframework.com/what-is-safe/" target="_blank" rel="nofollow">What is SAFe?</a>
- <a href="http://www.scaledagileframework.com/essential-safe/" target="_blank" rel="nofollow">The Ten Essential Elements</a>
- <a href="http://www.scaledagileframework.com/safe-lean-agile-principles/" target="_blank" rel="nofollow">SAFe Principles</a>

View File

@ -0,0 +1,35 @@
---
title: Scrum
---
## Scrum
Scrum is one of the methodologies under the Agile umbrella. The name is derived from a method of resuming play in the sport of rugby, in which the entire team moves together to make ground. Similarly, a scrum in Agile involves all parts of the team working on the same set of goals. In the scrum method, a prioritized list of tasks is presented to the team, and over the course of a "sprint" (usually two weeks), those tasks are completed, in order, by the team. This insures that the highest-priority tasks or deliverables are completed before time or funds run out.
### Components of a Scrum
Scrum is one of the methodologies under the Agile umbrella. It originates from 'scrummage' which is a term used in rugby to denote players huddling together to get possession of the ball.
The practice revolves around
- A set of roles (delivery team, product owner, and scrum master)
- Ceremonies (sprint planning, daily standup, sprint review, sprint retrospective, and backlog grooming)
- Artifacts (product backlog, sprint backlog, product increment, and info radiators and reports).
- The main goal is to keep the team aligned on project progress to facilitate rapid iteration.
- Many organisations have opted for Scrum, because unlike the Waterfall model, it ensures a deliverable at the end of each Sprint.
## Artifacts
- Sprint: It is the time duration, mostly in weeks, for which a Team works to achieve or create a deliverable. A deliverable can defined as a piece of code of fragment of the Final Product which the team wants o achieve. Scrum advises to keep the duration of a Sprint between 2-4 weeks.
- Product Backlog: It is the list of tasks a Team is supposed to finish within the current Sprint. It is decided by the Product Owner, in agreement with the Management as well as Delivery Team.
## Roles
- Product Owner(PO): The ONLY Accountable person to the Management. PO decides what goes in or out of the Product Backlog.
- Delivery Team: They are required to work in accordance with the tasks set by their PO in the product backlog and deliver the required delivarable at the end of the sprint.
- Scrum Masters: - Scrum Master's has to strictly adhere to Scrum Guide and make the team understand the need to adhere to Scrum guide when following Scrum. It is a Scrum Master's job to ensure all Scrum ceremonies being conducted on time and participated by all the required people as per the scrum guide. The SM has to ensure that the Daily Scrum is conducted regularly and actively participated by the team.
#### More Information:
There are several online tools that can be used to do scrum for your team. e.g. <a href='https://www.scrumdo.com/'>Scrum Do</a>, <a href='http://www.asana.com'>Asana</a>, or <a href='http://trello.com'>Trello</a>
<a href='https://www.scrumalliance.org/why-scrum'> Why Scrum </a> from The Scrum Alliance.
<a href = 'http://www.scrumguides.org/scrum-guide.html'>Scrum Guide</a> from Scrum.org
<a href='http://agilitrix.com/2016/04/doing-agile-vs-being-agile/'>Doing vs Being Agile</a>

View File

@ -0,0 +1,32 @@
---
title: Scrummasters
---
## Scrum Master
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which arent. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
### Scrum Master's Job
- Facilitating (not participating in) the daily standup
- Helping the team maintain their burndown chart
- Setting up retrospectives, sprint reviews or sprint planning sessions
- Shielding the team from interruptions during the sprint
- Removing obstacles that affect the team
- Walking the product owner through more technical user stories
- Encouraging collaboration between the Scrum team and product owner .
Typically a Scrummaster will ask the following qustions:
1. What did you do yesterday?
2. What are you going to do today?
3. Is there anything stopping your progress?
Scrum masters are part of an Agile team. They can be developers or other functional members (wearing multiple hats) or functioning individually as a sole role in a team. Their main objective is to enhance the development using the Scrum framework.
Often their role is to: guide the sprint planning, monitor daily standup, conduct retrospectives, ensure velocity is present, help Scoping of Sprints.
#### More Information:
- <a href="https://www.scrum.org/resources/what-is-a-scrum-master" target="_blank" rel="nofollow">What is a Scrum Master</a>
- <a href="https://www.scrum.org/resources/scrum-guide" rel="nofollow">Scrum Guide</a>

View File

@ -0,0 +1,29 @@
---
title: Self Organization
---
## Self Organization
In order to maintain high dynamics and agility of developed projects, all team members should mindfully share responsibility for product that is being developed.
Vertically oriented organisational structures proved themself to be slow and inflexible with many levels of decision making. If a team wants to act fast and react dynamically to constantly changing environment, the organisational structure needs to be flat with members feeling strongly responsible for their input into the project.
It does not mean that management is obsolete process in an agile self-organised team. It just has a different characteristic than in traditional approach (especially in large organisations, but not only), proving to be more effective when more supportive and advisory than despotic and direct.
Foundation of self-organisation is trust and commitment of team's members.
Scrum teams are said to be self organising. This means that the work done and generally the way it is done is left up to the team to decide - they are
empowered by their managers to guide themselves in the ways that makes them most effective. The members of the team (Delivery Team, Product Owner, and
Scrum Master) regularly inspect their behaviors to continuously improve.
During Sprint Planning the team will look at the product backlog (which will have been prioritised by the product owner) and decide which stories they
will work on in the upcoming sprint and the tasks which will need completing to mark the story as Done. The team will estimate a score or size for the
story to denote effort.
During a sprint it is up to the members of the team to pick up sprint backlog stories to work on, generally they will pick ones they think they can
achieve. Due to it being a self organising team, there should be no assigning a task to a team member by someone else.
#### More Information:
- Scrum.org on [Scrum Promoting Self Organization](https://www.scrum.org/resources/blog/how-does-scrum-promote-self-organization)
- Scrum.org on [Scrum Roles Promoting Self Organization](https://www.scrum.org/resources/blog/how-do-3-scrum-roles-promote-self-organization)
- Scrum Alliance on [What and How of Self Organization](https://scrumalliance.org/community/articles/2013/january/self-organizing-teams-what-and-how)

View File

@ -0,0 +1,23 @@
---
title: Spikes
---
## Spikes
Not everything your team works on during the Sprint are User Stories. Sometimes, a user story cannot be effectively estimated or research is required. Maybe help is needed to decide between different architectures, to rule out some risks, or it may be a Proof of Concept (POC) to demonstrate a capability.
In these cases, a Spike is added to the Sprint Backlog. The Acceptance Criteria for the Spike should be an answer to the question being posed. If the experiment is more difficult than anticipated, then maybe the answer is negative. (That's why the Spike should be limited in time.)
The time and energy invested in the Spike are intentionally limited so that the work can be completed within the Sprint while other User Stories are minimally impacted. The Spike does not usually receive a Story Point Estimate, but is given a fixed number of hours to be worked on.
Demonstrate the results of the Spike in the Sprint Review. Based on the new information, the original question is reframed as a new User Story in a future Sprint.
Your team gained the information necessary to make better decisions; to reduce uncertainty. With a small, measured amount of its resources to increase the quality and value of work in future Sprints, as opposed to making decisions based on guess-work.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
- Mountain Goat Software [Spikes](https://www.mountaingoatsoftware.com/blog/spikes)
- Scrum.org Forum [How to Integrate a Spike](https://www.scrum.org/forum/scrum-forum/5512/how-integrate-spike-scrum)
- Scrum Alliance [Spikes and Effort-to-Grief Ratio](https://www.scrumalliance.org/community/articles/2013/march/spikes-and-the-effort-to-grief-ratio)
- Wikipedia [Spike](https://en.wikipedia.org/wiki/Spike_(software_development))

View File

@ -0,0 +1,11 @@
---
title: Sprint Backlog
---
## Sprint Backlog
The Sprint Backlog is a list of tasks identified by the Scrum Team to be completed during the Scrum Sprint. During the Sprint Planning meeting, the team selects a number of Product Backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story.
It is critical that the team itself selects the items and size of the Sprint Backlog. Because they are the people implementing / completing the tasks, they must be the people to choose what they are forecating to achive during the Sprint.
#### More Information:
[Scrum Guide: Sprint Backlog](http://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog)

View File

@ -0,0 +1,24 @@
---
title: Sprint Planning Meeting
---
## Sprint Planning Meeting
The Sprint Planning is facilitated by the team's Scrum Master and consists of the Scrum Team: Development Team, Product Owner (PO) and Scrum Master (SM). It aims to plan a subset of Product Backlog items into a Sprint Backlog. The Scrum Sprint is normally started in after the Sprint Planning meeting.
### Main part
It is of high value for the team to part the meeting in two parts by asking this two questions:
* **What** should the team plan for the upcoming Sprint?
* **How** should the team (roughly) takle the items planned?
#### What
In What phase the team starts with the top of the ordered Product Backlog. The team at least implicitly estimates the items by forecasting what they could take into Sprint Backlog. If needed they could ask / discuss items with the PO, who has to be in place for this meeting.
#### How
In How phase the team shortly discusses every picked Sprint Backlog item with the focus on how they will takle it. SM helps the team not to deep dive into discussion and implementation details. It is very likely and good if more questions to the PO are asked or refinements to the items, or backlog is done by the team.
### Sprint Goal / Closing
The team should come up with a shared Sprint Goal for the Sprint to keep the focus in the Sprint time box. At the end of the Sprint Planning the team forecasts that they can achieve the Sprint Goal and complete most likely all Sprint Backlog items. The SM should prevent the team to overestimate by providing useful insights or statistics.
#### More Information:
[Scrum Guide: Sprint Planning](http://www.scrumguides.org/scrum-guide.html#events-planning)

View File

@ -0,0 +1,18 @@
---
title: Sprint Planning
---
## Sprint Planning
In Scrum, the sprint planning meeting is attended by the product owner, ScrumMaster and the entire Scrum team. Outside stakeholders may attend by invitation of the team, although this is rare in most companies.
During the sprint planning meeting, the product owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog.
There are two defined artifacts that result from a sprint planning meeting:
- A sprint goal
- A sprint backlog
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.
#### More Information:
* https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-planning-meeting
* [Scrum Guide](http://www.scrumguides.org/scrum-guide.html)

View File

@ -0,0 +1,31 @@
---
title: Sprint Review
---
## Sprint Review
The Sprint Review is one of the key Scrum ceremonies (along with Sprint Planning, the Daily Stand Up, the Retrospective, and Grooming).
At the end of the Sprint, your Scrum team hosts an "Invite the World" session to showcase what has just been Completed and Accepted. Invited are the Scrum Team, Stakeholders, Managers, Users; anyone with an interest in the project.
Holding these sessions every Sprint is important. It may be a mindset shift; showing unfinished work to your managers and stakeholders. But in the concept of "Fail Fast", there is incredible value in getting feedback on your incremental work. Your team can course-correct if necessary, minimizing work lost.
Since the Product Owner (PO) is often presenting at the Sprint Review, the Scrum Master will usually capture the feedback, perhaps facilitate the discussions, and then work with the PO to get new User Stories added to the Backlog and prioritized.
The agenda may also include a review of the Backlog (including value and priority), what is scheduled for the next Iteration or two, and what can be removed from the Backlog.
**IMPORTANT** The Sprint Review is completely different than the Retrospective. The Retrospective is stricly for the Scrum team (Scrum Master, PO and Delivery Team). The other parties that are invited to the Review are excused from, and will likely interfere with, the Retrospective. (Yes, including Managers.)
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
Ken Rubin of Innolution <a href='https://www.scrumalliance.org/community/spotlight/ken-rubin/january-2015/stop-calling-your-sprint-review-a-demo%E2%80%94words-matte' target='_blank' rel='nofollow'>Stop Calling Your Sprint Review a Demo</a>
Scrum.org <a href='https://www.scrum.org/resources/what-is-a-sprint-review' target='_blank' rel='nofollow'>What is a Sprint Review</a>
Mountain Goat Software <a href='https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-review-meeting' target='_blank' rel='nofollow'>Sprint Review Meeting</a>
Atlassian <a href='https://www.atlassian.com/blog/agile/sprint-review-atlassian' target='_blank' rel='nofollow'>Three Steps for Better Sprint Reviews</a>
Age of Product <a href='https://age-of-product.com/sprint-review-anti-patterns/' target='_blank' rel='nofollow'>Sprint Review Anti Patterns</a>

View File

@ -0,0 +1,21 @@
---
title: Sprints
---
## Sprints
In Scrum, the **Sprint** is a period of working time usually between one and four weeks in which the delivery team works on your project. Sprints are iterative, and continue until the project is completed. Each sprint begins with a Sprint Planning session, and ends with Sprint Review and Retrospective meetings. Using sprints, as opposed to months-long waterfall or linear sequential development methodologies, allows regular feedback loops between project owners and stakeholders on the output from the delivery team.
## Properties of a Sprint
-Sprints should remain the same pretetermined length of time throughout the length of the project.
-The team works to break up the User Stories to a size that can be completed within the duration of the Sprint without carrying over to the next.
-"Sprint" and "Iteration" are often used interchangeably.
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
- Agile Alliance on <a href='https://www.agilealliance.org/glossary/iteration/' target='_blank' rel='nofollow'>Iterations</a>
- Agile Alliance on <a href='https://www.agilealliance.org/glossary/timebox/' target='_blank' rel='nofollow'>Timeboxes</a>
- Agile Coach on <a href='http://agilecoach.typepad.com/agile-coaching/2014/02/sprint-vs-iteration.html' target='_blank' rel='nofollow'>Sprint vs Iteration</a>
- Scrum Alliance <a href='https://www.scrumalliance.org/community/articles/2014/february/timeboxing-a-motivational-factor-for-scrum-teams' target='_blank' rel='nofollow'>Timeboxing as a Motivational Factor</a>
- Scrum Alliance <a href='https://www.scrumalliance.org/community/articles/2014/may/sprint-is-more-than-just-a-timebox' target='_blank' rel='nofollow'>Sprint is More Than Just a Timebox</a>
- Scrum Inc <a href='https://www.scruminc.com/what-is-timeboxing/' target='_blank' rel='nofollow'>What is Timeboxing</a>
- Scrum.org <a href='https://www.scrum.org/resources/what-is-a-sprint-in-scrum' target='_blank' rel='nofollow'>What is a Sprint in Scrum</a>

View File

@ -0,0 +1,23 @@
---
title: Stakeholders
---
## Stakeholders
The Stakeholders are the people that will benefit from your project. It is up to the Product Owner to understand the outcome required by the Stakeholders, and to communicate that need to the Delivery Team.
Stakeholders may be made up from any of the following
- Users
- Customers
- Managers
- Funders / investors
Their participation in the project is essential for success.
For example, when your team is performing the Sprint Review meetings, the demonstration of the project is for the stakeholders, and their feedback is captured and added to the backlog.
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
- Scrum Study <a href='https://www.scrumstudy.com/blog/stakeholders-in-scrum/' target='_blank' rel='nofollow'>Stakeholders in Scrum</a>
- Scrum.org <a href='https://www.scrum.org/resources/blog/scrum-who-are-key-stakeholders-should-be-attending-every-sprint-review' target='_blank' rel='nofollow'>Key Stakeholders</a>
- Agile Modelling <a href='http://agilemodeling.com/essays/activeStakeholderParticipation.htm' target='_blank' rel='nofollow'>Active Stakeholder Participation</a>

View File

@ -0,0 +1,23 @@
---
title: Story Points and Complexity Points
---
## Story Points and Complexity Points
In Scrum/Agile, the functionality of a product in development is explored by way of **stories** a user might tell about what they want from a product. A team uses **Story Points** when they estimate the amount of effort required to deliver a user story.
Notable features of story points are that they:
* represent the contributions of the whole team
* do not equate directly to time the task might take
* are a rough measure for planning purposes - similar to orders of magnitude
* are assigned in a Fibonacci-like sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100
* estimate the 'size' of stories *relative to each other*
The concept of story points can be quite elusive if you are new to Agile ways of doing things. You will find many online sources discussing story points in different ways, and it can be hard to get a clear idea of what they are and how they are used.
As you learn about the principles and terminology of practices like Scrum, the reasons for some of these properties will become apparent. The use of story points, especially in 'ceremonies' such as planning poker, is much easier to understand by observing or taking part than in a written explanation!
### More Information:
- User Stories: <a href='https://guide.freecodecamp.org/agile/user-stories' target='_blank' rel='nofollow'>freeCodeCamp</a>
- Common mistakes when using story points: <a href='https://medium.com/bynder-tech/12-common-mistakes-made-when-using-story-points-f0bb9212d2f7' target='_blank' rel='nofollow'>Medium</a>
- Planning Poker: <a href='https://www.mountaingoatsoftware.com/agile/planning-poker' target='_blank' rel='nofollow'>Mountain Goat Software</a>

View File

@ -0,0 +1,13 @@
---
title: Sustainable Pace
---
## Sustainable Pace
A Sustainable Pace is the pace at which you and your team can work for extended periods, even forever.
It respects your weekends, evenings, holidays, and vacations. It allows for necessary meetings and personal development time.
#### More Information:
[What is Sustainable Pace?](http://www.sustainablepace.net/what-is-sustainable-pace)

Some files were not shown because too many files have changed in this diff Show More