Здравствуйте, Pauel, Вы писали:
P>Исследования это решение проблемы вида: неизвестно а можно ли сделать, а как вообще стоит сделать, а какие будут требования к этому
P>Вы привели пример совсем небольшой проблемы — у либы не та вычислительная сложность.
Очень легко осуждать, глядя на результаты.
А вото то, что проблема была исключительно в либе, стало известно только по результатам исследования.
Вначале, мы вообще предполагали, что ввиду того, что протокол дико overengineered, может существовать принципиальное ограничение, которое сделает весь проект бессмысленным или не практичным.
P>Это исследование с минимальной неопределенностью.
Это оно задним числом минимальное.
P>Конечно, если у вас только такие проблемы, то можно и в скрам. Представьте другой вариант — у вас нет этой либы, вообще, и вы не знаете, а решаема ли задача, реализуема ли в конкретные сроки, не займет ли это годы, а можно ли хоть как иначе.
Не вижу разницы.
P>Тут важно добавить, что негативный результат или даже отсутствие результа вполне себе нормально для исследовательской работы. Копали-копали-копали, и выяснили, что на данном этапе исключить неопределенность не выйдет, мощностей конкретного проекта не хватит. И сколько на это времени потрачено будет известно в конце исследования.
Ну да, как только стало известно, что сделать нельзя, исследование заканчивается.
L>>Скрам и был создан как методология работы над проектами, где в начале проекта ничего, кроме неопределенности, нет. P>Это вы перевираете. Скам вырос из продуктовой разработки, где неопределенность по определению невысокая.
Нет. Он вообще не из айти пришел. Советую ознакомиться с историей вопроса.
Здравствуйте, _ABC_, Вы писали:
_ABС_>Про разницу между проектами и операционной деятельностью есть, но в материалах по управлению проектами людей, далёких от разработки софта.
Раз все тут продвинутые проеджекты, может посоветуете пару книг по операционному и проектному управлению, наверное. Пришлось недавно вписаться во всё это, снова, но я просто кроме как "скрам бук", "как пасти котов" и "мифический человеко-месяц" что-то ничего не знаю, а освежить знания надо.
Здравствуйте, landerhigh, Вы писали:
L>Очень легко осуждать, глядя на результаты. L>А вото то, что проблема была исключительно в либе, стало известно только по результатам исследования. L>Вначале, мы вообще предполагали, что ввиду того, что протокол дико overengineered, может существовать принципиальное ограничение, которое сделает весь проект бессмысленным или не практичным.
Цель скрама — сделать разработку предсказуемой. С исследованием до самого конца вы этой предсказуемости не получите. Т.е. независимо от наличия спринтов или их отсутствия, как бы вы ни старались, вас это не приблизит к достижению целей основного проекта.
Максимум, что вы можете добиться — большей прозрачности. Только зачем вам скрам для этого?
L>>>Скрам и был создан как методология работы над проектами, где в начале проекта ничего, кроме неопределенности, нет. P>>Это вы перевираете. Скам вырос из продуктовой разработки, где неопределенность по определению невысокая.
L>Нет. Он вообще не из айти пришел. Советую ознакомиться с историей вопроса.
Здравствуйте, _ABC_, Вы писали:
_AB>Зачем "отвлечёшь", если это де-факто открытие дня?
У кого как.
_AB> Или закрытие, у кого как.
Если поставить к закрытию то вообще мало шансов даже половину увидеть.
CC>>Емыл же прочитают когда будет удобно. _AB>Если его напишут и если его прочитают. И если поздно не будет на него отреагировать.
Ну очень нужная мне информация что вася пупкин крутил свою гайку на 15, да!
Мне надо статус по нужному мне функционалу от совсем других людей, с бОльшего из других команд. И я с ними и так держу прямой контакт.
Наиболее полезное времяпровождение бывает когда сразу говорится что ай пофиг на то, кто что пилил недавно, тут относительно глобальный нежданчик случился, давайте обсудим вот такую заморочку.
_AB>Расскажешь, если научишься. А с чего ты взял что я вообще собираюсь? Наоборот идёт push извести эти статусы совсем, их у нас их в общем то и не было раньше, а ввели когда народ разогнали на ковидлу и манагерам полоскали мозги верхний менеджмент. Нынче же они играют роль будильника по дням когда народ глобально работает из дома.
_AB>Сколько всего человек в вашей команде? В той, что, грубо говоря, работает над одними и теми же кусками кода/продукта
Человек 20 примерно, лень считать, команда распределена географически. Работа идёт над разными компонентами проекта, друг дружке в функционал не лазят, разишо по мелочи какой.
_AB>которая делит один и тот же план работы на неделю
У нас нет планов именно на неделю.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, landerhigh, Вы писали:
L>Стендап — он не для менеджера.
Он для "процесса"
L>В принципе, скрам методология — это не об управлении.
Это про онанизм на процесс, да.
CC>>обычно человек 10-12. L>Это уже много
Эта фигня как то работает если есть небольшая кучка долбоклюев, которой раздали ключи, назначили гайки, и они их крутят.
А когда команда состоит в основном из DRI, которые берут фичу, дизайнят, планируют, договариваются с другими командами о том, что понадобится от них, и потом пару лет её пилят, координируясь с другими feature owner как внутри как и cross-team, то эти модные методологии только под ногами путаются. Нормально работают прямые коммуникации и периодические sync митинги.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>Поэтому и существуют гибкие методологии, которые не требуют создание плана на месяцы вперед.
Надо заметить что некоторые из них настолько гЫбкие что при достижении определённого размера не могут самостоятельно стоять.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
L>>Это уже много CC>Эта фигня как то работает если есть небольшая кучка долбоклюев, которой раздали ключи, назначили гайки, и они их крутят. CC>А когда команда состоит в основном из DRI, которые берут фичу, дизайнят, планируют, договариваются с другими командами о том, что понадобится от них, и потом пару лет её пилят, координируясь с другими feature owner как внутри как и cross-team, то эти модные методологии только под ногами путаются. Нормально работают прямые коммуникации и периодические sync митинги.
Да, и в конце этих пары лет выясняется, что фича либо не нужна, либо нужна, но совсем другая, либо она "почти работает" и нужно "всего" еще два года.
Чаще всего все вместе и одновременно.
_AB>>Если его напишут и если его прочитают. И если поздно не будет на него отреагировать. CC>Ну очень нужная мне информация что вася пупкин крутил свою гайку на 15, да!
Если у вас в скрам проекта разработки блока питания к туннельному микроскопу включают кухонных работников, которые вам будут готовить обед, то все вопросы к руководству.
_AB>>которая делит один и тот же план работы на неделю CC>У нас нет планов именно на неделю.
Ну тогда скоро не будет и на квартал. А потом и на год.
Примерно так загнивание выглядит.
Здравствуйте, Pauel, Вы писали:
L>>Вначале, мы вообще предполагали, что ввиду того, что протокол дико overengineered, может существовать принципиальное ограничение, которое сделает весь проект бессмысленным или не практичным. P>Цель скрама — сделать разработку предсказуемой. С исследованием до самого конца вы этой предсказуемости не получите.
Получаем, при этом мы уменьшаем неопределенность с каждым таском. Вплоть до того, что к достижению точки, которая станет примерно серединой проекта, мы можем давать очень точные estimations для всех тасков.
P>Т.е. независимо от наличия спринтов или их отсутствия, как бы вы ни старались, вас это не приблизит к достижению целей основного проекта. P>Максимум, что вы можете добиться — большей прозрачности. Только зачем вам скрам для этого?
Я делюсь своим опытом, где скрам сработал именно так. И добиться большей прозрачности — это уже сама по себе очень серьезная ачивка.
Не надо меня пытаться ни в чем убеждать, аппелируя к примерам карго-культа, мне это неинтересно, никого я переубеждать не собираюсь.
L>>Нет. Он вообще не из айти пришел. Советую ознакомиться с историей вопроса. P>По вашему, продуктовая разработка только в айти?
Он вообще не из продуктовой разработки пришел. Вообще не из разработки.
Еще раз — почитайте уже первоисточники, пересказывать их у меня нет ни времени, ни желания.
Здравствуйте, landerhigh, Вы писали:
L>Вот, кстати, неспособность (узколобость? туннельное видение? приверженность карго-культу?) вот это понять зачастую и приводит к кошмарным попыткам применения скрама, от которых бегут, роняя тапки и потом рассказывают на форумах.
Скорее, это просто что-то, что далеко не очевидно очень и очень многим, включая тех, кто обучает, а создатели всех этих фреймворков, методологий и прочего, скорее всего, это, наборот, считают слишком очевидным, чтобы затрагивать.
Плюс обучают либо управлению операционной деятельностью (канбаны, итили и прочее), либо управлению проектами. По отдельности. Не задумываясь над их пересечением. Управлению жизненным циклом разработки программного продукта если и обучают, то эти методологии, видимо, не так широко известны. Я про них не слышал, например.
Здравствуйте, CreatorCray, Вы писали:
CC>А с чего ты взял что я вообще собираюсь?
Ну, умение сжато самому себе рассказать о том, чем ты занимаешься, для чего и есть ли у тебя какие-то зависимости от других, в чём заключается эти зависимости и знаешь ли ты, кто тебе может с ними помочь, чисто ИМХО, полезно прежде всего себе самому.
CC>У нас нет планов именно на неделю.
На период работы. Можно спринтом обозвать. Не важно.
В целом по описанию у вас какой-то бардак получается. В котором все процессы по управлению зарыты где-то внутри, а сверху что-то прикручено для галочки и ИБД. Только в таком случае стендапы это не проблема, а лишь то, что делает ваши скрытые проблемы видимыми.
Здравствуйте, CreatorCray, Вы писали:
CC>эти модные методологии только под ногами путаются. Нормально работают прямые коммуникации и периодические sync митинги.
Забавно только одно. Эти "модные методологии" вот буквально про прямые коммуникации и периодические sync митинги.
Повторюсь, буквально один из принципов, который лежит под всеми этими модными фреймворками:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Ещё более забавен другой факт — ты ни разу не упомянул общение со своими пользователями, с клиентами. По твоему описанию, вы там варитесь внутри в своём соку, разрабатывая фичи в одиночку и исходя из собственного понимания того, что нужно пользователям. Либо ты упрощаешь всё до невозможности, либо просто не понимаешь всего, что находится над тобой и даёт тебе требования, которые ты реализуешь.
Здравствуйте, Pauel, Вы писали:
P>Цель скрама — сделать разработку предсказуемой.
Нет, цель скрама другая.
Если взять самоопределение скрама, то:
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
Если перевести это на человеческий, то цель скрама — получить хоть сколь-нибудь полезный результат при решении сложных задач при помощи подстраивающихся под текущие условия процессов. Полезный результат не означает непременно работающий продукт. Например, знание, что вот это, то и то не приведёт тебя к желаемому — тоже полезный результат. Хоть и не настолько полезный, как получение желаемого.
P>С исследованием до самого конца вы этой предсказуемости не получите.
Т.к. предсказуемость не является целью скрама, это не является препятствием. Впрочем, к самому концу исследования предсказуемость уже должна быть. Ибо конец исследования — это приведение документации в порядок и повторные эксперименты, подверждающие результаты исследования.
P>Т.е. независимо от наличия спринтов или их отсутствия, как бы вы ни старались, вас это не приблизит к достижению целей основного проекта.
Это утверждение требует доказательства. И некоторых определений. Что такое "цели основного проекта" в контексте обсуждения?
P>Максимум, что вы можете добиться — большей прозрачности.
Прозрачность — это уже здорово и великолепно. Но это не максимум. Максимум, вдобавок к прозрачности, можно добиться ещё и быстрого изменения планов в зависимости от достигнутых промежуточных результатов. Вплоть до полной смены цели исследования.
P>Только зачем вам скрам для этого?
Если есть что-то ещё, работающее лучше, чем скрам — надо применять это. Что в таких условиях работает лучше, чем скрам?
P>По вашему, продуктовая разработка только в айти?
По-моему, разработка нового продукта включает в себя фазу исследования в условиях полной неопределённости. В начале проекта кроме самой идеи нет никакой информации.
Здравствуйте, Kernan, Вы писали:
K>Раз все тут продвинутые проеджекты, может посоветуете пару книг по операционному и проектному управлению, наверное.
Я не продвинутый и я ничего по книгам не посоветую, наверное.
Я считаю полезными PMBOK Guide, Agile manifesto, Scrum Guide. Их надо почитать, но уже после понимания основ и какого-то опыта. Как введение в тему они могут быть даже вредны, ИМХО.
Основы я лично осваивал через через практику/наставничество и обучающие курсы. У нас в компании есть несколько внутренних курсов по управлению проектами, плюс бесплатная подписка на udemy, на котором я нашёл интересные/полезные лично для себя курсы. Не сказал бы, что эти курсы прям что-то сверхценное, просто они пришлись очень кстати именно мне именно на том этапе. Если интересно, я поищу в истории, что именно за курсы это были. Плюс статьи, блоги, влоги.
Книги по управлению проектами я тоже читал, но не могу посоветовать ни одной, к сожалению. Может, кто-то другой посоветует.
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, Артём, Вы писали:
Аё>>Смени деятельность, будь каа радостные коллеги. Но тебе же нравится ковыряться в C++- тогда не жалуйся.
S>я реально не понимаю как можно получать удвольствие от перекладывания байтов из базы на форму и обратно
S>я сейчас с желеозом вожусь, ставлю физические эксперементы, пишу софт, разбираюсь с драйверами S>и это все в рамках одной задачи
да, все здорово, но удовлетворения то нет
а может тебе в какой-нить локхид мартин? там железок много, ракеты или самолеты программировать можно, глядишь отладишь ф35 наконец
Здравствуйте, landerhigh, Вы писали:
L>Но это в бесконечное число раз лучше неизбежного waterfall прикола, когда весь проект "все почти готово", а за неделю до дедлайна — аврал и срыв сроков на полтора года
Здравствуйте, Codealot, Вы писали:
L>>Но это в бесконечное число раз лучше неизбежного waterfall прикола, когда весь проект "все почти готово", а за неделю до дедлайна — аврал и срыв сроков на полтора года C>Ложная дилемма.
Может, в иной вселенной и ложная. В нашей дело обстоит именно так.
Вот, в соседней ветке зявили, что скрам работает плохо на задачах с неопределенностью. Мы спросили, в сравнении с чем. Но автора и след простыл.
Здравствуйте, _ABC_, Вы писали:
_AB>Скорее, это просто что-то, что далеко не очевидно очень и очень многим, включая тех, кто обучает, а создатели всех этих фреймворков, методологий и прочего, скорее всего, это, наборот, считают слишком очевидным, чтобы затрагивать.
Думаю, тут дело в классическом "у нас процесс, а все остальное — вторично"
_AB>Плюс обучают либо управлению операционной деятельностью (канбаны, итили и прочее), либо управлению проектами. По отдельности. Не задумываясь над их пересечением. Управлению жизненным циклом разработки программного продукта если и обучают, то эти методологии, видимо, не так широко известны. Я про них не слышал, например.
У нас был опытный менеджер, перешедший из разработки железа. Его хватило на 1 софтверный проект.
А с чего ты взял что я вообще собираюсь? Наоборот идёт push извести эти статусы совсем, их у нас их в общем то и не было раньше, а ввели когда народ разогнали на ковидлу и манагерам полоскали мозги верхний менеджмент. Нынче же они играют роль будильника по дням когда народ глобально работает из дома.
