Рубрика «workflow»

image

Всем привет!

Мы решили поддержать тему миграции проекта, использующего Windows Workflow Foundation на .Net Core, которую начали коллеги из DIRECTUM, поскольку столкнулись с аналогичной задачей пару лет назад и пошли собственным путем.

Читать полностью »

Figma — простое решение для дизайнера, сложное решение для верстальщика - 1

Если вы работаете в области web-разработки, то рано или поздно, вам суждено будет познакомиться с Figma. Смиритесь с этим фактом и начинайте изучать. Я же попробую описать данный продукт, с точки зрения повседневного пользователя.
Читать полностью »

Правила подготовки макетов в Figma - 1

Боль с одним проектом привела нас к решению написать правила работы

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

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

Организовываем эффективный рабочий процесс веб-разработчиков: Confluence, Airtable и другие инструменты - 1

Я работаю фронтенд-разработчиком около двух лет, участвовал в создании самых разных проектов. Один из выученных мной уроков: взаимодействие между разными группами разработчиков, объединенных одной целью, но имеющих различные задачи и степень ответственности, — дело непростое.

Советуясь с другими участниками команды, дизайнерами и разработчиками, я создал цикл создания сайтов, предназначенный для небольших команд (5–15 человек). В него включены такие инструменты, как Confluence, Jira, Airtable и Abstract. В этой статье я поделюсь особенностями организации рабочего процесса.
Читать полностью »

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

  • Логики – это программисты с классическим флёром. Чтобы познакомиться с новой технологией они идут и читают документацию. Четкость кода – повышенная, ни шага влево, ни шага вправо. От забора и до обеда. Непритязательность к удобству работы с кодом пугает – кажется, что они могут работать и с минифицированным кодом, пользуясь одной только функцией поиска.
  • Визуалы – это люди, подходящие к коду более творчески, абстрактно. Чтобы изучить технологию они идут в youtube и смотрят видео про дельфинов уроки. В коде им важно разделение на осязаемые блоки, отсутствие простыней на 1000+ строк, возможность реализовать по-новому. Выполняя новую задачу они будут пристреливаться и искать свой вариант решения вместо поисков уже имеющегося на просторах интернета.

Речь в этой статье пойдет об инструменте разработки, без которого я, как представитель второго типа, уже не мыслю разработку проектов размером больше 250 строк и который, я уверен, будет полезен нашим коллегам из классического типа – он сделан в сотрудничестве с одним из вас – восходящей звездой мира программирования Степаном! Итак!
Читать полностью »

Привет! Сегодня мы расскажем о том, как разные команды в JetBrains “готовят” Agile и работают с Agile досками.

За продуктами JetBrains стоит множество команд: продуктовые, команды маркетинга, технической документации, дизайна и многие другие. Каждая команда придерживается собственного процесса, в зависимости от целей, ресурсов и особенности самой команды. На примере нашей компании и продукта YouTrack, мы расскажем о том, насколько гибкие бывают процессы, как найти подходящий для своей команды, и как настроить свою Agile доску.

Читать полностью »

В официальной документации Laravel написана целая страница о Homestead, но проблема в том, что в ней мало разъяснений зачем это вообще надо. В документации скорее инструкция для тех кто уже знаком и с VirtualBox и с Vagrant и с Linux (Ubuntu). Если Вы из таких — статья не откроет что-то новое, но если Вы прочитали про Homestead в документации и не поняли зачем это вообще надо, или что-то не получилось выполнить по инструкции — в этой статье все будет разжевано подробно.
Читать полностью »

Всем привет! Вчера мы выпустили новую версию системы управления проектами — YouTrack 2017.2 — и спешим поделиться с вами нововведениями.

Релиз YouTrack 2017.2: обновленный профиль пользователя, экспериментальная функциональность и многое другое - 1
Читать полностью »

Давайте представим некоторый проект на GitHub, куда мы хотим оформить Pull Request. Здесь нас будет интересовать только тот огромный жизненный цикл нашего пулл реквеста, который он фактически может пройти с момента рождения до самого момента его принятия и мержа в основной код проекта.

image

Итак, если порассуждаем, то пулл реквест может иметь следующие варицации над состояниями, которые я специально усложнил, если не знать о WorkFlow и смотреть на подобное тз:

1. Открыт
2. Находится в проверке в Travis CI, причем может попасть туда после того как были сделаны какие-то исправления или любые изменения, связанные с нашим Pull Request, ведь проверить-то надо все, не так ли?
3. Ждет Review только после того как была сделана проверка в Travis CI
3.1. Требует обновлений кода после того как была сделана проверка в Travis CI
4. Требует изменения после Review
5. Принят после Review
6. Смержен после Review
7. Отклонен после Review
8. Закрыт после того, как был отклонен после Review
9. Открыт заново после того как был закрыт, после того как был отклонен, после того как было проведено Review
10. Изменения после того как был помечен «Требует изменений», после того как было проведено Review, при этом после этого он снова должен попасть в Travis CI (пункт 2), а от Review снова может с ним случиться только те состояния, которые мы описали выше
Читать полностью »

imageТема внедрения изменений в бизнес-процессы дошла и до Российского отделения международной Ассоциации BPM-профессионалов (ABPMP Russian Chapter) в виде статьи президента этой ассоциации г-на Белайчука под названием "С чего начинается управление изменениями". Точнее г-н Белайчук поделился с читателями своего блога переводом статьи с англоязычного ресурса.

В статье речь идёт об управлении изменениями в бизнес-процессах. Основная мысль заключается в том, что "начинать управлять изменениями надо намного раньше — уже на первом этапе проекта BPI, когда разрабатывается устав, проводится выявление процесса и его моделирование". Автор статьи даёт понять, что управление изменениями должно носить систематический характер, и необходимо принимать во внимание, что в работе любой организации постоянными могут быть только изменения.

Далее в статье описываются трудности, которые непременно возникнут в организации при каждом витке итерации вносимых изменений в "устоявшуюся" работу процессов организации, и как с ними бороться на уровне психики?! "людей, сталкивающихся с изменениями".

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

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

Суть подхода заключается в следующем:

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js