Статьи про User Stories
1. Как формировать User Stories
2. Подробный гайд по User Stories: критерии INVEST, AC, Job Stories, метод персон, типичные ошибки
3. Декомпозиция User Stories — паттерны, метод гамбургера, SPIDR
#требования
1. Как формировать User Stories
2. Подробный гайд по User Stories: критерии INVEST, AC, Job Stories, метод персон, типичные ошибки
3. Декомпозиция User Stories — паттерны, метод гамбургера, SPIDR
#требования
🔥8🤔1
Карл_Вигерс_и_Джой_Битти_Karl_Wiegers_and_Joy_Beatty_Разработка.pdf
3.1 MB
Библия для Системного аналитика, если у кого её ещё нет. Кому нужно на английском, дайте знать в комментах — найдём
#требования
#требования
🔥11🤔1
Хорошая заметка, которая поможет разобраться в архитектурных стилях, паттернах и принципах проектирования
https://github.com/Max-Starling/Notes/blob/master/Architecture-Design.md
#архитектура #проектирование
https://github.com/Max-Starling/Notes/blob/master/Architecture-Design.md
#архитектура #проектирование
GitHub
Notes/Architecture-Design.md at master · Max-Starling/Notes
My notes about programming and everything related. Contribute to Max-Starling/Notes development by creating an account on GitHub.
🔥6
Бесплатный курс на Stepik Постановка задачи на разработку ПО при поддержке ВК
Курс формирует базовые навыки подготовки и документирования требований к программному обеспечению. По итогам курса вы научитесь: работать с требованиями и заинтересованными сторонами, анализировать проблему и формулировать требования, проектировать взаимодействие пользователей с системой, обеспечивать необходимые качества системы на этапе постановки задачи.
#курсы
Курс формирует базовые навыки подготовки и документирования требований к программному обеспечению. По итогам курса вы научитесь: работать с требованиями и заинтересованными сторонами, анализировать проблему и формулировать требования, проектировать взаимодействие пользователей с системой, обеспечивать необходимые качества системы на этапе постановки задачи.
#курсы
Stepik: online education
Постановка задачи на разработку ПО
Курс формирует базовые навыки подготовки и документирования требований к программному обеспечению. По итогам курса вы научитесь: работать с требованиями и заинтересованными сторонами, анализировать проблему и формулировать требования, проектировать взаимодействие…
🔥4👍3🤔1
Для высоконагруженных систем со множеством клиентов и высокими требованиями к производительности сервера, но неустойчивой сети лучше всего подойдет следующий API межсистемной интеграции
Anonymous Quiz
41%
REST
30%
gRPC
17%
GraphQL
13%
SOAP
👎1
Сколько конечных точек в REST?
Anonymous Quiz
24%
Одна
3%
Нисколько
74%
Сколько угодно: на каждый ресурс своя конечная точка
👎1
GraphQL больше всего похож на
Anonymous Quiz
13%
gRPC
27%
REST
55%
ни на что не похож, это отдельный самостоятельный стиль API
4%
SOAP
👎1
Какие HTTP-методы всегда являются идемпотентными?
Anonymous Quiz
68%
GET, PUT и DELETE (с оговорками)
3%
PATCH
2%
DELETE
12%
только GET
3%
POST
12%
все (GET, POST, PUT, PATCH, DELETE)
👎1
👎1
👎1
Сколько конечных точек в SOAP?
Anonymous Quiz
55%
Одна
8%
Нисколько
37%
Сколько угодно: на каждый ресурс своя конечная точка
👎1
4 шага как «раскопать» систему
1️⃣ Собери всё, что есть
В идеале документацияможет должна содержать:
1. описание потребности в этой функциональности (просто текстом, таблички, какие-то схемы в любой нотации);
2. описание фронта: поведение элементов, workflow пользователя;
3. описание бэка: внутренние сервисы, описание бд и компонентов;
4. описание интеграционных сервисов, включая примеры запросов и ответов, статусы ответов.
5. Требования к функциональности
6. Запротоколированные договоренности, в которых можно проследить какие-то несделанные пожелания
7. Требования регулирующих органов (если влияют напрямую)
8. Руководство пользователя/инструкции
2️⃣ Протыкать ручками (если есть возможность). Просто садишься и начинаешь тыкать везде и смотреть как реагирует система. При этом фиксируешь поведение, а сомнительные моменты отмечаешь для уточнения у носителей неявных знаний
3️⃣ Задай вопросы
Выясняешь у начальника (линейного, руководителя проекта, лида и прочее — нужное подчеркнуть), кто может проконсультировать по вопросам. Готовишь список вопросов. Задаёшь, конспектируешь ответ. Идёшь пропускать все это через себя.
4️⃣ Оформи то, что получил
Оформляешь полученную информацию в установленном порядке в своей фирме. Это может быть актуализация документов, или формирование базы знаний в конфлюенсе, может быть даже обновление родительских тикетов в таск-трекере — в общем удобное для вас место.
Задача аналитика — оставить после себя структурированную информацию. Оставить — это значит оформить и выложить в общедоступное место. А не разобраться, как школьник с новыми знаниями, и оставить их при себе. Структурированная информация — это значит разложить по полочкам все то, что до тебя плохо лежало.
Оригинал
#требования
1️⃣ Собери всё, что есть
В идеале документация
1. описание потребности в этой функциональности (просто текстом, таблички, какие-то схемы в любой нотации);
2. описание фронта: поведение элементов, workflow пользователя;
3. описание бэка: внутренние сервисы, описание бд и компонентов;
4. описание интеграционных сервисов, включая примеры запросов и ответов, статусы ответов.
5. Требования к функциональности
6. Запротоколированные договоренности, в которых можно проследить какие-то несделанные пожелания
7. Требования регулирующих органов (если влияют напрямую)
8. Руководство пользователя/инструкции
2️⃣ Протыкать ручками (если есть возможность). Просто садишься и начинаешь тыкать везде и смотреть как реагирует система. При этом фиксируешь поведение, а сомнительные моменты отмечаешь для уточнения у носителей неявных знаний
3️⃣ Задай вопросы
Выясняешь у начальника (линейного, руководителя проекта, лида и прочее — нужное подчеркнуть), кто может проконсультировать по вопросам. Готовишь список вопросов. Задаёшь, конспектируешь ответ. Идёшь пропускать все это через себя.
4️⃣ Оформи то, что получил
Оформляешь полученную информацию в установленном порядке в своей фирме. Это может быть актуализация документов, или формирование базы знаний в конфлюенсе, может быть даже обновление родительских тикетов в таск-трекере — в общем удобное для вас место.
Задача аналитика — оставить после себя структурированную информацию. Оставить — это значит оформить и выложить в общедоступное место. А не разобраться, как школьник с новыми знаниями, и оставить их при себе. Структурированная информация — это значит разложить по полочкам все то, что до тебя плохо лежало.
Оригинал
#требования
👍7🔥3❤1👎1🤔1
Чек-лист хороших требований
✅ Полнота. Все ли описано? Ничего не забыли? Вдруг у нас остался неописанный функционал или параметр API-метода? Чтобы проверить этот пункт, просто напишите чек-лист проверок функционала. Вот как начали читать ТЗ, сразу записывайте тесты. Важно именно писать, а не просто прикидывать в уме. Иначе что-то обязательно забудете.
✅ Однозначность. Требования должны трактоваться всеми одинаково.
Отчет должен загружаться быстро. Отчет за год должен загружаться не более секунды.
✅ Непротиворечивость. Требования не должны противоречить сами себе
Необходимость. Помните главный принцип: «Кратко, но емко». Пишите только то, что необходимо: функционал, основной сценарий и альтернативы, типы ошибок.
✅ Осуществимость. А можно ли реализовать то, что тут написано? Насколько это будет сложно и дорого?
✅ Тестируемость. Можно ли протестировать этот функционал? Подумайте об этом заранее. А то бывает так, что разработчик уже всё сделал, и тут только тестировщик понимает, что задачу никак нельзя проверить
✅ Атомарность. Не может быть разбито на ряд более детальных требований
Подробнее – см. свойства качественных требований
#требования
✅ Полнота. Все ли описано? Ничего не забыли? Вдруг у нас остался неописанный функционал или параметр API-метода? Чтобы проверить этот пункт, просто напишите чек-лист проверок функционала. Вот как начали читать ТЗ, сразу записывайте тесты. Важно именно писать, а не просто прикидывать в уме. Иначе что-то обязательно забудете.
✅ Однозначность. Требования должны трактоваться всеми одинаково.
✅ Непротиворечивость. Требования не должны противоречить сами себе
Необходимость. Помните главный принцип: «Кратко, но емко». Пишите только то, что необходимо: функционал, основной сценарий и альтернативы, типы ошибок.
✅ Осуществимость. А можно ли реализовать то, что тут написано? Насколько это будет сложно и дорого?
✅ Тестируемость. Можно ли протестировать этот функционал? Подумайте об этом заранее. А то бывает так, что разработчик уже всё сделал, и тут только тестировщик понимает, что задачу никак нельзя проверить
✅ Атомарность. Не может быть разбито на ряд более детальных требований
Подробнее – см. свойства качественных требований
#требования
Telegraph
Свойства качественных требований
В процессе тестирования требований проверяется их соответствие определённому набору свойств. 💡Завершённость (completeness). Требование является полным и законченным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям…
🔥8
Пиши_Сокращай_Как_составлять_сильный_текст.pdf
12.9 MB
Чётко и ясно излагать мысли — один из главных навыков системного аналитика. И этот навык можно прокачать. А помочь в этом может книга от создателей сервиса glvrd.ru «Пиши, сокращай» М. Ильяхова и Л. Сарычевой
👍7🤔1
Открытый курс по документированию API
Позволяет узнать:
1. стандарты, инструменты и спецификации REST API
2. необходимые разделы в документации API
3. как присоединиться к опен-сорс проекту для получения опыта
4. Как использовать Postman и составлять запросы curl
5. как составлять спецификацию OpenAPI и Swagger
#интеграции #api
Позволяет узнать:
1. стандарты, инструменты и спецификации REST API
2. необходимые разделы в документации API
3. как присоединиться к опен-сорс проекту для получения опыта
4. Как использовать Postman и составлять запросы curl
5. как составлять спецификацию OpenAPI и Swagger
#интеграции #api
👍9❤1🤔1
Как выбрать технологию для интеграции, реализовать и не сойти с ума — доклад с Analyst Days 15
Анастасии Воробьевой, интеграционного аналитика из Райфа
#интеграции #api #архитектура
Анастасии Воробьевой, интеграционного аналитика из Райфа
#интеграции #api #архитектура
analystdays.ru
Как выбрать технологию для интеграции и не ошибиться?
Наверняка многие из вас сталкивались с ситуацией, когда нужно связать свою систему с другой удаленной системой, чтобы получить данные, необходимые для ваших процессов, например, данные о клиенте, или чтобы инициировать бизнес-процесс в другой системе, например…
🔥6