Эм, а вот тот IMU, который вы используете, он работает в режиме шок-логгера, или вы просто значения с него каждые 10 мс считываете?? Если второе, то трудно судить, что же вы вообще измерили.
На философском уровне я это так понимаю — рашен бизнес в среднем не живет насколько долго, чтобы осознать вред «быстрых и дешевых» решений. По ощущениям для бизнеса, связанного с реальным производством (т.е. не чистая разработка ПО) этот срок составляет не менее четверти века — большинство российских предприятий в принципе этот срок не прошло.
Угу, нынче в части анализа рисков пришли к следующему соображению (и его уже учитывают при сертификации в ЕС например) — «никакие указания в пользовательской документации не могут считаться корректирующем мероприятием по данному риску».
например, он сам знает что пообещал сделать быстрее чем может и понял, что ошибся в оценке и ему надо свалить вину на кого-то
Ну, вообще говоря он необязательно кого-то винит, но суть в том, что, да, для рашен бизнеса в особенности характерно мечтать всех обмануть и родить ребенка за месяц (но усилиями не девяти женщин, а, например, трех). И не те самые «плохие менеджеры» стоят во главе этой идеологии, отнюдь.
Ныть на форуме
Вот уж не думал, что вы мою писанину воспринимаете как нытье… Лучше тогда прекратить это обсуждение.
Я думаю, описанный вами начальник сможет создать давление вполне и без скрама и получить то же самое.
Извините, что я отвечу только на эту часть вашего сообщения, но просто все здесь вертится вокруг именно вот этого вот — да, конечно, дело не в agile/scrum, а в условном нехорошем начальнике, который и так уже всех загнал в отказ от самого необходимого, а теперь решил «дожать» еще и за счет «гибкости».
К слову, SWOB де-факто много где существует, однако не всегда явно оговаривается и сотрудники всё-таки испытывают страх перед наказанием, не все и не всегда решаются всё-таки честно разобрать проблему и внезапно понять, что никто тебя убивать не собирается. Ну и в памяти народной же "лихие девяностые" с попаданием в рабство после порчи товары и т.п.
Угу, типичная вещь и при разборе NC, и при анализе рисков. К сожалению хорошо работает только в таких "красивых" случаях. Вот уберите разлитую жидкость — допустим он внезапно взял и уронил. Никто не знает, почему, включая его самого. И таких случаев очень много.
Совершенно, верно! Сам по себе скрам как бы не виноват, но…
Вот почему не удалась на практике идея «от каждого — по возможностям, каждому — по потребностям»? Да потому, что она физическому миру, психологии людей и структуре экономики по крайней мере на тот момент противоречила. И я склонен считать, что проблема не в реальном мире, а в этой самой идее и\или ее сторонниках.
То есть разработчикам и принципа Agile в общем и отдельных методологий в частности стоило сказать явно — сей метод заведомо НЕ работает там-то и там-то. Согласен с тем, что известный манифест например не содержит указаний на то, что это работает везде, но и не оговаривает ограничения. А стоило бы.
Ок, продолжаю быть начальником ))
By the way, все мои ответы будут непридуманными, это реальный опыт.
А вы как считаете за счет чего мы должны работать быстрее?
Надо просто лучше и больше работать, а не играть два раза в день по десять минут в пинг-понг и не читать статьи на Хабре после обеда.
Я совершенно за простоту как и вы
Тогда почему вы постоянно ноете про этот ваш «технологический долг»? Не нужна эта ваша красота архитектуры, нужно быстро!
В этом мы на одной волне
Ну так пишите же комментарии! Только не надо на это полдня тратить, мы не комментарии продаем!
Давайте потом подумаем, как сделать чтобы их было поменьше
Не потом, а сию секунду! Иначе я позвоню Самому Главному, и он вам объяснит, кому куда идти. Удовлетворенность клиентов на первом месте!
Потом прислать письмо с кратким описанием откуда возникли баги
Мне это нафиг неинтересно, откуда они возникли (хотя я и делаю вид, что интересно), просто скажите, кто виноват.
Далее не от имени начальника.
По моему опыту это не только декларируется
Само собой, это то, что реально необходимо любому руководителю, реально необходимо. Но когда следом за вопросом «когда по вашему мнению это возможно» следуют слова «нет, это нужно раньше и имеющимися ресурсами», а потом еще оказывается, что имелось в виду значительно больше результатов и никто не брал в расчет, что появятся новые и новые проекты, то это уже не «запрос на предсказуемость».
Еще заметьте что аджайл совершенно выпал из этого диалога — он просто не является фактором тут. Основные проблемы тут отношение к разработчикам, планирование и качество. Эти проблемы можно решать, хоть в аджайле, хоть в водопаде только разными средствами и в соответствующих книжках описано какими.
Так конечно же! Большинство виденных мной начальников транслируют запрос бизнеса, а запрос рашен бизнеса известно какой. Как следствие — все перечисленные проблемы. И любая из гибких методик оказывается плоха именно тем, что по общему безусловному убеждению она способствует безусловному увеличению эффективности. И вот когда, например, скрам, начинает натягиваться на имеющуюся реальность, где у вас не будет ни защиты от прессинга, ни скрам-мастера, ни вменяемой системы формирования требований, ни свободной работы с бэклогом, ничего вот этого вот, а только одни ожидания, что гибкость позволит взять от вас больше — тут и начинается адуха. То есть, буквально, вы работаете в тех же условиях, что и раньше, но ждут от вас больше.
Почему в данном случае я скепсисирую в отношении идеи, а не реализации — вспомним «от каждого — по возможностям, каждому — по потребностям». Эта прекрасная идея декларировалась реально и реально же не работала, потому что работать НЕ МОГЛА. Не учитывала обстоятельства реального мира.
То есть можно переформулировать так: «что нужно знать, чтобы понять ваши выкладки?»
Ок. Для конкретного рассмотренного примера речь может идти о базовой арифметике. Хотя на самом деле аппарат дифференциального/интегрального исчисления тоже используется при расчетах по схемотехнике.
Я говорю о математических средствах. Какой формализм использовался для выкладок?
Будучи знакомым (шапочно) с понятием математического формализма, тем не менее не могу ответить на ваш вопрос, т.к. видимо его совсем не понимаю. Скажу так — предложите варианты? :)
Смысл в том, что их очень мало, практически нет
Вот я как раз полагаю, что их не «очень мало», а «просто мало».
Ок, зафиксировали. Вот вам ответы условного начальника, условно «внедрившего» условный скрам:
1) Вы должны делать задачи быстрее.
2) Хватит изобретать и мудрствовать, пилите проще, пусть будут костыли, главное быстрее.
3) Нет, ну конечно должна быть хорошая архитектура и комментарии.
4) Так, стоп, хватит болтать, тут в Н-ске ваши прошлые баги вылезли, бегом все чинить (При этом сроки новых разработок никуда не двигаются — Прим. авт.).
Естественно начальник не дурак, и периодически градус накала снижает, журит, двигает сроки релизов — ладно, мол, подождем. Более того, даже штрафов, положим, нет! Но от выгорания и появления новых складов с костылями и протезами это не спасает, потому что прессинг и бардак все время.
Часто начальству нужна предсказуемость планирования
Само собой, и это декларируется постоянно и везде. Только при этом хочется, как в анекдоте, чтобы разработчику еще и пилу в задницу вставили — пусть заодно и дрова пилит.
Если не пытаться, то точно не работают. Если пытаться, то есть варианты
Ага, например заслужить репутацию «бессильного жалобщика». В этом нет ничего страшного itself, но деловые контакты у такого человека потом сильно усложняются, потому что — см. пирамиду Лебедева.
Кстати рашен бизнес это, в том числе, ABBYY, JetBrains, Касперский, Яндекс. Интересно, как у них.
Не могу сказать ничего о перечисленных компаниях «изнутри», но выскажу ничем не обоснованный скепсис в отношении любого рашен бизнеса и любых рашен бизнесменов.
Уволиться из говноконторы эта правильная деструкция
Ага, и бросить проект, и бросить людей, которые вместе с тобой тут ночевали, вот это вот все. То есть это конечно бывает необходимо. но от этого не легче.
Представьте, вы работаете в крупном банке. Принято решение создать мобильное приложение для мелких предпринимателей.
Блестящий пример. Только пусть это будет Росевробанк и не приложение для пбоюлов, а интернет-офис. Пока они на мне экспериментировали методами Эджайла, я просто решился наконец уйти из этого банка — не только конечно из-за интернет-офиса, но это тоже было каплей. Банк продолжал чахнуть и недавно решил лечь под Совкомбанк. Не потому ли, что в том банке вообще ВСЕ состояло из гаражных поделок?
Обычно то, что мне сильно эмоционально не нравится, меня интересует
Вот тут у многих людей как раз проблема — далеко не все изучают, например, механизмы распространения HIV, даже если страшно его боятся. Не хватит жизни на все «новости».
Интересно, что я вам предоставил несколько вариантов для обсуждения, а вы выбрали один. Почему? Деструкция не всегда плохо.
Буду говорить за рашен бизнес — другие варианты просто не работают.
Насчет деструкции — конечно оно так, «чем хуже — тем лучше», но глобально это не лучший подход.
Просто «жертва» — это такой подход к жизни. Я сам бываю таким, я знаю.
Это у всех периодически бывает, но ИМХО глобально дело не в этом, просто когда механизм воздействия на власть/руководство даже формально не прописан (а в тюрьмах он как раз прописан по крайней мере формально), то ничего не делать — естественный процесс. А вот ныть никто не запрещал, например кто-то про климат ноет, что же теперь.
Вы привели сравнения, я ответил на этом же поле
Я при этом и сразу написал, что предлагаю не продолжать.
Ну, базовые средства само собой — законы Ома и Кирхгофа. Дальше уже из знаний схемотехники все проистекает. То есть конечно тут больше физики, чем математики, но вторая есть язык первой. И в итоге ведь формула получается.
Ну и да, 99 из 100 программистов с такого рода задачами никогда не столкнется, т.к. с железом не работает
Вы преувеличиваете (или преуменьшаете, смотря с какой стороны смотреть).
Я согласен с тем, что тождественность программирования и математики является ошибкой, и когда абстрактная толпа программистов дистанцирует себя от остального общества по принципу «мы математики, а вы нет» — это выглядит смешно. Но это не повод утверждать, что математиков среди программистов ровно 1%.
То есть физически измерение производится раз в 10 миллисекунд?
Эм, а вот тот IMU, который вы используете, он работает в режиме шок-логгера, или вы просто значения с него каждые 10 мс считываете?? Если второе, то трудно судить, что же вы вообще измерили.
Думаю вам сильно повезло.
На философском уровне я это так понимаю — рашен бизнес в среднем не живет насколько долго, чтобы осознать вред «быстрых и дешевых» решений. По ощущениям для бизнеса, связанного с реальным производством (т.е. не чистая разработка ПО) этот срок составляет не менее четверти века — большинство российских предприятий в принципе этот срок не прошло.
Ну, вообще говоря он необязательно кого-то винит, но суть в том, что, да, для рашен бизнеса в особенности характерно мечтать всех обмануть и родить ребенка за месяц (но усилиями не девяти женщин, а, например, трех). И не те самые «плохие менеджеры» стоят во главе этой идеологии, отнюдь.
Вот уж не думал, что вы мою писанину воспринимаете как нытье… Лучше тогда прекратить это обсуждение.
Извините, что я отвечу только на эту часть вашего сообщения, но просто все здесь вертится вокруг именно вот этого вот — да, конечно, дело не в agile/scrum, а в условном нехорошем начальнике, который и так уже всех загнал в отказ от самого необходимого, а теперь решил «дожать» еще и за счет «гибкости».
Если так — то да. А если один раз? Списать на случайность?
К слову, SWOB де-факто много где существует, однако не всегда явно оговаривается и сотрудники всё-таки испытывают страх перед наказанием, не все и не всегда решаются всё-таки честно разобрать проблему и внезапно понять, что никто тебя убивать не собирается. Ну и в памяти народной же "лихие девяностые" с попаданием в рабство после порчи товары и т.п.
Угу, типичная вещь и при разборе NC, и при анализе рисков. К сожалению хорошо работает только в таких "красивых" случаях. Вот уберите разлитую жидкость — допустим он внезапно взял и уронил. Никто не знает, почему, включая его самого. И таких случаев очень много.
Совершенно, верно! Сам по себе скрам как бы не виноват, но…
Вот почему не удалась на практике идея «от каждого — по возможностям, каждому — по потребностям»? Да потому, что она физическому миру, психологии людей и структуре экономики по крайней мере на тот момент противоречила. И я склонен считать, что проблема не в реальном мире, а в этой самой идее и\или ее сторонниках.
То есть разработчикам и принципа Agile в общем и отдельных методологий в частности стоило сказать явно — сей метод заведомо НЕ работает там-то и там-то. Согласен с тем, что известный манифест например не содержит указаний на то, что это работает везде, но и не оговаривает ограничения. А стоило бы.
By the way, все мои ответы будут непридуманными, это реальный опыт.
Надо просто лучше и больше работать, а не играть два раза в день по десять минут в пинг-понг и не читать статьи на Хабре после обеда.
Тогда почему вы постоянно ноете про этот ваш «технологический долг»? Не нужна эта ваша красота архитектуры, нужно быстро!
Ну так пишите же комментарии! Только не надо на это полдня тратить, мы не комментарии продаем!
Не потом, а сию секунду! Иначе я позвоню Самому Главному, и он вам объяснит, кому куда идти. Удовлетворенность клиентов на первом месте!
Мне это нафиг неинтересно, откуда они возникли (хотя я и делаю вид, что интересно), просто скажите, кто виноват.
Далее не от имени начальника.
Само собой, это то, что реально необходимо любому руководителю, реально необходимо. Но когда следом за вопросом «когда по вашему мнению это возможно» следуют слова «нет, это нужно раньше и имеющимися ресурсами», а потом еще оказывается, что имелось в виду значительно больше результатов и никто не брал в расчет, что появятся новые и новые проекты, то это уже не «запрос на предсказуемость».
Так конечно же! Большинство виденных мной начальников транслируют запрос бизнеса, а запрос рашен бизнеса известно какой. Как следствие — все перечисленные проблемы. И любая из гибких методик оказывается плоха именно тем, что по общему безусловному убеждению она способствует безусловному увеличению эффективности. И вот когда, например, скрам, начинает натягиваться на имеющуюся реальность, где у вас не будет ни защиты от прессинга, ни скрам-мастера, ни вменяемой системы формирования требований, ни свободной работы с бэклогом, ничего вот этого вот, а только одни ожидания, что гибкость позволит взять от вас больше — тут и начинается адуха. То есть, буквально, вы работаете в тех же условиях, что и раньше, но ждут от вас больше.
Почему в данном случае я скепсисирую в отношении идеи, а не реализации — вспомним «от каждого — по возможностям, каждому — по потребностям». Эта прекрасная идея декларировалась реально и реально же не работала, потому что работать НЕ МОГЛА. Не учитывала обстоятельства реального мира.
Ок. Для конкретного рассмотренного примера речь может идти о базовой арифметике. Хотя на самом деле аппарат дифференциального/интегрального исчисления тоже используется при расчетах по схемотехнике.
Будучи знакомым (шапочно) с понятием математического формализма, тем не менее не могу ответить на ваш вопрос, т.к. видимо его совсем не понимаю. Скажу так — предложите варианты? :)
Вот я как раз полагаю, что их не «очень мало», а «просто мало».
1) Вы должны делать задачи быстрее.
2) Хватит изобретать и мудрствовать, пилите проще, пусть будут костыли, главное быстрее.
3) Нет, ну конечно должна быть хорошая архитектура и комментарии.
4) Так, стоп, хватит болтать, тут в Н-ске ваши прошлые баги вылезли, бегом все чинить (При этом сроки новых разработок никуда не двигаются — Прим. авт.).
Естественно начальник не дурак, и периодически градус накала снижает, журит, двигает сроки релизов — ладно, мол, подождем. Более того, даже штрафов, положим, нет! Но от выгорания и появления новых складов с костылями и протезами это не спасает, потому что прессинг и бардак все время.
Само собой, и это декларируется постоянно и везде. Только при этом хочется, как в анекдоте, чтобы разработчику еще и пилу в задницу вставили — пусть заодно и дрова пилит.
Ну а какое именно?
Вот мы ноем — ааа, сроки задает начальник, в спринт не успеваем, нас штрафуют. Что предложить?
Пример другого способа? Не вообще, а конкретно применительно к этому комментарию.
Вполне вероятно.
Манипуляция с чьей стороны в данном случае?
Ага, например заслужить репутацию «бессильного жалобщика». В этом нет ничего страшного itself, но деловые контакты у такого человека потом сильно усложняются, потому что — см. пирамиду Лебедева.
Не могу сказать ничего о перечисленных компаниях «изнутри», но выскажу ничем не обоснованный скепсис в отношении любого рашен бизнеса и любых рашен бизнесменов.
Ага, и бросить проект, и бросить людей, которые вместе с тобой тут ночевали, вот это вот все. То есть это конечно бывает необходимо. но от этого не легче.
Блестящий пример. Только пусть это будет Росевробанк и не приложение для пбоюлов, а интернет-офис. Пока они на мне экспериментировали методами Эджайла, я просто решился наконец уйти из этого банка — не только конечно из-за интернет-офиса, но это тоже было каплей. Банк продолжал чахнуть и недавно решил лечь под Совкомбанк. Не потому ли, что в том банке вообще ВСЕ состояло из гаражных поделок?
Вот тут у многих людей как раз проблема — далеко не все изучают, например, механизмы распространения HIV, даже если страшно его боятся. Не хватит жизни на все «новости».
Буду говорить за рашен бизнес — другие варианты просто не работают.
Насчет деструкции — конечно оно так, «чем хуже — тем лучше», но глобально это не лучший подход.
Это у всех периодически бывает, но ИМХО глобально дело не в этом, просто когда механизм воздействия на власть/руководство даже формально не прописан (а в тюрьмах он как раз прописан по крайней мере формально), то ничего не делать — естественный процесс. А вот ныть никто не запрещал, например кто-то про климат ноет, что же теперь.
Я при этом и сразу написал, что предлагаю не продолжать.
Ну, базовые средства само собой — законы Ома и Кирхгофа. Дальше уже из знаний схемотехники все проистекает. То есть конечно тут больше физики, чем математики, но вторая есть язык первой. И в итоге ведь формула получается.
Вы преувеличиваете (или преуменьшаете, смотря с какой стороны смотреть).
Я согласен с тем, что тождественность программирования и математики является ошибкой, и когда абстрактная толпа программистов дистанцирует себя от остального общества по принципу «мы математики, а вы нет» — это выглядит смешно. Но это не повод утверждать, что математиков среди программистов ровно 1%.