Гибкий.ру 1 Введение в примеры проектов
Внедрение проекта: В соответствии с требованиями онлайн-B2B-компании мы разработаем поисковый сервис, аналогичный Google. Как веб-сервис, сервис может быть встроен в веб-страницу. Когда пользователь вводит ключевые слова и выбирает тип и местонахождение продавца, система возвращает список конкретных продавцов (см. Рисунок 3).
Рисунок 3. Схема примера проекта
В таблице ниже представлены типичные действия по гибкой разработке и тестированию. Он в основном состоит из трех частей: от первоначального дизайна пользовательской истории и плана выпуска до итеративной разработки и тестирования нескольких циклов Sprint и фазы выпуска финального продукта.
Каждому периоду времени соответствуют соответствующие тестовые задания. Обычно циклы Sprint делятся на две категории: Feature Sprint и Release Sprint. Функциональный цикл в основном включает в себя разработку новых функций и различные тесты. Цикл выпуска будет объединен с планом для определения функций новой версии и последующего тестирования последних функций.
| Основные направления гибкой разработки | Тестовая деятельность |
|---|---|
| Дизайн пользовательской истории | Ищем скрытые гипотезы |
| План выпуска | Пример приемочного испытания для задания на проектирование |
| Итерационный спринт | Оценить время приемочного испытания |
| Кодирование и модульное тестирование | Оцените построение тестовой среды |
| Рефакторинг | Подробное описание сценариев приемочного тестирования |
| интегрированный | Напишите примеры приемочных испытаний |
| Провести приемочные испытания | Приемочный тест рефакторинга |
| Спринт заканчивается | Провести приемочные испытания |
| Следующий спринт начинается | Выполните регрессионное тестирование |
| выпуск | выпуск |
В итеративном цикле спринта часть разработки можно разделить на кодирование и модульное тестирование, рефакторинг и интеграцию в соответствии с традиционными шагами. Следует отметить, что рефакторинг и интеграция — это задачи, которые нельзя игнорировать в итерации гибкой разработки Sprint. Если вы хотите оптимизировать и улучшить последнюю функцию в новом цикле Sprint, рефакторинг и интеграция неизбежны.
Перед завершением каждого цикла спринта группа тестирования отправляет приемочные тесты для функций, выполненных в цикле спринта или в предыдущем цикле спринта (в реальных проектах команда тестирования обычно опережает прогресс команды разработчиков).
Когда все функции продукта реализованы и работа по тестированию в основном завершена, он входит в цикл выпуска. В настоящее время перед тестовой командой стоит относительно много задач.
Выше мы обозначили основные направления гибкой разработки. Ниже мы дадим подробное введение и анализ соответствующих тестовых действий на каждом этапе. Первый — это этап разработки и выпуска пользовательской истории.
Часть 1: введение в гибкую разработку программного обеспечения
Гибкая разработка программного обеспечения (Agile Software Development) началась в середине девяностых годов. Изначально она была предназначена для сравнения с традиционной моделью разработки программного обеспечения «водопад» (модель водопада), поэтому методы в то время назывались облегченными методами.
В начале своего создания Agile Alliance сформулировал четыре основных ценностных принципа:
- Коммуникация с людьми важнее процессов и инструментов (Individuals and interactions over processes and tools）
- Программные продукты важнее длинных статей (Working software over comprehensive documentation）
- Сотрудничество с клиентами важнее переговоров по контракту (Customer collaboration over contract negotiation）
- Отзывчивость важнее соответствия (Responding to change over following a plan）
На основе этих четырех принципов гибкая разработка программного обеспечения имеет свой уникальный процесс.
Весь процесс смешан со многими методами разработки программного обеспечения, появившимися еще до гибкой разработки, включая экстремальное программирование (1996 г.), Scrum (1986 г.), разработку через функции и разработку через тестирование. Подождите. Эти методы полностью отражены и применяются на всех этапах процесса гибкой разработки программного обеспечения.
Например, Скрам в основном фокусируется на управлении проектами. Менеджер проекта (Скрам-мастер) в команде должен сформулировать цикл Спринта при поступлении каждого запроса клиента, определить цели каждого Спринта, назначить задачи, контролировать и, наконец, подвести итоги достижений и результатов. потерь и начать Планируйте новый Спринт.
Напротив, разработка на основе функций и разработка на основе тестирования в основном используются в цикле Sprint. Если проект находится в периоде разработки новых функций, на этом этапе в основном реализуется функциональная разработка. Все тестировщики и разработчики сосредотачивают свою работу на новых функциях и выполняют свои задачи как с точки зрения разработки, так и с точки зрения тестирования.
Если проект находится в периоде тестирования новых функций, на этом этапе необходимо сместить фокус работы на тестирование. Все тестировщики и разработчики уделяют пристальное внимание дефектности текущей версии. Тестировщикам необходимо сообщать о новых дефектах, обнаруженных в предыдущий рабочий день, на Ежедневном совещании по работе с клиентами.
Менеджер проекта решает, следует ли исправить эти проблемы, в зависимости от хода проекта и серьезности дефектов. Дефект, который необходимо вовремя исправить, — это новая задача в текущем Спринте. Менеджер проекта добавит ее в Бэклог Спринта и уведомит разработчика об исправлении уязвимости.
Для процесса обзора в гибкой разработке и тестировании полностью применена идея коллегиального обзора в экстремальном программировании. Обзор кода и документации преследует цель простоты и эффективности. Члены команды образуют пару, чтобы проверять друг друга; иногда разработчик и тестировщик также могут образовать пару для сотрудничества друг с другом. Это может помочь устранить дефекты и проблемы в зародыше.
Гибкая разработка также имеет следующие ключевые концепции (ключевые вопросы):
- Итерационный процесс (Итерационный процесс)
- Истории пользователей
- Задачи
- Stand-up встреча
- Непрерывная интеграция
- Самые простые решения
- Рефакторинг
Эти концепции представляют собой представления и методы, часто используемые в гибкой разработке. Ниже мы подробно обсудим роли и функции тестировщиков в гибкой разработке программного обеспечения.
2 Стадия разработки пользовательской истории и планирования выпуска
На этапе пользовательской истории и планирования выпуска менеджер проекта и менеджер продукта формулируют сводный график выпуска продукта в соответствии с потребностями клиента. На этом этапе тестировщики и разработчики могут вместе изучать новые функции и понимать потребности клиентов.
3.2.1 Поиск скрытых гипотез
Как упоминалось ранее, разработчики обычно сосредотачиваются на некоторых важных системных функциях и игнорируют детали. Кроме того, гибкая разработка выступает за простые схемы реализации. Невозможно достичь идеальных функций в каждом цикле спринта разработки; напротив, каждый спринт должен будет разрабатывать некоторые функции постепенно.
Пример проекта:
- Подумайте с точки зрения онлайн-компаний B2B
В: Какое значение имеет это окно поиска для бизнеса компании?
A: Поле поиска может помочь пользователю получить справочную информацию поставщика. Если все больше и больше пользователей будут использовать это окно поиска, это может увеличить количество посещений нашего веб-сайта.
- Думайте с точки зрения пользователя
Q: Как пользователь веб-сайта ищет информацию и деловых партнеров, каковы преимущества окна поиска для меня?
A: Недостаток: я нашел адрес продавца только для того, чтобы узнать, что он был закрыт в прошлом.
Преимущества: найти продавцов легко, просто щелкните мышью
Недоволен: иногда я ищу продавца определенного типа, но не помню его конкретного названия.
- Думайте с точки зрения программиста
А как построен scrum у нас?
Команда состоит из PO (Product owner), Scrum Master и Developing Team, которая в свою очередь состоит из 1 QA Automation, 1 Backend developer, 1 Frontend developer, 1 UX и 1 верстальщика. Разработка идет итерационно, спринтами по 2 недели. Во время каждого спринта проводится несколько типов встреч:
- Planning — планирование спринта, набор задач на ближайшие 2 недели из Backlog проекта.
- Backlog refinement — разбор Road map проекта, оценка задач, лежащих в Backlog.
- Demo — показ результатов спринта, оценка проведенных работ, принятие решения об успешности спринта.
- Retro — обсуждение положительных и отрицательных моментов спринта, поиск решений, необходимых для устранения отрицательных моментов.
- Daily meeting — ежедневный митинг для того, чтобы увидеть ситуацию на проекте от лица каждого члена команды.
Процесс выполнения задачи проходит следующим образом:
- На планировании задача попадает в Backlog текущего спринта из Backlog проекта
- После переходит в статус In dev на Scrum Board и разработчики приступают к выполнению
- Результат выполнения задачи заливается в отдельную feature ветку в git
- Задача переходит из статуса “In dev” в статус “In test“на Scrum Board
- Результат выливается на тестовый стенд и тестируется
- Реализуются автотесты на выполненную задачу
- После этого написанные автотесты и реализованный функционал отправляются в основную ветку проекта в Git — в develop
- Когда все задачи выполнены и покрыты автотестами происходит их сборка на CI. При успешном выполнении сборки (пройдены все unit и автотесты) приложение автоматически раскатывается на внутренний демо стенд для проведения демо.
- Если результат спринта принят успешно — сборка раскатывается на пром сервер.
Что же происходит в начале спринта для автоматизатора тестирования и в конце спринта для разработчика? Ведь казалось бы в начале спринта еще нет выполненных задач, а в конце спринта уже не остается задач, которые не были бы переведены на тестирование. А происходит приблизительно одно и то же, оптимизация кода, рефакторинг, внедрение новых инструментов и тому подобное.
Как пример для автоматизатора — внедрение Allure отчетов, для девелопера — оптимизация работы запросов.
Вмешательство человека через глубокое тестирование
В нашей компании разработчики вместе со специалистами по контролю качества проводят глубокое тестирование — полезную практику, применяемую при разработке, для отсеивания более серьезных багов. Как и при проверке кода, при глубоком тестировании в команде разработчиков происходит обмен знаниями, полученными в ходе него. У разработчиков развиваются навыки тестировщиков, благодаря чему они изначально поставляют код более высокого качества.
Можно подумать, что глубокое тестирование — это ручное тестирование, но на самом деле нет. Во всяком случае, это не то же самое, что ручное регрессионное тестирование. Для глубокого тестирования используется подход, основанный на оценке риска, и критическое мышление.
Тестировщик может использовать свое знание рисков, особенностей реализации и потребностей клиентов, и на ранних стадиях тестирования эта возможность позволяет разработчику или специалисту по контролю качества быстро и системно находить проблемы без помощи тестовых сценариев, обстоятельных планов тестирования или требований.
Нам этот подход кажется эффективнее традиционного ручного тестирования, поскольку мы применяем выводы, сделанные в ходе сеансов глубокого тестирования, к исходному коду и автоматическим тестам. При глубоком тестировании мы также получаем опыт использования новой функции, который нам не дает тестирование по сценарию.
Для поддержания качества на постоянном уровне нужно сочетать глубокое и автоматическое тестирование. Глубокое тестирование позволяет обеспечить более полное соответствие кода разрабатываемых функций требованиям к качеству, нежели автоматические тесты сами по себе.
Гибкая методология
Компании по всему миру работают над тем, чтобы создавать продукты более высокого качества за меньшее время. Для достижения этой цели многие производители начали применять гибкие методологии разработки. Именно такой подход поможет ускорить выход продукта на рынок, повысить его качество и увеличить производительность, а также объединить различные цели бизнеса и технологии.
Использование гибких методологий разработки дает мощный импульс компаниям. Cогласно аналитическому отчету ведущей международной исследовательской компании Forrester, в последние годы значительно возрос интерес к гибким методологиям. По сравнению с традиционной водопадной моделью, гибкая методология позволяет получить большую ценность за более короткий срок, а также значительно увеличивает ROI.
Гибкая разработка подразумевает работу над проектами в командах, где разработка продукта происходит итерационно, и новый функционал добавляется от итерации к итерации. Гибкая методология разработки проповедует тесную командную работу, регулярные итерации, обзоры выполненной работы и высокую самоорганизацию участников команды.
При использовании водопадной модели разработки, тестирование производительности выполняется в конце жизненного цикла. В гибкой методологии такое тестирование становится возможным в самом начале, включая стадии анализа и проектирования.
Поскольку производительность приложения напрямую зависит от качества его архитектуры, необходимо уделить ей достаточное внимание на ранней стадии жизненного цикла. Тестирование производительности производится в течение всего процесса гибкой разработки, от стадии планирования релиза и далее.
Чтобы обеспечить тестирование производительности, надо сформировать целевые показатели производительности приложения. Если фактические показатели производительности удовлетворяют требованиям, тест считается успешно пройденным. В Agile методологии тестирование производительности нужно выполнять каждую итерацию.
Отказ от традиционных способов тестирования в пользу agile
Команды Agile и DevOps стремятся наладить стабильную поставку новых функций высокого качества. Однако традиционные методики тестирования попросту не вписываются в принципы Agile или DevOps. Высокие темпы разработки требуют нового подхода к обеспечению качества каждой сборки.
Технический долг, как задолженность по кредитной карте, растущая с процентами, поначалу ощущается как небольшая заноза, но затем быстро приобретает пугающие масштабы и сковывает действия команды, не позволяя ей следовать принципам agile. Чтобы справиться с быстрорастущим техническим долгом, мы в компании даем разработчикам возможность быть главными специалистами по качеству (более того, мы ожидаем этого от них). Мы уверены, что разработчики обладают принципиально важными навыками для обеспечения качества продукта.
- Разработчики — асы в устранении проблем с кодом.
- Разработчики, которые сами составляют тесты, более заинтересованы в том, чтобы устранить ошибки в них, если таковые обнаруживаются.
- Разработчики, которые понимают требования к функциональным возможностям и значение тестирования, как правило, пишут более качественный код.
По нашему мнению, для каждой пользовательской истории в бэклоге нужно писать код дважды: код самой функции и код автоматического теста. В некоторых командах код функции пишут разработчики, а кодом автоматических тестов занимается специальная команда, но мы считаем, что гораздо эффективнее, когда оба вида кода пишет один специалист.
Баги в новых функциях и ухудшения в существующих следует воспринимать по-разному. Если баг обнаруживается во время разработки, выделите время, чтобы понять, в чем проблема, устраните ее и продолжайте работу. Если обнаруживается ухудшение (т. е. проблема возникла в той функциональности, которая раньше работала нормально), то оно, скорее всего, проявится снова. Разработайте автоматический тест, который предотвратил бы это ухудшение в будущем.
Из этого подхода не следует, что разработчики должны работать сами. Важно, чтобы в команде были и специалисты по контролю качества. Они видят разработку функции с другой стороны, и их мнение важно. Хорошие специалисты по контролю качества знают, где обычно скрываются баги, и могут предупредить разработчиков о подводных камнях.
Переходный период. из традиционного тестирования в agile
Красиво, когда продукт выделяется среди своих конкурентов,
как художественная гимнастка в толпе газонокосилок. Но для этого нужно уметь
предугадывать желания целевых клиентов и муштровать проект в этом ключе,
постоянно тестируя и корректируя функционал.
И,
Чтобы новые продукты танцевали как гимнастки на пике
карьеры, компании переходят от традиционных методов разработки и тестирования (Waterfall) к гибким (Agile).
Ведь
Agile и направлен больше на скорость выпуска продукта и эффективность решений, а строгая фиксированность процессов разработки и тестирования
(что для ряда продуктов может быть критичным) остаются позади.
Но люди-то не любят
перемены. Традиционно у нас всё максимально формализовано – требования,
процедуры и даже сферы ответственности. А в гибких методологиях некоторые
звенья размываются, способы взаимодействия становятся более личными. И что
потом с этим делать – непонятно. Особенно заметна ситуация с точки зрения
тестирования и QA.
Какие-то компании нанимают специальных тренеров, гуру гибких
методологий, кто-то справляется своими силами и обучает команду шаг за шагом.
Мы в Webmart QA ребята самостоятельные, поэтому на своём опыте уже научились, что
и как лучше делать. Так что предлагаем наше видение на переход из Waterfall в
Agile – с матчастью, шагами и разбором проблем в контексте тестирования. Поехали!
Процесс разработки продукта в Agile состоит из ряда циклов по 1-4
недели, называемых итерациями. Каждая итерация считается обособленным проектом
и включает в себя планирование, проектирование, написание кода, тестирование и
ретроспективу.
Как это всё вообще работает:
Гибкая разработка не любит формальностей, поэтому решения по
проекту принимает вся команда. Тестеры участвуют во всех встречах команды –
сидят на ежедневных митингах, говорят на ретроспективе, вносят свои предложения
и правки. Даже если сидят отдельно от разработчиков!
Как мы уже сказали, Agile реализуется в форме итераций. Для успешного
завершения каждого цикла, команда тщательно планирует для себя пул задач, и да,
тестировщики тоже сидят и планируют. Вообще мы считаем участие тест-специалиста
в оценке объёмов работ самым прямым инвестированием в успех проекта. Потому что только так о тестировании не
забудут, и качество готового продукта будет на высшем уровне.
К функционалу ПО относятся строго. Если функция сделана, но
не протестирована – задача не считается закрытой. Все члены команды это
понимают, поэтому работают над планом итерации очень тщательно. Спасибо
командной ответственности, которая позволяет избежать раздувания функционала
продукта.
Задачи итерации – это задачи для всей команды. Конечно,
дизайнер вряд ли может помочь разработчикам. Но если у тестера есть время, то
он готов предложить свои руки и голову кодерам. Из этого принципа, кстати, и
происходит практика разработки через тестирование (TDD, Test Driven Development ). Мы обязательно подробнее
расскажем об этой интересной практике в следующих статьях, не пропустите!
В свою очередь, если тестер зашивается в работе, а конец
(итерации) близок, то прогеры выступают единым фронтом и проводят, к примеру, тестирование производительности.
Но самым главным является общий конечный результат,
появляющийся при эффективном взаимодействии:
- дизайнера и разработчика (применённый новый
внешний вид); - разработчика и тестировщика (стабилизированная
функция или новая фича); - разработчика, тестировщика и менеджера
(собранная стабильная версия); - владельца продукта и менеджера проекта
(актуальная информация, своевременное управление запросами и требованиями,
обратная связь).
А чтобы конечный результат всех устроил, важно правильно
перейти от традиционных методов разработки и тестирования к гибким. Приведём
ниже наше видение этапов перехода.
Из Waterfall в Agile за 5 шагов:
1. Митинги.
Первым и самым действенным шагом
будет внедрение ежедневных 15-минутных stand-up встреч команды. Суть встреч в
том, чтобы каждый участник рассказал, чем он занимался вчера, каких результатов
добился, чем будет заниматься сегодня и какие цели перед собой ставит.
Параллельно обсуждаются возникающие затруднения и сложности, по которым
коллектив может выработать решение, а менеджер – подтвердить тот или иной план
реализации.
2. Переоценка.
Затем менеджер проекта меняет подход к оценке разработки
требований. Он делит весь жизненный цикл на 1-4 недельные итерации, которые
наполняются соответствующими задачами для успешного релиза конечного продукта.
Обязательными задачами будут: реализация требований, тестирование,
стабилизация, демонстрация/ретроспектива, релиз (на актуальный тестовый либо
продуктивный контур). Для эффективного планирования каждой итерации требуется высокая
квалификация как менеджера проекта, так и ведущих специалистов направлений
разработки и тестирования.
3. Дефектология.
Теперь изменяется система ведения учета задач и дефектов.
Каждое требование, задача назначается на определенную версию продукта, билда,
программы, приложения. Команда участвует в планировании сроков и объемов работ.
Т.е. подразумевается изменение таск- и баг-трекинга и информирование команды.
4. Роли.
Редактируем ответственность за отдельные результаты работы
команды. Необходимо назначить на каждую активность одного основного исполнителя. Здесь
одним из главных критериев эффективности будет отсутствие перегрузки
ответственностью одного участника и недогрузки других. Так что менеджеру
проекта придётся научиться жонглировать людьми и задачами.
5. Документирование.
В соответствии с разработанными планами итераций, все
требования, доработки, тесты и исправление существующих проблем планируются
также в связке с версией продукта (или определенной итерацией).
Выполнив эту последовательность шагов, вы уже сможете гибко
подходить к планированию, объёмам и срокам выпуска критичных для бизнеса
результатов работы всей команды. Если говорить об аутсорсинге, то конечный
заказчик будет просто счастлив видеть, как его продукт превращается в настоящую художественную гимнастку. Однако, поскольку разница между двумя методологиями
огромна, при смене модели могут возникнуть и затруднения.
Проблемы при переходе от Waterfall к Agile:
То, что при каскадной разработке без документов никак – это
знают все. Но и с Agile стандарты, шаблоны, планы тестирования и тест-кейсы
никуда не пропадают!
Это очень большая составляющая работы по обеспечению
качества (QA), и мы не советуем ей пренебрегать. Стандарты помогают приводить процессы,
требования и критерии к общему знаменателю. Используйте документы в лёгкой
форме, тогда не возникнет диссонанс по поводу того, что «мы вроде гибкие,
работаем в agile, а тут
снова куча бумажек». Бумажки и не нужны, просто старайтесь письменно подводить
итоги митингов и каждой итерации – это поможет определить направление, в
котором вы идёте и сопоставить его с вашими целями.
Делайте доступные для команды документы на общем облачном
диске или используйте инструменты вроде OneNote. Обязательно организуйте всю
команду для участия в ведении таск- и баг-трекинга. Для этого всего, в том
числе и для учёта требований, лучше использовать единую систему.
В Waterfall этап тестирования идёт прямо перед выпуском
готового продукта. До его начала тестировщики могут не иметь ни малейшего
понятия о функционале и целях создаваемого ПО. А в Agile тестировать необходимо
в каждой итерации, вникая во все детали и полностью погружаясь в проект. К
этому нужно привыкнуть. Пока проверять ещё нечего, тестеры изучают требования,
пишут тест-кейсы и разрабатывают авто-тесты.
Автоматизация очень важна в Agile, поскольку короткие
временные промежутки требуют частых проверок. Мы рекомендуем специально
закладывать время на создание новых и модернизацию существующих тестов в план
каждой итерации.
Затем каждый новый билд проверяется на живучесть, а вместе с
ним и все последовательно добавляемые функции. Здесь тестирование – это не
одноразовое мероприятие, а постоянный процесс.
За 2 дня до конца итерации функционал не пополняется,
тестируется версия билда, которая будет показана владельцу проекта на
демонстрации в последний день итерации.
Командная ответственность, к сожалению, не всегда приводит к
общей дисциплинированности. И мы думаем, что для Agile важно всей командой сесть
и выработать DOD – Definition of Done
или параметр «Готово». Это позволит определить, насколько таск выполнен и
выполнен ли он вообще. При этом, для каждого случая и каждой команды DOD
уникален!
Что касается
тестирования, вы можете определять готовность, к примеру, так:
Для задачи:
- На основные моменты написаны авто-тесты
- Тесты успешно проходятся
Для функции:
- Написаны приёмочные авто-тесты
- Неавтоматизированные тесты добавлены в чек-лист
- Функция идёт со статусом Validated
Для итерации:
- Билд прошёл тестирование и не крэшится
- Билд понравился владельцу проекта на
демонстрации - Добавлены заявленные функции
- Вся документация одобрена
И так далее. Напоминаем, это только пример. Вся суть DOD и
его предназначение – дисциплинировать вашу команду, чтобы каждый участник
согласился с критериями готовности и применял их к себе. Так коллективная
ответственность будет на высоком уровне.
Да, оказывается,
переход из Waterfall в Agile вряд ли будет лёгким и беззаботным, придётся много
общаться, решать конфликты и создавать культ круговой поруки. Но! Это
сторицей окупится, поскольку:
1. Продукт будет постоянно развиваться и каждые 2-4
недели вы будете получать успешно реализованный объём функциональности.
2. Вы сможете управлять объёмами работ, увеличивая
и уменьшая задачи, входящие в версию.
3. Проектная команда будет не конкурирующими
отделами, а станет большой дружной семьей, которая сфокусирована на общих целях
в рамках итерации и всего жизненного цикла проекта.
4. Тестировщики будут постоянно работать с
проектом, смогут на самом деле консультировать, обеспечивать и контролировать
его качество.
5. Соответственно, качество продукта не поставит
конечного пользователя в тупик.
6. Ваше ПО будут использовать, покупать и
советовать друзьям.
7. PROFIT!
Поделитесь своим
опытом в комментариях. Приходилось ли вам менять модель тестирования, как
вы это делали, возникли ли проблемы, тормозящие разработку нового продукта, и
как вы с ними разобрались? Мы тоже присоединимся к обсуждению 😉
Приложение: инструменты управления гибкой разработкой
Давным-давно возникла такая идея: разработать комплекс эффективных управляющих программ для управления проектами в индустрии разработки программного обеспечения. Причина этой идеи связана с моим собственным опытом. В первые годы, когда я работал над системой **, директор отдела просил меня сделать такой набор вещей на основе Visual Basic и adodb. В то время у меня не было достаточно опыта, видения, и идеи, и я сделал это с мыслями о пробах и исследованиях. Это просто ограничено указанными выше ограничениями, как вы скажете, что вы сделали? Он кажется очень маленьким, потому что нет специального дизайна интерфейса, а дизайн UI не атмосферный.Отдел может реализовать только распределение задач на основе локальной сети, еженедельное написание отчетов и загрузку документов.
1. Leangoo, я узнал об этом инструменте через веб-поиск. Через веб-сайт я зарегистрировал учетную запись, создал новый список продуктов и просмотрел некоторые существующие примеры веб-сайта. Вообще говоря, он объединяет идеи управления гибкой разработкой., Вид ясный и приятный.
2. Teambition, это программное обеспечение, о котором я узнал раньше, и у него есть онлайн-версия и версия приложения. Есть управление задачами, управление часто задаваемыми вопросами и т. Д., Что неплохо, но концепции карточек задач управления гибкостью, канбан, диаграмма выгорания и т. Д.
, Похоже, не отображаются в программном обеспечении. Больше всего меня поразил FAQ, который может иметь какое-то отношение к характеру моей работы. Я лично считаю этот модуль более практичным. Это предыдущая ситуация. Не знаю, есть ли сейчас ревизия.
3. Worktile. В Worktile по умолчанию мы вводим «сообщение» IM. Эта функция мгновенного обмена сообщениями является воплощением коммуникации. В сценарии совместной работы предприятия задача — это начальный результат общения и суть выполняемой работы. Ядро Worktile — это задача.
Похожие гибкие материалы:
Моделирование жизненного цикла проекта — Управление проектами. Том 1 
Принципы исполнения обязательств (ПРИНЦИПЫ ИСПОЛНЕНИЯ ОБЯЗАТЕЛЬСТВ) [Курсовая №63732] 
Подготовка к ОГЭ и ЕГЭ. | Образовательная социальная сеть 
Гибкий камень технология производства своими руками, недостатки гибкого камня — Строй-специалист.ру 
Работа с гибким графиком в Тюмени, свежие вакансии с гибким графиком на SuperJob