Для одного z2m и nodered промышленный комп - оверкилл тот еще. Хватит простой коробочки на каком N100. В любом случае - придется кого-то обучать для бекапа.
Это не в области ИМХО. Сделайте пару звонков, поишите человека, который ваш колхоз захочет приехать поремонтировать. Это проблема, на самом деле. У меня тоже всякого заведено в УД и осознаю, что случись что, семейство не найдет, кто починит. Поэтому в планах отрефакторить все на более прямые решения, благо сейчас многие вещи проще стало делать.
Я не зря написал про заказчиков поопытней. Такие ставят скилованого PMа на своей стороне, нанимают сторонний QA и вот тогда аутстафф очень даже неплохо работает для всех.
Клиенты поопытней и сами понимают, что так не работает, на выходе будет кака и тёрки по доплатам и начинают пробовать аутстафф и прочий не совсем фикспрайс.
Скрам - это ещё про повышение прозрачности перед заказчиком (за что его исполнители и не любят). Внедрив некий гибрид скрама в один проект с ковбой-менеджментом, наконец удалось отшить бизнес с постоянными наездами "вы тут ни хрена не делаете, ничего не происходит, платим много, а результатов нет". Когда вся работа визуализировалась, стало проще тыкать бизнес в собственный бардак и хоть немного, но упорядочить работу.
Изменения - это данность, почти в любом плюс минус сложном бизнесе, с этим надо жить, эджайл потому и появился, как признание этого факта. Другой вопрос, что действительно, не надо приучать "бизнес", что любые изменения легко даются и можно хотелки в беклог всовывать легко и непринуждённо.
доп пункты -) твои проекты и код часто умирают. выживают немногие. неприятно работать на свалку. -) твои знания устаревают очень быстро, а с возрастом учиться всё сложнее, и смысла в этом видишь всё меньше из-за первого пункта.
Всегда надо исходить из того, что кто-то что-то пропустит, т.е. исходить из сценария вероятного факапа. Потому и накатывают апдейты не сразу на весь мир. Естественно, и в архитектуру, позволяющую релизить процентуально надо вложиться. А вот на это очень многие забивают, надеясь, что QA-индусы прикроют риски.
Сарказм? У водопада есть маленькая проблема - абсолютное большинство проектов не имеет полностью сформулированых требований, а если имеют, то эти требования меняются в процессе.
Ну вот приезжает извне "электрик" и видит некий black box. Дальше что?
Для одного z2m и nodered промышленный комп - оверкилл тот еще. Хватит простой коробочки на каком N100. В любом случае - придется кого-то обучать для бекапа.
Это не в области ИМХО. Сделайте пару звонков, поишите человека, который ваш колхоз захочет приехать поремонтировать. Это проблема, на самом деле. У меня тоже всякого заведено в УД и осознаю, что случись что, семейство не найдет, кто починит. Поэтому в планах отрефакторить все на более прямые решения, благо сейчас многие вещи проще стало делать.
Непонятно, как отсутствие требований=ответственности за их выполнение поможет эту ответственность воспитать.
Только для этого конечно не нужен. Бизнес хочет всё таки ещё и в планирование будущих релизов и одной доски для этого мало.
Я не зря написал про заказчиков поопытней. Такие ставят скилованого PMа на своей стороне, нанимают сторонний QA и вот тогда аутстафф очень даже неплохо работает для всех.
Клиенты поопытней и сами понимают, что так не работает, на выходе будет кака и тёрки по доплатам и начинают пробовать аутстафф и прочий не совсем фикспрайс.
Скрам - это ещё про повышение прозрачности перед заказчиком (за что его исполнители и не любят). Внедрив некий гибрид скрама в один проект с ковбой-менеджментом, наконец удалось отшить бизнес с постоянными наездами "вы тут ни хрена не делаете, ничего не происходит, платим много, а результатов нет". Когда вся работа визуализировалась, стало проще тыкать бизнес в собственный бардак и хоть немного, но упорядочить работу.
Имхо фикспрайс и эджайл - это антонимы по определению.
Изменения - это данность, почти в любом плюс минус сложном бизнесе, с этим надо жить, эджайл потому и появился, как признание этого факта. Другой вопрос, что действительно, не надо приучать "бизнес", что любые изменения легко даются и можно хотелки в беклог всовывать легко и непринуждённо.
Хороший аналитик умеет убедительно расписать, почему его предыдущий прогноз не сбылся =)
У Лекса Фридмана интервью со всей их бандой на 8 часов выходило недели 2 назад, много интересного.
доп пункты
-) твои проекты и код часто умирают. выживают немногие. неприятно работать на свалку.
-) твои знания устаревают очень быстро, а с возрастом учиться всё сложнее, и смысла в этом видишь всё меньше из-за первого пункта.
Светофоры могут заменить люди-регулировщики, только вот мало кто уже не помнит, что они там руками машут =)
Неоднократно видел такое и с людьми. Бывает и сразу с чуши начинается =)
Всегда надо исходить из того, что кто-то что-то пропустит, т.е. исходить из сценария вероятного факапа. Потому и накатывают апдейты не сразу на весь мир. Естественно, и в архитектуру, позволяющую релизить процентуально надо вложиться. А вот на это очень многие забивают, надеясь, что QA-индусы прикроют риски.
Работая на уровне ядра, уронить систему как 2 пальца. Любую.
Какая-то конторка поленилась делать роллинг апдейты, а виновата по привычке винда.
Не догоняю, какой реальный юзкейс этого девайса. Шлюз между сетями? Каким софтом? Контроллер например зигби, но как?
Сарказм? У водопада есть маленькая проблема - абсолютное большинство проектов не имеет полностью сформулированых требований, а если имеют, то эти требования меняются в процессе.