Комментарии 45
В Макдонольдс из людей делают роботов. А у программисты — это те, кто составляет инструкции для роботов. Естественно походы должны существенно отличаться.
В целом все верно, хоть статья и капитанская.
Если подходить к разработке как к разработке чего-то уникального, то да. Методы макдональдс не подходят.
Но, к сожалению, мы живем не в идеальном мире. Подавляющее большинство программ, которые пишут сейчас программисты это типичные сайты. И вот там-то как раз творчества у программистов минимум. Все творчество в этих проектах у дизайнеров.
Конвеер тут как раз подходит. Ибо организация довольно быстро вырабатывает свой стек технологий и пилит на них проект за проектом. Это уже не художники, а маляры. А работу маляров уже можно нормировать, что собственно и происходит. И таких программистов большинство. Это не плохо и не хорошо, это просто жизнь. Программы стремительно ворвались во все сферы деятельности и из творческой работы, программирование превращается в обычную работу. Процент творчество/процесс доходит до обычных соотношений
других профессий, по мере развития технологий.
Если подходить к разработке как к разработке чего-то уникального, то да. Методы макдональдс не подходят.
Но, к сожалению, мы живем не в идеальном мире. Подавляющее большинство программ, которые пишут сейчас программисты это типичные сайты. И вот там-то как раз творчества у программистов минимум. Все творчество в этих проектах у дизайнеров.
Конвеер тут как раз подходит. Ибо организация довольно быстро вырабатывает свой стек технологий и пилит на них проект за проектом. Это уже не художники, а маляры. А работу маляров уже можно нормировать, что собственно и происходит. И таких программистов большинство. Это не плохо и не хорошо, это просто жизнь. Программы стремительно ворвались во все сферы деятельности и из творческой работы, программирование превращается в обычную работу. Процент творчество/процесс доходит до обычных соотношений
других профессий, по мере развития технологий.
Про сайты полностью согласен. Это массовое производство.
ИМХО, это не так. Goole, Amazon, Yandex, Mail.ru — это не сайты. Это сервисы. Порой наукоемкие и уникальные. А еще есть продуктовая разработка и автоматизация бизнеса.
Подавляющее большинство программ, которые пишут сейчас программисты это типичные сайты.
ИМХО, это не так. Goole, Amazon, Yandex, Mail.ru — это не сайты. Это сервисы. Порой наукоемкие и уникальные. А еще есть продуктовая разработка и автоматизация бизнеса.
А к игроделу это применимо?
Да, но естественно не к любым проектам.
Для большинства мобильных, флеш и им подобных проектов так и есть. Игры в сторах на 90% братья близнецы.
А это и есть, то самое, массовое производство.
Для большинства мобильных, флеш и им подобных проектов так и есть. Игры в сторах на 90% братья близнецы.
А это и есть, то самое, массовое производство.
В высшей степени. Посмотрите на кучу «веселых фермеров». Если посчитать долю оригинальных разработок в области игр, то игрострой покажется еще большей рутиной, чем клепание сайтов.
К сожалению — не всё так однозначно. Возможно мне стоит написать отдельный пост на тему конвейерного метода организации программирования. И назову её «Домик из говна. Правильный способ производства ПО в индийских условиях».
У меня был личный опыт участия в подобном, в бытность стажировки в Индии в 2005 году. Сейчас эта структура называется Aricent, тогда это был Flextronics Software Systems (CMMI-5).
Огромный проект для телекома, целевая платформа Solaris 8. Его делает большая толпа (>120 человек) малоквалифицированных исполнителей (что всем очень понравится — индусов) с тоненькой прослойкой тимлидов уровня нормальных программистов (тоже индусов) и индусский менеджмент. Плюс группка стажёров, заброшенных с Украины и Беларуси чтобы оторвать кусок проекта в ту сторону.
Был устроен фабричный конвейер в чистейшем незамутнённом виде:
— Перед включением в проект — ПТУ. «Дети, знакомьтесь — это проект, проект — это дети». Серия тренингов об архитектуре проекта и всему инструментарию сверху до низу (включая vim, version control ClearCase, разбиение на модули, как входить на девелоперский сервер и т.д.), плюс вводная как это должно реализовываться. Для самого конечного исполнителя с сонным выражением лица стоящего в строю.
— API и архитектура — прибиты гвоздями заранее.
— Система спроектирована таким образом, что всё сделано через FSM. Исполнители кодят функции переходов между состояниями И ВСЁ. В худшем случае производительность участника можно оценивать количеством написанных функций в день. Их сотни и они одинаковые. Индусы радостно копипейстят одно и тоже.
непридуманный диалог со standup daily meeting:
— проект для рядового исполнителя разбит на стадии:
а. 2-3 месяца кодим, и только кодим. Вся команда кодит. 120 человек. Даже компиляция проверяется весьма эпизодически
б. 2 недели — юнит тесты. За программирование — бьют по рукам, только пишем тесты. Code coverage проверяется и прочие вещи.
в. 2 недели системная интеграция, заставляем модули работать вместе
В итоге через полгода работы (включая фазы подготовки людей, проектирования и непосредственно реализации) — имеем первую версию системы. За полгода 120 человек написали маштабируемую 3G VoIP телефонию (HA, расширяемость, все дела). На тестах первая итерация системы поддерживает только 2 (!) пользователей и всегда зависает на 35 звонке. Тимлиды возвращаются с показов заказчику седыми.
Но… Начинается следующая итерация «проектирование» ->«кодинг»->«юнит тестирование»->«системная интеграция». И я полностью уверен, что после 5 итерации система заработала в полном обьёме. Её тупо массой задавили и грамотным использованием неквалифицированных исполнителей в правильно выстроенным для них процессе.
Мои аплодисменты менеджменту и проектировщикам. Как выстроить людей, допускающих ДИЧАЙШИЕ косяки и особенно не умеющих программировать, в конвейер. И получить результат.
У меня был личный опыт участия в подобном, в бытность стажировки в Индии в 2005 году. Сейчас эта структура называется Aricent, тогда это был Flextronics Software Systems (CMMI-5).
Огромный проект для телекома, целевая платформа Solaris 8. Его делает большая толпа (>120 человек) малоквалифицированных исполнителей (что всем очень понравится — индусов) с тоненькой прослойкой тимлидов уровня нормальных программистов (тоже индусов) и индусский менеджмент. Плюс группка стажёров, заброшенных с Украины и Беларуси чтобы оторвать кусок проекта в ту сторону.
Был устроен фабричный конвейер в чистейшем незамутнённом виде:
— Перед включением в проект — ПТУ. «Дети, знакомьтесь — это проект, проект — это дети». Серия тренингов об архитектуре проекта и всему инструментарию сверху до низу (включая vim, version control ClearCase, разбиение на модули, как входить на девелоперский сервер и т.д.), плюс вводная как это должно реализовываться. Для самого конечного исполнителя с сонным выражением лица стоящего в строю.
— API и архитектура — прибиты гвоздями заранее.
— Система спроектирована таким образом, что всё сделано через FSM. Исполнители кодят функции переходов между состояниями И ВСЁ. В худшем случае производительность участника можно оценивать количеством написанных функций в день. Их сотни и они одинаковые. Индусы радостно копипейстят одно и тоже.
непридуманный диалог со standup daily meeting:
PM — Ритика, сколько функций ты вчера написала?
Ритика — 17
PM — Плохо! А ты Вишну?
Вишну — Я написал 36 функций!
PM — Молодец, Вишну! Всем тоже писать 36 функций в день!
— проект для рядового исполнителя разбит на стадии:
а. 2-3 месяца кодим, и только кодим. Вся команда кодит. 120 человек. Даже компиляция проверяется весьма эпизодически
б. 2 недели — юнит тесты. За программирование — бьют по рукам, только пишем тесты. Code coverage проверяется и прочие вещи.
в. 2 недели системная интеграция, заставляем модули работать вместе
В итоге через полгода работы (включая фазы подготовки людей, проектирования и непосредственно реализации) — имеем первую версию системы. За полгода 120 человек написали маштабируемую 3G VoIP телефонию (HA, расширяемость, все дела). На тестах первая итерация системы поддерживает только 2 (!) пользователей и всегда зависает на 35 звонке. Тимлиды возвращаются с показов заказчику седыми.
Но… Начинается следующая итерация «проектирование» ->«кодинг»->«юнит тестирование»->«системная интеграция». И я полностью уверен, что после 5 итерации система заработала в полном обьёме. Её тупо массой задавили и грамотным использованием неквалифицированных исполнителей в правильно выстроенным для них процессе.
Мои аплодисменты менеджменту и проектировщикам. Как выстроить людей, допускающих ДИЧАЙШИЕ косяки и особенно не умеющих программировать, в конвейер. И получить результат.
Наверно этот метод надо назвать «Атака Зомби»
Я предлагаю ещё более крутое название. «Атака Браминов-Зомби».
100% программистов в Aricent были из касты браминов. Это связано полагаю с невозможностью получить высшее образование представителям других каст. Плюс пониженная доступность нормальных школ, из которых можно поступить на IT-специальности.
100% программистов в Aricent были из касты браминов. Это связано полагаю с невозможностью получить высшее образование представителям других каст. Плюс пониженная доступность нормальных школ, из которых можно поступить на IT-специальности.
насчёт зомби — классическая конвейерная потогонка.
Я приходил в Guest House после работы и падал в кровать лицом вперёд не раздеваясь. И засыпал мгновенно.
Я приходил в Guest House после работы и падал в кровать лицом вперёд не раздеваясь. И засыпал мгновенно.
Спасибо. Оч. интересный опыт.
Возможно мой пост слишком категоричен. Конечно можно и конвейер построить. Только вот вопрос, насколько он будет конкурентоспособен на рынке?
Возможно мой пост слишком категоричен. Конечно можно и конвейер построить. Только вот вопрос, насколько он будет конкурентоспособен на рынке?
Для действительно больших и масштабных проектов — мне кажется вполне конкурентоспособен. Для типичных аутсорсеров из Восточной Европы и ex-USSR — они просто не смогут собрать такое дикое количество исполнителей на один проект. Плюс эти исполнители сравнительно малооплачиваемые и очень держатся за свою работу (рядом с офисом на улице на тротуарах спят бездомные, за стеной офиса — свалка, где коровы и бомжи конкурируют за отбросы).
Приемлимого качества продукта в целом с помощью такого модифицированного итерационного waterfall-конвейера можно добится к 4-5 итерации. Есть ниши для подобных долгоиграющих проектов. Как писал незабвенный Брукс в «Мифическом человеко-месяце» — на больших проектах на первый план выходят вопросы организации труда и взаимодействия внутри и между проектных команд, входящих в коллектив проекта.
Приемлимого качества продукта в целом с помощью такого модифицированного итерационного waterfall-конвейера можно добится к 4-5 итерации. Есть ниши для подобных долгоиграющих проектов. Как писал незабвенный Брукс в «Мифическом человеко-месяце» — на больших проектах на первый план выходят вопросы организации труда и взаимодействия внутри и между проектных команд, входящих в коллектив проекта.
А насколько малооплачиваемы?
Давайте проведем мыслительный эксперимент. Пусть средняя ставка в час у тех 120 разработчиков 3 бакса. Вместо них можно собрать 12 человек со средней ставкой 30 баксов в час. Такую команду можно легко собрать на территории России и ближнего зарубежья. Я предположу, что это будет очень сильная команда, и за 6 месяцев они могут сделать не меньше той толпы индусов. При этом будет сразу экономия на сопровождающий ресурс — менеджмент и аналитиков (которые обязаны разжевывать требования до диаграмм выполнения кода). Я уже не говорю про другие факторы типа тех долга, стоимости внесения изменений, количестве issues на 1000 строк кода.
Что скажете? Похоже на правду?
Давайте проведем мыслительный эксперимент. Пусть средняя ставка в час у тех 120 разработчиков 3 бакса. Вместо них можно собрать 12 человек со средней ставкой 30 баксов в час. Такую команду можно легко собрать на территории России и ближнего зарубежья. Я предположу, что это будет очень сильная команда, и за 6 месяцев они могут сделать не меньше той толпы индусов. При этом будет сразу экономия на сопровождающий ресурс — менеджмент и аналитиков (которые обязаны разжевывать требования до диаграмм выполнения кода). Я уже не говорю про другие факторы типа тех долга, стоимости внесения изменений, количестве issues на 1000 строк кода.
Что скажете? Похоже на правду?
Похоже, но этих 12 супер-старов должен кто-то прособеседовать и, скорее всего, их придется «вынимать» с какой-то другой работы, где он долго работает. Пойдет ли человек на 6 месяцев в непонятный проект на таких условиях? Должно быть не 30 а все 50.
Продолжу мысленный эксперимент.
— Из набранных 12 человек трое пропадут в течении первого месяца. Просто не выйдут на работу и все.
— Второй месяц все будет тихо и команда, возможно, даже будет работать на отлично. Только придется чуть сдвинуть сроки, потому что в команде теперь не 12, а 9 человек.
— На третьем месяце трое попросятся в отпуска, из которых вернется только два человека (третий таким хитрым образом проскочил испытательный срок в другой конторе). Вы в срочном порядке начнете искать замену недостающим- ведь из планировавшихся 12 работников осталось 8 человек. Пока вы будете их искать вам придется отвлекать уже сверх нормы загруженых членов команды от проекта на интервью, планирование и пере-планирование (на менеджерах же сэкономили, пусть сами программисты теперь отдуваются). Ваши программисты вместо программирования будут сидеть на минингах и охреневать от скуки, пока вы с их помощью решите кто будет закрывать задачи, которые должны были закрывать ушедшие работники. Кстати, сроки опять сдвигаются и на этот раз уже значительно — помимо неполной команды, вы еще тормозите работу пере-планированием и интервью.
— На четвертом месяце путем героических усилий вам удается нанять двоих, предложив им повышенную зарплату. Узнав о реальной разнице в оплате между новичками, и теми, кто начинал проект, еще один ушел в другую контору на похожий проект, а трое других вытребовали с вас повышение зарплаты. Правда вы нашли еще одного работника на зарплату ушедшего, хоть у него уровень и не такой высокий, как у остальных.
— На пятом месяце вы имеете пять человек, которым вы платите завышенную зарплату, четырех недовольных тем, что «им подняли, а нам нет», три новых работника, постоянно пристающих к вам с вопросами «зачем так, давайте переделаем», уже окончательно сорванные сроки, распухший бюджет (вы же увеличили зарплату фактически половине команды), одного новичка, который «не тянет», озлобленных клиентов (или Upper management, если проект внутренний). На этом месте вы осознаете, кто качество кода, который неполная команда выдавала последние два месяца несколько не соответствует ожиданиям. С другой стороны их сложно упрекать — каждый работал за двоих или даже троих.
И это я еще даже не включил в условия эксперимента остальные персонально-личностные отношения: один из работников окажется «звездой», человека четыре будут втихаря делать «как правильно», а не как договорились на прошлой неделе, еще двое внезапно решат, что свои модули они не будут писать на «этом вашем дотнете», какой-нибудь избранный будет писать код «в чилийской нотации» аргументируя это тем, что это его стиль.
:)
— Из набранных 12 человек трое пропадут в течении первого месяца. Просто не выйдут на работу и все.
— Второй месяц все будет тихо и команда, возможно, даже будет работать на отлично. Только придется чуть сдвинуть сроки, потому что в команде теперь не 12, а 9 человек.
— На третьем месяце трое попросятся в отпуска, из которых вернется только два человека (третий таким хитрым образом проскочил испытательный срок в другой конторе). Вы в срочном порядке начнете искать замену недостающим- ведь из планировавшихся 12 работников осталось 8 человек. Пока вы будете их искать вам придется отвлекать уже сверх нормы загруженых членов команды от проекта на интервью, планирование и пере-планирование (на менеджерах же сэкономили, пусть сами программисты теперь отдуваются). Ваши программисты вместо программирования будут сидеть на минингах и охреневать от скуки, пока вы с их помощью решите кто будет закрывать задачи, которые должны были закрывать ушедшие работники. Кстати, сроки опять сдвигаются и на этот раз уже значительно — помимо неполной команды, вы еще тормозите работу пере-планированием и интервью.
— На четвертом месяце путем героических усилий вам удается нанять двоих, предложив им повышенную зарплату. Узнав о реальной разнице в оплате между новичками, и теми, кто начинал проект, еще один ушел в другую контору на похожий проект, а трое других вытребовали с вас повышение зарплаты. Правда вы нашли еще одного работника на зарплату ушедшего, хоть у него уровень и не такой высокий, как у остальных.
— На пятом месяце вы имеете пять человек, которым вы платите завышенную зарплату, четырех недовольных тем, что «им подняли, а нам нет», три новых работника, постоянно пристающих к вам с вопросами «зачем так, давайте переделаем», уже окончательно сорванные сроки, распухший бюджет (вы же увеличили зарплату фактически половине команды), одного новичка, который «не тянет», озлобленных клиентов (или Upper management, если проект внутренний). На этом месте вы осознаете, кто качество кода, который неполная команда выдавала последние два месяца несколько не соответствует ожиданиям. С другой стороны их сложно упрекать — каждый работал за двоих или даже троих.
И это я еще даже не включил в условия эксперимента остальные персонально-личностные отношения: один из работников окажется «звездой», человека четыре будут втихаря делать «как правильно», а не как договорились на прошлой неделе, еще двое внезапно решат, что свои модули они не будут писать на «этом вашем дотнете», какой-нибудь избранный будет писать код «в чилийской нотации» аргументируя это тем, что это его стиль.
:)
Проект не будет стартовать сразу с 12 разработчиками. Для них всех не будет работы. Вначале будет сформирован костяк из сеньоров для проработки требований и формирования архитектуры, а потом потихонечку будут подключаться рабочие руки.
Я думаю, что в Индии можно словить всех 120 ребят быстро, но подготовка нужна серьезнее.
За 5 лет опыта ни разу не встречался с такими хитрыми, даже не слышал. Ок, может не повезло.
Не думаю, что с отпусками и перетеканием сотрудников в другие конторы ситуация принципиально отличается.
Перепланирование можно делать гораздо безболезненее, особенно в рамках митингов. Предположу, что чистый менеджмент может быть (в зависимости от масштаба проекта), но его в любом случае будет меньше, чем там.
По зп — сетки я бы устроил прозрачные, пересмотр зп по результатам, особенно в начале, чтобы исключить подобное недовольство.
По поводу работы команды в тихаря, вопросов по тех деталям, отношений — тимлид и сеньоры должны быть опытными и сильными, это да… Agile… А в общем то эти проблемы встречаются всюду и успешно решаются.
Мне кажется, Вы сильно сгустили краски :)
И даже с такими рисками мне было бы страшнее начинать проект с той толпой индусов. :)
Я думаю, что в Индии можно словить всех 120 ребят быстро, но подготовка нужна серьезнее.
За 5 лет опыта ни разу не встречался с такими хитрыми, даже не слышал. Ок, может не повезло.
Не думаю, что с отпусками и перетеканием сотрудников в другие конторы ситуация принципиально отличается.
Перепланирование можно делать гораздо безболезненее, особенно в рамках митингов. Предположу, что чистый менеджмент может быть (в зависимости от масштаба проекта), но его в любом случае будет меньше, чем там.
По зп — сетки я бы устроил прозрачные, пересмотр зп по результатам, особенно в начале, чтобы исключить подобное недовольство.
По поводу работы команды в тихаря, вопросов по тех деталям, отношений — тимлид и сеньоры должны быть опытными и сильными, это да… Agile… А в общем то эти проблемы встречаются всюду и успешно решаются.
Мне кажется, Вы сильно сгустили краски :)
И даже с такими рисками мне было бы страшнее начинать проект с той толпой индусов. :)
Непохоже, начиная с «можно собрать 12 человек со средней ставкой 30 баксов в час». Проблемой всегда было даже качественных 3-4 исполнителей найти. Я всегда работаю напрямую с HR своих компаний (хобби такое, неофициально), и знаю каково положение на рынке труда (очень перегрет, много лет подряд, проектов больше чем возможных исполнителей).
Технический долг может накапливаться, если лепят worlarounds. А если хреначат единственно разрешённым способом, без возможности обойти спущенные сверху догмы по инструментарию, организации кода, стилю и архитектуре — то тут единственное что может не удасться — это в срок накодить все фичи. В некоторых модулях упомянутой мной системы — не всё успевали, и выборочно выкашивали из первой итерации функционал.
Менеджмента на нашем Zerg Rush было не больше чем на типичном проекте разработки в западном стиле. Аналитики — тоже не так много, документация верхнего уровня написана ими, документация уровня подпроекта — тимлидами, документация уровня модуля — рядовыми исполнителями. Так уж получилось — что я документацию вычитывал. Помню, что качество линейно зависело от должности автора доки в иерархии компании :).
Стоимость внесения изменений? Везде одинаковая, куда не плюнь идентичный однообразный код.
Количество issues — стандартное, индусам не давали разгуляться в фантазиях.
Технический долг может накапливаться, если лепят worlarounds. А если хреначат единственно разрешённым способом, без возможности обойти спущенные сверху догмы по инструментарию, организации кода, стилю и архитектуре — то тут единственное что может не удасться — это в срок накодить все фичи. В некоторых модулях упомянутой мной системы — не всё успевали, и выборочно выкашивали из первой итерации функционал.
Менеджмента на нашем Zerg Rush было не больше чем на типичном проекте разработки в западном стиле. Аналитики — тоже не так много, документация верхнего уровня написана ими, документация уровня подпроекта — тимлидами, документация уровня модуля — рядовыми исполнителями. Так уж получилось — что я документацию вычитывал. Помню, что качество линейно зависело от должности автора доки в иерархии компании :).
Стоимость внесения изменений? Везде одинаковая, куда не плюнь идентичный однообразный код.
Количество issues — стандартное, индусам не давали разгуляться в фантазиях.
Плюс эти исполнители сравнительно малооплачиваемые и очень держатся за свою работуИз касты браминов?
Да, браминов. Они вкалывали, как проклятые, 12-14 часов в день, а когда сроки сгустились — и без выходных. Другое дело что мозга в этом зерг-раше было мало.
Рядом с офисом на тротуаре спят бездомные. А за стеной вокруг офиса — находится шикарная свалка на N гектар, где за пищевые отбросы конкурируют семьи бомжей и коровы. Я не сгущаю, достаточно было подняться на крышу офиса конторы в Гургаоне (город-спутник Дели) — чтобы получить вид на то как живёт остальная страна. Думаю это стимулирует.
Рядом с офисом на тротуаре спят бездомные. А за стеной вокруг офиса — находится шикарная свалка на N гектар, где за пищевые отбросы конкурируют семьи бомжей и коровы. Я не сгущаю, достаточно было подняться на крышу офиса конторы в Гургаоне (город-спутник Дели) — чтобы получить вид на то как живёт остальная страна. Думаю это стимулирует.
Консультировал я похожий кейс. Там, к сожалению, массой можно давить до определенного предела. Потом проблема сложности разрастается на харчах технического долга, отращивает несколько голов с большими пастями и начинает откусывать разработчикам руки-ноги-головы: попытка добавить что угодно занимает недели, система падает непонятно где и непонятно почему, в архитектуре не разбирается уже никто. На такой стадии обычно увольняются несколько ключевых разработчиков, после чего проект переписывается с нуля другим подрядчиком и история повторяется :).
Границы применимости — есть у любой методики разработки.
Кстати, я не упомянул, но на весь проект была документация, которую заставляли писать.
Как и у всего проекта в целом — её качество падало в зависимости от уровня. Высоко-уровневые архитектурные вещи — описаны отлично, чем ближе к коду — тем хуже и out of date. Ну и код — то хуже всего :).
Кстати, я не упомянул, но на весь проект была документация, которую заставляли писать.
Как и у всего проекта в целом — её качество падало в зависимости от уровня. Высоко-уровневые архитектурные вещи — описаны отлично, чем ближе к коду — тем хуже и out of date. Ну и код — то хуже всего :).
Ключевой момент — проектирование системы, API и FSM. Кто это сделал? «Тимлид уровня среднего разработчика» на такое не способен. Спроектировать API так, чтобы его смогла заимплементировать толпа в 120 мартышек — это очень и очень нехилый скилл, и такое проектирование требует очень и очень много времени. Думаю, что не ошибусь, если скажу, что работа архитекторов этой системы стоила дороже, чем работа 120 «программистов».
Архитектура была не очень сложная. И, судя по всему, типовая для этой конторы. Мне показалось что они уже делали подобные проекты. Было в составе одна или две звезды разработки, которые обитали где-то на верхних уровнях иерархии и спускали сверху правильные стратегические решения. Плюс менеджмент, меня больше всего удивил менеджмент сего зерг-раша. Вот где скилл! Как принципиально не-западное мышление и поведение исполнителей интегрировать в западную модель разработки с предсказуемыми рисками и сроками.
Это ж нейросетка на индусах! Строим софт генетическим методом!
Описано всё забавно и очень правдоподобно, но я отказываюсь верить, что «после 5 итерации система заработала». Точнее, что в результате получилась «система», а не шмот переваренных пельменей, красиво обложенных тестами, которые только и проходят на подобраных данных.
Если вы делаете механические часы, как можно надеяться на овальные шестерёнки и «шлифовку кирпичом»? Хоть всю систему по блокам опиши, некачественный код даст о себе знать — не сейчас, так при развитии проекта.
У меня тоже был «кооперэйшн» с индусами, которые готовы слепить хоть lamborgini! Это только потом ты узнаёшь, что двери — из фанеры, петли — снизу, а закрывается щеколдочкой изнутри — примерно так выглядела их работа в первой итерации. После разноса щеколдочку перенесли наружу, петли убрали вообще, а вход был через sunroof. Больше мы этих макак не нанимали. :)
Если вы делаете механические часы, как можно надеяться на овальные шестерёнки и «шлифовку кирпичом»? Хоть всю систему по блокам опиши, некачественный код даст о себе знать — не сейчас, так при развитии проекта.
У меня тоже был «кооперэйшн» с индусами, которые готовы слепить хоть lamborgini! Это только потом ты узнаёшь, что двери — из фанеры, петли — снизу, а закрывается щеколдочкой изнутри — примерно так выглядела их работа в первой итерации. После разноса щеколдочку перенесли наружу, петли убрали вообще, а вход был через sunroof. Больше мы этих макак не нанимали. :)
Насколько мне известно — заказчик (крупный вендор производящий телекоммуникационное оборудование) систему принял. И продолжает сотрудничество с нашими любимыми индусами. Не путайте качество работы конечных исполнителей с качеством организации разработки системы в целом. Зерг-раш на тестирование тоже думаю проводился неоднократно.
Касательно вашего bad experience работы с индусами — после вояжа в Flextronics я убедился, что нужен специально обученный на индусов менеджмент, с пониманием их менталитета и особыми палочно-конвейерными методами преодоления хаоса, который они порождают при работе. Некоторые наши ребята вернулись расистами, просто не в силах понять разницу между тем, что у них творится в голове и что творится у индусов.
Некачественный код — заложен в управляемые риски проекта и преодолевается примивитизацией операций, используемых конечными исполнителями. Это высокий полёт по управлению проектами, без всякой иронии.
Пару крутых историй из хроники той поездки:
1. Молодой, красивый и инициативный парень Gunjan, в компании с 3-4 подельниками, по telnet хуячили под одной учётной записью и в одной рабочей копии несколько недель изменения в базовое API. Без коммитов, за несколько недель до релиза. Но их поймал наш любимейший Ramakrishna Pulivendla (PM этого модуля), и раскалённой кочергой внутри-анально принудил к коммиту. Гунджан с подельниками вынужден был править последствия своего авантюризма в режиме 14 часов в день/7 дней в неделю. И из офиса они в понедельник, 12 декабря, в день релиза первой итерации, вышли в 6 утра.
2. Вишну получил задание — надо в логах сделать перенос строки. Чтобы между записями была отбивка 1 строка. Вишну открыл файл с сообщениями (да, система правильно спроектирована), и добавил в 200 сообщений '\n'. Я уверен что вручную, т.к. замене по регулярным выражениям в vim их перед стартом проекта не учили. Этот триумф усидчивой жопы над мозгами увенчивает факт, что было достаточно в макрос вывода логов добавить '\n'. Но, что характерно, задача была решена и это решение даже ничего не сломало :).
Касательно вашего bad experience работы с индусами — после вояжа в Flextronics я убедился, что нужен специально обученный на индусов менеджмент, с пониманием их менталитета и особыми палочно-конвейерными методами преодоления хаоса, который они порождают при работе. Некоторые наши ребята вернулись расистами, просто не в силах понять разницу между тем, что у них творится в голове и что творится у индусов.
Некачественный код — заложен в управляемые риски проекта и преодолевается примивитизацией операций, используемых конечными исполнителями. Это высокий полёт по управлению проектами, без всякой иронии.
Пару крутых историй из хроники той поездки:
1. Молодой, красивый и инициативный парень Gunjan, в компании с 3-4 подельниками, по telnet хуячили под одной учётной записью и в одной рабочей копии несколько недель изменения в базовое API. Без коммитов, за несколько недель до релиза. Но их поймал наш любимейший Ramakrishna Pulivendla (PM этого модуля), и раскалённой кочергой внутри-анально принудил к коммиту. Гунджан с подельниками вынужден был править последствия своего авантюризма в режиме 14 часов в день/7 дней в неделю. И из офиса они в понедельник, 12 декабря, в день релиза первой итерации, вышли в 6 утра.
2. Вишну получил задание — надо в логах сделать перенос строки. Чтобы между записями была отбивка 1 строка. Вишну открыл файл с сообщениями (да, система правильно спроектирована), и добавил в 200 сообщений '\n'. Я уверен что вручную, т.к. замене по регулярным выражениям в vim их перед стартом проекта не учили. Этот триумф усидчивой жопы над мозгами увенчивает факт, что было достаточно в макрос вывода логов добавить '\n'. Но, что характерно, задача была решена и это решение даже ничего не сломало :).
Некачественный код — заложен в управляемые риски проекта и преодолевается примивитизацией операций, используемых конечными исполнителями. Это высокий полёт по управлению проектами, без всякой иронии.У меня обычно хороший код появляется из плохого в результате рефакторинга. А тут сразу проектируется хорошая структура. Высокий полёт, оценил…
— API и архитектура — прибиты гвоздями заранее.Ну с такими вводными, когда каркас, считай, сделан, то и можно делать остальное методом «атака брамино-зомби»…
— Система спроектирована таким образом, что всё сделано через FSM. Исполнители кодят функции переходов между состояниями И ВСЁ
— проект для рядового исполнителя разбит на стадии:Я как-то практиковал подобное в уменьшенном масштабе на микропроекте в одно лицо — неделю тупо кодил в текстовом редакторе, потом компилировал и отлаживал… Методика сработала, но больше я так не делал.
а. 2-3 месяца кодим, и только кодим. Вся команда кодит. 120 человек. Даже компиляция проверяется весьма эпизодически
б. 2 недели — юнит тесты. За программирование — бьют по рукам, только пишем тесты. Code coverage проверяется и прочие вещи.
в. 2 недели системная интеграция, заставляем модули работать вместе
Методы Макдональдса в программировании не работают потому что программирование это проектирование, а не производство.
Скрытая реклама R-Style?
А чего скрывать. У R-Style в Минске и команда и офис достойные.
Буквальное следование определенной методологии в управлении проектом — это отличный способ надеть розовые очки и снять с себя ответственность. С другой стороны, менеджеров, способных организовывать эффективные процессы вне этих рамок — крайне мало. Это более тонкий и умный подход и средний «восторженный хипстер» просто завалит проект. И далеко не каждый проект может вызвать достаточный уровень мотивации, подходящей для супер-гибкой методологии управления. А так — все верно конечно написано.
>Статистика показывает
Можно взглянуть на статистику?
Можно взглянуть на статистику?
Соглашаясь с автором в целом…
Боюсь спросить, а что автор понимает под репродуктивной деятельностью и почему ей нет места? (программисты тоже люди и ничто человеческое им не чуждо). 8-)
Боюсь спросить, а что автор понимает под репродуктивной деятельностью и почему ей нет места? (программисты тоже люди и ничто человеческое им не чуждо). 8-)
Человечеству известны два вида деятельности. Репродуктивная деятельность (труд) является слепком, копией с деятельности другого человека либо копией своей собственной деятельности, освоенной в предшествующем опыте. Такая деятельность, как, например, труд токаря в любом механическом цеху, или рутинная повседневная деятельность менеджера-управленца на уровне раз и навсегда усвоенных технологий. Продуктивная деятельность (творчество) — деятельность, направленная на получение объективно нового или субъективно нового (для данного работника) результата.\
Как-то, так.
Как-то, так.
программирование отличается от индустриального производства и в нем методы управления Макдонольдса не работаютДумаю, более адекватной, чем индустриальное производство, аналогией для программирования являются научно-исследовательские и опытно-конструкторские работы…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Методы Макдональдса не работают, что делать?