Пост про то, что менеджеры прогнулись под клиента.
Работаю и с ZF/ZF2 и с Битриксом, и если честно, то в шоке. Вопрос один — «зачем?»
Клиент пашет поля, но ему нравится порше, говорят, что порше очень хорош. Мы прикрутили к порше плуг.
В итоге ни пахать не сможет, ни ездить комфортно.
Если клиент хочет битрикс, а вы любите писать на ZF, то вы ищите другого клиента, а клиент — другого исполнителя.
Тоже перехожу на scrum с водопада.
Спасибо за интересную статью и не менее интересные комментарии.
Теоретические моменты все понятны, но наблюдая за реальным опытом команд возникает ощущение «мой скрам лучше твоего».
Пока не видел ни одной команды, которая работала бы в полном соответствии со «стандартом», поэтому можно говорить именно о выстраивании процесса на основе scrum и в данном случае, реальный опыт крайне полезен для сравнения и понимания.
Некоторые вопросы (интересует именно реальный опыт команд), которые возникают, при попытке примерить процесс на себя:
— Насколько плотно у вас заказчик вовлечен в процесс? Присутствует ли он при обсуждении и сдаче спринтов?
— Как вписывается в процесс ревью кода и тестирование? В долгосрочном проекте фичу нельзя считать законченной, пока она не протестирована и ее код не принят.
— Есть ли у кого-то еще опыт разработки по TDD в рамках scum? Здесь говорится, что тесты пишут аналитики и до старта спринта. Мне кажется, что спринт — это целостная единица, в течении которой должны быть выполнены все работы по user story, а тесты должен писать сам разработчик. Или в рамках user story создается несколько задач (написать тест, запрограммировать, протестировать,..) и каждая из них может браться в разный спринт? Как же тогда демонстрировать такие задачи? Мне кажется, будут возникать те же проблемы, что и при водопаде — проблемы вслывают в самом конце, в результате чего и получаем 90% + еще 90% работы.
— Есть ли у кого-то личный опыт ведения процесса через Redmine? Используются ли какие-то плагины (можете посоветовать) или процесс ведется на доске, а задачи в Redmine?
— Есть ли реально практикующие недельные спринты? У меня такое же ощущение, что недели для полного цикла (постановка задачи, покрытие тестами, программирование, тестирование) мало, согласен в этом вопросе с автором, но часто вижу упоминания именно о недельных спринтах.
— Как у вас реализуется тестирование? Тестируется весь спринт целиком по завершении или каждый таск отдельно?
— Часто слышу, что брать в спринт больше задач, чем можно реально сделать — это нормально. В принципе, смысл в этом есть. Или же лучше брать меньше, но зато делать все в срок? Но как тогда быть с требованием не менять состав спринта в течение его разработки?
Я думаю, пока эппл делает такие качественные продукты таким предложения будет крайне сложно найти отклик.
Все правильно сказано, но люди не хотят знать ничего о лицензиях, они хотят, чтобы было удобно, ничего не тормозило и не нужно было разбираться в том как что-то настроить или отключить.
Поэтому сообщение выглядит как зависть. Возможно стоило бы выбрать менее эмоциональный тон и добиваться свободы ПО более настойчиво, агрументируя лучшим качеством самого ПО.
Свободное ПО имеет массу плюсов, я всегда стараюсь пользоваться именно открытым ПО, но вот в плане противостояния андроид / ios, в моем лично случае, победил эппл.
Дыма без огня не бывает.
Кто-то в скором времени начнет рекламировать новую «суперзащищенную» почту, новую функцию в антивирусе, какое-то ПО для защиты почты или что-то смежное.
Спасибо за наводки (Chef Vagrant).
Тоже пытаюсь похожую систему настроить — рассинхрон версий и длительный подъем окружения начинает напрягать.
Если была бы статья — было бы здорово.
Я пока не совмещаю )
У нас чистый водопад, и я пытаюсь понять, что как будет, если перейти на scrum.
В скрам'е все нравится, и вроде бы скрам решает все вопросы, которые сейчас встают.
Но пока все теоретически. Думаю, как наиболее безболезненно «мигрировать», в основном, беспокоит вопрос готовности заказчиков.
Возникают те же самые вопросы.
В свое время нативно наработали практически тот же scrum, но не хватало учета скорости + с ростом проекта возникало все больше задач по обслуживанию самого проекта (миграция данных, разнос по серверам, наработка инфраструктуры, оптимизация, исследования,..) и в результате нам казалось что мы делаем очень много, а заказчику — что очень мало.
Навскидку scrum гораздо выгоднее разработчикам, для заказчика плюсы в первую очередь в гибкости (поскольку если фиксируется бюджет и сроки, то уже и менять задачи разработчики не дадут) ну и в поточности — можно работать по проекту непрерывно.
Интересно было бы услышать мнение руководителей разработки и заказчиков (со стороны разработчиков процесс понятен).
Спасибо, большое за ответ.
Вроде все понимал, но традиционный подход заказчиков: «сколько денег и времени?» и частые делдлайны внесли свою лепту.
Правильно ли я понимаю, что время (а точнее выполненный объем в единицу времени) можно сказать только по прошествии нескольких спринтов и оно так же может меняться от раза к разу, а работа идет по принципу «от забора и до обеда» — время вышло, не успели — не важно, решится уже в следующем спринте за доп.оплату?
И еще вопрос — как заказчик в таком случае оценивает эффективность? Как мотивируется команда на увеличение скорости работы? Есть ли какие-то механизмы для этого в scrum или решается внутри каждой команды по своему?
У меня вопрос — как абстрактные Story Points в итоге трансформируются в часы? Получается, что все-таки 1 Story Points имеет фиксированную временную оценку?
Эппл прокомментировала ситуацию, заявив, что взлома iCloud не было, а был взлом отдельных аккаунтов и посоветовала пользователям делать более сложные пароли.
Адвокаты звезд заявили, что будут судиться с теми, кто распространяет фото )
Была похожая ситуация на одном боевом проекте.
Решилась установкой одинаковых версий на сервере и у всех участников. После этого сбоев и падений репозиториев не было.
Что-то iCloud зачастило в последнее время.
Хороший повод заострить внимание на проблеме.
А то слишком уже все безолаберно происходит — юзер никогда не читает длинное страшное соглашение, много всего идет по дефолту. Хорошо я программист, а большинство знакомых не подозревают даже, что их фотки с айфонов копируются в облако.
В идеале нужно какое-то членораздельное предупреждение для людей (типа — смотрите, фото будет храниться на нашем сервере и может быть украдено), со ссылкой уже на полный текст соглашения и выбор — включать функционал или нет.
Ну и компании, я считаю, раз уж используют облачные хранилища как маркетинговый плюс при продаже устройств должны отвечать за сохранность информации и обеспечивать ее. Интересно, будут иски и суды?
Сиськи сиськами, а вообще последствия могут быть весьма катастрофическими. Тут и недавно обсуждаемая тема про дистанционное превращения аппарата в кирпич не поможет.
Ну продают одни, а нажимать будут другие )
События последних дней показывают, что политика все-таки рулит и экономикой.
А вообще давайте меньше о политике — для нее много других мест.
В определенных условиях, при условии, что «красная кнопка» будет у владельца аппарата, функционал имеет смысл — зачастую потеря конфиденциальной информации многократно страшнее потери самого телефона.
А вырубить все девайсы «в радиусе», при необходимости, можно и сейчас.
Работаю и с ZF/ZF2 и с Битриксом, и если честно, то в шоке. Вопрос один — «зачем?»
Клиент пашет поля, но ему нравится порше, говорят, что порше очень хорош. Мы прикрутили к порше плуг.
В итоге ни пахать не сможет, ни ездить комфортно.
Если клиент хочет битрикс, а вы любите писать на ZF, то вы ищите другого клиента, а клиент — другого исполнителя.
Спасибо за интересную статью и не менее интересные комментарии.
Теоретические моменты все понятны, но наблюдая за реальным опытом команд возникает ощущение «мой скрам лучше твоего».
Пока не видел ни одной команды, которая работала бы в полном соответствии со «стандартом», поэтому можно говорить именно о выстраивании процесса на основе scrum и в данном случае, реальный опыт крайне полезен для сравнения и понимания.
Некоторые вопросы (интересует именно реальный опыт команд), которые возникают, при попытке примерить процесс на себя:
— Насколько плотно у вас заказчик вовлечен в процесс? Присутствует ли он при обсуждении и сдаче спринтов?
— Как вписывается в процесс ревью кода и тестирование? В долгосрочном проекте фичу нельзя считать законченной, пока она не протестирована и ее код не принят.
— Есть ли у кого-то еще опыт разработки по TDD в рамках scum? Здесь говорится, что тесты пишут аналитики и до старта спринта. Мне кажется, что спринт — это целостная единица, в течении которой должны быть выполнены все работы по user story, а тесты должен писать сам разработчик. Или в рамках user story создается несколько задач (написать тест, запрограммировать, протестировать,..) и каждая из них может браться в разный спринт? Как же тогда демонстрировать такие задачи? Мне кажется, будут возникать те же проблемы, что и при водопаде — проблемы вслывают в самом конце, в результате чего и получаем 90% + еще 90% работы.
— Есть ли у кого-то личный опыт ведения процесса через Redmine? Используются ли какие-то плагины (можете посоветовать) или процесс ведется на доске, а задачи в Redmine?
— Есть ли реально практикующие недельные спринты? У меня такое же ощущение, что недели для полного цикла (постановка задачи, покрытие тестами, программирование, тестирование) мало, согласен в этом вопросе с автором, но часто вижу упоминания именно о недельных спринтах.
— Как у вас реализуется тестирование? Тестируется весь спринт целиком по завершении или каждый таск отдельно?
— Часто слышу, что брать в спринт больше задач, чем можно реально сделать — это нормально. В принципе, смысл в этом есть. Или же лучше брать меньше, но зато делать все в срок? Но как тогда быть с требованием не менять состав спринта в течение его разработки?
Все правильно сказано, но люди не хотят знать ничего о лицензиях, они хотят, чтобы было удобно, ничего не тормозило и не нужно было разбираться в том как что-то настроить или отключить.
Поэтому сообщение выглядит как зависть. Возможно стоило бы выбрать менее эмоциональный тон и добиваться свободы ПО более настойчиво, агрументируя лучшим качеством самого ПО.
Свободное ПО имеет массу плюсов, я всегда стараюсь пользоваться именно открытым ПО, но вот в плане противостояния андроид / ios, в моем лично случае, победил эппл.
Кто-то в скором времени начнет рекламировать новую «суперзащищенную» почту, новую функцию в антивирусе, какое-то ПО для защиты почты или что-то смежное.
Тоже пытаюсь похожую систему настроить — рассинхрон версий и длительный подъем окружения начинает напрягать.
Если была бы статья — было бы здорово.
Scrum, по сути фреймворк, и каждый, мне кажется, нарабатывает свою схему.
У нас чистый водопад, и я пытаюсь понять, что как будет, если перейти на scrum.
В скрам'е все нравится, и вроде бы скрам решает все вопросы, которые сейчас встают.
Но пока все теоретически. Думаю, как наиболее безболезненно «мигрировать», в основном, беспокоит вопрос готовности заказчиков.
Мне, как разработчику, подход нравится, а вот как к этому относится заказчик — интересно узнать.
В свое время нативно наработали практически тот же scrum, но не хватало учета скорости + с ростом проекта возникало все больше задач по обслуживанию самого проекта (миграция данных, разнос по серверам, наработка инфраструктуры, оптимизация, исследования,..) и в результате нам казалось что мы делаем очень много, а заказчику — что очень мало.
Навскидку scrum гораздо выгоднее разработчикам, для заказчика плюсы в первую очередь в гибкости (поскольку если фиксируется бюджет и сроки, то уже и менять задачи разработчики не дадут) ну и в поточности — можно работать по проекту непрерывно.
Интересно было бы услышать мнение руководителей разработки и заказчиков (со стороны разработчиков процесс понятен).
Вроде все понимал, но традиционный подход заказчиков: «сколько денег и времени?» и частые делдлайны внесли свою лепту.
Правильно ли я понимаю, что время (а точнее выполненный объем в единицу времени) можно сказать только по прошествии нескольких спринтов и оно так же может меняться от раза к разу, а работа идет по принципу «от забора и до обеда» — время вышло, не успели — не важно, решится уже в следующем спринте за доп.оплату?
И еще вопрос — как заказчик в таком случае оценивает эффективность? Как мотивируется команда на увеличение скорости работы? Есть ли какие-то механизмы для этого в scrum или решается внутри каждой команды по своему?
Адвокаты звезд заявили, что будут судиться с теми, кто распространяет фото )
Решилась установкой одинаковых версий на сервере и у всех участников. После этого сбоев и падений репозиториев не было.
Было бы крайне интересно увидеть продолжение — про анализ и устранение проблем.
Люблю хабр за то, что всегда актуально. Как раз сейчас для меня актуально настолько, что актуальнее некуда )
Хороший повод заострить внимание на проблеме.
А то слишком уже все безолаберно происходит — юзер никогда не читает длинное страшное соглашение, много всего идет по дефолту. Хорошо я программист, а большинство знакомых не подозревают даже, что их фотки с айфонов копируются в облако.
В идеале нужно какое-то членораздельное предупреждение для людей (типа — смотрите, фото будет храниться на нашем сервере и может быть украдено), со ссылкой уже на полный текст соглашения и выбор — включать функционал или нет.
Ну и компании, я считаю, раз уж используют облачные хранилища как маркетинговый плюс при продаже устройств должны отвечать за сохранность информации и обеспечивать ее. Интересно, будут иски и суды?
Сиськи сиськами, а вообще последствия могут быть весьма катастрофическими. Тут и недавно обсуждаемая тема про дистанционное превращения аппарата в кирпич не поможет.
События последних дней показывают, что политика все-таки рулит и экономикой.
А вообще давайте меньше о политике — для нее много других мест.
В определенных условиях, при условии, что «красная кнопка» будет у владельца аппарата, функционал имеет смысл — зачастую потеря конфиденциальной информации многократно страшнее потери самого телефона.
А вырубить все девайсы «в радиусе», при необходимости, можно и сейчас.