Команда 1 реализовала отдачу данных для Команды 2 и приступила к другим своим задачам. Через 3 дня Команда 2 обратилась к Команде 1 — данные не заливаются/данные не валидные и т.п.
Формат выдачи данных не был описан правильно (косяк Product Owner-a), либо команда реализовала неправильные тесты (накосячила команда).
Не зря в условиях внедрения scrum написано, что команда должна быть профессиональная и стабильная. Т.е. технические проблемы, инфраструктура и т.д. должны быть решены как никогда хорошо.
Ну либо такую задачу, в которой компоненты взаимодействуют так тесно, хорошо бы решать в одной команде. Тогда она сама может описать формат обмена и тестироваться все будет с самой начальной стадии.
Имхо, графики были бы чуть более легко-читабельными, если бы наименее изменяющиеся величины были нарисованы ниже, а выше — более изменяющиеся с возрастом. Не приходилось бы думать выясняя какая именно категория в какую перетекает.
Да за примером не обязательно далеко ходить. Можно просто посмотреть в прошлое. В СССР были именно ящики с прорезью. Контролеры типа существовали но я ни одного не помню за все свое детство.
Мораль видимо в том, что сложно добиваться честности от общества, в котором считается вполне нормальным взять то, что плохо лежит, кинуть, дать/взять взятку и т.д. и т.п.
Тварищи, суть рассказа в том, что заказчит выдвигает требования, которые противоречат сами себе. Рисовать на шарах, неевклидовых пространствах — это не решение. Единственное решение — объяснить заказчику, что он не правильно понимает термины, которыми оперирует. Либо наоборот, попросить их определения и использовать их вместо общепринятых.
Если совсем не идет — запросить поставку фломастеров которые являются одновременнео красными, зелеными и прозрачными. Продолжить обсуждение после подтверждения от заказчика, что эти фломастеры рисуют именно такие линии, которые ему надо.
Тогда я бы это скорее сравнил с трюками на валютных рынках и рынках ценных бумаг. Когда грамотно вброшенная дезинформация провоцирует неправильное поведение других игроков. Не знаю, на сколько это вообще наказуемо. По идее же сами дураки, если информацию не перепроверяют.
1. Покупатель знает, что половина сайтов в интернете — шарашкины конторы в подвалах. По этому не доверяет и хочет убедиться.
2. Половина сайтов (или даже больше) не выполняют заявленные обязательства. По доставке и наличию например. Естественно каждый хочет получить подтверждение того, что ему важно.
5. Интереснее было бы раскрыть в чем причина такого поведения. Я так подозреваю — дискомфорт при использовании интернета и компьютерных технологий в целом. Излишне гуманитарный склад ума еще может быть? ))
6. Не особо понял в чем отличие от п.2
Обращаясь к зарубежному опыту — т.к. проблема недоверия практически решена, никто и не думает звонить в амазон например. А для тех, кто «любит пообщаться» — телефоны линии поддержки обычно платные ))
Легко сказать «принять решение откладывать раз в месяц во что бы это не стало», трудно сделать. Ибо каждый месяц есть соблазн таки потратить заначку на что-то нужное.
Для реализации такого решения, я бы завел автоматическую ежемесячную транзакцию для перевода денег на другой счет (считаем, что зарплата приходит безналом). А на том втором счету нет ни карточки ни интернет-банка. Т.е. чтобы снять деньги — надо ехать в банк.
И еще надо как-то специально накосячить, чтобы ни один банк кредит не давал ))
Мне кажется, все указанные личности создавали свои «велосипеды» сознательно, осознанно и очень аргументированно. Например Брин точно понимал в чем недостаток существующих поисковиков и как именно он собирается их избежать.
Меняем в истории «мы долго готовили дочку, учили быстро бегать» на «учили дочку вообще ходить и вставать на ноги». И сразу появляется второй вывод — без владения базовыми техниками можно даже и не думать о «перешагивании скамеечек».
А может тогда проще продавать цифровые исходники. А покупатель сам распечатывает в соседней типографии. Пусть стоимость печати в 10 раз больше, но это получится 10 долларов в не 50 )).
Продолжая мысль, вместо специализированных магазинов нужно ставить специализированные типографии, заточенные на печать именно игр.
Конечно встает о пиратстве, но как-то ведь продают аудио-книги, mp3, игры и т.д.
После получения задачи. Новичок:
Ок, задание понятно начинаем кодить. Профессионал:
Правильно ли я понял задачу? Есть ли вероятность что автор имел ввиду что-то другое? Есть ли конфликты в постановке?
Проектирование Новичок:
О! У меня есть классная идея, как сделать это круто и правильно. Профессионал:
Поискать в коде, возможно такая функция уже есть. Осмотреться вокруг, возможно правильнее делать как все а не как лучше. Ок, нам нужно новое решение, возможно задача уже решалась, надо погуглить на тему готовых решений или идей.
Ну и отладка — это конечно эпично: Новичок:
О! Проверяем сценарии которые я закодил, все работает! Профессионал:
А есть ли сценарии, которые явно не указаны в задаче? А не используется ли измененный мною код еще где-то, что могло упасть?
Не помню, где прочитал, но мне очень нравится эта фраза. Она, как мне кажется, покрывает большинство указанных тезисов:
Профессионализм — это способность оценить меру своей НЕкомпетентности
Т.е. обычный специалист ищет подтверждения тому что он прав. Профессионал же, всегда считает, что он не прав и пытается найти доказательства обратному.
Ну про знания программистов, я не помню чтобы прям так жестко было. Наоборот постоянно упоминается о том, что нужно работать над распространением знаний между членами команд и разными командами.
С другой стороны скрам говорит, что команда должна уметь справляться с задачей самостоятельно. Т.е. если для выполнения какой-то задачи вот реально нужен сисадмин — значит он должен быть в команде. Хотябы частично.
Если для выполнения задачи требуются какие-то ресурсы или знания извне — я бы включал это в «definition of ready» для user-story. Например если в команде нету UI-дизайнеров, значит все необходимые элементы должны быть предоставлены вместе с задачей. Если требуется какая-то спецификация, разъяснение и т.д. о том, о чем команда понятия не имеет — значит задача не начинается до тех пор, пока соотв. люди эти артефакты не предоставят. Соотв. запрос команда может озвучить РО во время груминг-митинга.
Ну и никто не отменял «пойти спросить» когда команда сталкивается с вопросом вне ее компетенции.
Ну, скажем так, это вообще большая тема для дискуссии — на сколько реализуема коллективная ответственность, что из нее получается в российской реальности и т.д.
Может у нас никто не умеет обращаться с ответственностью именно потому, что у нас никто не умеет ее давать? Всмысле, что ответственность то у все давать любят а вот свободу — не очень. Это как в воспитании детей, одни контролируют каждый шаг «не дай бог что случится», другие даже не смотрят на ребенка, говоря «сам никогда и не научится пока сам не упадет, не ушибется не обожгется».
Но все же с моей точки зрения скрам это когда:
— девелоперы сами планируют свое время
— РО не имеет сроки а получает сроки от девелоперов. Если дедлайн ближе — значит нужно уменьшать функциональность (при неизменности команды)
Не зря одним из ярких пунктов в теории скрама — отсутствие тимлидера.
По поводу «послать любого» — для девелопера вообще никого не существует кроме РО и его коллег-девелоперов. Так что посылать просто должно быть некого ))
Вобщем пора отделять мух от котлет. С одной стороны у нас теория и «как по идее должно быть» с другой стороны практика и реальные условия внедрения. Но на мой вопрос «а что в скраме является необходимым требованием, а чем можно пренебречь есть ли гибкость в его теории» ответ был — «Если что-то написано в сркам-гайд, значит так и должно быть, нарушили условия — не получите обещанного прироста производительности».
Хотя, даже «неправильные» реализации скрама по некоторым данным позволяют выполнять задачи на 50-70% быстрее. «Настоящий» скрам обещает как-бы 200-300%, но я пока не увижу — не поверю ))
В чем соль скрама? Почему он быстрее даже при разработке тех же самых фич теми же самыми девелоперами? Многие думают, что суть в митингах и совместном обсуждении, или в том, что команды наконец стали кросс-функциональными, некоторые вообще назовут девелоперские практики их ХР.
Мое мнение: соль, главная цель и суть — переключение сознания с индивидуального на командное. Нет больше ничего личного ни личных тасков, ни личных проблем ни личного успеха. Только командное. Команда берет себе юзер-стори, команда ответственна за ее выполнение.
Обосрался один девелопер — обосралась вся команда. С другой стороны, если обосралась твоя команда — обосрался и ты, даже если ты сделал «свои таски» супер быстро и качественно.
И как следствие — команда осталась без бонуса — ты тоже его не увидишь, даже если ты вообще теоретически не мог помочь Васе, т.к. он пишет на С++ а ты — РНР-шник.
Возвращаясь к вашему сообщению. Конечно не может быть «каждый берет» и «кто хочет делать». Вопрос звучит так (грубо говоря)
— Эй, команда!!! Мы успеем сделать истории А, В, С за это спринт?
— Успеем!
— Зашибись! Давайте теперь обсудим детали, как именно (и уже здесь распределяем кто что может делать)
Истории\команда должны быть такими, чтобы ВСЯ команда работала над одной историей одновременно и только по ее окончанию переключалась на следующую.
Формат выдачи данных не был описан правильно (косяк Product Owner-a), либо команда реализовала неправильные тесты (накосячила команда).
Не зря в условиях внедрения scrum написано, что команда должна быть профессиональная и стабильная. Т.е. технические проблемы, инфраструктура и т.д. должны быть решены как никогда хорошо.
Ну либо такую задачу, в которой компоненты взаимодействуют так тесно, хорошо бы решать в одной команде. Тогда она сама может описать формат обмена и тестироваться все будет с самой начальной стадии.
Мораль видимо в том, что сложно добиваться честности от общества, в котором считается вполне нормальным взять то, что плохо лежит, кинуть, дать/взять взятку и т.д. и т.п.
Если совсем не идет — запросить поставку фломастеров которые являются одновременнео красными, зелеными и прозрачными. Продолжить обсуждение после подтверждения от заказчика, что эти фломастеры рисуют именно такие линии, которые ему надо.
Единственное, что было сделано — покупатель представился другим именем и предоставил ложное объяснение цели покупки.
Я думаю такое деяние ни под одну статью какого-либо кодекса не попадает ))
1. Покупатель знает, что половина сайтов в интернете — шарашкины конторы в подвалах. По этому не доверяет и хочет убедиться.
2. Половина сайтов (или даже больше) не выполняют заявленные обязательства. По доставке и наличию например. Естественно каждый хочет получить подтверждение того, что ему важно.
5. Интереснее было бы раскрыть в чем причина такого поведения. Я так подозреваю — дискомфорт при использовании интернета и компьютерных технологий в целом. Излишне гуманитарный склад ума еще может быть? ))
6. Не особо понял в чем отличие от п.2
Обращаясь к зарубежному опыту — т.к. проблема недоверия практически решена, никто и не думает звонить в амазон например. А для тех, кто «любит пообщаться» — телефоны линии поддержки обычно платные ))
Для реализации такого решения, я бы завел автоматическую ежемесячную транзакцию для перевода денег на другой счет (считаем, что зарплата приходит безналом). А на том втором счету нет ни карточки ни интернет-банка. Т.е. чтобы снять деньги — надо ехать в банк.
И еще надо как-то специально накосячить, чтобы ни один банк кредит не давал ))
Продолжая мысль, вместо специализированных магазинов нужно ставить специализированные типографии, заточенные на печать именно игр.
Конечно встает о пиратстве, но как-то ведь продают аудио-книги, mp3, игры и т.д.
Знаю, что звучит утопично, так, прикола ради ))
После получения задачи.
Новичок:
Ок, задание понятно начинаем кодить.
Профессионал:
Правильно ли я понял задачу? Есть ли вероятность что автор имел ввиду что-то другое? Есть ли конфликты в постановке?
Проектирование
Новичок:
О! У меня есть классная идея, как сделать это круто и правильно.
Профессионал:
Поискать в коде, возможно такая функция уже есть. Осмотреться вокруг, возможно правильнее делать как все а не как лучше. Ок, нам нужно новое решение, возможно задача уже решалась, надо погуглить на тему готовых решений или идей.
Ну и отладка — это конечно эпично:
Новичок:
О! Проверяем сценарии которые я закодил, все работает!
Профессионал:
А есть ли сценарии, которые явно не указаны в задаче? А не используется ли измененный мною код еще где-то, что могло упасть?
И т.д. и т.п.
Т.е. обычный специалист ищет подтверждения тому что он прав. Профессионал же, всегда считает, что он не прав и пытается найти доказательства обратному.
Если от сисадмина в задаче больше толку, чем от программиста — значит он там действительно главную роль играть должен.
С другой стороны скрам говорит, что команда должна уметь справляться с задачей самостоятельно. Т.е. если для выполнения какой-то задачи вот реально нужен сисадмин — значит он должен быть в команде. Хотябы частично.
Если для выполнения задачи требуются какие-то ресурсы или знания извне — я бы включал это в «definition of ready» для user-story. Например если в команде нету UI-дизайнеров, значит все необходимые элементы должны быть предоставлены вместе с задачей. Если требуется какая-то спецификация, разъяснение и т.д. о том, о чем команда понятия не имеет — значит задача не начинается до тех пор, пока соотв. люди эти артефакты не предоставят. Соотв. запрос команда может озвучить РО во время груминг-митинга.
Ну и никто не отменял «пойти спросить» когда команда сталкивается с вопросом вне ее компетенции.
Может у нас никто не умеет обращаться с ответственностью именно потому, что у нас никто не умеет ее давать? Всмысле, что ответственность то у все давать любят а вот свободу — не очень. Это как в воспитании детей, одни контролируют каждый шаг «не дай бог что случится», другие даже не смотрят на ребенка, говоря «сам никогда и не научится пока сам не упадет, не ушибется не обожгется».
Но все же с моей точки зрения скрам это когда:
— девелоперы сами планируют свое время
— РО не имеет сроки а получает сроки от девелоперов. Если дедлайн ближе — значит нужно уменьшать функциональность (при неизменности команды)
Не зря одним из ярких пунктов в теории скрама — отсутствие тимлидера.
По поводу «послать любого» — для девелопера вообще никого не существует кроме РО и его коллег-девелоперов. Так что посылать просто должно быть некого ))
Вобщем пора отделять мух от котлет. С одной стороны у нас теория и «как по идее должно быть» с другой стороны практика и реальные условия внедрения. Но на мой вопрос «а что в скраме является необходимым требованием, а чем можно пренебречь есть ли гибкость в его теории» ответ был — «Если что-то написано в сркам-гайд, значит так и должно быть, нарушили условия — не получите обещанного прироста производительности».
Хотя, даже «неправильные» реализации скрама по некоторым данным позволяют выполнять задачи на 50-70% быстрее. «Настоящий» скрам обещает как-бы 200-300%, но я пока не увижу — не поверю ))
В чем соль скрама? Почему он быстрее даже при разработке тех же самых фич теми же самыми девелоперами? Многие думают, что суть в митингах и совместном обсуждении, или в том, что команды наконец стали кросс-функциональными, некоторые вообще назовут девелоперские практики их ХР.
Мое мнение: соль, главная цель и суть — переключение сознания с индивидуального на командное. Нет больше ничего личного ни личных тасков, ни личных проблем ни личного успеха. Только командное. Команда берет себе юзер-стори, команда ответственна за ее выполнение.
Обосрался один девелопер — обосралась вся команда. С другой стороны, если обосралась твоя команда — обосрался и ты, даже если ты сделал «свои таски» супер быстро и качественно.
И как следствие — команда осталась без бонуса — ты тоже его не увидишь, даже если ты вообще теоретически не мог помочь Васе, т.к. он пишет на С++ а ты — РНР-шник.
Возвращаясь к вашему сообщению. Конечно не может быть «каждый берет» и «кто хочет делать». Вопрос звучит так (грубо говоря)
— Эй, команда!!! Мы успеем сделать истории А, В, С за это спринт?
— Успеем!
— Зашибись! Давайте теперь обсудим детали, как именно (и уже здесь распределяем кто что может делать)
Истории\команда должны быть такими, чтобы ВСЯ команда работала над одной историей одновременно и только по ее окончанию переключалась на следующую.