Минусуют не за пиар статьи.
А из-за того, что у людей когнитивный диссонанс, они не могут понять, как можно обойтись без фреймворков.
Минусуют и комменты без ссылок.
А ссылку я вставляю только в постах, связанных с фремворками.
На собеседовании так уточнять, конечно же не стоит :)
Но если есть задача, то она должна быть нормально описана.
В примере выше с большой вероятностью заказчику не понравится текст какого-то фона или текста.
А программиста, наверно, часто задолбывали заказчики, которые сами не знают, чего хотят.
С такими заказчиками я поступаю так:
время работы над их заданиями откладываю, если начинают сыпаться уточнения, которые должны быть сразу.
Многие неясные моменты стараюсь выносить в конфиги.
Но иногда лучше уточнить требования, чтобы не мудохаться зря.
1. Спасибо за ликбез
2. Симфони один из наиболее сложных фреймворков, местами логичность страдает
3. Как он в сравнение с Ларавель?
4. Фреймворки в общем-то фигня: http://blog.kpitv.net/article/frameworks-1/
Может и нужно как-то бороться с веб-пиратством.
Но сами производители контанта тупорылые только провоцирую пиратство.
А еще в Украине все делается через задний проход.
Эти методологии разработки натянуты за уши и не везде подходят.
Вы не написали, что и на чем программируете.
1. Цели может и не быть. Ну или цель сделать то, что хочет заказчик. Но это наличие цели ради самого факта наличия цели.
>Задачи нарезаны таким образом, чтобы результат работы одного члена команды был использован другим членом команды в другом спринте.
А как их нужно резать? Чтобы результаты работы одного члена команды использовал тот же член команды?
Но разные люди могут работать над разными участками. Кто-то пишет АПИ, кто-то его использует.
Как это можно обойти?
>Таким образом, цель спринта — это командообразующий элемент скрама и хорошо подобранная цель — это то к чему стремится каждый из членов команды в течении спринта и это то что важно для всей команды в целом.
У каждого члена может быть своя цель…
2. Бюрократия
3. Та какой ритм? Как это все считается? Сферический конь в вакууме.
> Например, на график может повлиять постоянное изменение объема незапланированных задач, от спринта к спринту.
И что тут такого?
Баги-то фиксить нужно.
>Эта проблема в свою очередь может быть причиной срыва сроков спринта.
Дались Вам те сроки спринта.
>Также график производительности команды полезен при определении объема задач на спринт на основе метода вчерашней погоды.
Это все сферический конь в вакууме.
4. Что вообще такое ритм и производительность.
Провал ритма — это команда сидит и забила на работу? :)
5. Это ненужная вещь.
О проблеме нужно сообщать в задаче сразу, а не ждать DSM!
6.
> Во-первых, делая готовый продукт в конце спринта, команда избавляется от хвостов.
Заливайте в мастер готовые фичи и будет вам готовый продукт в любой момент!
> Новый спринт начинается с чистого листа, с новыми пользовательскими историями.
Не всегда успевают протестировать прошлый спринт в течение прошлого спринта!
>В-третьих, не приходится выпиливать куски кода для пользовательской истории, которая была наполовину реализована один или несколько спринтов назад и сильно упала в приоритете или совсем потеряла актуальность.
А если она была реализована полностью?
То как быть с выпиливанием?
Да и зачем ее выпиливыть, если хранить ее в отдельной ветке?
Ее в мастере и быть не должно.
Скрам вроде бы гибкая методология, но она никакая не гибкая.
Вы покупаете молоток в магазине, а потом дорабатываете его и половину выбрасываете? :)
А из-за того, что у людей когнитивный диссонанс, они не могут понять, как можно обойтись без фреймворков.
Минусуют и комменты без ссылок.
А ссылку я вставляю только в постах, связанных с фремворками.
http://blog.kpitv.net/article/frameworks-1/
Кто не считает, можете тоже сходит.
Статья изменит вашу точку зрения на фреймворки.
О чудо, тривиальные вещи делаются через тройные выверты.
Трезвый взгляд на фреймворки:
http://blog.kpitv.net/article/frameworks-1/
Но если есть задача, то она должна быть нормально описана.
В примере выше с большой вероятностью заказчику не понравится текст какого-то фона или текста.
А программиста, наверно, часто задолбывали заказчики, которые сами не знают, чего хотят.
С такими заказчиками я поступаю так:
время работы над их заданиями откладываю, если начинают сыпаться уточнения, которые должны быть сразу.
Многие неясные моменты стараюсь выносить в конфиги.
Но иногда лучше уточнить требования, чтобы не мудохаться зря.
2. Какая корелляция между внешним видом и фреймворком?
2. Симфони один из наиболее сложных фреймворков, местами логичность страдает
3. Как он в сравнение с Ларавель?
4. Фреймворки в общем-то фигня: http://blog.kpitv.net/article/frameworks-1/
Сама длительность спринта маразм.
Нужно реализовывать задачи, а не заниматься спринтостроением.
У меня на работе хоть и есть git, но старый код почему-то не удаляется.
Типа, а вдруг потом потребуется. :)
Но сами производители контанта тупорылые только провоцирую пиратство.
А еще в Украине все делается через задний проход.
Выгоды для страны ноль :)
ИБД.
Утверждение неверно.
Некоторый код может включатся / выключатся конфигами, когда нужно.
И это должно быть явно видно в самом коде.
Вы не написали, что и на чем программируете.
1. Цели может и не быть. Ну или цель сделать то, что хочет заказчик. Но это наличие цели ради самого факта наличия цели.
>Задачи нарезаны таким образом, чтобы результат работы одного члена команды был использован другим членом команды в другом спринте.
А как их нужно резать? Чтобы результаты работы одного члена команды использовал тот же член команды?
Но разные люди могут работать над разными участками. Кто-то пишет АПИ, кто-то его использует.
Как это можно обойти?
>Таким образом, цель спринта — это командообразующий элемент скрама и хорошо подобранная цель — это то к чему стремится каждый из членов команды в течении спринта и это то что важно для всей команды в целом.
У каждого члена может быть своя цель…
2. Бюрократия
3. Та какой ритм? Как это все считается? Сферический конь в вакууме.
> Например, на график может повлиять постоянное изменение объема незапланированных задач, от спринта к спринту.
И что тут такого?
Баги-то фиксить нужно.
>Эта проблема в свою очередь может быть причиной срыва сроков спринта.
Дались Вам те сроки спринта.
>Также график производительности команды полезен при определении объема задач на спринт на основе метода вчерашней погоды.
Это все сферический конь в вакууме.
4. Что вообще такое ритм и производительность.
Провал ритма — это команда сидит и забила на работу? :)
5. Это ненужная вещь.
О проблеме нужно сообщать в задаче сразу, а не ждать DSM!
6.
> Во-первых, делая готовый продукт в конце спринта, команда избавляется от хвостов.
Заливайте в мастер готовые фичи и будет вам готовый продукт в любой момент!
> Новый спринт начинается с чистого листа, с новыми пользовательскими историями.
Не всегда успевают протестировать прошлый спринт в течение прошлого спринта!
>В-третьих, не приходится выпиливать куски кода для пользовательской истории, которая была наполовину реализована один или несколько спринтов назад и сильно упала в приоритете или совсем потеряла актуальность.
А если она была реализована полностью?
То как быть с выпиливанием?
Да и зачем ее выпиливыть, если хранить ее в отдельной ветке?
Ее в мастере и быть не должно.
Скрам вроде бы гибкая методология, но она никакая не гибкая.