человек к сожалению имеет привычку адаптировать окружение под себя.

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

И в духе agile manifesto: я, понимая важность того что слева (майндсет), так же считаю важным то что справа (структура) :)

на самом деле важен майндсет и продукт который делается с этим майндсетом

структура тут - ну важность ее сильно преувеличена

Боюсь, без структуры бизнес загнется и не будет возможности делать продукт

Боюсь, без структуры бизнес загнется и не будет возможности делать продукт

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

Я искренне надеюсь, что это так

И ваш бизнес (лично ваш) бизнес будет процветать! :)

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

А вот тут я прям не верю. Команда с agile майндсетом не будет изобретать велосипед

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

Ну что ж, пойдемте сделаем стартап вместе )

нужен продуктовик с идеями :D у меня пока с идеями грустно

Есть продуктовики. Только денег нет ))

скорее не то чтобы денег нет. я прихожу к мысли что их надо уметь искать.

я сейчас работаю на таких ребят - что у меня задается вопрос как они находят инвесторов

Ну не хотите как хотите )

так на практическом примере помогаешь понять требуемый майндсет

так точно работает)

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

Эксперимент признан поддельным.

Интересно, спасибо. Почитал про опровержения. Если верно написано, то этот эксперимент не относится к влиянию структуры на поведение.

о как

Анастасия, скажите это создателям Манифеста: http://agilemanifesto.org/history.html. А заодно посмотрите в Википедии значение слова "методология".

давайте без двадцать пятого круга про методологии 😉

давайте без двадцать пятого круга про методологии 😉

Ты хочешь поговорить об этом? :)

Читал тут статью про десантников. И придумал девиз для Скрам-мастеров - "Никто кроме Вас!". Как вам?

"Только не вы!" может быть лучше подходит ))

Не. Речь про команду. Никто кроме Вас, команда :)

Тогда да )

Мы как бы есть, но в тени. Мы не принимаем решений, мы высчечиваем проблему, а решение принимают они.

👍

Где-то между мы и они

Прям мотивационные курсы какие то 😂

Без нас был бы коллапс, жизнь краше с СМ. Продолжайте, а то бывает такое что надоедает ИТ и хочется уйти лучок выращивать. 😂

Почитаешь и легче становится. Хотя по факту все профессии нужны и важны

Интересно, спасибо. Почитал про опровержения. Если верно написано, то этот эксперимент не относится к влиянию структуры на поведение.

Не совсем :) Эксперимент конечно научный но полностью фальсифицируемый. Если кратко нет доверия его результатам.

Привет! С удаленными сейчас работаем. Если команда целиком, то норм. У нас есть две такие команды. Но возникает масса проблем с митингами. Все равно они вываливаются из процесса и нужно много больше усилий для их вовлечения. А с отдельными людьми все еще тяжелее. Я за то, чтобы все сидели в одном офисе.

Я работал как agile-коуч со SkyEng, у них почти все команды удаленные, полет нормальный в целом.

Я работал как agile-коуч со SkyEng, у них почти все команды удаленные, полет нормальный в целом.

Привет Ларри)

Я работал как agile-коуч со SkyEng, у них почти все команды удаленные, полет нормальный в целом.

Команда разбросанная по трем городам - это круто. Не кто не лезит с разговорами а все коротко по делу в чатах

Команда разбросанная по трем городам - это круто. Не кто не лезит с разговорами а все коротко по делу в чатах

почему это должно быть так?

Такая организация в компании

звучит адовый ад если все коротко и по делу в чатах

За год устроили пару общих конф по Скайпу. Манагер обычно звонит пору раз в неделю. А так все в переписке. И знаете чем это хорошо ? - то что в переписке всегда есть доказательство того к чему пришли в итоге) и есть время подумать над реализацией какого то функционала, а не так что сидит человек на против тебя и ждёт ответа прямо сейчас.

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

это как говорится "ой вей проблема"

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

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

В чат выкатывается основное а в ждиру уже задачи конкретно расписывается. Вообще манагер пишет что надо. Я раскидывают по задачам и слежу как делают и манагер тоже смотрит как все исполняется.

Выше я спрашивала как построенный взаимоотношения на проектах у других людей но меня как то проигнорировали) только дали ссылки на литературу

Выше я спрашивала как построенный взаимоотношения на проектах у других людей но меня как то проигнорировали) только дали ссылки на литературу

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

у меня есть опыт удаленных команд - мы делаем так чатик мы используем как флудилку, вопросы все решаем через созвоны и только. основной инструмент открытости (понимания что происходит в команде) - это жира. в конфлюенсе у нас только соглашения которые оформлены командой (DoD, Codestyle, etc).

жира должна быть понятной и простой(чем меньше колонок тем лучше).

Меня больше волнует следующее: раньше все требования шли главному разработчику и он выливал это все на тестовую площадку, сейчас команда увеличилась и задач прибавилось и другие разработчики начали сливать все сами, в результате начало что то отваливаться ( то не войти, то функционал не так работает)

жира должна быть понятной и простой(чем меньше колонок тем лучше).

Про какие колонки пишите?

Про какие колонки пишите?

todo inprogress done

Меня больше волнует следующее: раньше все требования шли главному разработчику и он выливал это все на тестовую площадку, сейчас команда увеличилась и задач прибавилось и другие разработчики начали сливать все сами, в результате начало что то отваливаться ( то не войти, то функционал не так работает)

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

есть канешн варик еще один - нанять devops инженера и свесить на него ответственность за деплои.

Это купирование симптомов, кто чинить будет при отказе

Это купирование симптомов, кто чинить будет при отказе

свесим на кого нить ответственность и норм

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

Нет команды... Позиция типа "отыб***сь от меня, я работаю" это вобще не про команду.

Если пробежаться по ценностям того же скрама, полагаю, не одной не будет в этой "команде"

Lena У нас семь команд, нет формальных процедур и ответственных. Но одна из команд берет в Спринт подготовку к релизу с соответствующими тестами и исправлениями косяков, мешающим выкатке. Такая схема зло, она у нас вынужденная. Проблема в отсутствии полноценного покрытия тестами. Ситуация старая, проблема еще до Скрама была, когда не нашли ще инвестора и программистов было пять человек и пр, тот самый техдолг, тянущийся издавна. Ситуацию исправляют сами команды - DoD сейчас усилен самими командами и детализирован, без тестов фича не выходит. По старым долгам на Сообществах сами же команды сделали роадмап и исправляют ситуацию.

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

Огромную роль играют менторы компонентов. По сути лидеры, опытные разработчики, они ведут сообщества за собой. Это работает.

Где то уже писал, что при трансформации проще выявлять лидеров и работать с ними, чем пытаться как-то давить и работать со всем коллективом. Лидеров несложно выявить, как-то тоже писал как это сделать (хотя не все с такой интерпретацией их выявления согласились). Результаты бывают неожиданными. Лидеры меняются, с этим надо постоянно работать. Их можно формировать, это тоже хороший способ изменить культуру.

И да, вся система все время пытается вернуться в старое состояние. Они все время при любой проблеме пытаются предложить вариант в виде назначить ответственного, поставить руководителя, найти виновного. Тут нужно огромное терпение. Иногда два-три предложения моих или Владельца Продукта откатывает прогресс на месяцы назад. Словом можно ранить.

Меня больше волнует следующее: раньше все требования шли главному разработчику и он выливал это все на тестовую площадку, сейчас команда увеличилась и задач прибавилось и другие разработчики начали сливать все сами, в результате начало что то отваливаться ( то не войти, то функционал не так работает)

Как вы обеспечиваете качество?

Как вы обеспечиваете качество?

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

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

И все??

+ нагрузочное тестирование и тестирование безопасности Юзабилити отвечает отдел дизайна За качество функциональных требований отвечаю я

+ нагрузочное тестирование и тестирование безопасности Юзабилити отвечает отдел дизайна За качество функциональных требований отвечаю я

Не вижу тут модульных тестов, Рецензирования кода, Работу в парах Эти практики обеспечивают более короткий цикл проверок

Было несколько рефакторинг кода после нагрузочного тестирования. А про модульные тесты есть литература?

Было несколько рефакторинг кода после нагрузочного тестирования. А про модульные тесты есть литература?

См по ключу test driven development

Спасибо посмотрю обязательно!)

Было несколько рефакторинг кода после нагрузочного тестирования. А про модульные тесты есть литература?

Модульные тесты (unit tests) и разработка через тестирование (test driven development) - разные вещи. Вы можете писать модульные тесты без TDD. Прелесть TDD в том, что он сильно улучшает дизайн кода, потому что позволяет задумываться о дизайне кода ДО реализации. Но не всегда подход TDD возможен и нужен. Что касается модульных тестов, рекомендую книгу https://www.amazon.com/Art-Unit-Testing-examples/dp/1617290890

Привет! Посоветуйте, пжлст, место приличное, где коучигу поучиться.

Привет! Посоветуйте, пжлст, место приличное, где коучигу поучиться.

Эриксон

Привет! Посоветуйте, пжлст, место приличное, где коучигу поучиться.

Я рекомендую эту школу: в http://sorazvitie.ru Несмотря на страшный сайт, Юля учит Коучингу очень глубоко и системно. Учился у неё 8 модулей, получил Ассоциированного коуча. Юля преподаёт Коучинг вместе с основами NLP (потому что весь Коучинг основан на NLP), это может оттолкнуть тех, кто считает, что NLP - это нехорошо.

@dmitriyabr Andrey спасибо!

DHE гораздо экологичней, NLP суть манипуляция