Size: a a a

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

2020 June 03

RT

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

ОИ

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

DK

Daria Kaftan in Архитектура ИТ-решений
Олег Игонин
Да, хочешь не хочешь с этим сталкиваешься. Но вот на сторонние проекты времени не хватает.
Отлично помогает наставничество - в этом случае к тебе приходят коллеги и рассказывают о своей боли, становится примерно понятно как и кто работает.
Я какое-то время назад открыла, что можно с подругами обсуждать архитектуру их ИС. У меня ж подруги-программисты. А до этого обсуждали максимум отдельные технологии.
источник

I

Ivan in Архитектура ИТ-решений
Лично я понимаю @Stanta , и разделяю мнение Кент Бека, Крэга Лармана, Мартина Фаулера, Роберта Мартина и др. про архитектора в ivory tower.

Но ответ на предмет спора, на мой взгляд, лучше всего дает Фред Брукс с его "методом Хирурга". Автором, правда, является не Брукс (Брукс ссылается на источник), но мы знаем о нем от Брукса. Там же Брукс дает очень яркое определение архитектуры.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Stanislav Takt
ну сеньор  - он еще не архитектор. Нужен бизнес-опыт для этого. Координация - да, это больное место. Интерфейсы и Вики нас спасает.
Ровно в тот самый момент, когда к папе-архитектору придёт сын/дочь 3-9 класса, который уже три месяца на дистанте, и спросит "папа, расскажи, как люди учаться - потому что я не понимаю вот этого и вот этого" - настанет интересный момент:
- ребёнок не сервер, код не напишешь и в пайплайн CI/CD не отправишь
- можно отправить его заполнять поднятое "на коленках" wiki - но через час такой работы ребёнок спросит "а зачем я это делаю? Как я буду в этих текстах потом разбираться?"
- можно отправить его к маме или к учительнице ("почитай документацию")

Ровно в этот момент станет понятно, что "я не понимаю" - это не "я не понимаю букв в вики". И появится понимание "белого пятна" в работе архитектора.
источник

PD

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

I

Ivan in Архитектура ИТ-решений
Agile - это, прежде всего, итеративная разработка. Люди с 1930 года пытались с переменным успехом сделать разработку итеративной, но, по-настоящему массовой она стала только в 2001 году (или в конце 90-х).
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Ivan
Agile - это, прежде всего, итеративная разработка. Люди с 1930 года пытались с переменным успехом сделать разработку итеративной, но, по-настоящему массовой она стала только в 2001 году (или в конце 90-х).
Если пообщаться со старыми инженерами (например по радиолокации или ракетам), то оказывается что итеративные методы использвоались еще в пятидесятые, по ним сделаны наши космические и военные технологии.

Ситуация в ИТ скорее есть следствие подходов бизнеса к работе, с годовым планированием, согласованием фиксированных бюджетов, и т.д. Чтобы не пролететь со сроками-бюджатеами, нужен серьезный up-front design.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ivan
Agile - это, прежде всего, итеративная разработка. Люди с 1930 года пытались с переменным успехом сделать разработку итеративной, но, по-настоящему массовой она стала только в 2001 году (или в конце 90-х).
Эээ, но нет. Итеративная разработка была вообще всегда.
Agile - совсем про другое (и в манифесте нет ничего про итерации)
источник

I

Ivan in Архитектура ИТ-решений
Phil Delgyado
Эээ, но нет. Итеративная разработка была вообще всегда.
Agile - совсем про другое (и в манифесте нет ничего про итерации)
Да, была, по крайней мере, Крэг Ларман нашел её в 1930 году, о чем я упомянул. История развития итеративной разработки от Крэга Лармана:
https://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf

Там же ответ на ваш последний тезис.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Как-то плохо он искал. Итеративаня разработка в строительстве уходит в палеолит )
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Поспекулирую на то что сейчас мы видим переход от проектного управления (фиксированные бюджеты и сроки, плавающие цели) к продуктному управлению (фиксированные цели, но гибкие бюджеты и сроки). Вам по FixPrice или T&M?
источник

I

Ivan in Архитектура ИТ-решений
Roman Tsirulnikov
Если пообщаться со старыми инженерами (например по радиолокации или ракетам), то оказывается что итеративные методы использвоались еще в пятидесятые, по ним сделаны наши космические и военные технологии.

Ситуация в ИТ скорее есть следствие подходов бизнеса к работе, с годовым планированием, согласованием фиксированных бюджетов, и т.д. Чтобы не пролететь со сроками-бюджатеами, нужен серьезный up-front design.
Я всегда говорил, что лучше всего понимать суть вещей от первоисточника. Наибольшее влияние на Agile оказал Кент Бек. Именно от него нахватался этих идей Роберт Мартин, который в 2001 году организовал встречу группы из числа 17 человек, которые приняли Agile Manifesto.

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

Первый график: https://emacsway.github.io/_images/exponential-cost-of-change.png

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

Кое-что произошло в конце 90-х. Много писать не буду, скажу только, что это привело к другому графику, который приводит Кент Бек:
https://emacsway.github.io/_images/asymptotic-cost-of-change.png

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

RT

Roman Tsirulnikov in Архитектура ИТ-решений
> и здесь масло в огонь подлило одно судьбоносное решение Кена Швабера в Скраме. Но это уже детали

Интересно, раскроете какое?
источник

PD

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

PD

Phil Delgyado in Архитектура ИТ-решений
Ivan
Я всегда говорил, что лучше всего понимать суть вещей от первоисточника. Наибольшее влияние на Agile оказал Кент Бек. Именно от него нахватался этих идей Роберт Мартин, который в 2001 году организовал встречу группы из числа 17 человек, которые приняли Agile Manifesto.

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

Первый график: https://emacsway.github.io/_images/exponential-cost-of-change.png

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

Кое-что произошло в конце 90-х. Много писать не буду, скажу только, что это привело к другому графику, который приводит Кент Бек:
https://emacsway.github.io/_images/asymptotic-cost-of-change.png

При втором графике стоимость реализации уже не так сильно зависит от момента принятия решения. Это позволяет принимать и изменять решения когда программа уже реализована, опираясь на фидбэк от практической эксплуатации решений, реализованных в предыдущих итерациях. С этого момента итеративные разработки начинают становиться массовыми, но, надо заметить, что до сих пор этот вопрос протекает проблемно, и здесь масло в огонь подлило одно судьбоносное решение Кена Швабера в Скраме. Но это уже детали.
Откуда данные, что итерационная разработка до конца 90х не была массовой? Есть хоть один факт о наличии какой-то другой разработки?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
И есть хоть один пример большого проекта с второй кривой изменения стоимости доработок?
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Ivan
Я всегда говорил, что лучше всего понимать суть вещей от первоисточника. Наибольшее влияние на Agile оказал Кент Бек. Именно от него нахватался этих идей Роберт Мартин, который в 2001 году организовал встречу группы из числа 17 человек, которые приняли Agile Manifesto.

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

Первый график: https://emacsway.github.io/_images/exponential-cost-of-change.png

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

Кое-что произошло в конце 90-х. Много писать не буду, скажу только, что это привело к другому графику, который приводит Кент Бек:
https://emacsway.github.io/_images/asymptotic-cost-of-change.png

При втором графике стоимость реализации уже не так сильно зависит от момента принятия решения. Это позволяет принимать и изменять решения когда программа уже реализована, опираясь на фидбэк от практической эксплуатации решений, реализованных в предыдущих итерациях. С этого момента итеративные разработки начинают становиться массовыми, но, надо заметить, что до сих пор этот вопрос протекает проблемно, и здесь масло в огонь подлило одно судьбоносное решение Кена Швабера в Скраме. Но это уже детали.
» одно судьбоносное решение Кена Швабера в Скраме
Можете рассказать ,какое именно?
источник

I

Ivan in Архитектура ИТ-решений
Roman Tsirulnikov
> и здесь масло в огонь подлило одно судьбоносное решение Кена Швабера в Скраме. Но это уже детали

Интересно, раскроете какое?
Скрам включал в себя набор технических практик, заимствованных из XP, нацеленных на снижение стоимости изменения кода. Но это сдерживало продвижение Скрама в массы, так как вносило организационную сложность. Кен хотел форсировать распространение Agile, и убедил Джеффа Сазерленда вынести эти технические практики за пределы Скрама, четко обозначив Скрам как фреймворк, который разработчики, по своему усмотрению, должны дополнять практиками.

Скрам, действительно, стал распространяться вирусно. Но проблема в том, что на технические практики мало кто обращал должное внимание, что приводило к взлету стоимости изменения кода, при котором Agile уже не обладал экономическим превосходством перед BDUF. Это подмочило репутацию Agile на рынке. По этому поводу есть статья на AgileAlliance (сайт основан подписантами манифеста)
https://www.agilealliance.org/how-to-increase-velocity/
источник

ST

Stanislav Takt in Архитектура ИТ-решений
Ivan
Я всегда говорил, что лучше всего понимать суть вещей от первоисточника. Наибольшее влияние на Agile оказал Кент Бек. Именно от него нахватался этих идей Роберт Мартин, который в 2001 году организовал встречу группы из числа 17 человек, которые приняли Agile Manifesto.

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

Первый график: https://emacsway.github.io/_images/exponential-cost-of-change.png

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

Кое-что произошло в конце 90-х. Много писать не буду, скажу только, что это привело к другому графику, который приводит Кент Бек:
https://emacsway.github.io/_images/asymptotic-cost-of-change.png

При втором графике стоимость реализации уже не так сильно зависит от момента принятия решения. Это позволяет принимать и изменять решения когда программа уже реализована, опираясь на фидбэк от практической эксплуатации решений, реализованных в предыдущих итерациях. С этого момента итеративные разработки начинают становиться массовыми, но, надо заметить, что до сих пор этот вопрос протекает проблемно, и здесь масло в огонь подлило одно судьбоносное решение Кена Швабера в Скраме. Но это уже детали.
>Кое-что произошло в конце 90-х. Много писать не буду, скажу только, что это привело к другому графику, который приводит Кент Бек:
В основном произошел закон Мура. Стоимость машинного времени упала на порядки, что позволило начать развиваться CI/CD хоть на рабочих местах.  До этого процесс компиляции и сборки был священнодействием системных программистов.
источник