Вам бонус- начислено 1 монета за дневную активность. Сейчас у вас 1 монета

сравнение методов разработки ПО - Rup , XP, Scrum , Kanban Кабан-доска, Делай что хочешь , что выбрать?

Лекция



Привет, Вы узнаете о том , что такое сравнение методов разработки по, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое сравнение методов разработки по, rup, xp, scrum, kanban, кабан-доска, делай что хочешь , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.

Канбан – это не методология, это подход. В его основе лежат простые идеи:

  • Визуализируйте поток работ:
    • Разбейте работу на части, выпишите каждый из пунктов на карточку и прикрепите на стену.
    • Подпишите столбцы, чтобы видеть на какой стадии находится каждое задание.
  • Ограничьте НЗР (WIP) (прим. переводчиков work-in-progress – незавершѐнная работа) – определите возможное количество незавершенных пунктов на каждой стадии рабочего процесса.
  • Измеряйте время выполнения задачи (lead time) (среднюю продолжительность времени для завершения одного пункта, иногда называемую “оперативным временем” (cycle time)), оптимизируйте процесс, чтобы свести время выполнения задачи к минимуму и сделать его настолько прогнозируемым, насколько это возможно.

Инструмент – это то, что используется в качестве средства для выполнения задачи или достижения цели. Процесс – это то, как вы работаете. Scrum и Kanban – это инструменты процесса, они помогают вам работать более эффективно, до определенной степени подсказывая, что делать. Java – тоже инструмент, он упрощает программирование компьютера.

Как видно из книги, Канбан более чем гибкий и адаптивынй. Приведу количество предписаний:

  1. Rup – более 120
  2. XP – 13
  3. Scrum – 9
  4. Kanban -3
  5. делай что хочешь – 0

Фреймворк процессов – грубо говоря, это методология, содержащая большое количество правил, но в которой необязательно использовать их все, а можно выбрать только то, что нужно и построить свой процесс разработки. Имеют в своем составе специальные приложения, позволяющие просматривать и редактировать правила. Примеры: RUP, EssUp.

Scrum более директивный, чем Kanban, поскольку он предусматривает такие вещи, как итерации и кросс-функциональные команды. Scrum предписывает наличие 3-х ролей: Product Owner (отвечает за видение продукта и приоритеты), Команда (отвечает за реализацию продукта) и Scrum Master (устраняет препятствия в работе и руководит Scrum-процессом). Kanban же не предписывает вообще никаких ролей, чем меньше, тем лучше! Нужен один Product Owner с основной задачей – выставление приоритетов.

Методология Скрам (Scrum) – итерация называется спринтом. Команда состоит из 3 ролей: владелец продукта (представитель заказчика), скрам-мастер (следит за следованием процессу), остальные члены команды. Спринт начинается с митинга планирования, когда команда отбирает и распределяет задачи на итерацию, формируя бэклог спринта. Спринт заканчивается обзором спринта, где проводится демонстрация продукта и митингом ретроспективы спринта, на котором обсуждаются улучшения. Ежедневно проводятся 15-минутные скрам-встречи.

Методология экстремального программирования (XP) – состоит из 12 практик: парное программирование, разработка через тестирование, рефакторинг, простая архитектура, коллективное владение кодом, непрерывная интеграция, заказчик в команде, частые релизы, игра в планирование, 40-часовая рабочая неделя, стандарты кодирования, метафора системы. Обязательно использование всех 12 практик.


Методология RAD (Rapid Application Development) – ориентирована на быструю разработку приложения, итеративно, с максимально простой архитектурой, минимальными издержками на процесс, максимально используя готовые компоненты и мощные инструменты. Имеет ограничение на длительность проекта — 60-90 дней. Мне нравится аналогия с пирожками из полуфабрикатов. Так вот, RAD – когда нужно быстро слепить пирожок из готовых компонентов.


Методология Канбан (Kanban) – конвейер задач. Имеет всего 3 правила: визуализация процесса разработки с помощью канбан-доски, ограничение на количество задач на каждом этапе, постоянное измерение производительности команды и улучшения.

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

Команда №3 (управляемая событиями)

“Мы проводим планирование, когда у нас заканчивается работа. Мы делаем релиз, когда есть минимальная коммерчески ценная функциональность (minimum marketable feature set – MMF), готовая к выпуску. Мы проводим спонтанное обсуждение качества, когда сталкиваемся с одной и той же проблемой во второй раз. Мы также проводим более развернутые ретроспективы каждую четвертую неделю”.

Когда мы говорим о досках со стикерами мы видим колонку To Do (из Product Backlog), колонку In process (Ongoing) и колонку с завершенными задачами Done. Отличие Kanban от Scrum такое – в колонке Ongoing не может более n записей. В Scrum-е незавершенная работа ограничена за единицу времени.В Kanban-е незавершенная работа ограничена по каждому из статусов.

Канбан позволяет редактировать колонку To Do, в то время, как в Scrum мы можем поместить новую критичную задачу только в Product Backlog. То ест в канбане есть принцип “один ушел, один пришел”. Следует лишь следить за эквивалентность задач по трудозатратам.

Доска в Канбан может никогда не быть пустой во время проекта, в то время, доску Scrum надо очищать после каждого спринта. Доска в Канбан может быть поделена по функциям, а в Scrum команды кросс-функциональные.

Задачи в Канбан не обязательно разбивать на кучу подзадач тк, в отличие от Scrum, нет нужды уложиться с завершением в спринт. Кроме того: Scrum предписывает приоритезированный Product Backlog; В Scrum-е обязательны ежедневные собрания; В Scrum-е обязательны burndown диаграммы. Обе методологии, в принципе, позволяют работать с двумя проектам на одной доске.

Пример доски в Канбан:


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

Сейчас я хочу рассказать вам об эксперименте с канбан-доской, который дал великолепный результат в IT отделе далеко не IT-шной компании. Рабочий процесс с таким инструментом стал более контролируем и управляем, зависимость задач относительно каждого специалиста стала более прозрачна. Теперь всегда можно с уверенностью сказать, что отдел работает на все 100% и мы движемся к конкретным результатам, которые с большей вероятностью будут достигнуты.

Исходное состояние


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

Описанные выше реалии — это наша исходная точка. Об этом говорит сайт https://intellect.icu . Переходим к подготовке…

Проектирование


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

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

Пример:

  1. Создать виртуальную машину на ESXi #2, с параметрами Name: ServerABC, Guest: Ubuntu x64, RAM: 2 Gb, HDD: 20Gb Pre-allocated
  2. (after: #1) Установить Ubuntu Server 12.04 x64 на виртуальный сервер ServerABC (ESXi #2); разбить HDD: root 2Gb, swap 2Gb, home все оставшееся; IP: 192.168.0.7; hostname: ABC.com; user: abc pass: abc
  3. ...


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

Тикет-стикер


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

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

Так как наш план уже детально описан и помещен в тикетную ситему (в основной проектный тикет), для визуализации его на доске остается только вкратце переписать каждую задачу на стикер. Подготовленные стикеры размещаем на доске, группируя их по проектам.

Пример стикера:
сравнение методов разработки ПО - Rup , XP, Scrum , Kanban Кабан-доска, Делай что хочешь , что выбрать?

Поле действия


Подготовка закончена и теперь рассмотрим канбан-доску, с помощью которой будем управлять развитием событий. В отличие от «традиционного» течения слева направо, в этой стикеры будут спускаться вниз по следующим этапам, начиная с «пула»:

сравнение методов разработки ПО - Rup , XP, Scrum , Kanban Кабан-доска, Делай что хочешь , что выбрать?

  • Пул — самое большое место на доске, в котором находятся сгруппированные по проектам задачи. Область намеренно не размечена на участки, чтобы проекты занимали только необходимое пространство, так как они сами образуют область определенного цвета. Более того, термин «проект» в повседневной жизни IT отдела часто может означать просто большую задачу, которую можно разложить на подзадачи.
  • Очередь — ближайший краткосрочный план на исполнение. В этот раздел доски помещаются все задачи намеченные на исполнение в ближайшее время, и он используется в основном при реализации быстро идущих или приоритетных проектов. На практике для большинства задач раздел пропускается, и задачи из пула попадают сразу исполнителю в работу.
  • Выполнение — этот этап явно разделен на области соответствующие конкретному исполнителю. Выбирая исполнителя нужно учитывать тот факт, что решение некоторых задач может занять одинаковое время, как у высококвалифицированного специалиста, так и у начинающего. Но цели оптимизации исполнения могут быть разными, и как раз на этом этапе можно явно выбрать стратегию достижения цели. Например, мы можем менее требовательные к квалификации и несрочные задачи пропускать через начинающих специалистов, предоставляя им шанс для саморазвития. Естественно, срочные и важные работы нужно направлять на подготовленных специалистов. В общем, стратегий может быть множество, но самое главное мы видим в реальном времени, как у нас идет процесс, и мы оперативно можем подстраиваться под текущую рабочую ситуацию.
  • Проверка — так же, как и предыдущий этап разделен на исполнителей, но носит вспомогательный характер и похож на процесс Quality Assurance. Задачи помещаются в него, например, для получения фидбека от другого специалиста или для проверки специалистом, который владеет наибольшей компетенцией. Этот этап так же можно пропускать, если в проекте явно предусмотрен QA в отдельной задаче или сторонняя проверка не требуется.
  • Готово — финальный этап в котором все выполненные стикеры собираются в маленькие книжечки проектов.



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

«Готово»

P.S. Scrum и Kanban это не разные подходы, Kanban вполне используется для Scrum.

Как выбрать методологию?

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

сравнение методов разработки ПО - Rup , XP, Scrum , Kanban Кабан-доска, Делай что хочешь , что выбрать?

Разбор блок-схемы


сравнение методов разработки ПО - Rup , XP, Scrum , Kanban Кабан-доска, Делай что хочешь , что выбрать?

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

сравнение методов разработки ПО - Rup , XP, Scrum , Kanban Кабан-доска, Делай что хочешь , что выбрать?

Каждый проект имеет риски. Однако в данном случае имеются в виду риски настолько серьезные, что заранее не известно, можно ли будет вообще реализовать систему. Если такие риски присутствуют, то, скорее всего, вы начнете разработку с прототипов, концептов, моделей и т.п. чтобы выяснить принципиальную возможность задуманного. В таком случае для вас наиболее оптимальной моделью будет спиральная модель. Типичный пример применения этой модели – исследовательские проекты. Но только исследовательскими проектами применение этой модели не ограничивается.

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

сравнение методов разработки ПО - Rup , XP, Scrum , Kanban Кабан-доска, Делай что хочешь , что выбрать?

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

Однако в случае длительных проектов, каскадная модель будет плохо работать. Несмотря на то, что риски изменения требований отсутствуют, присутствует технические риски. Например, если вы разработали некорректную архитектуру, выбрали не те технологии и инструменты, не рассчитали требуемую производительность и т.п., с большой долей вероятности вы узнаете об этом в конце, и времени на исправление может не остаться. Чем дольше длится проект, тем выше цена исправления ошибки. Если на начальном этапе рефакторинги и кардинальные изменения кода даются легко, то под конец проекта, сделать это уже довольно-таки «болезненно».

Пример из практики: нам необходимо было реализовать мобильное приложение, которое делало бы абсолютно то же самое, что и такое же приложение для настольного компьютера. Таким образом, требования были известными и неизменными на всем протяжении проекта.

сравнение методов разработки ПО - Rup , XP, Scrum , Kanban Кабан-доска, Делай что хочешь , что выбрать?

Следующий вопрос: сложные ли требования. Вопрос опять-таки не однозначный и зависит от проекта. Кода вы начинаете проект, иногда бывает полезным на этапе анализа и проектирования продумать, как вы будете тестировать. Это может помочь раньше выявить потенциальные проблемы и лучше реализовать архитектуру, проработать требования и т.п. Когда требования сложные, рекомендуется тщательно продумать все сценарии тестирования, и еще на этапе анализа и проектирования разработать подходы к тестированию, тест-планы и тест-кейсы. В таком случае нам приходит на помощь модель V-Model, являющаяся разновидностью каскадной модели.

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

сравнение методов разработки ПО - Rup , XP, Scrum , Kanban Кабан-доска, Делай что хочешь , что выбрать?

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

Примером могут служить системы, от которых зависят жизни людей: медицина, транспорт, энергетика. Обычно подобные системы разрабатываются в соответствии с отраслевыми стандартами, многократно тестируются, подлежат лицензированию. Легкие методологии в подобных системах не работают. Как вы знаете, в них живое общение предпочтительнее документации, но, например, если ваше приложение будет тестироваться несколько раз разными командами, то лучше, если этот процесс тщательно задокументирован. Если в команде десятки человек, то никакой владелец продукта (представитель заказчика по терминологии скрам) не сможет им всем постоянно разъяснять требования.

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

сравнение методов разработки ПО - Rup , XP, Scrum , Kanban Кабан-доска, Делай что хочешь , что выбрать?

Если же нам формализованный подход не нужен, тогда мы будем использовать, так называемые, гибкие методологии. Скорость или качество? На самом деле здесь подразумевается немного более сложная формулировка: продуктивность или инженерия?

Под продуктивностью понимается наиболее быстрый процесс добавления функционала в приложение. Под инженерией подразумевается высокий уровень организации разработки, новаторские подходы и сложные приемы, которые могут быть применены только опытной командой. Я говорю о таких практиках экстремального программирования как разработка через тестирование, непрерывная интеграция, парное программирование и т.п. Особенность экстремального программирования заключается в том, что обязательно нужно использовать все 12 практик, только тогда эффект от них становится максимальным. Если вы не будете использовать какую-то практику, она обязательно потянет за собой все остальные. Например, если вы откажетесь от юнит тестов, тогда вы не сможете делать частые рефакторинги, без рефакторингов вы не сможете обеспечить простую архитектуру (как мы знаем простую архитектуру разработать сложнее, чем сложную) и т.п.

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

сравнение методов разработки ПО - Rup , XP, Scrum , Kanban Кабан-доска, Делай что хочешь , что выбрать?

Если же вам нужна максимальная продуктивность, то также есть варианты. Скрам ориентирован на постоянное усовершенствование процесса. Для этого у него есть митинг ретроспективы, которые проводятся в конце спринта. Также во время обзора спринта обсуждается, что было сделано хорошо, что плохо и что улучшить. Если у вас опытная команда, хорошо отлаженный процесс и вам в принципе не нужны совершенствования, то следование методологии Скрам будет отнимать у вас слишком много времени, которое вы могли бы потратить с большей пользой. Например, по Скраму, если спринт длится 1 месяц, то обзор спринта должен занимать 4 часа и ретроспектива спринта – 3 часа. Плюс к этому есть планирование спринта, длящееся 8 часов и ежедневные Скрам митинги по 15 минут.

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

сравнение методов разработки ПО - Rup , XP, Scrum , Kanban Кабан-доска, Делай что хочешь , что выбрать?

Если совершенствования не нужны и все, что нужно, это сконцентрироваться на выполнении задач, то хорошо подойдет RAD или Kanban. RAD имеет много общего с agile методологиями, но в нем есть существенное ограничение на длительность проекта. Желательно не более 60-90 дней. Канбан похож на некий беспрерывный конвейер, который может длиться бесконечно. Он хорошо работает на проектах поддержки, но плохо там, где требуется разработать сложную архитектуру, т.к. ориентирован на быстрое добавление фич в приложение. Под фичами имеется в виду кусок функциональности, который виден пользователю и непосредственно решает какую-либо его задачу. Например, логирование, оптимизация и масштабируемость пользователю не видны, это не фичи в терминологии Канбан. А вот новая страница, отчет, дополнительные фильтры в поиске— это то, что видно пользователю и является фичей.

Выводы

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

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

В следующей главе я очень кратко расскажу про упоминаемые в статье методологии и модели жизненного цикла, для тех, кто слышит о них впервые. Более подробно про каждую из них можно прочитать в Википедии. Если вы уже знаете их, то можете смело переходить к главе 2: «Разбор блок-схемы».

Вау!! 😲 Ты еще не читал? Это зря!

Представленные результаты и исследования подтверждают, что применение искусственного интеллекта в области сравнение методов разработки по имеет потенциал для революции в различных связанных с данной темой сферах. Надеюсь, что теперь ты понял что такое сравнение методов разработки по, rup, xp, scrum, kanban, кабан-доска, делай что хочешь и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем

создано: 2017-04-10
обновлено: 2020-12-26
132712



Рейтиг 9 of 10. count vote: 2
Вы довольны ?:


Найди готовое или заработай

С нашими удобными сервисами без комиссии*

Как это работает? | Узнать цену?

Найти исполнителя
$0 / весь год.
  • У вас есть задание, но нет времени его делать
  • Вы хотите найти профессионала для выплнения задания
  • Возможно примерение функции гаранта на сделку
  • Приорететная поддержка
  • идеально подходит для студентов, у которых нет времени для решения заданий
Готовое решение
$0 / весь год.
  • Вы можите продать(исполнителем) или купить(заказчиком) готовое решение
  • Вам предоставят готовое решение
  • Будет предоставлено в минимальные сроки т.к. задание уже готовое
  • Вы получите базовую гарантию 8 дней
  • Вы можете заработать на материалах
  • подходит как для студентов так и для преподавателей
Я исполнитель
$0 / весь год.
  • Вы профессионал своего дела
  • У вас есть опыт и желание зарабатывать
  • Вы хотите помочь в решении задач или написании работ
  • Возможно примерение функции гаранта на сделку
  • подходит для опытных студентов так и для преподавателей



Комментарии


Оставить комментарий
Если у вас есть какое-либо предложение, идея, благодарность или комментарий, не стесняйтесь писать. Мы очень ценим отзывы и рады услышать ваше мнение.
To reply

Разработка программного обеспечения и информационных систем

Термины: Разработка программного обеспечения и информационных систем