Материалы по теме «документация»

RSS

Аудит і оцінювання. Вдосконалюємо процес тестування Аудит і оцінювання. Вдосконалюємо процес тестування

Ramella Basenko 3869

Стаття буде цікавою тим, хто вже замислювався про аудит процесів на проєкті, хто вже почав збирати метрики або тільки збирається це зробити — QA Manager, QA Lead, PM та навіть executive persons. У статті розглянемо, чим відрізняється аудит від оцінювання, а також для чого і як часто проводити аудит. 4

Як створювати та оформлювати технічну документацію в IT: рекомендації для початківців і підказки для досвідчених Як створювати та оформлювати технічну документацію в IT: рекомендації для початківців і підказки для досвідчених

Iryna Isay 9337

Ця стаття стане в пригоді як початківцям — людям, які щойно прийшли у професію і хочуть розібратися, з чого починати та яких помилок уникнути, — так і техрайтерам, які вже встигли попрацювати та набити ґуль і яким мій досвід може стати натхненням для пошуку нових рішень у створенні документації. 14

Новое как старое. Как провести успешный User Acceptance Testing для Reverse Engineering проекта Новое как старое. Как провести успешный User Acceptance Testing для Reverse Engineering проекта

Anastasiia Serdiuk 2671

Проекты, требования к которым не предоставляются пользователями, а добываются из существующего кода — достаточно новый тип проектов. Но их актуальность только растет. В статье поговорим о Reverse Engineering, у которого есть свои законы и особенности. 10

Аудит технічної документації: кому, навіщо, як Аудит технічної документації: кому, навіщо, як

Iryna Isay 3049

Добре описана документація значно полегшує життя всім залученим у створення та підтримання продукту сторонам. Ісай Ірина, техрайтерка, ділиться своїм досвідом аудиту технічної та підготовки продуктової документації одночасно для кількох проєктів компанії. 4

User Flows. Як ця техніка допомагає в роботі над проєктами User Flows. Як ця техніка допомагає в роботі над проєктами

Bohdana Muzyka 6097

Богдана Музика розвиває напрям бізнес-аналізу в компанії TechMagic і в цій статті ділиться власним досвідом застосування такої техніки, як User Flows, на різних етапах існування проєкту. Читати варто всім, хто працює з виявленням та документуванням вимог, дизайном, розробкою та тестуванням продукту і хоче навчитись краще розуміти його. 5

Як порозумітися бекендеру і фронтендеру, обираючи архітектуру Як порозумітися бекендеру і фронтендеру, обираючи архітектуру

Hasanenko Denis 6978

Ефективна комунікація та взаємодія є ключовим елементом успішності проєкту. У цьому матеріалі автор концентрується на технічній комунікації між бекенд- та фронтенд-розробниками, огляді архітектур, їхньому застосуванні для розв’язання різних питань і, головне, на підходах та інструментах з документування інтерфейсів. 23

Тест-план не для галочки, или 8 вопросов к заказчику на старте проекта Тест-план не для галочки, или 8 вопросов к заказчику на старте проекта

Yuriy Babay 16776

Практически на всех проектах, где работал Software Testing Team Leader Юрий Бабай, был тест-план. Этот документ колоссально облегчал жизнь тестировщиков и делал ценность их работы для заказчика очевидной. Но есть одна деталь. Чтобы тест-план работал в интересах команды, надо составлять его с умом и задавая правильные вопросы клиенту. В этом материале поговорим о создании качественного тест-плана. 7

Навіщо і як QA писати тестову документацію. Структуруємо та робимо її зрозумілою Навіщо і як QA писати тестову документацію. Структуруємо та робимо її зрозумілою

Dmytro Kravchuk 10391

Часто тестування вважають одним із «входів» в IT-професію. Почасти це правда, але цей напрям потребує не менш системного та методичного підходу, ніж, скажімо, розробка. Дмитро Кравчук, QA Engineer в iDeals, зібрав, систематизував інформацію щодо створення тестової документації та ділиться нею. Це має стати в пригоді як QA-початківцям, так і більш досвідченим спеціалістам, які прагнуть впорядкувати свою роботу чи функціонування команди. 13

Навіщо дотримуватися документування на проєкті і хто це повинен контролювати Навіщо дотримуватися документування на проєкті і хто це повинен контролювати

Inna Kozak 6962

У статті поговоримо про документування ІТ-проєктів на різних стадіях життєвого циклу: навіщо взагалі документувати, яка від цього користь, хто має вести документацію та скільки це може коштувати проєкту. Інна Козак ділиться спостереженнями, які виникли під час роботи над різними проєктами на різних позиціях: тестувальника та менеджера. А також розповість, як це — працювати без документації взагалі. Стаття спрямована на менеджерів і тестувальників. 30

Что делать, если на вас падает Due Diligence Audit. Опыт РМ’а Что делать, если на вас падает Due Diligence Audit. Опыт РМ’а

Kostiantyn Bolotin 3298

Константин Болотин, Project Manager, рассказывает о прохождении Due Diligence Audit. Он зачастую проводится перед продажей, привлечением инвестиций, поглощениями или выходом компании на IPO и призван помочь точнее оценить, как обстоят дела в ней на самом деле. Для этого нанимают независимых экспертов в доменной области либо технологии, которые изучают продукт вдоль и поперек и дают свою оценку. В статье вы найдете рекомендации, которые помогут справиться с подобной задачей. 4

Комментарии

Далеко не всім, і далеко не все ця стипендія покриває. Хіба що ви маєте інший досвід. Тоді поділіться.
it’s interesting, thank you!
А пишет он какой-то базовый фундамент приложения по типу разбиения на слои как заложено в Clean architecture, к примеру? Вот тут скорее всего другой уже архитектор выполняет работу.
Солюшн архитектор решает будет ли монолит или микросервисы? Так. І що це змінює?
Для меня архитектор как бы «неправильный» который не спроектирует системный дизайн, где можно садиться сразу и писать код (точнее решать уже бизнес-требования). Солюшн архитектор решает будет ли монолит или микросервисы?
Причем тут украинский язык вообще??
К тому же я знаю, что ты из EPAM. Вау! І як же вам відкрились такі потаємні знання? Невже ви спромоглись клікнути на профіль, а потім ще й на посилання на лінкедін? Аплодую!
Ты тоже ведёшь к тому, что я ничего не понимаю) (Мета не розвести срач, а зрозуміти базові визначення, щоб розмовляти про одне й те саме) Іноді я навіть хочу вірити, що на доу так багато людей, які просто не знають українську мову, але «не варто пояснювати...
так, варто було дати їм завдання з системного дизайну і в кінці показати, що вийшло у кожного
К тому же я знаю, что ты из EPAM. А в меня только от названия уже тошнить начинает. Поэтому, закрыли тему.
Ты тоже ведёшь к тому, что я ничего не понимаю) я не хочу поднимать тут дискуссию, был уже такой тред.
Примечательно, что из трёх человек как раз System Architect и нет, взяли представителей галер, а в более мелких компаниях есть CTO/System Architect в основном. 1) В чому для вас різниця або краще дайте визначення System, Software та Solutions Architect?
Я и хотел ответить на это) просто я думал кто-то скажет, что Айяйяй ты не знаешь кто такие Solution Architect, тебе не понять.
Ліл, точно те, що я написав нижче :-D
забыли добавить, что в той же Sigma Software стартовый набор дают не всем, а как-то выборочно. Я к примеру за год работы здесь так ничего и не получил, хотя постоянно обещали, что-то прислать))