RT
Нет. Не нужен. Грамотный РП нужен. Вики живет от команд, рп привьет дух и покажет необходимость.
Вот тут годный топик чтобы потроллиать аджайлистов: PM-ы не нужны, у нас agile и самоорганизация)
Size: a a a
2020 June 03
ОИ
Вот тут годный топик чтобы потроллиать аджайлистов: PM-ы не нужны, у нас agile и самоорганизация)
Самозанятые 😂🤣
DK
Да, хочешь не хочешь с этим сталкиваешься. Но вот на сторонние проекты времени не хватает.
Отлично помогает наставничество - в этом случае к тебе приходят коллеги и рассказывают о своей боли, становится примерно понятно как и кто работает.
Отлично помогает наставничество - в этом случае к тебе приходят коллеги и рассказывают о своей боли, становится примерно понятно как и кто работает.
Я какое-то время назад открыла, что можно с подругами обсуждать архитектуру их ИС. У меня ж подруги-программисты. А до этого обсуждали максимум отдельные технологии.
I
Лично я понимаю @Stanta , и разделяю мнение Кент Бека, Крэга Лармана, Мартина Фаулера, Роберта Мартина и др. про архитектора в ivory tower.
Но ответ на предмет спора, на мой взгляд, лучше всего дает Фред Брукс с его "методом Хирурга". Автором, правда, является не Брукс (Брукс ссылается на источник), но мы знаем о нем от Брукса. Там же Брукс дает очень яркое определение архитектуры.
Но ответ на предмет спора, на мой взгляд, лучше всего дает Фред Брукс с его "методом Хирурга". Автором, правда, является не Брукс (Брукс ссылается на источник), но мы знаем о нем от Брукса. Там же Брукс дает очень яркое определение архитектуры.
EI
ну сеньор - он еще не архитектор. Нужен бизнес-опыт для этого. Координация - да, это больное место. Интерфейсы и Вики нас спасает.
Ровно в тот самый момент, когда к папе-архитектору придёт сын/дочь 3-9 класса, который уже три месяца на дистанте, и спросит "папа, расскажи, как люди учаться - потому что я не понимаю вот этого и вот этого" - настанет интересный момент:
- ребёнок не сервер, код не напишешь и в пайплайн CI/CD не отправишь
- можно отправить его заполнять поднятое "на коленках" wiki - но через час такой работы ребёнок спросит "а зачем я это делаю? Как я буду в этих текстах потом разбираться?"
- можно отправить его к маме или к учительнице ("почитай документацию")
Ровно в этот момент станет понятно, что "я не понимаю" - это не "я не понимаю букв в вики". И появится понимание "белого пятна" в работе архитектора.
- ребёнок не сервер, код не напишешь и в пайплайн CI/CD не отправишь
- можно отправить его заполнять поднятое "на коленках" wiki - но через час такой работы ребёнок спросит "а зачем я это делаю? Как я буду в этих текстах потом разбираться?"
- можно отправить его к маме или к учительнице ("почитай документацию")
Ровно в этот момент станет понятно, что "я не понимаю" - это не "я не понимаю букв в вики". И появится понимание "белого пятна" в работе архитектора.
PD
Вот тут годный топик чтобы потроллиать аджайлистов: PM-ы не нужны, у нас agile и самоорганизация)
Кстати, на моем опыте wiki всегда появлялась благодаря архитектору, а не PMу.
I
Agile - это, прежде всего, итеративная разработка. Люди с 1930 года пытались с переменным успехом сделать разработку итеративной, но, по-настоящему массовой она стала только в 2001 году (или в конце 90-х).
RT
Agile - это, прежде всего, итеративная разработка. Люди с 1930 года пытались с переменным успехом сделать разработку итеративной, но, по-настоящему массовой она стала только в 2001 году (или в конце 90-х).
Если пообщаться со старыми инженерами (например по радиолокации или ракетам), то оказывается что итеративные методы использвоались еще в пятидесятые, по ним сделаны наши космические и военные технологии.
Ситуация в ИТ скорее есть следствие подходов бизнеса к работе, с годовым планированием, согласованием фиксированных бюджетов, и т.д. Чтобы не пролететь со сроками-бюджатеами, нужен серьезный up-front design.
Ситуация в ИТ скорее есть следствие подходов бизнеса к работе, с годовым планированием, согласованием фиксированных бюджетов, и т.д. Чтобы не пролететь со сроками-бюджатеами, нужен серьезный up-front design.
PD
Agile - это, прежде всего, итеративная разработка. Люди с 1930 года пытались с переменным успехом сделать разработку итеративной, но, по-настоящему массовой она стала только в 2001 году (или в конце 90-х).
Эээ, но нет. Итеративная разработка была вообще всегда.
Agile - совсем про другое (и в манифесте нет ничего про итерации)
Agile - совсем про другое (и в манифесте нет ничего про итерации)
I
Эээ, но нет. Итеративная разработка была вообще всегда.
Agile - совсем про другое (и в манифесте нет ничего про итерации)
Agile - совсем про другое (и в манифесте нет ничего про итерации)
Да, была, по крайней мере, Крэг Ларман нашел её в 1930 году, о чем я упомянул. История развития итеративной разработки от Крэга Лармана:
https://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf
Там же ответ на ваш последний тезис.
https://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf
Там же ответ на ваш последний тезис.
PD
Как-то плохо он искал. Итеративаня разработка в строительстве уходит в палеолит )
RT
Поспекулирую на то что сейчас мы видим переход от проектного управления (фиксированные бюджеты и сроки, плавающие цели) к продуктному управлению (фиксированные цели, но гибкие бюджеты и сроки). Вам по FixPrice или T&M?
I
Если пообщаться со старыми инженерами (например по радиолокации или ракетам), то оказывается что итеративные методы использвоались еще в пятидесятые, по ним сделаны наши космические и военные технологии.
Ситуация в ИТ скорее есть следствие подходов бизнеса к работе, с годовым планированием, согласованием фиксированных бюджетов, и т.д. Чтобы не пролететь со сроками-бюджатеами, нужен серьезный up-front design.
Ситуация в ИТ скорее есть следствие подходов бизнеса к работе, с годовым планированием, согласованием фиксированных бюджетов, и т.д. Чтобы не пролететь со сроками-бюджатеами, нужен серьезный 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
При втором графике стоимость реализации уже не так сильно зависит от момента принятия решения. Это позволяет принимать и изменять решения когда программа уже реализована, опираясь на фидбэк от практической эксплуатации решений, реализованных в предыдущих итерациях. С этого момента итеративные разработки начинают становиться массовыми, но, надо заметить, что до сих пор этот вопрос протекает проблемно, и здесь масло в огонь подлило одно судьбоносное решение Кена Швабера в Скраме. Но это уже детали.
Кент приводит два графика стоимости изменения кода, по которым может протекать разработка.
Первый график: https://emacsway.github.io/_images/exponential-cost-of-change.png
При таком графике момент принятия решения играет важную роль, так как от этого зависит стоимость его реализации, причем, эта стоимость может возрасти на порядки. Это вынуждает принимать решение в момент наименьшей стоимости реализации, т.е. заблаговременно, т.е. BDUF. Это та самая причина, по которой итеративная разработка до конца 90-х, конечно же, была, но она была экономически нецелесообразной, и поэтому не нашла массовости.
Кое-что произошло в конце 90-х. Много писать не буду, скажу только, что это привело к другому графику, который приводит Кент Бек:
https://emacsway.github.io/_images/asymptotic-cost-of-change.png
При втором графике стоимость реализации уже не так сильно зависит от момента принятия решения. Это позволяет принимать и изменять решения когда программа уже реализована, опираясь на фидбэк от практической эксплуатации решений, реализованных в предыдущих итерациях. С этого момента итеративные разработки начинают становиться массовыми, но, надо заметить, что до сих пор этот вопрос протекает проблемно, и здесь масло в огонь подлило одно судьбоносное решение Кена Швабера в Скраме. Но это уже детали.
RT
> и здесь масло в огонь подлило одно судьбоносное решение Кена Швабера в Скраме. Но это уже детали
Интересно, раскроете какое?
Интересно, раскроете какое?
PD
Ну, я вот не уверен, что большее влияние оказал Кент, а не Коуберн, например.
Содержания у Коуберна больше.
Содержания у Коуберна больше.
PD
Я всегда говорил, что лучше всего понимать суть вещей от первоисточника. Наибольшее влияние на 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
При втором графике стоимость реализации уже не так сильно зависит от момента принятия решения. Это позволяет принимать и изменять решения когда программа уже реализована, опираясь на фидбэк от практической эксплуатации решений, реализованных в предыдущих итерациях. С этого момента итеративные разработки начинают становиться массовыми, но, надо заметить, что до сих пор этот вопрос протекает проблемно, и здесь масло в огонь подлило одно судьбоносное решение Кена Швабера в Скраме. Но это уже детали.
Кент приводит два графика стоимости изменения кода, по которым может протекать разработка.
Первый график: 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
И есть хоть один пример большого проекта с второй кривой изменения стоимости доработок?
EI
Я всегда говорил, что лучше всего понимать суть вещей от первоисточника. Наибольшее влияние на 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
При втором графике стоимость реализации уже не так сильно зависит от момента принятия решения. Это позволяет принимать и изменять решения когда программа уже реализована, опираясь на фидбэк от практической эксплуатации решений, реализованных в предыдущих итерациях. С этого момента итеративные разработки начинают становиться массовыми, но, надо заметить, что до сих пор этот вопрос протекает проблемно, и здесь масло в огонь подлило одно судьбоносное решение Кена Швабера в Скраме. Но это уже детали.
Кент приводит два графика стоимости изменения кода, по которым может протекать разработка.
Первый график: https://emacsway.github.io/_images/exponential-cost-of-change.png
При таком графике момент принятия решения играет важную роль, так как от этого зависит стоимость его реализации, причем, эта стоимость может возрасти на порядки. Это вынуждает принимать решение в момент наименьшей стоимости реализации, т.е. заблаговременно, т.е. BDUF. Это та самая причина, по которой итеративная разработка до конца 90-х, конечно же, была, но она была экономически нецелесообразной, и поэтому не нашла массовости.
Кое-что произошло в конце 90-х. Много писать не буду, скажу только, что это привело к другому графику, который приводит Кент Бек:
https://emacsway.github.io/_images/asymptotic-cost-of-change.png
При втором графике стоимость реализации уже не так сильно зависит от момента принятия решения. Это позволяет принимать и изменять решения когда программа уже реализована, опираясь на фидбэк от практической эксплуатации решений, реализованных в предыдущих итерациях. С этого момента итеративные разработки начинают становиться массовыми, но, надо заметить, что до сих пор этот вопрос протекает проблемно, и здесь масло в огонь подлило одно судьбоносное решение Кена Швабера в Скраме. Но это уже детали.
» одно судьбоносное решение Кена Швабера в Скраме
Можете рассказать ,какое именно?
Можете рассказать ,какое именно?
I
> и здесь масло в огонь подлило одно судьбоносное решение Кена Швабера в Скраме. Но это уже детали
Интересно, раскроете какое?
Интересно, раскроете какое?
Скрам включал в себя набор технических практик, заимствованных из XP, нацеленных на снижение стоимости изменения кода. Но это сдерживало продвижение Скрама в массы, так как вносило организационную сложность. Кен хотел форсировать распространение Agile, и убедил Джеффа Сазерленда вынести эти технические практики за пределы Скрама, четко обозначив Скрам как фреймворк, который разработчики, по своему усмотрению, должны дополнять практиками.
Скрам, действительно, стал распространяться вирусно. Но проблема в том, что на технические практики мало кто обращал должное внимание, что приводило к взлету стоимости изменения кода, при котором Agile уже не обладал экономическим превосходством перед BDUF. Это подмочило репутацию Agile на рынке. По этому поводу есть статья на AgileAlliance (сайт основан подписантами манифеста)
https://www.agilealliance.org/how-to-increase-velocity/
Скрам, действительно, стал распространяться вирусно. Но проблема в том, что на технические практики мало кто обращал должное внимание, что приводило к взлету стоимости изменения кода, при котором Agile уже не обладал экономическим превосходством перед BDUF. Это подмочило репутацию Agile на рынке. По этому поводу есть статья на AgileAlliance (сайт основан подписантами манифеста)
https://www.agilealliance.org/how-to-increase-velocity/
ST
Я всегда говорил, что лучше всего понимать суть вещей от первоисточника. Наибольшее влияние на 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
При втором графике стоимость реализации уже не так сильно зависит от момента принятия решения. Это позволяет принимать и изменять решения когда программа уже реализована, опираясь на фидбэк от практической эксплуатации решений, реализованных в предыдущих итерациях. С этого момента итеративные разработки начинают становиться массовыми, но, надо заметить, что до сих пор этот вопрос протекает проблемно, и здесь масло в огонь подлило одно судьбоносное решение Кена Швабера в Скраме. Но это уже детали.
Кент приводит два графика стоимости изменения кода, по которым может протекать разработка.
Первый график: 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 хоть на рабочих местах. До этого процесс компиляции и сборки был священнодействием системных программистов.
В основном произошел закон Мура. Стоимость машинного времени упала на порядки, что позволило начать развиваться CI/CD хоть на рабочих местах. До этого процесс компиляции и сборки был священнодействием системных программистов.