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

А как scrum и прочие эджайлы запрещают предлагать улучшения?

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

Это какая-то дичь уровня государственной организации, которой, в общем-то, все равно, какой результат будет, потому что материальной ответственности никто не несет.

Конфигурации пишутся и работают исправно.
Спасибо за это 1С.
И время имеется на создание своего велосипеда /конечно не так много, но главное тонус разработки не теряется/.
Так же благодарю начальника за то, что он любит 1С 7.7.
Разрабатываемый велосипед позволит вести как разработку учетных задач, так и использующих 2D, 3D, …

Владимир

В классическом scrum team роли архитектора вообще нет, так что посыл неверный.

В классическом scrum team роли архитектора вообще нет, так что посыл неверный.

В таком случае на исправлении ошибок в ПО данный подход будет работать отлично. Только тут и улучшения особо и не нужны: нашёл дырку в коде и заштопал быстренько - это деятельность уровня ПТУ.

метод называется: покажи, что сделал.

Это замечательно, но вопрос был о пользе скрама с канбаном и прочим аджайлом. Метод «покажи, что сделал», конечно, очень хороший, но появился несколько ранее этих замечательных практик.

Во-вторых, «покажи, что сделал» может означать разное, в зависимости от обстоятельств. Можно интересоваться результатом работы, а можно и правильностью оформления тикетов, глубиной бэклога, чувством взаимного удовлетворения после груминга и т.д.

«Покажи, что сделал» работает с компетентными менеджерами, где такие есть и негатива нет. В случае когда у руля гуманитарий, максимум что он может сделать - дать количественную оценку выполненной работы. Оценить трудозатраты или качество проделанной работы на короткой дистанции такой менеджер не может, что на большом проекте всплывает сильно позже. Зато отчеты красивые.

Покормлю!

Кто нибудь понимает нафиг это надо и реально использует?

А тебе в SCRUM book не объяснили чтоле?

Давай разъясню на примере:

Начнем с «основных идей»:

У нас нет знаний и опыта управления проектами по нормальным стандартам, поэтому

люди и взаимодействие важнее процессов и инструментов

работающий продукт важнее исчерпывающей документации;

Но, поскольку никто не заморачивался с управлением требованиями, то рабочим считается все, что смогло запуститься на железе разработчика…

сотрудничество с заказчиком важнее согласования условий контракта;

В данном случае под «сотрудничеством» понимается подмена нормального управления рисками, требованиями и изменениями манипуляциями в переговорах с лохом заказчиком.

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

особенно, когда основным источником рисков является PO/PM…

Теперь «Принципы»:

удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

Мы забили на управление требованиями, к тому же лох заказчик сам не знает, чего хочет, будем угадывать…

приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

Поскольку мы набрали разработчиков и PM по объявлениям, - основным источником рисков является сама команда, приходится как-то выкручиваться…

частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

работающее программное обеспечение — лучший измеритель прогресса;

лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;

тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

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

И да, поскольку у нас нет управления требованиями, мы, как «эффективные менеджеры» просто свяжем лоха заказчика с разработчиками, пусть сам им объясняет свои требования, мы все равно в этом ни хера не шарим.

спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;

Управление расписанием и содержанием, нафиг-нафиг мы же аджайл!

А про то, что время - единственный невозобновимый ресурс - не, не слышали…

проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

Не обращайте внимание, просто булщит для привлечения неофитов.

рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

Чтобы потом можно было оперативно съехать с темы, типа «я не помню такого разговора с тобой».

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

постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Опять реагирование на внутренние и внешние риски, которые сами же и создали…

исчерпывающее объяснение этого лохотрона. браво.

Это про аджайл, скрам - не аджайл.

Там таки добавили элементы управления содержанием и элементы управления расписанием микроменеджмент.

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

По приведенной тобой ссылочке есть другая как делали истребитель- убийцу Сухова :

https://www.scrumalliance.org/ScrumRedesignDEVSite/media/ScrumAllianceMedia/Global%20Scrum%20Gatherings/2017%20San%20Diego/Presentations/JusticeJoe_Agile_In_Military_Hardware_SGSD.pdf

Почитай и пошути еще раз так же смишно.

Ну и где этот убийца?

На вот, читани хабреца лучше: https://habr.com/ru/post/430890/

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

в принципе согласен с shkolnick-kun, но хочу сказать что идея спринта в 2 недели все же хороша, когда проект не только программный, но и железный и надо подвязывать по времени различные команды - это удобно, а то у нас бывало монтажники смонтировали - ждём высоковольтников, чтоб проверить (а они другое подразделение и уехали на месяц), программисты написали - ждём высоковольтников проверить, что то спалили - ждем ремонтников, а потом высоковольтников - время идёт проект стоит, работали бы все спринтами было бы удобнее (можно было бы планировать время).

Там не про Сухого, там про https://ru.wikipedia.org/wiki/Saab_JAS_39_Gripen

Который эксплуатируется только в Швеции и всяких бантустанах вроде Болгарии.

я очень много работала в больших проектах, где были и механики, и электроники, и программисты. я, собственно, писала взаимодействие между электроникой и «совсем программистами» - на уровне харда и системы. и там никаких «спринтов» тем более не надо. потому что сначала основательно думают и решают, что и как делать, а потом всё разрабатывается параллельно. каждый отдел делает свою часть. и если ты нормально всё в ТЗ продумал, то потом нет проблем с тем, чтобы это всё вместе заработало. и никакие скрамы в таких проектах не нужны. потому что только опытные разработчики могут такие вещи делать. а им скрамы даром не сдались.

а то у нас бывало монтажники смонтировали - ждём высоковольтников, чтоб проверить (а они другое подразделение и уехали на месяц)

А что делал PM, и сколько у него власти?

что то спалили - ждем ремонтников

А сколько образцов делали? У меня обычно три…

там написано, что он провалил испытания и вышел дорогостоящим.

они для макак, набранных с улицы

А ты илитка как я понимаю?

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

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

и да, я на сто процентов уверена, что команда важна. набрать обезьян с улицы и надеяться что-то сделать за счёт правильного рассаживания и муштры - это глупость. это никогда не работало и не будет работать.

Нет там написано что стоимость разработки F-35 - $1,5 триллиона, а этот самолетик разработали за $14 миллиардов. А это значит, что аджайл реально работает, чтобы вы тут не кукарекали.

нет. это значит, что бывают неэффективные разработки.

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

Кто такой PM? На счет образцов - тут как в анекдоте, сколько болванок испортил - 6, как шесть их 5 было - я и образец испортил. Та же херня, пока была замена меняли и ждали ремонта, а там все кончилось.

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

Это означает лишь одно, что бизнес у вас не высокодоходный и нет конкурентов. Задачи максимально быстро выкинуть продукт на рынок не стоит вот вы и работаете по колхозному.

Это все хорошо, когда отдел укомплектован всеми видами специалистов, а когда специалисты не то что по отделам, а по разным подразделениям/департаментам и у них есть свои начальники и свои приоритеты на выполнения работ - вот тогда все рассыпается к чертям. И да - это плохо организованное управление помноженное на бюрократию - но такое встречается очень часто.

minirobodancer, это ты? привет

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

Вот для этого выделяют руководителя проекта, РП/PM(Project Manager), и команду управления проектом (представителей подразделений), чтоб можно было графики согласовать скординировать работу подразделений.

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

Многоцелевой истребитель Gripen это серьезная техника или не очень?

Только они почему-то не пришли

Так они уже пришли, ЛОЛище, куда ни плюнь, - попадешь в PM/PO 80 уровня.

Откуда их столько? И как они все прокачались до 80lvl?

Cие тайна великая есть!

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

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

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

Вот поэтому у нас и разрабатывают трамваи по цене истребителя.

Кстати с появлением нормально руководителя проекта, не мямли - процесс пошел куда лучше.

Это политический момент, я по этому и спросил про власть.

Если функциональные руководители проявляют эгоизм (типа ждите, когда у нас люди освободятся), значит у них нет цели работать на достижение целей организации…

И тогда есть три решения:

• сформировать из них команду управления проектом и спрашивать с них за проект;

• дать руководство проектом человеку с более высоким положеннием;

• дать руководство проектом более властному, авторитетному человеку.

Пруфы будут?

Так лучше просто работу работать, даже если она полностью бесполезная?

Ибо именно при обсуждении и выясняют что нужно, а что нет.

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

судя по википедии - какое-то третьесортное поделие

Конкурент F-22 Raptor.

Называет самолеты разных поколений конкурентами…

Ну толсто же!

я кстати работал в некотором варианте аджайла, у нас было тз и у нас был тимлид и он нам говорил: - Петров надо сделать такой то функционал, сколько займёт это время? - тот отвечал. Тим - записывал, а потом спрашивал (2 недели примерно на среднюю задачу), если не выходило - уже впрягались всем миром. К выставкам успевали. Так что в принципе именно как режим работы - по мне так неплохо.

в Европе никогда не умели делать самолёты. это у них такая карма

Eurofighter Typhoon — многоцелевой истребитель четвёртого поколения.

Dassault Rafale — французский многоцелевой истребитель четвёртого поколения

Сааб JAS 39 «Грипен» — шведский многоцелевой истребитель четвёртого поколения

Не слышала? Ты хоть википедию почитай прежде чем лезть со своим ценным мнением. Я вот почитала, сижу и плачу от смеха.

Как и между жидким дерьмом и твёрдым, в сущности ни в чём.

https://youtu.be/F2skk6RFFos

Вообще, какой-то технарь это ТЗ ещё должен составить, а если команда маленькая — это будет один из разрабов, так что от обсуждения не уйти.

Вы правы, но «нифига не знаешь» она будет всем доказывать в двадцати тредах. Знаете почему?

Еще пятнадцать тредов.

PS: Как хорошо, что весь этот бред меня ни когда не касался и не коснется.

Владимир

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

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