#собеседование #вопросы #статья

Автор статьи "Как подготовиться к собеседованию на позицию системного аналитика. ТОП-5 тем", опираясь на личный опыт, выделяет 5 основных тем с примерными вопросами, которым стоит уделить внимание при подготовке к собеседованию:
1. Требования к ПО
2. Процесс разработки ПО
3. Документация к системе
4. Проектирование решения
5. Интеграция

И приводит ссылки на ресурсы для изучения данных тем.

Заметки Аналитика | @notes_analyst

​​Agile-подходы гибкой разработки ПО: Scrum и Kanban.
#agile #scrum #kanban 

Суть  Agile описана в Agile-манифесте, в котором на первое место выходят:  взаимодействие, работающий продукт, сотрудничество с заказчиком и готовность к изменениям.
Подробнее:"Ценности и принципы Agile-манифеста"

К отдельным Аgile-подходам (методологиям) относятся Scrum и Kanban. 
Данные подходы гибкой разработки ориентированы на итеративный и инкрементальный процесс программирования, в котором:
 ° разработка ПО разбивается на короткие циклы - итерации (в Scrum - спринты);
 ° формируется автономная и самоорганизующаяся команда;
 ° клиенты или представляющий их владелец продукта участвуют на всех стадиях проекта;
 ° требования могут документироваться менее подробно, чем в традиционных проектах;
 ° формируется Резерв  (backlog) проекта, содержащий список задач, которые должна выполнить команда;
 °  каждая задача должна быть актуальна (разрешается добавлять/удалять задачи), иметь вес (время, которое необходимо на её реализацию) и приоритет (может пересматриваться в ходе работы);
 ° для визуализации  данных подходов используют доски: физические или электронные, которые позволяют сделать рабочий процесс открытым и понятным для всех специалистов.

Особенности и принципы Scrum:
 ° над каждым проектом работает универсальная команда специалистов;
 ° выделяют спец.роли: Владелец продукта и Scrum-мастер;
 ° время работы делят на Спринты - одинаковые по длительности отрезки времени (напр.  2 недели);
 ° перед спринтом формируются задачи на данный спринт, в конце – обсуждаются и презентуются  результаты: выполненные задачи заливаются на продакшн, а невыполненные — переносятся в другой спринт;
 ° число задач в работе ограничивается их общим весом;
 ° приоритеты задач расставляет Владелец продукта;
 ° нельзя добавлять задачи в текущий спринт (новая важная и срочная задача -  только со следующего спринта);
° основная цель - закончить спринт;
° проведение ежедневных встреч для оценки результатов проделанной работы - основа процесса разработки.

Особенности и принципы Kanban:
 ° над задачей может работать несколько узкопрофильных команд (дизайнеры, аналитики, разработчики…);
 ° внутри команды нет выделенных ролей;
 ° проект делят на итерации, длина которых может различаться;
 ° рабочие задачи располагаются на доске, поделенной на колонки, каждая из которых отражает текущее состояние работ (стадии) - например: «Планируется», «Разрабатывается», «Тестируется», «Завершено»; 
° каждая задача представляется в виде отдельной карточки;
° основная цель - закончить задачу, т.е. пройти все стадии выполнения (когда задача завершает определённый этап, карточку с её описанием переносят в соответствующую колонку);
° над задачей трудятся столько времени, сколько это необходимо до её завершения или утраты актуальности и отмены;
° главный показатель эффективности -
среднее время прохождения задачи по доске;
° приоритеты задач расставляет команда;
° добавление новых задач - в любое время;
° проводить ежедневные встречи не обязательно.

---------
Подробнее о принципах работы по Scrum  и Kanban можно прочитать в статьях:
° Scrum
° Kanban: принципы и возможности в управлении проектами
° Разбираемся в Scrum и Kanban

Заметки Аналитика | @notes_analyst

​​"Разработка требований к программному обеспечению". Карл Вигерс и Джой Битти
#литература

"Эта книга — подробное руководство по разработке качественных требований к программному обеспечению. Здесь описаны десятки проверенных на практике приемов выявления, формулирования, разработки, проверки, утверждения и тестирования требований, которые помогут разработчикам, менеджерам и маркетологам создать эффективное ПО"

Найти электронную версию можно тут (2014г.)

Обзоры на книгу:
° Рецензия на книгу «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти

° Стоит прочитать: обзор книги Карла Вигерса «Разработка требований к программному обеспечению»


Заметки Аналитика | @notes_analyst

​​Варианты использования (Use Case).  Элементы структуры и примеры составления.
#usecase #работастребованиями #теория

Вариант использования/Use Case - описывает последовательность взаимодействия системы и внешнего действующего лица, в результате которого действующее лицо получает полезный результат.

На основе Вариантов использования аналитики могут сформулировать функциональные требования, а тестировщики - составить тесты. 
Варианты использования проще согласовывать, т.к. каждый Use Case несет конечную бизнес-ценность, понятную заказчику.

Вариант использования должен:
✔описывать, что именно система должна сделать, чтобы действующее лицо достигло своей цели;
✔иметь достаточный уровень детализации;
✔не затрагивать деталей реализации;
✔не описывать пользовательские интерфейсы и экраны. 

Единого формата (шаблона) составления Вариантов использования не существует. Чаще их представляют в текстовой форме, дополняя диаграммами/схемами.

Основными элементами структуры Варианта использования являются:

🔹️Имя - пишется в формате «глагол + объект», отражает цель и смысл сценария ( Зарегистрироваться на рейс, Снять деньги в банкомате).

🔹️Цель - короткое описание того, чего  намеревается достигнуть действующее лицо с этим сценарием

🔹️Актор (actor) - действующее лицо (человек/другая программная система/аппаратное устройство), взаимодействующее с системой для реализации Варианта использования.

🔹️Предусловия  - условия, которые должны быть удовлетворены до начала выполнения Варианта использования.

🔹️Активатор (триггер) – внешнее, внутреннее или временное событие, инициирующее выполнение Варианта использования.

🔹️Выходные условия (результат, постусловие) - описывают состояние системы после успешного выполнения Варианта использования. 

🔹️Порядок Событий (основной поток/сценарий) — пронумерованный список действий, иллюстрирующий последовательность этапов взаимодействия действующего лица и системы (диалогов) от предварительных до выходных условий.

🔹️Альтернативные пути (альтернативный поток/вторичный сценарий) - описание действий , которые тоже приводят к успешному результату  и удовлетворяют выходным условиям Варианта использования, но представляют менее популярные или менее приоритетные вариации самой задачи или способа ее выполнения. 

🔹️Исключения - условия, препятствующие успешному выполнению Варианта использования. Описывают ожидаемое ошибочное условие, которое может сложиться во время выполнения варианта использования, и как его обрабатывать.

🔹️Бизнес-правила - которые, наприпер, могут влиять на отдельные шаги нормального направления, задавая разрешенные входные значения или диктуя, какие вычисления должны выполняться.

То, какие элементы будет содержать ваш Вариант использования, зависит от сложности и необходимого уровня детализации конкретной задачи.

Для наглядности собрали несколько примеров готовых Use Case и варианты Шаблонов, различных по содержанию и дизайну.

------
Заметки Аналитика | @notes_analyst

​​Как подготовиться к собеседованию бизнес-/системному аналитику.
#подборка #собеседование

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

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

Вместе с кналом @analysis_it сделали небольшую подборку статей, авторы которых приводят примеры вопросов, встречающихся на собеседованиях, и рекомендации по ответам на них.

🔹 50 лучших вопросов из интервью для бизнес-аналитиков

🔹 Прохождение собеседования на позицию бизнес-аналитика

🔹 Как пройти техническое собеседование на системного аналитика в любой компании (сборник вопросов)

🔹 Как подготовиться к собеседованию на позицию системного аналитика. ТОП-5 тем

🔹 Что мы хотим от аналитика

🔹 Типовые вопросы на собеседовании на аналитика и ответы на них

🔹 «Кем вы видите себя через 5 лет»...

🔹 Бизнес-аналитик идет на собеседование

На сегодняшний день нет чётких границ в разделении обязанностей между бизнес- и системным аналитиком. В одних компаниях это могут быть два разных специалиста, в других - один.

Немного подробнее о задачах и обязанностях бизнес- и системных аналитиков можно прочитать тут и тут

Следите за новыми постами на каналах @analysis_it и @notes_analyst, где сможете найти ответы на многие вопросы из представленных статей ⬆️

Давайте готовиться к собеседованиям вместе!

Project-менеджер в IT - один из немногих каналов для начинающих проджектов в телеграм. Если вы хотите развиваться в сторону менеджмента в IT — подписывайтесь!

​​Диаграммы прецедентов (вариантов использования).
#usecase #диаграмма #теория

Диаграммы вариантов использования (use-case diagrams) позволяют получить высокоуровневое визуальное представление о требованиях пользователей.
Их чаще применяют в качестве дополнения к более описательным текстовым Вариантам использования.

При помощи use-case диаграммы можно:
▪︎ продемонстрировать различные способы взаимодействия пользователя с системой;
▪︎ визуально представить логическое развитие сложного варианта использования;
▪︎ описать общую функциональность системы;
▪︎ определить общие границы и контекст моделируемой предметной области;   
 ▪︎ разработать исходную концептуальную модель системы;
 ▪︎ подготовить исходную документацию. 

Основными элементами use-case диаграммы являются:
 🔹 Актеры (акторы) - группы лиц или систем, взаимодействующие с описываемой системой;
🔹 Варианты использования (прецеденты) - функции, которые система предоставляет актерам;
🔹 Комментарии;
🔹 Отношения между элементами диаграммы - отношения ассоциации, обобщения, включения, расширения.

Графические обозначения и определения данных элементов привела в таблице Основные элементы Use-case диаграммы

Строить диаграмму прецедентов можно в следующей последовательности:
1.Выделите группы действующих лиц
2. Определите функциональность для каждой из групп (варианты использования/прецеденты)
3. Дополните прецеденты словесным описанием (сценарием) - для каждого прецедента создайте разделы: "основной поток" и " "альтернативный"
4. Проведите анализ связей (отношений)
5. Перенесети собранные данные в графический формат - постройте use-case диаграмму.

При построении диаграммы помните, что use-case диаграмма должна выражать лишь требования к системе, а не детали ее реализации.
Отображайте на диаграмме только ключевые моменты, не делите процессы слишком мелко.

Ещё больше рекомендаций и примеров построения use-case диаграмм можете найти в статьях:
 ° Правила и рекомендации по разработке диаграмм прецедентов
 
° Использование диаграммы вариантов использования UML при проектировании программного обеспечения

Заметки Аналитика | @notes_analyst

​​Алистер Коберн. Современные методы описания функциональных требований к системам.
#работастребованиями #литература

Книга для тех, кто хочет улучшить свои знания и навыки в работе с Вариантами использования.

"Данная книга эксперта по объектной технологии Алистера Коберна служит новейшим практическим руководством по написанию вариантов использования. Богатый опыт в этой области помогает автору расширить классическое толкование вариантов использования. В книге представлены начальная, промежуточная и развитая концепции, поэтому она подходит читателям с разным уровнем подготовки. Инструкции подкреплены наглядными примерами и упражнениями."

Электронную версию можно найти тут

Аналитика данных - одно из IT направлений, которое развивается высокими темпами и имеет огромный потенциал развития в будущем. Компании и различные бизнесы повсеместно используют данные для получения бизнес-ценности и оптимизации своих процессов.

В рамках своего канала @data_study Даниил делится знаниями и теоретическими навыками работы аналитиком:
- работа с базами данных
- хранилища данных, озера данных
- управление данными, качество данных
- обработка данных
- SQL, Python
- бизнес-анализ
- визуализация данных
- soft-навыки аналитика

Канал будет интересен как новичкам в аналитике, так и специалистам, желающим повысить свои навыки работы с данными.
https://t.me/data_study
@daniildzheparov

Шпаргалка по основам SQL

Скачать в формате pdf

#sql | @notes_analyst

​​📑 Нормализация баз данных. 1, 2 и 3 нормальные формы.

Нормализация – метод проектирования базы данных, который позволяет привести базу данных к минимальной избыточности, обезопасив её от логических и структурных проблем, называемых аномалиями данных. 

Данный метод дает следующие преимущества:
▪︎ упрощает процесс выборки;
▪︎ обеспечивает целостность данных;
▪︎ улучшает масштабируемость;
▪︎ минимизирует избыточность данных;
▪︎ предотвращает потери информации.

Устранение избыточности происходит за счёт декомпозии отношений (когда одна таблица разбивается на несколько).

Существует несколько правил нормализации баз данных, каждое из которых называется «Нормальной формой». 
Применение данных правил осуществляется итерационно, последовательно переходя от одной нормальной формы, к другой.
Для большинства приложений достаточно нормализовать базы данных до третьей нормальной формы:

🔹️ Первая нормальная форма (1NF) - предполагает, что сохраняемые данные на пересечении строк и столбцов должны представлять скалярное значение, а таблицы не должны содержать повторяющихся строк.

🔹️ Вторая нормальная форма (2NF) - предполагает, что каждый столбец, не являющийся ключом, должен зависеть от первичного ключа.

🔹️ Третья нормальная форма (3NF) - предполагает отсутствие в таблицах транзитивной зависимости (когда один неключевой столбец связан с первичным ключом через другой неключевой столбец)

Полный перечень нормальных форм и требования к ним приводятся тут

#БазыДанных | @notes_analyst

📑 Jira. Знакомство с инструментом.

Jira - это программный инструмент с открытым исходным кодом, используемый для управления проектами, задачами и отслеживания ошибок, который:
 ▪︎ позволяет создавать карту проекта,  контролировать ход выполнения задач,
управлять загрузкой исполнителей, 
выделять "узкие" места в проектах и важные задачи;
 ▪︎ имеет ряд необходимых стандартных отчетов;
 ▪︎ использует настраиваемые доски Scrum и Kanban;
 ▪︎ имеет возможности конфигурирования, интеграции и расширения функций.

Статья: Jira - как вводная часть для тех, кто только начинает свое знакомство с данным инструментом.

Содержание статьи:
 ° Agile-разработка с Jira
  ° Для чего используют Jira
 ° Как пользоваться Jira
  ° Интерфейс
  ° Создание первого проекта
  ° Создание задачи
 ° Повышение производительности
 ° Аналоги.

#инструменты | @notes_analyst

​​Мини-курс "Введение в API".Брайан Кукси
(перевод под редакцией Артема Стукалова и Дениса Бескова)

Содержание:
 ▪︎ Глава 1: Введение
 ▪︎ Глава 2: Протоколы
 ▪︎ Глава 3: Форматы данных
 ▪︎ Глава 4: Аутентификация, часть 1
 ▪︎ Глава 5: Аутентификация,  часть 2
 ▪︎ Глава 6: Проектирование API
 ▪︎ Глава 7: Связь в реальном времени
 ▪︎ Глава 8: Реализация

Скачать оригинал в формате PDF

#API | @notes_analyst

Шпаргалка по SQL - JOINs

Скачать в формате pdf

#sql | @notes_analyst

​​📑 Как правильно писать User Stories

User stories (пользовательские истории) представляют исходные требования от заказчика о целях пользователей в общем виде.
Каждая Пользовательская История – это повод к обсуждению, а не конечное требование к системе.

Для написания Пользовательских историй часто используют шаблон:

Как <тип пользователя>, я хочу <цель>, чтобы <причина>.

Авторы статьи на примере разбирают возможные ошибки при написании User stories и способы их исправления.

Перейти к статье

#работастребованиями | @notes_analyst

​​📑 Частые ошибки бизнес-/системного аналитика

Виктор Дмитриев - практикующий бизнес-/системный аналитик с опытом управления командой / глубокого бизнес-анализа / запуска Web и Mobile проектов, подготовил список ошибок , которые часто допускают бизнес-/системные аналитики в своей ежедневной работе, и даёт рекомендации, как их не допустить:

Статья 1:
▪︎ Ошибка 1. Принимаем требования заказчика без уточнения его реальных потребностей
▪︎ Ошибка 2. Создали и продолжаем поддерживать систему-франкенштейн
▪︎ Ошибка 3. Забыли обработать исторические данные
▪︎ Ошибка 4. Принимаем слова руководителей за «чистую монету»

Статья 2:
▪︎ Ошибка 5. Забыли получить согласование ТЗ
▪︎ Ошибка 6. Не привлекаете дизайнера на интервью заказчика
▪︎ Ошибка 7. В процессе сбора требований вы общаетесь не с тем человеком
▪︎ Ошибка 8. Не фиксируете все договоренности в заметках встреч

#статья | @notes_analyst

​​📚 Путь аналитика. Практическое руководство IT-специалиста. А.Перерва, В. Иванова

"Как воплотить неясные ожидания заказчика в блестящий и прибыльный проект? Как избежать ошибок на начальном этапе? Как стать эффективным аналитиком? Авторы отвечают на эти вопросы и делятся своими ноу-хау, которые позволят вам стать гуру в разработке программного обеспечения. Главное достоинство книги — ее практическая направленность. В ней собрана полезная информация со ссылками на теоретические материалы из разных областей разработки программного обеспечения: анализа, архитектуры, управления проектами, лидерства и управления персоналом — все, что понадобится в реальных производственных проектах.."

Прочитать об авторах, о том, для кого предназначена данная книга и что вы в ней найдёте, а чего нет - можно тут

Скачать 📗

#литература | @notes_analyst

Шпаргалка по оконным функциям SQL

Скачать в формате pdf

#sql | @notes_analyst

​​📑 REST, что же ты такое? Понятное введение в технологию для ИТ-аналитиков.

- Какие принципы вложил в парадигму REST её автор и как они могут помочь при проектировании систем?

- Почему существует терминологическая путаница вокруг REST?

- Как связаны HTTP и REST?

- Почему REST противопоставляют SOAP?..

Ответы на эти и другие вопросы, касающиеся REST , можете найти в видео Андрея Буракова или  в статье, составленной по его вебинару.

#rest | @notes_analyst