Как стать автором
Обновить

Комментарии 18

Я ничего не понял

Ажаль это когда небольшие изолированные изменения имеют самостоятельную ценность. Тут часто используются MVP эволюционный подход, когда, прежде чем сконструировать реактивный лайнер большой кукурузник, нужно набрать опыта с парой поколений мелких кукурузников, с переиспользованием компонент.

Водопад это когда изменения влияют друг на друга и/или самостоятельной ценности не имеют.

Если самостоятельной ценности не имеют, но взаимовлияние компонент сильное, то строят несколько водопадов, итерационная модель. А если хочется ускорить, выкинуть лишнее и понимать конечный срок, то спиральная модель.

И от менеджмента почти не зависит выбор модели управления. Модель зависит от требований и ценностей бизнеса.

Браво! Написано понятней, чем в статье. Интересно, а индивидуальным разработчикам нужны все эти заморочки или достаточно здравого смысла? Неплохо было бы увидеть пример «правильной» разработки классов, на C++, для сложной программной логики, завязанной на GUI.

Зачем тогда agile, если есть интеграционная модель и спиральная?

Ажаль на 1-2 недельные спринты. А спиральные и прочие модификации итерационных не получается делать с такими короткими итерациями. Там типичный срок итерации пол-года

Office space неплохой фильм, в принципе ничего не изменилось в корпорациях - нередко формалист карьерист руководит отделом.

Запомнился случай из 2004 года - я работал в консалтинговой компании в Торонто и неожиданно получил задание от шефа помочь восстановить приложение e-commerce в офисе "за углом", не буду называть компанию, это была сеть онлайн аптек. Пришли - офис "дорого, богато, солидно, измерители давления стоят везде и умные весы - сразу видно, компания связана с медициной". Головная компания американская.

Встретил нас троих руководитель отдела разработки.

Привел в пустое помещение - впечатление что люди куда то вышли - на столах кружки с недопитым кофе, бумаги. Оказалось всех вызвали на совещание, уволили и никто не вернулся обратно.

В чем вопрос? Восстановить исходный код проектов. Где, что, и как - руководитель отдела не знал. В общем, пошуршали по компьютерам и серверам, нашли три (!) сервера CVS с проектами, но непонятно в чем отличие и какая крутится в проде версия. В итоге, восстановили код восстановлением из байт кода на серверах, благо было не обфускировано.

Через три дня отнес чек на 150 тыс кан. баксов боссу. Но впечатление осталось странное, как от посещения Хиросимы, как будто тени от людей остались.

Не люблю после этого корпоративный американский стиль увольнения.

Очень интересная история, спасибо! Интересно конечно, можно ли придумать такую методологию управления, в которой такое поведение менеджеров а) было очевидно непродуктивным для высшего менеджмента б) не было необходимым? Почему их всех уволили в один момент, в чем была истинная причина?..

не в курсе почему, думаю решение принимал не начальник отдела - он не вникал в детали, скорее всего. Решение приняли выше, думая что руководитель все знает. Скорее всего, сократили контрактников. Вроде все настроили, начальник отдела в курсе что и как, ас наберем на ставку в 2 раза дешевле ааа то и в 3 и сэкономим. Сэкономили сразу на 150 тыс, а потом еще с новым набором думаю с полгодика ловили проблемы. Идиотов хватает, иначе бы бизнесы не разорялись.

В той компании где работал, на следующий год произошла похожая история - ушло 80 процентов "полевого" персонала (кроме руководителей) почти единомоментно. Год был урожайным, зарплаты сильно ниже рынка, люди просили повышение на 10%, получали отказ и сразу находили, буквально за дни, от 50 до 100 процентов выше предложения.

восстановили код восстановлением из байт кода на серверах

За 3 дня? У меня в похожем случае восстановление солюшна на Шарп заняло месяц. И то, боюсь на прод пускать, так старый код в основном и крутится с костылями.

Сишарп не восстанавливал, может пара проектов на нем была, а java. не обфускированная быстро восстанавливается. Да и обфускированную можно в 90 процентах случаев, только дольше будет. Тем более репозитории были , нужно было выяснить какой из них мастер версия.

вы будете смеяться но в той же компании, консалтинговой, еще хуже история произошла.

привлекался на заказы к ним иногда из России, прилетаю в 2009 - встретили, поселили в отель за углом. Удобно.

На следующее утро у них помер основной RAID 5 массив на котором было много чего а главное репозиторий. И админ нарушил правило "бэкапов много не бывает". По логам, один диск помер в 7 утра, второй в 7:15.

Они долго собирали свои in-house приложения из исходников с рабочих станций , а часть пришлось из байт кода восстанавливать.

Админ, помни - делать пару бэкапов, лучше три, не полагайся на raid.

Декомпиляция ещё ладно, можно сделать. Вот собрать солюшн, со всеми файлами HTML разметки, настройками сборки... Вот время и ушло

Хотя бы один бекап. Ни одного не было что-ли?

Ресурсные файлы вытащить не проблема а вот по новой раскидать по модулям, зависимости и тд, еще и скрипты менеджера проекта... Да, придется повозиться.

В первом случае было послабление - репозитории были, непонятно было какая версия последняя. По сути, взял исходники из байт кода, ресурсы из архива ear/war или расжатого пакета, зависит от сервера, и обновил проекты. Затем сравнил ant XML скрипты и батчи между 3х репозиториев.

Во втором случае, тоже ант в основном, собрали как смогли, зависимости то остались на месте. Там полгода копались, так как смена состава была.

а вот разок вляпались у клиента с windows roaming profile, это было неудобно - логин в систему занимал пару часов... А компьютер , вернее случайную станцию , дали один на всех (а нас трое). Оказалось, коллега индус сохранил полтора гига музыки в домашней папке - она благополучно сохранилась в ка контроллере домена, а на следующее утро мы ждали пока это разбухший профайл поиперегруженной сети зальется на другой станции

Но если вы взглянете на список методологий, связанных с Agile, у вас могут зазвенеть тревожные звоночки — особенно если вы когда-либо сталкивались с дискриминацией или домогательствами на рабочем месте.

Видел много критики эджайла, но вот о том, что он поощряет домогательства на рабочем месте, пока читать не приходилось 🤔

Автор текста работала в большом университете в Калифорнии, очевидно, у них своя атмосфера по этой теме.

в Калифорнии, очевидно, у них своя атмосфера по этой теме

Я не понимаю, зачем переписывать очевидную ахинею. Независимо от локации, ни в одной методике эджайл невозможно найти ничего, способствующего дискриминации или сексуальным домогательствам. Вот вообще ничего. Если автор находит – это признак психического расстройства и явная причина для того, чтобы статьи такого автора не перепубликовывать.

"Утренний стендап" заиграл новыми красками.

как вариант, можно пробовать другие методологии, не связанные с Agile.

Зачем вообще переводить какую-то ахинею?!

Просто поток воды, цитат не к месту и сомнительных фактов о карго культе, который насколько человек успешно продали, воспользовавшись моментом.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации