Здравствуйте, sergey2b, Вы писали:
S>у нас например за каждую выполненную задачу начисляют баллы S>каждая команда набравшая меньше 50 баллов получает всенародное порецание на собрании команд Северной Америки
О, это ж классика "как разогнать всех толковых людей".
S>а затемо стал каждый день тупо готовиться к собеседованиям
И правильно сделал
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>И правильно сделал
Директора HR заменят через 1-3 года, а проект нужно зафейлить?
Опытные прогеры не истерят, а с пофигизмом наблюдают за калейдоскопом "внедрителей более лучшей производительности".
L>Серьезно, хватит заниматься перепевками Битлз по телефону, почитай уже основы, а?
Да не поможет это, я тоже читал, и думал, что понимал, но реально осмыслил происходящее только через 7-8 месяцев работы с опытным тренером (тем самым "скрам коучем", да).
Самым сложным было осознание простоты происходящего процесса. Я все где-то искал подвох, старался быть умнее и т.п., а всего-то надо было накопить историю выполнения задач конкретно взятой командой. Ключевое тут именно "команда", если люди постоянно меняются, не факт, что будет хорошо работать.
__>В общемто каждая нормальная нерешенная задача требует постоянной поддержки то есть потока тех самых простых задач, что радует хомячков
я сейчас конкретный пример из жизни дам
работал я в одной известной конторе и там текучкой была починка тестовых конфигов. их правили одновременно каждодневно сотни людей для своих нужд, для прохождения своих тестов, что ломало тесты других. причем самая частая проблема — правили автогенеренный код.
рабочий день часто начинался с того, что создавался тикет на упавшие тесты, нужно было лезить туда, править некоторые файлы, перегенерировать что автогенерится и тестить и т.д. по кругу. я занимался этим несколько месяцев подряд. мартышкин труд.
просто запретить кому попало править тесты и любые файлы не вариант, так как это поставит работу колом. я за эти несколько месяцев посидел, подумал и понял, что на самом деле тесты надо реорганизовать, чтобы правки в одних тестах не ломали другие и вообще убрать нефиг эту систему автогенерации, потому что по факту нужды в ней нет.
на что я наткнулся в итоге при обсуждении подобного подхода?
— нафиг менять то, что уже работает, надо просто научиться фиксить быстрее
— пока ты будешь что-то там менять у нас тут тесты поломанные, которые надо быстро фиксить
— ты собрался переписывать неполоманные тесты? а зачем?
— зачем ты будешь переписывать поломанный тест, когда ты знаешь как его можно просто пофиксить?
ну и самое главное
— это не "гавно какое-то", а начальник за эту систему автогенерации получил промо в свое время и презентовал как супирпупир решение всех проблем, поэтому система тут с нами навсегда
а поэтому каждый день — список поломанных тестов и фперед фиксить-фиксть бистро-бистро
Здравствуйте, Артём, Вы писали:
CC>>И правильно сделал Аё>Директора HR заменят через 1-3 года
C чего ты взял?
Аё> а проект нужно зафейлить?
Надо принести себя на алтарь долбоклюйства менеджмента, да!
Артёмка, работу работают за деньги. Если нет денег — все остальные сказки идут побоку.
Аё>Опытные прогеры не истерят
А сразу сваливают туда, где их ценят а не полощут мозги ерундой.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, SkyDance, Вы писали:
L>>Серьезно, хватит заниматься перепевками Битлз по телефону, почитай уже основы, а?
SD>Да не поможет это, я тоже читал, и думал, что понимал, но реально осмыслил происходящее только через 7-8 месяцев работы с опытным тренером (тем самым "скрам коучем", да). SD>Самым сложным было осознание простоты происходящего процесса. Я все где-то искал подвох, старался быть умнее и т.п., а всего-то надо было накопить историю выполнения задач конкретно взятой командой. Ключевое тут именно "команда", если люди постоянно меняются, не факт, что будет хорошо работать.
На самом деле беда в твердолобости и косности мышления.
Из того, что я лично видел в свое время, менеджмент, сходив на тренинг по скраму, выносил для себя, что решение всех проблем — это двухнедельные спринты. И выходил приказ всю запланированную работу на год разбить на двухнедельные периоды. Тут тоже такие отметились, кстати.
Люди реально не понимают, что разработка ПО — это не строительство дома, где все на самом деле делается по предсказуемым этапам. Наша работа намного ближе к разработке проекта этого самого дома, иными словами — это исследовательская деятельность в чистом ее виде.
Здравствуйте, sergey2b, Вы писали:
S>нет, а в чем смысл ?
Да примерно такой же смысл, как и в баллах за задачи.
S>у нас практически перед оффисом корабль на котором подписавли первую американскую конституцию, если не ошитаюсь его лет 10 назад взрывали
Здравствуйте, landerhigh, Вы писали:
L>Ликбез: L>В методологии скрам планируется только один спринт (следующий). И планируется он на основании результатов текущего (закончившегося) спринта.
Капитан Очевидность? Вместо хорошего примера вы занимаетесь словоблудием. Я уже говорил — ресерч в софтварных проектах больше похож на ту самую операционную деятельность в силу того, что постоянно возникает непредвиденный траблшутинг, суппорт и постоянное обнуление планов.
Вы начинаете играть во все слова и называете все софтварные проекты ресёрчем Между тем ключевая разница в степени неопределенности и наличии той самой операционной деятельности.
Собственно, вы уже ответили, что Канбан это тоже Скрам. Т.е. есть спринты, нету их — для вас всё едино.
Здравствуйте, landerhigh, Вы писали:
P>>Вот например маленький ресёрч который я делал, длился полгода — закончился тем, что все варианты решения были забракованы. Не сильно ясно, чем здесь помогает скрам.
L>И, следовательно, скрам не нужен вообще от слова совсем, да?
На эти полгода — нет, не нужен, т.к. здесь в чистом виде операционная деятельность.
Здравствуйте, baxton_ulf, Вы писали:
S>>есть ли какие то варианты улучшить ситуацию кроме смены работы ?
_>ну дык разбей на 10 маленьких задач. как говорится "в попугаях оно все значительно длиннее". и будешь самым производительным членом команды
Это не всегда возможно: иногда задачи бывают действительно сложные. Тогда в процессе их решения возникают подзадачи, а в процессе решения подзадач возникают ещё подзадачи, по несколько штук в день. Т.о. получается, что у тебя в работе будет стек задач.
К примеру: решаем задачу GUI-A. В процессе её решения появились задачи GUI-A001, GUI-A002. Ознакомился с A001 (т.е. оценил), перешёл к A002 глянул — поставил на паузу, вернулся к A001 — создал GUI-A003, GUI-A004. Положил в стек GUI-A001, решаем GUI-A003.
В итоге список выглядит вот так:
GUI-A — InProgress
GUI-A001 — InProgress
GUI-A002 — Paused
GUI-A003 — InProgress
GUI-A004 — TODO
Собственно, после решения GUI-A003 перейдём к GUI-A004, а после неё GUI-A001 будет автоматически решена.
В таком случае спрашивается: 1) на кой ляд нужны были A003 и A004, если это этапы одной задачи?
2) Стоило ли вообще заморачиваться со всей сетью задач GUI-A00X, если вся эта канитель — решение одной задачи: GUI-A
Когда у меня были такие задачи, я не заморачивался. Не заморачивался кстати не только я. У меня тогда в YouTrack'е были задачи на 12 и больше экранов текста. Там и рабочие материалы были, и скриншоты, и результаты тестирования — 2 месяца канители над одной задачей.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, CreatorCray, Вы писали:
CC>C чего ты взял?
Наблюдения.
Аё>> а проект нужно зафейлить? CC>Надо принести себя на алтарь долбоклюйства менеджмента, да!
HR- это не продакт менеджмент. Они играются в свои игры, нужно с этой неизбежностью считаться. Они даде стараются как лучше, для кого-то. Но лучше бы не старались.
CC>Артёмка, работу работают за деньги. Если нет денег — все остальные сказки идут побоку.
А я не спорю за деньги. Разговор про то, стоит ли менять контору из-за политик отдела кадров. Так вот чисто моё imho- политики hr меняются, как времена года.
Аё>>Опытные прогеры не истерят CC>А сразу сваливают туда, где их ценят а не полощут мозги ерундой.
В теории. А на практике кое-кто держится за Эппл.
Здравствуйте, Pauel, Вы писали:
P>Капитан Очевидность? Вместо хорошего примера вы занимаетесь словоблудием. Я уже говорил — ресерч в софтварных проектах больше похож на ту самую операционную деятельность в силу того, что постоянно возникает непредвиденный траблшутинг, суппорт и постоянное обнуление планов.
Я уже (единственный в этой теме, кстати) привел хороший, конкретный пример из жизни. Полегче с обвинениями, пожалуйста.
P>Вы начинаете играть во все слова и называете все софтварные проекты ресёрчем Между тем ключевая разница в степени неопределенности и наличии той самой операционной деятельности.
Отделяем операционную деятельность от разработки.
Степень неопределенности совершенно не важна, важно само наличие оной.
P>Собственно, вы уже ответили, что Канбан это тоже Скрам. Т.е. есть спринты, нету их — для вас всё едино. P>Итого — вам есть чего добавить по существу?
Я уже достаточно добавил. По существу и из собственного опыта.
Здравствуйте, Pauel, Вы писали:
L>>И, следовательно, скрам не нужен вообще от слова совсем, да?
P>На эти полгода — нет, не нужен, т.к. здесь в чистом виде операционная деятельность.
Операционная деятельность — это работа по плану/инструкции.
Вести ресерч по плану — это делать все то же самое, что и раньше, в надежде на иной результат. Кажется, в медицине этому даже название есть.
Здравствуйте, landerhigh, Вы писали:
L>Отделяем операционную деятельность от разработки. L>Степень неопределенности совершенно не важна, важно само наличие оной.
Наоборот, очень даже важна. Не ясно, как планировать спринт если у вас полно операционной деятельности которая зависит от этой самой неопределенности.
Здравствуйте, landerhigh, Вы писали:
P>>На эти полгода — нет, не нужен, т.к. здесь в чистом виде операционная деятельность.
L>Операционная деятельность — это работа по плану/инструкции.
Необязательно. Траблшутинг, суппорт тоже сюда относятся.
L>Вести ресерч по плану — это делать все то же самое, что и раньше, в надежде на иной результат. Кажется, в медицине этому даже название есть.
А кто сказал что всё то же самое? Вы усиленно стараетесь подметить тему разговора.
Здравствуйте, Философ, Вы писали: Ф>Это не всегда возможно: иногда задачи бывают действительно сложные. Тогда в процессе их решения возникают подзадачи, а в процессе решения подзадач возникают ещё подзадачи, по несколько штук в день. Т.о. получается, что у тебя в работе будет стек задач.
я некоторое время "продолжаю наблюдение" за работой менеджмента и да, он сильно меняется и они там постоянно придумывают новые системы. на самом деле цель системы — снизить порог входа, чтобы все люди были взаимозаменяемы и любой, условно, с дипломом, точно так же работал, как тот кто половину проекта сам написал за пять лет.
пока что им это не удается. при разбиении задач на подзадачи все все время забывают, что задачи действительно постоянно связаны между собой и образуют достаточно сложный граф зависимостей. воспринимать каждую задачу просто в вакууме это переупрощение
Здравствуйте, Pauel, Вы писали:
P>Наоборот, очень даже важна. Не ясно, как планировать спринт если у вас полно операционной деятельности которая зависит от этой самой неопределенности.
Это уже анекдот про мужиков и японскую бензопилу.
Если полно операционной деятельности, которая не дает вести разработку, то нужно поднимать вопрос с менеджментом о реогранизации работы.
Здравствуйте, landerhigh, Вы писали:
L>Это уже анекдот про мужиков и японскую бензопилу.
L>Если полно операционной деятельности, которая не дает вести разработку, то нужно поднимать вопрос с менеджментом о реогранизации работы.
Вот смотрите, есть два основных кейса в разработке с т.з. используемых технологий:
1. вы пилите, условно, еще одну приложуху из того класса что пишут везде. Неопределенность минимальна и ограничена почти что исключительно заказчиком, то есть — архитектура, стек, основные проблемы известны еще до старта проекта. Проблем хватает, но про них почти всегда известно, что "ну, можно и обойти" или "вернемся позже"
2. вы пилите приложение, навроде которого до вас никто еще не писал — здесь у вас риски вообще везде, не считая заказчика, вы не знаете ни примерную архитектуру, ни проблемы, не можете оценить перформанс, издержки на инфраструктуру итд.
В первом случае вы можете начинать прямо со скрама, именно под такие кейсы он и заточен
Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть. Каждый фейл нужно рассматривать как новый, неизвестный ранее риск для которого нужно понять, как быть — игнорировать, или как то подстраховаться.
Поскольку вы ничего про это не знали, ваш спринт накрылся медным тазом.
Следующий спринт вы получаете тож самое — вы запилили прототип клиента, только собираетесь брать очередной тикет из баклога, а тестировщики прибегают и орут "ужос, клиент не работает, валится стабильно после 8ми вечера"(реальный кейс). Вы бросаете всё и ищете проблему, проблема в том, что есть бага, которая пофиксана только для свежей ос, а поддерживать надо всё, на чем будут потенциальные юзера. Ищете фикс, пока ищете — ваш баклог на паузе. Нашли, только собираетесь взять тикет из баклога, снова прибегает QA и говорит, что клиент валится гарантировано в течение 30 минут(реальный кейс). Снова бросаете всё, ищете проблему. Находите. Только собираетесь брать тикет из баклога, QA прибегает и говорит, что работает только на виртуалке(снова реальный кейс). Вы снова бросаете баклог, ищете проблему. Находите, снова хотите брать чтото из баклога, а QA приходит и говорит что клиент(сервер) не может...
Итого — потрачено куча спринтов, в каждом из которых план ломается прямо на первый-второй день.
В конце, если задачи решаемые, вы найдете примерную архитектуру приложения, только далеко не факт, что бюджета хватит на ваши изыскания.
Здравствуйте, Pauel, Вы писали:
P>1. вы пилите, условно, еще одну приложуху из того класса что пишут везде. Неопределенность минимальна и ограничена почти что исключительно заказчиком, то есть — архитектура, стек, основные проблемы известны еще до старта проекта. Проблем хватает, но про них почти всегда известно, что "ну, можно и обойти" или "вернемся позже"
Нет, не пишем.
Зачем?
P>2. вы пилите приложение, навроде которого до вас никто еще не писал — здесь у вас риски вообще везде, не считая заказчика, P>вы не знаете ни примерную архитектуру,
Можем. И оцениваем
P>издержки на инфраструктуру итд.
Можем. И оцениваем.
P>Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть.
Между тем ключевая разница в степени неопределенности и наличии той самой операционной деятельности.
