Я понимаю, что есть люди, которые предпочитают такой режим, и в нем работают вполне успешно. Но на мой взгляд, когда речь идёт о большом проекте, где работает команда из большого количества людей, и кроме такой команды есть ещё другие команды и им надо синхронизироваться и так далее, то это бывает очень полезным и важным. Скрам — это не лекарство от всех бед, есть много методологий и они работают не хуже. Просто если процесс поставлен правильно, то обычно понятно, зачем в данном случае используется такая методология итеративная.
Одна из важных причин, почему так же используется Скрам — это прогноз и оценка, планирование. Я понимаю, что такие вещи могут не интересовать простого разработчика, но с точки зрения продукта — это важно, потому что это деньги. Чем более точное планирование, тем больше денег сохранит бизнес (в общем случаеъ есть много специфики от области бизнеса). Например, если разработка ведётся итерациями и все это мониторится, собираются метрики, то спустя какое-то время можно сказать, на какой капасити команда может 100% отрабатывать, и вы будете удивлены, на сколько точно такие «предсказания» работают. Но это при условии корректной интерпретации и применения методологии. Если коверкать понимание методологии, то лучше делать без неё. У меня есть опыт работы в компаниях, где использовали скрам, потому что надо бы, и от этого процесс страдал. И наоборот, работал там, где процесс поставлен грамотно, и разница видна очень сильно.
Я не призываю использовать скрам. Потому что он не всегда подходит, есть много причин его не использовать, в зависимости от многих факторов. Но нередко правильное применение скрама наводит правильный порядок и упрощает разработку продукта.
Вам ведь никто не запрещает за пределами ежедневного скрама общаться по разным вещам. 15 минутами не ограничивается общение, это подразумевает, что у вас есть 15 минут на команду, чтобы рассказать статусы с точки зрения общей перспективы текущего спринт. То есть можно заострить внимание на какие-то важные проблемы, но самое важное, держать в курсе всех не о том, какой код и комиты вы делаете, а что с точки зрения прогресса по задаче вы сделали, и как это влияет на прогресс в спринте.
Мне кажется, что статья немного странно написана, но на самом деле парное программирование довольно занятная вещь. Я ее довольно часто практикую на работе, когда есть какая-то сложная задача и вдвоём ее решить получается гораздо быстрее. Еще иногда практикуем парное программирование в open source проектах. На самом деле это позволяет получить некоторый прирост скорости и что самое главное, обычно это влияет на качество кода в хорошую сторону. Меньше code smells допускаешь, так как сразу происходит и ревью кода. Но не всегда парное программирование уместно. ИМХО. Есть кейсы, когда правда лучше закопаться самому.
Еще из CI могу добавить codeship. Неплохой CI tool тоже, легко прикручивается. Из ограничений — для опен сорс проектов нельзя параллелить тесты, так что все последовательно. Но в целом мне нравится, работает неплохо. Но я обязательно поковыряю другие, например, travis (UI у него классный)
Я обычно предпочитаю делать прототипирование на бумаге, если просят писать код. Вообще не парюсь по синтаксису. Нарисую алгоритм, примерный прототип обрисую, напишу что-то абстрактно. А потом уже пишу что-то подробнее по возможности. В целом, сколько раз код просили писать, мы всегда сначала обсуждали «Вы хотите, чтобы я написал все четко по синтаксису, или я могу просто архитектуру и прототип?» Всегда говорили «да, конечно, синтаксис не обязателен, мы на него не смотрим». И все адекватно обсуждалось, дописывался код, добавлялись идеи. Даже целые классы выписывал.
Кроме того на листке можно еще обрисовать схематично какие-то процессы, какие-то алгоритмы, объяснить что-то, что лежит в голове и не так просто словами разъяснить. В общем, я за листки и бумагу (все равно на чем писать, но доска чуть удобнее, но зато на бумаге ты сидишь сразу рядом с интервьюверами и вы всё обсуждаете, находясь на удобном расстоянии для коммуникации. а не как ведущий перезентации для всего рума вещаешь)
Участвовал в двух проектах со спарком как-то. В целом не было проблемой поискать в гугле. Просто запросы писал поподробнее. На самом деле искать что-то по нему вполне можно)
На столько притянутая статья, что просто слов нет. Я скорее не пойду в компанию, где так не говорят, а заменяют все слова на русский. Бэкграунд и опыт — окей, тут можно. Soft skills. Что не так с этим? Это используется, это абсолютно понятно. Scrum, Kanban, Big Data, кейсы, что в этом такого? Да, «случаи» вместо кейсов можно.
«Чекните кусочек кода и сделайте пропоузал по его улучшению» — никто так не говорит. Притянуто. Сколько раз был на собеседованиях, абсолютно нормально просили провести анализ кода.
Митинги. Вам не кажется, что это просто очень сильно притянуто? В России вообще это слово означает все, что угодно, кроме «встречи». Митинг — это встреча по какой-то цели, а не ходьба с транспарантами. И это абсолютно нормальный «слэнг».
Я видел компании, в которых такого всего нет, и я оттуда убегал.
Кроме того, работая постоянно с иностранным заказчиком иногда сложно не говорить «заапрувнуть пр», «заасайнить таску» и т.д., потому что привык использовать иностранные термины. Но проблема в том, что большая часть при переводе звучит невероятно тупо/глупо/вне контекста.
Тема интересная. Но я хочу сказать, что это только первые версии, скажем так, поэтому пока они предоставляют довольно ограниченную возможность кастомизации, и какие-то технические недостатки. Я думаю, что, если эту платформу развивать, то можно придумать классные решения. Что-нибудь типа модульного стола, на котором ты можешь модули двигать, как тебе удобно (типа сот, или что-то вроде того). Модуль беспроводной докстанции, модуль подогрева стакана, модуль подставки для ноутбука, мониторов и т.д. И можно потом на этих модулях делать бизнес — продавать компоненты для стола :) Я бы от такого не отказался)
Одна из важных причин, почему так же используется Скрам — это прогноз и оценка, планирование. Я понимаю, что такие вещи могут не интересовать простого разработчика, но с точки зрения продукта — это важно, потому что это деньги. Чем более точное планирование, тем больше денег сохранит бизнес (в общем случаеъ есть много специфики от области бизнеса). Например, если разработка ведётся итерациями и все это мониторится, собираются метрики, то спустя какое-то время можно сказать, на какой капасити команда может 100% отрабатывать, и вы будете удивлены, на сколько точно такие «предсказания» работают. Но это при условии корректной интерпретации и применения методологии. Если коверкать понимание методологии, то лучше делать без неё. У меня есть опыт работы в компаниях, где использовали скрам, потому что надо бы, и от этого процесс страдал. И наоборот, работал там, где процесс поставлен грамотно, и разница видна очень сильно.
Я не призываю использовать скрам. Потому что он не всегда подходит, есть много причин его не использовать, в зависимости от многих факторов. Но нередко правильное применение скрама наводит правильный порядок и упрощает разработку продукта.
Кроме того на листке можно еще обрисовать схематично какие-то процессы, какие-то алгоритмы, объяснить что-то, что лежит в голове и не так просто словами разъяснить. В общем, я за листки и бумагу (все равно на чем писать, но доска чуть удобнее, но зато на бумаге ты сидишь сразу рядом с интервьюверами и вы всё обсуждаете, находясь на удобном расстоянии для коммуникации. а не как ведущий перезентации для всего рума вещаешь)
«Чекните кусочек кода и сделайте пропоузал по его улучшению» — никто так не говорит. Притянуто. Сколько раз был на собеседованиях, абсолютно нормально просили провести анализ кода.
Митинги. Вам не кажется, что это просто очень сильно притянуто? В России вообще это слово означает все, что угодно, кроме «встречи». Митинг — это встреча по какой-то цели, а не ходьба с транспарантами. И это абсолютно нормальный «слэнг».
Я видел компании, в которых такого всего нет, и я оттуда убегал.
Кроме того, работая постоянно с иностранным заказчиком иногда сложно не говорить «заапрувнуть пр», «заасайнить таску» и т.д., потому что привык использовать иностранные термины. Но проблема в том, что большая часть при переводе звучит невероятно тупо/глупо/вне контекста.