Это в некотором роде продолжение репорта от 31.03, т.к. эту неделю работа продолжалась в плавающем режиме


Date

Participants

Alina Kondakova Kryuchkov Matvey SERGEY NIKULOV Veronika Kalgushkina Glikin Alexey

Что делали?

Alina Kondakova

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

Kryuchkov Matvey

Дописан бэк для добавления групп помещений.Реализован первый этап бронирования стиралки и настроен бэкенд для удобной реализации бронирования(сделан один ендпоинт)

SERGEY NIKULOV


Veronika Kalgushkina


Glikin Alexey

Ничего

Что будете делать далее?

Alina Kondakova

Доделать валидацию полей при регистрации на бэке

Kryuchkov Matvey

Реализовывать второй этап бронирования стиралки - настройка интерфейса для добавления записи со стороны фронта. 

SERGEY NIKULOV


Veronika Kalgushkina


Glikin Alexey

Продолжать работать с аунтефикацией через google

Какие трудности вы испытывали при выполнении?

Alina Kondakova

Нехватка времени и сложности с джанго: надо разобраться с валидаторами получше

Kryuchkov Matvey

Сложности с django - разбирался с написанием вьюх для атомарного добавления нескольких записей в бд

SERGEY NIKULOV


Veronika Kalgushkina


Glikin Alexey

Не нашёл времени


6 Comments

  1. Igor Soshilov

    Apr 10, 2020

    Комментарии (сразу по двум неделям):

    1. Вести Meeting Notes тоже надо. Это немного разные форматы. Meeting Notes — это заметки со встреч, вы фиксируете все моменты, которые обсуждаете. Scrum report — это отчёт каждого студента по работе за последнюю неделю.
    2. Оценивать нужно все таски.
    3. Идентификатор issue нужно указать не только в названии ветки, но и в сообщении коммита. Это позволит JIRA подтягивать сразу непосредственно написанный код.
    4. На примере тасок  ST-18 - Getting issue details... STATUS  и  ST-45 - Getting issue details... STATUS .
      Констатация факта выполнения задачи — это не артефакт выполнения. Если нужно было написать код, артефакт выполнения — код в репозитории. Если нужно было что-то нарисовать — приложенный файл с рисунком. И т.д. Упомянутые таски (и не только они) артефактом выполнения не обладают. Создавайте ветки, указывайте идентификатор таски в сообщении коммита, чтобы JIRA автоматом всё подхватывала и на этом работа по приложению артефакта автоматически выполнялась бы.
    5. Подключайте остальных участников проекта, в частности Сергея Никулова, Веронику Калгушкину и Алексея Гликина. Это хорошо, что половину кода пишет руководитель проекта, но плохо, что ничего не делают (судя по активности в JIRA, в том числе по Bitbucket) половина команды. 
    6. Проверьте, что у вас правильно настроен gitconfig локально на компьютере.
      В репозитории появились коммиты от pew-pew f2ac13ff00d, но, к сожалению, студента с такими именем и фамилией на потоке нет. Передайте соответствующему человеку, что надо это поправить.

    1. Ivan Arkhipov

      Apr 10, 2020

      Будем исправлять, спасибо

  2. Igor Soshilov

    Apr 17, 2020

    Поскольку нового report'а не появилось, напишу пару вещей сюда же.

    1. Спринты недельные.
    2. В запущенный спринт новые таски НЕ добавляются.

    Кажется, оба пункта решаются одним действием.

    Ну и ещё момент. По поводу обновлённой  ST-54 - Getting issue details... STATUS . Рекомендуется использовать не Google Doc'и, а Wiki-систему проекта, т.е. Confluence. В первую очередь из соображений целостности, во вторую — безопасности.

    Следующий момент.

    Если ветвление и мёрджи идут где-то в другом месте, то это частично обрубает результаты. Для примера есть  ST-28 - Getting issue details... STATUS . С ней должна была существовать ветка 'ST-28-registration-fields-validation', но она либо удалена, либо всё-таки была создана где-то в другом месте. Ведь pull-request'ов в проекте вообще не было. А создавать их нужно именно в репозитории проекта, а не пушить коммиты других репозиториев. Pull-request'ы и ветки намного нагляднее демонстрируют прогресс по задаче, чем единичные коммиты, которые нужно каждый просматривать, чтобы увидеть результат (результат работы, а не результирующий код).

    Тут хорошо ситуацию показывает коммиты  ST-20 - Getting issue details... STATUS : "There are no changes to display". Это значит, что никакой работы в прошлом спринте исполнитель не делал.

    В данном случае подобное техническое продавливание своей позиции идёт во вред студентам, которые работают в проекте в рамках инновационного практикума.

    1. Ivan Arkhipov

      Apr 17, 2020
      1. Насчёт недельных спринтов - исправим. Перемешались старые и новые задачи, поэтому пришлось продлить спринт до двух недель. Постараемся больше не повторять таких ошибок.
      2. Насчёт веток и merge-request'ов - ветки удаляются автоматически после слияния. Слияние веток можно смотреть в merge-commit'ах. Задача ST-20 имеет за собой артефакт перехода на новый формат, мердж был произведён до того, как были исправлены названия коммитов, поэтому дополнительно сделали фейковые коммиты, повторяющие функционал (оригинальный коммит живет от 09 апреля, вот он http://bb.prac.atp-fivt.org:8080/projects/ST/repos/stfpmi/commits/b168df9078ae29e8e3cef74afea194b4cc6925eb). Впоследствии такого не будет. История веток правильно отображается в дереве битбакета, pull-request'ы не являются необходимым условием для этого (случаи ручного разрешения конфликтов и слияния веток - обычное дело в промышленной разработке).

      > В данном случае подобное техническое продавливание своей позиции идёт во вред студентам, которые работают в проекте в рамках инновационного практикума.

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

      Veronika Kalgushkina  Alina Kondakova  Kryuchkov Matvey  Glikin Alexey  SERGEY NIKULOV

    2. Alina Kondakova

      Apr 17, 2020

      Игорь, мы не страдаем, в организации все устраивает (smile)

      Насчет моей задачи по UI/UX: я пишу в доках, потому что провожу анализ нашего проекта для курса от 1С, а там вроде как все через гуглодоки сдают. Но поинт насчет соображений целостности принят, поправим. 

  3. Kryuchkov Matvey

    Apr 18, 2020

    Мне тоже нравится текущая организация процесса.
    Кажется, гитлаб намного более естественней и более удобней.