# Qualified

• Software development process

  • Software development activities

• Basics of SDLC models

  • Waterfall Concept
  • Agile software development concept

• Scrum

  • Roles and responsibilities
  • Artifacts (Scrum board, Cards, Epics, Stories, Tasks, Backlogs, Sprint, Increment, etc.)
  • Estimation (Story Points, Velocity, Sprint Burndown Chart, Feature Burnup Chart)
  • Ceremonies (Release planning, Sprint planning, Daily Scrum, Sprint demo, Sprint retrospective)

• Kanban

---

# Software development process

Most modern development processes can be vaguely described as agile. Other methodologies include waterfall, prototyping*, iterative and incremental development, spiral development, rapid application development, and extreme programming.

# Software development activities

1. Planning: Without the perfect plan, calculating the strengths and weaknesses of the project, development of software is meaningless. Planning kicks off a project flawlessly and affects its progress positively.

2. Analysis: This step is about analyzing the performance of the software at various stages and making notes on additional requirements. Analysis is very important to proceed further to the next step.

3. Design: Once the analysis is complete, the step of designing takes over, which is basically building the architecture of the project. This step helps remove possible flaws by setting a standard and attempting to stick to it.

4. Development & Implementation: The actual task of developing the software starts here with data recording going on in the background. Once the software is developed, the stage of implementation comes in where the product goes through a pilot study to see if it’s functioning properly.

5. Testing: The testing stage assesses the software for errors and documents bugs if there are any.

6. Maintenance: Once the software passes through all the stages without any issues, it is to undergo a maintenance process wherein it will be maintained and upgraded from time to time to adapt to changes. Almost every software development Indian company follows all the six steps, leading to the reputation that the country enjoys in the software market today.

---

# Basics of SDLC models

# Waterfall Concept

In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.

The Waterfall model is the earliest SDLC approach that was used for software development.

The waterfall Model illustrates the software development process in a linear sequential flow. This means that any phase in the development process begins only if the previous phase is complete. In this waterfall model, the phases do not overlap.

In "The Waterfall" approach, the whole process of software development is divided into separate phases. In this Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially.

The sequential phases in Waterfall model:

Requirement Gathering and analysis − All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification document.

System Design − The requirement specifications from first phase are studied in this phase and the system design is prepared. This system design helps in specifying hardware and system requirements and helps in defining the overall system architecture.

Implementation − With inputs from the system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality, which is referred to as Unit Testing.

Integration and Testing − All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures.

Deployment of system − Once the functional and non-functional testing is done; the product is deployed in the customer environment or released into the market.

Maintenance − There are some issues which come up in the client environment. To fix those issues, patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.

All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like a waterfall) through the phases. The next phase is started only after the defined set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model". In this model, phases do not overlap.

Advantages:

• Simple and easy to understand and use
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Process and results are well documented.

Disadvantages:

• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is high with this process model.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or business bottleneck or challenges early.

# Agile software development concept

Examples: Feature-driven development, Extreme Programming,

Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с управлением ими комбинированным (либеральным и демократическим) методом.

Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.

Agile manifesto

• люди и взаимодействие важнее процессов и инструментов
• работающий продукт важнее исчерпывающей документации
• сотрудничество с заказчиком важнее согласования условий контракта
• готовность к изменениям важнее следования первоначальному плану

---

# Scrum

Scrum - это agile framework

«Скрам — это фреймворк управления, согласно которому одна или несколько кроссфункциональных самоорганизованных команд создают продукт инкрементами, то есть поэтапно. В команде может быть около семи человек».

«В Скраме есть система ролей, встреч, правил и артефактов. В этой модели за создание и адаптацию рабочих процессов отвечают команды».

«В Скраме используются итерации фиксированной длины, называемые Спринтами. Они обычно занимают 1-2 недели (до 1 месяца). Скрам команды стремятся создавать готовый к поставке (качественно протестированный) Инкремент продукта в каждой итерации».

# Roles and responsibilities

• Product owner
• Scrum master
• Команда разработки (Development team)

Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды.

Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).

Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO

Development team состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:

• Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде каким преобразовать Product Backlog в работающий продукт
• Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта
• За выполняемую работу отвечает вся команда, а не индивидуальные члены команды

# Artifacts

• Scrum board

  ToDo	In progress	In review	In test	Done

• Cards

  

• Epics

  Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories).

  Эпик — это большая история. Это требование, слишком большое чтобы реализовать его за один спринт. Эпики нужно разбивать на более мелкие работы (истории). Благодаря этому эпики вписываются в принципы agile (регулярная отгрузка софта, готового к выпуску, постоянная готовность к запуску на ранних этапах, регулярная ретроспектива).

  Пример эпика: “Как клиент, я хочу иметь возможность добавить товары в список желаний, чтобы можно было вернуться и купить их позже”.

• Stories

  Stories, also called “user stories,” are short requirements or requests written from the perspective of an end user.

• Tasks

  Story разделяются на мелкие таски, могут именоваться с приставкой (BE: - backend, FE: - frontend, QA: - tests)

• Backlogs

  Sprint backlog содержит функциональность, выбранную владельцем проекта из резерва проекта для реализации в данном спринте. Все функции разбиты по задачам. Каждый день команда разработчиков оценивает объем работы, оставшейся для завершения спринта.

  Product Backlog – это список требований к функциональности продукта (ПО), упорядоченный по степени важности и редактируемый всеми участниками скрам-процесса.

• Sprint

  в течении Sprint выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении все жизни продукта.

  Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog

• Increment

  ощутимый результат работы одного спринта. Например, внедрение новой функции на сайт, прототип мобильного приложения. Команда должна показать целевой аудитории, что она сделала за это время. Это нужно для получения обратной связи и планирования следующих задач по улучшению продукта.

---

# Estimation

• Story Points

  Для максимально эффективного и быстрого внедрения Story Points в жизнь команды нужно взять уже отработанные задачи с прошлых проектов и провести их полный анализ. В данный анализ должны входить названия задач, которые выполнялись, и их продолжительность. Дальше всё проще простого: необходимо расположить эти задачи в порядке возрастания, отсортировав по времени. Разделить на группы с одинаковыми или близкими показателями и проставить оценки из вашей колоды карт Scrum Poker.

• Velocity

  Скорость команды – количество очков, набранных командой за предыдущий спринт. Помогает команде понять, сколько она может сделать за спринт.

• Sprint Burndown Chart

  Диаграмма сгорания задач (Burndown Chart) – это общедоступный график (для спринта и выпуска продукта), показывающий, сколько задач выполнено и сколько осталось.

• Feature Burnup Chart

  Диаграмма сгорания задач — диаграмма, показывающая количество сделанной и оставшейся работы. Является частью фреймворка Scrum.

  Обновляется ежедневно с тем, чтобы в простой форме показать подвижки в работе над спринтом. График должен быть общедоступен.

  Существуют разные виды диаграммы:

  • диаграмма сгорания работ для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать в текущем спринте.
  • диаграмма сгорания работ для выпуска проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов).

---

# Ceremonies

• Release planning - то же что и Sprint planning, только релиз состоит из нескольких спринтов

• Sprint planning

  Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog

• Daily Scrum

  Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint'а.

• Sprint demo

  Демо, где заказчику (или команде, или тестировщикам) презентуется проделанная за спринт работа

• Sprint retrospective

  Собрание после завершения спринта. «Вся команда, скрам-мастер и владелец продукта обсуждают, что было сделано на «отлично», а что пошло не так, и что нужно сделать для того, чтобы в следующий раз быть успешнее.

---

# Kanban

• Приоритет главным задачам

  • Blockers — задачи и баги, которые надо править в режиме реального времени. Пример – сломанная регистрация.
  • Tasks and Bugs – обычные текущие задачи и баги.
  • Someday — задачи, которые потеряли актуальность по той или иной причине.

• Концентрация на работе

• Гибкость

• Не нужно оценивать фичи

• Концентрация на одной задаче