ясно понятно

А какие вообще бывают цели введения аджайла ?

Повышение прозрачность и предсказуемости ИТ отдела. Частые поставки повышают доверие Заказчика. Частая коммуникация - убирает недопонимание и Клиент пулчает имеено то о чем он подумал.

спасибо

Частая коммуникация убирает недопонимание и Клиент получает ровно то о чем подумал.

Тесты первыми (TDD) обеспечиевает меньшее число дефектов , что снижает стоимость разработки , поддержки.

Wiki как среда проектирования снижаест стоимость сопровождения и обучения. а занчит и влияние автобусного фактора. 1. пользовательская история —-> 2. проект решения (wiki) —-> 3. автотесты —-> 4. кодирование —> 5. демо если пропутить шаг 2 то система сдохнет через 2-3 поколения смены команды (тот самый проект Крайслера)

а Wiki как среда проектирования (и вообще документирование) вы рассматриваете как аджайл практику ?

ну это выглядит наверное как попытка обвинить но на самом деле я понял что оно довольно гибко всё. ну действительно круто если скрам мастера будут бороться за ведение документации

Человек- результат труда (труда ли?) двух человек

Не, смотри глубже. Это цепочка из бабушек-дедушек и их родителей рекурсивно :)

Человек- результат труда (труда ли?) двух человек

и культурной среды

а Wiki как среда проектирования (и вообще документирование) вы рассматриваете как аджайл практику ?

http://www.extremeprogramming.org/rules.html

14 сентября стартует первая очередь 1-й волны аgile-трансформации. Сотрудники блоков «Т» и «Розничный бизнес» Центрального аппарата, участвующие в трансформации, переезжают в специально оборудованное здание — бизнес-центр «Президент-Плаза» на Кутузовском проспекте, 32 в Москве. В этот день состоится Sbergile Town Hall — мероприятие для участников первой очереди 1-й волны. На встрече выступят Президент, Председатель Правления Герман Греф и другие топ-менеджеры Банка, а также Барт Шлатманн — chief operating officer ING, транснациональной финансовой группы из Нидерландов. Он поделится опытом внедрения Agile в ING Group и расскажет об основном аспекте трансформации — изменении корпоративной культуры. Из нового офиса Сбербанка в БЦ «Президент-Плаза» с 10:00 до 12:00 часов будет вестись онлайн-трансляция на www.sberbanktv.ru/live.

У нас есть

Всем привет! Продублирую из фейсбука вопрос: Всем привет! Поделитесь пожалуйста, как у вас организована (или как бы вы организовали) работа над ошибками (багами), которые выявляются на production (срочные, несрочные). С учетом того, что у вас над одним продуктом трудится 2-3 равнозначные feature teams? Кто и когда на нее реагирует? Как происходит выбор того, какая из feature teams возьмется за устранение ошибки? Фокусируется ли на этом Product Owner (следит ли за ошибками, способствует ли их устранению и как)?

привет, а можно узнать как вы сейчас решаете эту проблему?

У нас одна команда на все. Баги имеют приоритет выше чем фичи. Но в то же время есть разделение часов , % времени обязательный для разработки. Поддержка по канбан, разработка скрам(бан)

Если система стабильна, то эмпирически подбирается это соотношение. Но когда система растет или уходят люди, может быть просадка и прмходится хитрее лавировать между поддержкой и разработкой

Если есть несколько команд разработки, то можно вводить дежурство по кругу. Но лучшим мне кажется вводить норму выработки для каждой из команд. Например, в неделю 40 часов поддержки для команды 1 итд

Если есть несколько команд разработки, то можно вводить дежурство по кругу. Но лучшим мне кажется вводить норму выработки для каждой из команд. Например, в неделю 40 часов поддержки для команды 1 итд

А почему вы этот путь считаете лучшим?

У людей склонность к сохранению энергии, и при наличии несознательных членов команды в первом варианте проще получить ситуацию, когда начинают тягомотину по поддержке, ожидая конца дежурства

Грех заложен by design, так сказать :)

Всем привет! Продублирую из фейсбука вопрос: Всем привет! Поделитесь пожалуйста, как у вас организована (или как бы вы организовали) работа над ошибками (багами), которые выявляются на production (срочные, несрочные). С учетом того, что у вас над одним продуктом трудится 2-3 равнозначные feature teams? Кто и когда на нее реагирует? Как происходит выбор того, какая из feature teams возьмется за устранение ошибки? Фокусируется ли на этом Product Owner (следит ли за ошибками, способствует ли их устранению и как)?

Ошибки проходят квалификацию при появлении (можно воспроизвести / найдено в коде), дальше попадают в очередь с приоритетом, дальше тянутся разработкой. Если у вас команды не тянут задачи к себе в очередь, а вы пушите им в очередь, то согласуйте какие-то правила очередности для срочных/несрочных багов.

I <3 Scrum

Для понимания, я админ/полудевопс, сейчас повысили. у нас планируется agile и прочее. Хочется скажем так быть их тех рядов кто понимает в этом

Ты же отказывался вроде от повышения?)

Ты же отказывался вроде от повышения?)

Это уже другое

Это уже другое

Кстати я бы рекомендовал посмотреть доклады с agile days за прошлые года. Там есть хорошие для начала

и у скрам трека на ютубе тоже есть записи полезные

Кстати я бы рекомендовал посмотреть доклады с agile days за прошлые года. Там есть хорошие для начала

а поделись, пожалуйста тем, что тебя лично зацепило?

а поделись, пожалуйста тем, что тебя лично зацепило?

Это было год назад) прям конкретного доклада я уже не помню(

а поделись, пожалуйста тем, что тебя лично зацепило?

на youtube есть канал скрамтрек. Там все видео с презентаций. Рекомендую посмотреть хотя бы 5-10

scrumtrek

если люди больше работают значит и должны получать больше ЗП. значит и прибыль останется на прежнем уровне. но если платить столько же то прибыль увеличится

Больше или результативнее?

на youtube есть канал скрамтрек. Там все видео с презентаций. Рекомендую посмотреть хотя бы 5-10

я про скрамтрек выше написала))

я вам опять потролить принес

вопрос - какую проблему решает командная разработка ? по сравнению с разработкой одним человеком

недостаток ресурсов одного человека :)

да но каких ?

Время жизни?

много проблем решает: * ресурсы * квалификации * рефлексия * мотивация

ну с этим она не справится

https://ru.wikipedia.org/wiki/Ограниченность_ресурсов_(экономика)

квалификация это не проблема

это качество

увы

если рассматривать человека как ресурс

то наверное

но это не имеет смысла

ну вот ты сам тоже начал на вопрос свой отвечать. качество -- это тоже проблема

Вступить в обсуждение вопроса без контекста это значит сразу проиграть :)

если я в дизайне ни в зуб ногой, я могу, конечно лендинг нарисовать, но тупо подобрать цвета и сочетание элементов у меня уйдет раз в 5 больше времени, чем у человека с художественным вкусом (пусть он дальше фотошопа и не ходил никогда), и получится это хуже. я проверял 😀

так контекст то есть, "потроллить принес" ;-)

это не командная разработка это справедливое разделение труда

командная это в пределах одной области и одной задачи даже

ну я просто хочу сказать что например научные теории или архитектуры делаются строго в одиночку

так это и есть одна задача -- человек мне говорит какой цвет ставить, я быстро его ставлю (быстрее бы чем он сам сделал)

ну я просто хочу сказать что например научные теории или архитектуры делаются строго в одиночку

ну вообще-то нет

примерно как парное программирование

ну вот парное как раз командная

ок хорошо какую проблему решает парное ?

я ж написал в списке выше :-) и привел пример :-)

ну пример это пример

что в нем не так?

в том что пример это частное а я хочу общее

общее было в списке выше. частное было в примере

короче как вам такое - командная разработка возможна если есть много непроизводительного труда. иначе бы всё сделал один человек

ну тоесть если в делании дел очень много рутины типа писанины, тестирования то можно говорить о некотором факторе распаралеливания

я подозреваю что в сложных системах и громоздких языках этот фактор выше а в маленьких отзывчивых он ниже

лол

пришел кодерок и пытается теоретизировать ваши гадания ?

ты как-то свои догадки проверял?

хороший вопрос

ну я не стесняюсь потому что я походу единственный кто додумался их проверять из мира аджайла

лол)

А как проверял? ;)

а как вообще чтото проверяют ?

короче как вам такое - командная разработка возможна если есть много непроизводительного труда. иначе бы всё сделал один человек

Станислав, какую проблему решает твоя гипотеза?

она не решает она даёт понимание

Понимание чего? Зачем это понимать?

чтобы видя практику сказать плохая или хорошая