Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
7 changed files
with
277 additions
and
233 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,118 +1,146 @@ | ||
| ============================ | ||
| Day 2 - Thursday 9 2008 | ||
| Day 2 - Agile Process | ||
| ============================ | ||
|
|
||
| by Mike Robinson | ||
|
|
||
| Agile Process by Mike Robinson | ||
| Introduction | ||
| ============================== | ||
|
|
||
| - Agile is a conceptual framework | ||
| - Agile does have documentation | ||
| - Agile methods have been around since the 1990s and were united by the agile manifesto. | ||
| - Agile empowers the workers | ||
| - Agile knows their finished when they are finished | ||
| - Agile is: | ||
| - Like driving a race car, you know the course but can't account for all the variables | ||
| - Agile is a conceptual framework | ||
| - Agile does have documentation | ||
| - Agile methods have been around since the 1990s and were united by the agile manifesto. | ||
| - Agile empowers the workers | ||
| - Agile knows their finished when they are finished | ||
| - Agile is: | ||
|
|
||
| - Like driving a race car, you know the course but can't account for all the variables | ||
|
|
||
| Agile Values | ||
| ---------------- | ||
| - Individuals and interactions > process and tools | ||
| - Working software > comprehensive documentation | ||
| - Customer collaboration > contract negotiation | ||
| - Responding to change > following a plan | ||
| - Planning is more important than plans | ||
|
|
||
| - Individuals and interactions > process and tools | ||
| - Working software > comprehensive documentation | ||
| - Customer collaboration > contract negotiation | ||
| - Responding to change > following a plan | ||
| - Planning is more important than plans | ||
|
|
||
| Agile Principles | ||
| ---------------- | ||
| - **Highest priority is to satisfy the customer** | ||
| - **Welcome changing requirements**, even late in development. Agile processes harness change for the customer's competitive advantage | ||
| - **Deliver working software frequently**. 90% completion is a lie. Its either not started, working, or finished. If you do not deliver working software you are of no value. | ||
| - Business people and developers must **work together** daily | ||
| - Build projects over **motivated people** | ||
| - Give developers the support they need and trust them to **get the job done** | ||
| - **Working software is the primary measure of growth.** | ||
| - Information is best done in **face-to-face conversation** | ||
| - Agile processes promote **sustainable development** by not overworking people to meet deadlines. | ||
| - The sponsors, developers, and users should be able to **maintain constant speed**. | ||
| - **Simplicity** is really awesome. Code is a liability to any organization. The less code you can deliver the better. | ||
| - The best architecture, requirement, and designs emerge from **self-organizing teams**. | ||
| - At regular intervals the team reflects on how to become more effective, then **adjusts its behavior accordingly**. | ||
|
|
||
| - **Highest priority is to satisfy the customer** | ||
| - **Welcome changing requirements**, even late in development. Agile processes harness change for the customer's competitive advantage | ||
| - **Deliver working software frequently**. 90% completion is a lie. Its either not started, working, or finished. If you do not deliver working software you are of no value. | ||
| - Business people and developers must **work together** daily | ||
| - Build projects over **motivated people** | ||
| - Give developers the support they need and trust them to **get the job done** | ||
| - **Working software is the primary measure of growth.** | ||
| - Information is best done in **face-to-face conversation** | ||
| - Agile processes promote **sustainable development** by not overworking people to meet deadlines. | ||
| - The sponsors, developers, and users should be able to **maintain constant speed**. | ||
| - **Simplicity** is really awesome. Code is a liability to any organization. The less code you can deliver the better. | ||
| - The best architecture, requirement, and designs emerge from **self-organizing teams**. | ||
| - At regular intervals the team reflects on how to become more effective, then **adjusts its behavior accordingly**. | ||
|
|
||
| Why use agile? | ||
| ------------------------ | ||
| - Agile lets you meet what the marketing folks want to give to customers | ||
| - Agile means good for business so you can plan out hours better | ||
| - Operations likes it because your updates are simpler | ||
| - Development likes it because it empowers developers | ||
|
|
||
| - Agile lets you meet what the marketing folks want to give to customers | ||
| - Agile means good for business so you can plan out hours better | ||
| - Operations likes it because your updates are simpler | ||
| - Development likes it because it empowers developers | ||
|
|
||
| Developers need to be respected | ||
| ------------------------------- | ||
| - Don't agree on schedules without developer input | ||
| - Don't agree on tasks without developer inpit | ||
| - Developers need to be honest in describing what needs to be done | ||
| - Get developers to demo their work to the customer! | ||
|
|
||
| - Don't agree on schedules without developer input | ||
| - Don't agree on tasks without developer input | ||
| - Developers need to be honest in describing what needs to be done | ||
| - Get developers to demo their work to the customer! | ||
|
|
||
| Charging for the assessment phase | ||
| ------------------------------------ | ||
| - Bill for it | ||
| - Tell customers that you'll bill for planning as long as the customer is willing to pay | ||
|
|
||
| - Bill for it | ||
| - Tell customers that you'll bill for planning as long as the customer is willing to pay | ||
|
|
||
| Roles on a team | ||
| ------------------------------ | ||
| - Product owner: Drives the project | ||
| - Project Manager: Handles the resources | ||
| - Team: Developers | ||
| - Stakeholders: Customers | ||
| - Users: obvious | ||
|
|
||
| - Product owner: Drives the project | ||
| - Project Manager: Handles the resources | ||
| - Team: Developers | ||
| - Stakeholders: Customers | ||
| - Users: obvious | ||
|
|
||
| Artifacts | ||
| ------------ | ||
| - Impediment list (use stickies on the wall to be obvious) | ||
| - Project iteration | ||
| - Working code | ||
|
|
||
| - Impediment list (use stickies on the wall to be obvious) | ||
| - Project iteration | ||
| - Working code | ||
|
|
||
| Agile requirements analysis, estimating and planning | ||
| -------------------------------------------------------- | ||
| - Identify the users | ||
| - Gather requirements from the users via | ||
| - Interviews | ||
| - Questionnaires | ||
| - Observation | ||
| - workshops | ||
| - Ways of documenting | ||
| - Use cases fixed the ATM returning cards after cash | ||
| - too big to plan for and measure with | ||
| - prone to include UI details | ||
| - User stories | ||
| - a tiny bit of information. | ||
| - You can attach these to use cases | ||
| - Estimating development | ||
| - Prediction is difficult! | ||
| - You will never be 100% accurate | ||
| - Short efforts on estimates are accurate | ||
| - Long efforts on estimates are always off | ||
| - Breakdown tasks into manageable chunks | ||
| - Estimation performed by development team | ||
| - Deriving an estimate | ||
| - Expert opinion | ||
| - Analogy | ||
| - Planning poker | ||
| - Story points are a relative measure of size of a story. 10 points is more than 5. | ||
| - Ideal time it would take to complete a task without interruptions. A football game is 60 ideal minutes and 120 minutes with interruptions | ||
| - Planning poker | ||
| - Each member gets six cards | ||
| - People put the value they think it will take down on the table. The most common value is how long it will take in story points. | ||
| - If one person has things way off, then talk out why there is a discrepancy | ||
| - After each task has point assigned, figure out how long a point is worth. Use previous effort to determine the length of a story point. | ||
| - Prioritizing user stories | ||
| - Priority assignment is the primary responsibility of the Product Owner | ||
| - Velocity | ||
| - Measure the rate of progress of a team | ||
| - Amount of story points completed in the last iteration | ||
| - Next iteration = same as last iteration ("yesterday weather") | ||
| - velocity corrects estimation error | ||
| - Accommodate developer optimism | ||
| - Burndown chart | ||
| - Plots the amount of committed effort left against the time left to complete the iteration | ||
|
|
||
| - Identify the users | ||
|
|
||
| - Gather requirements from the users via | ||
|
|
||
| - Interviews | ||
| - Questionnaires | ||
| - Observation | ||
| - workshops | ||
|
|
||
| - Ways of documenting | ||
|
|
||
| - Use cases fixed the ATM returning cards after cash | ||
|
|
||
| - too big to plan for and measure with | ||
| - prone to include UI details | ||
|
|
||
| - User stories | ||
|
|
||
| - a tiny bit of information. | ||
| - You can attach these to use cases | ||
|
|
||
| - Estimating development | ||
|
|
||
| - Prediction is difficult! | ||
| - You will never be 100% accurate | ||
| - Short efforts on estimates are accurate | ||
| - Long efforts on estimates are always off | ||
| - Breakdown tasks into manageable chunks | ||
| - Estimation performed by development team | ||
| - Deriving an estimate | ||
|
|
||
| - Expert opinion | ||
| - Analogy | ||
| - Planning poker | ||
|
|
||
| - Story points are a relative measure of size of a story. 10 points is more than 5. | ||
| - Ideal time it would take to complete a task without interruptions. A football game is 60 ideal minutes and 120 minutes with interruptions | ||
|
|
||
| - Planning poker | ||
|
|
||
| - Each member gets six cards | ||
| - People put the value they think it will take down on the table. The most common value is how long it will take in story points. | ||
| - If one person has things way off, then talk out why there is a discrepancy | ||
| - After each task has point assigned, figure out how long a point is worth. Use previous effort to determine the length of a story point. | ||
|
|
||
| - Prioritizing user stories | ||
|
|
||
| - Priority assignment is the primary responsibility of the Product Owner | ||
|
|
||
| - Velocity | ||
|
|
||
| - Measure the rate of progress of a team | ||
| - Amount of story points completed in the last iteration | ||
| - Next iteration = same as last iteration ("yesterday weather") | ||
| - velocity corrects estimation error | ||
| - Accommodate developer optimism | ||
| - Burndown chart | ||
|
|
||
| - Plots the amount of committed effort left against the time left to complete the iteration | ||
|
|
||
| Agile planning game |
32 changes: 0 additions & 32 deletions
32
ploneconf2008/day_2_bringing_open_source_practices to education.rst
This file was deleted.
Oops, something went wrong.
31 changes: 31 additions & 0 deletions
31
ploneconf2008/day_2_bringing_open_source_practices_to_education.rst
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,31 @@ | ||
| ================================================================= | ||
| Day 2 - Bringing Open Source Practices to Educational Enterprises | ||
| ================================================================= | ||
|
|
||
| moving k-12 to the modern era | ||
|
|
||
| Can't do business with a web site that sucks | ||
| -------------------------------------------- | ||
|
|
||
| - Investigate: http://clubs.psu.edu/up/taxidermy | ||
| - Can't afford the old school ways | ||
| - Chose plone because it gives a lot of web 2.0 model of user generated cotnent | ||
|
|
||
| Ecosystem | ||
| --------- | ||
|
|
||
| - Engage learners, teachers, families, and communities | ||
| - Modernizing business processes | ||
| - Cleaning up a bucket of organizations | ||
| - Diverse organization | ||
| - Platform to build some homogeny on | ||
| - Many little bunkers of IT staff | ||
| - IT at Penn state is distributed (not) | ||
|
|
||
| - IT at Penn state is actually disorganized | ||
|
|
||
| Behaviors and Structures | ||
| ------------------------ | ||
|
|
||
| - Policies | ||
| - Standards |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,18 +1,12 @@ | ||
| ============================ | ||
| Day 2 - Thursday 9 2008 | ||
| ============================ | ||
| ======================= | ||
| Day 2 - Consultant Talk | ||
| ======================= | ||
|
|
||
| Figuring out charge rates | ||
| -------------------------- | ||
|
|
||
| - Don't lose money | ||
| - Fixed price for very short projects only | ||
| - Give estimates for x number of days at x price | ||
| - Optional scope reevaluations can be critical | ||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
| - Give a percentage rate on things you don't know | ||
| - Don't lose money | ||
| - Fixed price for very short projects only | ||
| - Give estimates for x number of days at x price | ||
| - Optional scope reevaluations can be critical | ||
| - Give a percentage rate on things you don't know |
Oops, something went wrong.