Как стать автором
Обновить
0
Карма
0
Рейтинг
Евгений Савицкий @devprom

Пользователь

  • Подписчики 2
  • Подписки 1

История двух нитей

я бы согласился, если бы речь шла о приеме на работу в research отделы ibm, sun, microsoft, etc, однако практик (инженер) должен знать правильные методы.

«Бегун» в гостях у PA AdLabs

Это как учиться в техническом вузе и завидовать тем, кто учится в пищевом ;)
Молодцы, мужики!

История двух нитей

Отвечать нужно по варианту №1 и не тратить собственное время и время интервьюера.

Песочная разработка

«Конечно, как это всегда бывает, функционал под конец был урезан, но не настолько, чтобы чья-то работа оказалась убрана из релиза.»

Как писал Кент Бек: «отрезайте себе по пальцу каждый раз, когда выкидываете из итерации запланированный функционал».

В вашем случае столь радикальных мер не требовалось, но в реальном мире придется, когда заказчик будет платить за функционал.

Вообще, урезание функционала под конец релиза — это совсем не всегда, но конечно бывает, посему нужно учиться правильно оценивать сроки и следить за ними в течение релиза.

PSD подарок

А сколько стоит такой дизайн, если заказывать?

Git Workflow

Вообще-то, не последняя практика использования svn это создание собственного бранча под разработчика/версию/фичу и т.п. с последующим мерджем в нужный/релизный бранч.

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

Git Workflow

«Плюс одна веточка на новую фишка» — насколько я понял преимущество git тут в том, что в конечный бранч мы можем надергать этих веточек (не все использовать) и оно автоматом вольется без необходимости мерджа? Крайне мало времени в проекте занимают такие изменения, если продукт уже относительно зрелый, то изменения — это слоеный пирог, вытащить нижний слой без проблем не получится (!)

«Не надо путать ветки в svn и ветки в git» — никто же не запрещает делать ветки в svn такими же короткими как в git, пусть у вас хоть на каждую фичу будет своя ветка, а потом сливайте нужные ветки (фичи) в один бран, если они действительно независимы, то мерджа не будет.

Git Workflow

«Плюсы такой системы очевидны! Вы получаете возможность колдовать с кодом как душе угодно, а не как диктует система контроля версий: разрабатывать параллельно несколько «фишек» в собственных веточках, исправлять баги, чтобы затем все это дело сливать в единую кашу главной ветки»

Вот-вот, организуется полнейший бардак. Сколько ни думал над революционностью Git, так и не понял ее. Линус, вобщем-то, так и говорит, что ничего нового, просто нет централизованного хранилища и действительно бенефиты только при сильно распределенных проектах.

Однако, как бы разработчики не колдовали, сколько бы сотен собственных бранчей не имели, чаще всего на выходе будет одна единственная ветка продукта, которая продается или передается заказчику. Иногда таких веток две или три, в случае поддержки нескольких версий продукта.

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

Не спешите уходить с централизованных репозиториев.

Какими системами управления проектами пользуетесь вы и почему?

> По сути все равно чем управлять.

Верно, однако суть в деталях.

> Главное уметь планировать и достигать целей.

Вопрос лишь в том, сколько сил придется потратить на это.

> В любом проекте.

Проект по строительству дома и проект по разработке ERP отличаются если не кардинально, то существенно и требуют соответствующих навыков.

> Какую систему Вы предлагаете посмотреть?

www.devprom.net

Какими системами управления проектами пользуетесь вы и почему?

Вопрос в том, что вам действительно нужно и что Вы понимаете под «управлением проектом». Если под проектом подразумевается разработка программного обеспечения, то посмотрите на эту систему. Пользуемся ею в нескольких проектах на протяжении более 2х лет, результат отличный.

Строители-фрилансеры получили «свою» Интернет-биржу

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

а) заказчикам
б) «прокладкам» — между заказчиками и исполнителями.

Так вот об этих «прокладках» — в их карманах оседает очень нехилый процент. Следовательно стоимость работ будет довольно высокой. Те исполнители, которые умееют и ищут заказы в инете, стоят совсем не дешево.

Вопрос в том, на какую аудиторию заказчиков и исполнителей вы ориентируетесь? Возле каждого строй-магазина таких фрилансеров хоть отбавляй.

Основная проблема во всей этой стройке: качество работ. Не делайте ошибку, не считайте что качество можно отразить в фотографии.

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

Самомаркетинг — «Портфолио» программиста

Не сочтите за рекламу, но наш сервис мы делали в том числе и для этого. Суть: оценить разработчика по выполненным проектам и показателям его эффективности. Заказчик сможет оценить уровень проекта, его ход и т.п. Разработчикам остается только разместить скриншоты и некоторое описание на странице проекта.

Что важнее — простота инструмента или безграничные возможности его настройки?

«если исполнитель или разгребатель багов видит, что это не ошибка — он трансформирует её в импрув и отправляет на согласование.» — а если это ошибка? что делать?

«желание самолично перепроверить отсутствие какой-либо ошибки — это не относится к её жизненному циклу.» — при профессиональном подходе в жизненном цикле ошибки есть стадия «проверки»/«приемки», как ее выполнять: через QA или заказчика — это дело конкретного проекта, но факта не убрать — жизненный цикл ошибки является частью жизненного цикла доработки.

Что важнее — простота инструмента или безграничные возможности его настройки?

тут скорее проблема несколько в ином:

1. на личном опыте убедился, сколько команд, столько и вариантов настройки процесса разработки. Гибкость в настройке workflow, заложенная в инструменте, является «дьявольским» искушением.

Вопрос настройки процесса далеко не праздный и когда им начинают заниматься команды, не достаточно погрузившиеся в детали процесса разработки, то настройка занимает массу времени (на одном из мест работы команда из 10 человек несколько дней по паре часов придумывала и каждый доказывал друг другу свое понимание как же должно быть).

Результат: состояния перемешиваются с переходами и резолюциями, появляется более 10 состояний дефекта (если о Jira), в которых без отдельного процессного документа и не разобраться, а при обычной текучке процесс просто перестает работать.

2. речь скорее не о простоте, а о фиксированности и упрощенности (до уровня необходимого), достаточной для постановки эффективного процесса.

Суть в том, что хорошо продуманный (но фиксированный) процесс гораздо лучше для массового использования, чем изначально не соответствующий действительности (в смысле Jira — это трэкер, а нужно управлять проектом), но настраиваемый неспециалистами.

Что важнее — простота инструмента или безграничные возможности его настройки?

позвольте не согласиться:

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

2. исправленная ошибка требует того, чтобы ее перепроверили QA, а часто и сам заказчик, поскольку коммуникационные шумы и невсеобъемлющее владение предметной области вносят свою погрешность в реализацию. Следовательно нужен и этап «сдачи» для ошибки.

Конфигурационный менеджмент (часть1, вступительная)

Парсить инсерты и сравнивать с содержимым БД? Неслабая затея :) А если нужно откатиться до определенной версии, ведь это должно обеспечиваться конфигурационным менеждментом?

Конфигурационный менеджмент (часть1, вступительная)

Отлично, но сразу хотелось бы отметить, что схема — это только половина проблемы. Зачастую поведение приложения определяется не столько схемой, сколько данными, если так можно выразиться, то управляющими данными.

Твиттер для поддержания пульса проекта

Несколько моментов:

1. все что назойливое, к тому сильно вырастает антипатия (пример, реклама где-либо), со временем это приведет к блокировки участника — он просто будет выключать телефон (или сменит номер :)

2. заставлять людей работать — можно разными способами, но в любом случае, если это не будет для них комфортно — результат будет не то что нулевой, а отрицательный. Если человек не занимается проектом, значит у него другие приоритеты и цели.

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

4. если у команды есть план, то пинать и навязываться через твиттер, чтобы ему следовать, это совершенно лишнее, либо менять план, либо менять команду.

Кстати, есть анлогичная методика в Scrum, она требует от каждого члена команды каждый день сообщать о том, что сделано вчера, что будет сделано сегодня и какие есть проблемы на текущий момент.

Однако, применяется она отнюдь не для «пинания», а для простой синхронизации команды (вместо ведения плана).

Конфигурационный менеджмент (часть1, вступительная)

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

Зачем нам это было нужно или очередной бесполезный ресурс?

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

Интернет-проект, как любой бизнес, характеризуется показателем возврата инвестиций. То что деньги у людей есть — факт (может они бандиты, но в Витебске видел Honda Legend). Вопрос в том, какую прибыльность Вы гарантируете. Если это > 50% в год, то у Вас отличный бизнес и желающих будет хоть отбавляй, поскольку в Беларуси не так много свободных нефтяных скважин.

Главный вопрос в том, чтобы понять прибыльность Вашего проекта. А для этого не нужно консульитроваться со специалистами. Просто составьте финансовый план хотя бы на несколько лет вперед.

Для этого Вам нужно довольно четко представлять как бизнес будет развиваться, расписать предполагаемые расходы, доходы, налоги. И вы сразу поймете: а) стоит ли вообще этим заниматься, б) где искать инвестора.

Информация

В рейтинге
Не участвует
Откуда
Россия
Дата рождения
Зарегистрирован
Активность