PM & Process
Get flash to fully experience Pearltrees
IBM Rational Unified Process
The Rational Unified Process ( RUP ) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. [ 1 ] RUP is not a single concrete prescriptive process, but rather an adaptable process framework , intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process . [ edit ] History The Rational Unified Process (RUP) is a software process product, originally developed by Rational Software, which was acquired by IBM in February 2003. The product includes a hyper linked knowledge base with sample artifacts and detailed descriptions for many different types of activities. RUP is included in the IBM Rational Method Composer (RM C) product which allows customization of the process.Agile management
Agile management or agile project management is an iterative method of determining requirements for engineering and information technology development projects in a highly flexible and interactive manner, for example agile software development . It requires empowered individuals from the relevant business, with supplier and customer input. [ citation needed ] There are also links to lean techniques , Kanban and Six Sigma . [1] Agile techniques are best used in small-scale projects or on elements of a wider programme of work, or on projects that are too complex for the customer to understand and specify before testing prototypes. [2] Agile techniques may also be called extreme project management . It is a variant of iterative life cycle [ 1 ] where deliverables are submitted in stages.
Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. Its focus is on "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach". [ edit ] History Scrum was first defined as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach" in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in the "New New Product Development Game". [ 1 ] Hirotaka Takeuchi and Ikujiro Nonaka later argued in "The Knowledge Creating Company" [ 2 ] both by Ikujiro Nonaka and Hirotaka Takeuchi that it is a form of "organizational knowledge creation, [...] especially good at bringing about innovation continuously, incrementally and spirally".
Scrum
Planning poker
Planning Poker , also called Scrum poker, is a consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in software development . It is a variation of the Wideband Delphi method. It is most commonly used in agile software development , in particular the Extreme Programming methodology . The method was first described by James Grenning [ 1 ] in 2002 and later popularized by Mike Cohn in the book Agile Estimating and Planning , [ 2 ] whose company trade marked the term. [ edit ] Process [ edit ] The reason
In software development and product management , a user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. User stories are used with agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management. It captures the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. User stories are written by or for the business user as that user's primary way to influence the functionality of the system being developed. User stories may also be written by developers to express non-functional requirements (security, performance, quality, etc.), [ 1 ] though primarily it is the task of a product manager to ensure user stories are captured.
User story
INVEST in Good Stories
In XP, we think of requirements of coming in the form of user stories. It would be easy to mistake the story card for the "whole story," but Ron Jeffries points out that stories in XP have three components: Cards (their physical medium), Conversation (the discussion surrounding them), and Confirmation (tests that verify them). A pidgin language is a simplified language, usually used for trade, that allows people who can't communicate in their native language to nonetheless work together. User stories act like this. We don't expect customers or users to view the system the same way that programmers do; stories act as a pidgin language where both sides can agree enough to work together effectively. But what are characteristics of a good story?
Good user stories follow Bill Wake’s INVEST model . They’re I ndependent, N egotiable, V aluable, E stimable, S mall, and T estable. The small requirement drives us to split large stories.