City universitylondon devprocess_g_a_reitsch
Upcoming SlideShare
Loading in...5
×
 

City universitylondon devprocess_g_a_reitsch

on

  • 112 views

Proposed Development Process

Proposed Development Process

Statistics

Views

Total Views
112
Slideshare-icon Views on SlideShare
112
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    City universitylondon devprocess_g_a_reitsch City universitylondon devprocess_g_a_reitsch Presentation Transcript

    • Proposed Development Process for City University London by G. Alan Reitsch alanreitsch@gmail.com 04.10.2013
    • Project Guidelines – Project Success • Days Deviation from Scheduled Delivery Date • Deviation from Budget • User Satisfaction • Value Generation (ROI, Strategic Positioning, Charitable Contribution, etc…) – Project Management • Schedule • Scope • Budget • Quality – Online, Desktop, Embedded
    • Business Scenario and Culture Shape Approach – Benefits of latest techniques and principles • Competitive offering of skill building for staff attracts talent. • Implementation of recent forms offers internships and opportunities for students. • In the field teaching provides learning context. • Implementation and integration of student projects with University technology. • Cultural Influences – Encourage Fun, Innovation, Courage – Encourage Discipline, Conduct, and Trust
    • Methodologies – Theory and Practice – Keep It Simple – Do What Works – Drive Value – Continuous Improvement • Waterfall for Microsoft Led to Agile at Catalysis – The Vendor Plume and Pool Reduction Competition – Sprints and Minimal Documentation – Open seating – Continuous Integration – Reuse, Refactore, and SOA • The Evolution of Methodology at Copart, Inc. – Waterfall led to Agile-blend XP as business analysts moved from centralized to embedded following years of requirements documentation. – We built the existing site in new technology without specification. – We then refactored to the one year late and incomplete functional specification. – Release was then scrapped because of user revolt and low adoption; we simultaneously deployed the old and new websites. – We then conducted UAT, redesigned the site, built functional mock-ups by pairing engineering to stakeholders and users, and then executed via Sprints.
    • Method Option - SDLC Waterfall – Phases • Requirements • Design • Implementation • Verification • Maintenance – Benefits • Plan-focused – Challenges • Each phase requires a documentation deliverable. • Iteration expensive, unresponsive, and dependent. • Developers distanced from clients. – Client Trust » Expectations – Intermediaries – Developer Trust » Lack of Insight • Scheduling Inefficiencies
    • Method Option - MSF (Microsoft Solution Framework) – Waterfall with Spiral Iteration of Requirements – Phases • Envision – Milestone: Vision Approved • Plan – Milestone: Project Plan Approved • Develop – Milestone: Scope Complete • Stabilise – Milestone: Release Ready • Deploy – Benefits • Robust Requirements • Plan-focused – Challenges • Process-focus • Unresponsive to Rapid Change • Track Record
    • Method Option - Agile and Scrum – Principles • Value Not Process – Individuals and Interactions - Customer Collaboration – Working Product - Response to Change – Methodology • Scrum – Sprint cycles of two to six weeks for deliverables: typically four. » Pre Sprint: Plan Features (Product Backlog, Planning Meeting, Sprint Backlog Locked) » Sprint: Build (Daily Scrums, Impediments) » Post Sprint: Review and Retrospective – Benefits • Provides predictable value quickly. • Individual and team focus and achievement. • Stand-ups facilitate communication and collaboration. – Challenges • No Prescribed Engineering Practices. • Scales poorly across enterprise for multiple teams and distributed developers. • Post-product documentation difficult to prioritise. • Continuous development and maintenance outside methodology.
    • Agile Scrum Methodology http://en.wikipedia.org/wiki/File:Scrum_process.svg
    • Method Option - Agile and Extreme Programming (XP) • Paired Coding – Specialist & Second – Touring vs Camping • Collective Ownership – Anyone can change the code as needed. • Open Seating - Colocation Optimized • High Communication with Client • Customer Prioritises ToDo Tasks • No Detailed Design • Short Delivery Cycles – Coding – Testing (Unit, Functional) – Listening (Customer) – Designing (Governance) • Change Within Iterations
    • Proposed Option - Agile Extreme Programming (XP) Development Process – An Agile XP approach that incorporates: • Agile Principles and Scrum Methodologies (Value-driven Sprints, Prioritised Backlogs, Daily Stand-ups) • XP Tools and Techniques (TDD, Governance, Continuous Integration, Engaged Customer and Embedded Liason) • The Communication Intention of Waterfall and MSF via Indexed Communication Channels
    • – Unit Tests First • Effective on Model & Business Objects • Controllers/ Drivers Secondary • Exempted View • Functional Code Eligible to Check-in to Shared Code Branch • Check-ins with Non-functional Code – Local – User Branch Proposed Agile XP - Light Test Driven Design
    • Proposed Agile XP - Governance – Coding Standards • Building for Reuse • Style Guides (Marketing and Brand) • Security Testing – Penetration Tests – Source Code Analysis • Performance Testing – Thread Testing – Load Testing – Libraries and Services • Reuse Efficiencies • Centralised Logic • Remoting Affects Performance
    • Proposed Agile XP - Code Branches – Schedule Based per Product • Emergency – ASAP • Firefight – SLA (Same Day) • Sprint – 5d / 10d / 20d / 30d • Frameworks, Libraries, Service Oriented (Remoting and Performance) • Quarterly, Annual • Enterprise Refactoring and New Products
    • Proposed Agile XP - Continuous Integration Tools – Code Repositories • Check-in Unit Testing • Automated Code Muster at Development (Build) Server – Automated Test Suites – Embedded Test Engineer – Scheduled and Manual Deployments • QA Test Server – Scheduled Release to Testing Environment (Server) – Automated Test Suites – Manual Tests (Check Lists) • Production – Out-of-Rotation Deployment » Rollback Option » Manual Tests Only (Check Lists) – Rolling Deployment
    • Proposed Agile XP - Communication – Daily Stand-ups and Breakouts – Collaboration Tools • Indexed for Search – Communication Channels » Chat » Email » Forums – Auto-generated » Inline (JavaDoc) – Libraries (Wiki) – Defect Tracking – Visuals and Diagrams Uploaded to Wiki • UML – Sequence – Class • Flow for Business Logic • Ecosystem (Systems, Networks, Services, Providers) – Annotated Mock-ups Uploaded to Wiki
    • Proposed Agile XP - Gathering Requirements – Stakeholders • Identification • Stakeholder Inclusion – User Tests • Alpha • Beta • User Acceptance Test Labs • Community Engagement – Feature Voting – Blogs and Forums – Social Networks – Web Traffic Analysis • Multi-variant Tests • Path Analysis • Page Statistics
    • Proposed Agile XP - Business Requirements – Minimise Formal Documentation • Optional – Wireframe – Prose – Use Cases – Prototypes • Necessary – Business Logic – Functional Specifications – Mock-ups • Embedded Business Analysts and Embedded Clients – Not all stakeholders want to sit with Engineers.
    • Proposed Agile XP - Technical Requirements – Backlog • Bug Lists • Library and Service Promotions – Graphical Representation • White boards • UML – Sequence – Class • Flow • Ecosystem – Prototype
    • Proposed Agile XP - Prioritisation Matrix • What Are Criteria? – Who’s Asking – Level of Difficulty? – Specialised Skills – Number of Systems – Amount of Effort – Income Generator – Cost to Implement – Strategic Value – User Impact – User Value – Security Risk Level – Business Risk Level – More? • Order Criteria by Importance (Index) • Weight Criteria • Priority = Index * Weight • Fine Tune Matrix Over Time – Adjust Importance or Weight of Criteria • Fit Prioritised List Into Sprint – Big Rocks and Small Pebbles
    • Proposed Agile XP - Reporting & Continuous Improvement – Burn-downs • Features • Functionality – Traffic Analysis – Social Activity – Customer Support – Project Success Key Performance Indicators • Schedule Adherence • Scope Adherence • Cost Adherence – Dashboards – Surveys • Quality • Customer Value and Loyalty • ROI and Strategic Value
    • Proposed Agile XP Development Process Summary – An Agile XP approach that incorporates Agile principles and Scrum methodologies, XP tools and techniques, and the communication intentions of SDLC Waterfall and Microsoft Solution Framework via indexed communication channels.
    • Benefits – Adherence to User Requests and Wishes – Developer Ownership – Value over Process – Measurable Prioritisation – Nimble Releases (Emergency, Firedrill, Sprint, Enterprise) – Predictable Releases (QA and Production by Schedule) – Highly Stable Rolling Deployments – Predictable and Efficient Code Practices (Standards, Security, Performance) – Rapid Builds Satisfy Short and Long-term Objectives – Measurable Performance Reporting
    • Challenges – Off-book approach requires “handbook” and training. – Proof of Concept for methodology helpful for momentum and adoption.
    • Online Resources and Reference – http://xprogramming.com/index.php – http://en.wikipedia.org/wiki/Software_development_process – http://en.wikipedia.org/wiki/Extreme_Programming – http://en.wikipedia.org/wiki/Scrum_(development) – http://www.slideshare.net/dimka5/introducing-agile-scrum-xp- and-kanban – http://cevsdc.blogspot.co.uk/
    • Thank You