Одна з наших переваг - ми Не є "євангелістами 1С:Підприємство", і пропонуємо бізнесу цей продукт в разі оптимальності рішення в конкретних умовах замовника і для тих завдань, де 1С:Підприємство дійсно зараз справляється краще всього. Ми розробляємо для наших клієнтів IT-рішення з урахуванням переваг кожної з платформ щодо конкретної розв'язуваної задачі (готові або розробку з нуля, залежно від умов проекту). Платформи, які ми в основному використовуємо: Node.JS, .NET, 1С:Підприємство.
У нас великий досвід розробки і впровадження систем класу ERP, CRM, ECM і ін. Ми використовуємо цей досвід для створення SaaS-сервісів та Web-додатків, що вирішують реальні бізнес-завдання.
Сьогодні для реалізації проектів ми використовуємо Agile / Scram методологію. При цьому в деяких випадках це може бути гібридна модель - при необхідності використовуються переваги елементів каскадної методики Waterfall. Якщо стисло:
На етапі узгодження цілей і функціонального обсягу проекту ми окреслюємо межі проекту, щодо яких і робимо припущення про його бюджет. У каскадних проектах цей етап зазвичай називають функціональними вимогами або технічним завданням. Далі ведеться ітераційна розробка продукту, ви зможете контролювати результат кожні 2 тижні. Важливим етапом в реалізації проектів на базі 1С:Підприємство є їх впровадження (досвідчена і промислова експлуатація) і подальший супровід.
Давайте спробуємо дати деякі пояснення до даних термінів крізь призму звичних термінів і 1С:Підприємство понять.
Власник продукту - 1 людина зі сторони замовника. Отримує вимоги до системи від функціональних керівників, збирає свою команду всередині компанії і разом визначають загальний список вимог до проекту і їх важливість. Отримує завдання з проставленою оцінкою трудовитрат від скрам-команди і разом зі своєю внутрішньою командою визначає чиї і які завдання увійдуть в наступну версію. Обговорює деталі і поточні питання від Скрам-команди (з власниками процесу) при реалізації поточної версії.
Скрам майстер Менеджер проекту - може бути як співробітником відділу продажів, так і одним з учасників команди. Проводить комунікацію з Власником продукту (по телефону, скайпу, ел. поштою тощо). Організовує зустрічі Скрам-команди і Власника продукту. Стежить за регламентом ведення зборів (місце, час, план, підсумок). Координує роботу команди (призначає збори, стежить за часом). Організовує ретроспективу і демонстрацію версії.
Скрам-команда - збирається вперше, коли ініційовано процес (підписано договір). Учасники команди можуть бути залучені паралельно не більше ніж в 2 проекти. В команду входять розробники і аналітик / і.
Беклог продукту - це список вимог до продукту, в ньому повинні бути зафіксовані вимоги користувача (перелік того, що хоче отримати Власник продукту, формулювання вимог повинне бути зрозумілим для Власника продукту), їх важливість (визначає Власник продукту, при необхідності спільно аналітиком).
Беклог спринту - всі вимоги з беклогу продукту розбиваються на завдання для реалізації.
Спринт - в інший, більш звичної, інтерпетаціі можна назвати це релізом або версією, це готове ПО з частково реалізованими вимогами з беклогу продукту.
Складання списку вимог до продукту - в період інтерв'ювання клієнта (з Власником продукту, власниками процесів) за вимогами до продукту вся Скрам-команда не збирається, тільки Аналітик. Вимога замовника - мінімально завершена вимога з точки зору клієнта, що формулює Аналітик. Критеріями розбивки однієї вимоги на завдання є - об'єкт / механізм. Здача розробок клієнту здійснюється за його вимогами, а не за завданнями розробки.
Складання списку завдань до спринту - Готовий перелік вимог до продукту Скрам-команда деталізує на завдання і формує перелік вимог до версії (відбираються за функціональністю і важливістю для Власника продукту). Документ з переліком завдань за вимогами повинен бути зрозумілим для Власника продукту і представлений у вигляді деревовидної структури з відображенням ієрархії.
Демонстрація версії - На демонстрації версії присутня вся Скрам-команда, Менеджер проекту (при необхідності), Власник продукту і власники процесів (при необхідності). Розробки за версією демонструються в робочій базі клієнта.
Ретроспектива - Ретроспектива з Власником продукту передбачає з'ясування які з розробок активно використовуються, а які «не прижилися» і чому.
Copyright © 2008-2024 TQMsystems. Всі права захищені. Privacy Policy | Terms of Service
