Поставил, но еще не тестил досколнально на проекте, самые гнусные баги как правило выявляются потом.Вообще очень рад MonoDroid потому, что разработка на C# обходиться меньшими нервами.
Есть баги с GC вылетает с out of memory иногда, нужно самому писать GC.Collect()
Я еще с 5 превью в бете, в рассылках просто ужас описывают, все время что-то вылетает.Чего стоила бага при отладке больших проектов в 13 превью, сам специально веду 1 проект на MonoDroid для того, чтобы быть в курсе развития, но им еще далеко до нормального состояния, да и процесс идет медленно, приложения то уже нужны заказчикам. Но все равно, приятно, что хоть кто-то работает над этой областью.
фишка в том что понятие счастья очень сильно колеблеться в зависимости от социокультурных особенностей…
на востоке это будет впасть в нирвану, а на западе заработать миллион…
open source что-то хорошее написали, но пишется это долго и не целенаправленно, если говорить про дев-ов, которые энтузиасты.Если говорить, про вендоров типа Red Hat, Suse то у них команды программистов как в обыкновенных компаниях.Есть три фактора: быстро, качественно, недорого.Выберете любые 2 ))
Сколько лет работаю, ни разу не видел чтобы кто-то когда, не может разобраться в задачах лез в соц.сети.Программисты по своей природе любознательный народ, возможно жизнь меня пощадила, но все с кем я работал или общался было очень хорошо прокачаны в области разработки как таковой.
Ну это заодно к цитате Дамиена, чтобы отсеять плохих прогов, достаточно нескольких недель работы в одном помещении.Однако я не утверждаю, что моя точка истина в последней инстанции, но коммуникация максимально эффективный инструмент в социальной среде, пускай даже программистов.
Хотя и у меня были фейлы, когда собиралась команда интровертов в комнате, которых невозможно было ни воодушевить не взбодрить… они больше получали кайф просто от деятельности.Поэтому эффективней всего собирать разношерстные команды
Я не буду спорить, но опять же вычитал у Коберна, вольный перевод «плевать на методологии, если у вас что-то работает используйте это!»
Для меня лично, именно сбор всех в одном месте и создание духа работа является волшебной палочкой, все мы эмоциональны, и если народ не накачивать каждый день, то моральный дух может упасть, а если команда где-то далеко то даже видеоконференции не спасают «они там, а вы здесь».
Поэтому ко всему ПО для Agile отношусь как средству накопления данных для статистики…
Алистер Коберн хорошо описывает такие вещи, коммуникация самый главный залог успеха команды, самая эффективная это личная, потом телефон, потом интернет.Имхо, адаптация «под наши реалии» как сейчас любят говорить, просто искажает суть методологий.Если вы хотите делать качественный софт делайте его в одном месте, желательно в одной комнате… проверено на лично опыте со всех сторон, как провальной так и с успешной…
Автономная команда, это как команда в команде, своего рода матрешка… Если вас смущает эффективность работы, то она была на хорошем уровне, как сейчас не знаю.Просто вопрос не инструментов, а людей встает острее даже в распределенной команде…
на самом деле, работал в фирме до последнего времени, в которой использовали Devprom, и все-таки практика показывает, что лучше не вести общий для распределенных команд беклог, а выделять под распределенную команду задачи, а они их уже там сами организуют…
я говорил о конфликте интересов, что не столь важно.Вы так и не ответили, что подразумеваете под словом «левый».
Насчет проверки профпригодности командой скажу, что с тех пор это стала частая практика.Особенно когда серьезно настроили Agile в команде.Проявляется много интересных вещей, ведь и TL ошибается...)
Реальный пример, приводит project manager (PM) молодого бойца, говорит он такой толковый все знает, все хочет новое постигать-берем!..
Есть team leader(TL), который общается с этим парнем и понимает, что его уровень очень далек о того что описал PM и на данный момент такой сотрудник не нужен.Возникает вопрос, для PM это свой человек, для TL он «левый». Возможно и обратная ситуация.Как в таких случаях предложите поступать?
А завязка на чем? У PM язык подвязан и он тянется к таким же, TL предпочитает хороших технарей.В таких случая идеальная команда будет, это команда разнообразных людей, потому что, тот кто сегодня левый завтра будет очень своим. Гласс кстати в своих трудах хорошо описывает эти сутации, да и Тони ДеМарко в Peopleware, так что не думаю что пост откроет кому-то глаза…
P.S: Мы вышли из этой ситуации просто, вся команда по очереди проинтервьюировала парня и вынесла вердикт, но не всегда так бывает.
даже java программистам она особо интересно не была, ибо простыни кода просто.А вот первые 14 глав просто источник знаний для программиста любого уровня.Кто не найдет для себя что-то новое, то хотя б освежит в памяти знания.
Есть баги с GC вылетает с out of memory иногда, нужно самому писать GC.Collect()
на востоке это будет впасть в нирвану, а на западе заработать миллион…
Сколько лет работаю, ни разу не видел чтобы кто-то когда, не может разобраться в задачах лез в соц.сети.Программисты по своей природе любознательный народ, возможно жизнь меня пощадила, но все с кем я работал или общался было очень хорошо прокачаны в области разработки как таковой.
Ну это заодно к цитате Дамиена, чтобы отсеять плохих прогов, достаточно нескольких недель работы в одном помещении.Однако я не утверждаю, что моя точка истина в последней инстанции, но коммуникация максимально эффективный инструмент в социальной среде, пускай даже программистов.
Хотя и у меня были фейлы, когда собиралась команда интровертов в комнате, которых невозможно было ни воодушевить не взбодрить… они больше получали кайф просто от деятельности.Поэтому эффективней всего собирать разношерстные команды
Для меня лично, именно сбор всех в одном месте и создание духа работа является волшебной палочкой, все мы эмоциональны, и если народ не накачивать каждый день, то моральный дух может упасть, а если команда где-то далеко то даже видеоконференции не спасают «они там, а вы здесь».
Поэтому ко всему ПО для Agile отношусь как средству накопления данных для статистики…
на самом деле, работал в фирме до последнего времени, в которой использовали Devprom, и все-таки практика показывает, что лучше не вести общий для распределенных команд беклог, а выделять под распределенную команду задачи, а они их уже там сами организуют…
Насчет проверки профпригодности командой скажу, что с тех пор это стала частая практика.Особенно когда серьезно настроили Agile в команде.Проявляется много интересных вещей, ведь и TL ошибается...)
Реальный пример, приводит project manager (PM) молодого бойца, говорит он такой толковый все знает, все хочет новое постигать-берем!..
Есть team leader(TL), который общается с этим парнем и понимает, что его уровень очень далек о того что описал PM и на данный момент такой сотрудник не нужен.Возникает вопрос, для PM это свой человек, для TL он «левый». Возможно и обратная ситуация.Как в таких случаях предложите поступать?
А завязка на чем? У PM язык подвязан и он тянется к таким же, TL предпочитает хороших технарей.В таких случая идеальная команда будет, это команда разнообразных людей, потому что, тот кто сегодня левый завтра будет очень своим. Гласс кстати в своих трудах хорошо описывает эти сутации, да и Тони ДеМарко в Peopleware, так что не думаю что пост откроет кому-то глаза…
P.S: Мы вышли из этой ситуации просто, вся команда по очереди проинтервьюировала парня и вынесла вердикт, но не всегда так бывает.