Agile management Agile management or agile project management is an iterative and incremental method of managing the design and build activities for engineering, information technology, and new product or service development projects in a highly flexible and interactive manner, for example agile software development. It requires capable 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 program 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. The Agile Project Leadership Network[3] provides a community of practice for those using Agile methods, with international conferences and online forums. See also[edit] References[edit]
Team TIBET(tm) Planning poker Planning poker, also called Scrum poker, is a consensus-based technique for estimating, mostly used to estimate effort or relative size of development goals in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed. The method was first defined and named 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. Process[edit] The reason[edit] The reason to use Planning poker is to avoid the influence of the other participants. Equipment[edit] Planning poker is based on a list of features to be delivered and several copies of a deck of numbered cards. The cards in the deck have numbers on them. Planning Poker card deck The reason for using the Fibonacci sequence is to reflect the inherent uncertainty in estimating larger items. Procedure[edit]
Object-oriented programming Overview[edit] Rather than structure programs as code and data, an object-oriented system integrates the two using the concept of an "object". An object has state (data) and behavior (code). Objects correspond to things found in the real world. The goals of object-oriented programming are: Increased understanding.Ease of maintenance.Ease of evolution. The overall understanding of the system is increased because the semantic gap—the distance between the language spoken by developers and that spoken by users—is lessened. Object-orientation takes this to the next step. In addition to providing ease of maintenance, encapsulation and information hiding provide ease of evolution as well. An object-oriented program usually contains different types of objects, each corresponding to a real-world object or concept such as a bank account, a hockey player, or a bulldozer. History[edit] Fundamental features and concepts [edit] A survey by Deborah J. Benjamin C.
INVEST in Good Stories (French) 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. But what are characteristics of a good story? I – IndependentN – NegotiableV – ValuableE – EstimableS – SmallT – Testable Independent Stories are easiest to work with if they are independent. We can’t always achieve this; once in a while we may say things like “3 points for the first report, then 1 point for each of the others.” Negotiable… and Negotiated A good story is negotiable. Valuable A story needs to be valuable. This is especially an issue when splitting stories. Estimable Small Testable
Software prototyping Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing. A prototype typically simulates only a few aspects of, and may be completely different from, the final product. Prototyping has several benefits: The software designer and implementer can get valuable feedback from the users early in the project. Overview[edit] The original purpose of a prototype is to allow users of the software to evaluate developers' proposals for the design of the eventual product by actually trying them out, rather than having to interpret and evaluate the design based on descriptions. The practice of prototyping is one of the points Frederick P. Outline of the prototyping process[edit] Dimensions of prototypes[edit] Horizontal Prototype[edit]
User story History[edit] User stories originated with Extreme Programming (XP), whose first written description in 1998 only claimed that customers defined project scope "with user stories, which are like use cases". Rather than offered as a distinct practice, they were described as one of the "game pieces" used in the planning game. In 2001, Ron Jeffries proposed the well-known Three C's formula, i.e. A Card (or often a Post-it note) is a physical token giving tangible and durable form to what would otherwise only be an abstraction; A Conversation is taking place at different time and places during a project between the various stakeholders concerned by the given feature (customers, users, developers, testers, etc.), which is largely verbal but most often supplemented by documentation; The Confirmation, the more formal the better, ensures that the objectives the conversation revolved around have been reached finally. Creating user stories[edit] Format[edit] "As a <role>, I want <goal/desire>" Run tests
Manifesto for Agile Software Development Splitting User Stories Good user stories follow Bill Wake’s INVEST model. They’re Independent, Negotiable, Valuable, Estimable, Small, and Testable. The small requirement drives us to split large stories. But the stories after splitting still have to follow the model. Many new agile teams attempt to split stories by architectural layer: one story for the UI, another for the database, etc. Over my years with agile, I’ve discovered nine patterns for splitting user stories into good, smaller stories. (Note: As with any pattern language, I didn’t invent these patterns, I’ve just observed and compiled them. How Small? How small should stories be? When you’re in a planning meeting and you hit your trigger estimate, pull out the cheat sheet at the end of this article and try a few of the patterns until you find a good split. Which Pattern to Use You’ll often find that you can split a story using several of the patterns. Choose the split that lets you deprioritize or throw away a story. Pattern #1: Workflow Steps
5 Tips For Using LinkedIn's Mobile Site LinkedIn's mobile site is a powerful way to get in touch with its 135 million users. February 13, 2012 Have you checked out LinkedIn's mobile site yet? No, not the mobile app–the in-browser mobile site. LinkedIn released the updated mobile site (along with iPhone and Android apps) last summer. “We are seeing mobile grow at a very rapid pace, as high as 400 percent a year,” Joff Redfern, mobile product director at LinkedIn told The New York Times in August of last year. Want to know more? 1. Did you just read an interesting article on your mobile device and you think that it's something your LinkedIn contacts should see right away? You can share a text update or drop in a link to content you'd like your contacts to see. 2. When you open LinkedIn's mobile site, you're greeted with a scrollable list of your connections' updates. That smart design saves precious mobile bandwidth (and money, for those not on an unlimited data plan). 3.
Scrum Scrum is an iterative and incremental agile software development framework for managing product development. It defines "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal", challenges assumptions of the "traditional, sequential approach" to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines in the project. A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called "requirements churn"), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. Later, Schwaber with others founded the Scrum Alliance and created the Certified Scrum Master programs and its derivatives. Each sprint is started by a planning meeting.
The Backlog Caveats I continually abuse 2 terms below, Backlog and Sprint. Sprints don’t have to be 2 weeks, but for the sake of simplicity, I assume they are. Also, Backlogs contain user stories, not requirements or features. However, I assume for the sake of this article your features are already formed into user stories. Review: What is a Backlog? First, a review. While a requirements document may say “The application needs to allow users to register and login”, the Product Backlog would probably have that as 4 line items: Upon entering [product URL], and the user isn’t logged in, they’ll be presented with a login screen. There are a lot more user stories you can write, or even refining the ones above. These units of work, called user stories, are stored in the Backlog. Review: Sprint Backlog A Sprint Backlog is where you put features/user stories that team needs to complete each Sprint. What Are We Building? There were 3 huge problems with that. Scope Creep Unless you use a Backlog in Scrum.
Technical Debt This article will discuss what Technical Debt is from a Flash/Flex developer perspective, how it negatively affects my Scrum projects, and what are some of the prescribed ways to prevent it. Nothing ground breaking here folks, just corroboration that TD IS a major problem, and not even Scrum is immune. What is Technical Debt? Martin Fowler has a good summary about what Technical Debt is. You have a piece of functionality that you need to add to your system. Git-r-done vs. doing it right. Another quote which describes the metaphor: …doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. He goes on to mention that unlike money, you cannot effectively measure technical debt. Signs of Technical Debt There are various signs of Technical Debt. System fragility examples include when you move a login button, the entire login form doesn’t work. Another example is the statement “the application doesn’t seem to be working”. Pullback & Reassess