Rules: >You start from the last letter of the term posted previously. >In case, more than one terms posted with same letters (concurrently posted), you start with the latest term. >Only PMI-ACP® Terms in this relay. >A term may include multiple words. >Acronyms are fine. please include the expansion before the description. >Your term needs to be followed by a short description of the term. >No successive posting of term by the same member. The below one is fine. member A: --------L member B: L----- --- ----D member A: D---- ------ ---- > If you don't get a term starting from a particular letter(last letter of previous term), feel free to start from the next letter. e.g. previous term - buzz, if you don't get a term starting with 'z', you may start with 'a'. (Hoping this rule will be rarely used.:) >End date of game: No end date. Till the game goes on.
Markus KopkoAI Enabler for Project & Program Mgmt | Founder PMotion.ai / The PM
AI Coach| PMotion.aiHamburg, Hamburg, Germany
Team Space -
William Pietri put together a list of rules for great development spaces. Amongst the well documented suggestions like putting the team together, room for daily standup, enough whiteboards and information radiators other suggestions included,
? Get collaboration-friendly desks – William suggested this as one of the big pitfalls. He mentioned that many companies would like to foster collaboration but end up having furniture which is hostile to it.
? Minimize distractions – The recommended rules to minimize distractions for the development stations include no phones, no email or IM, no off-topic conversation, less foot traffic and executives stay on mute.
? Only direct contributors sit in the room – No chickens and certainly not the receptionist nor the sales people who would mostly be on the phone.
? Pleasant space – Good lighting, decent air, plants, decorations and snacks. Saving Changes...
Markus KopkoAI Enabler for Project & Program Mgmt | Founder PMotion.ai / The PM
AI Coach| PMotion.aiHamburg, Hamburg, Germany
Envision phase:
Envision phase captures the essence of a potential product and creates a rough plan for the creation of that product. It begins with the creation of a vision, followed by the creation of a high-level product backlog and frequently a product roadmap.
Envision phase is the first phase of the Agile Project Management (APM) framework. Saving Changes...
Markus KopkoAI Enabler for Project & Program Mgmt | Founder PMotion.ai / The PM
AI Coach| PMotion.aiHamburg, Hamburg, Germany
Extreme Programming
Extreme Programming (or XP) is a set of values, principles and practices for rapidly developing high-quality software that provides the highest value for the customer in the fastest way possible. XP is extreme in the sense that it takes 12 well-known software development "best practices" to their logical extremes.
The 12 core practices of XP are:
1) The Planning Game: Business and development cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same:
a) Business comes up with a list of desired features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes in broad strokes what is required. User stories are typically written on 4x6 cards.
b) Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration).
c) Business then decides which stories to implement in what order, as well as when and how often to produce a production releases of the system.
2) Small Releases: Start with the smallest useful feature set. Release early and often, adding a few features each time.
3) System Metaphor: Each project has an organizing metaphor, which provides an easy to remember naming convention.
4) Simple Design: Always use the simplest possible design that gets the job done. The requirements will change tomorrow, so only do what's needed to meet today's requirements.
5) Continuous Testing: Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Tests in XP come in two basic flavors.
a) Unit Tests are automated tests written by the developers to test functionality as they write it. Each unit test typically tests only a single class, or a small cluster of classes. Unit tests are typically written using a unit testing framework, such as JUnit.
b) Acceptance Tests (also known as Functional Tests) are specified by the customer to test that the overall system is functioning as specified. Acceptance tests typically test the entire system, or some large chunk of it. When all the acceptance tests pass for a given user story, that story is considered complete. At the very least, an acceptance test could consist of a script of user interface actions and expected results that a human can run. Ideally acceptance tests should be automated, either using the unit testing framework, or a separate acceptance testing framework.
6) Refactoring: Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn't break anything because you have the tests.
7) Pair Programming: All production code is written by two programmers sitting at one machine. Essentially, all code is reviewed as it is written.
8) Collective Code Ownership: No single person "owns" a module. Any developer is expect to be able to work on any part of the codebase at any time.
9) Continuous Integration: All changes are integrated into the codebase at least daily. The tests have to run 100% both before and after integration.
10) 40-Hour Work Week: Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.
11) On-site Customer: Development team has continuous access to a real live customer, that is, someone who will actually be using the system. For commercial software with lots of customers, a customer proxy (usually the product manager) is used instead.
12) Coding Standards: Everyone codes to the same standards. Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code. Saving Changes...
A characteristic of a process whereby the assets or activities of a work stream become available or occur just as they are needed.
Agile is based on JIT. User stories are created when they are needed and not before. Releases happen when there is an appropriate value in releasing, not before and not after. Each iteration has a commitment which is met on time. Saving Changes...
Markus KopkoAI Enabler for Project & Program Mgmt | Founder PMotion.ai / The PM
AI Coach| PMotion.aiHamburg, Hamburg, Germany
Empirical Process Control -
The word "empirical" denotes information gained by means of observation, experience, or experiment. The empirical process control constitutes a continuous cycle of inspecting the process for correct operation and results and adapting the process as needed. There are three legs that hold up every implementation of empirical process control: transparency, inspection, and adaptation. The first leg is transparency. It means that those aspects of the process that affect the outcome must be visible to those controlling the process. The second leg is inspection. The various aspects of the process must be inspected frequently enough that unacceptable variances in the process can be detected. The third leg of empirical process control is adaptation. The process or the material being processed must be adjusted if one or more aspects of the process are outside acceptable limits and the resulting product will be unacceptable. Saving Changes...
Lead time:
Lead time is the time elapsed between the identification of a requirement and its fulfillment. Defining a more concrete measurement depends on the situation being examined: for instance, when focusing on the software development process, the "lead time" elapsed between the formulation of a user story and that story being used "in production", that is, by actual users under normal conditions.
The lead time can be thought of as the cycle time plus any time the story spent in the backlog. Saving Changes...
Markus KopkoAI Enabler for Project & Program Mgmt | Founder PMotion.ai / The PM
AI Coach| PMotion.aiHamburg, Hamburg, Germany
skipping E:
Feature Breakdown Structure (FBS) -
During detailed planning, agile development favors a feature breakdown structure (FBS) approach instead of the work breakdown structure (WBS) used in waterfall development approaches. Feature breakdown structures are advantageous for a few reasons:
1. They allow communication between the customer and the development team in terms both can understand.
Last Updated 6/15/2015
2. They allow the customer to prioritize the team's work based on business value.
3. They allow tracking of work against the actual business value produced.
It is acceptable to start out with features that are large and then break them out into smaller features over time. This allows the customer to keep from diving in to too much detail until that detail is needed to help facilitate actual design and delivery. Saving Changes...
Skipping E:
Facilitation:
Facilitation is 'making things easier'. A facilitator does the role of conducting a meeting. This role usually entails that the facilitator will take little part in the discussions on the meeting's topic, but will focus primarily on creating the conditions for effective group processes, in the pursuit of the objectives for which the meeting was convened.The facilitator function is making sure that the time utilized and the effort expended are appropriate and valuable, and that there is as little as possible waste in meetings and normal day-to-day activities.
@Markus: FBS is already covered. Saving Changes...
