Соглашение внутри команды

    Привет, у нас довольно большой поток разношерстных проектов. В какой-то момент нам пришла в голову светлая идея создать внутреннюю хартию ведения проектов, с которой соглашается каждый участник команды. Есть надежда, что это сократит издержки, увеличит качество и уменьшит количество неразберихи, позволит проще вводить новых «игроков» и вообще В качестве системы управления проектами выбрана Redmine, и надо сказать даже в default устанвоке эта штука правильно решает много вопросов за тебя: разделение на Ошибка\Улучшение, интеграция Git, лог действий, подпроекты, удобная Wiki и.т.д.


    Каждое приложение — один проект в формате Redmine
    Например, мобильное приложение «Для поиска свежего хлеба». Скорее всего приложение будет иметь три стороны: web, android&iOs, тогда структура проектов выглядит так:
    • Первичный — web (там же все организационные вопросы)
    • Подпроект 1 — iOs
    • Подпроект 2 — Android

    Задачи внутри проекта
    Стандартный процесс статусов задачи (М. — менеджер, П. — программист): М.Создана → П.В работе → П.Решена → М.Закрыта. (М. при необходимости менять на К — клиент)
    Уточнение параметров задачи: М. Создана → П. Обратная связь → М. Обратная связь → П. В работе.
    Типа задач: Ошибка — багфикс, Поддержка — плановая работа, Улучшение — работы не входящие в первоначальный план.

    Мало, но емко в Wiki.
    Например: FTP доступ, контакты участников команды и.т.д. Иначе говоря информация несущая административный характер. Redmine — стремление построить единое информационное пространство, в котором каждому участнику команды доступна вся необходимая информация.

    Git
    Обязательность связки коммит-задача. По возможности, следовать правилу одна выполненная задача — привязанный коммит. И соответственно наоборот, к каждому коммиту привязана задача. При описании коммита (commit -m), указать ид задача — «refs #Issue ID».

    Миграции БД
    Программист создает в корне проект файл migration.sql в котором содержится инструкция к созданию БД.

    Хранение файлов
    Файлы — хранение файлов внутри дирректории проекта. PSD и PDF в соответствующих папках внутри первичного проекта (design и ui). Таким образом сохраняется история рисования, места на hdd не жалко).

    Описание test-cases.
    По мере реализации проекта, менеджер совместно с программистом описывают сценарии тестирования приложения. В завершении каждого микрорелиза, в конце спринта проводится регрессивное тестирование проекта. На основании выполненных задач в релизе документ дополняется.

    Майлстоуны
    Мы поддерживаем идеологию непрерывной интеграции, при старте проекта менеджер проекта оценивает ключевые этапы в разработке проекта. И отмечает их на оперативном плане. Например, «Возможна регистрация пользователей» 15-го мая. Таким образом можно примерно оценить протяженность проекта, стоимость и нагрузку специалистов.

    Не проверено на практике Спринт
    Длительность спринта для каждого проекта варьируется от 3-х до 5 рабочих дней, и для каждой команды устанавливается индивидуально. В начале спринта команда совместно выбирает задачи для следующей итерации (берется в учет выставленный приоритет и личный интерес к задаче). По окончании спринта команда встречается на «ретроспективе», обсуждая ход предыдущего спринта, как правило это не занимает более 20 минут. Итак, на входе есть задачи, в процессе спринта они решаются, в результате получаем рабочие интерфейсы. Если задача не решена в ходе спринта, программист в комментариях описывает причину. В конце каждого спринта команда проводит регрессивное тестирование.


    Алгоритм реализации проекта
    1. Инициализация проекта в Redmine.
    2. Проработка UI. На «Форуме проекта» открывается ветка UI. Файл PDF прикрепляется прямо к сообщению в форуме, замечу, что обсуждения UI на форуме не отменяют встреч в офисе. Как только UI завершен и согласован, в разделе «Файлы» появляется файл «Final UI.pdf»
    3. Менеджер проекта стартует первый спринт, по паралелльным процессам дизайн и программирование. Вносит в оперативный план: дату завершения спринта, версия 0.1. Для обсуждения дизайна формируется ветка на форуме, в обсуждении участвуют: менеджер, дизайнер, ui специалист. Как и в случае в UI, форум не отменяет живых встреч. Результат согласован, и в разделе «Файлы» появляется файл «Final DESIGN»
    4. Этап верстки и программирования, заслуживает отдельной статьи.


    P.S. Итак, %username%, обращаюсь к тебе. Все пункты проверены на практике и написаны кровью. Но если ты поделишься капелькой мудрости, я буду очень благодарен. Конкрентно интересует, как вы используете Redmine, есть ли у вас в команде стандарты написания кода?

    Средняя зарплата в IT

    120 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 8 965 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 37

      +1
      Спринт лучше мерить неделями. 1-2, т.е. 5-10
      ибо спринт в 3 рабочих дня — фигня какая-то :) Тратить время на ретроспективу и тестирование каждый 4 день — антивариант.
      Стандартная практика 2 недели.
        +1
        Это всё, конечно так, но практика показывает, что бывают ситуации, когда нет возможности растягивать спринт на 2 недели, по самым разным причинам.

        К тому же, не обязательно проводить ретроспективу каждый такой маленький спринт — можно раз в 2 спринта.

        И, наконец, тестирование — его периодичность зависит от типа и потребностей. У нас тестирование проводится каждой* новой фичи, не важно закончился спринт или нет.

        Т.е. я к чему клоню — если использовать Agile, то нужно быть гибким, а не просто следовать «лучшим практикам».

        p.s. К слову, у нас в компании мы вообще отошли от спринтов, в общем их понимании.
        0
        >Программист создает в корне проект файл migration.sql в котором содержится инструкция к созданию БД.
        А почему вы не хотите пользоваться стандартным механизмом миграций?
          –1
          Привет, извини не знал про такой. Слышал про подобный механизм в RoR, но про PHP не знаю. Если в двух словах?
            +3
            В двух словах. Любое изменение базы сохраняется в отдельный файл, которых попадает в репозиторий вместе с остальными изменениями. После выкатки кода на продакшен по всем миграциям проходит скрипт, смотрит, какие еще не были применены и применяет их в том порядке, в котором они были добавлены. Если у вас нет проектов на нескольких серверах, то это оптимальный, на мой взгляд, способ.

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

            Вот тут описание, как это работает в yii.
              0
              Вот подобный механизм для PHP Mysql schema Migrations with PHP
              +2
              «стандартный» — это какой? (:
                0
                например, этот — github.com/davejkiger/mysql-php-migrations. Ему уже пару лет.
                  0
                  именно MPM послужил отправной точкой для MMP ( Mysql schema Migrations with PHP )
                  Автор не очень резво принимал мои патчи, и не очень хотел автоматизировать тулзу. Так и родился мой велосипед.
              0
              И соответственно наоборот, к каждому коммиту привязана задача

              Т.е. на одну большую задачу вы предлагаете делать всего один коммит?
                –1
                Стараюсь дробить большие задачи на маленькие.
                  0
                  Как написано в комментариях ниже, это не правильный подход. Коммит должен быть атомарным, но не обязательно, чтобы он закрывал задачу целиком, мне кажется это правило вносит только неудобство разработчикам. У нас обязательно принято, чтобы все коммиты были привязаны к задачам, но их может быть сколько угодно, в редмайне они хорошо выводятся, не мешает. Обычно их там получается 2-5.
                +1
                • Первичный — web (там же все организационные вопросы)
                • Подпроект 1 — iOs
                • Подпроект 2 — Android

                По-моему гораздо логичнее в качестве первичного создавать как раз общий проект, для орг. вопросов.
                А конкретные технологии уже выносить в подпроекты, потому как
                — что если вы решите использовать другую технологию вместо PHP? Тогда логика будет нарушена.

                И я думаю что все файлы лучше прикреплять к вкладке «Files», в случае если возникнут какие-то вопросы, то те же первичные UI проще найти.
                Это удобно для того чтобы новый разработчик мог просмотреть историю развития архитектуры и не задавал лишних вопросов/не предлагал идей, которые уже отмели и т.п.
                ИМХО конечно.
                  0
                  Cтандартный процесс статусов задачи (М. — менеджер, П. — программист): М.Создана → П.В работе → П.Решена → М.Закрыта. (М. при необходимости менять на К — клиент)

                  а тестирование сюда почему не входит?
                    +1
                    Прочитал ваш пост. Кроме этого вопроса habrahabr.ru/post/146231/#comment_4921212, у меня ещё куча других
                    Программист создает в корне проект файл migration.sql в котором содержится инструкция к созданию БД.

                    а если скриптов много? а если миграция с разных версий базы?

                    Описание test-cases.

                    автоматизированные тесты юзаете? если да, как и кто их пишет, когда запускаете?

                    Алгоритм реализации проекта

                    а где анализ? где тестирование? где пересмотр требований? (и не говорите, что этого не бывает)
                    как вам удаётся распараллелить разработку и дизайн?
                      +1
                      1. Я неправильно выразился, миграция в моем понимании — файл позволяющий воспроизвести рабочую структуру БД.
                      2. Автоматизированные скрипты не используем, надеюсь — это временно, постигаем эту науку.
                      3. Дизайн, только после прототипов, потому программист может начать без графики.
                        0
                        спасибо за ответ! и всё же, где у вас стадии анализа и тестирования?
                          0
                          Вам, спасибо за дельный комментарий и статью «про Мишу». Анализ проекта на этапе проработки интерфейсов взаимодействия, тестирование при каждой выполненной задаче\новой фиче. Или мы говорим о качестве кода: code review, refactor и.т.д.?
                            0
                            не, речь про бизнес-анализ. теперь более-менее ясно)
                              0
                              Много времени уделяется проработке проекта на старте, в среднем — две недели. Впрочем, мы строим машину, не космический корабль (ну вы поняли) — ценности или концепция могут меняться. Протипы получа.тся оцень приближенными к конечному результату, и содержат не только интерфейсы, но и комментарии для программистов\верстальщиков\дизайнеров.
                    +1
                    Вы, вроде как, используете некоторые плюшки из agile, но некоторыми остальными вещами вы делаете процесс разработки не очень гибким. Например, в agile нет никаких Final PDF, Final ТЗ, Final Tasks, там финальная версия может быть только по истечении последнего спринта (до этого момента все может «гибко» измениться). С гитом тоже не все супер — идеологически неверно приравнивать коммит задаче. Иногда решение задачи может разбиваться на несколько веток, не говоря уже о коммитах. Ваше понятие непрерывной интеграции я вообще не понял :), но если у вас это прижилось, то вы хороший PM.
                      0
                      Никто же не мешает привязать несколько коммитов к задаче, ведь так? И будут в таске несколько коммитов, пусть даже и в разных ветках. Плюсы же очевидны.
                        0
                        Может быть я не верно понял вашу фразу
                        одна выполненная задача — привязанный коммит
                        но мне она даже сейчас видится, как одна задача = один коммит :)
                          0
                          не, я не автор)
                          я просто посмотрел на «к каждому коммиту привязана задачак каждому коммиту привязана задача» и подумал, что все не очень тут печально)
                      0
                      Судя по описанию рабочего процесса основные задачи у вас — установка и настройка wordpress/drupal/e-shop :)

                      — У нас в компании приняты 2-х недельные спринты.
                      Этапы работы вполне стандартны: Задача — В процессе — Готово для тестов — Тест в процессе — QA — Готово.

                      Естественно перед каждым спринтом — планирование, игра в SCRUM карты. После — ретроспектива.

                      Кроме этого по четвергам — bugfix day, каждый берет какой-либо маленький баг и фиксит его, создавая отдельную ветку. Затем создается пулл реквест и отправляется в основной репозиторий на code review. После прохождения code review пулл-реквест изменения сливаются в основную ветку и тестируются командой QA, если все в порядке — изменения одобряются и ждут релиза, если нет — делается revert пулл-реквеста.

                      Ну и конечно же ежедневные stand up митинги в формате: что делал вчера — что планирую делать сегодня
                        0
                        Промазал, ответьте, пожалуйста на вопрос ниже.
                        0
                        А можете расписать, что происходит, если код не проходит code review. Интересует как организуется работа в системе контроля версий? Накатывается новый коммит на ветку с исправленным кодом?
                          0
                          Если code review не проходит, данные изменения не попадают в релиз. Есть неделя времени, чтобы все поправить и открыть новый пулл реквест.

                          Как у нас все это работает — разработчик мерджит master в свою ветку. Т.к. master содержит revert его изменений, не прошедших code review, необходимо сделать двойной revert, т.е. в логе смотрим какой коммит отменяет пулл-реквест, делаем revert этого коммита и получаем наш исходный код. Правим и отправляем очередной пулл-реквест.
                            0
                            А почему не делать фичу во временном «фича-бранче» и не отдавать на ревью его же? Потом там же после ревью вести правки и уже готовый код сливать в мастер? На минификсах же мастер погнете((
                          0
                          Программист создает в корне проект файл migration.sql

                          Мы обычно пользуемся стандартными механизмами миграция или вручную, но в таком случае используется далеко на 1 файл, как написано у вас. Есть папка Sql, в которой находятся папки: insert, update, delete, create, alter. И в каждой файлы, название которого соответствует названию таблицы и в нем уже содержится ряд изменений.
                            0
                            Как опредеояется порядок применения файлов?
                              0
                              как выполняются patches по уходу за данными?
                              0
                              У нас процесс несколько иначе построен, потому что там больше шагов. А именно:

                              1. Релиз раз в месяц, ответвляемся от development ветки в первое воскресенье месяца и делаем feature freeze. Месяц гоняем по тестам и в последнее воскресенье месяца выходим в production. Получается что у каждого разработчика на харде как минимум три ветки: development, current-release, upcoming-release где и ведутся разработки.
                              2. Все задачи ставят проект-менедждеры.
                              3. Задачи попадают главным по модулям системы.
                              4. Главные задачи описывают технически и разбивают на таски указывая размер, приоритет и срок. Максимальный размер любой задачи не может превышать 2 дня.
                              5. Разработчик в начале недели получает задачь на 4 дня (1 день — буфферный).

                              6. Взял таск, выполнил, сделал коммит для этого конкретного таска и отметил его «готовым для review»
                              7. Другой разработчик делает code review задачи, если всё ок идём дальше, если нет возвращаем разработчику.
                              8. Ответственный за модуль делает code review задачи, если всё ок идём дальше, если нет возвращаем разработчику.
                              9. Проект менеджер тестирует задачу, если всё ок идём дальше, если нет возвращаем разработчику.
                              10. Технический редактор документирует задачу, если всё ок идём дальше, если нет возвращаем разработчику.
                              11. Ответственный за репозиторий и целостность кода делает merge кода задачи в development branch.

                              Уии! Качество :)
                                0
                                Спасибо, у нас не практикуется code review, наверное это плохо. А вот у меня к вам такие вопросы:
                                1. судя по вашему описанию трудозатратность определяет менеджер, но он должен должен быть не просто спецом в технической части, но и погружен в проект не меньше чем программист?
                                2. что делаете если программист не уложился в отведенный срок?
                                3. есть ли у команды тех.лид, если есть какие задачи он выполняет?
                                4. есть ли ежедневные утренние совещения менеджер\программист?
                                5. Каким образом считается премия для програмиста?
                                6. Какие стандарты написания кода используете, есть ли они, как передаете новичкам?
                                7. Я так понимаю у вас не веб?)

                                Ваши ответы помогут мне стать лучше)
                                0
                                У меня к вам есть пара вопросов.

                                1. Есть ли у вас приоритет задач на спринт? И делаете ли вы их по приоритету?
                                2. Если задача ушла на тестирование, в ней найден баг. Когда вы его фиксите?
                                3. Имеете ли вы в конце спринта готовый продукт в котором нет незаконченных задач?
                                4. Вы разрабатываете новый функционал в ветках или все коммитите в основную ветку?
                                5. Если в ветках, то как у вас осуществляется тестирование. Сначала ветки, потом мерджа?
                                6. Используете ли вы какой-то инструмент для депмлоймента?
                                7. Проводите ли вы стенд апы и насколько они эффективны?
                                8. Насколько эффективны ретроспективы и имеете ли вы от них какие-то плюсы? Приведите пару примеров, если есть.
                                  0
                                  Есть неплохая практика — список функций серверного API заносим в таблицу на гугл-докс и расшариваем на всех разработчиков.
                                    0
                                    Или собираем с помощью phpdoc для каждого проекта)

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое