Могу добавить про Австралию. У нас Telstra блокирует rutracker. Приходится включать VPN в Австралию же чтобы открыть сайт. Сами торренты качаются без проблем и с выключенным VPN
Я не знаю. Я знаю точно, что это аджайл процесс, когда команда сама себя и свои процессы перестраивает. Началось все с типичного scrum, а сейчас это что-то канбаноподобное — у нас спринтов больше нет, это, как мне кажется, кстати, влияние работы из дома в течении 4-х месяцев.
Я еще раз повторюсь, что я думаю, что как раз четко следовать скраму не обязательно, были тут разговоры из серии «это не настоящий скрам» — это не про то, я думаю, имелось в виду просто соблюдение некоторых базовых принципов, сама форма не так уж важна, какова длина спринта или какие встречи проходят в течении спринта.
Просто скрам дает некоторую рамку, некий шаблон, с которого можно начать. А главная идея этого шаблона — быстрая обратная связь и возможность изменения ритуалов и процессов команды.
А дальше все зависит от команды и их доверия к друг другу, могут устроить карго-культ, а могут и создать cohesive коллектив, который не нужно будет особенно микроменеджить. People management никто не отменял, собственно, мне кажется, одна из важнейших черт аджайла — это опора на людей, которые смелы и которые связываются друг с другом сами, порождая инновации и качество.
То есть на остальные примеры и логику, которые я привел, вы отвечать не будете, а спрыгнете сразу на Австралию и как там из атомной отрасли бегут ученые, потому что денег в них не вкладывают :) Мне кажется это вы все время уходите от предмета дискуссии, которую сами же начали, а именно про общее состояние науки в России.
Давайте же окончим ее и займемся какими-то более полезными вещами.
На мой взгляд, маленькие итерации, прежде всего — это быстрая обратная связь, а не предсказуемость, возможность заметить отличие воображаемого идеального состояния проекта от его реальных показателей. Тут планировали сделать эту фичу за неделю, а чувак пыхтит уже две недели и явно пока еще не прорвался, что-то тут не так, давайте перепланируем и или отменим пару других запланированных эпиков и ему кинем парней на помощь или в принципе все норм, справится сам, скажем аналитикам, что этот A/B эксперимент будет запущен позднее.
Это позволяет управлять скоупом и ожиданиями продуктовой команды. А предсказуемость обычно задается как раз опытом самих разработчиков и их желанием быть профессиональными. Поскольку особо формальных требований и показателей нет, люди стараются сами определить скоуп (обычно на эпик выделяется микро-команда, выбирается разработчик, ответственный за эпик), договорится со всеми участника процесса и пытаться всех держать в курсе хода проекта и поднимать красный флаг, если где-то что-то поменялось.
Мне кажется, предсказуемость тут больше в постоянных пересмотрах и рефлексии на событиях, которые поддерживаются на уровне ритуалов (ретро и просто люди иногда темы поднимают). На моей памяти за эти почти 4 года в команде, процесс у нас поменялся с десяток раз.
Например, сначала было еженедельное планирование, когда оба офиса собирались все вместе онлайн через большой экран и обсждали состояние эпиков, сколько осталось, что новое добавляется, обычно эпик оунер рассказывал по каждому эпику. Потом в какй-то момент вылезло наружу, что народу что-то не нравится, а именно, что выходит, что мы просто отчитываемся перед менеджментом, никакое это не планирование, менеджмент может и почитать в джире и сам спланировать, а нам время не маза тратить.
Коллега-программист предложил эксперимент — а давайте вообще выкинем этот митинг и посмотрим, как нам без него. Попрессовали продакт команду, договорились с ними, что эпик оунер будет просто писатьв специальный слэк канал отчет по специальной форме — типа что сделали, что будем делать, сколько всего осталось делать. А митинг отменим нафиг.
Ну после трех недель собрались обсудить вместо планирования — как перемена. И программисты и менежеры согласились, что не хватает форума, где можно послушать, что поменялось, и задать вопросы. Договорились, что выкладывать репорты будем все равно, но рано, до 9:30, а на статус-митинге — переименовали его из планирования, в 10:00 на созвон заходят только эпик оунеры и те у кого есть вопросы, по очереди всем их задают. Выходит довольно быстро, кстати, на 7-10 эпиков и набора текущих задач без эпиков сейчас полчаса уходит, по старой процедуре — час. И главное, люди признали, что необходимость писать репорт заставляет обдумать, что происходит с эпиком и помогает собраться.
В-первых, мне кажется это вы потеряли. Я сказал «жаль, что в России совершенно никаких условий нет для научной работы» и именно эту фразу я и подтверждаю.
Во-вторых, не может быть в стране какой-то отдельной изолированной научной отрасли, которая каким-то чудесным образом позволяет именно данным ученым кататься в масле, все, что нужно для экспериментов получать и жить хорошо, а в соседних областях не иметь нифига.
Наука — государственное дело и требует совместной и независимой работы многих гражданских институтов, просто сам по себе научный процесс требует вовлечения всех этих групп людей. Если в каком-то одном месте это не работает совершенно, то везде будет примерно то же самое.
Ну и живу я сейчас в Австралии и прекрасно вижу, насколько лучше тут живут люди, которые занимаются наукой по сравнению с теми людьми, которые занимаются наукой в России.
Вы сами спросили про «в теме ли» а потом, когда человек сказал что «в теме» и поделился опытом, вы сразу про экстраполяцию и личный пример, что-то вам не угодишь. Передергиваете.
Я вообще в теме, по крайней мере был пять лет назад и не думаю, что что-то сильно поменялось. У меня есть два источника информации.
Во-первых, мой собственный опыт. Я попытался перейти работать из программистов в психологию. Я оканчивал сразу и гештальт-институт и мог пойти работать гештальт-терапевтом, в то же самое время я оканчивал магистратуру в институте психологии Выготского (его какое то время назад разогнали в РГГУ), защищал диссертацию по изучению данной гештальт-терапии (чем очень горд, вообще никто не пытается научно подойти к психотерапии), и очень хотел остаться и заниматься научной работой.
Так вот, как психотерапевт, я мог, в принципе, при удачном стечении обстоятельств, зарабатывать примерно 75% зарплаты моей программистской, если я буду очень хорош. А работа в институте принесет мне разве что 15%. И это опять же, если повезет. Условия работы моих преподавателей и научных руководителей я посмотрел и мне было очень грустно.
А второй источник у меня отец, который и профессор и доктор наук уже много-много лет в обычных средних институтах, специалист по лучевой сварке. И я следил, как лет 15 назад они пытались выживать с новыми технологиями, пытались в ЦЕРН заехать, а теперь вот преподавателем работает и наблюдает эксперименты государства над институтами, как научные работники получает гигантское количество часов на учебу и не могут заниматься научной работой. Как базы материальной нет.
Соответствует действительности. Может островки и есть, но в целом по стране наука загнивает именно просто потому что там нет денег и заботы об ученых.
Это не плохо, а очень даже хорошо. Но могло бы быть лучше если бы ученые могли бы работать там, где родились. Жаль, что в России совершенно никаких условий нет для научной работы.
1. Никто особенно с этим не борется, потому что такого не замечали. Программисты все крутые, все хотят делать хорошо, нет оценки работы программиста по количеству тикетов. Так же у нас есть правило двух аппрувов на каждый PR, соответственно, если срежешь угол, тебе вежливо на это укажут и предложат помощь правильно все сделать. Тут еще и особенность Ruby-коммьюнити, пока идеально не сделаешь архитектуру изменения, аппрува не получишь.
2. Не совсем понимаю этот вопрос. По-моему, всегда за качество кода отвечает программист, который его пишет. Не знаю, как на это ответить. Я вот код написал, и мне будет стыдно если ребята увидят, что я там где нить накостылял. Если надо делать костыль (типа слишком сложно получается, или надо что то сначала переделать, но не до того сейчас), собираем колл с заинтересованными людьми и решаем, готовы ли вложится в большой рефакторинг или костыль пока сгодится. Опять же, все люди адекватные и обычно всегда находится удовлетворяющий всех подход.
3. У нас спринт длился неделю (мы сейчас на какое-то подобие канбана перешли), и если появлялись баги, которые надо срочно починить, то их ставили поверх всех тасков, чтобы желающие могли взять. У нас никто особо не ставил цели заканчивать все задачи в течении спринта, треть задач постоянно оставалась в стеке. Это вроде никак не мешало, тестирования, как отдельного шага у нас нет, все покрывается тестами, которые тоже проходят ревью, деплоится изменение сразу после всех аппрувов и прогонки тестов на circle ci.
4. Настоящего технического долга (когда архитектурные проблемы требуют переделки системы) я не припомню, чтобы как-то особо накапливалось. Пару раз вначале было такое — какой-то человек говорил — блин, надо тут переделать все. Начинал долбить тех лида, собирал людей обсудить, все смотрели и говорили, да, тут было бы неплохо все подчистить. В итоге создавали эпик и тех лид пробивал его с командой менеджмента, начинали добавлять таски в спринты.
Сейчас основная проблема — надо поддерживать все джемы, все системы в обновленном состоянии, и не всегда это просто сделать. Для этого мы в итоге мы поменяли процесс, теперь разработчики могут завести таску с описанием в специальный беклог в джире, откуда на встрече по приоритезации менеджеры достают задачки, обсуждают их импакт и добавляют какое-то количество в спринт. Ну и мы провели серию воркшопов, обсуждали все животрепещущие темы для разработки и создали роадмэп, по которому большие технические темы выделены в эпики, которые периодически добавляются в скоуп.
Вообще, на мой взгляд, textbook scrum — довольно утопичная идея, и если подходить к нему как к священной корове, да еще если руководство все свои старые замашки в него принесет, очень может стать токсично работать в коллективе.
Выше правильно сказали, что единственная задача Scrum — создать быструю обратную связь к команде, чтобы она могла выстраивать процессы под свои запросы и стиль работы. И конечно же, люди. Люди должны быть адекватными, особенно руководство. Если начальник бегает с табличками количесва закрываемых тикетов, хорошего не жди :)
Мне с этим вот повезло. В текущем, самом моем лучшем проекте, спрашивается только грубый эстимейт в неделях на эпик и он не проверяется потом, когда сделаете, тогда сделаете. Иногда интересуются, не нужна ли помощь, если команда эпика сильно уж запозднилась. Нет никаких особых дедлайнов, главное — do the right thing. Бывали случаи, когда понимали, что фичу делать сложно и, главное, она не принесет какой-то уж большой пользы, заворачивали на полпути. Никакой оценки программиста нет, все итак все друг про друга знают. Ну и тех лид (он сейчас уже поднялся до руководителя всего проекта), очень крутой и адекватный, не давит не отсвечивает и требует от всех только одного — чтобы в каждый момент времени человек делал правильную вещь, которая сейчас наиболее важна.
Удивлен таким количеством негатива по поводу скрама и аджайл методологии. В моем личном опыте переход к любому аджайл подходу обычно приводил к позитивным изменениям в команде, даже в очень трудной и нездоровой (хотя не решал ее проблемы, конечно же).
Но мне вот интересно, а какие подходы люди применяют кроме них? По какой методологии делают проекты? Неужели waterfall еще жив, когда аналитики планируют релиз несколько месяцев, а потом команда делает заранее изготовленные задачки? И что еще есть, у меня какие-то пробелы в этом месте.
Вы мне ответили, но я вроде и не спорил с этими утверждениями. Сам Раст очень полюбил, хотя так и не смог в моей компании его вытащить что нибудь сделать. Начал переписывать один Ruby gem на нем (i18т), но прирост перформанса не стоил возни, поэтому не стали.
На самом деле попробуйте на нем что-то написать. Я когда его изучал, помню, был момент, когда бьюсь и не понимаю почему ошибка то там вылезет, то тут, никак проект не собирается.
А потом понял, что у меня просто кривая архитектура (я уж не помню, что там у меня было) — в итоге все эти лайфтаймы, борроу чекер — они загоняют в такие рамки, когда ты и проектировать код должен правильно и он выходит логичней и безопасней сам по себе.
Все таки вы это не просто набор закорючек, а очень стройный набор правил и принципов, которые определяют сам стиль программирования. Просто надо его как следует разжевать
Scala — это хорошо очень даже, люблю и сам под Akka код писал. Посмотрел вашу библиотеку — очень годно и как раз то что нужно. Но я что-то давно уже к самой идее не возвращался, если вернусь, обязательно воспользуюсь.
Лурк православнее, конечно же
Я еще раз повторюсь, что я думаю, что как раз четко следовать скраму не обязательно, были тут разговоры из серии «это не настоящий скрам» — это не про то, я думаю, имелось в виду просто соблюдение некоторых базовых принципов, сама форма не так уж важна, какова длина спринта или какие встречи проходят в течении спринта.
Просто скрам дает некоторую рамку, некий шаблон, с которого можно начать. А главная идея этого шаблона — быстрая обратная связь и возможность изменения ритуалов и процессов команды.
А дальше все зависит от команды и их доверия к друг другу, могут устроить карго-культ, а могут и создать cohesive коллектив, который не нужно будет особенно микроменеджить. People management никто не отменял, собственно, мне кажется, одна из важнейших черт аджайла — это опора на людей, которые смелы и которые связываются друг с другом сами, порождая инновации и качество.
Давайте же окончим ее и займемся какими-то более полезными вещами.
Это позволяет управлять скоупом и ожиданиями продуктовой команды. А предсказуемость обычно задается как раз опытом самих разработчиков и их желанием быть профессиональными. Поскольку особо формальных требований и показателей нет, люди стараются сами определить скоуп (обычно на эпик выделяется микро-команда, выбирается разработчик, ответственный за эпик), договорится со всеми участника процесса и пытаться всех держать в курсе хода проекта и поднимать красный флаг, если где-то что-то поменялось.
Мне кажется, предсказуемость тут больше в постоянных пересмотрах и рефлексии на событиях, которые поддерживаются на уровне ритуалов (ретро и просто люди иногда темы поднимают). На моей памяти за эти почти 4 года в команде, процесс у нас поменялся с десяток раз.
Например, сначала было еженедельное планирование, когда оба офиса собирались все вместе онлайн через большой экран и обсждали состояние эпиков, сколько осталось, что новое добавляется, обычно эпик оунер рассказывал по каждому эпику. Потом в какй-то момент вылезло наружу, что народу что-то не нравится, а именно, что выходит, что мы просто отчитываемся перед менеджментом, никакое это не планирование, менеджмент может и почитать в джире и сам спланировать, а нам время не маза тратить.
Коллега-программист предложил эксперимент — а давайте вообще выкинем этот митинг и посмотрим, как нам без него. Попрессовали продакт команду, договорились с ними, что эпик оунер будет просто писатьв специальный слэк канал отчет по специальной форме — типа что сделали, что будем делать, сколько всего осталось делать. А митинг отменим нафиг.
Ну после трех недель собрались обсудить вместо планирования — как перемена. И программисты и менежеры согласились, что не хватает форума, где можно послушать, что поменялось, и задать вопросы. Договорились, что выкладывать репорты будем все равно, но рано, до 9:30, а на статус-митинге — переименовали его из планирования, в 10:00 на созвон заходят только эпик оунеры и те у кого есть вопросы, по очереди всем их задают. Выходит довольно быстро, кстати, на 7-10 эпиков и набора текущих задач без эпиков сейчас полчаса уходит, по старой процедуре — час. И главное, люди признали, что необходимость писать репорт заставляет обдумать, что происходит с эпиком и помогает собраться.
Пару месяцев уже так живем, вроде нормально
Во-вторых, не может быть в стране какой-то отдельной изолированной научной отрасли, которая каким-то чудесным образом позволяет именно данным ученым кататься в масле, все, что нужно для экспериментов получать и жить хорошо, а в соседних областях не иметь нифига.
Наука — государственное дело и требует совместной и независимой работы многих гражданских институтов, просто сам по себе научный процесс требует вовлечения всех этих групп людей. Если в каком-то одном месте это не работает совершенно, то везде будет примерно то же самое.
Ну и живу я сейчас в Австралии и прекрасно вижу, насколько лучше тут живут люди, которые занимаются наукой по сравнению с теми людьми, которые занимаются наукой в России.
Во-первых, мой собственный опыт. Я попытался перейти работать из программистов в психологию. Я оканчивал сразу и гештальт-институт и мог пойти работать гештальт-терапевтом, в то же самое время я оканчивал магистратуру в институте психологии Выготского (его какое то время назад разогнали в РГГУ), защищал диссертацию по изучению данной гештальт-терапии (чем очень горд, вообще никто не пытается научно подойти к психотерапии), и очень хотел остаться и заниматься научной работой.
Так вот, как психотерапевт, я мог, в принципе, при удачном стечении обстоятельств, зарабатывать примерно 75% зарплаты моей программистской, если я буду очень хорош. А работа в институте принесет мне разве что 15%. И это опять же, если повезет. Условия работы моих преподавателей и научных руководителей я посмотрел и мне было очень грустно.
А второй источник у меня отец, который и профессор и доктор наук уже много-много лет в обычных средних институтах, специалист по лучевой сварке. И я следил, как лет 15 назад они пытались выживать с новыми технологиями, пытались в ЦЕРН заехать, а теперь вот преподавателем работает и наблюдает эксперименты государства над институтами, как научные работники получает гигантское количество часов на учебу и не могут заниматься научной работой. Как базы материальной нет.
Соответствует действительности. Может островки и есть, но в целом по стране наука загнивает именно просто потому что там нет денег и заботы об ученых.
1. Никто особенно с этим не борется, потому что такого не замечали. Программисты все крутые, все хотят делать хорошо, нет оценки работы программиста по количеству тикетов. Так же у нас есть правило двух аппрувов на каждый PR, соответственно, если срежешь угол, тебе вежливо на это укажут и предложат помощь правильно все сделать. Тут еще и особенность Ruby-коммьюнити, пока идеально не сделаешь архитектуру изменения, аппрува не получишь.
2. Не совсем понимаю этот вопрос. По-моему, всегда за качество кода отвечает программист, который его пишет. Не знаю, как на это ответить. Я вот код написал, и мне будет стыдно если ребята увидят, что я там где нить накостылял. Если надо делать костыль (типа слишком сложно получается, или надо что то сначала переделать, но не до того сейчас), собираем колл с заинтересованными людьми и решаем, готовы ли вложится в большой рефакторинг или костыль пока сгодится. Опять же, все люди адекватные и обычно всегда находится удовлетворяющий всех подход.
3. У нас спринт длился неделю (мы сейчас на какое-то подобие канбана перешли), и если появлялись баги, которые надо срочно починить, то их ставили поверх всех тасков, чтобы желающие могли взять. У нас никто особо не ставил цели заканчивать все задачи в течении спринта, треть задач постоянно оставалась в стеке. Это вроде никак не мешало, тестирования, как отдельного шага у нас нет, все покрывается тестами, которые тоже проходят ревью, деплоится изменение сразу после всех аппрувов и прогонки тестов на circle ci.
4. Настоящего технического долга (когда архитектурные проблемы требуют переделки системы) я не припомню, чтобы как-то особо накапливалось. Пару раз вначале было такое — какой-то человек говорил — блин, надо тут переделать все. Начинал долбить тех лида, собирал людей обсудить, все смотрели и говорили, да, тут было бы неплохо все подчистить. В итоге создавали эпик и тех лид пробивал его с командой менеджмента, начинали добавлять таски в спринты.
Сейчас основная проблема — надо поддерживать все джемы, все системы в обновленном состоянии, и не всегда это просто сделать. Для этого мы в итоге мы поменяли процесс, теперь разработчики могут завести таску с описанием в специальный беклог в джире, откуда на встрече по приоритезации менеджеры достают задачки, обсуждают их импакт и добавляют какое-то количество в спринт. Ну и мы провели серию воркшопов, обсуждали все животрепещущие темы для разработки и создали роадмэп, по которому большие технические темы выделены в эпики, которые периодически добавляются в скоуп.
Вообще, на мой взгляд, textbook scrum — довольно утопичная идея, и если подходить к нему как к священной корове, да еще если руководство все свои старые замашки в него принесет, очень может стать токсично работать в коллективе.
Выше правильно сказали, что единственная задача Scrum — создать быструю обратную связь к команде, чтобы она могла выстраивать процессы под свои запросы и стиль работы. И конечно же, люди. Люди должны быть адекватными, особенно руководство. Если начальник бегает с табличками количесва закрываемых тикетов, хорошего не жди :)
Мне с этим вот повезло. В текущем, самом моем лучшем проекте, спрашивается только грубый эстимейт в неделях на эпик и он не проверяется потом, когда сделаете, тогда сделаете. Иногда интересуются, не нужна ли помощь, если команда эпика сильно уж запозднилась. Нет никаких особых дедлайнов, главное — do the right thing. Бывали случаи, когда понимали, что фичу делать сложно и, главное, она не принесет какой-то уж большой пользы, заворачивали на полпути. Никакой оценки программиста нет, все итак все друг про друга знают. Ну и тех лид (он сейчас уже поднялся до руководителя всего проекта), очень крутой и адекватный, не давит не отсвечивает и требует от всех только одного — чтобы в каждый момент времени человек делал правильную вещь, которая сейчас наиболее важна.
Но мне вот интересно, а какие подходы люди применяют кроме них? По какой методологии делают проекты? Неужели waterfall еще жив, когда аналитики планируют релиз несколько месяцев, а потом команда делает заранее изготовленные задачки? И что еще есть, у меня какие-то пробелы в этом месте.
А потом понял, что у меня просто кривая архитектура (я уж не помню, что там у меня было) — в итоге все эти лайфтаймы, борроу чекер — они загоняют в такие рамки, когда ты и проектировать код должен правильно и он выходит логичней и безопасней сам по себе.
Все таки вы это не просто набор закорючек, а очень стройный набор правил и принципов, которые определяют сам стиль программирования. Просто надо его как следует разжевать