Регулярные дейлики с командой с демонстрацией бэклога задач
Дейлики предназначены не для демонстрации бэклога, а идентификация проблем в проекте (утверждение Брукса про "почему проекты отстают на год") как можно раньше и подтверждение контракта. Таким образом - цели и проблемы.
Актуализация статусов в процессе дейли-митинга
Это также не задача daily. Задача меняет свой статус согласно жизненному циклу. Менять статус на daily -так себе идея, зачем тратить время общей встречи на это?
Наличие DoD/DoR в задачах
В задачах? В задачах может быть только AC. DoD/DoR определяют как минимум на процесс или на межпроцессное взаимодействие. Это намного шире и обще. Логика здесь какая? Каждая задача - разная. Круг работ - также разный и определяет соотвественно критерий приемки. А вот DoD - это комлекс общих процедур: например, какие-то нефункциональные требования или наличие сопроводительной документации и технической ревизии от двух людей итд для задач технического долга или дефектов.
Не, я все понимаю, но как теперь быть игрокам, которым в 3 части нужен был только Гвинт и Пассифлора? Если теперь Цирилла - ГГ как теперь по барделям ходить и морды бить в турнирах??? Верните Герыча!
К счастью, аджайл не ограничивается скрамом. Даже наоборот, скрам несмотря на все старания не смог убить хорошую идею в основе гибкого подхода.
Почитал ответы, увы до большинства так и не дошло, что автор сказал. Кстати, чего-то вспомнилось, что когда время позволяло посещать ПМ-конфы замечал, что большинство народа там просто банально безграмотные, то есть они знают что такое "скеджуал", "грумминг" и "рефайминг", но банально никто не понимал, когда спрашивали, например про "цикломатическую сложность задачи" или "факторный анализ".
Может я излишне строг, но большинство для которых применение скрама - это всего лишь "потому что все так делают, это ж модно", - то это секта.
Запросы не будут распределены равномерно (день/ночь, праздники, время года), будут считаться нормальными пики для распределения, это где-то 14.6-26.58 запросов в секунду.
Ну с 7 зоны если перется, то и ойстер будет дороже. В целом данные по ЗП в Лондоне ваши подтверждаю (как в других городах UK не знаю). Могу только дополнить, что многие первое время 50К получают и не жужжат — и увы это чистое правда. Многие спрашивают а как жить? Да вот так и живут, разные обстоятельства — кто-то в теске питается, или ланч с собой, или с мамкой живут на их квартире — пока доход не позволяет.
Есть еще «компьюторщик» — это типа «тожепрограммиста», обычно частое слово и используется в лексиконе «управленческой элиты». А начет терминов, я бы не заморачивался так, ведь ответы на поверхности и без сокрального смысла — «инженер», значит есть высшее техническое образование, с «кодером» тоже все понятно — это «макака» которую если обучить Visual Basic можно отправить на Марс (старая шутка про Майкрософт), девелопер — это разработчик который работает с иностранным клиентом, а разрабочик — его калька с английского, относительно новое слово, в 90-х я не припомню чтоб программистов называли разрабочиками. Впервые я услышал в 2000х, даже не помню кто его изобрел ) ПрограммистЪ — это самое старое из всех перечисленных слов (исключая инженера), инженер-программист — тоже что и инженер с дипломов в CS или CE
Oracle в 90-х начало 2000-х это тихий ад для разработчика. Код был не просто ад, а адищще, принятый TDD был скорее закономерностью, ибо ранние версии Oracle были написаны на Pascal (кстати, этим объяснялась их любовь к «Борману/Borland»). Кроме того код надо было портировать на C — ибо без C не было бы связки с тогда еще новым языком Java (на это решение повлияло кстати тот факт, что Ларри как раз в то время возглавлял и Apple, а когда началось портирование на C++, с тогда еще только появившимся STL — начался трешаковый ад — типа первых попыток реализовать OCCI дав волну различных велосипедов лишь бы уменьшить геморрой от ObjC и OCI).
Многие тут спорят TDD в Оракле или не TDD )) Народ, могу успокоить в версии Oracle многие вещи имеют «иное» понимание — от их реализации STL (особенно под UltraSparc лол) до их понимания паттернов проектирования в те года (особенно запомнилась с тех времен реализация PImpl).
Мое мнение Oracle существует только потому, что Ларри подмазал везде и у ЦРУ и IBM, и Apple, и Sun (когда он еще существовал) он с кем надо давно договорился — просто посмотрите его биографию и станет понятно — почему этот монстр до сих продается (только не надо мне про масштабируемость решений от Оракл) И да, легко верю автору, что хуже кода базы Оракл нет ничего в мире))
Можно делать снимок root view controller/root activity принадлежащее им, либо дочернее от вышеназванного. Объект push notification/alert таковым не является.
Нет, «оно» делает снимок root view controller/root activity принадлежащее им, либо дочернее от вышеназванного. Объект push notification/alert таковым не является
Актуализирую информацию и выскажу мнение на 06.2018. На основе собственного опыта и изучения рынка решений проблем распространения:
1. TestFlight + Google Play — для обоих решений требуется… никаких усилий, от слова совсем. Оба решения есть часть консоли разработчика Apple и Google. Уже будут и отчеты о крашах и распространение без «серых» сертификатов, вообще все «легально» и в «белую». Недостаток лишь один — недоступно распространение на Amazon и Samsung маркетплейсы (короче только Google).
2. HockeyApp — в принципе понравился тем что довольно легко интегрируем и даже без CocoaPods (я с большой настороженностью отношусь к неродным по отношению к продукту непрозрачным заскриптованным активностям в предкомпайл стадии).
Fabric в принципе это из мира единорогов ибо натягивается на любой нетривиальный сценарий сборки (иными словами любой что за пределами понимания разработчиков Fabric — т.е. все то, что не является ни xCode ни Android Studio/Eclipse) Так вот какие-то сценарии через CI с разными фокус группами распространения — такой геморрой. И если даже получится, то автоматизировать процесс «вычленения» этого «добра от Fabric» такой же ад. Вот эти «подсказки» с интеграцией и визарды мне напоминают «скрепыша» в 90-х годах MS Office — пользы ноль.
PS. Перечитал — как-то получается что я здесь выступаю хейтером Fabric. Но я, честно, не хотел этого, просто резануло глаз, что такой высокий балл в статье отдали именно Fabric — я не понимаю за что, стоимость интеграции у него гораздо выше.
Послушал минут 30, хех что тут сказать… Ах да, такое ощущение что Microsoft это фабрика всякого дерьма, которым оно заражает весь мир, а потом его (дерьмо) бросает и создает новое (аджаил блин), а куча обманутых пользователей потом по конфам Microsoft ходят и задаются вопросами по старому дерьму, а Microsoft уже(!) рассказывает про новое и ничего не слышала про старое.
Мы о разных вещах говорим, вы про типичный российский крысятник (до 100 человек), я же про либо региональный филиал крупной российской корпорации, либо про дочернюю компанию иностранной компании в РФ (авто/кондитерка/нефть). В типичном российском крысятнике делать нечего даже на этапе собеседования(но это я отвлекся), и я почему-то думаю, что «сергей» ну никак не мог решить со своей ипотекой, видя ставку крысятника, во главе крысятника естественно король крыс из «Щелкунчика».
Пусть эта фраза не вводит вас в заблуждение, в таких компаниях квартальная премия платится за выполнение ранее поставленного плана, а сводят они(по сути заинтересованные люди) баланс настолько красиво, что как правило, этот самый план всегда выходит выполнен (сводится в ноль, кому как привычнее слышать).
Эх, жаль, название конторы-то не сказали, а то по некоторым признакам там еще есть и производственные отделы, и даже конструкторский отдел ) Это ведь намного-намного увлекательнее могло быть начало, типа «в первый день сотворения Компании был поставлен турникет, и первые люди сразу начали ходить через него, а потом вырасли стены конструкторского отдела...»
Я считаю, что не было в тексте ни одного момента где бы Сергей получил бы повышение. И не важно, какие там технологии и не важно какие там будут условные «сергеи» с горящими глазами или нет, испорченные они или нет. Один результат — никаких повышений никаким сергеям в таких компаниях не видать. Какие P&L? О чем вы говорите, история ведь повторила итерацию зимой, а что у нас зимой? — Годовой отчет с закрытием финансового года.
Могу предположить что запарка с закрытием периода, со сведением несводимого и проводками у финансового отдела (бухгалтеров) была из-за того, что кто-то в компании мутит с товарными позициями по черному. И уверен что делается это группой лиц, и даже почему-то не буду удивлен, что вот эта вот дама, условная жанна с крамольной «задачей реального бизнеса», всего лишь ширма, за которой таится яма безисходности в которой тонет и засасывает. Что сергей хотел оптимизировать? Колян-то небось на этот момент уже был в курсе про мифические остатки на складе и левые проводки с логистикой или сетями?
Как мы знаем прописную истину, сотрудники уходят не из компании, сотрудники всегда уходят от других людей. Вот здесь кроется все самое-самое главное. От других людей уходят. Вот в этом направлении я бы и копал — начиная с завхоза, старшего менеджера логистики и «продажников». Скорее всего именно от этого списка убегали эти николаи и сергеи, а не от условных битриксов или «ужасного» кода.
Сергей мог бы получить повышение (стоп, а что такое повышение вот этого Сергея? На таких компаниях это всегда — слив условной Жанны.) если бы он тихо начал бы исследовать предметно источники всей этот текучки, и главное(!), а это всегда ключ к повышению (тьфу) решению, выяснил причины по которым конкретные люди не увольняются. То вот тогда бы, можно было бы писать докладную записку на главного (только на самого главного, владельца бизнеса, а не кантри-менеджера который вполне может быть и в доле), где он бы во всех красках рассказал по каким реальным причинам дяди и тети сводят несводимый баланс и рисуют упомянутый выше P&L репорт. Вот тогда, бы история была бы намного интереснее.
Как показывает практика, книги, собственный опыт проведения собеседований, да и подтверждают давние дискуссии на различных технических площадках (за последние 15-20 лет) список вопросов почти один и тот же, а вот список «правильных» ответов на эти вопросы всегда меняется из года в год и от одной головы к другой.
А кто это такой красивый с пейсами и в железной кипе на превью у вас стоит?
Дейлики предназначены не для демонстрации бэклога, а идентификация проблем в проекте (утверждение Брукса про "почему проекты отстают на год") как можно раньше и подтверждение контракта. Таким образом - цели и проблемы.
Это также не задача daily. Задача меняет свой статус согласно жизненному циклу. Менять статус на daily -так себе идея, зачем тратить время общей встречи на это?
В задачах? В задачах может быть только AC. DoD/DoR определяют как минимум на процесс или на межпроцессное взаимодействие. Это намного шире и обще. Логика здесь какая? Каждая задача - разная. Круг работ - также разный и определяет соотвественно критерий приемки. А вот DoD - это комлекс общих процедур: например, какие-то нефункциональные требования или наличие сопроводительной документации и технической ревизии от двух людей итд для задач технического долга или дефектов.
Не, я все понимаю, но как теперь быть игрокам, которым в 3 части нужен был только Гвинт и Пассифлора? Если теперь Цирилла - ГГ как теперь по барделям ходить и морды бить в турнирах??? Верните Герыча!
А в чем смысл писать:
вместо:
?
Почитал ответы, увы до большинства так и не дошло, что автор сказал. Кстати, чего-то вспомнилось, что когда время позволяло посещать ПМ-конфы замечал, что большинство народа там просто банально безграмотные, то есть они знают что такое "скеджуал", "грумминг" и "рефайминг", но банально никто не понимал, когда спрашивали, например про "цикломатическую сложность задачи" или "факторный анализ".
Может я излишне строг, но большинство для которых применение скрама - это всего лишь "потому что все так делают, это ж модно", - то это секта.
В целом сервис понравился, хоть и засыпался на простом тесте:
вывело:
должно вывести:
Запросы не будут распределены равномерно (день/ночь, праздники, время года), будут считаться нормальными пики для распределения, это где-то 14.6-26.58 запросов в секунду.
У нас в команде есть мечта: однажды разработать идейного наследника Heroes of might and magic.
Каких версий героев? Движки и вторых (https://github.com/ihhub/fheroes2) и третих героев (https://github.com/vcmi/vcmi) есть на гитхабе, их давно разрабатывает сообщество. Билды доступны на рутрекере
А распознавание
{code}- это стандартная фишка Allure или надо писать свой класс "annotation expander"?Многие тут спорят TDD в Оракле или не TDD )) Народ, могу успокоить в версии Oracle многие вещи имеют «иное» понимание — от их реализации STL (особенно под UltraSparc лол) до их понимания паттернов проектирования в те года (особенно запомнилась с тех времен реализация PImpl).
Мое мнение Oracle существует только потому, что Ларри подмазал везде и у ЦРУ и IBM, и Apple, и Sun (когда он еще существовал) он с кем надо давно договорился — просто посмотрите его биографию и станет понятно — почему этот монстр до сих продается (только не надо мне про масштабируемость решений от Оракл) И да, легко верю автору, что хуже кода базы Оракл нет ничего в мире))
1. TestFlight + Google Play — для обоих решений требуется… никаких усилий, от слова совсем. Оба решения есть часть консоли разработчика Apple и Google. Уже будут и отчеты о крашах и распространение без «серых» сертификатов, вообще все «легально» и в «белую». Недостаток лишь один — недоступно распространение на Amazon и Samsung маркетплейсы (короче только Google).
2. HockeyApp — в принципе понравился тем что довольно легко интегрируем и даже без CocoaPods (я с большой настороженностью отношусь к неродным по отношению к продукту непрозрачным заскриптованным активностям в предкомпайл стадии).
Fabric в принципе это из мира единорогов ибо натягивается на любой нетривиальный сценарий сборки (иными словами любой что за пределами понимания разработчиков Fabric — т.е. все то, что не является ни xCode ни Android Studio/Eclipse) Так вот какие-то сценарии через CI с разными фокус группами распространения — такой геморрой. И если даже получится, то автоматизировать процесс «вычленения» этого «добра от Fabric» такой же ад. Вот эти «подсказки» с интеграцией и визарды мне напоминают «скрепыша» в 90-х годах MS Office — пользы ноль.
PS. Перечитал — как-то получается что я здесь выступаю хейтером Fabric. Но я, честно, не хотел этого, просто резануло глаз, что такой высокий балл в статье отдали именно Fabric — я не понимаю за что, стоимость интеграции у него гораздо выше.
Эх, жаль, название конторы-то не сказали, а то по некоторым признакам там еще есть и производственные отделы, и даже конструкторский отдел ) Это ведь намного-намного увлекательнее могло быть начало, типа «в первый день сотворения Компании был поставлен турникет, и первые люди сразу начали ходить через него, а потом вырасли стены конструкторского отдела...»
Могу предположить что запарка с закрытием периода, со сведением несводимого и проводками у финансового отдела (бухгалтеров) была из-за того, что кто-то в компании мутит с товарными позициями по черному. И уверен что делается это группой лиц, и даже почему-то не буду удивлен, что вот эта вот дама, условная жанна с крамольной «задачей реального бизнеса», всего лишь ширма, за которой таится яма безисходности в которой тонет и засасывает. Что сергей хотел оптимизировать? Колян-то небось на этот момент уже был в курсе про мифические остатки на складе и левые проводки с логистикой или сетями?
Как мы знаем прописную истину, сотрудники уходят не из компании, сотрудники всегда уходят от других людей. Вот здесь кроется все самое-самое главное. От других людей уходят. Вот в этом направлении я бы и копал — начиная с завхоза, старшего менеджера логистики и «продажников». Скорее всего именно от этого списка убегали эти николаи и сергеи, а не от условных битриксов или «ужасного» кода.
Сергей мог бы получить повышение (стоп, а что такое повышение вот этого Сергея? На таких компаниях это всегда — слив условной Жанны.) если бы он тихо начал бы исследовать предметно источники всей этот текучки, и главное(!), а это всегда ключ к повышению (тьфу) решению, выяснил причины по которым конкретные люди не увольняются. То вот тогда бы, можно было бы писать докладную записку на главного (только на самого главного, владельца бизнеса, а не кантри-менеджера который вполне может быть и в доле), где он бы во всех красках рассказал по каким реальным причинам дяди и тети сводят несводимый баланс и рисуют упомянутый выше P&L репорт. Вот тогда, бы история была бы намного интереснее.