👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Ой... Плакса Zed Show... У него все виноваты, кроме него самого... Только увидел его подпись, дальше не читал.

Только увидел его подпись, дальше не читал.

там, дальше, после его подписи и читать то нечего :)

а мне сначало стало интересно кто этот бред написал. Потом всё стало понятно.

какой бред если вы не читали? :)

тот что выше подписи

а мне сначало стало интересно кто этот бред написал.

А почему бред?

А кто разжованные требования программистам «доставляет»?

Просто тут нахватает ещё одного компонента — Analyze And Write Requirements, Motherfucker.

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

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

А в чем проблема для проектов, где никто никого не знает?

Это то, что я делаю дома на своем пет-проекте. Потому что четко понимаю что мне нужно делать и как.

В рабочих проектах как правило никто нихрена не понимает что нужно делать и зачем. И в первую очередь — заказчик. Поэтому играем в скрам, митингуем, переделываем по 20 раз...

В рабочих проектах как правило никто нихрена не понимает что нужно делать и зачем. И в первую очередь — заказчик. Поэтому играем в скрам, митингуем, переделываем по 20 раз...

Ибо это выгоднее исполнителю чем нанять аналитика.

ну некоторые заказчики это понимают и нанимают менеджеров которые могут в getting shit done. Правда я такое видел очень редко )

Зачем играть во что-то? Может просто сесть и обсудить все, записать на листочке. Потом ещё раз обсудить, и записать. И так пока не будут четкие конкретные продумные требования, и после этого уже делать так — как написано в заголовке темы?

Что тут обсуждать? Детский сад

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

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

Если провести аналогию с постройкой дома, твоя методология расшифровывается как «просто класть камни».
Выйдет куча камней

Потому, что писать код

«Programming» (программирование) и «Coding» (написание кода) — это немного разные процессы.

Если просто кодить, без планирования,...

Если вкратце, то идея оградить исполнителя (программиста) от управленческих задач. Задача «программиста» как раз просто сделать продукт, а за сроками, требованиями, планированием, связью с бизнесом, печеньками и тд будет следить менеджер.

P.S. Я то думал вы про стиль изложения.

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

Допустим, проект не вкладывается в сроки. Нужно выйти в субботу, менеджер к разработчику:" Вась, а Вась, в субботу поработаешь?" А разработчик ему: «директор, пошёл ты в ж_пу директор!© Сам принимал сроки, меня не спрашивал — вот теперь сам и расхлёбывай. А у меня в контракте восьмичасовый день прописан»

Вот, всяческие «процессы» для того и нужны, чтоб

1) адекватно оценивать сроки

2) если уж и случился ляпсус с оценкой тебя не послали на три буквы

Не, конечно можно и чувство вины культивировать, но внимание... это тоже процесс. Да кроме того, могут попасться люди со стержнем — пошлют подальше и дело с концом.

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

И к чему вы это сказали?

1) адекватно оценивать сроки

И почему это должен делать программист, почему он это должен делать раз в 1-3 недели?

2) если уж и случился ляпсус с оценкой тебя не послали на три буквы

А что мешает Васе сказать

А у меня в контракте восьмичасовый день прописан

Если он дал не верную оценку?

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

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

И почему это должен делать программист, почему он это должен делать раз в 1-3 недели?

Потому, что менеджер не технический специалист.

А что мешает Васе сказать
А у меня в контракте восьмичасовый день прописан

Если он дал не верную оценку?

Во первых, если сам сказал, до известных пределов работает самолюбие.

Во вторых, если сказал сам, скорее всего это будет ближе к истине, чем чужая оценка.

Во первых, если сам сказал, до известных пределов работает самолюбие.

Есть 2 типа людей: те которые посылают нах и те кто не посылает нах.

Фактически вы предлагаете манипулировать чувством вины — это к добру не приведет.

Во вторых, если сказал сам, скорее всего это будет ближе к истине, чем чужая оценка.

Потому, что менеджер не технический специалист.

Не важно кем он не является, важно кем он есть. Менеджер — это управленец, у него есть опыт и знания, на основание которых он может ставить строки. Если он профессионал.

Я не говорю что не должно быть процесса. Я лишь спрашиваю: Надо ли передавать исполнителям права и обязанности управленцев?

у него есть опыт и знания, на основание которых он может ставить строки

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

Надо ли передавать исполнителям права и обязанности управленцев?

Это зависит от процесса, в ватерфоле не надо, в ХП надо, в скраме управленческие решения принимает продакт овнер.

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

Опыт в программировании не нужен. Нужно понимание того чем он управляет, в данном случае процессом разработки.

Это зависит от процесса

Вопрос: Накуя?

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

Принято.

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

Когнитивный этот самый. А как же этот самый процесс, если все равно все сводится к «достичь любой ценой»?

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

как же этот самый процесс, если все равно все сводится к «достичь любой ценой»?

Организационный процесс это процесс организации деятельности наиболее рациональным способом

allendy.ru/...rg-process.html

Основные принципы рациональной организации как управ¬ленческой функции — это:
— определение и детализация целей;
— определение приемов, способов деятельности, способствующих достижению этих целей;
— поручение различных задач индивидуумам (разделение труда) и объединение их в управляемые рабочие группы;
— координация, согласование различных видов деятельности, порученных каждой группе;
— обеспечение единства целей;
— установление эффективного контроля.

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

Так что, всё равно нужно планировать соотношения кнута и пряника, а это и есть рациональный организационный процесс

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

2) если уж и случился ляпсус с оценкой тебя не послали на три буквы

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

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

Если провести аналогию с постройкой дома, твоя методология расшифровывается как «просто класть камни».

А каменщики и должны «просто класть камни». Не сидеть на собраниях, не читать заказчику стихи и не спорить с архитектором по поводу красоты проекта.

А в ИТ получается так: на хорошего ПМа, архитекта и синьора денег нет — лучше наймем кучу ньюбов и пусть они будут «агильными», «кросс-функционалыми», «самоорганизующимися» и «коммуникабельными» — что бы самим делать все что надо. В итоге получается халтура из разряда «мы кладем на совесть».

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

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

некоторые здания по тысяче лет стоят

Они построены без плана? Планирование не обеспечивает успеха, но без него не будет ничего

Поддерживаю, создание ПО — это написание кода + архитектура что тоже является по сути высокоуровневым написанием кода.

Наверное для аутистов самое оно.

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

Signed: Zed A. Shaw, поэтому как минимум Mongrel.

Вполне логично:

Find out what the customers want by asking them.
Get what the Programming Motherfuckers need to get shit done.
Tell the Programming Motherfuckers when their shit is not good enough to sell.

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

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

придется как-то формализовать

Get what the Programming Motherfuckers need to get shit done.

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

почему :) если погромист исповедует эту религию, он сам вполне осознает что его задача — решить задачу :)

Там есть еще более важный момент:

...figures out the strategic plans, orders the cookies and sodas,...

programming-motherfucker.com a sort of joke movement that I created and sell t-shirts for

Что и подтверждает тот факт, что все хорошее строится на реальных задачах, а не на попытке разработать что-то правильное :)

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

Ну это уже детали :) Сначала он его все же написал.

Все пральна сделал ©

Наверное для аутистов самое оно.

Почему для аутистов?

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

Есть подозрение что mongrel :)

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

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

А если посмотреть так:

В «остальных методологиях» общения, которое так любят распиздяи (уж простите за стиль изложения), куда больше.

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

Поэтому не смотря на формальные правила, стиль взаимодействия складывается со временем, скорее сам по себе. Как в той истории про тропинки: сначала протопчим там где удобно, а потом уже асфальт.

вы не находите, что до вас эти тропинки уже были протоптаны и был положен асфальт и вас просто смущает, что эти тропинки не вы протаптывали?

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

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

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

Ну как бы да. Дом я не перенесу, дорогу напрямую от работы к дому тоже перекладывать не предлагаю.

То есть как бы задача, бизнес интересы — это внешние условия, эти условия игры меняются очень трудно. Но собственно и речь не об этом.

что-то мы вообще не в ту степь заехали.

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

Есть много «но». У нас в универе физик говорил что нужно верить в приметы, которые обещают хорошую оценку. Так же и тут: хорошо все что работает, для вас, в данной конкретной ситуации. Если методология прям просится для конкретной ситуации — почему бы и нет, если ничего не просится:

http://пиши-код-блять.рф/

по крайней мере у вас будет код. Как и когда его релизить — решить легче, когда есть предмет обсуждения :) Да и код — это гораздо более понятный предмет обсуждения, чем то «как мы будем обсуждать, то как мы пишем код».

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

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

Но разве при хорошем процессе и с хорошими коммуникациями не должно быть хорошо видно и понятно, что есть проблема в кодировании если она есть?

Просто иногда это приобретает черты карго-культа. В таких случаях лучше кодить.

А разве кодинг не может приобретать черты карго-культа? Когда вместо обсуждения или планирования кодится много строк, от которых только хуже становится и которые потом жалко выбросить.

У кодирования есть хотя бы критерий — работает проект или нет. Без написанного кода, даже плохого (из которого состоит 90% корпоративного софта), функциональности не будет вообще.

Хороший подход, правильный. ПО само не напишется :)

Подписаться на комментарии