Как много вразуметельных слов! Не могу голосовать, но подписываюсь под каждым вашим словом. Именно это и есть корень проблемы. Но будет ли она решёна - вот в чем вопрос.
язык программирования - это не есть базовые знания.
Здесь Вы и правы и в тот-же момент нет. Обьясню. Какой-то язык програмирования Со всеми его возможностями и функциями - да, он может быть и не должен быть базой. И не каждый учитель сможет выбрать именно те базовые элементы из языка, чтобы заинтересовать, а не охладить интерес к програмированию/ит-технологиям.
Но сами принципы языков, логическое мышление - может быть без практики или на примере того языка, которым в состоянии показать учитель - это я считаю сегодня всё равно базой. Програмирование - оно такое разное. От установить будильник на часах, запрограмировать адрес в навигации, расчёт в excel, организация базы данных на примере листа контактов в том-же мобильнике, logo черепашку, lego mindstorm, scratch итд. до настоящего програмирования на ассемблере. Я делал практику ученикам на платинах Arduino. Были просто рады, что под моим указанием, но всё равно своими руками - научили устройство вкючать/выключать светодиоды по нажатию кнопок, измерять и показывать на дисплее растояние до предметов или температуру в помещении. Поэтому именно понятие програмирования - оно должно быть всё равно основой. А ответвления влево и в право - это уже удел учителя по его усмотрению.
В Германии в старших классах изучают програмирование например с помощью www.greenfoot.org и могу сказать, что очень продуманно - от основ, до ООП - разная сложность в языке позволяет каждого ученика по своему заинтересовать.
В 88-м году обучался информатике учительницой по-математике. Конечно никаких компьютеров не было, и как работает компьютер - всё расказывала на пальцах. Но так, как она и сама его отродясь не видела, то и рассказывала так неинтерессно, что этот предмет терпеть не мог. В 89-переехал в другой город город и там информатику преподавал инженер из компьютерного центра, отвечающего за погоду. Он рассказывал, как работают компьютеры, учил програмированию на FORTRAN(е). Да так увлекательно и интересно, что это стало судьбоносным влиянием на многих из нашего класса. Для меня очень сильно.
После прочитаного могу добавить ко многим, кто здесь уже высказался. Информационные технологии - это база. Она нужна. А вот сверху, и програмирование, и наброски каких-либо веб-страничек и многое другое - учитель должен по ходу дела интегрировать. Если класс продвинутый и в состоянии это переварить, то всегда стоит увлекательно показать, дать "пощупать".
Со отступом на то, что это не школа, но приведу пример из области моего преподавания в университете (в Германии). Преподаю модуль "BigData" - так вот по ходу дела, если студенты в большинстве своём не осилят, то и програмироваие под Hadoop, Kafka, NoSQL базы данных , AWS, Machine Learning итд. - только вскольз и без практики, но для понимания - хватает. Если-же сильный состав (а такое тоже иногда бывает), то и написание MapReduce функций не проблема.
с модулем, который тоже предлагаю - "Harware и информационные технологии", так вот некоторые доценты предлагают студентам метериалы, как работает компьютер на примере ламп и реле. Потому что так сами учили. И посмотришь их конспекты, мало чего из проекции на сегодня. И описание работы компьютеров или алгоритмов с помощью картинок из 70-годов.
Надо быть чуточку гибким. Но в одном соглашусь с автором - учителя должны свои навыки обновлять и увеличивать. Смотреть по сторонам. Потому что только так появляется увереность в использовании технологий и та сама гибкость в выборе того или иного пути будет всегда возможна.
А предложил свеому сокурснику, который в школе в Казахстане преподаёт "Информатику" сделать видео-мост, где могли бы поделится опытом, позадавать друг-другу вопросы - то никакой реакции.
Как вы можете на 2-м месяце определить, насколько сдвинут некоторые изменения весь срок? Может быть у вас и правда стеклянный шар и там всё будет видно.
Но у меня как то не получается согласовать изменения/общий срок/неизменение бюджета итд. В момент изменений все уверены что риски вроде всегда есть, но их не воспринимают как основопалагающие. И только, когда сроки сдачи еально начинают поджимать, вот тогда "..а почему вы не конкретно давали понять, что срок можнт срывается,? И не важно, что мы там хотели, вы же обещали...".
У меня сложилась такая вещь, что или общий план (roadmap) с конкретным сроком и бюджетом. Но без изменений по ходу дела. Или конкретное количество заданий на один спринт (или PI), и общее представление, но без ответственности за общий план, срок и бюджет.
Не, ну как может быть изначальный срок обязательными, если по дороге все/многое может меняться? Ведь воочию вижу каждый день именно неподтвеождение этого тезиса.
Или есть сроки, тогда всякие изменения по ходу не имеют место быть, или постоянные изменения, но тогда срок только действует на них, но никак на изначальный срок.
Во втором случае вы берёте ТЗ, делаете что-то месяц, потом показываете результат заказчику и в случае необходимости изменяете ТЗ. И так двенадцать раз.
Вашего вопроса не понял. Это же ваши слова выше, и они имеют смысл. Потому что в этом то и суть agile, что не через год встречаются заказчик и исполнитель. Но если это так и изменения будут по ходу дела проявляться, то тогда как можно говорить, что что-то будет длится год если не известно, что будет сделано.
Короче противоречие , но мало кого это волнует. И если это не будет работать, то проблему будут не в методике искать, а в неправильном использовании agile. А сама противоречивая методика не имеет права поддаваться сомнению.
С вами согласен. Сам обожаю ассемблер. За возможности, за красоту и за самоудовлетворение. Хотя в большинстве своём люди всё же покупают компьютер, а не собирают его на уровне активных и пасивных эллементов сами. Хотя такие тоже имеются. Но увы, количество таких стойких и любящих своё дело всё меньше и меньше.
Вместе с этим процессы разработки продукта становятся прозрачнее и уменьшаются риски, что проект не будет принят.
Мне вот интересно, как вообще себе предствляют ситуацию те, кто такое пишет?
Принят - это значит, что сделано то, о чём договорились. Договорились - это значит описали ожидаемую систему/продукт с её параметрами и функциями. Если договора на конкретные детали нет, а детали обсуждаются каждые 1-10 недель, где вообще находится граница, когда будет что-то принято или нет? Ведь в каждом спринте всё меняется, иногда переворачивается вверх ногами.Как люди себе представляют себе само выражение "принят" в таком случае?
Waterfall — условно существующая каскадная модель разработки. Здесь процесс воспринимается как поток, а переход от одного этапа к другому происходит только после успешного завершения предыдущего.
А не чё, что водопад уже с 60-70-х годох в чистом виде нигде не используется, а для популиризации agile его везде для сравнения за уши тянут - никого не трогает.
Потому что на предполагаемые проблемы с чистой моделью водопада было введено множество модифицированных моделей водопада. Эти модели могут отражать некоторые или все критические замечания по поводу «чистой» модели водопада.
К ним относятся модели
быстрого развития (modified waterfalls), которые Стив МакКоннелл называет «модифицированными водопадами»
«модель сашими» (sashimi model) Питера ДеГрейса (водопад с перекрывающимися фазами)
водопад с подпроектами и водопад с уменьшением риска. Существуют и другие комбинации моделей разработки программного обеспечения, такие как «инкрементная водопадная модель» итд.
И все эти модели уже есть гибкие. Т.е. если бы сравнение шло с ними, то в некоторых местах не видно было-бы никакой разницы. Но нет, надо сравнивать с динозаврами, как в СССР всегда сравнивали с 1913-м годом, чтобы воочию показать, какой "огромный" прогресс имеет место быть.
Автор путает безопасность реализации с безопасностью программирования. Visual Studio тоже безопасный инструмент, если только понимать, что программисту разрешено делать с инструментом то, что инструментом предусмотрено. Но. Это не мешает ему в коде извращаться так, как ему захочется.
талмуты ненужной информации держал в руках, но и они - и их полное отсутствие - не есть решение. Это два радикальных полюса, которых надо остерегаться.
А вы видили-ли в agile, что кто-то несёт вообще какую-нибудь ответственность? Такого понятия там нет. Прям социализм какой-то - каждый решает сам, что делать. Ну или коллектив. А коллектив - это то ещё состояние общества. Оно отображает и преумножает все сильные, но и все слабые стороны людей. И коллектив сообща тоже всегда сходит с пути. Итд.
Потому что самодисциплина каждого в отвельности и группы в целом будет всё меньше и меньше работать, если со стороны не будет какой-нибудь "плётки".
Ну тогда всё сводится к статистике как в анекдоте по поводу вероятности увидеть динозавра на Красной площади и ответу - 50 на 50, мол или увижу или нет.
Очень сильная мотивация у людей, которые вот-вот накаплиют опыт, которые молоды, видят перспективы роста. Когда-же происходит созревания человека, то он смотрит на мир совсем иными глазами, и пытается из инвестиций в прошлом сделать капитал в будущем. И вот тут аджайл не даёт ответов. В надежде, что на замену всегда много других придёт. А проблема накопления потому что сегодня получить базовый опыт не так легко с теми темпами, которые сегодня, в мире. Agile в этом случае не только ответ на вызовы сегодня, но и триггер ухудшения для вызовов в будущем. Потому что координально ломает устои не предоставляя взамен основ, а только скрывает проблемы с поля зрения. Один только пункт из манифест что работающая система стоит ваше, чем документация - это просто пиизыв для тех, кто никогда этого не собирался делать, за это и не браться. Итд.
Не соглашусь в принципе. Почитайте книги по Project Management. Это целая наука. С формулами для расчёта рисков, возможной реализации, планирования, работа со stakeholder(ами) итд. А здесь (и не только здесь) общие фразы - ..понимайте, не волнуйтесь, не контролируйте, поддерживайте, используйте мотивацию итд. Поэтому все сложные проекты, которые я когда-либо пережил и которые пытались с agile(м) провести - это были провалы. По времени, по качеству и всё возвращалось на круги своя. Но терялись специалисты, терялось время, терялись деньги. Потому что как-то так так и работает - как-то так.Извините - их более детально описать не имею права. Но поверьте моему мнению на слово.
Потому что все люди разные. У каждого свои цели. Один ленивый, другой трудяга, один хитрый, другой простодушный, один - серая мышка, другой хочет быть звездой на проект-сцене, один - живёт один и ему немного надо. И в деньгах и по времени он готов днём и ночью работать. А у другого - семья, дети с их проблемами или болезнями итд. Уравниловка никогда не работает. Тем более на долгое время. Это противоречит нашему природой заложеной принципу. Я несколько раз бывал в фирме, которая работает по принципу - плоская хирархия. Так вот. Там средний возраст - 30 лет. А почему. Ну ответ кроется в сути agile. Когда-то люди мечтают иметь больше, чем просто безконтрольность со стороны "несправедливых" начальников и свободные руки в выборе задач. Когда люди взрослеют и понимают, что это конструкция им этого не позволит добиться. Поэтому уходят. Сказать, что это работает - это значит сказать не правду. Хотя именно в этой фирме - это работает. Но это больше похоже на принцип, когда выставляется на показ то, что на самом деле вырвано из общего правила.
И мотиваций должно быть тонна с горкой. Одному леденца хватит, другому грамоты, как лучшему работнику месяца, а третьего надо и масажировать и машину предоставить итд. Потому что он того может стоить. Почему? Ну не знаю - а я всю свою жизнь сталкиваюсь с людьми, которые очень разный уровень мастерства к различным темам или ремеслам имеют. Програмы писать может каждый. Хорошие намного меньше. Ценные или стреляющие идеи имеют и могут единицы.
Один продавец может продать кучу машин ,а другой намного меньше. Оба имеют одинаковые условия, но знают и работают по разному. И почему я не должен поощерять хорошего продавца/программиста/дизайнера итд. Об этом ни слова - хотя пост о мотивации.
По иронии судьбы, чем больше руководство пытается управлять и контролировать, тем меньше вероятность того, что случится прирост в производительности.
Мне это кажется выдумкой. Слева и справа - от булочной за углом до Теслы только и наблюдаю как - структура, контроль, дисциплина, правильный подбор людей, талант и в исполнении и в управлении - приводят к целям, которые устанавливаются. Не важно прирост, создавание чего-либо или завоевание новых рынков сбыта.
Есть какие-нибудь доказательства Вашим словам? Не ссылки на такие-же высказывания в других книжках по agile, а именно статистика.
Вдохновляйте: объясняйте почему нужно делать работу, а не что нужно делать. Давайте командам решать проблемы самим, но не давайте им планы, которым нужно следовать.
Всё опять свелось к советам менеджерам, как сделать что-то agile. Но вы так и не обьяснили, как мотивируются люди, работая в агиле. Да, есть такое - как совместное решение задач. И гармоничным коллектив - тоже хорошая вещь. Но каждый идёт/едет вечером домой. Где его ждёт жена и дети. Он с ними хочет поехать в отпуск, он хочет себе купить новую и дорогую машину и планирует профинансировать покупку дома. Итак. В чём заключается мотивация человека, который хочет не сегодня, но завтра себе больше позволить, чем сегодня?
Откажитесь от контроля: чем больше вы пытаетесь контролировать сотрудников, тем менее автономными становятся команды и тем меньше мотивации остаётся у их членов.
Хорошо, он работает в agile-команде. С кем он будет разговаривать насчёт повышения зарплаты? Со своим начальником по линии. Но тот с ним не оговаривал ни цели, ни способ их достижения. Он его не контролирует и не может как-либо повлиять на него. Значит начальник по линии не может адекватно с ним вести разговоры развитию в росте, по повышению зарплаты. В какой-то момент эти самые линии вообще должны исчезнуть по идее agile.
Мотивалки, типа "ты работаешь над самым прекрассным проектом и с самым хорошим agile-коллективом" когда-то перестают быть чем-то особенным. На Вдохновляйте - далеко не уедешь. Какие есть возможности роста в agile? Роста в виде значимости? Финасового роста?
В этом и есть проблема всех этих блок-схема-редакторов. С их помощью можно кое-что нарисовать, но не больше. В 90'х были такие case редакторы, оно они не стрельнули. Потому что ими генерированный код надо было допиливать или видоизменять. И как только один раз такое делалось, то терялась вся суть использования этого case редактора.
Графические редакторы только там нужны, где все то, что с ними создаётся и есть то что исполняется. Те. они должны представлять из себя нааамного большую абстракцию, чем простой язык программирования. Вот тут уже кем-то указаный MatLab или например редакторы обьектов, цветов и стилей в том же Photoshop. Или редакторы 3D или какой-нибудь CAD программы, или редакторы Workflow процессов. Вон например описание инфраструктуры будущей архитектуры приложений AWS использует похожий принцип, когда используемые элементы как квадратики, кружочки и линии представляют из себя целые горы строчек в настоящем языке программирования. Но они от пользователя "спрятаны". Вот тогда есть толк от такого редактора. Когда он упрощает сложность каких-либо процессов. Когда-же он просто видоизменяет, то что уже есть, но требует всё равно столько же суппорта и при этом уже является 150-м вариантом на рынке, то и успеха у такого начинания мало. Как раз сам работаю над таким framework для своей специализированной идеи. Именно для узкого коридора возможностей, где настоящее програмирование и правда есть муторное дело.
Как много вразуметельных слов! Не могу голосовать, но подписываюсь под каждым вашим словом. Именно это и есть корень проблемы. Но будет ли она решёна - вот в чем вопрос.
Здесь Вы и правы и в тот-же момент нет. Обьясню. Какой-то язык програмирования Со всеми его возможностями и функциями - да, он может быть и не должен быть базой. И не каждый учитель сможет выбрать именно те базовые элементы из языка, чтобы заинтересовать, а не охладить интерес к програмированию/ит-технологиям.
Но сами принципы языков, логическое мышление - может быть без практики или на примере того языка, которым в состоянии показать учитель - это я считаю сегодня всё равно базой. Програмирование - оно такое разное. От установить будильник на часах, запрограмировать адрес в навигации, расчёт в excel, организация базы данных на примере листа контактов в том-же мобильнике, logo черепашку, lego mindstorm, scratch итд. до настоящего програмирования на ассемблере. Я делал практику ученикам на платинах Arduino. Были просто рады, что под моим указанием, но всё равно своими руками - научили устройство вкючать/выключать светодиоды по нажатию кнопок, измерять и показывать на дисплее растояние до предметов или температуру в помещении. Поэтому именно понятие програмирования - оно должно быть всё равно основой. А ответвления влево и в право - это уже удел учителя по его усмотрению.
В Германии в старших классах изучают програмирование например с помощью www.greenfoot.org и могу сказать, что очень продуманно - от основ, до ООП - разная сложность в языке позволяет каждого ученика по своему заинтересовать.
В 88-м году обучался информатике учительницой по-математике. Конечно никаких компьютеров не было, и как работает компьютер - всё расказывала на пальцах. Но так, как она и сама его отродясь не видела, то и рассказывала так неинтерессно, что этот предмет терпеть не мог. В 89-переехал в другой город город и там информатику преподавал инженер из компьютерного центра, отвечающего за погоду. Он рассказывал, как работают компьютеры, учил програмированию на FORTRAN(е). Да так увлекательно и интересно, что это стало судьбоносным влиянием на многих из нашего класса. Для меня очень сильно.
После прочитаного могу добавить ко многим, кто здесь уже высказался. Информационные технологии - это база. Она нужна. А вот сверху, и програмирование, и наброски каких-либо веб-страничек и многое другое - учитель должен по ходу дела интегрировать. Если класс продвинутый и в состоянии это переварить, то всегда стоит увлекательно показать, дать "пощупать".
Со отступом на то, что это не школа, но приведу пример из области моего преподавания в университете (в Германии). Преподаю модуль "BigData" - так вот по ходу дела, если студенты в большинстве своём не осилят, то и програмироваие под Hadoop, Kafka, NoSQL базы данных , AWS, Machine Learning итд. - только вскольз и без практики, но для понимания - хватает. Если-же сильный состав (а такое тоже иногда бывает), то и написание MapReduce функций не проблема.
с модулем, который тоже предлагаю - "Harware и информационные технологии", так вот некоторые доценты предлагают студентам метериалы, как работает компьютер на примере ламп и реле. Потому что так сами учили. И посмотришь их конспекты, мало чего из проекции на сегодня. И описание работы компьютеров или алгоритмов с помощью картинок из 70-годов.
Надо быть чуточку гибким. Но в одном соглашусь с автором - учителя должны свои навыки обновлять и увеличивать. Смотреть по сторонам. Потому что только так появляется увереность в использовании технологий и та сама гибкость в выборе того или иного пути будет всегда возможна.
А предложил свеому сокурснику, который в школе в Казахстане преподаёт "Информатику" сделать видео-мост, где могли бы поделится опытом, позадавать друг-другу вопросы - то никакой реакции.
Нет времени объяснять, но это .......... убрать, а это ......... вставить (нужное по усмотрению внести).
Как вы можете на 2-м месяце определить, насколько сдвинут некоторые изменения весь срок? Может быть у вас и правда стеклянный шар и там всё будет видно.
Но у меня как то не получается согласовать изменения/общий срок/неизменение бюджета итд. В момент изменений все уверены что риски вроде всегда есть, но их не воспринимают как основопалагающие. И только, когда сроки сдачи еально начинают поджимать, вот тогда "..а почему вы не конкретно давали понять, что срок можнт срывается,? И не важно, что мы там хотели, вы же обещали...".
У меня сложилась такая вещь, что или общий план (roadmap) с конкретным сроком и бюджетом. Но без изменений по ходу дела. Или конкретное количество заданий на один спринт (или PI), и общее представление, но без ответственности за общий план, срок и бюджет.
Не, ну как может быть изначальный срок обязательными, если по дороге все/многое может меняться? Ведь воочию вижу каждый день именно неподтвеождение этого тезиса.
Или есть сроки, тогда всякие изменения по ходу не имеют место быть, или постоянные изменения, но тогда срок только действует на них, но никак на изначальный срок.
Вашего вопроса не понял. Это же ваши слова выше, и они имеют смысл. Потому что в этом то и суть agile, что не через год встречаются заказчик и исполнитель. Но если это так и изменения будут по ходу дела проявляться, то тогда как можно говорить, что что-то будет длится год если не известно, что будет сделано.
Короче противоречие , но мало кого это волнует. И если это не будет работать, то проблему будут не в методике искать, а в неправильном использовании agile. А сама противоречивая методика не имеет права поддаваться сомнению.
С вами согласен. Сам обожаю ассемблер. За возможности, за красоту и за самоудовлетворение. Хотя в большинстве своём люди всё же покупают компьютер, а не собирают его на уровне активных и пасивных эллементов сами. Хотя такие тоже имеются. Но увы, количество таких стойких и любящих своё дело всё меньше и меньше.
Мне думается, что когда 12 раз, то вероятность того, что 12 раз или год - непланируемы. потому что ...
расчитывается, когда знаешь, что делать.Когда знаешь, что делать, но по ходу дела это меняется, размерность год - теряет смысл.
Мне вот интересно, как вообще себе предствляют ситуацию те, кто такое пишет?
Принят - это значит, что сделано то, о чём договорились. Договорились - это значит описали ожидаемую систему/продукт с её параметрами и функциями. Если договора на конкретные детали нет, а детали обсуждаются каждые 1-10 недель, где вообще находится граница, когда будет что-то принято или нет? Ведь в каждом спринте всё меняется, иногда переворачивается вверх ногами.Как люди себе представляют себе само выражение "принят" в таком случае?
А не чё, что водопад уже с 60-70-х годох в чистом виде нигде не используется, а для популиризации agile его везде для сравнения за уши тянут - никого не трогает.
Потому что на предполагаемые проблемы с чистой моделью водопада было введено множество модифицированных моделей водопада. Эти модели могут отражать некоторые или все критические замечания по поводу «чистой» модели водопада.
К ним относятся модели
быстрого развития (modified waterfalls), которые Стив МакКоннелл называет «модифицированными водопадами»
«модель сашими» (sashimi model) Питера ДеГрейса (водопад с перекрывающимися фазами)
водопад с подпроектами и водопад с уменьшением риска. Существуют и другие комбинации моделей разработки программного обеспечения, такие как «инкрементная водопадная модель» итд.
И все эти модели уже есть гибкие. Т.е. если бы сравнение шло с ними, то в некоторых местах не видно было-бы никакой разницы. Но нет, надо сравнивать с динозаврами, как в СССР всегда сравнивали с 1913-м годом, чтобы воочию показать, какой "огромный" прогресс имеет место быть.
Автор путает безопасность реализации с безопасностью программирования. Visual Studio тоже безопасный инструмент, если только понимать, что программисту разрешено делать с инструментом то, что инструментом предусмотрено. Но. Это не мешает ему в коде извращаться так, как ему захочется.
талмуты ненужной информации держал в руках, но и они - и их полное отсутствие - не есть решение. Это два радикальных полюса, которых надо остерегаться.
А вы видили-ли в agile, что кто-то несёт вообще какую-нибудь ответственность? Такого понятия там нет. Прям социализм какой-то - каждый решает сам, что делать. Ну или коллектив. А коллектив - это то ещё состояние общества. Оно отображает и преумножает все сильные, но и все слабые стороны людей. И коллектив сообща тоже всегда сходит с пути. Итд.
Потому что самодисциплина каждого в отвельности и группы в целом будет всё меньше и меньше работать, если со стороны не будет какой-нибудь "плётки".
Ну тогда всё сводится к статистике как в анекдоте по поводу вероятности увидеть динозавра на Красной площади и ответу - 50 на 50, мол или увижу или нет.
Очень сильная мотивация у людей, которые вот-вот накаплиют опыт, которые молоды, видят перспективы роста. Когда-же происходит созревания человека, то он смотрит на мир совсем иными глазами, и пытается из инвестиций в прошлом сделать капитал в будущем. И вот тут аджайл не даёт ответов. В надежде, что на замену всегда много других придёт. А проблема накопления потому что сегодня получить базовый опыт не так легко с теми темпами, которые сегодня, в мире. Agile в этом случае не только ответ на вызовы сегодня, но и триггер ухудшения для вызовов в будущем. Потому что координально ломает устои не предоставляя взамен основ, а только скрывает проблемы с поля зрения. Один только пункт из манифест что работающая система стоит ваше, чем документация - это просто пиизыв для тех, кто никогда этого не собирался делать, за это и не браться. Итд.
А что лучше - велосипед или подводная лодка? Передвигаться оба могут. Но. Смотря для каких задач.
Не соглашусь в принципе. Почитайте книги по Project Management. Это целая наука. С формулами для расчёта рисков, возможной реализации, планирования, работа со stakeholder(ами) итд. А здесь (и не только здесь) общие фразы - ..понимайте, не волнуйтесь, не контролируйте, поддерживайте, используйте мотивацию итд. Поэтому все сложные проекты, которые я когда-либо пережил и которые пытались с agile(м) провести - это были провалы. По времени, по качеству и всё возвращалось на круги своя. Но терялись специалисты, терялось время, терялись деньги. Потому что как-то так так и работает - как-то так.Извините - их более детально описать не имею права. Но поверьте моему мнению на слово.
Потому что все люди разные. У каждого свои цели. Один ленивый, другой трудяга, один хитрый, другой простодушный, один - серая мышка, другой хочет быть звездой на проект-сцене, один - живёт один и ему немного надо. И в деньгах и по времени он готов днём и ночью работать. А у другого - семья, дети с их проблемами или болезнями итд. Уравниловка никогда не работает. Тем более на долгое время. Это противоречит нашему природой заложеной принципу. Я несколько раз бывал в фирме, которая работает по принципу - плоская хирархия. Так вот. Там средний возраст - 30 лет. А почему. Ну ответ кроется в сути agile. Когда-то люди мечтают иметь больше, чем просто безконтрольность со стороны "несправедливых" начальников и свободные руки в выборе задач. Когда люди взрослеют и понимают, что это конструкция им этого не позволит добиться. Поэтому уходят. Сказать, что это работает - это значит сказать не правду. Хотя именно в этой фирме - это работает. Но это больше похоже на принцип, когда выставляется на показ то, что на самом деле вырвано из общего правила.
И мотиваций должно быть тонна с горкой. Одному леденца хватит, другому грамоты, как лучшему работнику месяца, а третьего надо и масажировать и машину предоставить итд. Потому что он того может стоить. Почему? Ну не знаю - а я всю свою жизнь сталкиваюсь с людьми, которые очень разный уровень мастерства к различным темам или ремеслам имеют. Програмы писать может каждый. Хорошие намного меньше. Ценные или стреляющие идеи имеют и могут единицы.
Один продавец может продать кучу машин ,а другой намного меньше. Оба имеют одинаковые условия, но знают и работают по разному. И почему я не должен поощерять хорошего продавца/программиста/дизайнера итд. Об этом ни слова - хотя пост о мотивации.
Мне это кажется выдумкой. Слева и справа - от булочной за углом до Теслы только и наблюдаю как - структура, контроль, дисциплина, правильный подбор людей, талант и в исполнении и в управлении - приводят к целям, которые устанавливаются. Не важно прирост, создавание чего-либо или завоевание новых рынков сбыта.
Есть какие-нибудь доказательства Вашим словам? Не ссылки на такие-же высказывания в других книжках по agile, а именно статистика.
Всё опять свелось к советам менеджерам, как сделать что-то agile. Но вы так и не обьяснили, как мотивируются люди, работая в агиле. Да, есть такое - как совместное решение задач. И гармоничным коллектив - тоже хорошая вещь. Но каждый идёт/едет вечером домой. Где его ждёт жена и дети. Он с ними хочет поехать в отпуск, он хочет себе купить новую и дорогую машину и планирует профинансировать покупку дома. Итак. В чём заключается мотивация человека, который хочет не сегодня, но завтра себе больше позволить, чем сегодня?
Хорошо, он работает в agile-команде. С кем он будет разговаривать насчёт повышения зарплаты? Со своим начальником по линии. Но тот с ним не оговаривал ни цели, ни способ их достижения. Он его не контролирует и не может как-либо повлиять на него. Значит начальник по линии не может адекватно с ним вести разговоры развитию в росте, по повышению зарплаты. В какой-то момент эти самые линии вообще должны исчезнуть по идее agile.
Мотивалки, типа "ты работаешь над самым прекрассным проектом и с самым хорошим agile-коллективом" когда-то перестают быть чем-то особенным. На Вдохновляйте - далеко не уедешь. Какие есть возможности роста в agile? Роста в виде значимости? Финасового роста?
В этом и есть проблема всех этих блок-схема-редакторов. С их помощью можно кое-что нарисовать, но не больше. В 90'х были такие case редакторы, оно они не стрельнули. Потому что ими генерированный код надо было допиливать или видоизменять. И как только один раз такое делалось, то терялась вся суть использования этого case редактора.
Графические редакторы только там нужны, где все то, что с ними создаётся и есть то что исполняется. Те. они должны представлять из себя нааамного большую абстракцию, чем простой язык программирования. Вот тут уже кем-то указаный MatLab или например редакторы обьектов, цветов и стилей в том же Photoshop. Или редакторы 3D или какой-нибудь CAD программы, или редакторы Workflow процессов. Вон например описание инфраструктуры будущей архитектуры приложений AWS использует похожий принцип, когда используемые элементы как квадратики, кружочки и линии представляют из себя целые горы строчек в настоящем языке программирования. Но они от пользователя "спрятаны". Вот тогда есть толк от такого редактора. Когда он упрощает сложность каких-либо процессов. Когда-же он просто видоизменяет, то что уже есть, но требует всё равно столько же суппорта и при этом уже является 150-м вариантом на рынке, то и успеха у такого начинания мало. Как раз сам работаю над таким framework для своей специализированной идеи. Именно для узкого коридора возможностей, где настоящее програмирование и правда есть муторное дело.