Please enable JavaScript.

Coggle requires JavaScript to display documents.

SEG - Coggle Diagram

- - - - Understand
      - Extend
      - Re-use
      - Test
  - - - Models the domain of the application
      - Usually one-to-one mapping to real world objects or concepts
      - Contains relevant domain or business logic
      - Responds to state queries and operations on its state
      - Independent of particular view or controller (should work without either)
    - - Graphically represents state of model to the user
      - Can consist of many sub-views
      - Typically passive: responds to update operations
      - Receives user input, but passes this on to controller
    - - This is the plumbing between the model and view
      - Translates user actions (button presses, keyboard input) into operations on the model
      - May be very simple - single class is acceptable, but decomposition and multiple controllers for different sub-views or functionalities are possible
- - - - Predictable
      - Estimates and Schedules are met with consistency
      - Meets functional and quality expectations
  - - - "A lightweight, low-ceremony, high-discipline methodology"
      - Contains values and practices
        Check Agile Planning section
    - - An empirical framework for developing and sustaining complex products
      - Framework for a set of processes, not a process in itself
        
        Lightweight
        
        Simple to understand
        
        Difficult to master
      - Principles
        
        Inspection
        
        Adaption
        
        Transparency
      - Framework
        
        Teams
        
        Roles
        
        Scrum Master
        
        Team
        
        Product Owner
        
        Events
        
        Daily Scrum
        
        Sprint Planning
        
        Sprint Review
        
        Retrospective
        
        Backlog Grooming
        
        Artifacts
        
        Burndown
        
        Velocity Chart
        
        Calendar
        
        Story Map
        
        Backlogs
        
        Product Backlog
        
        Release Backlog
        
        Sprint Backlog
        
        Rules
    - - Japanese for "signboard"
      - I think this is essentially the board with TO DO, DOING, and DONE sections. You arrange each task/postit into each section
      - Core Principles
        
        Visualise Work
        Making the work visible-- along with block, bottlenecks and queues--- instantly leads to increased communication and collaboration
        
        Limit Work in Progress
        By limiting how much unfinished work is in progress, you can reduce the time it takes an item to travel through the Kanban system. You can also avoid problems caused by task switching and reduce the need to constantly reprioritise items
        
        Focus on Flow
        Collect metrics to analyse the flow of work and get leading indicators of future problems by analyzing the flow of work.
        
        Continuous Improvement
        Teams measure their effectiveness by tracking flow, quality, throughput, lead times, and more. Experiments and analysis are used to improve the team's effectiveness
      - Kanban Card
        
        Ticket name/ID
        
        Task Description
        
        Time Estimate
        
        Workers
        
        Type of task
        
        Blocker
        (There is a need for something to happen before this task can be completed)
  - - - Minimalist five step process
        
        Developing an overall shape object model
        
        Building a features list
        
        Planning by feature
        
        Iterative design-by-feature
      - Key Roles
        
        Chief Architect
        
        Chief Programmer
    - - Practices
        
        Iterative Development
        
        Feature Based Planning
        
        Customer Focus Group Reviews
      - Leadership-collaboration management philosophy
    - - Focuses on people
        
        Collaboration
        
        Good Citizenship
        
        Co-operation
      - Methods scale to project on two factors:
        
        Project Size
        
        Criticality
      - Crystal Teams
        
        "People are communicating beings, doing best face-to-face, in person, with real-time question and answer
        
        "People have trouble acting consistently over time"
        
        "People are highly variable, varying from day to day and place to place"
        
        "People generally want to be good citizens, are good at looking around, taking initiative, and doing 'whatever is needed' to get the project to work"
      - 7 Properties
        
        2. Continual Feedback
        Regular meetings with entire team and stakeholders
        
        3. Constant Communication
        Small projects expect the entire team to be in the same room, while larger projects are expected to be co-located in the same facility.
        
        1. Frequent Delivery
        On larger, or more critical projects, the deliverables may not go into production, but stakeholders will see intermediate versions and be able to provide feedback
        
        4. Safety
        Team member feel safe to communicate truth without fear of reprisal; true in most agile
        Project safety: some software projects affect the safety of their end-users. For example, a space shuttle system is much more critical than a recipe organiser
        
        5. Focus
        Team members are expected to know the top two or three priority items each member should be working on and should be given time to complete them without interruption.
        
        6. Access to Users
        The project team will have access to one or more users of the system being built
        
        7. Automated Tests and Integration
        As it says, I guess
    - - Principles
        
        People
        
        Process
        
        Products
        
        Practices
      - Concept
        
        All stakeholders understand and buy into business vision and objectives
        
        All stakeholders are empowered to make decisions within their area of expertise
        
        Focus on the business need
        
        Deliver on time
        
        Collaborate
        
        Never compromise quality
        
        Build incrementally
        
        Communicate continuously and clearly
      - What is actually different?
        
        Explicit pre-project phase (envisioning)
        
        Extended (and more hierarchical) roles and responsibilites
        
        More defined project products
        
        Values training and qualification
    - - Shu
        The student follows the teachings of one master precisely.
        He concentrates on how to do the task, without worrying too much about the underlying theory.
        If there are multiple variations, he concentrates on just the one way his master teaches hime
      - Ha
        The student branches out, learning the underlying principles and theory behind the technique.
        He learns from other masters and integrates that learning into his practice
      - Ri
        The student now learns from his own practice rather than other people. He creates his own approaches and adapts what he;s learned to his own particular circumstances.
- - - - Each persona used to represent a stakeholder group
      - Benefits
        
        Users become tangible and personal
        
        Different personas for the same person
        
        Incorporate personas into stories
      - Describes
        
        Background
        
        Job function
        
        Situation in the organisation
        
        Beliefs, desires, anxieties
        
        Maybe an image
    - - As-is
        Scenarios represent the current practice
      - To-be
        Scenario represents the improved practice
    - - Types of Stakeholders
        
        Secondary Stakeholders
        People who do not directly interact with the system but provide input or receive output
        
        Tertiary Stakeholders
        People who do not directly interact with the system but are affected by it
        
        Facilitating Stakeholders
        People who are involved in the design, development, and maintenance of the system
        
        Primary Stakeholders
        People who actually use the system
  - - - Card
        Story cards can be written on notecards or post-its
      - Conversation
        Details of the story come out during conversations with the product owner
        
        Design ideas and working documents that elaborate how you are going to achieve user story success
        
        Storyboards
        
        Scenarios
        
        Purposeful models
        
        Help to understand the problem
        
        Share understanding
        
        User centric interaction design
      - Confirmation
        Tests that will confirm whether the story was coded correctly
    - - I = Independent
      - N = negotiable
      - V = valuable
      - E = estimable
      - S = small
      - T = Testable
- - - - People's understanding of the requirements change
      - People make up requirements
      - You effectively put a cap on what you deliver
      - If it goes wrong, it completely fails
      - Produces a tick box culture
        (i.e. software can be ticked even if it is no longer wanted or fails to delight)
      - The requirements change
    - - Agile manifesto
        
        Individual and interaction over process and tools
        
        Working software over comprehensive documentation
        
        Customer collaboration over contract negotiation
        
        Responding to change over following a plan
      - Agile principles
        
        XP Values
        
        Simplicity
        We will do what is needed and asked for, but no more. We will take simple steps to our goal
        
        Communication
        Everyone is part of the team and we communicate face to face daily. We work on everything together
        
        Feedback
        Deliver working software and every iteration commitment. Demonstrate software early on then listen carefully to feedback and make any changes needed
        
        Respect
        Everyone gives and receives the respect they deserve as a valued team member
        
        Courage
        We will tell the truth about our progress and our estimates
        
        XP Practices
        
        Feedback
        
        The Planning Game
        At the start of each iteration, everyone meets to flesh out and estimate requirements
        
        On-site Customer
        Development team has continuous access to a real life person who will be using the software
        
        Test Driven Development
        Developers work test-first
        
        Pair Programming
        Two programmers sat at the same computer write all the code
        
        Continuous Process
        
        Small Releases
        Release early and often, adding a few features at a time
        
        Continuous Integration
        Developers integrate new code into the system as often as possible. All functional tests must still pass after integration or the new code is discarded
        
        Refactoring
        As developers work, the design should be evolved to keep it as simple as possible
        
        Shared Understanding
        
        Collective Ownership
        The code is owned by all developers, and they make changes anywhere in the code at anytime they feel necessary
        
        Metaphor
        Customers, managers, and developers construct a metaphor, or set of metaphors after which to model the system
        
        Simple Design
        Developers are urged to keep the design as simple as possible
        
        Coding Standards
        
        Programmer Welfare
        
        Sustainable Pace
        
        Avoiding burnout
        
        Scope and prioritisation
    - - SCRUM
  - - - Features
      - Bugs
      - Technical Work
      - Knowledge Acquisition
    - - Describe the requirements of the product in a visual way
      - Storyboards describe the operation of the software from the user's point of view as well as the basic function of the software
      - They are a plan and a record of the design decisions for the product
      - Everyone in the team works to the storyboards
      - They can show the layout of your app detailing colour, fonts, etc..
      - This is the static design
    - - Interactions between the buttons, text boxes, etc..
      - Starting and exiting the program
      - The range of inputs that can be tolerated
      - The ranges of outputs that will be allowed
      - Details of any warning messages
      - The details of the calculations
      - Use them to test your software