15. Agile introduction Flashcards
Agile Charter
- Authorize PM. Broad and high level (not specific)
- Описывает: Who engaged, what is about, where, when start and end. Vision Statements, Team riles, Code of Conduct, Communication rules, DoD/Success factors.
- Answers the questions: (1) Why are we doing the project (2) Who benefits and how (3) What does DONE mean for the project (4) How are we going to work together (non-colocated/colocated)
- Often single page
- Define success criteria
- Team charter: Team values, Working agreements, Ground rules, Group norms, Servant leader принцип
Agile Contracting
Procurement is always tricky in Agile. Обязательно обсуждать DoD, иначе попадешь в Gulf of Evaluation (имели в виду одно, получили другое)
-
Dynamic Systems Development Method (DSDM) contracting.
Grew out of Rapid Application Development (RAD) Берет лучшее от RAD и Waterfall. DSDM Contracting - Creates a fixed schedule, cost and quality but follows agile framework -
Graduated Fixed-Price Contract
Both parties share some of the risk and reward. Если раньше закончит вендор - больше получит hourly rate и наоборот. Плюсы: focus on results, not hourly rate
Agile Data Model
- Screen Designs - избегаем разночтений между PO и Dev team
- Wireframe - короткая диаграмма, скетч, о процессе. A quick mock-up of a product. Может содержать переход между экранами. Помогает clear understanding
- User Personas - описывает несколько Key SH. Что хочет пользователь, biographical sketch, goal oriented. Focus on the users and who the users will be. Коротко, до 1 страницы. Focus on main usage. As <personal> I want <what?> so that <why?>.</personal>
Agile Modeling
(?) Описание рабочего процесса или системы, которую команда может просмотреть, прежде чем превратить ее в код.
Общие тезисы
- Defining data models determines the structure of data and is sometimes called a data structure.
- Делать самыми простыми. Дополнительно к XP & Scrum frameworks. Сложно с большими распределенными командами.
XP & Modeling идут близко друг к другу:
- Communication
- Simplicity - лучше диаграмма, чем строчки кода
- Feedback - посмотрели диаграму, дали быстрый фиитек
- Courage - как говорить, так и делать изменения и пр. Safe environment
- Humility - мы не можем всё знать и это ОК
Agile Requirements Prioritization Model
Goal
* prioritized Backlog. Prior don’t change в течение iteration.
Общие statements и что нужно учитывать
* Value
* Cost - how much vs ROI
* Risk - riskiest req first
* Difficulty of implementation - safest first
* Success factors - high prob of success
* Regulatory compliance - laws and regulations
* Relationship to other requirements - linked to other requirements
* SH agreement - consensus on requirement
* Urgency - time-sensitive req
Simple prioritization - RAG
* .
Customer-Valued Prioritization
* .
MoSCoW Analysis
* An analysis used to help stakeholders understand the importance of each requirement delivered. MoSCoW is the acronym for Must have, Should have, Could have, and Would like to have.
Kano Analysis/Model
* An analysis of product development and customer satisfaction based on needs fulfilled/not fulfilled vs. satisfaction/dissatisfaction.
5 categories of Customer Preferences:
* Must-be quality - ignored when met, dissatisfied when not met
* One-dimensional quality - spoken attributes that are promises
* Attractive quality - nice-to-have fatures
* Indifferent quality - клиенту всё равно какой цвет выбрать
* Reverse quality - some customers will love, others will hate the feature
Dot Voting Or Multi Voting
* Все получают предопределенное кол-во dots. Можно класть на каждую features часть своих dots. Но нужно избегать большого кол-ва опций, убирать дубликаты, учитывать что люди следуют за толпой.
Monopoly Money
* Все получают деньги из монопологии в размере бюджета проекта. Каждый определяет во что вкладываемся
100-Point Method
* Каждый SH is alloted 100 points. Похоже на dots. Нужно определить public or private voting
Без названия
* От 1 до 9 шкала. Оценивается (?) benefit, penalty, cost and risk of every feature
Agile Project Performance
Общие сведения
- PO responsible for monitor the progress of the project. At least once per Sprint Review
- Sprint Performance измеряется на Daily Scrum. Используется для понимания достижения Sprint Goal. Плюс используется Sprint board
Monitoring and control прогресс спринта/проекта?
- Kanban
- Sprint goal
Дополнительные тулы для мониторинга
- Information Radiator - big signboard (спидометры, диаграммы и пр.)
- Features burnup/burndown charts - show that requirements grew during the project
Agile Requirements
Workshops или Games
- Remember the Future - 20мин написать репорт в будущем, как прошел проект. Все идеи раскидываются по доске. На выходе - define success
- Prune The Product Tree - рисуем большое дерево. Ствол - что уже сделали. Ветки - что надо делать. Люди накидывают идеи, и чем ближе к стволу - тем более приоритетнее
- Speed Boat Game - задаем вопрос “почему ветер дует - кто хочет что-то”, “что нас держит, останавливает”, “в каком направлении движемся”, “какие проблемы по пути”
Use Case Diagram.
- How will the user use the solution. Use case diagram components include system, use case, actors, and relationships.
Coarse Grained Requirements
- Не сильно погружаемся в детали implementation, until the last responsible moment
Agile Sprint / Iterations
Продолжительность: Typically 2-4 weeks
Позволяет получить на выходе: iterations or increments. В случае с Increment - POTENTIALLY releasable part
Этапы:
- Sprint Planning
- Activities / Daily Scrum
- Sprint Review (team делает, показывает demo)
- Sprint Retrospective
Pre-sprint activities
- Creating the vision statement
- Creating the Product Roadmap
- Developing the Product Backlog
Sprint planning:
- одна или несколько встреч (8 hours in 4 weeks iteration)
- Можно не ждать приоритезации всего backlog, начинать первый Sprint когда поймут что есть достаточно Stories в backlog
- PO, Scrum Master, Dev team - встречаются. Dev выбирают сколько смогут сделать User Stories. Это становится Sprint Backlog, затем dev team estimates effort for stories - декомпозиция до Tasks (“post-its”?).
- After Sprint Backlog, team drafts a Sprint Goal
- Договариваемся что будет DoD
- В итоге Sprint Backlog содержит следующие компоненты: (a) Sprint Goal, (b) Sprint Backlog (c) Detailed plan for turning stories into DONE Increment (d) Team capacity
Sprint Review / demo:
- 4 hours for one-month Sprint
- Возможность обсудить CR
- Present and inspect the DONE items
- PO смотрит ДО Scrum Review
- Вся команда collaborates on Product Backlog
Sprint Retrospective
- It is REQUIRED, can be skipped по решению team, но редко
- 3 hours for one-month Sprint
- Lessons learning, look for ways to process improvement
Особенности:
- В начале проекта договариваемся о продолжительности спринта. Все спринты должны быть одинаковой продолжительности
- Sprint backlog - не меняется после старта спринта. CHG заявляются только на Sprint review для следующего Sprint
- Все должны договориться о Definition of Done (DoD)
- PO can cancel a Sprint. Всё равно попадает на Sprint Review
- Post-Its создаются как на этапе Sprint Planning, так и в течение Sprint
- Декомпозиция: Product Backlog -> Sprint Backlog -> Task (smallest element)
- Не после каждого инкремента мы делаем релиз. Это обсуждается PO с Key SH
- SH привлекаются на Sprint Review, но не на leassons learned
Agile Team
Состав:
* PO (one person, or committee with one representative) Represents the business.. Measures the performance of project, forecast completion date. Not even the CEO should try to override decision of the PO (!). Works to engage SH about requirements.
* Scrum Master (coach, проверяет следование процессу, учит организацию в т.ч.). Help PO со всякими фасилитациями. SM может быть среди dev team, но НЕ рекомендуется. Выступает щитом для команды, до Sprint Review. Keep SH в курсе. Может адресовать вопросы к PO Func manager, и при необходимости - обсуждать проблемы на Sprint Retrospective.
* Dev Team
* (not part of the team) Stakeholders and Users
Правила:
* Dev team отвечает , а не каждый отдельный мембер (!)
* Нет роли PM! Распределена среди других ролей
* Self-organized and self-led
* Cross-Func team
* Servant leadership
* В идеале 3-9 человек
* В идеале 100% dedication
* В идеале 33 feet of each other, no physical barrier
* Encourage Emergent Leadership. Anyone can be a leader. Allow team members to take charge. Avoid zero sum rewards
Agile Team Self Assessments Scoring Model
- Thinking
- Collaborating
- Releasing
- Planning
- Developing
Agile terms
- Agile Industrial vs Knowledge Work projects agile best suited for SW development projects. Knowledge: invisible, Autonomy driven, Innovative, High-Uncertainity work, Empirical Processess
- Agile Smells Symptoms of problems that affect Agile teams and projects.
- Architectural Spikes - рано в проекте - тестируем environment, проверяем proof of concept. Чтоб в будущем не строить продукт на кривой архитектуре. It should always take LESS TIME than a Sprint.
- Burn Rate The rate of resources consumed by the team; also cost per iteration.
- CARVER An acronym to measure the goals and mission of the project with each letter meaning: Criticality, Accessibility, Return, Vulnerability, Effect, and Recognizability.
- Cumulative Flow Diagram A chart that displays feature backlog, work-in-progress, and completed features.
- DEEP The qualities of a product backlog include: detailed, estimate-able, emergent, and prioritized.
- Emergent Stories that grow and change over time as other stories reach completion in the backlog.
- Empiricism - knowledge come from experieence
- Epic - большая User-Story, распределенная на несколько Спринтов
- Feature anttibutes of the product
- Five Whys The root causes analysis technique that asks WHY five times. The problem is looked into deeper each time WHY is asked. Toyota developed this technique.
- Four themes to manage - There are four themes to manage when setting up large agile projects: people, product, project, and process.
- Intrinsic Schedule Flaw Poor estimation occurs at the beginning of the iteration
- Iteration H Iteration used to prepare the launch of software and to test software. Wrapping thins up
- Iteration 0 Iteration to complete tasks before the development work occurs, for technical and architectural spikes, and to gather requirements into the backlog. Например установка системы управления релизами (что тоже должно быть частью Product Backlog). Но НЕ СУЩЕСТВУЕТ ПОНЯТИЯ “Sprint Zero” (как понимать?)
- Lagging metrics - измерение past experience (в отличие от Leading metrics, где мы смотрим в будущее)
- Little’s Law by limiting WIP teams complete work faster (концентрация на минимальном кол-ве задач)
- Low Tech and High Touch Solutions - используется в Agile. Это лучше high-tech сложных решений
- Minimal Marketing Feature (MMF) = MVP
- Scrum of Scrums - для оч больших проектов, daily встреча скрам мастеров
- Post-its - tasks created by breaking down each user story.
- Project tweet (elevator statement) - на проект или итерацию пишется с SH, очень короткое описание, что хотим получить на выходе. Помогает быть involved
- Risk-based spike - fail early, fail often. Проверяем риск , чтоб дальше не натыкаться на это
- Silo Work that is isolated.
- Swarming When the team collaborates to focus on a single user story.
- Two-way Communication: (1) Dispatching model - top down communication (2) Collaborative model - interactive communication between sender and receiver
Agile User Story
Общие принципы
- small chunk of business func, ~1-3 days work (20 hours of work, 24 max). All in the Product Backlog
- Porential stories = candidate
- Format: Given (что делаю), When (action конкретный), Then (result)
- Дополнительно: детали - обсуждаются в conversation. Подтверждение внедрения - на Sprint Review.
Effective user stories follow INVEST:
- Independent
- Negotiable - доступны к обсуждению командой (что-то поменять и пр.)
- Valuable - иметь смысл
- Estimate - доступны к оценке
- Small - 4 to 40 hours of work
- Testable - можно протестировать на соответствие DoD
Three C’s of user stories:
Card, Conversation, Confirmation
Agile Value-Based Analysis
- Assessing and prioritizing the business value of work by subtracting the cost from the benefit.
- Answers how often the item will generate business value.
- Пример: Бенефит: 8000, Косты 5500, Value = 2500
- Анализируем это + возможно что перед внедрением revenue-generating фишек надо внедрить что-то другое
- Value-based decomposition includes requirements elicitation, grouping of like features, breaking down of features, ranking of requirements, and prioritization of requirements into development.
Agile Verification and Validation
Обычные виды тестирования:
- Unit Testing - test of smallest testable portion of app code
- Acceptance Testing - determine acceptability of results: конкретные требования/спека/требования контракта
- Exploratory Testing - тестировщик пробует discover issues and unexpected behavior. Спонтанные эксперименты. Ответственный - тестер, не скрипт. On the fly.
User-Centered Interaction Design
- Usability Testing - (a) как юзер отреагирует under realistic condition? (b) How easy is to use the system, как улучшить
- Hallway testing - показываем рандомным людям попробовать
- Expert review - нанимаем экспертов протестировать
Continuous Integration (System)
Цель:
- Храним и управляем кодом и поставками.
Плюсы:
- Быстрый фитбек, помогает найти конфликт и несовместимый код - в этом польза frequent поставок и синхронизаций.
Минусы:
- долго устанавливать, поэтому делается в Iteration 0, стоимость отдельного сервера
Что делает
- Source code control system - version control
- Build tools - тулы для компилирования
- Test tools
- Scheduler or trigger - builds are launched on a schedule or based on conditions
- Notifications - an email or instant msg reporting on the resulsts of a build
Empirical Processess
Used in Agile
