Взаимоотношения или споры в команде
179 views
Skip to first unread message
Евгений Сверчков
Jan 9, 2012, 2:23:22 AM1/9/12
to dotnetconf
Наверное каждый из нас встречался с такой ситуацией: Когда вам кажется
что ваш коллега не прав в принятии какого либо решения. Вы предлагаете
альтернативу, которая на ваш взгляд более верна. И тут начинается
спор. Как себя правильно себя вести в такой ситуации? Спорить до
последнего или позволить реализовать решение коллеги для того чтобы он
увидел что оно не верное. Иногда мы обращаемся к начальнику, и он
выбирает одно из двух решений. Но начальник не всегда на месте...
что ваш коллега не прав в принятии какого либо решения. Вы предлагаете
альтернативу, которая на ваш взгляд более верна. И тут начинается
спор. Как себя правильно себя вести в такой ситуации? Спорить до
последнего или позволить реализовать решение коллеги для того чтобы он
увидел что оно не верное. Иногда мы обращаемся к начальнику, и он
выбирает одно из двух решений. Но начальник не всегда на месте...
Alex
Jan 9, 2012, 2:59:55 AM1/9/12
to dotnetconf
В таких случаях всегда ищем 3-го человека, мнение которого весомо для
обоих участников спора. Это не обязательно начальник, а любой человек
из команды.
Если есть интерес и небольшой запас по времени и оба решения
равносильны, то можно набросать склеты для обоих вариантов (тесты или
минималистический функционал) что-бы стали видны подводные камушки, но
до этого доходит крайне редко :)
обоих участников спора. Это не обязательно начальник, а любой человек
из команды.
Если есть интерес и небольшой запас по времени и оба решения
равносильны, то можно набросать склеты для обоих вариантов (тесты или
минималистический функционал) что-бы стали видны подводные камушки, но
до этого доходит крайне редко :)
Алексей Волков
Jan 9, 2012, 4:02:45 AM1/9/12
to dotne...@googlegroups.com
Это же классно, когда есть разные мнения! :)
--
С уважением,
Алексей Волков
Без этого было бы скучно.
И все программы были бы одинаковыми.
И новые идеи давно бы закончились.
Я в таких ситуациях стараюсь отложить подальше предвзятость и нахожу способ выслушать и детализировать все мнения, не доходя до крайностей типа авторитарного принятия решения (позвать шефа, пускай рассудит) или траты времени на реализацию всех вариантов.
Авторитарное решение, конечно, тоже можно применять. Но такой вариант применяется либо при обсуждении вопроса, где этот авторитет действительно на порядок более опытен, чем спорящие, либо в запуганных командах (причем, если авторитет — Сталин, то это может происходить постоянно).
Вариант привлечения более опытного человека — это хороший признак осознания и принятия начинающим человеком своей некомпетентности и желания чему-то учиться. Лишь бы человек учился, а не пропускал все мимо ушей (эдакое смирение со своей некомпетентностью).
Вариант запуганной команды или тоталитарного контроля — это, имхо, нехороший признак :)
А тратить время, чтобы реализовать заранее плохой вариант — трата денег заказчика, снижение эффективности и конкурентоспособности своего же работодателя. Проще сразу начинать искать себе другую работу :)
Мы, например, при обсуждении UI рисуем все варианты эскизов, даже если есть предвзятое ощущение — и спокойно обсуждаем все варианты. Как следствие — даже самые бойкие и вспыльчивые люди успокаиваются и понимают, что их никто не критикует, а действительно слушают и все ищут самый рациональный путь. Как бонус, имея изначально 3 варианта, мы находим еще 2-3 новых варианта, о которых даже не подумали бы, если бы спорили (неосознанный мозговой штурм :) ).
С архитектурой системы поступаем так же.
Иногда, кстати, спорящие меняют свои мнения на противоположные — и продолжают обсуждать, заняв чужую позицию, но все еще не придя к общему мнению.
Потом откладываем все в сторону и обсуждаем основные критерии (тут можно иногда привлекать product-owner-а или любого другого, кто исполняет эту роль, для напоминания основных целей), проецируем это все на нарисованные эскизы, описания тест-кейсов, и т.п., а дальше уже редко бывают споры.
Такой сценарий легко переводит любой внезапный спор в мирное принятие правильного в данной ситуации решения.
И еще: правильное решение — не всегда ваше! :) И не всегда идеальное, что может раздражать еще больше, тем более, что в ходе обсуждения можно поменяться сторонами.
Иногда мы принимали решения, которые противоречат всем идеальным принципам. Потому что наша ситуация была не идеальной, а более реальными были совершенно другими критериями. Мы даже делали разработку «на выброс». Осознанно, взвесив все «за и против». Главное, не забывать это потом выбрасывать :)
9 января 2012 г. 13:23 пользователь Евгений Сверчков <u02...@gmail.com> написал:
С уважением,
Алексей Волков
Алексей Волков
Jan 9, 2012, 4:05:31 AM1/9/12
to dotne...@googlegroups.com
Кстати говоря, третий человек может быть действительно хорошим помощником для реализации описанного мною сценария — он менее зависим эмоционально, т.к. обсуждаются не его решения (любой творческий человек трепетно относится к своим идеям), и ему наплевать, чье решение будет принято :) Зато ему не наплевать на исход проекта.
9 января 2012 г. 13:59 пользователь Alex <mr.kar...@gmail.com> написал:
В таких случаях всегда ищем 3-го человека,
Alexander Byndyu
Jan 9, 2012, 4:29:01 AM1/9/12
to dotne...@googlegroups.com
Всем привет!
Я рассматривал похожую ситуацию Объяснить или давать разбираться?
Byndyu Alexander
--
Best regards,Byndyu Alexander
9 января 2012 г. 15:05 пользователь Алексей Волков <m...@aivolkov.ru> написал:
Alexander Byndyu
Jan 9, 2012, 4:46:22 AM1/9/12
to dotne...@googlegroups.com
Еще вспомнил реальную ситуацию, которая произошла у нас в компании пару лет назад.
Мы начинали новый этап проекта, где должна была появится сложная математика и работа с большими объемами данных для вычислений. В БД к тому времени был накоплен довольно приличный объем - 80 ГБ. Предполагалось, что объем данных будет быстро расти и дальше.
Предложений по реализации было два: 1) сделать реализацию в БД и работать с данными с помощью реляционных преобразований 2) сделать конвейер с пошаговой обработкой (например, на NServiceBus) на .NET
Спорили об этих двух подходах пару часов всей командой. Как удалось выйти из ситуации?
Мы разделились на две команды, те кто за БД и те кто за NServiceBus. Каждая была уверенна в своем решении и должна была сделать прототип, чтобы убедиться, что их подход сработает.
В итоге, подход с БД сдался уже к концу дня :)
Как результат, систему на NServiceBus реализовали, до сих пор работает без перебоев.
9 января 2012 г. 15:29 пользователь Alexander Byndyu <alexande...@gmail.com> написал:
Алексей Волков
Jan 9, 2012, 4:57:39 AM1/9/12
to dotne...@googlegroups.com
И почему он сдался?
Не смогли реализовать?
Вдруг смогли найти причины, почему это плохо?
Ни разу не поддерживаю подход с БД, но мне интересно, почему вы не смогли найти взаимопонимания еще до создания прототипа — что-то изменилось с началом работы над прототипом?
Мы разделились на две команды, те кто за БД и те кто за NServiceBus. Каждая была уверенна в своем решении и должна была сделать прототип, чтобы убедиться, что их подход сработает.В итоге, подход с БД сдался уже к концу дня :)
Alexander Byndyu
Jan 9, 2012, 5:01:46 AM1/9/12
to dotne...@googlegroups.com
И почему он сдался?
Не смогли реализовать?
Вдруг смогли найти причины, почему это плохо?
Да, не увидели какие запросы придется присать даже для простых операций. Когда ты себе это представляешь, то кажется, что будет довольно просто.
...почему вы не смогли найти взаимопонимания еще до создания прототипа — что-то изменилось с началом работы над прототипом?
Когда пишешь на SQL запрос с кучей подзапросов, то начинаешь задумываться о целесообразности этого подхода.
Про взаимопонимание - до этого был проект, где активно использовались хранимые процедуры, видимо поэтому было ощущение, что и в этот раз получится применить SQL.
Сами запросы сейчас восстановить уже не получится, но могу сказать точно, что на .NET все получилось очень красиво.
9 января 2012 г. 15:57 пользователь Алексей Волков <m...@aivolkov.ru> написал:
Alexander Byndyu
Jan 9, 2012, 5:13:11 AM1/9/12
to dotne...@googlegroups.com
Кстати, вот еще один случай, который был совсем недавно, буквально месяц назад.
Я выступал в качестве консультанта в компании (название не скажу), где были проблемы со скоростью работы и качеством кода. Кроме того, их система должна через год-два стать продуктом, а текущая архитектура не позволяет сделать ее "коробкой".
Для общения собралась вся команда, руководители, менеджеры, даже приехали их ведущие специалисты из других городов.
В первый день я показывал где проблемы в коде, почему это проблемы и как можно решить эти проблемы.
Во второй день мы 3 часа обсуждали 1) оставлять бизнес-логику в БД 2) дублировать логику в БД и .NET или 3) переносить всё в .NET. Были и другие темы, но эта вызвала больше всего споров.
Чего удалось добиться за 3 часа:
- Все члены команды впервые открыто обсудили проблемы в проекте вместе с руководством. Совместно вскрыли много серьезных проблем, наметили решения.
- Выделили группу из 2х программистов, которые пообещали до конца января сделать прототип системы целиком на .NET, а БД оставить в качестве СУБД не более.
Из этого всего я могу сказать, что споры это хорошо, в них иногда рождается истина.
Евгений, аргументируйте свою позицию, показывайте прототипы, донесите проблемы до руководства, ну и отпишитесь о результатах.
9 января 2012 г. 16:01 пользователь Alexander Byndyu <alexande...@gmail.com> написал:
Евгений Сверчков
Jan 9, 2012, 5:14:21 AM1/9/12
to dotne...@googlegroups.com
Теперь будем искать подтверждения третей стороны. Но иногда я делаю прототипы, для того чтобы доказать сою правоту.
И еще я не утверждаю что мои решения единственно верные. Но альтернативы всегда нужны.
Алексей Волков
Jan 9, 2012, 5:19:40 AM1/9/12
to dotne...@googlegroups.com
Значит в следующий раз вместо прототипов можно сразу просить начать записывать SQL-запросы. Можно даже на бумаге. И от этого плясать в дальнейших обсуждениях. Правильно? :)
9 января 2012 г. 16:01 пользователь Alexander Byndyu <alexande...@gmail.com> написал:
...почему вы не смогли найти взаимопонимания еще до создания прототипа — что-то изменилось с началом работы над прототипом?Когда пишешь на SQL запрос с кучей подзапросов, то начинаешь задумываться о целесообразности этого подхода.
Евгений Сверчков
Jan 9, 2012, 5:25:01 AM1/9/12
to dotne...@googlegroups.com
Как правило детали реализации мы не обсуждаем... Об этом можно только спрашивать если не знаешь чего то...
9 января 2012 г. 16:19 пользователь Алексей Волков <m...@aivolkov.ru> написал:
Alexander Byndyu
Jan 9, 2012, 5:25:36 AM1/9/12
to dotne...@googlegroups.com
Можно даже на бумаге
Тогда точно всё желание отпадет писать бизнес-логику в БД :)
9 января 2012 г. 16:19 пользователь Алексей Волков <m...@aivolkov.ru> написал:
Murad Muradov
Jan 9, 2012, 5:27:17 AM1/9/12
to dotne...@googlegroups.com
В спорах не всегда рождается истина.
Есть много факторов, которые могут не позволить вам ее найти:
1. Цели участников в споре
2. Уровень владения участниками риторикой
Есть много факторов, которые могут не позволить вам ее найти:
1. Цели участников в споре
2. Уровень владения участниками риторикой
И не факт, что какая-то третья сторона выберет лучший вариант. Все
бывает очень субъективно, к сожалению.
В качестве примера можно вспомнить спор Выщепана, Бындю и других
http://blog.byndyu.ru/2011/12/domain-driven-design.html
Спор так ничем и не закончился
09.01.12, Евгений Сверчков<u02...@gmail.com> написал(а):
--
С уважением
Мурадов Мурад
Alex
Jan 9, 2012, 5:28:46 AM1/9/12
to dotnetconf
Не соглашусь. Принимать концептуальные решение сходу не есть хорошо.
Ведь когда идет процесс обсуждения можно в горячке и написать пару
тройку запросов :)
Разойтись, сходить на перекур, в это время в мозгу пройдет инкубация
всех изложенных идей и сформируются некие конкретные решения. Потом
попробовать применить, и только потом делать финальные выводы.
Ведь когда идет процесс обсуждения можно в горячке и написать пару
тройку запросов :)
Разойтись, сходить на перекур, в это время в мозгу пройдет инкубация
всех изложенных идей и сформируются некие конкретные решения. Потом
попробовать применить, и только потом делать финальные выводы.
On 9 янв, 13:19, Алексей Волков <m...@aivolkov.ru> wrote:
> Значит в следующий раз вместо прототипов можно сразу просить начать
> записывать SQL-запросы. Можно даже на бумаге. И от этого плясать в
> дальнейших обсуждениях. Правильно? :)
>
> 9 января 2012 г. 16:01 пользователь Alexander Byndyu <
> alexander.byn...@gmail.com> написал:
>
>
>
> >> ...почему вы не смогли найти взаимопонимания еще до создания прототипа --
Алексей Волков
Jan 9, 2012, 5:34:44 AM1/9/12
to dotne...@googlegroups.com
Согласен про перекур. Тут в команде нужно выработать комфортный стиль обсуждения — кому и когда нужна пауза для обдумывания. Иногда даже несколько раз :)
И написание трех-этажного SQL-запроса с использованием курсоров вполне может быть тем самым перекуром :)
В описанной мною ситуации у нас было два перекура. И наброски на бумаге помогали легко вернуться в контекст обсуждения.
9 января 2012 г. 16:28 пользователь Alex <mr.kar...@gmail.com> написал:
Alexander I. Zaytsev
Jan 9, 2012, 5:45:36 AM1/9/12
to dotne...@googlegroups.com
У нас в команде все большие решения выносятся на обсуждение, вне зависимости от того, есть альтернативное мнение или нет. В обсуждении обычно принимают участие все заинтересованные лица.
9 января 2012 г. 13:23 пользователь Евгений Сверчков <u02...@gmail.com> написал:
Наверное каждый из нас встречался с такой ситуацией: Когда вам кажется
Егор Кожевников
Jan 9, 2012, 6:34:13 AM1/9/12
to dotne...@googlegroups.com
Привет, Евгений!
--
Егор
Как себя правильно себя вести в такой ситуации?
Я прочитал все письма в ответ на это инициирующее сообщение.
Возможно, ключом к ответу является обсуждение только практических ситуаций, когда ты пишешь сюда пусть ту же самую проблему, но когда она конкретна. Тогда и советы будут конкретные, а иначе и невозможно, потому что в абстрактной ситуации слишком много переменных, а в конкретной - конкретный начальник, конкретные ты и твои коллеги, конкретная проблема. Можно провести границы.
А в абстрактной ситуации - можно бесконечно теоретизировать о сферическом коне, потому что каждый волен видеть его по-своему в силу его природы ).
Обсуждение конкретных проблем, пусть 100 похожих подряд, в отличие от задавания теоретически абстрактных вопросов, является...
Скажу так - это 2 совершенно разные практики. Точнее, одна практика, а другая - теория. В буддизме, например, практикующих называют буддистами, а изучающих - буддологами. Такая же грань между психиатрами (психотерапевтами, консультантами, коучами - так или иначе, практиками) и психоЛОГами, которые изучают историю, культуру, этапы и разные возможности на каждом из этапов.
Насколько мне кажется из сути твоего письма, ты нацелен именно на получение конкретного практического навыка.
В этой связи (если утверждение выше является правдивым) предлагаю тебе задавать сюда конкретные вопросы по конкретно возникающим ситуациям. Со временем опыт проведения границ, в качестве сути ответа на твой вопрос, приложится.
Егор!
//////////
9 января 2012 г. 12:23 пользователь Евгений Сверчков <u02...@gmail.com> написал:
Егор
///////////
Евгений Сверчков
Jan 9, 2012, 9:08:25 AM1/9/12
to dotnetconf
Я вас понял, Егор.
Я хотел узнать у коллег их опыт в таких ситуациях. У меня споры
происходят несколько раз в день.Я и мой коллега вместе работаем вдвоем
над одним проектом. Он меня опытнее, а только что институт закончил.
Но суть в том, что он предлагает откровенно несуразные решения, не
зная многих возможностей .net, так как программировал на Delphi.
Например как можно писать что то в базу в обход доменной модели? Или
как можно разные сущности помещать в одну таблицу только потому что у
них поля данных одинаковые? Или как можно выбрать вместо строгой
типизированных объектов массив из строк, для того чтобы потом их
отобразить на клиенте. Или как можно писать код бизнес логики на T-
SQL? Или как можно заявить что сложно разработать библиотеку классов
потому-что ее нельзя отладить? Скоро в центр тяжести писать буду :)))
Я пытаюсь ему рассказать про TDD, и про DDD, ссылки ему кидаю на
статьи. А у него наверное времени нет все прочитать, или желания.
Наверное у меня авторитета маловато пока.
Но недавно он начал со мной советоваться. Наверное спорить все таки
надо, пусть даже если со старшими...
Murad Muradov
Jan 9, 2012, 9:21:09 AM1/9/12
to dotne...@googlegroups.com
У меня был подобный опыт.
Спорить нужно! И статьи ему показывай. Если ты прав, то он скоро
сдастся и будет спрашивать не только советов, но и сами решения.
Спорить нужно! И статьи ему показывай. Если ты прав, то он скоро
сдастся и будет спрашивать не только советов, но и сами решения.
09.01.12, Евгений Сверчков<u02...@gmail.com> написал(а):
Alexander I. Zaytsev
Jan 9, 2012, 10:04:14 AM1/9/12
to dotne...@googlegroups.com
Привет.
9 января 2012 г. 20:08 пользователь Евгений Сверчков <u02...@gmail.com> написал:
Я вас понял, Егор.
Я хотел узнать у коллег их опыт в таких ситуациях. У меня споры
происходят несколько раз в день.Я и мой коллега вместе работаем вдвоем
над одним проектом. Он меня опытнее, а только что институт закончил.
Но суть в том, что он предлагает откровенно несуразные решения, не
зная многих возможностей .net, так как программировал на Delphi.
Например как можно писать что то в базу в обход доменной модели?
Запросто.
Или как можно разные сущности помещать в одну таблицу только потому что у
них поля данных одинаковые?
Почему нет?
Или как можно выбрать вместо строгой типизированных объектов массив из строк, для того чтобы потом их
отобразить на клиенте.
А так разве нельзя?
Или как можно писать код бизнес логики на T-SQL?
Ну как-то же пишут.
Или как можно заявить что сложно разработать библиотеку классов потому-что ее нельзя отладить?
Вот это конечно чушь;)
Смысл в том, что универсального решения нет. Нет серебряной пули. Есть проекты, где проще и целесообразнее написать хранимую процедуру. Есть задачи, которые проще решить на голом С или ASM. Использовать всегда и везде один и тот же подход - это смерть. Нужно под каждую задачу выбирать оптимальное решение.
Конечно плохо, когда какое-то решение выбирается от незнания возможности применить другое решение.
Скоро в центр тяжести писать буду :)))
Я пытаюсь ему рассказать про TDD, и про DDD, ссылки ему кидаю на
статьи. А у него наверное времени нет все прочитать, или желания.
А ему это надо? Лучше всего показывать на своём примере, а не какие-то абстрактные ссылки на абстрактные блоги с учебными избитыми примерами по TDD/DDD/etc.
Для открытия глаз другому человеку придумали очень хорошую технику - парное программирование. Просто сядьте за один компьютер и решайте одну задачу в день (неделю, месяц - на ваш выбор) строго в паре. А с помощью техники "а давай попробуем так" оптимальные решения находятся легко и непринужденно.
Алексей Волков
Jan 9, 2012, 10:12:46 AM1/9/12
to dotne...@googlegroups.com
Судя по описанию ситуации ты его очень сильно напугал навалив на него кучу новой информации.
На такое может быть только одна реакция — закрыться и сказать «сам дурак».
Люди не любят отказываться от всего своего опыта и мгновенно становиться другими людьми, тем более по чьей-то указке. Только постепенно — постепенное и совместное развитие.
Говорят, Yahoo! тоже отказались от идеи Пейджа и Брина, сказав, что это бесперспективная идея.
9 января 2012 г. 20:08 пользователь Евгений Сверчков <u02...@gmail.com> написал:
Я пытаюсь ему рассказать про TDD, и про DDD, ссылки ему кидаю на
статьи. А у него наверное времени нет все прочитать, или желания.
Евгений Сверчков
Jan 9, 2012, 10:19:04 AM1/9/12
to dotnetconf
Да вы правы...
Но я боюсь что менеджера скажут что мы фигней маемся. И в два раза
меньше работы делаем за одним экраном.
Но я боюсь что менеджера скажут что мы фигней маемся. И в два раза
меньше работы делаем за одним экраном.
Alex
Jan 9, 2012, 10:22:57 AM1/9/12
to dotnetconf
Внедрять Agile в компании методом "cнизу" весьма неблагодарное
занятие, шансов на успех достаточно мало.
занятие, шансов на успех достаточно мало.
Alexander Milikovski
Jan 9, 2012, 10:40:22 AM1/9/12
to dotnetconf
Истина так. Особенно если компания здоровая и у неё корпоративные
правила.
правила.
Alexander I. Zaytsev
Jan 9, 2012, 10:43:17 AM1/9/12
to dotne...@googlegroups.com
9 января 2012 г. 21:40 пользователь Alexander Milikovski <ale...@gmail.com> написал:
Истина так. Особенно если компания здоровая и у неё корпоративные
правила.
Совсем не так.
On Jan 9, 5:22 pm, Alex <mr.karaba...@gmail.com> wrote:
> Внедрять Agile в компании методом "cнизу" весьма неблагодарное
> занятие, шансов на успех достаточно мало.
Враки. Вы пробовали?
>
> On 9 янв, 18:19, Евгений Сверчков <u02...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Да вы правы...
> > Но я боюсь что менеджера скажут что мы фигней маемся. И в два раза
> > меньше работы делаем за одним экраном.
Прикрытием для начальства может служить "отмаз": "сложную задачу разбираем, одному не справится".
Alex
Jan 9, 2012, 10:53:55 AM1/9/12
to dotnetconf
Очень даже так. Пробовал, компания 100+ человек и 10+ активных
проектов уровня предприятия.
На все попытки - ответ один, это время, а время есть? А посмотри в баг-
трекинг + планы. Так что да, это круто, но как-нить потом.
Максимум до чего довелось все старания, так это что группа развития
этом заинтересовалась, но это опять же будет внедрено в новой жизни,
радоваться которой будут новые, более совершенные существа.
Но опять же процесс пойдет только в случае если в этом будет
заинтересована голова, а не ноги.
Да и опять же, люди работают, все устраивает. В 9 пришел, в 6 ушел. Ни
в одном кабинете нет даже намека на доску. И тут приходит весь такой
из себя агиле и начинает рассказывать как это круто, только вот блин
никому это нафиг и не надо ибо уже 17.55 и время мыть кружку...
Про вместе разбираем - аналогичная ситуация, есть места где
практикуется самокопание в системе и индивидуализм каждого, что в
переводе - не отвлекай у него своей работы валом.
проектов уровня предприятия.
На все попытки - ответ один, это время, а время есть? А посмотри в баг-
трекинг + планы. Так что да, это круто, но как-нить потом.
Максимум до чего довелось все старания, так это что группа развития
этом заинтересовалась, но это опять же будет внедрено в новой жизни,
радоваться которой будут новые, более совершенные существа.
Но опять же процесс пойдет только в случае если в этом будет
заинтересована голова, а не ноги.
Да и опять же, люди работают, все устраивает. В 9 пришел, в 6 ушел. Ни
в одном кабинете нет даже намека на доску. И тут приходит весь такой
из себя агиле и начинает рассказывать как это круто, только вот блин
никому это нафиг и не надо ибо уже 17.55 и время мыть кружку...
Про вместе разбираем - аналогичная ситуация, есть места где
практикуется самокопание в системе и индивидуализм каждого, что в
переводе - не отвлекай у него своей работы валом.
p.s. это все из личного. проработал в таком месте что-то около 3-х
месяцев :)
On 9 янв, 18:43, "Alexander I. Zaytsev" <hazzik+nos...@gmail.com>
wrote:
> 9 января 2012 г. 21:40 пользователь Alexander Milikovski
> <alex...@gmail.com>написал:
Alexander Milikovski
Jan 9, 2012, 2:43:17 PM1/9/12
to dotnetconf
Серьёзно? И в скольких крупных команиях вы работали, что бы делать
такие заявления?
такие заявления?
Опять таки согласен с Alex-ом. И у него пример про компанию 100+
человек. А что же говорить про 5000+ человек? Конечно не все эти люди
программисты, но это показывает уровень на котором она работает. Да им
чаще проще и быстрее, как часть работы над проектами, купить и
внедрить системы у которых лицензии с поддержкой стоят сотню тысяч
долларов на год, чем внедрять какой то там agile. Это не значит что
они этого делать не хотят принципиально или никогда не сделают. Просто
для этого решение обязано придти сверху. Я говорю про общую политику
ведения проектов в компании, а не про отдельные группы, которые
используют новые подходы в рамках своего бюджета и времени.
On Jan 9, 5:43 pm, "Alexander I. Zaytsev" <hazzik+nos...@gmail.com>
wrote:
> 9 января 2012 г. 21:40 пользователь Alexander Milikovski
> <alex...@gmail.com>написал:
Alexander I. Zaytsev
Jan 9, 2012, 3:17:28 PM1/9/12
to dotne...@googlegroups.com
10 января 2012 г. 1:43 пользователь Alexander Milikovski <ale...@gmail.com> написал:
Серьёзно? И в скольких крупных команиях вы работали, что бы делать
такие заявления?
Давайте не будем мериться пиписьками, и останемся при своём.
Опять таки согласен с Alex-ом. И у него пример про компанию 100+
человек. А что же говорить про 5000+ человек? Конечно не все эти люди
программисты, но это показывает уровень на котором она работает. Да им
чаще проще и быстрее, как часть работы над проектами, купить и
внедрить системы у которых лицензии с поддержкой стоят сотню тысяч
долларов на год, чем внедрять какой то там agile. Это не значит что
они этого делать не хотят принципиально или никогда не сделают. Просто
для этого решение обязано придти сверху. Я говорю про общую политику
ведения проектов в компании, а не про отдельные группы, которые
используют новые подходы в рамках своего бюджета и времени.
Смысл в том, что если люди внизу хотят agile, то они его внедрят и руководство об этом даже и не узнает.
А такие, как вы, находящиеся в позиции жертвы, будут все силы тратить на то, чтобы доказать окружающим, что вам "сверху" не дают внедрять agile.