Комментарии 80
Описание работы супер! А теперь пусть кто нибудь расскажет как все работает на самом деле.
НЛО прилетело и опубликовало эту надпись здесь
Для feature-team (команды, которая занимается разработкой новой функциональности на сайте / доработкой старой) workflow соответствует тому, что написано в статье: вас не обманывают, всё действительно происходит именно так :).
Помимо feature-team существуют другие отделы: биллинг, антиспам, «платформа», backoffice. Каждый из этих отделов имеет свою специфику при разработке, и многие этапы могут пропускаться, например этап code review в нашей «админке» не является столь критичным, как для основной функциональности на сайте.
Я, к примеру, работаю в отделе «платформы», которая в основном занимается поддержанием и доработкой архитектуры сайта, а также выполняет массивный рефакторинг. Для наших задач workflow почти всегда отличается от описанного выше, поскольку те же задачи по рефакторингу нельзя деплоить, просто «замержив» задачу — нужно отдельное тестирование, аккуратная разработка и ручной контроль за происходящим на всех этапах работы.
Так что да, статья описывает workflow, который относится к команде, которая разрабатывает новую функциональность и они действительно ему следуют :).
Помимо feature-team существуют другие отделы: биллинг, антиспам, «платформа», backoffice. Каждый из этих отделов имеет свою специфику при разработке, и многие этапы могут пропускаться, например этап code review в нашей «админке» не является столь критичным, как для основной функциональности на сайте.
Я, к примеру, работаю в отделе «платформы», которая в основном занимается поддержанием и доработкой архитектуры сайта, а также выполняет массивный рефакторинг. Для наших задач workflow почти всегда отличается от описанного выше, поскольку те же задачи по рефакторингу нельзя деплоить, просто «замержив» задачу — нужно отдельное тестирование, аккуратная разработка и ручной контроль за происходящим на всех этапах работы.
Так что да, статья описывает workflow, который относится к команде, которая разрабатывает новую функциональность и они действительно ему следуют :).
Каждый разработчик выкладывает свой кусочек в продакшен, или есть несколько ответственных за сервис, и только они катят что-то в продакшен?
Как вообще процесс выкладки происходит? Вот есть новый билд (кстати, что это: набор php файлов, большой бинарь, пакет?), как он попадает на машины?
Как вообще процесс выкладки происходит? Вот есть новый билд (кстати, что это: набор php файлов, большой бинарь, пакет?), как он попадает на машины?
Каждая задача — ветка в гите. Билд — тоже ветка, куда мержатся задачи из всех веток, которые протестированы. Как только разработчик запушил ветку, и нажал «Готово» в таск-трекере, от него больше ничего не зависит. Как только тестировщики проверят задачу (читай — выгрузят к себе ветку и посмотрят, что все работает, и нажмет кнопку «Протестировано»), она автоматически будет смержена в ветку следующего билда и вместе с ним уедет на продакшен.
Как попадает на машины уже ответили чуть ниже, на эту тему был целый доклад addconf.ru/event.sdf/ru/add_3/authors/YuriyNasretdinov/786
youROCK, прошли те времена, когда «этап code review в нашей «админке» не являлся столь критичным, как для основной функциональности на сайте».
ммм… Подозреваю, что все делается очень и очень медленно. Это ж почти вотерфолл.
Летом плотно использовал продукт компании ) — классный, теперь доказали, что и разработка поставлена грамотно.
А как дела обстоят с client-side тестированием?
У нас тестировщики вручную всегда проверяют все задачи, прокликивают интерфейс, плюс активно пишутся селениум-тесты.
И формат кода не проверяется и автоматически не переформатируется, в отличии от PHP.
Артем, ты всех сдал.
Лучше расскажи про selenium. В какой момент пишутся тесты и на каком языке? Какой стек барузеров? Почему selenium, в конце концов? :]
P.S. А как собираете ошибки с клиента?
Лучше расскажи про selenium. В какой момент пишутся тесты и на каком языке? Какой стек барузеров? Почему selenium, в конце концов? :]
P.S. А как собираете ошибки с клиента?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Плюсы:
* Запуск из консоли;
* NodeJS;
* API (+ DOM API, CSS Selectors);
В идеале, можно запускать тесты и через Selenium, но это адова работа и пока её никто не сделал.
* Запуск из консоли;
* NodeJS;
* API (+ DOM API, CSS Selectors);
В идеале, можно запускать тесты и через Selenium, но это адова работа и пока её никто не сделал.
НЛО прилетело и опубликовало эту надпись здесь
Мы же говорим про автоматические тесты?
Делаем хук на комит и запуск тесты, всё просто и быстро, с селениум такое не возможно. Да и кто работал с селениумом прекрасно знает, насколько там всё медленно, тест может занять часы.
NodeJS записал в плюсы, т.к. с ним может работать и client-side разработчик.
Делаем хук на комит и запуск тесты, всё просто и быстро, с селениум такое не возможно. Да и кто работал с селениумом прекрасно знает, насколько там всё медленно, тест может занять часы.
NodeJS записал в плюсы, т.к. с ним может работать и client-side разработчик.
Но вы так и не ответили на вопрос «На каком языке и в какой момент пишутся тесты и кем?»
А так же, как мониторите ошибки на клиенте?
А так же, как мониторите ошибки на клиенте?
Позадаю немножко вопросов, если позволите ;-)
1. Сколько разработчиков, тестировщиков работают по этому процессу?
2. Сколько по времени занимает полный цикл подготовки релиза, с момента мерджа фич (раскладываете 2 раза в день, это я понял, а сколько билд маринуется на тестах)?
3. В релиз входят 1 модуль (подразумевается что весь фронт это 1 модуль) или может входить несколько (взаимозависимые изменения на фронте, в БД, бакенд серверах)?
4. Как/чем регресс и интеграционное тестирование делаете 2 раза в день?
5. Как/чем тестирование UI, особенно под несколькими браузерами?
6. Что делаете, если на этапе интеграционного тестирования находите ошибку (ведь за полдня ее можно не успеть пофиксить и перетестировать)?
1. Сколько разработчиков, тестировщиков работают по этому процессу?
2. Сколько по времени занимает полный цикл подготовки релиза, с момента мерджа фич (раскладываете 2 раза в день, это я понял, а сколько билд маринуется на тестах)?
3. В релиз входят 1 модуль (подразумевается что весь фронт это 1 модуль) или может входить несколько (взаимозависимые изменения на фронте, в БД, бакенд серверах)?
4. Как/чем регресс и интеграционное тестирование делаете 2 раза в день?
5. Как/чем тестирование UI, особенно под несколькими браузерами?
6. Что делаете, если на этапе интеграционного тестирования находите ошибку (ведь за полдня ее можно не успеть пофиксить и перетестировать)?
НЛО прилетело и опубликовало эту надпись здесь
1. Не могли бы вы сообщить приблизительное количество человек. Понятие «много» весьма растяжимо, тем более в сочетании с «но не все» ;-)
2. Не совсем понятно как билд (не таск) может мариноваться на тестах 2 месяца и при этом раскатываться 2 раза в день. как я понял из статьи, индивидуальные таски (которые разрабатывались долго и тестировались отдельно) интегрируются в билд. потом этот билд тестируется ( регресс + интеграция ). потом выкладывается. правильно ли я понимаю, что этап регрессионного тестирования и интеграционного занимает максимум полдня? или у вас есть какой то конвеер типа сегодня таски собрали в билд, тестируете день, потом выкладываете.
6. вариант «не проходит и доделывается», как я понял, возможен только если баги нашли на этапе тестирования отдельного таска. а если он уже собран в билд (бранч смерджен в мастер/staging, но еще билд не раскатан на прод), то есть была ошибка обнаружена на этапе интеграционного тестирования? все равно раскатываете и заводите баги и хотфиксы? или по дефолту откатываете коммит из гита? или ждете пока автор исправит?
2. Не совсем понятно как билд (не таск) может мариноваться на тестах 2 месяца и при этом раскатываться 2 раза в день. как я понял из статьи, индивидуальные таски (которые разрабатывались долго и тестировались отдельно) интегрируются в билд. потом этот билд тестируется ( регресс + интеграция ). потом выкладывается. правильно ли я понимаю, что этап регрессионного тестирования и интеграционного занимает максимум полдня? или у вас есть какой то конвеер типа сегодня таски собрали в билд, тестируете день, потом выкладываете.
6. вариант «не проходит и доделывается», как я понял, возможен только если баги нашли на этапе тестирования отдельного таска. а если он уже собран в билд (бранч смерджен в мастер/staging, но еще билд не раскатан на прод), то есть была ошибка обнаружена на этапе интеграционного тестирования? все равно раскатываете и заводите баги и хотфиксы? или по дефолту откатываете коммит из гита? или ждете пока автор исправит?
НЛО прилетело и опубликовало эту надпись здесь
Ветка билда на завтра создается сегодня, и сегодня же туда начинают домерживаться протестированные задачи до определенного часа. Если какая-то задача уже смерженная в билд не работает и быстрым фиксом никак не поправить, ее откатывают из билда (раньше git revert, сейчас как-то хитрее, т.к. реверт добавляет проблем впоследствии), либо просто собирают билд заного без этой задачи (создается ветка от мастера и туда заного мержатся задачи).
Для патчей в билд у нас сделан специальный интерфейс, в который достаточно отправить diff правок, после чего они будут просмотрены и закомичены прямо в билд релиз-инженером.
Для патчей в билд у нас сделан специальный интерфейс, в который достаточно отправить diff правок, после чего они будут просмотрены и закомичены прямо в билд релиз-инженером.
6. зависит от важности задачи и сложности исправления бага. Можем подождать фикс, а можем и выкинуть задачу из деплоя.
6. Сейчас мы «вымерживаем» проблемные задачи из билда с помощью git rebase в полуавтоматическом режиме. При этом, мы тупо создаем новую ветку, в которой есть все коммиты, кроме указанного. Это одна из причин, почему создавать ветки прямо из билда у нас запрещено.
Спасибо, очень интересно!
Очень хочется услышать ответы на следующие вопросы:
1. Чем не угодил phpcs? Почему используете свою утилиту?
Кстати, насколько codestyle в Вашей компании отличается от PSR*?
2. gitphp — гуй некрасивый и неудобный.
Что, кроме исторического наследия или паранои, мешает использовать гитхаб или битбукет?
И, кстати, Ваша компания существует уже не первый год, как так Вы перебрались на гит? Реквестирую статью!
3. Очень интересен процесс автоматизации построения тегов(наверное) для деплоя.
Это как раз очень хороший кейс, который ни в одной из известных мне компаний не автоматизирован.
Получается надо запускать тесты после каждого коммита(нереально с большим кол-вом тестов), и если тесты прошли, подливать в тег билда.
Раскройте плз подробнее этот процесс.
4. Как происходит деплой? Капистрано-стайл? Его используете или что-то свое? Почему?
Очень хочется услышать ответы на следующие вопросы:
1. Чем не угодил phpcs? Почему используете свою утилиту?
Кстати, насколько codestyle в Вашей компании отличается от PSR*?
2. gitphp — гуй некрасивый и неудобный.
Что, кроме исторического наследия или паранои, мешает использовать гитхаб или битбукет?
И, кстати, Ваша компания существует уже не первый год, как так Вы перебрались на гит? Реквестирую статью!
3. Очень интересен процесс автоматизации построения тегов(наверное) для деплоя.
Это как раз очень хороший кейс, который ни в одной из известных мне компаний не автоматизирован.
Получается надо запускать тесты после каждого коммита(нереально с большим кол-вом тестов), и если тесты прошли, подливать в тег билда.
Раскройте плз подробнее этот процесс.
4. Как происходит деплой? Капистрано-стайл? Его используете или что-то свое? Почему?
1. На сколько я знаю, phpcs умеет только указывать на ошибки в код-стайле, но не умеет сам их форматировать. Когда мы вводили четкий стандарт кодирования, обязательным условием было наличие утилиты, которая бы сама умела правильно форматировать код. Иначе это была бы ужасная пытка для разработчиков. Более того, наша утилита проверяет и форматирует только тот код, который был затронут в коммите.
2. Он быстрый, простой и его не так сложно допиливать под свои нужды. Нам он нужен в первую очередь, чтобы смотреть дифф ветки и оставлять комментарии к строкам. Мы пробовали более тяжелые решения, например, FishEye но его так и не получилось по-нормальному внедрить, плюс он достаточно долго работал на нашем репозитории.
В кратце, раньше у нас был svn, потом поставили git-svn, а потом по-командно перевелись на git. До сих пор у нас еще осталось несколько репозиториев на svn, которые по-тихоньку переводим на git.
2. Он быстрый, простой и его не так сложно допиливать под свои нужды. Нам он нужен в первую очередь, чтобы смотреть дифф ветки и оставлять комментарии к строкам. Мы пробовали более тяжелые решения, например, FishEye но его так и не получилось по-нормальному внедрить, плюс он достаточно долго работал на нашем репозитории.
В кратце, раньше у нас был svn, потом поставили git-svn, а потом по-командно перевелись на git. До сих пор у нас еще осталось несколько репозиториев на svn, которые по-тихоньку переводим на git.
про деплой у нас был доклад на одной из конференций: addconf.ru/event.sdf/ru/add_3/authors/YuriyNasretdinov/786
1. phpcs всем хорош, вот только форматировать не умеет, к сожалению. Думали о том, чтобы научить, но там нужно очень много переделывать. Мы думали (и думаем) о том, чтобы использовать и phpcf и phpcs вместе, ибо phpcf умеет проверять и исправлять пробельные символы + совсем простенькие преобразования.
Наш код-стайл почти не отличается от PSR-1, есть совсем минорные отличия, связанные со спецификой и legacy именно нашего кода.
2. no comments…
3. У нас нет тегов для деплоя, используется просто ветка. При любых изменениях в этой ветке в teamcity прогоняются автотесты. При этом «стабильная» и production ветка — это всегда master
4. Деплой был изначально сделан своими силами (в тот момент особо ничего интересного не было). Не так давно дорабатывался для использования UFTP для заливки файлов и нашей библиотечки libpssh для легкого и удобного коннекта по SSH к нашим сотням сервачков.
Наш код-стайл почти не отличается от PSR-1, есть совсем минорные отличия, связанные со спецификой и legacy именно нашего кода.
2. no comments…
3. У нас нет тегов для деплоя, используется просто ветка. При любых изменениях в этой ветке в teamcity прогоняются автотесты. При этом «стабильная» и production ветка — это всегда master
4. Деплой был изначально сделан своими силами (в тот момент особо ничего интересного не было). Не так давно дорабатывался для использования UFTP для заливки файлов и нашей библиотечки libpssh для легкого и удобного коннекта по SSH к нашим сотням сервачков.
3. Смотрели и github, и gitlab, и прочие аналоги, они плохо ложатся на наш флоу разработки, для их нормального использования пришлось бы подгонять процесс под инструмент, что в корне неправильно. Общая закрытость и трудность допиливания под свои нужды также играет роль.
НЛО прилетело и опубликовало эту надпись здесь
Причем здесь картинки ракет? Или вы сравниваете свой «производственный цикл» с таковым циклом в космической отрасли? Просто смешное сравнение. Крохотные команды разработчиков — просто ерунда по сравнению с производством ракеты. Посмотрел бы я, как у вас все бы было «гладко» в реально крупном проекте.
Хм… Вы точно уверены что баду маленький проект?
Немаленький. Но по сравнению с ракетно-космической отраслью — просто детский садик.
НЛО прилетело и опубликовало эту надпись здесь
в чем-то вы правы.
Я думаю, картинками ракет автор хотел создать аллюзию на «Rocket science»: anything overly complex, detailed or confusing (http://en.wiktionary.org/wiki/rocket_science)
Менеджер команды не становится уским звеном? Как часто задачи возвращают на доработку требований?
С моего опыта наличие нескольких Product manager (или product owner в гибких методологиях) и команд которые формируются под задачу очень эфективный процес. Они помогают перевости требования с «птичего языка» и нечётких требований аля «кнопка „сделать круто“» в требования понятные команде разработчиков с минимальным отвлечением сотрудников заинтересованых отделов. У вашей модели заложено потенциальное бутылочное горлышко в виде менеджера который распределяет работу, а также проблема слиском большого количества заинтересованых лиц. Когда нет авторитетного лица которое «над схваткой» и его решение «в последней инстанции» очень сложно удержатся от постоянного разрастания требований к разработываемым фичам.
Насчёт git, какие недостатки не дали исспользовать GitHub for Enterprise или Attlasian Crucible если хочется большей формализации, потому что code review наверное не та ключевая деятельность которой стоит заниматся, если вы не разработчик систем code review?
С моего опыта наличие нескольких Product manager (или product owner в гибких методологиях) и команд которые формируются под задачу очень эфективный процес. Они помогают перевости требования с «птичего языка» и нечётких требований аля «кнопка „сделать круто“» в требования понятные команде разработчиков с минимальным отвлечением сотрудников заинтересованых отделов. У вашей модели заложено потенциальное бутылочное горлышко в виде менеджера который распределяет работу, а также проблема слиском большого количества заинтересованых лиц. Когда нет авторитетного лица которое «над схваткой» и его решение «в последней инстанции» очень сложно удержатся от постоянного разрастания требований к разработываемым фичам.
Насчёт git, какие недостатки не дали исспользовать GitHub for Enterprise или Attlasian Crucible если хочется большей формализации, потому что code review наверное не та ключевая деятельность которой стоит заниматся, если вы не разработчик систем code review?
Менеджер проектов, как у нас любят говорить, работает в основном со списками и осуществляет первичную приемку задач. Дальше уже задачу целиком ведет разработчик, а менеджер следит за ее статусом и сроками. Зачастую задачу сразу можно отнести к тому или иному компоненту, поэтому она достаточно быстро минует менеджера проектов и попадает в пул задач соответствующей группы разработчиков. Когда разработчик берет задачу, если там что-то не понятно, то он сам все уточняет у продуктового менеджера. Отсюда бутылочного горлышка в виде менеджера не создается, но возрастает ответственность разработчика, которому приходится самостоятельно переводить с «птичьего». Конечно, при необходимости менеджер разруливает спорные вопросы и разрастания требований. К примеру, если product team очень хочет внести какие-то существенные изменения, мы можем запланировать вторую итерацию для этого проекта.
Fisheye и Crucible с огромным скрипом работают с большими и частообновляемыми git -репозиториями. По нашему опыту задержка с индексацией пришедших изменений может легко достигать 1-2 часов, что делает невозможным быстрый code-review только что сделанного тикета.
Общение с атлассианавцами в попытках решить эти проблемы ни к чему ни привело.
Было бы интересно узнать про опыт работы с этими инструментами в других крупных проектах.
Про GitHub for Enterprise описал выше.
Решение на базе gitphp, которое было сделано за пару недель и теперь активно развивается и допиливается именно под наши нужды, работает быстро и четко. Тем более что заинтегрировать его с JIRA через стандартный API не представляет никаких проблем.
Общение с атлассианавцами в попытках решить эти проблемы ни к чему ни привело.
Было бы интересно узнать про опыт работы с этими инструментами в других крупных проектах.
Про GitHub for Enterprise описал выше.
Решение на базе gitphp, которое было сделано за пару недель и теперь активно развивается и допиливается именно под наши нужды, работает быстро и четко. Тем более что заинтегрировать его с JIRA через стандартный API не представляет никаких проблем.
Такое ощущение, что коментаторы в основном пытаются придраться к чему-нибудь из зависти. Да, ребята, так работают в солидных ИТ компаниях.
Очень интересно! Спасибо за такой подробный рассказ. Не могли бы вы также ответить на пару вопросов?
1. Какие фишки Jira'ы вы используете? Например, версионирование и билды, интеграция с CVS, интеграция с Confluence, интеграция с FishEye,…
2. Как вы используете Confluence — постятся ли там релиз ноутсы, what's new, какие-нибудь known issues и т.д?
3. Используете ли вы CI с запуском тестов на нем?
1. Какие фишки Jira'ы вы используете? Например, версионирование и билды, интеграция с CVS, интеграция с Confluence, интеграция с FishEye,…
2. Как вы используете Confluence — постятся ли там релиз ноутсы, what's new, какие-нибудь known issues и т.д?
3. Используете ли вы CI с запуском тестов на нем?
И еще немного:
4. Как у вас ведется девелоперская документация, типа функциональной спецификации, требований к функционалу, описания архитектуры и т.д.? Как вы ее храните, когда и чьими силами обновляете?
5. Участвуют ли QA в подготовке функциональных и юнит-тестов, их валидации?
4. Как у вас ведется девелоперская документация, типа функциональной спецификации, требований к функционалу, описания архитектуры и т.д.? Как вы ее храните, когда и чьими силами обновляете?
5. Участвуют ли QA в подготовке функциональных и юнит-тестов, их валидации?
1. API
3. TeamCity
5. Участвуют
Возможно в ближайшее время кто-то раскроет некоторые из деталей непрерывной интеграции здесь или на одной из конференций.
3. TeamCity
5. Участвуют
Возможно в ближайшее время кто-то раскроет некоторые из деталей непрерывной интеграции здесь или на одной из конференций.
Круто, спасибо! А про API можно немного подробнее? Что вы с ним делаете — получаете какие-то данные (отчетность, например), либо отправляете POST-запросы (например, для автоматического создания тикетов)?
Например… TeamCity пишет в JIRA о пройденных тестах.
В настоящий момент больше можно узнать из предыдущей статьи — AIDA. Автоматизация работы с Git, JIRA и TeamCity.
В настоящий момент больше можно узнать из предыдущей статьи — AIDA. Автоматизация работы с Git, JIRA и TeamCity.
1. Вот так ещё например
Для осуществления ревью мы доработали утилиту gitphp (www.gitphp.org/) так, что в ней стало возможно просматривать общий diff ветки, оставлять комментарии к коду, которые впоследствии отправляются единым комментарием к задаче в JIRA
2. В Confluence у нас хранится документация и подготавливаются PRD по функционалу со стороны Product Team. Описания обновлений у нас рассылаются в maillist при каждом деплое, обновлении версий мобильных приложений и раз в неделю рассылается сводка по всем отделам.
А как у вас происходит обновление схемы в базе?
Простые и быстрые правки делают разработчики самостоятельно. Если надо обновить сотню баз, такие альтеры осуществляет отдел системного администрирования в низах трафика. Самое частое обновление схемы — это добавление новых полей, поэтому никаких проблем не возникает.
Если нужно изменить существующие поля:
1. пишут код совместимый со старой и новой схемой работы, релизят его
2. вносят правки в базы
3. оставляют код, работающий по новой схеме
Если нужно изменить существующие поля:
1. пишут код совместимый со старой и новой схемой работы, релизят его
2. вносят правки в базы
3. оставляют код, работающий по новой схеме
То есть скрипты миграции не пишутся и все прямо руками? Или вы просто имеете в виду, что скрипты запускаются самим разработчиком?
Специфика такая, что править базу приходится достаточно редко, поэтому у нас нет большой необходимости в скриптах миграции. Небольшие изменения вносятся руками прямо в консоли mysql. Когда надо очень много таблиц обновить (к примеру таблицы, по которым шардятся пользователи, их тысячи), то тут конечно системный администратор запускает скрипт, который обходит базы и выполняет sql запрос.
Для добавления нового поля вы отключаете по одному серверу БД, накатываете изменения и включаете? А потом когда на все сервера накатились изменения выкладываете код, которому нужны эти поля, так?
Нет, мы ничего не отключаем (возможно только для обновления ПО). Просто подбирается время, когда низкий трафик, чтобы не создавать проблем пользователям и выполняется альтер. Когда на все сервера накатились изменения, то да, мы выкладываем код, который их использует.
Логично, т.е. получается когда накатывается альтер, то запросы ждут пока снимется блокировка с таблицы. Процент timeout`ов будет крайне низкий из-за маленького трафика.
Тут ещё интересный момент, что «низ трафика» это всё равно порядочная нагрузка, поэтому без дополнительных действий оно работать скорее всего не будет. У нас в добавок к этому используется очень «мелкий» шардинг: на каждом сервере по несколько схем, в каждой схеме порядка 5000 таблиц, примерно по одной на 1000 пользователей. Это позволяет избежать длительных блокировок при запросах, даже если сам альтер «тяжелый».
Неужели у вас бывает низкий трафик? :)
А действительно, вы же работаете по всему миру, и из-за часовых поясов активность в течение дня должна быть примерно одинакова. Или это не так?
А действительно, вы же работаете по всему миру, и из-за часовых поясов активность в течение дня должна быть примерно одинакова. Или это не так?
Почему TeamCity, а не atlassian's bamboo?
У меня вопрос — действительно ли полное ТЗ по задаче у вас формируется примерно так:
Рисуется, верстается, менеджер проекта или направления сам или с помощью тех. писателя пишет полное исчерпывающее ТЗ.
Все вопросы от программистов решаются в рамках комментариев в задаче — т.е. разработчик спрашивает, ему там отвечают и ничего не остается не задокументированным?
Рисуется, верстается, менеджер проекта или направления сам или с помощью тех. писателя пишет полное исчерпывающее ТЗ.
Все вопросы от программистов решаются в рамках комментариев в задаче — т.е. разработчик спрашивает, ему там отвечают и ничего не остается не задокументированным?
Полного ТЗ у нас не бывает, есть именно продуктовый документ, в комментариях к которому действительно много чего может обсуждаться. Если в процессе разработки мне что-то не понятно, я могу позвонить менеджеру и уточнить вопрос, а в комментарии к тикету дописать «договорились с менеджером, что полоски будут синего цвета», чтобы избежать вопросов от тестировщиков.
Как функционал работает с технической точки зрения, этот документ может описывать, но очень поверхностно. Обычно мы пишем такую документацию постфактум на особо сложные участки системы.
Как функционал работает с технической точки зрения, этот документ может описывать, но очень поверхностно. Обычно мы пишем такую документацию постфактум на особо сложные участки системы.
Александр, вы описали процесс работы одной команды над одной фичей. Интересно, как строится процесс, когда фича требует какого-то функионала на фронте, функционала в админке и, допустим, каких-либо изменений в биллинге, то есть поучаствовать в фиче (или проекте) должны три команды разработки, при этом релиз их частей должен быть синхронизирован по времени.
Получается, что в процессе участвут менеджер продукта, который «сгенерил идею» и подготовил PRD, и три менеджера проектов по одному из каждой команды разработки? Как строится дальнейший процесс? Кто им управляет и как синхронизирует между собой разные команды разработки для того, чтобы весь проект попал в продакшен в срок и в полном объеме (все три части)?
Получается, что в процессе участвут менеджер продукта, который «сгенерил идею» и подготовил PRD, и три менеджера проектов по одному из каждой команды разработки? Как строится дальнейший процесс? Кто им управляет и как синхронизирует между собой разные команды разработки для того, чтобы весь проект попал в продакшен в срок и в полном объеме (все три части)?
Всю задачу от начала и до конца ведет один php-программист. Допустим, мне пришла задача, в ней PRD с макетами. Я сразу ставлю задачу в пул команды Frontend, ссылаясь на родительскую задачу. Если нужен биллинг, к примеру, это промо акция и при переходе по ссылке мне надо начислить 100 кредитов, я договариваюсь с человеком из биллинга, который отвечает за промо-акции и ставлю на него подзадачу. Если я не знаю, кто среди них может мне помочь, тогда я обращаюсь к менеджеру.
Когда я ставлю задачу на верстку макетов и на заведение новой промо-акции, я всем говорю одну ветку в git, в которой необходимо вести разработку. То есть синхронизировать ничего не надо, я лишь дожидаюсь пока будут сделаны подзадачи, параллельно подготавливая свою часть. Далее я свожу все вместе, проверяю и отправляю на тестирование.
Когда я ставлю задачу на верстку макетов и на заведение новой промо-акции, я всем говорю одну ветку в git, в которой необходимо вести разработку. То есть синхронизировать ничего не надо, я лишь дожидаюсь пока будут сделаны подзадачи, параллельно подготавливая свою часть. Далее я свожу все вместе, проверяю и отправляю на тестирование.
И еще, если возможно, расскажите чуть подробнее про то, что включает в себя «идеальный» PRD.
У вас в списке городов в Таиланде нет Паттайи. Это странно. Пытался дать знать поддержке сайта, но никаких контактов тоже не нашел.
А что такое «Features team» и кто такие «менеджеры проекта» из этого «Features team»?
И еще такой вопрос. Помимо веб-клиента есть еще мобильные приложения. На этапе проектирования продумывается реализация фичи сразу везде (сайт, мобильные клиенты)? На этапе разработки — новые фичи запиливаются одновременно во всех клиентах? Или сначала фича может быть поддержана и зарелизена только на сайте, а когда-то потом — в iOS- и Android-приложениях?
И еще такой вопрос. Помимо веб-клиента есть еще мобильные приложения. На этапе проектирования продумывается реализация фичи сразу везде (сайт, мобильные клиенты)? На этапе разработки — новые фичи запиливаются одновременно во всех клиентах? Или сначала фича может быть поддержана и зарелизена только на сайте, а когда-то потом — в iOS- и Android-приложениях?
Ребят, вы не упомянули главное действующее лицо в процессе. Это пользователь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Процесс разработки в Badoo