Size: a a a

Архитектура ИТ-решений

2020 June 03

F

Fagor in Архитектура ИТ-решений
Roman Tsirulnikov
Вот тут годный топик чтобы потроллиать аджайлистов: PM-ы не нужны, у нас agile и самоорганизация)
Там скрам мастер, неа? Все нормально с аджайлом. Его нужно уметь готовить, ну и подвать блюдо в нужный момент и время. Десерт только после основного блюда.
источник

F

Fagor in Архитектура ИТ-решений
Phil Delgyado
Кстати, на моем опыте wiki всегда появлялась благодаря архитектору, а не PMу.
Фиговые ПМы значит, не заинтересованные оставить после себя. ПМ нужно объяснить, что в рамках проекта есть работы по передаче в эксплуатацию. А то закрыли бумаги и пусть система хоть огнем горит.
источник

Т

Товарищ Паркинсон... in Архитектура ИТ-решений
Fagor
Фиговые ПМы значит, не заинтересованные оставить после себя. ПМ нужно объяснить, что в рамках проекта есть работы по передаче в эксплуатацию. А то закрыли бумаги и пусть система хоть огнем горит.
аджайл же, документация не важна, хе-хе
источник

F

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

PD

Phil Delgyado in Архитектура ИТ-решений
Fagor
Фиговые ПМы значит, не заинтересованные оставить после себя. ПМ нужно объяснить, что в рамках проекта есть работы по передаче в эксплуатацию. А то закрыли бумаги и пусть система хоть огнем горит.
Ээ, жизненный цикл продукта - это не дело проджекта, разве что продукта, но обычно архитектора. Эксплуатация - это тоже про архитектора.
Для проджекта почти нет активностей, требующих wiki в разработке, ему актуальнее MS Project, Excel и TODO
Для продакта, вообще, тоже удобнее постановки делать не в wiki (если он один, а не группа)
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Но аджайл - не исключает менеджеров, конечно. Скорее наоборот )
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Товарищ Паркинсон
аджайл же, документация не важна, хе-хе
Нуу, не "не важна", а менее важна.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Fagor
Вообще, я вижу, что скрам говорит про модель разработки, никто не отменял, и скрам не упоминает, что с системой и модель эксплуатации неплохо бы сдавать.
В скраме вообще не рассматривается система.
источник

F

Fagor in Архитектура ИТ-решений
Согласен, но... проджект сдает проект, с эксплуатационной моделью. Да эксплуатация и утилизация обычно исключается из самого проекта. Но почему сдается только ситема а не комплекс, т.е. Проект?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Просто за границами фреймворка.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Fagor
Согласен, но... проджект сдает проект, с эксплуатационной моделью. Да эксплуатация и утилизация обычно исключается из самого проекта. Но почему сдается только ситема а не комплекс, т.е. Проект?
Ээ. Обычно у проектов нет эксплуатационных моделей, это у продуктов они есть.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Phil Delgyado
Просто за границами фреймворка.
Если что-то за границами, значит его не существует для тех, кто в этих границах работает.
источник

F

Fagor in Архитектура ИТ-решений
Phil Delgyado
Ээ. Обычно у проектов нет эксплуатационных моделей, это у продуктов они есть.
Обычно, да. Но если есть в рамках Проекта ПродуктМ., то она должна быть и у ПроджектМ. А если продукта нет, роль размазывается, и модель какая никакая должна быть при сдаче проекта.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Alexander Luchkov
Если что-то за границами, значит его не существует для тех, кто в этих границах работает.
Ну, да, скрам - это только небольшой кусок процесса разработки (возможного).
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Fagor
Обычно, да. Но если есть в рамках Проекта ПродуктМ., то она должна быть и у ПроджектМ. А если продукта нет, роль размазывается, и модель какая никакая должна быть при сдаче проекта.
Ну, если проект по созданию первой версии продукта, то скорее да. Но обычно про это думает не проджект (у него разве что в списке артефактов есть "модель эксплатации"), а архитектор или продакт.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Оптимизация системы по ЖЦ - это не функция проекта, а продукта и архитектуры
источник

F

Fagor in Архитектура ИТ-решений
Phil Delgyado
Оптимизация системы по ЖЦ - это не функция проекта, а продукта и архитектуры
В проекте царь ПроектМ. Кто и что будет делать - разговор отдельный. Я к тому что он заинтересован и организовать, в том числе и вики - его часть.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Fagor
В проекте царь ПроектМ. Кто и что будет делать - разговор отдельный. Я к тому что он заинтересован и организовать, в том числе и вики - его часть.
Это противоречит роли скрам мастера. Скрам мастер это фасилитатор команды без права лично принимать решения.
Чтобы что-то куда-то двигалось, всегда нужно заинтересованное лицо. В скраме предполагается что это внешний заказчик.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Fagor
В проекте царь ПроектМ. Кто и что будет делать - разговор отдельный. Я к тому что он заинтересован и организовать, в том числе и вики - его часть.
Ну, оно по разному и сильно зависит от компании.
Если у нас монопродуктовая компания с проектным офисом, то проектному офису wiki не очень нужна и не понятно, зачем ее внедрять.
источник

F

Fagor in Архитектура ИТ-решений
Вики по всем "частям"(назовем это так), да, ее соберет кто то другой. Информацию для вики, передает проектный офис. Если офис это не делает, то ему просто плевать, а руководство это устраивает.
источник