Comments 37
Спринт лучше мерить неделями. 1-2, т.е. 5-10
ибо спринт в 3 рабочих дня — фигня какая-то :) Тратить время на ретроспективу и тестирование каждый 4 день — антивариант.
Стандартная практика 2 недели.
ибо спринт в 3 рабочих дня — фигня какая-то :) Тратить время на ретроспективу и тестирование каждый 4 день — антивариант.
Стандартная практика 2 недели.
Это всё, конечно так, но практика показывает, что бывают ситуации, когда нет возможности растягивать спринт на 2 недели, по самым разным причинам.
К тому же, не обязательно проводить ретроспективу каждый такой маленький спринт — можно раз в 2 спринта.
И, наконец, тестирование — его периодичность зависит от типа и потребностей. У нас тестирование проводится каждой* новой фичи, не важно закончился спринт или нет.
Т.е. я к чему клоню — если использовать Agile, то нужно быть гибким, а не просто следовать «лучшим практикам».
p.s. К слову, у нас в компании мы вообще отошли от спринтов, в общем их понимании.
К тому же, не обязательно проводить ретроспективу каждый такой маленький спринт — можно раз в 2 спринта.
И, наконец, тестирование — его периодичность зависит от типа и потребностей. У нас тестирование проводится каждой* новой фичи, не важно закончился спринт или нет.
Т.е. я к чему клоню — если использовать Agile, то нужно быть гибким, а не просто следовать «лучшим практикам».
p.s. К слову, у нас в компании мы вообще отошли от спринтов, в общем их понимании.
>Программист создает в корне проект файл migration.sql в котором содержится инструкция к созданию БД.
А почему вы не хотите пользоваться стандартным механизмом миграций?
А почему вы не хотите пользоваться стандартным механизмом миграций?
Привет, извини не знал про такой. Слышал про подобный механизм в RoR, но про PHP не знаю. Если в двух словах?
В двух словах. Любое изменение базы сохраняется в отдельный файл, которых попадает в репозиторий вместе с остальными изменениями. После выкатки кода на продакшен по всем миграциям проходит скрипт, смотрит, какие еще не были применены и применяет их в том порядке, в котором они были добавлены. Если у вас нет проектов на нескольких серверах, то это оптимальный, на мой взгляд, способ.
Можете посмотреть как это реализовано в популярных фрэймворках и вытащить этот функционал к себе на проекты… ну или можно самим написать по аналогии.
Вот тут описание, как это работает в yii.
Можете посмотреть как это реализовано в популярных фрэймворках и вытащить этот функционал к себе на проекты… ну или можно самим написать по аналогии.
Вот тут описание, как это работает в yii.
Вот подобный механизм для PHP Mysql schema Migrations with PHP
«стандартный» — это какой? (:
например, этот — github.com/davejkiger/mysql-php-migrations. Ему уже пару лет.
именно MPM послужил отправной точкой для MMP ( Mysql schema Migrations with PHP )
Автор не очень резво принимал мои патчи, и не очень хотел автоматизировать тулзу. Так и родился мой велосипед.
Автор не очень резво принимал мои патчи, и не очень хотел автоматизировать тулзу. Так и родился мой велосипед.
И соответственно наоборот, к каждому коммиту привязана задача
Т.е. на одну большую задачу вы предлагаете делать всего один коммит?
Т.е. на одну большую задачу вы предлагаете делать всего один коммит?
Стараюсь дробить большие задачи на маленькие.
Как написано в комментариях ниже, это не правильный подход. Коммит должен быть атомарным, но не обязательно, чтобы он закрывал задачу целиком, мне кажется это правило вносит только неудобство разработчикам. У нас обязательно принято, чтобы все коммиты были привязаны к задачам, но их может быть сколько угодно, в редмайне они хорошо выводятся, не мешает. Обычно их там получается 2-5.
- Первичный — web (там же все организационные вопросы)
- Подпроект 1 — iOs
- Подпроект 2 — Android
По-моему гораздо логичнее в качестве первичного создавать как раз общий проект, для орг. вопросов.
А конкретные технологии уже выносить в подпроекты, потому как
— что если вы решите использовать другую технологию вместо PHP? Тогда логика будет нарушена.
И я думаю что все файлы лучше прикреплять к вкладке «Files», в случае если возникнут какие-то вопросы, то те же первичные UI проще найти.
Это удобно для того чтобы новый разработчик мог просмотреть историю развития архитектуры и не задавал лишних вопросов/не предлагал идей, которые уже отмели и т.п.
ИМХО конечно.
Cтандартный процесс статусов задачи (М. — менеджер, П. — программист): М.Создана → П.В работе → П.Решена → М.Закрыта. (М. при необходимости менять на К — клиент)
а тестирование сюда почему не входит?
Прочитал ваш пост. Кроме этого вопроса habrahabr.ru/post/146231/#comment_4921212, у меня ещё куча других
а если скриптов много? а если миграция с разных версий базы?
автоматизированные тесты юзаете? если да, как и кто их пишет, когда запускаете?
а где анализ? где тестирование? где пересмотр требований? (и не говорите, что этого не бывает)
как вам удаётся распараллелить разработку и дизайн?
Программист создает в корне проект файл migration.sql в котором содержится инструкция к созданию БД.
а если скриптов много? а если миграция с разных версий базы?
Описание test-cases.
автоматизированные тесты юзаете? если да, как и кто их пишет, когда запускаете?
Алгоритм реализации проекта
а где анализ? где тестирование? где пересмотр требований? (и не говорите, что этого не бывает)
как вам удаётся распараллелить разработку и дизайн?
1. Я неправильно выразился, миграция в моем понимании — файл позволяющий воспроизвести рабочую структуру БД.
2. Автоматизированные скрипты не используем, надеюсь — это временно, постигаем эту науку.
3. Дизайн, только после прототипов, потому программист может начать без графики.
2. Автоматизированные скрипты не используем, надеюсь — это временно, постигаем эту науку.
3. Дизайн, только после прототипов, потому программист может начать без графики.
спасибо за ответ! и всё же, где у вас стадии анализа и тестирования?
Вам, спасибо за дельный комментарий и статью «про Мишу». Анализ проекта на этапе проработки интерфейсов взаимодействия, тестирование при каждой выполненной задаче\новой фиче. Или мы говорим о качестве кода: code review, refactor и.т.д.?
не, речь про бизнес-анализ. теперь более-менее ясно)
Много времени уделяется проработке проекта на старте, в среднем — две недели. Впрочем, мы строим машину, не космический корабль (ну вы поняли) — ценности или концепция могут меняться. Протипы получа.тся оцень приближенными к конечному результату, и содержат не только интерфейсы, но и комментарии для программистов\верстальщиков\дизайнеров.
Вы, вроде как, используете некоторые плюшки из agile, но некоторыми остальными вещами вы делаете процесс разработки не очень гибким. Например, в agile нет никаких Final PDF, Final ТЗ, Final Tasks, там финальная версия может быть только по истечении последнего спринта (до этого момента все может «гибко» измениться). С гитом тоже не все супер — идеологически неверно приравнивать коммит задаче. Иногда решение задачи может разбиваться на несколько веток, не говоря уже о коммитах. Ваше понятие непрерывной интеграции я вообще не понял :), но если у вас это прижилось, то вы хороший PM.
Судя по описанию рабочего процесса основные задачи у вас — установка и настройка wordpress/drupal/e-shop :)
— У нас в компании приняты 2-х недельные спринты.
Этапы работы вполне стандартны: Задача — В процессе — Готово для тестов — Тест в процессе — QA — Готово.
Естественно перед каждым спринтом — планирование, игра в SCRUM карты. После — ретроспектива.
Кроме этого по четвергам — bugfix day, каждый берет какой-либо маленький баг и фиксит его, создавая отдельную ветку. Затем создается пулл реквест и отправляется в основной репозиторий на code review. После прохождения code review пулл-реквест изменения сливаются в основную ветку и тестируются командой QA, если все в порядке — изменения одобряются и ждут релиза, если нет — делается revert пулл-реквеста.
Ну и конечно же ежедневные stand up митинги в формате: что делал вчера — что планирую делать сегодня
— У нас в компании приняты 2-х недельные спринты.
Этапы работы вполне стандартны: Задача — В процессе — Готово для тестов — Тест в процессе — QA — Готово.
Естественно перед каждым спринтом — планирование, игра в SCRUM карты. После — ретроспектива.
Кроме этого по четвергам — bugfix day, каждый берет какой-либо маленький баг и фиксит его, создавая отдельную ветку. Затем создается пулл реквест и отправляется в основной репозиторий на code review. После прохождения code review пулл-реквест изменения сливаются в основную ветку и тестируются командой QA, если все в порядке — изменения одобряются и ждут релиза, если нет — делается revert пулл-реквеста.
Ну и конечно же ежедневные stand up митинги в формате: что делал вчера — что планирую делать сегодня
А можете расписать, что происходит, если код не проходит code review. Интересует как организуется работа в системе контроля версий? Накатывается новый коммит на ветку с исправленным кодом?
Если code review не проходит, данные изменения не попадают в релиз. Есть неделя времени, чтобы все поправить и открыть новый пулл реквест.
Как у нас все это работает — разработчик мерджит master в свою ветку. Т.к. master содержит revert его изменений, не прошедших code review, необходимо сделать двойной revert, т.е. в логе смотрим какой коммит отменяет пулл-реквест, делаем revert этого коммита и получаем наш исходный код. Правим и отправляем очередной пулл-реквест.
Как у нас все это работает — разработчик мерджит master в свою ветку. Т.к. master содержит revert его изменений, не прошедших code review, необходимо сделать двойной revert, т.е. в логе смотрим какой коммит отменяет пулл-реквест, делаем revert этого коммита и получаем наш исходный код. Правим и отправляем очередной пулл-реквест.
Программист создает в корне проект файл migration.sql
Мы обычно пользуемся стандартными механизмами миграция или вручную, но в таком случае используется далеко на 1 файл, как написано у вас. Есть папка Sql, в которой находятся папки: insert, update, delete, create, alter. И в каждой файлы, название которого соответствует названию таблицы и в нем уже содержится ряд изменений.
У нас процесс несколько иначе построен, потому что там больше шагов. А именно:
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.
Уии! Качество :)
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.
Уии! Качество :)
Спасибо, у нас не практикуется code review, наверное это плохо. А вот у меня к вам такие вопросы:
1. судя по вашему описанию трудозатратность определяет менеджер, но он должен должен быть не просто спецом в технической части, но и погружен в проект не меньше чем программист?
2. что делаете если программист не уложился в отведенный срок?
3. есть ли у команды тех.лид, если есть какие задачи он выполняет?
4. есть ли ежедневные утренние совещения менеджер\программист?
5. Каким образом считается премия для програмиста?
6. Какие стандарты написания кода используете, есть ли они, как передаете новичкам?
7. Я так понимаю у вас не веб?)
Ваши ответы помогут мне стать лучше)
1. судя по вашему описанию трудозатратность определяет менеджер, но он должен должен быть не просто спецом в технической части, но и погружен в проект не меньше чем программист?
2. что делаете если программист не уложился в отведенный срок?
3. есть ли у команды тех.лид, если есть какие задачи он выполняет?
4. есть ли ежедневные утренние совещения менеджер\программист?
5. Каким образом считается премия для програмиста?
6. Какие стандарты написания кода используете, есть ли они, как передаете новичкам?
7. Я так понимаю у вас не веб?)
Ваши ответы помогут мне стать лучше)
У меня к вам есть пара вопросов.
1. Есть ли у вас приоритет задач на спринт? И делаете ли вы их по приоритету?
2. Если задача ушла на тестирование, в ней найден баг. Когда вы его фиксите?
3. Имеете ли вы в конце спринта готовый продукт в котором нет незаконченных задач?
4. Вы разрабатываете новый функционал в ветках или все коммитите в основную ветку?
5. Если в ветках, то как у вас осуществляется тестирование. Сначала ветки, потом мерджа?
6. Используете ли вы какой-то инструмент для депмлоймента?
7. Проводите ли вы стенд апы и насколько они эффективны?
8. Насколько эффективны ретроспективы и имеете ли вы от них какие-то плюсы? Приведите пару примеров, если есть.
1. Есть ли у вас приоритет задач на спринт? И делаете ли вы их по приоритету?
2. Если задача ушла на тестирование, в ней найден баг. Когда вы его фиксите?
3. Имеете ли вы в конце спринта готовый продукт в котором нет незаконченных задач?
4. Вы разрабатываете новый функционал в ветках или все коммитите в основную ветку?
5. Если в ветках, то как у вас осуществляется тестирование. Сначала ветки, потом мерджа?
6. Используете ли вы какой-то инструмент для депмлоймента?
7. Проводите ли вы стенд апы и насколько они эффективны?
8. Насколько эффективны ретроспективы и имеете ли вы от них какие-то плюсы? Приведите пару примеров, если есть.
Есть неплохая практика — список функций серверного API заносим в таблицу на гугл-докс и расшариваем на всех разработчиков.
Sign up to leave a comment.
Соглашение внутри команды